9.0
重磅
AI SCORE
技术实践2026-08-17 02:12
Kimi K3的2.8T参数不是最难部分：MoE推理系统工程分析
dev.to · AI#MoE#LLM推理#量化部署
Editor brief · 编辑速览
深度解析Kimi K3的MoE架构、MXFP4量化权重、1.56TB公开checkpoint与vLLM服务优化实践，说明LLM部署已变成内存布局系统工程问题。
当第一次看到 Kimi K3 时，最引人注目的数字是 2.8 万亿参数。
听起来这就是部署的全部故事。
但在深入研究了 checkpoint、架构以及当前的 vLLM serving 方案之后，我认为更有趣的故事是这样的：
Kimi K3 是一个很好的例子，说明现代 LLM 部署正在变成一个内存布局和系统工程问题，而不是简单的参数数量问题。
Kimi K3 是一个 MoE（Mixture-of-Experts）模型，具有以下特性：
然而发布的模型远非假设中的 5.6 TB BF16 checkpoint。
原因在于部署的第一个有趣的细节。
Kimi K3 训练时使用 MXFP4 权重和 MXFP8 激活值。
公开的 checkpoint 约为 1.56 TB，所以你不需要先下载一个巨大的 BF16 模型，然后再决定是否量化以使其部署可行。
低精度表示是模型预期推理路径的一部分。
这是一个有意义的转变。
对于基础设施规划，问题的焦点从：
"我应该下载哪个社区量化版本？"
变成：
"哪种硬件能高效执行模型的原生格式？"
这立刻将你推向需要 MXFP4 内存容量和内核的新一代加速器。
这可能是关于大型 MoE 模型最容易误解的点。
Kimi K3 每个 token 仅激活约 104B 参数。
这对于计算来说很棒。
但这并不意味着你只需要足够的 GPU 内存来存放 104B 参数。
其他 experts 仍然存在。
它们的权重仍然必须可用。
所以实际上需要考虑两个不同的数字：
这个区别解释了为什么一个 2.8T 的 MoE 可以有合理的单 token 计算量，同时仍然需要数据中心级别的硬件才能自托管。
这就是模型不再像你在闲置推理服务器上随意启动的东西的地方。
当前的 vLLM 指南以 NVIDIA 的 8× GB300 作为起点。
对于 AMD，记录在案的 ROCm 路径从 8× MI355X 或 MI350X 开始。
vLLM 的发布文档还将 16× B200 描述为支持的配置。
所以即使模型被大量压缩，我们仍然在讨论在认真考虑服务余量之前大约两 TB 的聚合加速器内存。
最后这部分很重要。
权重容量只是开始。
Kimi K3 支持超过 100 万 token 的上下文。
很容易看到这个数字就立即用以下命令启动 vLLM：
--max-model-len 1048576
但这可能不是大多数生产部署应该开始的方式。
每个上下文 token 都有服务成本。
更长的序列意味着更多的缓存状态、更低的并发度、以及更少的并发请求空间。
Kimi K3 确实比传统 Transformer 使长上下文更有趣，因为它的架构不仅仅是堆叠了一层又一层的普通全注意力层。
它使用混合设计：
Kimi Delta Attention 维护循环状态，而不是允许传统的 KV cache 在每一层以相同方式增长。
周期性的全注意力层仍然需要自己的 KV 状态。
这意味着 vLLM 必须在同一模型内管理两种不同类型的缓存状态。
这不仅仅是一个架构上的好奇。
它影响了前缀缓存、调度、内存分配和长上下文服务的实际工作方式。
正常的前缀缓存在概念上很简单。
如果多个请求共享：
system prompt
+
large common document
+
user-specific question
你不会想每次都重新计算公共前缀。
对于普通的 Transformer，你可以重用缓存的 KV 块。
Kimi K3 使这变得复杂，因为 KDA 层维护循环状态，而全注意力层维护常规的 token 级 KV 状态。
因此 vLLM 必须让它的缓存管理器理解两者。
这是我发现比 2.8T 这个标题数字更有趣的 Kimi K3 的亮点之一。
新的模型架构正越来越多地迫使 serving 引擎成为架构感知的系统，而不是通用的"加载权重然后运行注意力"的框架。
一旦基础设施准备就绪，面向用户的部分看起来仍然很熟悉：
vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--trust-remote-code \
--load-format fastsafetensors \
--enable-prefix-caching \
--enable-auto-tool-choice \
--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3
这为你提供了一个 OpenAI 兼容的端点。
复杂性大多隐藏在下面：
这正是一个推理引擎应该对应用开发者隐藏的东西。
对于交互式应用，仅让模型能运行是不够的。
一个模型在技术上可以运行，但用户仍然可能感到非常缓慢。
vLLM 的 Kimi K3 工作包括对 DSpark 投机解码的支持。
不是让完整的 2.8T 模型顺序生成每个下一个 token，而是让一个更小的 draft 模型提出几个候选，Kimi K3 验证它们。
发布的 GB300 基准测试相当惊人：
在单用户基准测试中大约有 3.14 倍的提升。
投机配置使用七个提议的 token：
--speculative-config '{
"model":"Inferact/Kimi-K3-DSpark",
"method":"dspark",
"num_speculative_tokens":7,
"attention_backend":"FLASHINFER_MLA",
"draft_sample_method":"probabilistic",
"rejection_sample_method":"block"
}'
对我来说，这是部署故事中重要的部分。
我们花了很多时间比较量化格式和 GPU 内存。
但是一旦一个巨大的模型已经能运行，decode 策略对用户体验的影响可能比从 checkpoint 再压缩几个百分点更大。
8-GPU 机器回答的是：
我能加载和服务这个模型吗？
它不会自动回答：
我能经济地服务数百个 agent 会话吗？
在更高流量级别上，Kimi K3 开始变成一个集群架构问题。
你有几个维度可以处理：
一旦跨越机器边界，网络就成为模型性能的一部分。
vLLM 的 K3 方案明确区分了高带宽 NVLink 风格部署和 RDMA 连接的多节点设置。
在那个点上，说：
"这个集群有足够的 VRAM"
你需要知道那个 VRAM 在哪里，以及 GPU 能以多快的速度通信。
如果我现在规划 Kimi K3 部署，我不会从问"哪个集群有 1.56 TB VRAM 最便宜？"开始。
我会从四个工作负载问题开始。
1. 我实际需要多少上下文？
如果请求通常保持在 32K 或 64K 以下，就不要像每个请求都会消耗 100 万 token 那样预留资源。
2. 工作负载是否对延迟敏感？
交互式编码 agent 可能会从投机解码中获益巨大。
批处理工作负载可能更关心聚合吞吐量。
3. 我期望多少并发？
一个开发者测试 K3 和一个生产 agent 平台服务数百个会话是完全不同的部署。
4. 我是在优化最低硬件还是生产效率？
能加载模型的最小集群不一定是有最佳每 token 成本的集群。
对于 MoE 模型尤其如此，在那里通信和 expert 路由开始主导扩展决策。
但更有用的教训是它告诉我们的关于下一代开放模型的东西。
部署思维正在从：
参数数量
→ 精度
→ VRAM
→ 启动服务器
转向更像：
模型架构
→ 原生数值格式
→ 内存拓扑
→ 缓存架构
→ 并行策略
→ 互联
→ 投机解码
→ 工作负载特定的上下文
这是一个更复杂的部署栈。
也是一个更有趣的栈。
不久之前，一个 2.8T 参数的开放权重模型听起来几乎不可能自托管。
今天，它可以通过 OpenAI 兼容的 vLLM 端点提供服务。
你只是首先需要几 TB 的非常快速的 GPU 内存。 :)
我整理了一份更偏重基础设施的详细分析，包括 checkpoint 大小、经过验证的 GPU 布局、vLLM 配置和部署方案：
完整的 Kimi K3 部署指南：https://blog.gpus.market/deploying-kimi-k3-with-vllm-verified-gpu-pods-quants-and-serving-recipes