Kimi K3.1 Pro 上线：API 账单怎么算，要不要等开放权重

🇺🇸
Read in English: Kimi K3.1 Pro and the Bill Nobody Wants to Recalculate

设想一个做跨境店铺工具的三人小团队。深夜十一点多，后端同事屏幕上开着两个窗口，一个是日志，一个是上个月的云账单。账单这件事他们讨论过不止一次：调用量涨了三成，费用涨了快一倍，客户没多几个。有人提议换模型，评估下来要改的地方太多，结论是先拖着。这是一个设想的场景，不是真实案例，但不少小团队的处境大概就是这样。

拖到 10 月 23 日，Moonshot 把 Kimi K3.1 Pro 放上了 Kimi API，前代是 Kimi K3。Simon Willison 在当天的 link blog 里记了一笔（simonwillison.net），指向的原始公告在 Kimi 官方博客。公告里有一句话需要单独拿出来看：完整模型权重会在 2026 年 11 月 4 日之前发布。这是承诺，眼下权重还没有放出来。

如果这个团队在群里看到这条消息，第一反应多半是把计价页翻到最下面，按自己的流量重算一遍。下面就是这笔账的算法。

两美元的输入，十美元的输出

标准版的价格是输入每百万 token 两美元，输出每百万 token 十美元。另有一个 Highspeed 版本，速度快两到三倍，价格是标准版的两倍；输入 token 里缓存命中的那部分，价格不变。

Simon Willison 给的参照很直接：这个价格和 GPT-6.1 Sol 相同，是 Claude Opus 5.5 的一半。按一半倒推，Opus 5.5 大概是输入四美元、输出二十美元。把这两个数摆在一起，原本抽象的讨论就落地了：同样的工作量，一边花一份钱，另一边要花两份。

单价只是第一层。真正该看的是自己账单的结构。多数产品的 token 消耗并不均匀，少数长上下文请求吃掉大头，大量短请求花不了几个钱。输出价格是输入的五倍，所以输出占比决定了换模型能省多少。一个以短问答为主的产品，输入占九成，价格砍半的感受不会太强烈；一个以长文生成为主的产品，输出占大头，差价会直接印在月底的账单上。

对做内容生成、代码补全、批量翻译这类输出密集的业务，一半的价差能改变产品定价。对只做分类和抽取的业务，省下来的钱，可能还不够一次重测的人力。判断自己属于哪一类，不用猜，把上个月的用量明细导出来，按输入和输出分开加总，十分钟就有答案。很多团队直到被账单咬了一口，才发现自己一直以为的用量结构和实际差得很远。

账单不是单价乘数量

Highspeed 那档需要单独说一句。价格翻倍，但缓存命中的输入部分不变。如果产品里有很长的系统提示词、固定的知识库前缀，每次请求都能命中缓存，实际涨幅会明显低于两倍。反过来，如果每次请求都是全新的长文本，缓存基本不命中，翻倍就是实打实的翻倍。买之前先看自己的缓存命中率，比看跑分有用。

推理档位是另一个开关。K3.1 Pro 支持 low、medium、max 三档，档位越高，模型想得越久，写出来的中间步骤越多，输出 token 跟着涨，账单也就跟着涨。同一个问题用 low 和 max 各跑一遍，人工返工率差多少，值不值这个差价，只有自己的数据能回答。常见的错误是一上来全量开 max，觉得分数高就该用最高档，结果成本比预期高出一截，还找不到原因。

把量放大之后，单价的意义会更清楚。假设一个团队每月消耗十亿输入 token、一亿输出 token，按标准价是输入两千美元、输出一千美元，合计三千美元。同类工作量放在 Opus 5.5 上，按倒推的价格是六千美元。一年差三万六。对一个小团队，这笔钱够招一个兼职，也够把某个功能重做一遍。但前提是输出质量掉得不多，否则省下来的钱会以返工和退款的形式还回去。

还有一笔账不在计价页上：迁移本身的工程成本。换模型要重跑评测集，要调提示词，要处理输出格式的细微差异，要盯着上线后一周的异常。这些人力不会出现在账单里，但它们真实存在。便宜一半是账面数字，能不能落袋，取决于迁移有多轻。

榜单上的 55 分

第三方评测机构 Artificial Analysis 给 K3.1 Pro 的分数是 55。同一张表上，Claude Fable 5.1、GPT-6 Astra、Gemini 4 Argon 都是 53，Claude Opus 5.5 是 58。

Moonshot 自己的基准显示，K3.1 Pro 与 Opus 5.5、GPT-6 Astra 大致持平，个别项目领先，个别项目接近。厂商自测和第三方测是两套东西，方向一致时可以参考，冲突时要多留个心眼。自测的题目是自己挑的，第三方至少题目不是自己挑的。

Simon Willison 的评价是，这是（即将）开放权重的模型第一次在前沿对比里拿到这么高的分数。这句话的重点不在 55，在第一次。过去前沿名单和开放权重名单基本是两张表，现在有人把两张表叠在了一起，虽然还差着一名。

差一名是多少？五十八和五十五差三分。三分在这个区间不能算误差，但也不足以支撑全面超越的说法。五十三那一档三个模型挤在一起，说明这一梯队的水平已经靠得很近，谁高谁低很看题目。真实业务里的差别通常不在平均分，而在某一类任务上：中文长文改写、结构化抽取、多轮工具调用，各家强弱不一样。拿自己的二十条真实请求跑一遍，比看十张榜单都准。

还有一个容易被忽略的变量：榜单测的是哪个推理档位。同一模型在 low 和 max 下的表现可能差出一截，成本也差出一截。看到分数先问一句这是哪一档跑出来的，很多争论会立刻变得具体。

11 月 4 日这个日期

从上线到承诺的发布日期，中间是十二天。十二天在模型行业不算长，但足够发生很多事：延期、改成分批发布、先放一个小尺寸版本。这些可能性公告里没写，也不该替它写。

开放权重的意义是具体的。权重能下载，就能自己部署，能审计，能在 API 涨价或者下线的时候有条退路，能把模型放进不能出网的内部系统。对做产品的团队，这些不是情怀，是风险条款。过去几年，被 API 变更打乱排期的团队不少，权重在手，至少多一个选项。

但承诺和交付之间隔着一整套工程。权重放出来，许可证怎么写还不知道，商用允许到什么程度、有没有附加限制，这些决定了它能不能真的进产品。硬件也是门槛：一个前沿尺寸的模型，权重是一回事，跑得动是另一回事，量化之后效果掉多少又要重新测。社区把推理跑通、把工具链接好、把各种微调版本放出来，通常还要一段时间。

所以 11 月 4 日更适合当成一个观察点，不是一个排期。到那天去看三件事：权重是否真的可下载，许可证是否允许商用，社区有没有在常见硬件上跑通的报告。三件都成立，再谈自托管。三件缺一件，就继续用 API，把省下来的精力放在产品上。

还有一个常被混着说的点：开放权重不等于开源。权重是训练完之后的那堆参数，训练数据、训练代码、数据配比通常不会一起放出来。对只想自己部署的使用者，权重够用；对想复现训练过程、做合规审计的人，不够。这两件事在讨论里经常被压成一句“开源模型”，落到合同和采购上，差别不小。

现在能做的事，和先别做的事

K3.1 Pro 已经可以通过 OpenAI 兼容端点调用，地址是 api.moonshot.ai/v1，模型名 kimi-k3.1-pro，推理档位分 low、medium、max 三档。兼容端点这件事的实际价值在切换成本：如果代码里用的是标准 OpenAI 客户端，改一个 base_url 和一个模型名就能跑，调用层不用重写。这也是为什么价格出来之后，很多团队的第一个动作不是迁移，是拿一个测试 key 跑影子流量。

影子流量的做法不复杂。把真实请求复制一份发给新模型，不返回给用户，只记录输出和耗时，再用原来的评测集或者人工抽查比对。跑一周到两周，看三个数：错误率、人工返工率、每千次请求的成本。三个数都过得去，再切百分之十的真实流量。这个顺序看起来慢，实际上比切过去再回滚快。

评测集最好提前攒。从线上日志里挑几十条有代表性的请求，覆盖常见的输入长度和任务类型，把当前模型的输出和人工判定的好坏存下来。有了这份底子，换任何模型都是跑一遍的事；没有这份底子，每次换模型都得靠感觉，感觉通常不准。

有几件事现在做不合适。

一是不要因为单价便宜就把全量流量切过去。新模型上线头两周，限流、稳定性、长上下文表现都还在被人摸。先切一小部分，出问题也好收。

二是不要把产品架构押在一个还没发布的权重上。开放权重是加分项，不是排期依据。真到了 11 月 4 日权重没来，或者许可证不合用，产品不能因此停摆。

三是不要为了三分的差距重写提示词库。榜单差三分，落到具体任务上可能什么都不差，改写一遍的成本倒是实打实的。等真实测试结果出来再动。

四是不要看到便宜一半就忘了算工程成本。换模型要重测输出质量、要调提示词、要改评测集，这些人力账单不会出现在计价页上。省下来的 API 费用能不能覆盖这部分，取决于产品对输出质量的敏感度。

回到开头设想的那个团队，比较稳妥的做法是：先开一个测试账号，把最贵的那条链路切十分之一过去，比如商品描述生成，跑两周，只看账单和人工返工率两个数。权重的事等到 11 月 4 日再说，来了算意外之喜，没来也不影响已经跑起来的那部分。

先看自己的账单，再看榜单。对小团队来说，顺序大概就该是这样。