从 200K 到 1M：长上下文管理的原理

最近我们团队做了一个销售AI助手，以问答为主，慢慢加上了识别文档功能。最开始的需求很小：识别一张图片——销售在客户现场拍一张资料或名片的截图，模型提取关键信息。后来能力一路扩到 PDF、Word 等文档，用户一上传就是几十上百页的政策细则或方案。

我们当时用的模型是 Claude Sonnet 4.5，默认 context window 是 200K。文档一上来，第一个担心就是：单次上传太大，会不会把 context window 撑爆？

团队最初的直觉是：Sonnet 4.5 本身支持 Files API，文件走专门的文件通道，应该不怕大。但把 Files API 的原理研究了一遍之后，结论恰恰相反——Files API 解决的是"重复上传的浪费"，不是"上下文容量"。文件内容仍然会被完整 token 化，照样占用 context window 的额度。窗口只有 200K，走 Files API 一样会撑爆。

所以最终的决策是升级到支持 1M context window 的 Sonnet 4.6。这个决策逼着我们把 200K 到 1M 背后的原理完整梳理了一遍，这篇文章就是这个梳理：先讲清楚 Files API 到底省了什么、没省什么，再展开 200K 到 1M 的三层底层技术。

一、Files API：省的是传输，不是 token

第一次看到 Files API 文档时，我下意识以为这是某种变相的 RAG：上传、切 chunk、建索引、检索 top-k，只把相关片段塞进上下文。认真读完文档才发现完全不是。

Files API 解决的是一个很朴素的工程问题：重复上传浪费。一个 5MB 的 PDF base64 编码后变成 6.6MB，10 次请求就是 66M 传输，而且每次都要重新处理。Files API 的思路是上传一次，拿到 file_id，后续只传这个几十字节的引用。它省的是带宽和延迟，不减少 token 使用量——文件内容仍然会被完整 token 化、占用 context window 并计费。

Files API 核心流程：上传一次拿 file_id，后续只传引用；省的是传输，不是 token

对销售助手这个项目，这一点的含义很直接：撑爆 context window 的不是上传方式，是窗口本身。一份 300 页的政策文档，无论是塞 base64 还是走 Files API，token 一个都不会少。Files API 没有绕过 context window 这个硬上限，它只是让在上限内反复用同一份文件变得更便宜——它真正的降本手段是 prompt caching：5 分钟内对同一份文档的复用请求，缓存命中部分的计费可以降到原来的 1/10。但第一次请求时，几百 K token 仍然要全额付费。

即便我们对上传单文件做了 1MB 的上传限制。在大致估算下，中英文混杂的 PDF 文件，就可能达到 15 万到 20 万 token，为了限制文件 token 数不能超过模型 context window，我们选择升级模型。

二、200K 到 1M，底层改了什么

决定了升级，下一个问题自然冒出来：200K 到 1M 这 5 倍，底层到底是怎么做到的？拆开看，长上下文的技术栈可以归纳为三层。

位置编码外推是第一步。Transformer 需要知道每个 token 的位置。RoPE 把位置信息编码成旋转角度，训练时模型只见过 4K/8K 的旋转范围，突然塞给它 1M，相当于让一个人用 10 米卷尺量 1 公里的路。解决方案是外推：PI 把位置均匀压缩，YaRN 区分高频和低频做非均匀压缩，ABF 则直接换一把更精密的尺子，把 RoPE base 从 10000 调到 1000000。具体留作后文讨论。

Attention 计算扩展是第二步。位置问题解决了，计算量还在。self-attention 的复杂度是 O(n²)，200K 到 1M 意味着 attention score 矩阵膨胀 25 倍。FlashAttention 把大矩阵拆成小块，像 MapReduce 一样分批算；Ring Attention 把序列切到多台 GPU，KV 像接力棒一样在环里转；DCA（Dual Chunk Attention）把 attention 拆成局部 intra-chunk 和全局 inter-chunk 两部分，让长序列的内存占用从 O(n²) 降到 O(n·c)，c 是 chunk 大小。

训练策略是第三步。不可能拿一个 4K 预训练的模型一步拉到 1M。主流做法是渐进式扩展：4K → 32K → 128K → 1M，每个阶段用约 40% 的当前最大长度数据混合 60% 的短数据，避免模型忘了短文本怎么写。

RoPE base 从 10000 调到 1000000：旋转更细密，便于外推更长位置

即使这三层都做到位，长上下文还有一个隐形成本：Lost in the Middle。模型对上下文中间部分的信息召回率明显低于开头和结尾。它不是 attention 算不动，而是 attention 的注意力在超长序列里会被稀释。200K 窗口里这个效应已经可测，到了 1M 只会更明显。对工程实践的意义是：窗口变大不等于可以随便塞，关键信息仍然要尽量放在上下文的开头或结尾。

位置编码让模型记得住长位置，attention 扩展让模型算得动长序列，渐进训练让模型学得会长文本。200K 到 1M，靠的就是这三层同时到位。

三、落地时的几个取舍

销售助手上线前后，我们实际做的取舍可以归成几条：

落地取舍：问题与对策对照——先算 token，再看窗口，最后谈缓存

核心原则就一条：先算 token，再看窗口，最后才谈缓存和降本。顺序反了，就会像我们最初那样，指望 Files API 解决它本来就不解决的问题。

四、时间线：从 200K 到 1M

从 200K 到 1M：商用长上下文时间线

五、结语

回头看这个决策，最关键的一步是把两个概念分开：Files API 和 context window 是两件独立的事。前者解决传输和复用，后者是硬上限；指望文件通道绕过窗口限制，是架构判断上最容易踩的坑。

而 200K 到 1M 这个升级为什么可行，靠的是三层技术同时到位：位置编码外推让模型记得住长位置，attention 计算扩展让模型算得动长序列，渐进式训练让模型学得会长文本。理解了这三层，下次再遇到"文档太大装不下"的问题，排查顺序就清楚了：先算 token 量，再看窗口上限，最后才轮到 Files API 和 prompt caching 这些降本手段粉墨登场。