⚡ 概述
月之暗面放出 Kimi K3-256K:能力与完整版 K3 一致,砍掉视频输入,上下文封顶 256K。第一眼看像「阉割版」,但开发者社区算完一笔账后,结论出奇一致——这才是务实的做法,因为长上下文本身,就是最大的成本刺客。
对绝大多数 coding 任务,模型开销的大头不是输入输出,而是上下文。把上下文从 5 万拉到百万级,平均 Token 消耗直接翻一个数量级——除非缓存极便宜,否则这就是「Token 刺客」。Kimi 在配置层直接掐断长上下文,等于替用户关掉了那个最贵的开关。
💸 长上下文为什么这么贵
一个被反复验证的事实:在 coding 任务里,只要缓存没打下来,整个会话的主要开销就压在上下文那部分 Token 上。窗口拉得越大,你每轮请求都在反复搬运一座越来越大的山。
但这话有个前提——只有当缓存命中价格足够低,长上下文才「贵得有限」。目前真正把缓存价格打下来的,市面上只有 DeepSeek 和 MiMo 两家,所以也只有这两家的百万上下文算「用得起」。其余各家,长上下文的计费方式堪称离谱,理性选择永远是短上下文。
算笔简单的账:1M 上下文平均下来大约 500K,和 50K 上下文相比,开销差了整整 10 倍。
习惯在 100K 左右就主动收一次,平均上下文能压到 50K;习惯堆到 990K 等系统自动压缩,平均就是 500K。同样是「长上下文模型」,后者比前者贵 10 倍。哪怕只看 256K 这一档,一轮对话跑到 200K,开销也是 50K 基线的 4 倍。
这一切,只有当【缓存命中价格很便宜】时才不成立。可惜绝大多数主流模型的缓存价格同样不低,于是主要开销始终是上下文,长上下文注定会推高使用成本。主动限制上下文,能让 Agent 软件自动控制好上下文尺寸,大幅度降低开销。
🧠 多数人没有「上下文管理」这个概念
更深的问题在用户习惯。相当多的人根本没有「主动管理上下文」的意识,完全依赖 Harness(Agent 软件层)的自动压缩——而且往往挑最贵的模型,一个对话框走到黑,涨满 1M 才触发压缩。
这种用法下,「几轮就烧光额度」几乎是必然。Kimi 飞书群里被群嘲「用量少、几轮就没」的现象,很可能就跟这种用法直接相关。群里官方公告提到「90% 的使用场景不超过 256K 上下文」——反过来看,居然还有 10% 的「壕」拿 K3 在烧长上下文。
更有意思的是 K3 文档里那句「建议开新会话再切换到 K3」。这本来是个善意提示,但很多人根本没读懂:他们直接把一个已经堆到 200K+ 的老会话切到 K3,然后一路顶到 1M 极限再自动压缩——这种用法,不管什么套餐都撑不住。官方那句提示,更像是提前在堵公关危机。
此前 GPT 5.6 Sol 在 Codex 里把默认 Context Window 从 272K 上调到 372K,立刻被一堆人喷「Token 不耐用」。Tibo 还特地发帖解释 Auto Compact 在两档之间差异没那么大,但最后还是顶不住,默默把默认限制调了回来。默认把上下文拉满,是一种吃力不讨好的设计。
🔍 「我缓存命中率 98%」其实是危险信号
社区里常有人炫耀自己缓存命中率高到 98%、99%,并据此觉得自己用得很省。这个直觉很可能是反的。
Harness 层面的缓存命中率,各家差不了太多。命中率异常高,往往恰恰说明你在重度使用长上下文——而长上下文,正是最贵的那部分。所以「高命中率」换个角度看,约等于「我在最贵的地方用了最多」。
说到底,并不是所有场景都需要长上下文。学会主动控制上下文,那些高价模型才勉强一用;如果你是那种「一个对话框走到黑、愣是等上下文涨满 1M 自动压缩」的用法,那么除了 DeepSeek 和 MiMo,其它所有模型可能都会超出你的预算。
🏷️ 那 256K 版本会降价吗?大概率不会
很多人在猜这个新模型 ID 会不会更便宜。大概率不会——还是同样的价格。官方说的价格倍率,主要来自长上下文的输入与缓存命中开销,而不是模型本身降价。
按二者的平均情况,差距会拉到 3 倍左右。只是大多数人一个会话压根到不了 1M 这么长,所以官方给了个保守的「预估 2 倍」说辞。
256K 限制下,平均 Context 长度大概在 150K;1M 限制下均值约 600K——光缓存价格开销就拉开 4 倍。一条 Prompt 下平均约 8 条消息轮次,假设每轮输入 4K、输出 600 Token,实际输入输出开销占比其实很低。
所以性价比提升,来自「从模型配置层面掐断长上下文」这个动作本身,而不是降价。
也正因如此,Kimi 才特地另出一个版本的模型,从配置层就把长上下文掐断,这样才能真正提升用户实际任务的性价比。
📊 实测:额度消耗约为完整版的三分之一
评论区有几条值得记的实测与冷知识:
- 冷知识:Codex 和 Cursor 接的都是 1M 模型,但实际能用的上下文都只有 2–3 百 K。
- 缩水版到底亏多少:有人拿同一任务实测,这个 256K 版消耗的额度大约只有完整版的 1/3——因为大上下文本身就会加大 Token 消耗;按同等完成标准算,同样任务的额度消耗约为原来的 40%。
- 长线任务:在 kimi cli 跑了一两个小时的长线任务,周额度消耗 5.53%;而之前基本是每小时 10% 往上。
- 效果有影响吗:有,review 后需要返工修补一下,完整版则几乎不需要返工。
- 视频与 1M 的算力:砍掉视频输入和 1M 上下文,算力需求至少减半。
对 199 套餐用户来说,本身额度就严重不够,用缩水版可以稍微放开点用;而关键是——K3 MAX 的 1M 版本照样可用,不像 ChatGPT 你不走 API 计费都用不了 1M。
等于在低成本档之外,又多给了你一个选择(顺带也降低了官方的算力消耗),百利而无一害。
🎯 一句话总结
对绝大多数人来说,长上下文就是一个 Token 刺客——除了 DeepSeek、MiMo 这种缓存极低的模型,其余都在悄悄掏空你的余额。
Kimi K3-256K 用一个配置层的封顶,替用户管住了花钱姿势。对一个算力始终偏紧的团队来说,算得上体面。真正贵的从来不是模型,是你以为自己用得起的那个「无限」。
本文基于开发者社区对 Kimi K3-256K 发布的公开讨论与实测整理,数字与观点均来自社区反馈,仅供参考;具体计费以月之暗面官方为准。