Kimi K3 Landed With Open Weights. The US Pool That Can Serve It Is 11.
Moonshot's 2.8T Kimi K3 is downloadable, but only 11 US engineers can actually serve it. Why LinkedIn title search finds zero of them, and where they really live.
Moonshot released Kimi K3 on July 16, 2026 and pushed the full open weights out on July 26 at roughly 7:30 PM EDT, a day ahead of schedule. Every US AI team now has the same question on the whiteboard: who on our roster can actually stand this thing up in our own VPC? For most, the honest answer is nobody, and the follow-up question, "where do we hire that person," has a much smaller answer than anyone expects.
Why "open weights" and "servable in production" are not the same job
Downloadable weights do not equal a running service. Kimi K3 is a 2.8T-parameter sparse Mixture of Experts (MoE) with a 1M-token context window, hybrid KDA plus full-attention layers, and native multimodal input, and Moonshot's own deployment guide recommends supernodes of at least 64 accelerators.
The model can barely fit on a single NVIDIA DGX B300 and needs a minimum of 16 B200/GB200 GPUs to serve on that generation of hardware. Even after MXFP4 four-bit quantization, the weights still occupy roughly 1.4 TB of fast memory (versus about 5.6 TB at 16-bit). Only 16 of 896 experts fire per token, leaving about 50B active parameters, but that sparsity is exactly what makes routing, expert parallelism, and prefix caching so unforgiving.
Two mechanisms make this a different job from serving Llama-class dense models:
- KDA (Kimi Delta Attention) is a linear-attention variant that keeps a fixed-size recurrent state instead of a growing KV cache. Most of K3's layers are KDA, interleaved with periodic full-attention layers.
- PD-disaggregated serving splits the prefill and decode stages onto separate GPU pools so each can be scaled independently. It is table stakes for 1T+ MoE latency, and almost nobody outside a handful of labs has shipped it.
If a candidate cannot explain why KDA breaks conventional paged-KV prefix caching, they have not served this class of model.
The US pool that can actually serve K3 is 11 people
In Refolk's index of professional profiles, only 11 US engineers hold a title in {Inference Engineer, ML Systems Engineer, Performance Engineer} and list both CUDA and Triton as skills. That is the realistic "can write the kernels" pool for hiring Kimi K3 engineers, and it is where every serious deployment starts.
The top employers in that slice are Qualcomm (2), Meta, Apple, NVIDIA, and Atlassian. Not one of them advertises this work under an "MoE inference" banner. That is not an oversight, it is the market. Nobody self-describes as an "MoE inference engineer" because the title does not exist on any org chart.
Broaden the filter and the picture gets slightly better, then worse again:
| Slice (US) | Count | Note |
|---|---|---|
| "vLLM" as a listed skill, all seniorities | 553 | Broadest pool; most are users, not contributors |
| Title in {Inference, ML Systems, Performance Eng.} + CUDA + Triton | 11 | Can-ship-kernels pool |
| Headline keyword "MoE mixture of experts inference" | 0 | Nobody writes this on their profile |
| Headline keyword "SGLang vLLM inference kernels", Senior+ | 0 | LinkedIn title filter returns nothing |
| Kernel-capable / vLLM-skill | ~2.0% | The drop from "familiar" to "can ship" |
| Kernel-capable US / global vLLM contributors (1,969) | ~0.6% | US kernel talent as share of global base |
The takeaway is blunt. There are 553 US profiles that have used vLLM, and about 2% of them have the systems chops to move K3 from "downloaded" to "serving 50 QPS at P99." Everyone else is a customer of the stack, not a builder of it.
LinkedIn title search returns zero. Here is why.
A recruiter typing "MoE inference engineer" into LinkedIn today gets an empty result set, and that is not a bug in LinkedIn, it is a mismatch between how the work is done and how the work is titled. The people who ship this carry titles like "Performance Engineer" (7 of the 11 in the kernel-capable slice), "Member of Technical Staff," or "Software Engineer, Infrastructure."
Three structural reasons the title filter fails:
- The work is too new to have a canonical title. PD disaggregation, MXFP4 expert-parallel kernels, and KDA-aware prefix caching all shipped inside the last 18 months. HR taxonomies lag by two to three years.
- The talent sits in "systems" orgs, not "ML" orgs. They report to infra directors, so their titles inherit infra conventions.
- The skill signals are in commits, not in profile text. A vLLM PR touching
moe_kernels.cuis worth more than any self-description, and no ATS ingests commit history by default.
This is the exact gap Refolk closes. You describe the person in plain English ("engineers who have contributed MoE or expert-parallel kernels to vLLM or SGLang, based in the US, senior or above") and get a ranked shortlist that spans GitHub, LinkedIn, and the open web instead of one field on one platform.
The real hiring list is a commit graph, not a job board
Read the vLLM K3 branch. Moonshot AI's own team contributed the KDA prefix caching implementation to vLLM to ship alongside the weights, and vLLM, NVIDIA, AMD, and the broader community closed final integration so day-0 open-source serving worked. The names on those commits are the hiring list.
A few named starting points from the research:
- Woosuk Kwon, vLLM originator, Berkeley, Ion Stoica's lab.
- Lianmin Zheng, SGLang originator, same lab, same lineage. The entire US genealogy of production LLM serving traces to one Berkeley group.
- Red Hat, the largest non-academic backbone of vLLM contributions.
- SGLang's core contributors at xAI, Skywork, Oracle, and LinkedIn.
- Together AI and Modal, which shipped day-0 hosted access to K3 while the hyperscalers were still writing blog posts.
- Inferact, which open-sourced DSpark, a block-diffusion speculative decoding path for K3 trained with vLLM and TorchSpec. Small firm, demonstrably K3-competent.
- Anthropic and Crusoe, which surface as top US employers in the vLLM-skill slice of Refolk's index.
The commit graph on the vLLM K3 branch is the actual hiring list. LinkedIn is not. </pull> If your sourcing pipeline does not start from those artifacts, you are drawing from the 553-profile pool and hoping. The 11-profile pool never appears on a job board because those people get inbound from Moonshot, DeepSeek, and Together AI directly. ## Screen for the KDA prefix-cache redesign, not the buzzwords The single fastest way to separate real K3 operators from people who have read the release notes is to ask about KDA prefix caching. KDA keeps a fixed-size recurrent state per layer, which breaks the assumption baked into paged-KV that every prefix token owns a KV block you can hash and share. vLLM solved this by separating the physical KDA state-block size from the prefix-match granularity, so partial prefix-cache hits are possible without storing a recurrent snapshot at every small attention block. A candidate who can whiteboard that redesign has actually touched the code. A candidate who says "we use vLLM" and cannot go deeper is a user. Adjacent screens that work: - **MXFP4 expert-parallel kernels.** Ask how they handle the 1.4 TB weight footprint across a 16-GPU partition and where the all-to-all bandwidth walls hit. - **PD disaggregation.** Ask about prefill/decode ratio tuning under bursty 1M-context traffic. If they mention KV transfer over NVLink versus RDMA, keep going. - **Router imbalance.** Only 16 of 896 experts fire per token. Ask how they diagnose and fix hot-expert stalls in production.
refolk prompt: US engineers who have merged commits to vLLM or SGLang touching MoE, expert parallelism, or PD disaggregation, senior or above, open to talking. note: Refolk returns a ranked shortlist pulled from GitHub commits, LinkedIn context, and open-web signals, not a title filter that misses the whole pool. slug: gbgbtze6nd
## The $20M license clause just expanded the demand side
Kimi K3 ships under a custom "kimi-k3" license that gates commercial inference use above $20 million a year in revenue. That single clause is the reason the talent squeeze is about to get worse.
The mechanism: any mid-market SaaS with real ARR that wanted to swap in K3 as a cheaper Claude replacement cannot just sign an API contract. They either negotiate a commercial license with Moonshot or serve the model themselves. Both paths need someone in-house who understands the deployment cost model, the router behavior, and the true throughput at their traffic profile. That is a large model deployment talent hire, and six months ago that company had zero of those roles budgeted.
The result is a demand curve that no longer matches supply:
- **Supply**: 11 US engineers with the exact skill stack, roughly 553 in the broader vLLM-familiar pool.
- **Demand**: every enterprise AI buyer above the $20M revenue line that wants K3 economics.
```stat
number: 0.6%
label: US kernel-capable engineers as a share of global vLLM contributors
note: 11 US profiles against 1,969 vLLM contributors globally. The bottleneck is nationality plus skill, not either alone.
</stat>
Where to source, in order
Start from artifacts, then move to profiles, then to titles, in that order. Reversing the sequence is how you end up with the 553-pool instead of the 11-pool.
- Commit graphs first. vLLM's
moe_kernels,attention/kda,disaggregateddirectories. SGLang's FlashMLA, DeepGEMM Mega MoE, EP MoE on DeepEP, and PD disaggregation paths. Same pool, different repo. - Day-0 operator teams. Together AI and Modal shipped K3 hosting first. Their infra ICs are the visible operator layer.
- Berkeley lineage. Ion Stoica's group and its recent alumni. Both founders came from there, and so did a disproportionate share of the contributor bench.
- Adjacent MoE work. DeepSeek-V4 shipped the same class of features on SGLang. Anyone who touched that stack transfers directly.
- Only then, LinkedIn titles. Performance Engineer plus CUDA plus Triton, at Qualcomm, Meta, Apple, NVIDIA, Atlassian, Anthropic, Crusoe, Together AI.
Sourcing vLLM contributors is a plain-English query problem, not a boolean-string problem, which is why Refolk lets you ask for "engineers who wrote MoE expert-parallel kernels for vLLM in the last 12 months" and returns the actual humans rather than a keyword match. For open weights fine-tuning hiring, the same approach surfaces the smaller adjacent pool: engineers who have shipped LoRA or full fine-tunes at 1T+ scale, which correlates strongly but not perfectly with the serving pool.
The window is short
Moonshot, DeepSeek, and a handful of vLLM and SGLang core contributors already know who each other are. The moment a US enterprise hires its first K3 operator, the bidding on the remaining 10 accelerates. Fireworks, Together, Modal, Anthropic, and Crusoe are all in the same slice of Refolk's index, and none of them are done hiring.
If you are the second company to figure out that the pool is 11 people, you are still fine. If you are the fifth, you are hiring from the 553-pool and paying MoE inference engineer salaries for people who have only read the vLLM docs.
FAQ
How many US engineers can actually serve Kimi K3 in production?
Roughly 11, based on Refolk's index filter of {Inference Engineer, ML Systems Engineer, or Performance Engineer} plus CUDA plus Triton skills in the US. The broader "has touched vLLM" pool is 553, but most of those are users of the stack, not people who have written or debugged MoE kernels, PD-disaggregated serving, or KDA-aware prefix caching. The 11-person figure is the realistic pool for a first hire who can stand K3 up on a 16-GPU B200 partition without external help.
Why does LinkedIn title search return zero MoE inference engineers?
Because the title does not exist yet. The work is 18 months old, sits inside infra orgs that use titles like Performance Engineer or Member of Technical Staff, and the strongest skill signals live in commit history rather than profile text. Recruiters who filter on "MoE" or "mixture of experts inference" get an empty funnel by construction. Sourcing has to start from artifacts (vLLM and SGLang commits, day-0 operator teams) and only later filter by title.
What is the fastest technical screen for a real K3 candidate?
Ask them to explain how KDA breaks conventional paged-KV prefix caching and how vLLM solved it by decoupling the physical KDA state-block size from prefix-match granularity. A candidate who has actually shipped this work can whiteboard the redesign in five minutes. A candidate who has only read the release notes will pivot to buzzwords about linear attention. Follow up with MXFP4 expert-parallel memory layout and router hot-expert diagnosis.
Does the $20M revenue clause in the K3 license really change hiring?
Yes, materially. The license gates commercial inference above $20 million ARR, so mid-market SaaS companies that wanted a cheap Claude alternative now have to either license commercially from Moonshot or self-serve. Both paths require in-house deployment talent that these companies never had to hire before, which shifts demand for MoE inference engineers from a handful of frontier labs into the broader enterprise market, against a supply pool that has not grown.