DeepSeek 的 1M 上下文：能放几本书，什么时候开始失忆

能放下，但不一定找得到。1M token 约等于四五本 30 万字的书，可窗口填到七成以上时，中段信息的召回会明显变差，具体从第几万 token 开始掉，官方没有公布曲线。

先做一次换算

deepseek-flash 与 deepseek-v4-pro 的上下文都是 1,048,576 token，单次输出上限 384K token。

中文的 token 压缩比官方未披露，不同分词器版本之间差得也不小。下面的换算按「一个汉字折 0.7 个 token」这个假设值估算，只用来判断量级，不要拿去算预算：

• 一本 30 万字的长篇，约 21 万 token，1M 窗口装四到五本
• 一份十万字量级的技术文档，约 7 万 token，装十份上下
• 一个中型项目的代码库，实际占用取决于行数与注释密度，没有通用换算；同样的字数下，代码通常比中文省 token

真正决定装不装得下的，是上下文由输入和输出共用这件事。假设留十万 token 给输出，可用的输入就只剩九十万上下。想让它读完整个仓库再生成完整报告，这个组合已经不成立了。

更常先撞墙的是输出上限

384K 输出看着很大，按上面的假设折成中文是二十多万字。但真实场景里很少有人一次生成这么多——多数时候是被「要求它把全文重写一遍」这种指令撞上的。

输出越长，后半段越容易跑偏：格式崩、重复、前后矛盾。实用的做法是把长输出拆成若干段，每段明确「只写第 3 章，控制在 3000 字内」。分段生成再拼接，比一次要 20 万字稳。

衰减没有官方曲线，只能自己测

第三方评测给出的长上下文推理平均分在八成出头，但这个数字帮不了你——它不告诉你第 40 万 token 处的那句话还在不在。厂商普遍不公布位置维度的召回曲线，所以只能自测。

「针在草堆」的做法够用了：取一份 50 万 token 的文档，在里面埋 10 个不重复的事实句（比如「编号 A7 的合同金额是 43.2 万」），分别埋在不同深度，然后用同一组问题去问。

记录三件事：答对几个、答错时说没说「文中未提及」、被问到跨段落对比时会不会只引用开头结尾。第二项特别重要——坦率承认找不到，比编一个数字好得多；如果它开始编，说明这个长度已经超出可用范围。

测三轮，取稳定值。单次结果受采样影响很大，一轮不算数。

分段策略，比扩窗口更实际

按结构切，不按字数切。 章节、函数、庭审记录里的每一段证言，天然边界比 10 万字一断更合理。切断语义单元是长上下文任务里最常见的失误。

给每段加一句摘要放开头。 十段材料，开头先列十条一句话摘要，再放全文。模型读开头时会建立索引，后面检索的准确率会好一些。

关键信息放两端。 首尾位置的召回通常好于正中。要把结论性材料放前面，问题放后面。

让它在回答里标注出处。 要求每个结论后面写「出自第几段」。没有出处的结论，人工复核成本会高得多。

想验证同一份材料在小模型上的表现做对照，可以先在 Qwen3.8-27B 本地部署 那套环境里跑一遍；成本结构上看，长输入走缓存命中只要 $0.003 每百万 token，把固定材料放前面反复问，账单比想象中低，具体档位见 11 月大模型 API 价格表。

判断标准

材料在 20 万 token 以内，直接整份丢进去，省掉切片的麻烦。超过 50 万，先做一次针在草堆测试，过不了就老实分段。至于那些「一百万字全书分析」的演示，看看就好——能读进去和能读明白，是两件事。