Pin the tag. SGLang v0.5.14 landed 26 June 2026 with DeepSeek-V4 NVFP4 paths and Waterfill/LPLB MoE dispatch. The LICENSE file is Apache-2.0. Star count is UNKNOWN. Whether it beats vLLM on your SKU is a bench, not a README.
What it does
The repository README describes SGLang as a high-performance serving framework for LLMs and multimodal models, with an OpenAI-compatible HTTP API and a separate frontend language for structured generation workflows. Documented runtime features include RadixAttention prefix caching, continuous batching, paged attention, prefill-decode disaggregation, speculative decoding, tensor and expert parallelism, structured outputs, and quantization paths (FP8/NVFP4 and others depending on hardware).
The project publishes cookbooks per model family: DeepSeek-V4, Nemotron 3 Ultra, Kimi-Linear, GLM-5.2. Operators copy launch flags instead of reverse-engineering kernel support from issue threads. That matters when a checkpoint drops on a Tuesday and production wants a route by Thursday.
SGLang also ships SGLang-Diffusion for image and video generation and documents RL rollout integrations (verl, Miles, and others listed in the README). Buyers evaluating one runtime for both chat inference and training rollouts should read those sections separately. The diffusion subtree is not a drop-in for the LLM server path.
Why it is moving now
Open-weight MoE checkpoints now arrive on weekly cadences. Teams that standardized on vLLM alone spend days porting new expert-parallel dispatch while traffic waits. SGLang's release train tracks those drops. v0.5.14 on 26 June 2026 lists day-zero DeepSeek-V4 support on GB300, NVFP4 MoE paths, and Waterfill/LPLB load balancing for DeepEP expert parallelism: dispatch-time balancing for shared experts and redundant expert replicas, per the release notes and an LMSYS blog the same day.
The June 2026 LMSYS blog on speculative decoding (DFlash and Spec V2) is where latency work is heading: draft-model paths and n-gram speculative variants in the same quarter as the MoE dispatch fixes. Treat SGLang as a moving target. Release v0.5.13 shipped 13 June 2026. v0.5.14 shipped 26 June 2026. This is not a frozen 2024 fork.
The README states deployments on more than 400,000 GPUs worldwide and lists enterprise adopters by name. Treat throughput claims in release blogs as project-reported until your own benchmark reproduces them on your hardware SKU.
License + activity + maturity (demo | usable | production-shaped)
License: the repository LICENSE file is Apache License 2.0. Activity: tagged releases roughly every two weeks through Q2 2026 (v0.5.12.post1 on 26 May 2026 through v0.5.14 on 26 June 2026, per GitHub release metadata). GitHub star count at publication date is UNKNOWN.
Maturity: usable for teams with GPU operators who can read cookbooks, pin releases, and own kernel-specific flags. Production-shaped only after you run your model's exact quantization path, disaggregation topology, and speculative-decoding config under load. v0.5.14 alone touched scheduler shutdown, MSCCL++ collectives, AMD breakable CUDA graphs, and Ascend NPU paths. That surface is easy to misconfigure.
Default quick-start configs get a demo running. They do not prove your MoE layer count, context length, or PD disaggregation layout survives a production traffic mix.
When to pick it vs the default alternative
Pick SGLang when you need day-zero support for new open MoE checkpoints, expert-parallel dispatch tooling, or PD disaggregation on clusters you already operate, and you have engineers who will read release notes every two weeks.
Pick vLLM when your stack is already tuned there and you don't need SGLang-specific MoE or RadixAttention features enough to justify a second runtime.
Pick vendor-managed endpoints (Bedrock, Vertex, Azure OpenAI) when procurement wants one invoice and you are not hosting weights. SGLang is for teams holding GPUs or bare-metal contracts.
Pick TensorRT-LLM or TGI when you are NVIDIA- or Hugging Face-locked and want a narrower, vendor-aligned build without LMSYS's broad hardware matrix.
Pick LiteLLM or another HTTP router when the problem is normalizing API calls across SaaS providers, not scheduling GPU kernels. Routers can forward to SGLang. They don't replace it.
Failure modes
Release velocity cuts both ways. Upgrading for one model family can regress another backend path. Pin release tags in production. Don't track the default branch tip unless you employ runtime engineers full time.
MoE load-balancing flags change token routing. Waterfill and LPLB can hide per-layer imbalance until tail latency spikes. Measure before and after enabling them.
Disaggregated prefill/decode and speculative decoding multiply failure domains. A slow decode pool looks like a model quality problem in dashboards until you trace PD handoffs.
Hardware-specific kernels (Blackwell NVFP4, AMD HIP graphs, Ascend NPU) mean works-on-H100 does not imply works-on-MI300 without the cookbook. Test the exact SKU.
README adoption numbers are project-reported, not independently audited.
Links
- Repository: https://github.com/sgl-project/sglang
- Documentation: https://docs.sglang.io/
- Release v0.5.14: https://github.com/sgl-project/sglang/releases/tag/v0.5.14
- LICENSE: https://github.com/sgl-project/sglang/blob/main/LICENSE
Whether SGLang beats vLLM on your model and SKU is UNKNOWN until you benchmark with your context length, concurrency, and quantization settings.