2026 Kimi K3 vLLM OOM：调参还是扩容？

最后更新于 2026 年 8 月 16 日，环境要求与部署建议核实自 vLLM Kimi K3 官方 Recipe 及 vLLM 官方发布说明。

官方 Recipe 当前列出 CUDA 13 构建、R580 及以上 NVIDIA 驱动，以及至少 8 张 GB300 的 NVIDIA 路径；AMD 路径则要求至少 8 张 MI355X 或 MI350X。这组门槛直接决定排障顺序：如果 OOM 发生在权重加载和引擎初始化阶段，先查环境与拓扑，不能指望降低并发解决；只有模型初始化完成、请求运行时才 OOM，才适合从上下文、并发和缓存策略入手。

症状：Kimi K3 vLLM OOM。
最快解法：加载期先核对官方环境，运行期再用同一请求集调上下文、并发和缓存；生产负载仍无余量，就迁移或扩容。

这篇文章适合三类人：

• 个人研究者或 POC 团队：判断现有资源是否只够接口和工具调用验证。
• 小型 Agent 团队：在上下文长度、并发量与 prefix caching 之间找到稳定边界。
• 平台与生产交付团队：决定继续优化集群，还是启用多节点、迁移环境或临时扩展算力。

先按 OOM 发生阶段分流，而不是先改参数

先看日志位置和服务状态：

如果权重尚未加载完成，降低 max_num_seqs 或请求并发通常不会改变模型权重、通信缓冲区和初始化阶段的基本占用。你应该先确认是否使用官方 CUDA 13 镜像、宿主机是否达到 R580+，以及当前硬件是否落在官方支持路径内。

如果模型没有完成初始化，连续尝试零散显存参数只会增加排查噪声。停止条件应当是：在官方支持拓扑之外仍无法完成初始化时，停止把问题归咎于 vLLM 参数，转向合规环境验证。

个人研究者：先证明链路可运行，再谈容量

个人研究或 POC 的目标通常是验证 API、工具调用、视觉输入和基础推理链路，不是提前模拟生产吞吐。你可以把请求缩短到能覆盖工具定义、系统提示和一次完整 Agent 回合的范围，再把并发限制为单请求，目的是判断服务能否稳定返回，而不是测出最终容量。

推荐按这个顺序操作：

1. 固定官方 Kimi K3 Docker 镜像和启动命令，不同时更换镜像、后端和硬件。
2. 记录启动日志中权重加载完成、Engine ready 和端口监听的时间点。
3. 使用一个短文本请求验证首个响应，再加入工具定义或图像输入。
4. 只改变一个变量，例如上下文上限或并发限制。
5. 连续重复同一请求，确认不是偶然成功。
6. 保存启动参数、镜像摘要、驱动版本、错误日志和峰值显存。

官方发布说明给出的快速启动命令显式加入了 --tensor-parallel-size 8、--enable-prefix-caching 和工具调用解析器等参数；同时，官方说明当前 Kimi K3 的 Docker 镜像依赖预发布组件，因此不能把任意本地 vLLM 安装结果与官方 Recipe 等价看待。(vllm.ai)

POC 阶段可以接受的降载包括：

• 缩短测试上下文，只保留能复现功能的提示；
• 限制并发，避免把调度压力误判成模型无法加载；
• 暂时关闭非必要的视觉、工具和 speculative decoding 实验变量；
• 不把某个未经官方文档确认的参数值写成所有环境都适用的答案。

权重加载阶段的 OOM，调参数还有意义吗？
只有在确认模型已经完成初始化、错误发生于请求运行阶段时，参数调整才有明确意义。若权重仍未加载完成，优先检查镜像、驱动、硬件和并行拓扑；在官方支持拓扑之外无法初始化时，应转向合规环境，而不是无限压缩上下文或并发。

小型 Agent 团队：保留真实前缀，再压缩并发

小型 Agent 服务比单轮问答更容易遇到隐性显存压力。固定系统提示、工具定义、历史消息和工具结果会反复进入上下文；多轮请求既影响上下文占用，也决定 prefix caching 是否真正有收益。

Kimi K3 的缓存不是普通 Transformer 的单一 KV 缓存。vLLM 同时管理全注意力层的 KV block 与 KDA 层的循环状态；官方资料确认 Kimi K3 支持覆盖两类状态的 prefix caching，但默认未启用，需要显式传入 --enable-prefix-caching。(vllm.ai)

打开 prefix caching 后显存仍然不足，应该怎样处理？
先不要直接关闭缓存。你应当把“缓存命中带来的重算减少”和“缓存保留带来的显存占用”放在同一组请求里比较。官方发布说明介绍了按间隔保存 KDA 状态，以及在前缀第二次命中后再选择性保留等思路；其中，VLLM_PREFIX_CACHE_RETENTION_INTERVAL=0 可用于只保留提示结尾状态的场景，但是否适合你的版本和负载，仍应以对应版本复测为准。(vllm.ai)

不要用一次短提示证明问题已经解决。至少准备一组包含以下内容的请求：

• 相同系统提示、相同工具定义；
• 不同用户问题；
• 连续多轮 Agent 调用；
• 工具返回较长结果的请求；
• 一次超过日常输入长度的压力请求。

每次只改变一个变量，然后记录显存峰值、缓存命中情况、请求失败位置和响应稳定性。若降低并发后稳定，但上下文一恢复就 OOM，结论不是“修复完成”，而是服务受上下文容量约束。

平台团队：先确认你能控制哪一层

已有 GPU 集群的平台团队，最容易陷入“重新安装一遍”的循环。真正要先确认的是：你能否升级宿主机驱动，能否使用官方镜像，能否调整节点互联，能否改变 TP、EP 或多节点布局。

当前官方 Recipe 确认了 CUDA 13-only 镜像和 R580+ 主机驱动要求；如果主机仍是 CUDA 12.9 与 R575 驱动，方向是升级驱动，或自行从 K3 分支构建对应环境。后者属于自维护路径，不应与官方镜像支持混为一谈。(recipes.vllm.ai)

平台团队可以用这张表做分流：

官方建议在 NVLink 环境使用 flashinfer_nvlink_one_sided，RDMA 环境使用 deepep_v2；对于 DEP 部署，Recipe 推荐 deep_gemm_mega_moe。这意味着多节点不是简单增加 GPU 数量，通信路径本身会改变可用的并行方案。(recipes.vllm.ai)

现有集群不满足 Kimi K3 要求时，自构建是否值得？
如果你拥有宿主机、驱动、内核、网络和镜像发布的完整控制权，自构建可以作为研发路径；如果你只能修改容器，却无法改变驱动和节点互联，继续自构建往往会把一次性 OOM 变成持续维护成本。尤其是当前镜像依赖预发布组件，版本更新后需要重新验证。

生产交付团队：目标负载稳定不了，就从调参转向扩容

生产判断不能只问“模型能不能启动”。你需要把预期上下文、并发会话、Agent 前缀复用、工具调用失败重试和节点故障恢复一起纳入容量结论。

如果模型已经完成初始化，且 OOM 只在并发上升或长上下文请求出现，先降低并发并缩短上下文，目的是测出当前环境的稳定边界；如果在合理降载后仍没有稳定余量，或者目标流量恢复后持续触顶，就应该增加符合官方拓扑的算力，而不是继续牺牲业务参数。

官方资料给出的 Kimi K3 上限上下文为 1M tokens，但这不是建议你直接以该上限承载生产请求。vLLM 发布说明还给出过特定测试拓扑下的吞吐数据：在 16 张 NVIDIA GB300 NVL72 GPU 上，单用户 decode 从 118 tokens/s 提升到 370 tokens/s，使用了 DSpark；这些数字只适用于官方描述的测试条件，不能外推到你的集群。(vllm.ai)

生产复测至少分成三档：

1. 基线档： 日常上下文、日常并发、真实工具定义。
2. 峰值档： 高于日常的并发会话与长输入。
3. 恢复档： 节点重启、请求重试、缓存重新升温后的连续请求。

每档都记录：

• 权重加载是否完成；
• Engine 是否持续在线；
• 峰值显存和显存余量；
• 首 token 延迟与完整响应延迟；
• prefix caching 命中和重算情况；
• 工具调用解析失败与重试次数；
• 多节点通信错误和请求恢复时间。

如果只在峰值档 OOM，但基线档有稳定余量，可以进入限流、队列和持续监控阶段；如果基线档也没有余量，继续优化参数通常不能替代扩容。官方资料将多节点、专家并行以及 prefill/decode 分离列为大规模服务路径，这些方案必须匹配真实互联条件，不能按 GPU 数量简单相加。(vllm.ai)

Agent 服务什么时候已经到了必须扩容的程度？
当基线请求在目标上下文和日常并发下持续出现显存尖峰，或合理降载后仍无法覆盖目标流量，就应进入扩容评估。若只有极端峰值失败，可以先使用限流和排队；若每次缓存升温、工具重试或节点恢复都会再次触顶，则应优先考虑更大拓扑，而不是继续关闭业务能力。

用复测证据决定调参、迁移还是扩容

在做高风险变更前，你可以按下面的可勾选清单收集证据：

• [ ] 已确认 OOM 发生在权重加载、Engine 初始化还是请求运行阶段。
• [ ] 已记录镜像版本、vLLM 版本、CUDA 版本和宿主机驱动版本。
• [ ] 已确认当前硬件与官方 Kimi K3 支持拓扑一致，或明确标记为自定义验证。
• [ ] 已使用同一组真实请求，分别测试不同上下文和并发设置。
• [ ] 已显式确认是否启用 --enable-prefix-caching。
• [ ] 已记录缓存命中、峰值显存、失败请求和响应稳定性。
• [ ] 已分别测试基线、峰值和恢复场景。
• [ ] 已保存启动参数、请求样本和资源曲线，便于 vLLM 更新后复测。
• [ ] 已确认节点互联与 all-to-all backend 相匹配。
• [ ] 已计算降载后是否仍满足目标流量，而不是只看服务是否存活。

最终结论可以压缩成三种：

• 低负载验证通过： 保留最小环境，用于接口、工具和推理链路验证。
• 合理降载后稳定： 进入监控和容量积累阶段，明确并发、上下文与缓存上限。
• 权重无法加载或生产余量不足： 停止继续牺牲业务参数，迁移到官方支持拓扑或扩展多节点算力。

如果你需要先做环境对照，可以把同一份镜像、启动参数和请求集放到按周期交付的临时算力环境中，再与现有集群比较。这样做的价值不是“绕过 OOM”，而是把环境不兼容、通信问题和真实容量不足分开。你可以先查看 MacHTML 的帮助页面 了解交付与使用边界，再根据测试周期参考 MacHTML 的算力方案。

如果当前集群只能靠不断缩短上下文、压低并发和关闭缓存才能勉强运行，那么它更像验证环境，而不是生产环境。对 Kimi K3 这类依赖 CUDA 13、R580+ 驱动以及特定多节点通信路径的服务，临时租用合规算力做同请求集对照，通常比在受限集群上反复自构建更容易得到可审计的升级、迁移或长期扩容结论。