Two open-source LLM inference engines shipped major versions on the same day this month. vLLM's site dated its v0.33.0 announcement November 2: “New models — 927 commits from 389 contributors · PyTorch 2.14 · CUDA 12.9 dropped.”[1] SGLang's release feed timestamps v0.5.23 at 2026-11-02T22:14:10Z, built from “1007 PRs from 257 contributors.”[3] The question of what separates the two engines is on Zhihu's hot list this week, and the same-week releases give that discussion a dated anchor.
Read together, the two releases mark out a division of labor. vLLM spent this cycle on platform breadth: a ten-platform hardware matrix, a stable binary interface that decouples PyTorch upgrades, and a project listing under the PyTorch Foundation.[1][4][5] SGLang spent its cycle on workload depth: fused low-latency decode kernels, file-backed prefix caching, and serving features aimed at agentic and RL use.[2][3] For an enterprise choosing between them, the decision these releases expose follows a fixed order: hardware support first, workload fit second, performance numbers last. Every performance figure either side publishes is a vendor self-report with its own hardware and model conditions attached, and none of the documents behind this piece compares the two engines on the same task.
vLLM v0.33.0 spends its release on platform breadth
vLLM's site positions it as “The High-Throughput and Memory-Efficient inference and serving engine for LLMs,” with throughput credited to PagedAttention, advanced scheduling, and continuous batching, and “a drop-in OpenAI-compatible API for instant integration.”[1]
The release contents push in a platform direction. v0.33.0 features 927 commits from 389 contributors, 122 of them new.[4] It upgrades to PyTorch 2.14.0 with torchvision 0.29.0 and Triton 3.8.0, and it drops CUDA 12.9: “release wheels and images are CUDA 13.0 only,” with the -cu129 wheels and images no longer published.[4] Teams pinned to CUDA 12.9 now have an upgrade decision to make before they can take this release.
The November 6 follow-up blog addresses that maintenance burden directly. “As of v0.33.0, vLLM publishes LibTorch ABI Stable CUDA wheels,” so a PyTorch update can be handled by swapping the torch wheel instead of rebuilding vLLM.[5] The post states its own limit: the stable ABI covers binary compatibility, while Python API changes, CUDA minimum versions, and third-party dependencies still constrain upgrades.[5]
The hardware matrix on vLLM's site lists ten platform families: NVIDIA CUDA, AMD ROCm, Huawei Ascend, AWS Neuron, Google Cloud TPU, IBM Spyre, Intel Gaudi/XPU/CPU, Apple Silicon, Baidu Kunlun XPU, and Cambricon MLU.[1] The site also carries the project's governance markers: a link to its PyTorch Foundation project page, four cash donors (a16z, Sequoia Capital, Skywork AI, ZhenFund), and sixteen compute sponsors including Alibaba Cloud, AMD, AWS, Google Cloud, IBM, Intel, NVIDIA, Red Hat, and UC Berkeley.[1] The site's ecosystem section lists tooling such as AIBrix for Kubernetes infrastructure, GuideLLM for performance evaluation, and LLM Compressor for quantization.[1]
SGLang v0.5.23 spends its release on workload depth
SGLang's README positions it differently: “SGLang is an open-source inference framework for large language, vision-language, and diffusion models, optimized for agentic workloads, large-scale serving, and RL rollouts.”[2] SGLang Diffusion, its built-in image and video generation engine, ships in the same repository and Python package.[2] Its community runs its own event: SGLang Summit 2026 is scheduled for November 12–13 in San Francisco.[2]
The v0.5.23 release notes are a catalog of workload-specific work, stated in the project's own voice. DeepSeek-V4.1 on GB300 “gets up to 1.5x more prefill throughput under load and about 28% lower first-token latency on 32K to 64K prompts.”[3] SGLang's opt-in low-latency mode runs DeepSeek-V4.1-Flash decode as fused persistent kernels on NVIDIA megakernel and AMD monokernel plugins, “for up to 44% faster single-user decode on GB300 and 75% on MI350X.”[3] On H200, “MoE models such as DeepSeek-V4.1-Flash, GLM-5.3-Flash and gpt-oss reach the first token 30% to 58% sooner on 8K prompts.”[3] A new opt-in Paged Experts mode “runs MoE models larger than GPU memory on a single consumer GPU, up to 30x faster than CPU offload,” with CPU offload as the comparison base.[3] The release also adds Google TPU7x support through SGLang-TorchTPU, LoRA adapters on FP8 and NVFP4 quantized MoE models, and file-based L3 prefix caching in HiCache for DeepSeek-style MLA models running decode context parallelism.[3]
The README's hardware table covers NVIDIA GPUs from B200 through GB300 down to consumer RTX cards, AMD Instinct MI300X through MI355X, TPU v6e/v7, Intel Arc and Xeon, Apple Silicon, Huawei Ascend A2/A3/950PR/DT, and Moore Threads S5000.[2] A separate list is labeled “Integrations in progress” and names AWS Trainium, Cambricon MLU, and Qualcomm QAIC among others.[2] The project's community infrastructure runs through LMSYS: the official Docker image lives under the lmsysorg namespace, the README directs contact to sglang@lmsys.org, and long-term contributors qualify for coding-agent sponsorship on Cursor, Claude Code, or OpenAI Codex.[2]
The scheduler story SGLang is known for comes from an older post. The December 4, 2024 v0.4 blog credited a zero-overhead batch scheduler with a 1.1x throughput increase and a cache-aware load balancer with up to 1.9x, and described overlapping CPU scheduling with GPU computation to “hide expensive overheads such as the radix cache operations.”[8] That is a two-year-old baseline, useful for understanding the mechanism, separate from the v0.5.23 figures above.
The rivalry sits on top of shared code and overlapping new-model lists
The two projects are not strangers. SGLang's README acknowledges the lineage in one line: “We learned the design and reused code from the following projects: Guidance, vLLM, LightLLM, FlashInfer, Outlines, and LMQL.”[2]
This release week shows how tightly they track each other. Both release lists add Muse Spark Open: vLLM's notes list “Muse Spark Open (#61879)” among the new models it names, and SGLang's new-model table carries Muse Spark Open as an LLM/VLM entry.[3][4] Both lists also carry a Beam-1.0 entry, written “Reflection Beam-1.0” in vLLM's notes and “Beam-1.0” in SGLang's table; the captured text does not establish whether the two names refer to the same model.[3][4] Both projects also publish RL-facing claims. SGLang's positioning text names RL rollouts as an optimization target.[2] vLLM's other November 6 post describes asynchronous RL training: REINFORCE Zero, from NVIDIA Research and Inferact, “trains stably for 20,000 updates, learns at policy lag 64, and reaches 2.40× the training-step throughput of synchronous training with aligned kernels,” with zero-mismatch coverage of DeepSeek-V4.1-Flash and Kimi K3.1 on day 0, and both DeepSeek-V4-Flash and Kimi K3.1 on AMD MI355X.[6] Those figures come from the teams' own post reporting their paper's results.[6]
Hardware and workload decide the choice before any benchmark can
For a deployment decision, the two hardware lists are the fastest filter, and they answer differently in specific places. IBM Spyre and Baidu Kunlun XPU appear in vLLM's matrix and not in SGLang's supported table; AWS Trainium, Qualcomm QAIC, MetaX, and Hygon sit in SGLang's “integrations in progress” list, which is a declaration of work under way.[1][2] Cambricon MLU is a direct contrast in labeling: vLLM's matrix lists it as a supported row, while SGLang's README files it under integrations in progress.[1][2] Moore Threads appears in SGLang's supported table and not in vLLM's captured matrix.[1][2] Both lists are vendor declarations; the “in progress” label is the more explicit about maturity, and “supported” in either matrix is a claim on paper, not a certified deployment.
Workload fit is the second filter, and each project's own words draw the line. Generic high-throughput serving is what vLLM's own site claims as its core use: PagedAttention, continuous batching, and a drop-in OpenAI-compatible API.[1] Agentic workloads, large-scale serving, and RL rollouts are the targets SGLang names; if the workload includes serving image and video generation, SGLang's README describes a built-in diffusion engine and vLLM's homepage does not.[2]
The performance numbers come last in that order, and each carries its own conditions. SGLang's figures run on GB300, MI350X, and H200, against the DeepSeek-V4.1 family and other MoE models.[3] vLLM's day-0 Kimi K3.1 Pro figures run on 8× GB300, with “up to 1.69× faster time to first token than head-sharded prefill at 340K tokens,” and day-0 support spanning NVIDIA GPUs, AMD GPUs, Google TPUs, and Alibaba T-Head Zhenwu PPUs.[7]
What the public record settles, and what it leaves open
By November 9, the documents both projects published settle the difference in emphasis: vLLM's release went to platform breadth, SGLang's to workload depth. What they do not settle is the head-to-head: no reliable public comparison of the two engines on the same hardware, the same model, and the same metric has surfaced. That comparison is what the hot-list debate keeps asking for.
The next checkpoints are on the calendar: SGLang Summit 2026 on November 12–13,[2] followed by the next round of release notes from both projects. Until such a comparison surfaces, the defensible selection method is the one the two matrices support: exclude by hardware first, match the workload second, and read each vendor's throughput figures as the vendor's own account of its engine.