【翻译】SGLang 社区 Kimi K3 首日支持

<aside>

本文由 AI 翻译得来

</aside>

原文：SGLang and Miles Add Day-0 Support for Kimi K3

作者：SGLang Team

日期：2026 年 7 月 27 日

翻译说明：正文、表格、图注与脚注均按原文完整翻译。为便于核验，模型名、算法名、命令行参数和并行缩写保留英文。所有标成「技术解读」的段落均为结合 SGLang kimi-k3 分支源码所作的补充，不属于原文。

我们很高兴地宣布，SGLang 和 Miles 已在首日支持 Kimi K3。K3 是首个进入 3 万亿参数级别的开源模型，其混合架构几乎在服务栈作出假设的每一个地方都偏离了惯例。SGLang 与 Moonshot AI 和 NVIDIA 团队合作，在发布当天完整覆盖 K3：SGLang 负责推理，Miles 负责 RL 训练。本文介绍实现这一目标所需的工作。

亮点

**一种新的混合架构。**2.8T 参数，69 个 KDA 线性注意力层与 24 个 MLA 层交错排列，并引入 LatentMoE 和 Attention Residuals；服务栈的大多数假设都会在某处失效。
**管理两种状态的内存，**其中包括一种会原地覆盖自身的循环状态；在此基础上重新构建 prefix caching、overlap scheduling 和 paging，并设计统一内存池，消除最后一个容量配比猜测。
**一条 kernel 优化阶梯，**在启用推测解码前，batch 1 达到约 113 tok/s。
**DSpark 推测解码，**使用我们为 K3 训练的 draft model：batch 1 解码达到约 423 tok/s。ReplaySSM 负责处理 KDA 状态，通过重放原始输入代替逐步保存快照，将 draft window 内存降低约 32 倍。
**按阶段拆分并行策略：**prefill 使用 chunked pipeline parallelism，decode 使用 tensor parallelism；两者在 PD disaggregation 下组合后，每张 GPU 达到 2,808 tok/s。
**Miles 在原生 MXFP4 checkpoint 上进行 LoRA RL，**trainer 与 rollout 共置于同一批 GPU：一次 12 小时训练将 AIME-2024 从 43.3% 提高到 76.7%。

启动命令和针对不同工作负载的配置建议见 Kimi K3 cookbook。

启动 Kimi K3

Kimi K3 是首个进入 3 万亿参数级别的开源模型：2.8T 参数、100 万 token context window，并原生支持视觉理解。它的前代 K2.5 在架构上与 SGLang 已能良好服务的模型十分接近，因此现有栈的大部分能力都可以直接应用。K3 则不同——它同时在多个相互独立的方面偏离了惯例：

	Kimi K2.5	Kimi K3
规模	约 1T 参数	2.8T 参数
注意力	全部为 MLA，共 61 层	混合架构：69 个 KDA 线性注意力层 + 24 个 MLA 层，共 93 层
Attention Residuals	无	保存每个注意力输出，并在每个 block 中聚合
MoE	384 个 expert，top-8	LatentMoE：896 个 expert，top-16，在 3584 维 latent space 中运行
Expert 激活函数	SwiGLU	SiTU
Vision tower	MoonViT	MoonViT3d，一套面向 K3 的新栈

表中每一行都是一个服务问题。混合注意力栈使 100 万 token context 在成本上变得可行，但这也意味着服务器必须同时保存两种状态：每个请求一份固定大小的 KDA 状态，以及 MLA 按 token 保存的 KV；下文的内存管理章节讨论的正是这个问题。Attention Residuals 让一个注意力输出 bank 贯穿整个栈，这破坏了 SGLang 标准 layer plumbing 的假设，并迫使 DP attention 等位置引入 K3 专用路径。LatentMoE 在降维后的 latent space 中，从 896 个 expert 里路由 16 个，并使用 SiTU 激活函数而非 SwiGLU，因此现有 MoE kernel 无法直接适用。视觉路径——tower、projector、processor 和 Kimi 的 XTML 媒体格式——也完全从头构建。下文各节都建立在这些启动工作之上。

技术解读：为何它不能只被当成一个更大的 K2.5。

kimi-k3 分支把这些差异直接编码成独立模型，而不是只改一份 config。模型文件开头明确列出 Attention Residual、Latent MoE、SiTU、MLA output gate 和 full-rank KDA gate 五条 K3 专用语义；KimiK3MoE 先把 hidden state 投影到 routed_expert_hidden_size，再在 latent space 中执行 top-k expert，最后投影回原维度。换句话说，896 个 expert 的主要计算发生在 3584 维空间，服务端既要支持新的权重布局，也要让路由、量化、EP 通信和激活 kernel 使用同一套 latent-space 契约。源码见 kimi_k3.py 的架构声明和 KimiK3MoE。

混合 KDA 内存管理

K3 的 KDA 与 MLA 混合架构带来两个内存管理难题。第一个难题是如何安全、高效地对可变的 KDA 循环状态使用 prefix caching。第二个难题是如何在 KDA 状态与 MLA KV 之间动态共享容量。

安全且高效地复用状态

Attention KV 只会追加。一旦计算完成，它就不再改变，因此 scheduler 可以安全地让多个请求共享 radix tree 中缓存的 prefix。KDA 状态则不同。每一层都维护一个固定大小的循环 buffer，并且该 buffer 会在每个 token 上被原地覆盖，因此 prefix caching 管理的是可变状态，不是不可变 KV。