长文本API选型别只看上下文长度：有效窗口、预切分代价与长输入成本怎么算

做合同审阅、年报抽取、日志归因或整库代码理解的团队，几乎都会撞上同一个困惑：模型标称支持128K甚至更长，把一份八万字的文档整段投进去，答案质量却明显下滑。长文本API的难点从来不是“能不能塞进去”，而是塞进去之后注意力还剩多少、延迟能不能接受、账单是否算得过来。把这条链路上的卡点逐一摊开，才谈得上选型。 第一个卡点是注意力计算与显存。标准注意力对序列长度呈平方级增长，长度翻一倍，注意力矩阵的规模就是四倍。即便推理侧用KV Cache缓存历史键值来避免重复计算，缓存本身的显存占用仍然随长度线性上升，并发几路长请求，显存很快被吃满。很多服务在短请求下表现稳定，一旦并发跑长文档就出现排队、超时甚至请求被拒，根源大多在这里。 第二个卡点是位置编码的外推能力。不少模型训练时接触的有效长度明显短于宣传窗口，靠RoPE缩放、NTK插值一类手段做外推，长距离上的位置区分度会变差。表现出来就是开头和结尾的信息抓得住，中间段落容易被忽略，也就是常说的“中间遗忘”。标称窗口和有效窗口是两回事，用多跳问题验证中段召回，比看参数表有意义得多。 第三个卡点是预填充与解码两个阶段的不对称。长输入的时间几乎全部花在预填充上，首token延迟随长度近似线性上升，而后续解码每个token的开销相对固定。这意味着长文档问答如果只问一句话，用户等待时间主要由文档长度决定。前缀缓存能缓解同一份文档的二次调用，但前提是请求前缀完全一致，真实业务里的复用率往往没有想象中高。 第四个卡点是成本结构。按量计费下，输入token通常是主要支出，一份需要反复追问的长文档会在每次调用中重复计费。若业务要对同一份材料做多轮问答，整篇重传的账单增长非常快。这也是分层摘要、检索召回等预处理手段流行的原因，它们并非技术炫技，而是把每次调用的输入规模压下来。 于是就有了预切分这条路。把长文档按标题、段落或固定字数切成块，逐块解析再汇总，好处很直接：单次输入可控、成本可预估、可以并行、失败重试的代价也小。对于字段抽取、要点归纳这类任务，切分后的准确率甚至比整篇投喂更高，因为模型面对的上下文更干净，噪声更少。 但预切分有它自己的代价。跨块的指代会断掉，“上述条款”“该公司”“前一项数据”这类表述一旦离开原段落就失去指代对象；表格与跨页附注被切开后，表头和数据行分属两块，抽取结果容易错位；需要跨章节比对的问答，比如两份协议条款是否冲突，切分后基本无法完成。切得越碎，单块越干净，全局语义的损失却越大。 反过来，完全不切分也不能算稳妥。整篇输入会稀释注意力，模型对中段的利用率下降；长请求占用资源更久，在并发受限的服务上容易触发超时；一旦超出窗口，要么被静默截断，要么直接报错，而截断往往发生在一份文档的中间，结果看起来正常，实际已经丢了关键内容。切与不切，本质是在局部精度和全局视角之间做取舍。 比较务实的做法是分层处理。先用版面解析把PDF、Word里的标题层级、表格、页码转成带锚点的结构化文本，再按语义边界分块，块之间保留一定重叠，并把所属章节路径写进每块的元数据。检索阶段先定位相关块，回答阶段把命中块和相邻块一起送入模型，必要时补一层全局摘要作为背景。这样既控制单次输入规模，又给跨块推理留了线索。 回到选型，只看窗口数字没有意义，建议按四件事做验证。第一是有效上下文压测，用针在草堆和跨章节多跳问题测中段召回，而不是只问文档开头的内容。第二是长输入的成本模型，按真实调用次数与单次输入量推算账单，而不是看单次单价。第三是延迟与并发，测首token延迟、长请求下的排队表现，以及是否存在按长度分级的限流。第四是边界行为，超窗时是截断、报错还是自动分片，返回里有没有明确的用量与截断标识。 在真实验证阶段，入口的选择会直接影响试错成本。快米兔的模型API中转采用按量计费，注册送5元测试金，用同一入口就能切换不同国产模型做长文本对比。对需要先跑一轮压测、再决定长期方案的团队来说，这种低门槛起步方式省掉了分别开户、分别适配的麻烦，也更容易把有效上下文、延迟和账单放进同一张表里比较，具体额度与计费细则以官方说明为准。 把这些算清楚，选型方向自然会收窄。先判断业务是局部抽取还是全局比对，再决定切分粒度，最后拿手上的真实文档去压测有效窗口、成本和延迟，比追着参数表上的数字跑更靠谱。长文本能力从来不是一个可以单看宣传口径判断的指标，它更像一套需要和业务文档一起调出来的工程参数。