How LinkedIn leveraged vLLM to power GenAI applications at scale
LinkedIn needed to deploy LLMs at scale across diverse real-time and batch GenAI use cases while meeting strict latency requirements, managing GPU efficiency, and giving internal engineering teams control over performance tuning without modifying engine code.
LinkedIn's initial serving stack tightly coupled the server and engine, limiting flexibility. The first offline deployment had limited concurrency suitable only for low-QPS workloads. Traditional NER models for job search were brittle, costly to maintain, and slow to adapt to evolving language and job taxonomies.
vLLM now supports more than 50 GenAI use cases at LinkedIn and runs on thousands of hosts.
The v1 engine upgrade saved over 60 GPUs for one workload. Open-source contributions yielded a 7% improvement in Time Per Output Token and an 8% improvement in decoding speed for smaller models.
Show all 10 reported metrics
Frequently asked questions
What did this team achieve with this AI workflow?
vLLM now supports more than 50 GenAI use cases at LinkedIn and runs on thousands of hosts.
What tools did this team use?
vLLM, AsyncLLMEngine, PagedAttention, CUDA graphs, gRPC, OpenAI-compatible API, Red Hat, UC Berkeley Sky Computing, NVIDIA, LMCache.
What results were reported?
GenAI use cases supported: more than 50; hosts running vLLM: thousands of hosts; TPS improvement from scheduler tuning: ~10%; Throughput under saturation (v1 engine): ~1245 tokens/sec (source-reported, not independently verified).
What failed first in this deployment?
LinkedIn's initial serving stack tightly coupled the server and engine, limiting flexibility.
How is this recruiting AI workflow structured?
Hirer specifies qualifications → vLLM prefix-cached batched inference → LLM classifies and explains per candidate → Qualified candidates filtered for hirer → User submits job search query → LLM interprets intent and extracts facets → Personalized job recommendations returned.