Cheng Wan
aaf9a95763
Fifth of five; stacked on #38049. The split gave every namespace a file, but only for the half an operator types. This is the other half. ## The parallel quotients are declared, not written out `attn_tp_size` and its five siblings were sixty lines of near-identical properties in the runtime context, a file away from the leaves they are quotients of, so reading `parallel.py` told you what you could set and nothing about what that decides. They are declared in `Parallel` now, in the same class as those leaves. They carry no annotation, so they are not dataclass fields and `collect_input_fields` never puts them on the record -- the same mechanism that already keeps `_NS_PATH` off it. That is the right exclusion: a quotient has no operator input to preserve, and the record is what crosses a process boundary, where a stamped width is one an elastic scale-up will not refresh. ## A quotient is a value in the bag, like every other derived one `_derived_width` answered from a stamp or, failing that, a live process group. The group read could never disagree with the stamp: - `initialize_model_parallel` stamps all six as its last statement, unconditionally; - an elastic scale-up restamps `attn_dp_size` through `update_dp_attention_post_scale` -- the comment claiming it does *not* was wrong; - no hardware backend builds groups of its own; - `multimodal_gen`, which has its own `initialize_model_parallel` and does not stamp, never reads a quotient. So a built group was always already stamped, and the group read goes -- and with it the last reason for a quotient to be resolved on every read. Every input to `derive_parallel_widths` is a record field. `dcp_enabled` is `decode_context_parallel_size > 1`, not a fact about a built group; it was spelled `_DCP is not None`, which is a longer way to say the same thing. So the six are fixed once the configuration is fixed -- the same test every other `Derived(fn=...)` in this PR passes. They are declared the same way and computed the same way: once, at publish, into ordinary bag leaves. What remains is override -> stamp -> published leaf. The stamp stays above the leaf because an elastic scale-up restamps `attn_dp_size`; the override stays on top because that is how a test names a width. ## One answer for the config-derived predicates `enable_mamba_extra_buffer` and its lazy variant, `is_ep_joiner`, `is_ep_scale_joiner`, `is_startup_weight_load_overlap`: each existed as a `ServerArgs` member for the resolution pipeline and, for most of them, again as a `runtime_context` function for readers after publish. Three places to keep saying the same thing. A `Derived(fn=...)` is a pure function of the published configuration, so `publish` computes it once and stores it as an ordinary bag leaf -- a plain attribute load, which is what a read inside compiled model code needs. The function is handed the whole resolved config rather than the bag it lands in, because a derivation is free to span namespaces and the mamba one does: it reads `memory.disable_radix_cache` alongside its own `exec.mamba` strategy, which is why it could never have been a method on either bag. The pre-publish helpers stay -- resolution needs the predicate before there is a bag to read -- and three readers keep them, because they run before their own process publishes: `initialize_dp_attention`, which the weight-cache daemon calls while building its groups thirty lines before its `publish`, and `PortArgs.init_new`, a factory handed the record that already reads eighteen other fields off it. ## Notes for a reviewer **Overriding a leaf does not move its quotient.** `override(tp_size=2)` leaves `attn_tp_size` where the published config put it, because nothing is recomputed on read. A test states a topology by publishing a config -- which is what a real process does -- or by naming the width it wants, `override(attn_tp_size=2)`. Six tests say it that way now. This is the price of having one answer computed once, and it is the same price every other derived value in the config already carries. A caller that reads a quotient without publishing or overriding now gets an explicit error naming the field, instead of a default that an uninitialised group happened to supply. One fixture was in that state -- `TestMlaWriteDoorsUnderDcp` built a bare pool and asked whether DCP was on -- and it publishes a config now, which is what the process it stands in for does. Eighteen sites read these predicates without calling them. That is correct -- they are properties -- but it is worth saying they were checked, because a census that assumes otherwise reports eighteen always-true conditions. ## The skill that documents this subsystem is updated with it `.claude/rules/modify-component-must-read.md` points at `.claude/skills/sglang-runtime-context/SKILL.md` before anyone touches these files, so a stale sentence there is a wrong instruction rather than a stale note. Four of its load-bearing statements stopped being true across this series and are corrected here: `NS(...)` is no longer how a field states its namespace (the declaring class is); the DCP degrade rule is gone, because the quotients are not live reads; `mamba_extra_buffer_enabled()` and the other predicate functions it named as the shape to copy no longer exist; and the namespace-coverage ratchet is described in terms of the marker. The docstring of `test_server_args_namespaces.py` said the same thing and is fixed too. The consequence a test author actually trips over is stated there as well: overriding a leaf no longer moves its quotient, so a topology is stated by publishing a config or by naming the width. ## Verification A full registered-unit sweep (648 files) against this stack's merge-base: 19 failures on both sides, the same 19 -- AMD `gfx950`, `modelopt`, `cuda_vmm`, `weight_checker` and friends, none of them config. The narrower 139-file config sweep used earlier in this series does not contain the files this change reaches -- `test_kv_index_translator` never names `get_parallel()`, it constructs an object that does -- which is why the baseline differential over everything is what is quoted here.
🌐 Website | Blog | Documentation | Roadmap | Join Slack | Weekly Dev Meeting | Slides
News
- [2026/07] 🔥 SGLang and Miles add day-0 support for Kimi K3 (blog).
- [2026/07] RadixArk and Google bring full SGLang features to TPUs (blog).
- [2026/07] Serving GLM5.2 NVFP4 agentic workloads with SGLang: Reaching 500 TPS in two weeks (blog).
- [2026/06] 🔥 The next generation of speculative decoding: DFlash and Spec V2 (blog).
- [2026/06] SGLang provides day-0 support for latest open models (Nemotron 3 Ultra, Nemotron 3 Super, Higgs Audio v3 TTS).
- [2026/04] 🔥 DeepSeek-V4 on Day 0: From Fast Inference to Verified RL with SGLang and Miles (blog).
- [2026/02] 🔥 Unlocking 25x Inference Performance with SGLang on NVIDIA GB300 NVL72 (blog).
- [2026/01] SGLang Diffusion accelerates video and image generation (blog).
More
- [2025/12] SGLang provides day-0 support for latest open models (MiMo-V2-Flash, Nemotron 3 Nano, Mistral Large 3, LLaDA 2.0 Diffusion LLM, MiniMax M2).
- [2025/11] SGLang Diffusion accelerates video and image generation (blog).
- [2025/10] SGLang now runs natively on TPU with the SGLang-Jax backend (blog).
- [2025/10] PyTorch Conference 2025 SGLang Talk (slide).
- [2025/10] SGLang x Nvidia SF Meetup on 10/2 (recap).
- [2025/09] Deploying DeepSeek on GB200 NVL72 with PD and Large Scale EP (Part II): 3.8x Prefill, 4.8x Decode Throughput (blog).
- [2025/09] SGLang Day 0 Support for DeepSeek-V3.2 with Sparse Attention (blog).
- [2025/08] SGLang x AMD SF Meetup on 8/22: Hands-on GPU workshop, tech talks by AMD/xAI/SGLang, and networking (Roadmap, Large-scale EP, Highlights, AITER/MoRI, Wave).
- [2025/08] SGLang provides day-0 support for OpenAI gpt-oss model (instructions)
- [2025/06] SGLang, the high-performance serving infrastructure powering trillions of tokens daily, has been awarded the third batch of the Open Source AI Grant by a16z (a16z blog).
- [2025/06] Deploying DeepSeek on GB200 NVL72 with PD and Large Scale EP (Part I): 2.7x Higher Decoding Throughput (blog).
- [2025/05] Deploying DeepSeek with PD Disaggregation and Large-scale Expert Parallelism on 96 H100 GPUs (blog).
- [2025/03] Supercharge DeepSeek-R1 Inference on AMD Instinct MI300X (AMD blog)
- [2025/03] SGLang Joins PyTorch Ecosystem: Efficient LLM Serving Engine (PyTorch blog)
- [2025/02] Unlock DeepSeek-R1 Inference Performance on AMD Instinct™ MI300X GPU (AMD blog)
- [2025/01] SGLang provides day one support for DeepSeek V3/R1 models on NVIDIA and AMD GPUs with DeepSeek-specific optimizations. (instructions, AMD blog, 10+ other companies)
- [2024/12] v0.4 Release: Zero-Overhead Batch Scheduler, Cache-Aware Load Balancer, Faster Structured Outputs (blog).
- [2024/10] The First SGLang Online Meetup (slides).
- [2024/09] v0.3 Release: 7x Faster DeepSeek MLA, 1.5x Faster torch.compile, Multi-Image/Video LLaVA-OneVision (blog).
- [2024/07] v0.2 Release: Faster Llama3 Serving with SGLang Runtime (vs. TensorRT-LLM, vLLM) (blog).
- [2024/02] SGLang enables 3x faster JSON decoding with compressed finite state machine (blog).
- [2024/01] SGLang provides up to 5x faster inference with RadixAttention (blog).
- [2024/01] SGLang powers the serving of the official LLaVA v1.6 release demo (usage).
About
SGLang is a high-performance serving framework for large language models and multimodal models. It is designed to deliver low-latency and high-throughput inference across a wide range of setups, from a single GPU to large distributed clusters. Its core features include:
- Fast Runtime: Provides efficient serving with RadixAttention for prefix caching, a zero-overhead CPU scheduler, prefill-decode disaggregation, speculative decoding, continuous batching, paged attention, tensor/pipeline/expert/data parallelism, structured outputs, chunked prefill, quantization (FP4/FP8/INT4/AWQ/GPTQ), and multi-LoRA batching.
- Broad Model Support: Supports a wide range of language models (Llama, Qwen, DeepSeek, Kimi, GLM, GPT, Gemma, Mistral, etc.), embedding models (e5-mistral, gte, mcdse), reward models (Skywork), and diffusion models (WAN, Qwen-Image), with easy extensibility for adding new models. Compatible with most Hugging Face models and OpenAI APIs.
- Extensive Hardware Support: Runs on NVIDIA GPUs (GB200/B300/H100/A100/Spark/5090), AMD GPUs (MI355/MI300), Intel Xeon CPUs, Google TPUs, Ascend NPUs, and more.
- Active Community: SGLang is open-source and supported by a vibrant community with widespread industry adoption, powering over 400,000 GPUs worldwide.
- RL & Post-Training Backbone: SGLang is a proven rollout backend used for training many frontier models, with native RL integrations and adoption by well-known post-training frameworks such as AReaL, Miles, slime, Tunix, verl and more.
Getting Started
Benchmark and Performance
Learn more in the release blogs: v0.2 blog, v0.3 blog, v0.4 blog, Large-scale expert parallelism, GB200 rack-scale parallelism, GB300 long context.
Adoption and Sponsorship
SGLang has been deployed at large scale, generating trillions of tokens in production each day. It is trusted and adopted by a wide range of leading enterprises and institutions, including xAI, NVIDIA, AMD, Intel, LinkedIn, Cursor, Oracle Cloud, Google Cloud, Microsoft Azure, AWS, Atlas Cloud, Voltage Park, Nebius, DataCrunch, Novita, RunPod, InnoMatrix, Modal, MIT, UCLA, the University of Washington, Stanford, UC Berkeley, Tsinghua University, Baseten, Baidu, AntGroup, Alibaba, Tencent, and other major technology organizations. As an open-source LLM inference engine, SGLang has become the de facto industry standard, with deployments running on over 400,000 GPUs worldwide. SGLang is currently hosted under the non-profit open-source organization LMSYS.
Contact Us
For enterprises interested in adopting or deploying SGLang at scale, including technical consulting, sponsorship opportunities, or partnership inquiries, please contact us at sglang@lmsys.org.
Long-term active SGLang contributors are eligible for coding agent sponsorship, such as Cursor, Claude Code, or OpenAI Codex. Email sglang@lmsys.org with your most important commits or pull requests.
Acknowledgment
We learned the design and reused code from the following projects: Guidance, vLLM, LightLLM, FlashInfer, Outlines, and LMQL.