SGLang v0.5.17：Kimi K3 首日可服务，以及一个认识会话的前缀缓存

这一版补齐的是支持路径，不是功能表

本站 07-16 发过 Kimi K3——2.8 万亿参数旗舰，当时的看点之一是「承诺月内开放权重」。这一版回答的是那条信号必然会引出的下一个问题：开放之后，自托管栈跑不跑得动、走哪条路、跑得对不对。

答案是首日可服务，而且落在《模型与推理引擎的支持路径》里的第三、四档而不是第一档。SGLang 为 Kimi K3 提供的不是「能加载」，而是：DCP、DSpark 推测解码、分段预填充 PP 配合 TP 解码、KDA 感知的前缀缓存、DCP 之上的 HiCache L2、量化权重上的 LoRA，以及推理、工具调用与 OpenAI 兼容服务——并且在 NVIDIA GB300 与 AMD MI35x 两家的硬件上分别验证过。

被服务的这个模型本身值得看一眼形状：2.8T 参数的多模态 LatentMoE，896 个专家、top-16，在 3584 维的隐空间里路由；1M token 上下文；69 层 KDA 线性注意力与 24 层 MLA 交错；MoonViT3d 视觉塔；并且以原生 MXFP4 检查点发布。原生低比特发布意味着量化不再是部署方自己补的一步。

认识会话的前缀缓存

这一版里最值得单独拿出来的一条，不是最快的那条。统一 Radix 缓存现在支持会话引用感知：请求可以携带一个稳定的 session_id，于是淘汰逻辑知道哪些前缀仍被一个活跃会话引用，而不是纯按缓存策略把它们踢掉；用完通过 /close_session 释放引用。开关是 --enable-session-radix-cache。

发布说明写明了它是为智能体与强化学习推演负载加的。这是推理层第一次长出一个明显属于智能体形状的概念：一个跑二十轮工具循环的会话，和二十个互不相干的请求，对缓存来说本来毫无区别——直到有人告诉它区别在哪。

其余几项，以及它们各自的条件

• Rust 前端初步支持：把从网络入口到「已分词请求交给 GPU 调度器」这前半段，从 Python 迁到多线程 Rust 实现。
• DWDP（MoE 预填充新并行策略）：通过 NVLink P2P 预取对端专家权重并在本地计算全部专家，从而去掉 EP 的 all-to-all token 分发。4 张 B200、gpt-oss-120b、仅预填充场景下，DWDP4 在 MNT 32K / ISL 32K 达到 1.92 倍于 DEP4；饱和时（CONC=128、ISL=8K）506K 对 329K tok/s，1.54 倍。作者自己标注为早期开发阶段。
• DCP 通信后端与 q-replicate：a2a 把打包后的注意力输出与 fp32 LSE 放进每层一次 NCCL 集合通信，fp8 KV 以 uint8 字节承载；fi_a2a 在 GB200 上把跨 rank 交换交给 FlashInfer MNNVL 内核。--dcp-replicate-q-proj 在本地投影全头 Q，跳过逐层 Q 头维 all-gather。
• MiniMax-H3 首日支持：一次请求同时产出视频与同步立体声音轨，三种公开任务配置全覆盖；在 B200、H100 与两张 RTX 5090（逐层卸载）上验证。
• 其他新增模型：EmbeddingGemma 与 LFM2.5 嵌入模型、nvidia/MiniMax-M3-NVFP4，以及 Poolside Laguna-S-2.1 与 Thinking Machines Inkling-Small 的 cookbook 配方。

那个 1.92 倍值得按《交互系统中的延迟权衡》的规矩读一遍：它是仅预填充、在 4 张 B200 上、在特定 MNT/ISL 组合下、对照 DEP4、且作者标为早期开发的一个数。饱和吞吐那一组降到 1.54 倍——同一项优化在两种条件下差了近四成，这正是「速度永远是条件下的速度」的现成例子。

和这条线上的其他版本比

形状与本站已发布的 vLLM v0.26.0 完全一样：一个开源推理引擎在旗舰模型发布后的很短时间内，把整条推理栈补齐。区别在于覆盖面——这一版同时接住了一个 2.8T 的语言模型、一个视频加音频的扩散模型、若干嵌入模型，并且在两家 GPU 厂商上都做了验证。

对读者的实际含义是：判断「我能不能用上某个新旗舰」时，模型公告的日期已经不是决定性的那个日期；引擎的支持日期才是，而这两个日期正在被压缩到同一周。