Kimi K3.1 Pro：Serafim Batzoglou 对归纳基准与 Token 成本的观点

一句话结论

作者依据 Challenge100 截图称，Kimi K3.1 Pro 以 21/100 追平 Claude Opus 5、领先 Qwen 3.8 Max 和 Muse Spark 1.3，但落后 GPT-5.6 Sol、GPT-6.1 Sol 与 Claude Opus 5.5；他还认为 Kimi 的 Token 使用量使其比 GPT-6.1 Sol 更贵。帖子与 GitHub 页面提供了榜单和部分协议说明，但没有公开逐题原始输出、完整复现实验包或价格账单，因此不能把这条信息改称为已复现的作者独立 benchmark，也不能当作保证性排名。

适用场景

• 适合判断的任务：了解 Kimi K3.1 Pro 在该 Challenge100 归纳任务快照中的位置，以及 Token 量、上限和失败计费如何影响跨模型比较。

• 不适合外推的任务：推断通用推理、编码、Agent 或所有生产任务的固定排名；据此计算确定的模型单次成本。

• 适用的模型版本：Kimi K3.1 Pro；GitHub 结果页记录的模型 ID 为 kimi-k3.1-pro。

• 测试环境或客户端：GitHub 结果页记录为直接调用 Moonshot kimi-k3.1-pro；客户端、完整请求载荷和服务区域未公开。

• 推理档位和参数：reasoning_effort=max，max_completion_tokens=500000（含 thinking）；其他采样与完整请求参数未注明。

测评方法

X 主帖展示了一张 Challenge100 表格，并用归纳基准的 holdout 分数做排序。帖子正文没有解释题目、提示词、判分脚本、请求次数或价格口径，只附了一个 GitHub 链接。

链接页面 leaderboard.md 说明：Challenge100 是冻结的 Challenge64 与互斥 New36 的有序并集；holdout 使用每题五个 worlds；缺失、供应商错误、空响应、输出上限未完成和解析无效都计为错误。表格按 Holdout Correct %、Train Correct、Evaluable coverage 和模型名排序。

链接的 Kimi 结果页 进一步自述：100 个原始请求之外有 38 次传输重试；实际有 138 个物理请求，100 个确认终态和 38 个远端完成状态未知的中断原请求。十个 pilot task 使用 seed 20261023，其余为精确的 90 题补集；没有工具、前序响应、采样覆盖或自动 HTTP 重试。

这些是链接页面的自述和统计口径，本文没有独立运行请求、审计远端记录或复核每道题。因此不能据此声称作者已经完成可公开复现的独立 benchmark。

关键结果

X 截图中的 Challenge100 相关行如下。输出 Token 单位为百万，—* 表示截图没有报告数值。

按这张表，Kimi K3.1 Pro 与 Claude Opus 5 的 holdout 分数相同；Kimi 的 Train Correct 更高，但 Evaluable 略高，不能据此说 Kimi 在所有任务上胜过 Opus 5。Kimi 是截图中列出的开源权重模型里分数最高者这一表内观察，也不等于所有开源权重模型的普遍排名。

原始数据

主帖原文的核心判断是：Kimi K3.1 Pro 在 induction benchmark 上与 Opus 5 持平或超过，明显领先 Qwen 3.8 Max 和 Muse Spark 1.3；但仍明显低于 GPT-5.6 Sol，更低于 GPT-6.1 Sol 与 Opus 5.5，因此尚未达到 frontier，并且按其 Token 使用量比 GPT-6.1 Sol 更贵。

可见回复中，AI Quanting 指出 Astra 在 2.0M 输出 Token 上排名第一，Opus 5.5 在 50.6M 上排名第三，并询问 Challenge100 是否有 Token 上限。作者回答称，Astra（OpenAI 整体）把 Token 限制在 128k，Kimi 把它限制在 1M；多数模型在这些问题中会耗尽 Token，OpenAI 不收费，而 Anthropic 会对失败收费，因此失败 Token 会计入总量。

这段 128k 对 1M 是作者在 X 回复中的上限口径，帖子没有定义它对应上下文、输出还是服务端总预算。GitHub Kimi 结果页另记录 max_completion_tokens=500000，两者不能混写成同一个参数。

GitHub 结果页给出的 Kimi 已知用量为：594,862 input tokens、11,539,644 completion tokens，共 12,134,506；completion 已包含 11,530,392 reasoning tokens 和 9,252 visible tokens，不能把 reasoning 再加一次。另有 79,616 个缓存输入 Token，但 76 个请求的缓存使用量未知；38 个中断原请求的输入和 completion usage 未知。页面明确写着 pricing and billing are unknown，不能当作零费用或账单估算。

GitHub 的 Token JSON 将 Kimi output_tokens 记录为 11,539,644、physical_attempts 为 138、未报告响应下界为 38。其他模型的截图 Token 量同样只是输出量，不能直接转换为费用：价格、缓存折扣、失败重试、套餐额度和供应商结算规则没有统一披露。

结论与边界

• 该 X 帖子可作为 2026-10-24 的社区观点快照：在截图所示 Challenge100 表中，Kimi K3.1 Pro 为 21/100，和 Opus 5 并列，低于 GPT-5.6 Sol、GPT-6.1 Sol 与 Opus 5.5。

• 11.5M 输出 Token 高于 Astra 的 2.0M、GPT-6.1 Sol 的 4.1M 和 Muse Spark 1.3 的 4.7M，低于 Opus 5.5 的 50.6M、Opus 5 的 27.1M；Token 量不能单独决定费用或质量。

• 作者“比 GPT-6.1 Sol 更贵”是观点，不是公开账单比较。GitHub 页面明确把 Kimi 的 pricing and billing 标为 unknown。

• 失败计费的 128k/1M 说法来自作者回复，未给出供应商账单或请求级证明。Kimi 的 38 个中断原请求存在远端完成状态未知，不能假设已取消、未计费或必然计费。

• GitHub 页面写有“completed, independently audited campaign”，但公开页面没有逐题原始响应、完整 prompt、远端请求日志和审计材料。本文只转述其自述，不把榜单升级为本文已验证的作者独立 benchmark，也不把排序当成保证性排名。

• Challenge100 的五个 holdout worlds、题目组成、重试和计数规则会影响结果；不同模型的上限、失败处理和可报告 Token 范围也不同，不能简单用输出量做跨供应商性价比排序。

复现说明

若要复现这条观点，应固定 Challenge100 的 Challenge64/New36 版本、五个 holdout worlds、原始 prompt、JSON contract、模型 ID、reasoning_effort、completion cap、超时、并发、重试和选择规则；每个请求保存输入、输出、thinking 是否计入、终态、失败原因和账单状态。

费用应按统一口径计算：

总成本 = 未命中缓存的输入 Token × 输入单价
       + 输出 Token × 输出单价
       + 缓存命中 Token × 缓存单价
       + 已确认失败/重试请求费用

单价应统一换算为每 token 价格；如供应商另收缓存写入费，也须计入，避免缓存输入重复计费。

对 38 个远端完成状态未知的中断请求，应分别记录“未知”，不能补成 0。只有拿到供应商请求级账单、完整原始输出和可复核的 benchmark 工件后，才能讨论成本排名或重复运行稳定性。