July's HN "Who Is Hiring" Has 8 Kernel Roles. The Global Pool Is 30.

The July 2026 "Ask HN: Who is hiring?" thread (item 48747976) went live 13 hours ago and reads less like a job board than an arXiv table of contents. Persistent-kernel LLM engines, fused Triton dequant+attention, monokernel decode pipelines, gigawatt datacenter buildouts. If you are a recruiter opening this thread with a LinkedIn tab and a "CUDA" keyword filter, you are already lost.

The addressable pool for these roles is not "GPU engineers." It is roughly 200 people on earth who have shipped code into five open-source repositories. Here is where they are.

The July 2026 HN thread is a kernel-author job board in disguise

The top posts on HN item 48747976 are not generic ML roles; they are engineering abstracts asking for named primitives (monokernel decode, fused dequant+attention, persistent kernels) that fewer than a few hundred people worldwide have ever written. Screening these with title keywords fails on the first phone call.

The three anchor posts to look at:

• Kog (Paris) is hiring a GPU Engineer for "the fastest LLM inference engine on standard datacenter GPUs," owning "low-level kernel work in CUDA/PTX or HIP/CDNA ISA, the monokernel pipeline." Their public benchmark: 3,000 tokens/s per request on 8x AMD MI300X and 2,100 on 8x NVIDIA H200, batch size 1, FP16, no speculative decoding.
• PODOS AI / Syntropic wants a fused Triton/CUDA dequant + attention kernel engineer. That is one primitive, not a stack.
• Fluidstack is hiring against its $50B Anthropic partnership (signed November 12, 2025), building Texas and New York facilities online throughout 2026, roughly 800 permanent and 2,400 construction roles.

None of these are interchangeable with "senior ML engineer." Kog's own JD contains the shibboleth: "At batch size 1, the decode is GEMV, so it is memory bandwidth bound, and MBU is what counts." A candidate who cannot discuss Model Bandwidth Utilization vs. Model FLOPs Utilization is out in five minutes. Recruiters who screen on "LLM experience" filter in the wrong 99%.

Why LinkedIn keyword search returns the wrong 99%

Because "kernel author" is a task, not a title. The people who write these kernels sit inside PyTorch, DeepMind, Anthropic, character.ai, or Together with the job title "Member of Technical Staff," and they do not put "Triton" in their skills section.

Here is what the numbers look like when you actually run the query.

30

Thirty people. That is the entire titled pool for a role every serious inference startup is now hiring for. In the US, the number drops to ten, concentrated in the SF Bay Area and Austin, at Apple, Meta, NVIDIA, Rivos, Qualcomm, Intel, and Vorticity.

If you keep sourcing off titles, you are fighting eight companies (Kog, PODOS, Syntropic, Fluidstack, plus the four Anthropic-adjacent posters in the thread) over the same thirty names. Everyone loses except the candidates.

The real pool is 66x bigger and lives in contributor graphs

The addressable talent surface for CUDA kernel recruiting is the union of contributor graphs from five OSS projects, not job titles. It is roughly 2,000+ people if you count lifetime commits, and roughly 200-250 if you count anyone active in the last quarter.

The five graphs that matter, in rough order of signal:

1. vLLM (vllm-project/vllm). The canonical modern inference stack. A single recent release shipped 558 commits from 232 contributors, 64 of them new. The SIG-performance and SIG-core member handles (@WoosukKwon, @njhill, @mgoin, @dsikka) are public in the Q2 2026 roadmap issue (#39749).
2. llama.cpp (ggml-org/llama.cpp). The CPU/Metal/CUDA hobbyist-to-production pipeline. Contributors here skew toward independent operators who take term sheets fast.
3. SGLang (LMSYS). The runtime that quietly powers a lot of research infra. Smaller graph, higher signal-per-name.
4. OpenAI Triton (triton-lang/triton). PR authors here are the people writing the kernels that PyTorch 2.x's torch.compile lowers to by default. This is the fastest-growing Triton kernel engineer pool on earth.
5. NVIDIA CUTLASS (NVIDIA/cutlass). C++ template-metaprogramming heavy. Overlaps hard with the classic HPC / graphics veterans.

Add FlashInfer and Liger-Kernel for depth, and GPU MODE Discord (formerly CUDA MODE) as the live meeting place. Recruiters are largely absent from GPU MODE; principals are present.

This is the exact gap Refolk closes for GPU engineer sourcing: you describe the person in plain English (a vLLM committer who has touched paged attention, based in Europe, currently at a big lab) and get the ranked shortlist across GitHub and LinkedIn in one pass. You are searching the commit graph, not the title graph.

Triton inverted the last decade of CUDA hiring

Triton (OpenAI's Python-embedded DSL for GPU kernels) is now the default kernel layer in PyTorch 2.x, and that has flipped the sourcing profile for kernel work from C++ HPC veterans to Python-native ex-researchers. If your ideal-candidate profile still says "10 years CUDA C++," you are sourcing a lagging signal.

The mechanism, briefly:

• torch.compile lowers to Triton by default.
• vLLM's attention backends (PagedAttention, ROPE, RMS Norm) are written in Triton.
• FlashAttention 2 and 3 use Triton for Hopper.
• Liger-Kernel is 100% Triton.

The practical consequence: the fastest-growing Triton kernel engineer pool is people whose LinkedIn says "Research Engineer" at a lab, whose GitHub shows a stream of .py files decorated with @triton.jit, and who have never once written the word "CUDA" on their resume. A boolean search for "CUDA" AND "kernel" misses them entirely.

Kernel work is a task, not a title. Ninety-nine percent of the people who can do it will never show up in a title search.

The five-year-out consequence is worse. C++ CUDA veterans still matter for CUTLASS-heavy work (dense GEMM, sparse attention primitives), but the marginal LLM inference hiring win is now a 26-year-old who wrote a Triton fused RMSNorm+ROPE for a research project and shipped it to vLLM upstream. They do not answer InMails. They answer pull request review requests.

Persistent kernels are converging, which is why 8 companies want the same 20 people

Kog's "monokernel" is not a fringe idea; it is a live research direction inside vLLM itself, which means Kog, PODOS, Syntropic, and the vLLM core team are all hiring against roughly the same 20-person shortlist.

From the vLLM performance working group: "To address this, we designed persistent kernels (PRs to vLLM pending)." The Kog HN post describes essentially the same architectural bet. The pending-PR authors on that thread are, quite literally, the shortlist for at least three of the roles in the July HN thread.

Two implications for anyone doing LLM inference hiring right now:

• Compete on speed of contact, not on JD polish. These candidates have three to five active conversations. The first credible technical outreach wins the meeting. Attribution to a specific PR beats a rewritten JD.
• Compete on the problem, not the comp band. The candidates who write persistent kernels for fun are picking based on the substrate: which GPU, which model family, which quantization scheme. Recruiters who cannot answer "what is the MBU target on H200?" lose the intro call.

Refolk's ranking is designed for this: ask for "engineers with pending or merged persistent-kernel PRs on vLLM, plus their current employer and GitHub activity in the last 90 days," and you get a shortlist you can actually work through in an afternoon rather than a 2,000-row export you never touch.

Fluidstack's post is a datacenter buildout in a SWE trenchcoat

Fluidstack's July HN roles look like standard infrastructure listings and are not; they are gigawatt-scale power, substation, and network topology work tied to Anthropic's $50B commitment. The talent overlap is Meta and Microsoft datacenter engineering, not Kubernetes SRE.

Anthropic's stated rationale for choosing Fluidstack over larger clouds was "exceptional agility, enabling rapid delivery of gigawatts of power." Fluidstack also supplies GPU capacity to Meta, Midjourney, and Mistral. The July JDs slot into that reality.

Sourcing lanes for these specific roles:

• Hyperscaler datacenter engineering. Meta's Prineville and Los Lunas alumni, Microsoft's Azure infrastructure org, Google's SRE-Datacenter track.
• Utility-scale power. Ex-Tesla Megapack, ex-Fluence, ex-substation contractors from ERCOT and NYISO territory. Not the typical GitHub graph, and not something LinkedIn's Recruiter tool ranks well.
• HPC network fabric. InfiniBand and NVLink engineers from national labs (ORNL, LLNL, NERSC).

$50B

For these roles specifically, plain-English sourcing beats boolean by an even wider margin: "datacenter engineers who have shipped substation buildouts in Texas or upstate New York, currently at a hyperscaler." That query is unrunnable on LinkedIn Recruiter. It is a single sentence in Refolk.

The 90-minute sourcing map for this HN thread

If you are picking one candidate out of this HN thread by Monday, here is the sequence that actually works.

1. Read the JDs as primitives. Extract the specific kernel or architecture named (monokernel, fused dequant+attention, persistent kernel). Do not translate to generic keywords.
2. Pull the relevant contributor graph. For a fused Triton kernel role, that is Triton PR authors + Liger-Kernel + vLLM SIG-performance. For persistent kernels, vLLM PRs referencing "persistent" in the last 6 months.
3. Cross-reference employer. People at Meta, Apple, NVIDIA, Rivos, Anthropic, character.ai, Together are the current employers of the ten US Triton+CUDA titled profiles in Refolk's index. The unlisted 200 are elsewhere but their commits are public.
4. Outreach with attribution. Reference a specific PR, a specific issue thread, or a specific benchmark. Never a JD.
5. Skip the recruiter middleman on the first message. These candidates reply to engineers. If you are a recruiter, get a hiring engineer to co-sign the first note.

The July HN thread will roll off in a month. The eight roles at the top will not. Sourcing them from the title layer is a way to spend a quarter losing to whoever went to the commit layer on day one.

FAQ

How many people can actually write a production LLM inference kernel?

Somewhere between 200 and 250 people are active contributors to the major open-source inference projects (vLLM, SGLang, llama.cpp, Triton, CUTLASS) in any given quarter. The lifetime pool across those graphs is 2,000+, but many are one-time contributors. The subset who can walk into a role like Kog's monokernel engineer and be productive in 30 days is closer to 30 to 50 globally.

Why does searching "CUDA" on LinkedIn return the wrong people for these roles?

Because "kernel author" is a task, not a title, and most of the people doing it work under "Member of Technical Staff" or "Research Engineer" titles at labs. Refolk's index shows only 30 people worldwide self-title with both Triton and CUDA in a GPU/Kernel/Performance-engineer role. The other ~200 active kernel authors are invisible to keyword search and only surface through commit graphs on vLLM, Triton, and CUTLASS.

What is MBU and why does it matter for screening?

MBU (Model Bandwidth Utilization) measures how close a decode step gets to the GPU's peak memory bandwidth. At batch size 1, LLM decoding is memory-bandwidth-bound (a GEMV, not a GEMM), so MBU is the KPI, not MFU. Candidates who cannot fluently discuss the MBU vs. MFU tradeoff on H200 or MI300X have not worked on real inference optimization, regardless of what their resume claims.

Is the Fluidstack HN post really different from a normal infra role?

Yes. Fluidstack's July HN roles ladder into the $50B Anthropic partnership signed November 12, 2025, which means the work is gigawatt-scale power, substation, and topology engineering across Texas and New York facilities coming online through 2026. The candidate profile overlaps with Meta and Microsoft datacenter engineering, ERCOT-region utility work, and HPC fabric specialists, not with typical cloud SRE.