Kimi 读长文档：1M 上下文能装多少页，哪里开始读不准

按官方口径换算，1M token 大约对应 50 万到 100 万字，也就是上千页 A4。但装得下不等于读得准：真正决定体验的是你要问的问题落在文档的哪个位置，以及你给没给它一条检索路径。想让第 800 页的条款被准确引用，光靠窗口够大不够。

先把页数算清楚

K3 系列三个模型的上下文窗口都是 1,048,576 token。官方帮助中心给的换算是：中文 1 个字通常 1 到 2 token，英文 1 个词 1 到 1.5 token。

按中文一页 600 字算，1 字 1.5 token，一页约 900 token。1,048,576 除以 900，大约 1,160 页。如果排版密、图表多，实际 token 会更高，页数掉到七八百页。

按纯字数估更稳：50 万字左右是我按上面的换算给出的保守水位，80 万字接近上限。这两个数不是官方口径，是按「中文 1 字 1 到 2 token」自己折算的，实际取决于你的排版密度和图表数量。超过 50 万字，留给自己验证的时间会明显变长。

还要先确认你手上是哪一档。1M 上下文只在 Max 和 Ultra 解锁，官方会员页没有写明低档位的具体上下文长度是多少。有个第三方测试帖称 Plus 档给到 256K，但这条我没在官方页面找到对应表述，按未核实处理。稳妥的判断是：如果你买的是 Plus 或 Pro，先按「远小于 1M」来规划，别默认能塞进一份三五百页的研报。

装得下和读得准是两件事

模型处理长上下文时，不同位置的召回质量不是均匀的。中间段落最容易被忽略，这是长上下文模型的通病，各家都在做，程度不同。

Kimi 官方没有公开任何「第 N 页开始准确率下降」的曲线，所以任何精确到页的数字都不可信。能说的是两件事。

一是位置效应确实存在，把关键问题指向文档开头或结尾，命中率通常高于指向正中间。

二是提问方式的影响比位置更大。问「这份合同里关于违约金的条款是什么」，比问「总结一下这份合同」更容易拿到可核对的答案，因为后者要求模型在整个窗口上做一次全局摘要。

上下文越长，单次请求的算力开销也越高，KV cache 随长度线性增长。1M 上下文的显存占用和十万字级别的上下文不是一个量级，这也是为什么只有高配套餐才放开这一档——算的是成本，不只是营销分层。想理解这套开销的构成，本地部署的显存对照表 里把权重和 KV cache 分开列了。

一个自己就能跑的自测

不用等别人给结论，用你自己的文档跑一遍，二十分钟能出结果。

准备一份结构清晰、你熟悉内容的长文档，长度控制在你套餐的上限附近。然后埋三个问题：

第一个问题，问文档第一页里的一个具体数字。第二个，问正中间章节里的一个具体条款编号。第三个，问最后一页的结论。

三个都要求模型指出原文位置。命中两个以上，说明这份长度对你可用。只命中首尾，中间的丢了，就该切分。三个全丢，可能是文档格式问题——扫描件 PDF 需要先转文字，图片里的字不会被当成 token 读进去。

这套方法的价值在于它测的是你的文档类型和你的提问方式，而不是别人的平均值。

分段：目录先行

分段不是简单地按字数切。有效的做法是先让它读目录，再按目录切。

具体三步。先只传目录和第一章，让它输出一份结构化提纲，标出每一节讲什么。然后按提纲把文档切成 5 到 10 个块，每块开头粘一段 200 字的前情摘要，说明「这是第几部分，前文讲了什么」。最后逐块提问，把答案累积到一个单独的文件里，而不是在同一轮对话里连续追问。

第三步最容易做错。在同一轮对话里连续问十个问题，前面九次的回答会占掉大量 token，到第十次时窗口里塞的多半是模型自己的输出，原文被挤到边缘。分开问、单独存，反而更准。

引用核对三条

第一条，凡是涉及数字、日期、条款编号的回答，要求它同时给出原文引用。给不出原文的，按未验证处理。

第二条，同一份材料问两次，看两次引用的位置是否一致。不一致说明该处召回不稳定，需要人工回原文确认。

第三条，跨文档对比时，先分别问再合并问。一次让它同时读五份材料做对照，出错率远高于分五次读完再汇总。

这套流程跑顺之后，1M 窗口的实际价值不在「一次读完」，而在「不用反复重建上下文」。真正省时间的是这一点。Kimi 这条长上下文能力在产品侧怎么落地，Kimi OK Computer 这一版 有对应的记录。