Kimi-K2.7-Code 2026-10-03 在 Microsoft Foundry 退役
只关 Foundry 这一面 · 官方替换栏是空的
Microsoft 的 Foundry 退役日程表把 Kimi-K2.7-Code（版本 2026-06-12，生命周期 Preview）那一行的退役日写成 2026-10-03，suggested replacement 一栏是「—」。到点不会自动换模型：之后打进去的推理请求返回 410 Gone，替代要你自己选。本页只管 Foundry 这一面 —— Moonshot 自家 API 文档（2026-09-20 抓取）仍把这个 id 列为可选值，别把两件事拼成「这个模型全线关停」。
更新于 2026-09-20
四个关键点
Foundry 表的退役日
那一行读作：模型 Kimi-K2.7-Code、版本 2026-06-12、Preview、退役日 2026-10-03、替换「—」。文档 ms.date 是 2026-09-02，页面 updated_at 是 2026-09-14，本页核对日 2026-09-20。
官方替换栏
那张表自述它发布的是 lifecycle stage、retirement date、suggested replacement，而这一行的 suggested replacement 是空。所以「微软会把你自动升到 K3」在原文里找不到依据，替代要自己定、回归自己跑。
到点后的调用形态
官方对「无替换的 Preview 条目」那句话包含两点：退役前给通知，退役后推理返回 410 Gone。通知天数本页不引用 —— 我方两次核对得到的天数并不一致，没回到官方现页定稿就宁可不写。
距退役日（我方换算）
以本页核对日 2026-09-20 起算，到 2026-10-03 是 13 天。这是本页自己算的，官方没有倒计时，条目也可能改期；改配置请赶在日期之前。
这是怎么回事
表上这一行管的只是 Microsoft Foundry 里的一个模型条目：Kimi-K2.7-Code、版本 2026-06-12、生命周期 Preview、退役日 2026-10-03。它管不到 Moonshot 自营端点，也管不到别的云 —— 同一模型族在每个入口各有自己的生命周期（例如 K3 在 Bedrock 写的是「不早于」加至少 45 天 EOL 通知，那是另一条款，套不到这里）。读者的动作只有一个：在 2026-10-03 之前，让线上不再有请求打到 Foundry 的这个条目。
发生了什么
2026-09-20 复核：Foundry 退役日程表（文档 ms.date 2026-09-02、页面 updated_at 2026-09-14）里 Kimi-K2.7-Code 那一行仍是 Preview + 2026-10-03 + 替换栏空。同一天的 Moonshot 官方 Chat Completions 文档，model 取值里仍写着 kimi-k2.7-code 与高速版 kimi-k2.7-code-highspeed，并写明两者是同一模型。
时间线
2026-06-12：Kimi-K2.7-Code 那一行版本栏的值，生命周期标为 Preview。表里没有上架日，本页就不把这一格当上线日期讲。
2026-09-20 本页复核：文档 ms.date 2026-09-02、页面 updated_at 2026-09-14，那一行没变；同日的 Moonshot 官方文档里这个 id 还在。
2026-10-03：Foundry 侧的退役日。替换未列时，之后仍打进该条目的请求返回 410 Gone。条目可能改期，请赶在日期之前把改动做完，而不是当天。
官方确认 vs 需注意
官方确认
能逐字对上的只有四件：Foundry 退役表该行的版本 2026-06-12、生命周期 Preview、退役日 2026-10-03、替换栏「—」；表自述它给出 lifecycle stage / retirement date / suggested replacement；「无替换条目退役后推理返回 410 Gone」那句；以及 Moonshot 文档把 kimi-k2.7-code 与高速版写成同一模型。
⚠️ 需注意
不能当事实写的：「K2.7-Code 全线停服」（表只约束 Foundry Models）；「微软会把你自动升到 K3」（替换栏空着）；「Bedrock / Vertex 上同一 id 也是 2026-10-03」（未查到那一行）；把 K3 on Bedrock 的至少 45 天 EOL 通知套到这条 Preview 上；以及引用 Foundry 的通知天数。范围之外的推测本页一律不做。
相同点 vs 差异
相同点
两条路调的都是 Moonshot 这颗编码模型；请求侧都靠 model / deployment 的值决定落在哪一条目；无论走哪条，改完都要用同一套 prompt 集回归，只换字符串不算验证。
差异
Foundry 那条有硬日期：2026-10-03 退役，之后返回 410 Gone，替换栏空。Moonshot 自营端点没有进我们查过的任何退役表（2026-09-20 抓的文档里它仍是可选的 model 值），但 base_url、鉴权、限速、计费与日志都要在你这边重配一遍。
该怎么做
四步。1）全仓搜 Kimi-K2.7-Code 与版本串 2026-06-12：应用配置、IaC、网关的模型映射表、评测集、告警规则都算，散在多处是常态。2）定替代 —— 官方替换栏是空的，可选「同 id 换端点」（Moonshot 官方文档仍列这个 id）或「换模型」；后者是换模型而不是改字符串，必须重跑回归。3）灰度：同一份固定 prompt 集在两条路上各跑一遍，比完成率与思考链行为。4）验证：先确认你的请求靠哪个字段选中这条目（模型 id 还是 deployment 名），再给 410 Gone 加一个监控计数，看它保持为零 —— 出现它就是切漏了。
在 QCode 上
先把线划清楚：QCode 的 /models 目录里没有 kimi-k2.7-code 这条（2026-09-20 核对），本页不给你「换到我们家就行」的捷径。/models 公开列表里能检到的 Kimi 只有 kimi-k3（近 30 天计价 850 次）；kimi-k2.6 在 30 天计价台账里是 21 次、但不在我们抓的这份公开列表 —— 那是族内另一次选型，改过去等于换模型，回归得你自己跑完。价格与限速以 /pricing 和实时目录为准。
常见问题
这是 Moonshot 把 K2.7-Code 下线了吗？
不是。退役日程表是 Microsoft 为自己云上条目写的清单，被标日期的那一行是 Kimi-K2.7-Code。Moonshot 自家平台文档在 2026-09-20 仍把 kimi-k2.7-code 列为 Chat Completions 的 model 取值。
微软给了替代 id 吗？
该行的 suggested replacement 是「—」，也就是没点名。对无替换的 Preview 条目，官方写法是退役后推理返回 410 Gone —— 不会静默切换，也不会自动升到 K3。
只改配置里的 model 字符串够吗？
先看你的请求是靠什么选中这条目的（模型 id 还是 deployment 名），再决定改哪一行。然后把 Kimi-K2.7-Code 与 2026-06-12 两个串在应用配置、IaC、网关映射里搜干净；改完看监控：打进旧条目的流量应归零，一旦出现 410 Gone 就说明有路径没切。
Bedrock / Vertex 上的 K2.7-Code 也是 2026-10-03 吗？
未查到那一行，所以别的云本页不讲。也别合并日历：K3 在 Bedrock 的条目写的是 EOL 日期未定、至少 45 天通知，那是另一平台的条款。
QCode 上还能继续调 kimi-k2.7-code 吗？
不能。2026-09-19 核对，/models 目录里没有它，本页不承诺任何「换过来就行」。/models 公开列表里的 Kimi 只有 kimi-k3（850 次）；计价台账里另有 kimi-k2.6（21 次），迁过去是换模型，不是改名字。
还剩多少时间？
本页核对日 2026-09-20 到 2026-10-03 是 13 天（我方换算，官方没有倒计时）。真正该盯的是官方现页：我们读到的那份文档 ms.date 停在 2026-09-02。
信息来源
Microsoft Foundry《Model retirement schedule》https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirement-schedule（文档 ms.date 2026-09-02、页面 updated_at 2026-09-14，本页于 2026-09-21 直接重取两份微软页面复核）与《Foundry Models lifecycle and support policy》https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirements（页面 ms.date 2026-07-24；「Retired = Removed from service. All inference requests return 410 Gone.」这条定义出自该政策页，不是专写 Kimi 的那一行）；Moonshot《Chat Completions API》https://platform.kimi.com/docs/api/chat（2026-09-20 抓取）。K3 在 Bedrock 的 EOL 条款一手出处是 https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-moonshot-ai-kimi-k3.html（2026-09-20 抓取；本站 /kimi-k3-amazon-bedrock-guide 也引了同一张卡）。QCode 目录与 30 天计价调用为本站内部核对。
相关阅读
Kimi K3 上 Amazon Bedrock
同一模型族在另一朵云上的生命周期与价格条款，和这页的 Foundry 日历不是一回事。
Kimi K2.6 完整指南
另一条 Kimi 线的指南，含在售状态与 30 天真实调用量的核对口径。
Kimi K3 状态追踪
把 K3 当替代之前，先看它哪些已确认、哪些仍是传闻。
本页转述 Microsoft 与 Moonshot 的公开文档，与两家均无隶属关系。所有外部日期以 2026-09-20 核对的版本为准，之后可能改期。QCode 不提供 Microsoft Foundry 服务，也不代其报价；13 天这类换算是本页自算，官方未给倒计时。