Engineering/Research Lead - GPU Code Translation in Southampton

Our portfolio company is aiming to become a unicorn and is a leader in code translation platform. Not a one-shot port but a continuous, drift-aware sync between languages and runtimes. You point us at a CUDA codebase, we produce maintainable HIP source. You merge a CUDA commit upstream, we ship a clean HIP PR. The output lives in your repo, auditable and tunable, not behind a binary blob or a runtime shim.

The GPU translation market has three incumbents and one open seam:

• ZLUDA translates PTX to AMDGPU IR at runtime. No source artifact. AMD just pulled their funding.
• SCALE (Spectral Compute) compiles CUDA C++ directly to AMD ISA. They claim up to 33× over HIP on MI300X. The output is an opaque binary you cannot read, audit, or hand-tune.
• hipify-clang produces readable HIP. It also leaves an order of magnitude of performance on the floor because mechanical translation doesn’t understand warp-size assumptions, MFMA layouts, async-copy semantics, or cooperative-groups gaps.

If SCALE is 33× faster than hipify-style mechanical output on real kernels, that gap is what mechanical translation costs. We’re betting that a small model (7–14B), trained with verifiable rewards against compile + numerical-equivalence + performance signals, can produce HIP that’s both readable AND close to expert-tuned. Small enough to run on the same ROCm box the customer is already paying for, so translation happens in-process, on the fly.

You’d own the technical track that proves or disproves that bet. You’re the technical owner of GPU code translation. You define the verification harness, the data, the training, the model architecture choices, and the inference path. You report directly to the founders. Your first hire under you will likely be the half of this triangle you’re weakest on: compiler engineer or ML researcher.

Must-haves:

• GPU systems internals you’ve earned the hard way. PTX and AMDGPU ISA. Warp (32) vs wavefront (64) and the hundred subtle bugs that one number causes. MFMA vs WMMA vs tensor-core layouts. cp.async lowering. LDS bank conflicts. Cooperative-groups gaps in HIP. cuBLAS/cuDNN vs rocBLAS/MIOpen API divergence points. You can look at hipify-clang output and tell us, by reading, where it lost the throughput.
• Compiler internals. LLVM/MLIR, lowering passes, AST-driven rewrites (Clang or equivalent). You know why a peephole rewrite is sometimes wrong and a structural one is needed.
• Code-model training with verifiable rewards. SFT, GRPO/DPO/RLVR where the reward is compile + correct + within performance budget, not human preference. Distillation from larger teachers. You understand translation stability as a training objective - same input, same output across runs — and why our continuous-sync product depends on it.
• Production inference. vLLM or SGLang on ROCm (not just CUDA). FP8/AWQ quantization tradeoffs on AMD silicon. Speculative decoding with a tiny draft model. You know what 7–14B actually buys you and what’s structurally infeasible there.
• You’ve shipped at least one of the above in production, not just published.

Strong nice-to-haves:

• AMD ROCm or NVIDIA CUTLASS production background.
• CUTLASS-class or Composable Kernels-class kernel authorship.
• Code-model training experience in the StarCoder / DeepSeek-Coder / Qwen-Coder lineage.
• Polyhedral compilation or auto-tuning (Polly, Polygeist, TVM, Triton).
• Track record with rocprof, omnitrace, ncu, or nsight on real workloads.
• Open-source contributions to hipify, ZLUDA, SCALE, Polygeist, Triton, or LLVM AMDGPU.

What we don’t care about:

• PhD vs no PhD.
• Years of experience as a number.
• Whether you can pass a leetcode round.
• Whether your last title said “Principal” or “Staff”.

What we offer:

• Founding technical seat. Meaningful equity. Direct line to the founders.
• Compute budget sized to actually do the work - not the usual startup ration.
• A roadmap problem with verifiable signal end-to-end: compile, run, measure. You can know whether you’re winning.
• Bias toward shipping. We prefer one bundled PR over five small ones. We don’t waste your time with status theatre.

We will be asking for the following:

1. The most under-discussed pitfall of CUDA-to-HIP translation that you have personally hit, in one paragraph.
2. A GPU kernel you wrote that you’re proud of, and the one decision in it that an outsider wouldn’t have made.