DigitalOcean 在发布首日上线 Kimi K3 模型服务

DigitalOcean 在第 0 天就上线了 Kimi K3。它已经是平台上乃至整个市场上最受欢迎的模型之一：在 Hugging Face 上点赞数排名第二，在 OpenCode 上流量排名第六。要让这么大规模的模型在第一天就运行良好，需要多个团队付出实打实的工作。感谢 Moonshot AI、Inferact、RadixArk、NVIDIA 和 AMD 的帮助，让我们走到了这一步。

把一个新模型部署起来、集成进 DigitalOcean 的 Inference Engine，并在第 0 天就展示出它的独特之处，需要三样东西：合适的硬件、调优过的 serving 栈，以及对照 Moonshot 自家 benchmark 的严格验证。

以下是我们一路走来学到的经验：

我们选择了 NVIDIA HGX™ B300 和 AMD Instinct™ MI350x GPU 来运行 K3，因为这些实例提供了 K3 这种规模和架构的模型所必需的内存容量、FLOPs 和互连能力。我们用 llm-d 构建了分布式推理栈，因为它原生支持 GPU 类型的异构性。这让我们能快速把 K3 同时接入 AMD 和 NVIDIA 平台。

Kimi K3 总参数量约为 2.78 万亿，有 896 个路由专家，其注意力栈将 69 层 Kimi Delta Attention（KDA）与 24 层 Gated Multi-head Latent Attention（MLA）交错排列。Kimi-K3 的权重总计约 1.56 TB，每块 GPU 需要约 195 GiB。

仅权重就有如此大的内存占用，而且还要为 KV cache 和激活值留出足够的余量，因此实际的部署单元是一台 8x NVIDIA HGX B300 或 AMD Instinct MI350X 服务器。两者都有 288GB 的显存容量，加载权重之后，仍剩下一定量的可用内存给 KV cache。

完整的权重无法加载到单块 GPU 上。这正是高速 scale-up 互连——NVIDIA 的 NVLink 或 AMD 的 Infinity Fabric——至关重要的地方，它确保有足够的互连能力来支撑带宽密集、延迟敏感的注意力和专家并行计算。

K3 的 serving 方案是与 vLLM 团队合作，沿以下维度优化出来的：

我们在不牺牲单位经济效益的前提下，最大化了输入/输出 token 吞吐量。

具体来说，这意味着三件事：

我们寻找并发的甜点区：同时处理的请求足够多，让 token 吞吐量保持健康，又不让延迟拖累用户体验。具体来说，这意味着三件事：

在 8x 服务器上 serving Kimi-K3 这样的大模型，意味着每台服务器能承载的并发用户会话数相对较少。在确定了并发甜点区、并支持 100 万 token 上下文窗口之后，我们有了足够的数据点来规划发布所需的 NVIDIA HGX™ B300 和 AMD Instinct™ MI350X 容量。

一个开放权重模型的 benchmark 分数，只有在 serving 它的人把 serving 栈配置正确时才是真实的。像 Fable 5 或 GPT 5.6 这样的闭源前沿模型，由单一厂商端到端地调优、服务和验证。Kimi K3 没有这个待遇：Moonshot 发布权重，而每一个 serving 这些权重的基础设施提供商——包括 DigitalOcean——都必须独立地把每一个解码参数、每一条解析规则、每一处线格式细节都弄对。只要我们弄错任何一处，模型的表现就会低于它自己公布的数字——不是因为权重更差，而是因为 serving 层更差。

Kimi K3 是一个接近前沿的模型，在真实 benchmark 上与 Fable 5 和 GPT 5.6 有竞争力。但这一切只有在模型被正确 serving 时才成立。糟糕的 serving 可以把一个前沿模型变成一个平庸的模型。

在之前几次模型发布之后，Moonshot 发现，serving 相同权重的各厂商得到了不一致的 benchmark 结果，有时是因为解码参数不匹配，有时是因为更深层的 serving 栈问题。这就是为什么他们在 K2.6 同期开源了 Kimi Vendor Verifier（KVV），以确保每一个 serving 他们权重的厂商都正确运行这些权重。

Moonshot 在 K2.6 同期开源 Kimi Vendor Verifier（KVV）项目，正是出于这个原因：他们已经认识到，开源权重只是工作的一半。另一半呢？确保每一个 serving 这些权重的厂商都正确运行它们。

他们的结论，用他们自己的话说：权重越开放、部署渠道越多样，质量就越难以控制。如果用户无法区分模型能力缺陷和工程实现偏差，整个开放权重生态的信任就会被侵蚀。因此，KVV 是 Moonshot 的答案：一套六个 benchmark 的测试套件，每个厂商都必须通过，其中包括解码参数预验证、OCRBench、MMMU Pro、AIME2025、一个工具调用 F1 与 JSON-schema 准确率 benchmark，以及 SWE-Bench。持续的修复直接贡献给了 vLLM、SGLang 和 KTransformers，并提供发布前访问权限，让厂商能在用户之前发现问题，同时还有一个公开的厂商结果排行榜。

KVV 中的每一项测试——工具调用 schema 注入、动态工具、流式规范符合性、解码参数处理——之所以存在，都是因为配置错误的 serving 栈会把一个真正接近前沿的模型变成一个在质量 benchmark 上表现差得多的弱模型。

我们还具体定位了 BEAM，这是 KVV 中听起来比较奇怪的一项：它是一个长期记忆 benchmark，运行在最长 100 万 token 的合成对话上。这也是为什么我们分享的若干修复都是对照 Moonshot 的真实 fixture 来检查的。这包括一条动态工具消息发送 content: null 或一个精确的 usage.prompt_tokens 整数——这些是来自 Moonshot 的真实值，而不是我们自己对这些 fixture 应该长什么样的猜测。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）