Kimi K3.1 Pro 选型：1M 上下文和每任务成本怎么算-平芜编程栈

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，纯粹算账用。

# cost.py —— 按一次 Agent 任务的完整用量核算成本PRICES={# 美元 / 每百万 token，价格随官方调整，用前核对定价页"kimi-k3.1-pro":{"in":2.0,"out":10.0,"cache":0.20},}deftask_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)defcompare(traces:list[dict],models:list[str])->None:"""把同一批任务轨迹套到不同模型上，输出每任务成本与缓存命中占比。"""forminmodels:costs=[task_cost(t,m)fortintraces]hit=sum(t["cache_hit"]fortintraces)total_in=sum(t["input"]+t["cache_hit"]fortintraces)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}]*20compare(demo,["kimi-k3.1-pro"])