Kimi K3 vLLM 上线验收清单

进程已经启动，单次请求也返回了，但 Kimi K3 vLLM 仍可能不具备生产上线条件。

最快判断：只有 CUDA 13 与 R580+ 驱动链、压力下资源余量、prefix caching 实际命中、Agent 接口正确性全部通过，才能批准上线；版本不符先返工，资源持续不足再扩容。

谁需要这份 Kimi K3 vLLM 上线验收清单

这份清单适合已经跑通 Kimi K3 vLLM、准备从测试环境切到生产环境的推理工程师，也适合需要签署上线结论的 SRE、平台负责人和容量规划人员。

如果当前任务只是处理某一条启动报错，可先查看 ProxyMac 的技术帮助与环境排查入口。本文不从权重下载开始，而是回答一个更实际的问题：现有部署是否有足够证据进入生产。

截至 2026 年 8 月 13 日，官方 Kimi K3 recipe 仍标记为 Pre-release。当前 recipe 指定 Kimi K3 专用 Docker 镜像、CUDA 13 构建和宿主机 R580+ NVIDIA 驱动；后续 vLLM stable 支持状态、镜像标签或驱动要求变化时，应重新核对官方资料。(recipes.vllm.ai)

⚠️ 经验判断：进程存活、健康检查返回 200、短提示词成功，都只能证明基础链路可用。它们不能替代长输入、并发、缓存和工具调用验收。

第一项对比：能启动，不等于可以上线

Kimi K3 的验收结论不宜只写“成功”或“失败”。生产发布需要把证据分成四类：

• ✅ 可上线：兼容链符合官方要求；模型加载、长输入和并发压力没有持续性资源故障；缓存测试能观察到真实复用；工具调用和结构化输出通过 schema 校验。
• ⚠️ 限流观察：核心请求正确，但非关键路径仍有可控问题，例如工具调用偶发格式异常，或者高并发排队需要临时限制。必须有明确限流范围、值班责任人和回滚条件。
• ❌ 环境返工：镜像、CUDA、驱动、vLLM 支持状态或容器运行时信息不一致。此时继续修改零散启动参数，通常只会把环境问题变成更难复现的运行时问题。
• ❌ 资源扩容：兼容链已通过，但模型加载、长上下文、并发或持续运行阶段反复出现 OOM、KV Cache 挤压、排队堆积或跨节点通信瓶颈。

每一个结论都应附带测试时间、样本版本、硬件拓扑、容器信息、关键日志和复核人。没有这些内容，“可以上线”只是口头判断，无法交给后续值班人员执行。

兼容链对比：官方镜像验收与自建环境验收不能混写

官方 recipe 当前列出 vllm/vllm-openai:kimi-k3 镜像，并明确说明该镜像是 CUDA 13，也就是 cu130 构建；recipe 同时指出没有 cu129 标签，K3 相关 wheel 也不在 cu129 nightly index 中。宿主机需要 R580+ NVIDIA 驱动。(recipes.vllm.ai)

NVIDIA 的 CUDA 兼容文档也显示，CUDA 13.x 的最低驱动大版本为 R580；CUDA 13.0 GA 对应的 Linux 驱动要求为 580.65.06 或更高。这里的“R580+”是兼容基线，不等于任何一个驱动小版本都自动适合生产，还要结合 GPU、NCCL、Fabric Manager 和容器运行时验证。(docs.nvidia.com)

验收时至少采集三组信息：

1. 容器信息：镜像完整标签、容器内 CUDA runtime、PyTorch 与 vLLM 版本。
2. 宿主机信息：nvidia-smi 输出、驱动完整版本、GPU 型号、GPU 数量、节点间互联方式。
3. 启动日志：CUDA 初始化、通信后端、并行策略、KV Cache 初始化和任何 warning 或 fallback。

nvidia-smi 中显示的 CUDA 版本只能说明驱动宣称支持的最高 CUDA 版本，不能证明当前容器实际运行的 CUDA runtime、构建依赖和 vLLM wheel 完全一致。NVIDIA 官方文档明确区分了驱动提供的 API 兼容性和 Toolkit 所需的最低驱动版本。(docs.nvidia.com)

如果团队自行针对其他 CUDA 环境构建，验收表必须另开一栏，记录：

• 构建分支或提交版本；
• CUDA、PyTorch、FlashInfer 等依赖来源；
• Dockerfile 和锁定文件；
• 已知补丁；
• 回滚镜像；
• 与官方镜像测试结果的差异。

自建环境没有问题，但不能把自建结果写成“官方镜像已通过”。两者的故障边界不同，后续排障责任也不同。

容量对比：启动阶段、业务阶段和持续运行阶段分别验

Kimi K3 的官方 recipe 当前列出至少 8 张 GB300 的 NVIDIA 配置，并建议真实生产流量使用多节点；官方发布文还给出不同 GPU 代际与并行拓扑的部署说明。这个信息只能作为官方硬件基线，不能直接推导出某个团队的并发量、上下文上限或显存余量。(recipes.vllm.ai)

容量验收应拆成四个阶段，而不是只执行一次“加载模型 + 发请求”：

1．模型加载阶段

记录每张 GPU 的显存曲线、进程启动时间、权重加载完成时间和初始化日志。此阶段失败，通常指向权重、并行拓扑、容器依赖或基础显存不足，不应归因于 prefix caching。

2．长输入阶段

使用接近 Agent 生产请求的固定样本，包含系统提示、工具定义、历史消息和必要的结构化字段。不要只用几句话的短 prompt，因为短输入会低估预填充、混合缓存和上下文配置带来的资源压力。

3．并发阶段

逐步增加并发请求，观察：

• vllm:kv_cache_usage_perc；
• vllm:num_requests_running；
• vllm:num_requests_waiting；
• vllm:num_preemptions；
• 首 token 延迟和端到端延迟；
• OOM 前后的显存变化。

这些指标由 vLLM 的 /metrics 端点暴露。官方生产指标文档同时列出请求成功数、排队请求数、KV Cache 使用率、预填充时间和首 token 延迟等指标。(docs.vllm.ai)

4．持续运行阶段

让固定样本和变化样本交替进入服务，观察缓存是否逐渐挤压、请求是否被抢占、跨节点传输是否出现失败，以及进程是否在长时间运行后失去稳定性。

OOM 发生时，证据至少包括：

• OOM 前后每张 GPU 的显存曲线；
• 当时的输入 token、最大输出 token 和上下文设置；
• 并发数、请求持续时间和排队情况；
• 模型加载是否已经完成；
• 是否启用了 prefix caching、KV offload 或跨节点传输；
• OOM 后进程是否自动恢复、退出或留下异常状态。

如果只看到一条 CUDA out of memory，无法判断是启动容量不足、max-model-len 过大、并发造成 KV Cache 挤压，还是节点拓扑不适合。连续复现的资源瓶颈，优先调整上下文、并发或拓扑；调整后仍失败，才进入扩容评估。

第二项对比：参数存在，与 prefix caching 真命中

官方 Kimi K3 发布文给出的示例命令包含 --enable-prefix-caching，并说明 Kimi K3 的混合 KDA 与全注意力结构需要专门的 hybrid prefix caching 机制。当前验收不能只截图启动命令，因为“参数存在”不代表请求发生了可观测复用。(vllm.ai)

建议使用一组冷请求和三组热请求：

• 冷请求：首次发送完整系统提示、工具 schema 和业务上下文。
• 热请求 A：保持系统提示和工具定义完全一致，只改变用户问题。
• 热请求 B：保持共享前缀一致，改变工具调用所需的业务数据。
• 对照请求：修改系统提示中的一个关键字段，确认缓存不会被错误复用。

在 /metrics 中保存以下计数器的前后差值：

• vllm:prefix_cache_queries：发生过多少 prefix cache 查询；
• vllm:prefix_cache_hits：命中了多少缓存 token；
• vllm:prompt_tokens_cached：实际被缓存的 prompt token；
• vllm:request_prefill_kv_computed_tokens：本次预填充实际新计算的 KV token；
• vllm:request_prefill_time_seconds：预填充时间是否出现可解释变化。

vLLM 官方指标文档明确给出了这些指标的含义。其中 prefix_cache_hits 和 prefix_cache_queries 以缓存 token 计数，不是简单的请求次数；prompt_tokens_cached 同时覆盖本地和外部缓存。(docs.vllm.ai)

Kimi K3 的 KDA 状态不会像普通全注意力 KV 一样在每个 token 边界都低成本保存。官方发布文介绍了 prompt-end retention、间隔保留和基于重复命中的选择性保留机制，因此长 Agent 上下文的缓存命中形态可能与短对话不同。(vllm.ai)

通过标准不是“启动日志出现 cache enabled”，而是：

• 冷请求查询数增加，但命中接近 0；
• 热请求的命中 token 增加；
• 热请求新计算的预填充 token 减少；
• 预填充耗时出现与复用规模相符的变化；
• 修改共享前缀后，命中行为按预期下降；
• 重启、跨实例或外部 KV 连接场景下，缓存来源能够被区分。

如果只有命中计数增长，却没有新计算 token、预填充时间或请求延迟的对应变化，应先检查样本是否真的共享前缀、指标采集是否来自正确实例，以及是否存在外部缓存统计混入。

接口正确性：文本能返回，不等于 Agent 能调用

Kimi K3 的生产验收还要覆盖工具调用、多轮对话、推理字段和结构化输出。官方 recipe 特别提醒，K3 偶尔可能生成工具调用格式，而自身 parser 未必能按预期解析，因此建议加入 schema 校验和重试。(recipes.vllm.ai)

固定样本至少应包含：

• 一个带多个参数的工具 schema；
• 一次需要调用工具的用户请求；
• 工具返回结果后的第二轮对话；
• 一次工具失败后的重试；
• 一次结构化 JSON 输出；
• 一次包含推理字段、正文和 tool_calls 的流式响应。

逐项检查：

• 响应正文是否位于调用方预期字段；
• 推理字段是否被网关错误拼接到正文；
• tool_calls 的名称、参数和索引是否符合协议；
• JSON 是否能通过 schema 校验；
• 工具失败后是否触发预期重试；
• 多轮历史是否保持角色、工具定义和工具结果的顺序；
• 流式与非流式接口是否返回一致的语义结果。

发现异常后，要把问题拆成三类：

• 模型输出问题：同一输入重复出现非法格式。
• vLLM 解析问题：模型输出合理，但 parser 字段映射错误。
• 网关或调用方问题：服务端返回正确，经过代理、解析器或重试层后被破坏。

不要把所有 tool_calls 异常都归因于 GPU 环境。接口验收的目标是确认调用链契约，而不是证明模型“看起来会用工具”。

可勾选的 Kimi K3 vLLM 上线验收表

在签署发布单前，建议由部署工程师执行，SRE 或平台负责人复核：

• [ ] 已记录官方 recipe 访问日期、镜像完整标签和 vLLM 支持状态。
• [ ] 已核对容器内 CUDA 13 runtime 与宿主机 R580+ 驱动。
• [ ] 已分别保存容器、宿主机和启动日志中的版本信息。
• [ ] 已记录 GPU 型号、GPU 数量、节点数量和节点间互联方式。
• [ ] 已完成模型加载阶段显存曲线采集。
• [ ] 已使用固定 Agent 样本完成长输入测试。
• [ ] 已在不同并发条件下记录排队、抢占、KV Cache 和延迟指标。
• [ ] OOM 测试保存了请求参数、并发条件和前后显存曲线。
• [ ] 已显式启用 prefix caching，并完成冷请求、热请求和变更前缀对照。
• [ ] 已保存 prefix_cache_queries、prefix_cache_hits 和 prompt_tokens_cached 差值。
• [ ] 已完成工具 schema、多轮调用、结构化输出和失败重试测试。
• [ ] 已将模型、解析器、网关和调用方故障分开记录。
• [ ] 已指定上线后的监控负责人、限流策略和回滚触发条件。
• [ ] 所有结果均有测试条件、时间、日志位置和复核人。

上线后的首轮监控至少保留 GPU 显存、KV Cache 使用率、排队请求、抢占次数、请求成功率、首 token 延迟、端到端延迟和 prefix cache 命中计数。若出现持续 OOM、进程重启、工具调用协议错误扩大，或缓存命中与预期样本明显背离，应暂停放量并回滚到上一套可验证环境。

返工还是扩容：用证据选择下一步

对于需要临时扩容、异地测试或交付 GPU 推理环境的团队，可以先结合 ProxyMac 的算力租赁方案说明整理当前驱动版本、容器信息、负载样本和压测记录，再判断是重建兼容链、增加容量，还是更换部署拓扑。具体可用资源、交付方式和地域需要以实际确认结果为准，不能用静态页面替代现场验收。

常见验收误区：为什么“看起来正常”仍会失败

• ❌ 只跑短 prompt：没有覆盖 Agent 的系统提示、工具定义和历史上下文。
• ❌ 只看 nvidia-smi：没有证明容器实际使用的 CUDA runtime 与构建依赖一致。
• ❌ 只看启动参数：没有证明 prefix caching 产生了命中和计算量变化。
• ❌ 只记录 OOM 文本：没有保存显存曲线和请求条件，无法判断根因。
• ❌ 只测试一次工具调用：没有覆盖 parser 偶发异常、失败重试和多轮协议。
• ❌ 看到资源不足就盲目扩容：如果根因是 R580、CUDA 13 或镜像链不一致，扩容只会复制问题。

FAQ

Kimi K3 vLLM 启动成功后，还需要保留哪些验收证据？

至少保留容器镜像与 vLLM 版本、容器内 CUDA 信息、宿主机驱动信息、启动日志、压力阶段的显存曲线、请求参数、并发条件和接口响应样本。单次请求成功只能证明基础链路可用，不能证明长上下文、缓存复用和工具调用在生产负载下稳定。

Kimi K3 的 CUDA 13 和 NVIDIA 驱动怎样才算兼容？

官方 recipe 当前要求使用 Kimi K3 专用容器镜像，该镜像是 CUDA 13 构建，并要求宿主机使用 R580 或更高版本驱动。验收时要同时核对容器运行时、宿主机和启动日志；如果自行改用其他 CUDA 环境，必须单独记录构建来源、依赖锁定和回滚方式。

怎样确认 Kimi K3 的 prefix caching 真的生效？

先显式启用 prefix caching，再用完全相同的系统提示、工具定义或共享上下文发送冷请求和热请求。检查 vLLM 的 prefix cache queries、prefix cache hits、prompt_tokens_cached 以及缓存前后的预填充时间。只有计数器增长且延迟或计算 token 出现对应变化，才能认定产生了有效复用。

Kimi K3 压测出现 OOM，还能直接上线吗？

不能把 OOM 当成偶发日志直接放行。需要判断它发生在模型加载、长输入、并发增加还是缓存挤压阶段，并保留 OOM 前后的显存曲线和请求条件。若通过调整上下文或并发后仍重复出现资源瓶颈，应重新规划拓扑或扩容；只有非关键、可限流的问题才适合观察上线。

Kimi K3 部署验收不通过，应该重装环境还是扩容？

版本链不符合官方要求时，优先重建或返工环境，扩容无法修复 CUDA、驱动和镜像不匹配。只有兼容链已通过、但在真实上下文和并发下持续出现显存、排队或跨节点通信瓶颈时，才进入扩容或调整拓扑评估。接口解析问题则应先隔离网关和调用方协议。

当前自建方案的主要风险通常不是“能不能启动”，而是 CUDA 13 与 R580 驱动链容易被节点差异破坏、长上下文和并发容量难以提前验证、缓存指标与业务请求脱节，以及工具调用问题可能在网关层才暴露。若团队需要的是临时算力、上线前复测或短期生产交付，ProxyMac 的 Mac 方案可以作为对照环境来评估；但长期稳定重负载、需要物理 GPU 拓扑控制或必须接入专用硬件的场景，仍应优先建设自有集群。最终决策应以真实驱动、容器、负载和压测记录为准，而不是以一次成功请求作结论。

常见问题