Kimi K3.1 Pro 对比 Kimi K3.1：一个是模型，另一个是系列名称

如果你正试图在Kimi K3.1 Pro和Kimi K3.1之间做出选择，首先有用的事实是：它们中只有一个以你可以调用的形式存在。Moonshot AI 的 K3 系列费率表有三行：kimi-k3.1-pro、kimi-k3.1-pro-highspeed 和 kimi-k3。没有单独的 kimi-k3.1 行，没有它的模型卡，也没有任何端点会响应这个名字。“K3.1”是 2026 年 10 月 24 日发布版本所属的系列。“Pro”是其中的模型。

这听起来像是命名上的吹毛求疵，直到你就是那个把“kimi-k3.1”写进配置文件的人。那时它就变成了一个 404、一次失败的 eval 运行，或者某条需要有人解释的发票明细。这种混乱不是读者的错：Moonshot 在自己的预热视频中就使用了这个裸名称，而自 10 月 23 日预告发布以来，第三方报道在区分二者时一直不够严谨。所以这次比较实际上是一个问题包含两层——这个名字是什么意思，以及两个可调用的 K3.1 端点中你究竟该选哪一个。

“裸”的“K3.1”名称从何而来

Moonshot 本身就埋下了歧义。其 24 秒预告片显示，一个 Kimi Code 终端上写着“Model: Kimi K3.1”，而不是“Kimi K3.1 Pro”。大约同一时间，中国科技媒体报道的一笔 SGLang 提交新增了“Kimi-K3.1 support for the K3 chat encoder”，并引用了一个名为 moonshotai/Kimi-K3.1 的 Hugging Face 仓库。这个版本号也出现在 Kimi Work 的桌面应用中，版本为 3.1.0。模型标签、仓库名称和产品版本这三样不同的东西，在公众视野中都坍缩成了同一个字符串。

发布文章解决了其中一部分问题。Moonshot 将 Kimi K3.1 Pro 描述为其全新 K3.1 系列中的首个模型，而 API 文档恰好列出了两个标识符。仓库名称仍是唯一尚未确定的部分，可能会在 2026 年 11 月 4 日前权重发布时敲定。如果此次发布以 Kimi-K3.1 之名发布，那么“K3.1”将是开放权重产物，而“K3.1 Pro”则是基于它构建的托管 API 产品。这是一种自洽的划分，但它并不是你今天就能调用的第二个模型。

所以，对于“Kimi K3.1 Pro 和 Kimi K3.1 有什么区别”这个问题，答案是：在端点层面没有区别，因为两者中有一个根本没有端点。在系列层面，Pro 才是实际实现。如果未来出现非 Pro 的 K3.1，它得先在费率卡上拥有自己的一行，然后才谈得上需要一篇对比文章。

确实存在的对比：Pro 与 Pro Highspeed 的对比

一旦你接受“K3.1”只是一个标签、而非一个竞争对手，产品线中真正的分岔就显现出来了。Moonshot 在同一天发布了两款可调用的变体，而它们其实是同一个模型处于两个不同工作点的产物。

• 价格 — Kimi K3.1 Pro 的输入价格为每百万 token 2.00 美元，输出价格为每百万 token 10.00 美元；Kimi K3.1 Pro Highspeed 则为 4.00 美元和 20.00 美元。两者的缓存命中输入价格均为 0.20 美元。

• 缓存写入 — 在 Pro 上，五分钟 TTL 为 $2.00，一小时 TTL 为 $4.00；在 Highspeed 上分别为 $4.00 和 $8.00。

• 速度 — Moonshot 表示，Highspeed 的产出速度快两到三倍。它使用相同的权重和相同的质量目标，其服务优化侧重延迟而非吞吐经济性。

• 配额 — 在 Kimi Code 中，Highspeed 档位完成同样的工作大约消耗两倍的配额，这正是订阅侧对 token 价格翻倍的对应体现。

• 上下文与能力——两者均具备 1,048,576 token 的窗口、原生图像与视频输入、工具调用、结构化输出，以及始终开启、支持低、高、最高三档推理强度的推理能力。两者之间不存在能力分级。

• 最适合 — Highspeed 适用于有人等待的交互式编码和智能体循环；标准 Pro 适用于批量生成、长文档处理，以及输出由另一进程消费的任何场景。

因此，决策规则关乎的是等待，而不是智能。如果两到三倍的加速能消除人的空闲等待循环，那么翻倍的价格就容易证明合理。如果它只是缩短一个通宵运行的批处理作业，那你就是在为本来不会感受到的延迟付两倍的钱。

API 实际接受的内容

标识符问题很重要，因为该 API 的严格之处很容易被忽略。Kimi K3.1 Pro 始终会进行推理——没有关闭思考的开关——而 reasoning_effort 接受 low、high 或 max，默认值为 max。采样固定为 temperature 1.0 和 top_p 0.95，惩罚项为零；传入其他值会返回错误，而不是被静默钳制。最大补全 token 数默认为 131,072，可提高到 1,048,576。

这会带来两个运行层面的后果。第一，一个会调节温度的评测框架在这个模型上会失败，而不是产生略微不同的分数。第二，在对话中途更改推理投入会使前缀缓存命中失效，因此探索不同投入级别的成本高于 token 价格所暗示的水平。这两项约束同样适用于 Highspeed 变体。

访问权限还以容易让团队措手不及的方式受到限制：API 要求账户达到最低充值额度，且新用户优惠券不适用。企业管理员必须启用该模型，因为发布时访问权限默认关闭。对于旗舰级发布来说，这些都不算异常，但正是这类细节，会让原本十五分钟就能完成的集成变成一张支持工单。

为什么这个名字会不断带来麻烦

模型家族通常是在事后才形成一套清晰的命名惯例。K3.1 系列却以相反的顺序开始：一则预告把家族名当作模型名，一个代码仓库把它当作制品名，而 API 把它当作命名空间。搜索“Kimi K3.1”的读者会不断落到要么把它当作一个模型、要么声称它不存在的页面上。这两种说法都不完整。它作为一个家族存在，而 Pro 是其中的成员。

实际检验很简单，而且适用范围不止于这次发布。一个模型要算真实存在，需要三件事同时吻合：价目表中带价格的一行、有文档记录的模型标识符，以及模型卡或权重仓库。Kimi K3.1 Pro 现在已有前两项，第三项承诺在11月4日前提供。未加 Pro 的 Kimi K3.1 只有一个仓库名称和一个预告标签，这并不等同。等权重发布后，要检查该仓库究竟是以更短名称发布的 Pro 产物，还是真正不同的检查点。这一区别对任何计划自托管的人都很重要。

对名称保持谨慎还有第二个原因：它们会传播。一个从论坛帖子复制到路由器配置、成本仪表盘或合规清单中的模型字符串，其存续时间可能比最初造成这一混淆的情况还要长。如果某个名称无法解析为有文档记录的标识符，正确的做法是让部署失败，而不是去猜测最接近的匹配项。

绕过无法解析的名称进行路由

这正是 OrcaRouter 所要解决的问题类型，尽管并非营销通常所描述的那样。一个 API 覆盖 200 多个模型确实很方便；而明确、可解析的模型标识符才是让生产环境保持可信的关键。我们的目录列出的是实际可调用的模型，目前包括kimi/kimi-k3，以 Moonshot 的标价、0% 加价提供。截至撰写本文时，Kimi K3.1 Pro 尚未列入目录，我们宁愿明确说明这一点，也不愿让搜索结果暗示相反的情况。

路由层真正体现价值的地方在于过渡环节。路由 DSL 让你能在一处表达主模型与备选模型，而自动故障转移意味着供应商侧的中断或已弃用的标识符不会连带拖垮整个应用。当 K3.1 系列真正上架目录时，改动只是该策略中的一个字符串——而不是新的 SDK、新的密钥，或另一段计费关系。这个说法比“我们拥有所有模型”要低调，但它是经得起审计的那一个。

10月24日该做什么

如果你想要 Kimi K3.1 Pro，请调用 kimi-k3.1-pro。如果你希望速度更快，并愿意为降低延迟支付双倍费用，请调用 kimi-k3.1-pro-highspeed。如果你的配置中有 kimi-k3.1，请将其替换掉——不存在这个模型，最接近的真实模型是 Pro 标识符。

唯一悬而未决的问题是，11月4日的权重发布将叫什么名字。在该仓库公开之前，“Kimi K3.1”仍然只是一个附带预告的家族名称，而它和 Kimi K3.1 Pro 之间的比较，也只是标签与产品之间的比较。这个答案不如一份规格表那样令人满意，但它是准确的，而且现在就据此行动，比日后在生产环境中才发现要划算。