Kimi K3 vs K2:升级了什么、要不要现在就换?

月之暗面的 Kimi K3 一出,很多已经在用 K2 / K2.x 的团队第一反应都是:值不值得换?答案不是「无脑升级」,而是看你的场景吃不吃得到 K3 那几项新能力,以及扛不扛得住它更高的输出价。下面把两代的差异摊开对比,再分场景给结论。

一张表看懂两代差异

维度	Kimi K2 / K2.x	Kimi K3
上下文窗口	256K token	1M(1,048,576)token
视觉能力	无 / 外挂	原生视觉(图片 + 视频)
推理	K2-thinking 单独型号	常开推理,reasoning_effort 控制
架构	MoE,约 1T 总参	MoE 2.8T,896 专家激活 16
注意力	标准 MoE 注意力	KDA + Attention Residuals
扩展效率	基线	约 2.5× 于 K2
输出价(官方参考)	约 ¥8–16 / 1M	¥100 / 1M

K3 到底强在哪

上下文从 256K 跳到 1M。 这是最直观的升级。整个中型代码库、一整份长合同、几十页 PDF 现在能一次性塞进单轮请求,不用再费劲切片做 RAG。长程 Agent(跑一长串工具调用、维护长历史)的体验差别尤其明显。

原生视觉成了一等公民。 K2 时代看图基本靠外挂 OCR 或另调视觉模型;K3 直接吃图片和视频,做「照着设计稿写前端」「看游戏 / CAD 截图改代码」这类任务是原生支持。注意视觉输入要用对象数组、走 base64 或 ms:// 文件引用,不支持公网图片 URL。

推理默认常开。 K2 想要深度思考得切到 kimi-k2-thinking 那类专门型号;K3 把推理内建进主型号,用 reasoning_effort 调力度(当前仅 max),复杂推理和多步规划开箱即用。

新架构带来的效率。 2.8T 的 MoE 配上 KDA(Kimi Delta Attention)+ Attention Residuals,官方称整体扩展效率约为 K2 的 2.5 倍 —— 换句话说,同样的算力预算能训 / 推得更划算,这也是它敢把上下文拉到 1M 的底气。

代价:输出价明显更高

K3 是旗舰定位,价格也旗舰。官方参考价里 输出高到 ¥100 / 1M,输入缓存未命中 ¥20、命中 ¥2。对比 K2 系列几块钱的输出价,纯跑量的场景成本差距很大。好在 K3 默认开启上下文缓存,长 system prompt、固定文档反复调用时输入能压到一折,长程 Agent 反而受益。价格随时浮动,下单前请看实时价 —— GetModel 上 Kimi 全系的实时单价见价格页。

分场景结论:该用哪个

继续用 K2 / K2.x:

• 纯跑量、高并发的通用任务(分类、抽取、改写、客服),对能力上限要求不极致 —— K2 单价低得多;
• 上下文很少超过 256K,也用不到视觉;
• 成本是硬约束。

升级到 K3:

• 要一次吃下整库代码 / 超长文档,吃满 256K 已经捉襟见肘;
• 有看图写代码 / 多模态需求(前端、游戏、CAD、设计稿还原);
• 跑长程 Agent、需要强推理和长历史稳定性;
• 长 prompt 高度重复,能吃到缓存降价,把旗舰价摊薄。

折中做法很实际:用一个聚合网关同时挂着 K2 和 K3,便宜任务走 K2、硬任务走 K3,代码里只改 model 字段就切换。用 GetModel 这类聚合接口时,一个 Key 就能在两代之间自由调度,还能顺带比一比 GPT、Claude。

迁移要点(K2 → K3)

真要升级,代码上避开三个坑:

• 删掉 thinking 参数,K3 改用 reasoning_effort(当前仅 max);
• 多轮 / 工具调用把完整 assistant message 原样回传,别只留 content;
• 上下文预算翻了 4 倍,但别无脑塞满,越长越贵越慢。

完整的接入代码、curl / Python 示例和报错排查,见 Kimi K3 API 接入教程。想在一套代码里同时用 K2、K3 和别家模型,从 GetModel 控制台拿个 Key 开始最省事。