Kimi 在 2026-10-23 17:15 UTC（北京时间 10 月 24 日凌晨）由官方账号发布 K3.1 系列的第一个模型 kimi-k3.1-pro，同时上线 2～3 倍速度的 kimi-k3.1-pro-highspeed。对已经在跑 kimi-k3 的团队来说，真正的问题不是模型跑分，而是：这次切换值不值得动生产环境的代码。
关键结论先说：K3.1 Pro 的单价低于上一代 K3，参数约束一致，只换 model 字段就能迁。但"该不该换"取决于你的请求是延迟敏感还是吞吐敏感、任务有多少落在官方给出的提升区间内、以及你能不能做一次可回滚的 A/B。
本文价格、参数与官方基准引自 Kimi 官方文档（检索 2026-10-26，页面最后更新 2026-10-23）与官方 X 发布帖；第三方数据引自 Artificial Analysis 模型页与几位博主的公开实测帖。三类来源在文中分开标注，不合并成同一个“强”字。
先固定比较维度
选型文章最容易犯的错是先看结论再看维度。这里先把维度摆出来，后面的数据只填进这些格子里。
| 维度 | 为什么影响决策 | 本文是否有可核验数据 |
|---|---|---|
| 输入/输出单价 | 直接决定单位任务成本 | 有，官方定价页 |
| 缓存命中与写入价格 | 长上下文 Agent 的主要成本项 | 有，官方定价页 |
| 参数约束差异 | 决定迁移是否要改代码 | 有，官方参数参考页 |
| 上下文窗口 | 决定能否单次塞入整库代码 | 有，官方模型列表 |
| 延迟与速度 | 决定交互式场景是否可用 | 只有官方对速度版的相对描述 |
| 能力提升区间 | 决定换模型能否解决现有失败任务 | 有，但为官方基准口径 |
| 回滚成本 | 决定试错是否可控 | 可推导，取决于是不是只改 model |
| 开源权重可自托管 | 决定内网部署是否可行 | 官方给出时间承诺，尚未到期 |
没有数据的两行必须留白，不能从其他型号的价格或跑分反推。
价格差在哪：K3.1 Pro 比 K3 更便宜
这是这次发布里最容易被忽略的一条。官方定价页给出的 K3 系列（上下文均 1,048,576 tokens）单价如下，单位为每 1 MTok：
| 模型 | 输入 | 输出 | 缓存命中 | 缓存写入 5m | 缓存写入 1h |
|---|---|---|---|---|---|
kimi-k3.1-pro | ¥13.00 | ¥68.00 | ¥1.30 | ¥13.00 | ¥26.00 |
kimi-k3.1-pro-highspeed | ¥26.00 | ¥136.00 | ¥1.30 | ¥26.00 | ¥52.00 |
kimi-k3 | ¥20.00 | ¥100.00 | ¥2.00 | ¥20.00 | ¥40.00 |
来源：模型推理价格说明，最后更新 2026-10-23。
读这张表要注意三点。
第一，K3.1 Pro 的输入价是 K3 的 65%，输出价是 68%，缓存命中价也从 ¥2.00 降到 ¥1.30。也就是说，在同等 token 用量下，换到 K3.1 Pro 是降价，而不是加价。这一点和"新一代旗舰一定更贵"的直觉相反。
第二，速度版不是"同价更快"。kimi-k3.1-pro-highspeed 的输入、输出、写入价格都是标准版的 2 倍左右（输入 26 vs 13，输出 136 vs 68），只把速度换来 2～3 倍。它不是省钱选项，是延迟选项。
第三，缓存写入是独立计费项，5m 和 1h 两档价格不同。K3 系列缓存命中价约为未命中价的 1/10，意味着长前缀场景下，缓存策略对账单的影响远大于单价的小幅差异。这部分单独展开。
国际站按美元计价，官方 X 发布帖与 OpenRouter 页面都写作输入 $2 / 输出 $10 每百万 tokens，速度版为双倍；Simon Willison 的发布笔记里给了一个横向坐标：这与 GPT-6.1 Sol 同价，约为 Claude Opus 5.5 的一半。两个平台的币种不同，不要拿人民币单价和美元单价直接比。
参数规模有两个口径
官方英文发布帖写的是 2.8T total / 104B active params（MoE），中文文档写的是“3 万亿级参数”。两个说法都是官方的，但不是同一个数字，引用时必须写明是哪一个。
| 来源 | 表述 | 性质 |
|---|---|---|
| 官方 X 发布帖（2026-10-23） | 2.8T 总参数 / 104B 激活参数，MoE | 具体数字 |
| 官方中文模型页与快速开始 | “3 万亿级参数”、K3.1 系列首个模型 | 量级定位 |
| Artificial Analysis 页面 | 标为 “Proprietary”，未列出参数量 | 未核验 |
实际影响不大：无论取 2.8T 还是“3 万亿级”，结论都是“本地部署不现实”。按 8-bit 估算，博主 @ziwenxu_ 的算法是约 6 台 512GB 的 Mac Studio，自建成本 $60K 起（原帖，2026-10-23）。
参数约束一致，迁移改动很小
官方参数参考页明确写着：kimi-k3.1-pro 和 kimi-k3.1-pro-highspeed 的参数约束与 kimi-k3 完全一致。这句话的实际含义是，把 model 从 kimi-k3 改成 kimi-k3.1-pro 之后，请求体不需要其它改动。
来源：模型参数参考，最后更新 2026-10-23。
| 参数 | 官方约束 | 迁移时该做什么 |
|---|---|---|
reasoning_effort | low / high / max，默认 max | 保持原值，但注意切档会破坏前缀缓存 |
thinking | K3 系列不适用 | 从 K2.x 迁移过来的代码要删掉这个字段 |
tool_choice | auto / none / required | 不用改 |
temperature | 固定 1.0，传其他值报错 | 不要显式传 |
top_p / n / 两个 penalty | 固定 0.95 / 1 / 0 | 不要显式传 |
max_completion_tokens | 默认 131072，最大 1048576 | 按任务需要显式设置上限 |
来源：Kimi K3.1 Pro 快速开始，最后更新 2026-10-23。
真正会咬人的地方不在参数表，而在两个隐性约束。
一是保留式思考。K3.1 Pro 始终进行推理，且保留式思考始终开启，多轮对话和工具调用必须把 API 返回的完整 assistant message 原样回传，包括 reasoning_content 和 tool_calls。如果代码里为了省 token 只保留 content，换模型后会直接拿不到连贯的推理链。
二是视觉输入不支持公网图片 URL，必须用 base64 或 ms://<file-id>，且 content 必须是对象数组而不是序列化字符串。这条在 K3 上已经存在，但迁移时如果顺手重写了消息构造函数，很容易退回字符串拼接。
一次编程会话的成本实算
抽象单价不如一次真实请求。假设一个编程 Agent 会话的典型请求是：输入 200k tokens（其中 180k 是代码库等稳定前缀、20k 是每轮变化的提问与工具结果），输出 5k tokens，稳定前缀能命中缓存。
按官方单价计算单次请求成本：
| 计费项 | K3.1 Pro | K3 |
|---|---|---|
| 未命中输入 20k | 20,000 × 13 ÷ 1e6 = 0.26 元 | 20,000 × 20 ÷ 1e6 = 0.40 元 |
| 命中输入 180k | 180,000 × 1.30 ÷ 1e6 = 0.234 元 | 180,000 × 2.00 ÷ 1e6 = 0.36 元 |
| 输出 5k | 5,000 × 68 ÷ 1e6 = 0.34 元 | 5,000 × 100 ÷ 1e6 = 0.50 元 |
| 合计 | 约 0.83 元 | 约 1.26 元 |
折算下来 K3.1 Pro 约为 K3 的 66%。另外每次前缀首次写入缓存还有一次写入费：K3.1 Pro 是 200k × 13 ÷ 1e6 ≈ 2.6 元，K3 是 200k × 20 ÷ 1e6 = 4.0 元。写入费只在缓存过期后重新发生，不随请求次数线性增长，会话越长摊得越薄。
这个算例只说明按官方单价推算的相对关系，不代表你的实际账单。真实成本还取决于缓存命中率、思考 token 占比和重试次数。
还有一个容易被忽略的变量：输出变长了。Artificial Analysis 测得 K3.1 Pro 完成 Intelligence Index 任务时输出 token 比 K3 多 14%（55K vs 48K），模型页给出的 Intelligence Index 总输出量为 150M（同组中位数 87M），并直接描述它“明显偏慢、输出冗长”；速度 57.5 tokens/s，低于同价位中位数的 82（模型页，检索 2026-10-26）。单价降了、token 多了，两个方向会部分抵消，该看的是“每任务成本”而不是“每百万 token 价格”：AA 算出的数字是 $2.11 / 任务。
官方基准该怎么读
官方给出的能力提升集中在代码、3D 创作、金融研究和长程 Agent 上。以下数字均引自官方模型页，属于厂商自测口径：
| 基准 | K3.1 Pro | 对照 | 说明 |
|---|---|---|---|
| Terminal-Bench 4.0 | 65.7% | GPT-6 Astra 58.2%，Claude Opus 5.5 66.4% | 真实环境终端任务 |
| Kimi Code Bench 3.0 Long-horizon | 61.2% | K3 55.95% | 官方内部基准 |
| Office QA Pro v2 / SpreadsheetBench 2 | 官方称最佳 | 对比 Opus 5.5、Fable 5.1、GPT 6 Astra | 第三方外部基准 |
| 单项事实陈述错误率 | 6.85% | K3 23.35% | 去标识化对话压力测试 |
| 含至少一处事实错误的回答比例 | 前代的约 46.4% | — | 同上 |
| Business Operation | 37.0 | 约为 K3 的 4.2 倍 | 官方内部模拟经营基准 |
来源：Kimi K3.1 Pro 模型介绍，最后更新 2026-10-23。
三条阅读规则。
第一，外部基准（Terminal-Bench、Office QA Pro、SpreadsheetBench）可以横向对比，但要看对照组选的是哪几个模型、什么版本、什么日期。官方把 K3.1 Pro 描述为"达到或接近最强闭源模型的水平"，这是相对描述，不是排名。
第二，内部基准（Kimi Code Bench、Business Operation）只能证明相对上一代有提升，无法复现，也不能用来比较其他厂商。
第三，幻觉那组数字官方自己加了限定：样本刻意聚焦模型容易出错的情形，所报告的错误率不代表日常使用中的整体水平。绝对值不能当真，方向可以看——错误率从 23.35% 降到 6.85%，幅度不小。
第四条规则最重要：厂商自测不能替第三方评测。同一个模型，在两个独立来源里会给出不同的数：
| 来源 | 性质 | 关键数字 |
|---|---|---|
| 官方模型页 | 厂商自测，部分题目集不公开 | Terminal-Bench 4.0 65.7%，内部基准 +7.2/+11.6 分 |
| Artificial Analysis | 第三方独立跑测，方法公开（Index v4.3.2 含 10 项评测） | Intelligence Index 55，第 4/215；比 K3 高 11 分 |
来源：Artificial Analysis 模型页，检索 2026-10-26。
更值得看的是个体实测里的反例。博主 @PawelHuryn 用两个真实仓库、105 个重新植入的 bug 做“找到并修复”测试，K3.1 Pro 得分 36，低于 DeepSeek V4.1 Flash 1017（42.7）、Muse Wonder（42）和 Opus 5.5（41.7），只高于 Muse Spark（32.2）（原帖，2026-10-23）。另一位博主 @notjazii 用同一 prompt 对比长任务生成，结果相近，但 K3.1 Pro 花了约 25 分钟 / $1.50，GPT-6.1 Sol 约 17 分钟 / $0.70（原帖，2026-10-24）。
这两条帖子的价值不在于推翻官方基准，而在于提醒：基准提升是“平均能力”，你的任务可能恰好落在没提升甚至变差的那一类。三层数据的读法在单独一篇里展开。
什么条件下不该换
有四种情况，现在换过去并不划算。
延迟敏感且任务简单。 短问答、格式转换、分类打标这类请求，max 推理强度会带来不必要的思考开销。先把 reasoning_effort 调到 low 再评估，而不是直接上速度版——速度版价格是标准版的 2 倍。
预算极紧且任务不需要旗舰能力。 kimi-k2.7-code 是输入 ¥6.50、输出 ¥27.00、缓存命中 ¥1.30；kimi-k2.6 是 ¥6.50 / ¥27.00 / ¥1.10。如果现有 K3 用量大部分是模板化任务，先考虑降到 K2.7 Code，而不是升级。
需要内网自托管。 官方写明完整模型权重将于 11 月 4 日前发布，也就是本文写作时还不能自己部署。K3 的权重已开放，合规要求必须自建推理的团队，迁移窗口还没到。
还在 K2 系列上。 官方公告 K2 系列从 2026-10-31 起停止向新注册用户开放，并计划 12 月底下线全部 K2 系列模型。这批调用该规划迁移，但目标不一定是 K3.1 Pro——先按任务分层，简单任务去 K2.7 Code，复杂任务去 K3.1 Pro。
迁移步骤：先校验身份，再 A/B，最后放量
按下面的顺序做，出问题可以随时停。
第一步，确认模型 ID。不要凭博客或群消息拼写，直接用平台的模型列表接口取当前可用 ID，记录返回结果和时间。
响应里应能看到 kimi-k3.1-pro。这一步同时验证了端点与 Key 是否匹配——中国站和国际站的 Key 不通用，混用会返回 401。
第二步，准备任务集。从线上真实请求里抽样 30～50 条，覆盖你认为最容易失败的场景（长上下文检索、多步工具调用、结构化输出、视觉输入）。同一批请求分别跑 kimi-k3 和 kimi-k3.1-pro，其余参数完全一致。
第三步，逐条记录指标，而不是只看"感觉更好了"。
| 指标 | 记录方式 | 用途 |
|---|---|---|
| 任务通过率 | 人工或脚本判定每条是否达标 | 判断能力是否真的提升 |
usage 三段拆分 | 未命中 / 命中 / 写入 tokens | 换算实际单价 |
| 思考 token 占比 | reasoning_content 长度 | 判断延迟与成本来源 |
| 首 token 延迟 | 调用侧计时 | 判断交互体验 |
| 重试与错误码分布 | 401 / 404 / 429 / 500 计数 | 判断入口是否稳定 |
| 人工修订量 | 每条改动的字符数 | 判断是否真的省人力 |
第四步，灰度放量。把 model 做成配置项或环境变量，而不是硬编码在代码里。放量节奏建议先内部工具、再非关键业务、最后核心链路，每一档至少观察一个完整业务周期。
第五步，保留回滚开关。回滚的前提是缓存策略也一起回滚：5m 和 1h 两档缓存互不通用，TTL 在首次写入时锁定，改档位要等旧条目完全过期才会生效。回滚时账单上的缓存写入费用会重新发生一次，这部分要有预期。
用聚合网关调用时的额外检查
如果业务不止 Kimi 一个模型，常见做法是通过聚合网关统一端点。这时除了模型 ID，还要单独验证三件事，因为网关可能只做了协议转发而没有对齐字段。
| 检查项 | 最小验证方法 |
|---|---|
| 模型身份 | 响应体中的模型字段是否与请求一致 |
usage 明细 | prompt_tokens_details.cached_tokens 与 cache_write_tokens 是否返回 |
| 保留式思考 | 多轮工具调用是否要求回传 reasoning_content，网关是否透传 |
以可替换实例来说，若通过 4SAPI 这类统一入口调用，模型名、参数直通范围和 usage 字段以该平台控制台当期显示为准；上述三项验证在任何入口都需要单独做一遍，不能用纯文本聊天成功来代替。
限制与结论
K3.1 Pro 在 API 层面的三个确定事实是：单价低于 K3，参数约束与 K3 一致，上下文仍是 1M。这三点让它成为一个迁移风险较低、且方向是降本的选项。
不确定的部分也很清楚：官方基准是厂商自测，内部基准无法复现；速度版只有相对描述（2～3 倍），没有公开的绝对吞吐数字；权重尚未发布，自托管路线暂时不可行；联网搜索工具官方标注"正在更新，近期不建议用于生产流程"，依赖实时搜索的业务不能指望它。
如果要给一个条件化结论：以长程编程、多步 Agent、金融与表格类任务为主，且已经能稳定维护多轮上下文历史的团队，值得用自己抽样的任务集做一次 A/B；以短问答和高并发为主的团队，先把 reasoning_effort 降档再评估，或者继续留在 K2.7 Code 更省钱。
下一步的技术验证建议只有一条：把上面那张指标表跑完，用自己业务里的通过率和单价回答"该不该换"，而不是用公开跑分。
