Back in July we counted which AI models companies name in their own job posts, and one line in that post has been bothering us ever since. Open-weight models (Llama, Mistral, Qwen, DeepSeek) showed up at eight companies. Eight, out of 867 that were hiring. We noted at the time that this probably undercounted things, because teams running their own models tend to write the serving stack into the post rather than the weights, and we left it there.
That was a lazy place to stop, so we went back and counted the serving stack properly.
vLLM is in the stack of 43 hiring companies. SGLang, its closest rival, is at 21. Set those against eight and the "open models are dead in hiring" read gets a lot shakier.
Which raises a fair question if you have not been living in inference land for the past two years: what is vLLM, and why would a company advertise for it?
The short version of what it does
vLLM is an open source engine for serving large language models. You point it at a set of weights and it gives you an API that other software can call, handling the ugly parts: batching requests from many users at once, streaming tokens back, keeping the GPU busy.
The specific trick it launched with was called PagedAttention. When a model generates text it keeps a running scratchpad in GPU memory (the KV cache) for every conversation in flight. The naive approach reserves a fixed block per request, sized for the longest reply that request might produce. Most replies are much shorter, so most of that reserved memory just sits there. The waste was enormous, something like 60 to 80 percent on typical workloads.
PagedAttention borrowed the fix from operating systems: stop reserving contiguous blocks, hand out small pages on demand, keep a lookup table. Anyone who has read about virtual memory will recognise it immediately, which is part of why it landed so well. The idea was not exotic. It was just the first time somebody applied a forty-year-old systems idea to the thing everyone was suddenly trying to run.
The result was several times the throughput on the same hardware. That is the whole pitch, and for anyone paying an hourly GPU bill it did not need further explanation.
When it started popping up
June 2023, out of UC Berkeley's Sky Computing Lab, in a paper by Woosuk Kwon and colleagues. Although "launched in June" undersells it a bit: it had already been quietly serving the Vicuna demo and Chatbot Arena for two months before the announcement, which is a much better proof than a benchmark table.
Adoption was fast even by 2023 standards. Tens of thousands of GitHub stars inside six months.
By 2024 the interesting thing was that PagedAttention had stopped being a differentiator. Hugging Face's TGI had it, NVIDIA's TensorRT-LLM had it, and SGLang shipped in January 2024 with RadixAttention extending the same line of thinking. When your headline feature becomes table stakes across every competitor in eighteen months, you either fade or you become the default. vLLM became the default.
The moment that actually matters for a hiring post, though, is 2025, when vLLM joined the PyTorch Foundation as a hosted project. That sounds like governance trivia. It is not. It moved vLLM from "fast open source thing a startup would bet on" to something that clears an enterprise procurement review, with named compute backing from Alibaba Cloud, AMD, AWS, Google Cloud, IBM, Intel, NVIDIA, Red Hat and others.
Foundation membership is boring. Boring is exactly what a bank's architecture review is looking for.
Companies do not write down the weights
Here is the part we find genuinely interesting, and it is the reason July's number was wrong in spirit even though it was right in arithmetic.
Almost nobody puts "Llama" in a job post. What would that even be asking for? The weights are a download. There is no skill attached to having obtained a file.
The serving stack is different. Running vLLM well at production scale is a real job with real failure modes: memory pressure, batching strategy, tensor parallelism across GPUs, quantisation tradeoffs, keeping tail latency sane when traffic spikes. That is a person you hire. So it goes in the post.
Which means if you want to know how many companies are running open models in anger, counting model names is close to useless, and counting serving engines gets you much closer. Not perfect. Closer.
For scale, here is where vLLM sits against neighbours in our tag data, across the 1,121 companies on the platform:
| Technology | Hiring companies naming it |
|---|---|
| Kubernetes | 445 |
| Docker | 348 |
| LLM (generic) | 256 |
| PyTorch | 164 |
| LangChain | 96 |
| Ray | 48 |
| vLLM | 43 |
| CUDA | 42 |
| SGLang | 21 |
vLLM is a specialist tool, and the table says so honestly. It is not Kubernetes. But it sits right alongside CUDA, which is a useful anchor: roughly as many companies want someone who can serve open models as want someone who can write GPU kernels.
The SGLang list is the tell
The 21 companies naming SGLang are almost entirely a subset of the 43 naming vLLM. Very few name SGLang alone.
That pattern says something specific. Nobody adopts a second inference engine casually. You run two when you have workloads different enough that one engine's scheduling does not suit both, which means you are far enough in to have measured the difference. The SGLang list is, roughly, the set of companies where serving open models is not an experiment.
It reads like you would expect: Together AI, Modal, Perplexity, Nebius, Prime Intellect, RadixArk, Reducto, Databricks, Cohere, Roblox, Cloudflare, Snowflake.
Two of those we can corroborate without leaning on our own data at all: Nebius and Roblox are both listed as compute backers of vLLM at the PyTorch Foundation. They are not just naming it in a job post, they are paying for its CI.
Where this data is soft, including a bug we found
Usual honesty section, and this time we have a real one to own up to.
While pulling these numbers we found a defect in our own pipeline. A company's tech stack is built as the union of every technology across all of its open job posts, with no frequency floor. One "familiarity with vLLM a plus" line in a single posting makes vLLM a permanent company-level tag, weighted the same as a company that names it in every role.
You can see it if you look: our data has vLLM tagged on Keywords Studios (video game QA and localization) and on Wealthsimple (Canadian retail banking). Neither of those is running an inference cluster. Our stored stack for OpenAI lists 410 technologies, which is not a stack, it is an archive.
So treat 43 as an upper bound. Reading the list by hand, we would put the companies where serving open models is plausibly core at somewhere around twenty. The SGLang cut at 21 lands in the same neighbourhood from a different direction, which is mildly reassuring but not proof. We have filed the bug and we will rerun this count once there is a frequency threshold in place. If the number moves a lot, we will say so.
One more thing we will not claim: July's count had vLLM at 26 and today it reads 43. That looks like fast growth and it might be, but tag accumulation alone could produce the same shape, so we are not going to pretend we can tell those apart yet.
And the standard caveat that applies to every one of these posts: named in a job post is not a production audit. It measures what somebody chose to write down. That is a real signal, because a human typed it deliberately, but it is a floor rather than a census.
If you are job hunting
The practical read is short. "Has called an LLM API" is now an unremarkable line on a CV, sitting at 256 companies. "Has served open weights in production and can tell you what broke" is at 43, and the second sentence is worth considerably more in an interview than the first.
If that is the direction you want, the specific things these posts ask for are memory and batching behaviour, multi-GPU parallelism, quantisation tradeoffs, and latency under load. Nobody is screening for whether you have downloaded Llama.
The cut we would actually want here is not one a search box will give you. Something like "companies that name vLLM, also run Go, and have mid-level roles open" needs the tag-level data underneath, not a keyword match on a description.
Connect whatever agent you already use to Remoet over MCP and you can just ask for it. Star the handful that genuinely fit your stack, and their new roles come to you rather than you checking back every week.
Anyway. If you run vLLM in production we would honestly love to know what made you pick it over the alternatives, and whether the PyTorch Foundation move changed anything on your side or was invisible to you. Come tell us on Discord. And if you think we have miscounted, say so and we will rerun it. Thanks for reading!