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