模型会回答，还不等于能接客
一家服务同时涌进几千个 AI 请求，难题就不只是“模型能不能回答”，而是怎样排队、复用已经算过的内容，并让多块芯片一起工作。SGLang 就是处理这些杂务的推理服务框架——把训练好的模型封装成可并发调用的网络服务，负责调度、缓存和多卡协作。它面向部署团队，而不是普通聊天用户。
这也解释了它为什么值得现在看：模型发布越来越密集，每款模型又要适配不同芯片。发布当天能否真正上线，越来越取决于背后的服务栈。不过，本期材料只有项目方 GitHub 仓库一个机构信源；性能、采用规模和“连续升温”等判断都缺少独立验证。
它管的是模型背后的流水线
SGLang 覆盖从单块 GPU 到大型分布式集群的部署。项目列出的能力很多，核心可以归为三件事。
第一是少做重复计算。前缀缓存会保存不同请求中相同开头的中间结果，好比多份文件共用同一段模板，不必每次从头处理。第二是把请求更紧密地编排起来，包括连续批处理、多种并行方式，以及把“读懂输入”和“逐字生成”拆开运行。第三是扩大适配面：项目称其支持 Llama、Qwen、DeepSeek、Kimi、GLM 等模型，也覆盖 NVIDIA、AMD、Google TPU、Intel CPU 和 Ascend NPU。TPU 是 Google 为机器学习设计的专用加速器；支持它，意味着框架不再局限于常见 GPU。
项目时间线显示，这套服务栈一直追着模型与硬件更新。2025 年，它为 DeepSeek V3/R1、DeepSeek-V3.2 和 OpenAI gpt-oss 提供了首日支持；2026 年 7 月，又与 Miles 为 Kimi K3 增加 day-0 support，也就是尽量在模型发布当天即可部署。同月，RadixArk 与 Google 宣布把 SGLang 的完整功能带到 TPU。以上均为项目方说法。
热点为何从模型移到服务层
我们 9 月 1 日曾写过，同一个 Qwen 模型要跨手机、NVIDIA、AMD 和多卡系统运行，需要量化格式、推理引擎与硬件后端接力。SGLang 正处在服务器部署这一环。新模型越多、更新越快，这一层越像交通调度中心：模型本身决定车能不能开，服务框架决定大量车辆能否同时上路。
项目方展示的数字也指向这个需求：其称为 GLM5.2 的 NVFP4 智能体工作负载在两周内做到 500 TPS。TPS 表示单位时间处理的 token 或请求数量，反映整体吞吐量，并不等于单个用户看到第一个字的速度。项目还称，在 NVIDIA GB300 NVL72 上取得 25 倍推理性能提升；部署 DeepSeek 时，曾报告 3.8 倍输入处理吞吐量和 4.8 倍生成吞吐量。
这些数字不能直接横向比较。仓库摘要没有交代完整基线、模型配置、硬件规模、并发量、精度和测试方法，更适合视为项目方展示的案例，而非普遍性能结论。
SGLang 的轨迹也说明资本开始关注这一层。据 TechCrunch 报道，它最初是 2023 年诞生于 UC Berkeley、由 Databricks 联合创始人 Ion Stoica 主持的实验室项目；部分维护者后来成立 RadixArk。报道援引消息人士称，公司成立数月后估值约 4 亿美元。一个开源运行时迅速长成创业公司，侧面显示推理成本和部署效率已经成为独立赛道。
局限与未知
- “两日升温”和“受追捧”目前只是标题层面的趋势判断。材料没有提供连续两日的星标、排名、下载量或讨论数据，无法判断热度来自短期曝光还是持续采用。
- 项目称其每天支撑数万亿 token、覆盖超过 40 万块 GPU，并称自己已成行业标准，但没有给出统计口径或第三方审计。
- 仓库罗列了大量机构与兼容能力，却不足以证明各方采用深度。当前最可靠的结论是：SGLang 正积极追赶新模型与新硬件；它究竟在多大范围内成为默认基础设施，仍需外部数据回答。