Kimi Code 悄悄给 Kimi K3 加了一个新选项:k3-256k。上下文窗口从最高 1M 砍到固定 256K,官方却说,在这个范围内,效果和跑满 1M 的旗舰版一样。
上下文窗口一直是长上下文竞赛里最贵的参数。这次 Kimi 反着来,主动砍掉四分之三,还把额度消耗压到大约一半。这笔账,比多发一个新模型更值得算清楚。
发生了什么:256K 版怎么定价
k3-256k 和 k3 同属 Kimi K3,区别只在上下文窗口。官方口径很克制:只承诺 256K 范围内结果和 1M 版一致,超出这个范围不在承诺之列。
输入能力也缩了一圈。k3-256k 只支持图片,不支持视频;k3(1M)图片、视频都能喂。
会员门槛上,两者都要 Moderato 及以上才能调用。想真正跑满 1M,得升到 Allegretto 及以上。换句话说,不少 Moderato 会员挂着 k3 的名字,实际也只用得到 256K 的窗口——k3-256k 只是把这件事挑明了。
同样一段代码任务,两边花的额度差多少?官方给的说法是接近两倍。
谁该换,谁该留在 1M
日常问答、代码补全、单文件小改动,256K 窗口绰绰有余。用 Kimi Code CLI、VS Code 插件或第三方编码代理写日常代码的人,可以直接把默认模型切成 k3-256k,基本没有代价,还能省下一半额度。
跨文件的大重构、需要长会话维持上下文的任务,还有要喂视频素材的场景,建议继续锁定 k3(1M)。
| 场景 | 推荐版本 | 为什么 |
|---|---|---|
| 日常问答、代码补全、单文件小改动 | k3-256k | 256K 够用,额度省一半 |
| 跨文件大重构、超长会话 | k3(1M) | 避免中途触发 compact,上下文更完整 |
| 需要分析视频素材 | k3(1M) | k3-256k 不支持视频输入 |
切换本身也有代价。如果当前会话已经超过 256K,从 1M 切到 256K 时,Kimi Code CLI、Claude Code 这类工具会自动做一次 compact 压缩上下文。会话里带过视频文件的话,切换前得先手动 compact,不然会因为 k3-256k 不支持视频直接报错。
模型切换、reasoning effort 切换,都会让之前攒下的上下文缓存失效,得重新预填充。这段时间用量看着不降反升,是正常现象,不是 bug。官方文档里专门列了一条"为什么切换后用量反而涨了"的常见问题,说明这不是个别用户遇到的意外。
官方目前没有公布 256K 额度消耗的具体测算口径,也没给出判断会话是否接近上限的具体方法。这部分只能靠用户实际用下来自己摸索。接下来值得盯的,是官方会不会把这套换算公式补全。
长上下文正在从能力卖点,变成分层定价工具
少则得,多则惑。
老子这句话放在这儿意外贴切。多数编码任务本来就用不到百万级上下文,硬塞满反而拖慢速度、吃光额度。Kimi 把 256K 单独拎出来定价,更像是承认了一个行业心照不宣的事实:长上下文的边际收益,在大多数真实任务里,早就摸到了顶。
真正值得判断的不是 K3 变强还是变弱,而是 Kimi 把"上下文长度"从纯粹的能力参数,变成了额度耐用度的一个旋钮。用得少的人少花钱,用得多的人多花钱,这个逻辑站得住。
代价没有说得那么干脆。模型切换、reasoning effort 切换都会打掉缓存,这部分隐性成本被转嫁给了用户,得自己去踩坑摸索。对大多数只写日常代码、改小文件的人,k3-256k 是明显更划算的默认选项;真正用得上 1M 的场景,其实一直没那么多。
百万级上下文听着更有分量。但对着一个写惯了单文件小改动的开发者,256K 够用,才是这次更新真正值得记住的地方。