Kimi K3.1 Pro 选型：1M 上下文和每任务成本怎么算
原文：Artificial Analysis - 《Kimi K3.1 Pro launches at 4th on the Intelligence Index and will lead open weights models》（https://artificialanalysis.ai/articles/kimi-k3-1-pro-launch-benchmarks）
一、先把能核实的数字摊开
Moonshot 在 10 月 23 日发了 K3.1 系列的第一个模型 Kimi K3.1 Pro，同一天 Artificial Analysis 放出了完整评测。选型时最怕的是拿一条"排名第 4"就下单，所以我先把可核实的数字列出来，并标清口径。
| 项目 | 数值 | 口径 |
|---|---|---|
| 智能指数 | 55 分，第 4 | Artificial Analysis Intelligence Index |
| 与上代差距 | K3 为 44 分，提升 11 分 | 同上 |
| 领先者 | Claude Opus 5.5 58、Claude Sonnet 5.5 56、Muse Wonder Full 56 | 同上，后两者为 max with fallback |
| 上下文 | 100 万 token | 官方博客 |
| 参数 | 2.8T 总量、104B 激活 | AA 模型页口径；官方博客表述为"3T 级"开放权重模型，两个口径并存 |
| 输入模态 | 文本 + 图像 | AA |
| 定价 | 每百万 token 输入 2 美元、输出 10 美元、缓存命中 0.20 美元 | AA，三项均比 K3 低 33% |
| 权重 | 11 月 4 日前释出 | 官方博客 |
| 加速版 | Highspeed，速度 2 到 3 倍 | 官方博客；第三方口径称价格翻倍，采购前以官方定价页为准 |
看到"2.8T 总量 / 104B 激活"和"3T 级"摆在一起时别纠结，这是两个不同粒度的表述，写选型文档时统一按官方模型卡填就行。真正要留意的是 104B 激活这个数------它决定了自部署时你要算的是显存带宽和卡数，不是 2.8T 那么吓人的总量。
二、真正的涨幅在 Agent 侧，不在知识侧
这是本篇最值得记的一点。同一份评测里，几类指标的涨幅差得非常远：
| 评测 | K3 | K3.1 Pro | 性质 |
|---|---|---|---|
| GDPval-AA | --- | 1846 Elo，第 3，比 K3 高 312 | 真实职业任务，Agent 味最重 |
| Terminal-Bench 4.0 | 13% | 67%，全场最高 | 终端里连续执行命令 |
| AutomationBench-AA | 58% | 73% | 多步 SaaS 工作流 |
| Humanity's Last Exam | 47% | 52% | 知识推理 |
| SciCode | 59% | 61% | 科学编程 |
| CritPt | 23% | 25% | 物理推理 |
| AA-Omniscience | 20 | 30（幻觉率 53%→44%，准确率 48%→51%） | 知识广度与幻觉 |
GDPval-AA 的 1846 Elo 只落后 Claude Opus 5.5 的 1866 和 Muse Wonder Full 的 1857，挤进了前三。而 Terminal-Bench 从 13% 到 67% 是五倍多的变化------如果你只看"智能指数提升 11 分"这个数字，会完全错过这一档。
这种"Agent 类大涨、知识类微涨"的组合，通常意味着后训练的重心压在工具使用和多步执行上，而不是单纯把模型堆更大。对你的判断很直接：单轮问答、知识型客服这类场景，换它的收益有限；让 Agent 连续调工具、跑终端、操作后台系统，才是这波提升兑现的地方。
还有一个容易被忽略的横向信息：权重释出后，开放权重模型与闭源最强模型在智能指数上的差距会从 12 分收窄到 3 分。这是选型时"能不能自部署"这个选项第一次变得现实的前提。
三、单价降了 33%，为什么每任务成本没降
AA 给了一个很反直觉的数字：K3.1 Pro 的每任务成本约 1.98 美元，和 K3 基本持平。
拆开看就明白了。它的输出 token 用量是每个智能指数任务 55K，比 K3 的 48K 多 14%；而三项单价都低了 33%。单纯乘一下，输出侧本该降两成多，可实测每任务成本没降------差额只能来自输入侧：更长的上下文、更多的工具往返、以及缓存命中结构的变化。
这段算术是我根据 AA 公布的三个数字推的，不是原文结论，具体口径以 AA 的方法说明和官方定价页为准。但推出来的结论够用了：按单价排序选模型，在 Agent 场景里是错的。
原因是 Agent 任务的成本结构和对话完全不同。一次任务会发几十次请求，每次请求都带着系统提示、工具定义、历史轨迹，输入量是输出的十几倍。所以正确的算法是：
每任务成本 = Σ(输入 token × 输入价) + Σ(缓存命中 token × 缓存价) + Σ(输出 token × 输出价)求和号不能省------要先把一次任务里所有调用的用量加起来，再算钱。这也是下一个坑的来源。
四、1M 上下文解决的是"装得下"，不是"算得省"
上下文从 K3 到 K3.1 Pro 拉到 100 万 token，很多人第一反应是"终于可以把整个仓库塞进去了"。能塞，但未见得该塞。
两个原因。一是价格结构：缓存命中价 0.20 美元，只有输入价 2 美元的十分之一，这个差价是在明确奖励"前缀稳定"的用法。系统提示、工具定义、固定文档放前面不动，命中缓存，成本差一个数量级；而每轮都变的中间结果堆在上下文里，全部按输入价付费，1M 就是 1M 的账单。
二是效果层面：上下文变长不会自动让 Agent 更准。KV 越长，注意力被稀释得越厉害，你需要的是压缩、摘要、检索这些手段，而不是把窗口当硬盘用。这也是为什么不少团队宁可停在 200K 窗口、配一套靠谱的记忆检索，也不追求把窗口塞满。
一个立刻能用的实操：把 prompt 结构切成三段------稳定前缀（系统提示、工具定义）、半稳定（仓库快照、参考文档）、每轮变化（工具返回、思考轨迹）。前两段位置固定不动，第三段只追加在尾部，缓存命中率立刻能看出来。
五、标准版、Highspeed、自部署怎么选
| 场景 | 选择 | 理由 |
|---|---|---|
| 交互式编码、要人等 diff 再确认 | 标准版 | 单位成本更低，人的思考时间本来就是瓶颈 |
| 前台 Agent、用户盯着进度条 | Highspeed | 2 到 3 倍速换体验，串行多步任务的体感差距最大 |
| 批量离线评测、回归跑分 | 标准版 + 并发 | 慢一点没关系，成本优先 |
| 数据不能出内网 | 等 11 月 4 日权重自部署 | 权重释出后才有这个选项，但要按 104B 激活算 GPU 账 |
两件事要提前做：一是把模型名、base_url、价格表全部外置成配置，别写死在代码里，否则换模型要改业务代码；二是把 Highspeed 的价格单独核实一遍------官方博客只说了速度倍数，价格口径我是从第三方看到的"翻倍"，采购前必须以官方定价页确认。
六、一段成本核算脚本
这段是自拟示意代码，不依赖任何 SDK，纯粹算账用。
python
# cost.py ------ 按一次 Agent 任务的完整用量核算成本
PRICES = { # 美元 / 每百万 token，价格随官方调整，用前核对定价页
"kimi-k3.1-pro": {"in": 2.0, "out": 10.0, "cache": 0.20},
}
def task_cost(usage: dict, model: str = "kimi-k3.1-pro") -> float:
"""usage 是一次任务累计的 token 三元组，不是单次请求的用量。"""
p = PRICES[model]
return (
usage["input"] * p["in"] / 1e6
+ usage["cache_hit"] * p["cache"] / 1e6
+ usage["output"] * p["out"] / 1e6
)
def compare(traces: list[dict], models: list[str]) -> None:
"""把同一批任务轨迹套到不同模型上，输出每任务成本与缓存命中占比。"""
for m in models:
costs = [task_cost(t, m) for t in traces]
hit = sum(t["cache_hit"] for t in traces)
total_in = sum(t["input"] + t["cache_hit"] for t in traces)
print(f"{m}: 每任务 ${sum(costs) / len(costs):.4f} "
f"缓存命中 {hit / total_in:.1%}")
if __name__ == "__main__":
demo = [{"input": 180_000, "cache_hit": 620_000, "output": 12_000}] * 20
compare(demo, ["kimi-k3.1-pro"])参数与返回值：task_cost 收一个 usage 字典和一个模型名，返回该任务的美元成本；usage 的三个键必须来自"同一次任务里所有请求的汇总"，不能只取最后一次响应。compare 收一批任务轨迹和候选模型列表，只打印不返回，因为它的用途是横向铺开看趋势，不是给程序判断。
调用链是这样：Agent 每轮请求结束后从响应的用量字段里取三个数，累加进当前任务的 usage → 任务结束把 usage 落盘成一条轨迹 → 累积到几十条之后跑 compare → 拿结果和候选模型列表对照。
这段代码刻意做的两件事：一是把缓存命中和普通输入分开计价，否则算出来的账会虚高；二是强制按任务聚合，避免把"单次请求成本"当成"每任务成本"。后者是最常见的错误估算来源，能把成本低估一个数量级。
收尾
Kimi K3.1 Pro 值得试的理由，不是它排第 4，而是两件更具体的事：Terminal-Bench 从 13% 到 67% 说明工具调用能力真的换了一代，缓存命中 0.20 美元说明它在认真做长上下文的经济性。
选型的顺序建议反过来：先拿自己 20 条真实任务跑一遍 token 账，看清输入侧占多少、缓存能命中多少，再回头看排行榜。榜单告诉你上限，账本告诉你代价。
文中分数与价格来自 10 月 23 日的评测与官方博客，权重尚未发布，正式释出后价格和分数都可能变，最终以官方文档为准。