Kimi K2 的 10 月 31 日限制，不是所有用户当天断服
Kimi API 平台的 K2 从 10 月 31 日起不再对新注册用户提供，既有用户不受这项限制影响；全系列退役仍是年底计划。迁移 K3.1 前，还要分清 API、会员、待发布权重与 Highspeed 缓存计费。
按 Kimi API 平台的迁移通知，K2 的 10 月 31 日变化针对新注册用户：他们将不再获得 K2 系列模型，既有用户不受这项限制影响。官方同时计划在 2026 年 12 月底前退役全部 K2 系列，因此老应用需要开始准备迁移，但不是所有用户都要在 10 月 31 日当天停服。K3.1 Pro 已有 API 接入路径；完整权重则是另一项尚待核实兑现的发布承诺，不能把两者合成“已经可以自部署”。
对于还在运行的应用，这比新模型在排行榜上前进了几名更紧迫。真正要回答的是：现在该不该切、切到哪里，以及换完之后的账单怎么读。
10 月 31 日限制新入口，全系列计划于年底前退役
假设一个团队已经用 K2 搭好了文档助手。看到“10 月 31 日”就立即停掉旧路径，可能把一次有准备期的迁移变成仓促切换；反过来，看到“既有用户不受影响”，就把新项目也继续押在 K2 上，同样误读了通知。
官方把两件事放在同一段，但适用范围不同：
| 时间 | 官方当前说明 | 对开发者的含义 |
|---|---|---|
| 2026 年 10 月 31 日起 | K2 系列不再对新注册用户提供，既有用户不受此项影响 | 新项目不应继续以新注册后可用 K2 为前提 |
| 2026 年 12 月底前 | 计划退役全部 K2 系列模型 | 既有应用也需要安排替代路径，不宜无限期拖延 |
“既有用户不受影响”描述的是第一项限制，不是永久保留 K2 的承诺。“计划退役”也应保留为计划，而不是改写成已经发生的关停。（Kimi API 定价说明：K2 系列迁移通知）
这段通知没有给出精确切换小时、时区或各种账号关系下的新老用户判定。若你的交付依赖新开账号继续调用 K2，应该向平台确认，而不是从日历日期自行推导。对已有应用，更有用的动作是利用准备期做验证，而非等到最后一刻再找替代模型。
K3.1 API 可用，不等于权重已能下载
K3.1 Pro 的官方公告列出了两个 API 模型名：kimi-k3.1-pro 与 kimi-k3.1-pro-highspeed。公告称它们已在 Kimi API 及相关产品渠道提供，同时承诺完整模型权重最迟于 2026 年 11 月 4 日发布。（Kimi K3.1 Pro：可用范围与完整权重计划）
这对应两种不同的迁移项目。调用托管 API，需要验证账号可用范围、应用行为和费用；改成自托管，还要等实际权重、对应许可与部署条件明确。API 现在能调用，不会自动让后一项也准备就绪。本篇现有材料没有核实权重承诺已经兑现，也不足以确定商用许可。
日期也不必为了凑一条新品时间线而强行统一。官方研究博客索引标注 10 月 24 日，而 Simon Willison 的独立 API 观察标注 10 月 23 日，并称当日已经通过 API 尝试。两者没有统一时区，公告正文也没有首发日期，因此这里不认定一个精确的北京时间首次上线日。对迁移者，当前可用路径与后续承诺更重要。
还有一个容易付错钱的岔口：Kimi API 按量计费，与 Kimi 会员、Kimi Code 是不同产品。在某个产品里能够选 K3.1，不代表你给 API 充过值，也不代表会员权益覆盖应用发出的调用。先确定自己要消费哪个渠道，再看那个渠道的价格和权限。（Kimi API 定价说明：按量计费与产品区别）
Highspeed 的缓存命中价没有翻倍
接入渠道确定之后，才值得比较速度档。
Kimi API 平台首页列出的基础费率如下，单位为美元／百万 tokens，官方定价说明注明不含适用税费：
| 计费项 | K3.1 Pro | K3.1 Pro Highspeed |
|---|---|---|
| 输入 | 2.00 | 4.00 |
| 输出 | 10.00 | 20.00 |
| 缓存写入：首页列价 | 2.00 | 4.00 |
| 缓存命中 | 0.20 | 0.20 |
来源为Kimi API 平台：K3.1 基础费率。缓存写入这一行只转述首页列价，不代表已经核全不同 TTL 的写入费率。
前三行看起来都是两倍，最后一行却相同。因此，“Highspeed 每项都贵一倍”不准确，“一个任务的总账单必然翻倍”也不能从这张表推出。若工作流反复使用相同前缀，命中部分与新写入部分的占比，会改变两档之间的实际费用差异。
速度也要读清对象。官方公告给出的 Highspeed 口径是约 2–3 倍速度；这是厂商描述，不是本站测量。一个需要联网搜索、运行工具、等待外部服务的 Agent 任务，整段完成时间还包含模型生成之外的步骤，不能直接承诺缩短到相同比例。
因此，先为需要低等待时间的任务保留试验入口，比仅凭“高速”两个字把全部流量切过去更稳妥。是否值得多付，应该看用户实际等待的时间，以及完成同一任务的总费用。
K3 默认缓存，让“只换模型名”的预算失真
缓存不只是一个可有可无的折扣项。Kimi 当前说明指出，K3 系列针对重复请求前缀自动启用上下文缓存计费，默认保留时间 TTL 为 5 分钟；缓存写入又按 5 分钟和 1 小时分别计费。命中输入只按命中价计费，不再额外收写入费。（Kimi API 定价说明：缓存与计费逻辑）
这意味着，不能把首页的一项写入单价套到所有保留时长，也不能只拿普通输入价乘整段提示词，就把结果称为完整预算。本篇没有完整的 TTL 费率表，因此不提供看似精确、实则漏项的单请求或月账单算例。
仍以文档助手为例：它可能每次带上相同的规则和文档前缀，再附加一个新问题。你要观察的不只是“这次输入多少 tokens”，还包括哪些部分命中、哪些需要写入、使用什么 TTL，以及两次请求之间隔了多久。换了目标模型之后，应重新观察这些读数，而不是把旧工作流的命中比例当成固定常数。
文件处理还有另一处容易混淆的“免费”。文档说明，文件提取和存储接口目前暂时免费；但如果把提取出的文档内容送给模型，它仍会作为输入按使用量计费。上传 PDF 没产生文件接口费用，不代表让模型读 PDF 也没有输入成本。
把这两层分开后，迁移验证才有意义：一边检查模型能否完成工作，一边记录实际输入、输出、缓存写入和命中。否则，同样是文档问答，测试时连续提问与生产中零散提问，可能根本不是同一种账单形状。
K2 迁移先跑一条真实工作流，再扩大切换
对已有 K2 应用，合理的第一步不是证明 K3.1 在所有任务上更强，而是选出一条你最在意的工作流，验证它能否接班。
可以先整理一组去敏样例：一段普通对话、一份长文档、一次工具调用，以及旧应用曾经处理失败的请求。保留旧路径的输出与耗时作为基线，再用目标模型比较答案质量、输出格式、工具参数和失败后的行为。这是迁移建议，不是本站已经完成的兼容测试；现有材料也不构成“只换模型名就全部兼容”的保证。
费用检查应跟着同一批任务走。不要只测一次空缓存请求，也不要只测连续重复的热缓存请求；分别观察与你的真实使用频率接近的情况。需要 Highspeed 的，再比较它有没有缩短用户真正感知的等待，而不是只比较厂商给出的生成速度。
确认关键任务可接受后，再考虑少量流量切换，并预先写清什么情况下停止扩大范围、回到仍可用的旧路径。回退机制服务于迁移准备期，不能代替寻找最终替代方案，更不能依赖 K2 永久存在。
到实际切换前，重新检查三个会变化的事实：K2 通知有没有更新，目标 API 与权重究竟处于什么状态，当前费率及所选 TTL 是否仍与预算一致。尤其是权重发布这件事，要等正式产物和许可来兑现，不能把一条未来承诺提前当成部署资产。
10 月 31 日不是老应用统一断服的闹钟，但年底退役计划已经足以让迁移进入日程。老用户应把这段时间用来测完一条真实路径；新项目则不应再以能长期接入 K2 为前提。先把渠道、行为和账单核清，比仓促改掉一个模型名更接近真正完成迁移。