Kimi K2.6 今日从 NVIDIA NIM 下线：operator 必须立即评估的三条迁移路径

2026 年 7 月 7 日起，NVIDIA NIM 关闭了其托管的 Kimi K2.6 endpoint。如果你的 AI gateway 或应用将流量路由到 https://integrate.api.nvidia.com/v1，并使用 model: "moonshotai/kimi-k2.6"，这些请求现在已经返回错误。这不是渐进式下线——NIM 的 deprecation 通知已明确写明该 API「将于 07/07/2026 后不再受到支持」。

你现在面临的路由决策不仅仅是「换哪个模型」，而是一次 provider 迁移：NVIDIA NIM 并没有添加 Kimi K2.7 Code endpoint 来替代 K2.6。与 K2.5 → K2.6 过渡不同（当时 K2.6 在 K2.5 下线前已上线 NIM），目前 build.nvidia.com 上没有 moonshotai/kimi-k2.7-code endpoint。你的路由层需要切换 provider，而不仅仅是改个 model name。

发生了什么

Kimi K2.6 于 2026 年 4 月 29 日作为托管 trial endpoint 上线 build.nvidia.com。NVIDIA 在同一页面发布了 deprecation 通知：该 API 仅支持到 2026 年 7 月 7 日，也就是今天。

这个模式与 K2.5 周期如出一辙：NVIDIA 在 NIM 上托管 Kimi K2.5，以极短通知期（4 月时仅 10 天）下线，并未立即添加 K2.6 替代，之后才上线了 K2.6。K2.6 的生命周期有所延长（约 10 周窗口），但目前仍无确认的 K2.7 Code NIM endpoint。

为何对 AI 工程团队至关重要

NVIDIA NIM 是 Kimi K2.6 颇受欢迎的后端，原因有两点：一是提供了免费 tier endpoint，无需 Moonshot 账号即可原型开发；二是基于 NVIDIA endpoint URL 的 OpenAI-compatible API，对于某些企业网络策略而言，比中国托管的基础设施更容易列入白名单。

依赖 NIM 作为 Kimi K2.6 生产或 staging 后端的团队，现在必须回答一个具体的路由问题：Kimi K2.6 流量该去哪里？

Kimi K2.7 Code 目前在 Moonshot 平台 API 上可用。它是 Moonshot 目前最强的编码专项模型，具备 256K context、始终开启的 thinking-mode 推理，以及在短 context 场景下可达 260 t/s 的 HighSpeed 变体。与 K2.6 相比，K2.7 Code 更专注——它是编码专项，不具备 K2.6 的原生多模态（图像/视频）输入能力。主要用于代码生成的团队可直接升级；依赖 K2.6 视觉能力的团队则需要不同的迁移路径。

Router/operator 视角

三条迁移路径，按 operator 复杂度排序：

路径一：Moonshot 直连 API（摩擦最低，适合大多数团队） 将路由层的 base_url 切换为 https://api.moonshot.ai/v1，model 改为 kimi-k2.7-code（对延迟敏感的工作负载可选 kimi-k2.7-code-highspeed）。Kimi 平台 API 与 OpenAI 兼容，可直接使用相同的 SDK。若尚未有 Moonshot 平台 API key，需先申请。延迟特征与 NIM 托管推理不同，建议在切换生产流量前先跑基准测试。

路径二：通过 vLLM 或 HuggingFace 自托管（适合有本地 GPU 集群的团队） Kimi K2.7 Code 以 Modified MIT 协议开源，可在 HuggingFace（moonshotai/Kimi-K2.7-Code）获取。如果你的团队已经在用 vLLM 服务其他开权重模型，可将其添加为新的服务目标。vLLM Recipes（recipes.vllm.ai/moonshotai/Kimi-K2.7-Code）提供了详细的部署文档。这条路径保留了数据本地化保证，不依赖任何外部 API，但需要为 1T MoE 模型准备 GPU 算力。

路径三：通过 Moonshot 直连或其他 provider 回退到 K2.6（如需多模态能力） kimi-k2.6 仍在 Moonshot 平台 API（api.moonshot.ai/v1）上可用。如果你的工作负载依赖 K2.6 的图像/视频输入能力，可暂时将流量路由到 Moonshot 直连的 K2.6，同时评估 K2.7 Code 的纯文本能力是否满足需求。这是短期过渡方案，而非最终状态。

对 gateway operator 的路由策略影响：

• 立即更新所有 NIM 专属 endpoint URL——这些 URL 现在正在返回错误。
• 如果你的 gateway 使用 provider: nvidia_nim + model: kimi-k2.6，model 字符串也需要更改；NIM 上不存在 kimi-k2.7-code。
• 检查 fallback chain 中是否将 NIM 作为 Kimi 的次级 provider。如果是，该 fallback 现在已损坏，会在最终失败前静默消耗所有重试次数。
• 成本说明：Moonshot 直连 API 的 K2.7 Code 按用量计费；迁移后 NIM 免费 tier 配额消失。

TheRouter 用户该关注什么

如果你的路由配置中将 NVIDIA NIM 作为任何 Kimi 模型的后端，请立即审查。NIM 临时托管 Kimi 模型后又在不提供同版本替代的情况下下线，这种模式已经发生两次（4 月的 K2.5，今天的 K2.6）。构建不把 NIM 硬编码为 Kimi 主路由的 provider fallback 逻辑——并能 fail over 到 Moonshot 直连或自托管 endpoint——将有效降低未来 NIM 调整周期的影响。

实际测试方法：现在就向 integrate.api.nvidia.com/v1 发送一个 model: moonshotai/kimi-k2.6 的请求。如果报错，你的 NIM 路由已经损坏。切换到 api.moonshot.ai/v1 的 kimi-k2.7-code，验证 context 和 tool call 行为后再切换生产流量。