Kimi K3 长文本实测：256K 下的稳定性

Kimi K3 的 256K 窗口适合整本手册、整套合同、完整代码仓库的问答。我们用一个 180K token 的技术文档集做了「大海捞针」测试：把唯一标识句放在不同深度，观察模型能否准确引用。 整体召回在 20%–60% 深度区间最稳，接近首尾两端反而更好，中段偶有遗漏；超过 220K 后，边缘位置的召回开始波动。这与多数长上下文模型的注意力分布一致，不是某个站点的特有问题。 工程上的应对很直接：把最关键的约束放在提示词开头或结尾，中间部分用结构化标题分隔；超过 200K 的输入先做一次分块摘要再拼接。另外注意长输入的首包时间会显著上升，交互式场景建议加进度提示，别让用户以为卡死。 还有一个成本提醒：长输入的计费按 token 累加，一次 180K 的问答约等于 20 次普通请求。把它用在「一次问清」的场景最划算，用在反复追问上则会迅速失控。批量核对类任务建议先做一次全文索引，再按需取片段。