100万Token单次输出上限：工程代价、适用场景与避坑指南

上周把一个二十多万行的老旧业务仓库丢给模型做整体梳理输出到第四万多字的时候被拦腰截断返回里明晃晃写着finish_reason: length。那一刻我才真切意识到单次输出上限这个参数比上下文窗口更早地卡住了很多人的脖子。最近某头部厂商放出的新一代模型把单次输出上限直接顶到了100 万 Token这个量级朋友圈里一片上下文又要卷起来了的声音——但说实话这跟上下文窗口根本不是一回事。这篇东西想聊的就是100 万 Token 的输出能力落到真实工程里到底意味着什么它在服务端要付出什么代价哪些任务真的吃得下这么大的输出以及我在试用类似长输出能力时踩过的那些坑。如果你平时用大模型写长文档、做整库重构、跑批量数据抽取或者在做需要长时间连续产出的智能体这篇应该能帮你少走点弯路。没接触过长输出场景的朋友也能看我会把该换算的单位、该算的账都摊开讲。1. 100万Token的输出上限落到实际工作里是什么概念1.1 先做一次粗糙但有用的单位换算很多人看到100 万这个数字第一反应是牛逼但没什么实感。我习惯先换算成人类能感知的单位。按主流分词器的经验值英文大约是 1 Token 对应 0.75 个单词、4 个字符中文的差异就大了一个汉字可能被切成 1 到 2 个 Token取决于词表和文本类型古汉语、专业术语、生僻字的切分颗粒度会更细。保守一点估100 万 Token 大概能装下六七十万汉字或者七十多万英文单词。这个量级是什么概念一部中长篇小说差不多二三十万字也就是说一次调用理论上能吐出两三本长篇的体量。放到工程场景里一个中等规模的代码仓库比如十万行量级的业务代码加配置完整重写一遍也是够的。但这里有个特别容易混淆的地方我见过不少同事把输出上限和上下文窗口当成同一个指标来比较。真不是。上下文窗口说的是模型一次能看见多少内容输出上限说的是它一次能写出多少内容。前者是输入侧的记忆容量后者是输出侧的产出容量。一个模型可能有几百万 Token 的上下文但输出上限只有几万反过来也有上下文不大但输出很长的模型。这两个数字必须分开看否则你排出来的架构方案会完全跑偏。1.2 上下文窗口和输出上限是两个完全不同的工程指标为什么这两个指标不能混为一谈因为它们在底层走的是两条路径。输入侧的处理叫prefill所有输入 Token 是并行喂进网络一次性算完的GPU 的并行能力能吃满虽然计算量大但吞吐高本质上是一次大矩阵乘法。输出侧的处理叫decode是逐 Token 自回归生成的每生成一个 Token 都要完整跑一遍前向而且下一个 Token 依赖上一个 Token 的结果天然串行GPU 利用率很难打满。这个差别直接决定了成本结构。长上下文贵在一次性的大计算你可以靠批处理、靠更高效的注意力实现来摊薄长输出贵在时间它是硬生生的串行延迟你没办法通过加机器把它压缩到零。我一般跟团队里新人的说法是上下文窗口决定你能不能把一本书塞进去输出上限决定你能不能让它把这本书翻译完。前者是读得下后者是写得完工程含义完全不同。还有一层长输出的质量衰减比长上下文的检索衰减更隐蔽。上下文太长模型找不到中间信息这个错误通常比较明显答非所问但长输出跑到后期开始注水、开始复读、开始偏离最初约束这个错误是渐进的你不逐段核对根本发现不了。1.3 输出比输入难在哪一个字一个字往外挤的解码过程拆开看 decode 的每一步模型拿到当前已生成的全部 Token算出下一个 Token 的概率分布按采样策略挑一个追加到序列末尾然后再来一遍。100 万 Token 的输出意味着这个循环要跑 100 万次。每一次都要把此前所有 Token 的中间状态Key/Value读一遍——这就是后面要重点算的 KV Cache 账。我用生活化的比喻解释给非技术同事听输入像是你把一整箱资料交给一个助理他可以分门别类一次性看完输出像是让他把这箱资料重新誊写一遍只能一个字一个字写写的过程中还得不停回头看前面写了什么保证前后一致。写一万字和写一百万字累的不是手是回头看的次数。所以当我看到单次输出 100 万 Token这种规格时第一反应不是能写好多而是服务端得为这个串行过程准备多少资源、花多长时间。这个念头一旦起来后面所有的选型判断都会变得冷静很多。2. 百万级输出背后的资源账显存、时间与调度2.1 解码耗时怎么估一个粗算公式加实测修正先说时间。假设单请求的生成速度是每秒 40 Token这个数字在不同硬件、不同批处理规模下差异很大个人实测在独占资源时能到 60 到 80混在共享队列里可能只有 15 到 25那么 100 万 Token 需要 25000 秒接近7 个小时。即便是每秒 100 Token 的理想情况也要将近 3 小时。这个数字一出来很多场景就直接被判死刑了。你不能指望用户在对话框里等三个小时。所以我评估长输出任务时第一条判断标准就是这个产出是同步消费还是异步消费。同步消费用户盯着屏幕等结果基本别想除非任务本身只需要几万 Token异步消费后台跑批、夜间任务、离线生成才谈得上用百万级输出。提示粗算时用预计Token数 / 实测单请求TPS然后把结果乘 1.5 作为排队和网络开销的缓冲。别用厂商宣传的峰值吞吐去算那个数字通常是在最优批处理条件下测出来的跟你实际拿到的单请求速度不是一回事。还有一个容易被忽略的点长输出的时间不是线性的。序列越长注意力计算里跟长度相关的部分占比越高单 Token 的生成耗时会缓慢上升。我在一个生成 8 万 Token 的任务里测过前 1 万 Token 平均 38ms/Token到最后 1 万 Token 平均涨到了 52ms/Token涨了差不多三成。做容量规划时这个曲线得考虑进去。2.2 KV Cache 的显存占用为什么长输出是服务端的噩梦这是我认为最值得讲清楚的一笔账因为它解释了为什么支持百万输出不是改个配置项就能上线的事。每生成一个 Token模型每一层都要缓存这个 Token 的 Key 和 Value 向量供后续 Token 计算注意力时使用。用现在流行的分组查询注意力GQA架构估算单 Token 单层的 KV 缓存大小约等于2 × KV头数 × 头维度 × 每元素字节数。假设 32 层、8 个 KV 头、头维度 128、FP16 存储每元素 2 字节那么单 Token 单层 2 × 8 × 128 × 2 字节 4 KB 单 Token 全模型 4 KB × 32 层 128 KB这意味着每 1000 个 Token 的缓存约 128 MB。跑到 100 万 Token 时单个请求的 KV Cache 就是128 GB 左右。这个体量已经超过绝大多数单卡的显存容量了。所以长输出请求在服务端必须做特殊处理分页管理显存把 KV Cache 切成块不要求物理连续、把不活跃的缓存换出到主机内存、甚至落到高速存储上再按需换回。这些机制都会带来性能损失。分页管理有寻址开销换出换入有带宽瓶颈长序列的注意力计算本身也有额外成本。所以你在 API 层面看到的100 万 Token 输出背后是一整套调度策略在硬撑这也解释了为什么这类请求的单位 Token 价格通常不会便宜为什么会有更严格的并发限制。对你我这样的调用方这个知识点的实际价值在于长输出请求要单独做重试和超时设计。它比普通请求更容易触发服务端的资源调度、更容易在高峰期被排队、更容易在中途断开。把它和普通短请求放在同一个重试队列里是给自己找麻烦。2.3 长输出会把采样参数的所有小毛病放大短输出场景下采样参数的影响是局部的。temperature 调到 0.9 写个五百字顶多是风格活泼一点放到十万字的长输出里高温度累积的随机性会让文本在后半段慢慢跑偏主题甚至开始自造事实。我的经验是长输出要把 temperature 压下来一般 0.3 到 0.6 之间需要创意发散的任务可以到 0.7 但别再往上。top_p 保持在 0.9 左右足够。重复惩罚repetition penalty要慎用这是最容易帮倒忙的参数短文本里它能有效打散复读长文本里它会让模型为了避开重复而刻意换词结果是用词越来越怪到后期语言结构开始崩坏读起来像机翻。真正解决长输出复读问题的不是惩罚参数而是内容结构约束。给模型明确的分节大纲、每节的主题边界、每节要覆盖的要点它就没有空间去原地打转。我在一个需要连续生成两万多字技术文档的任务里对比过纯靠提示词说不要重复后半段还是有明显的车轱辘话换成按这 12 个小节写每节必须包含 X、Y、Z 三个要点之后重复率肉眼可见地降下来了。2.4 流式传输、超时设置与断点续写的工程处理百万级输出的请求你几乎必须用流式接收。原因有两个一是用户至少要看到进度二是很多网关和客户端对单次响应体大小有限制非流式的超长响应容易在中转环节被截断。流式接收的坑在于数据帧的切分。SSE 或分块传输给你的数据块边界跟 Token 边界、跟 JSON 结构边界都不一定对齐一个 JSON 对象可能被切成两半送到你手上。处理方式是按分隔符缓冲收到数据先追加到缓冲区找到完整的分隔符再解析解析不了的部分留在缓冲区等下一块。这个逻辑听着简单但异步流里出错很难复现我建议直接用一个成熟的流式解析库别自己手写状态机。更关键的是断点续写。7 个小时的任务中途断掉的概率不低如果每次断了都从头再来成本和心情都受不了。我的做法是让模型每完成一个逻辑单元一节、一个模块、一批数据就输出一个明确的结束标记客户端按标记切分并落盘记录已完成的单元编号和最后一小段内容。续写时把已完成到第 N 节加上最后一两百字的衔接内容作为上下文传进去让它接着写。这样即使断三次损失的也只是当前这一节。这套机制还有个额外好处产出是增量可见的。你不用等 7 小时才知道结果对不对第一个单元出来就能校验格式和质量发现跑偏了立刻停省下的都是真金白银。3. 哪些活真的吃得下百万Token的输出3.1 整库级的代码理解与批量重构这是我个人认为最有价值的场景。传统做法是把仓库切片一片一片丢给模型各片之间互不知情改出来的东西风格不统一、接口对不齐、公共方法各写各的。有了长输出能力可以让模型一次性读完整个模块的代码然后输出一份完整的重构方案甚至直接输出重写后的全部文件。具体操作上我会这么组织先把目录树、关键文件的完整内容、公共接口定义、编码规范文档作为输入然后要求模型按先出诊断报告再按文件逐个输出重写结果的顺序产出。每个文件用固定的分隔标记包裹标记里带上文件路径。这样输出虽然长但是可解析、可自动落盘。这里有个硬性经验不要让模型写补丁让它写完整文件。长输出场景下模型的 diff 格式极容易出错行号偏移、上下文对不上、缩进不一致人工核对的时间比自己重写还长。直接输出完整文件用脚本覆盖再靠版本控制做差异对比出了问题随时能回滚整条链路清爽得多。还要提醒一点整库重写这种活儿产出量动辄几十万 Token成本真的不低。我一般的做法是先拿一个模块试水评估一下模型在这个代码库上的理解准确率觉得靠谱再铺开。上来就全库跑一遍很容易花了大钱拿到一堆需要返工的东西。3.2 一次性成稿的长文档与结构化写作第二类吃得下长输出的是长篇文档。技术白皮书、产品需求文档、培训教材、长篇报告这些东西的共同特点是结构明确、章节之间有依赖关系、术语和口径必须统一。用短输出分章写最大的痛苦是前后不一致——第三章的术语跟第一章对不上第五章的结论跟第二章的数据矛盾。长输出能缓解这个问题因为模型在同一次生成里记得前面写过什么。但它不是银弹我实测下来超过十五万字之后一致性还是会掉。所以实用的做法是分层一次调用写到章节级别把全书大纲和已完成章节的摘要作为上下文逐章生成。这样既保留了一致性的好处又控制了单次输出的规模。文档类任务还有个特别实用的技巧先让模型输出一份术语与口径表明确这个文档里某个概念统一叫什么、某个指标怎么表述、数字用什么格式。这份表放在提示词最前面作为整篇的写作契约。我在一个涉及大量业务指标的长文档项目里加了这个动作前后不一致的问题少了大概七成。3.3 大批量结构化抽取与格式转换第三类是数据加工。比如把几百份格式各异的合同、报告、工单抽取成统一的结构化记录或者把一批遗留系统的配置文件批量转换成新格式。这类任务的特点是单条记录不长但条数极多。用长输出的思路是一次调用处理一整批把几十上百条原始数据拼成输入要求模型逐条输出结果。这样比一条一次调用省得多——省的不只是调用次数更是每次调用都要重复传一遍系统提示和格式说明的那部分输入 Token。这类任务最大的风险是漏条和错位。模型处理长列表时可能跳过几条或者输出的顺序跟输入对不上。我的应对是强制的序号对齐输入每条数据前面打上[#序号]输出要求严格按序号输出并且每条结果自带序号字段。拿到结果后跑一遍脚本检查序号集合是否完整、是否有重复、是否跟输入一一对应缺的单独补跑。这一步自动化校验绝对不能省人工核对上百条记录的对应关系是会出错的。3.4 长时间运行的智能体中间产物得有个地方沉淀最后一类是智能体场景。一个复杂任务跑几十轮工具调用每一轮的观察结果、推理过程、中间结论都要留在上下文里很快就把窗口撑满了。长输出能力在这里的价值不是一次吐很多字而是允许把中间产物完整地沉淀下来不用频繁压缩、摘要、丢弃历史。具体做法是让智能体在关键节点输出结构化的工作日志当前目标、已完成步骤、关键发现、待验证假设、下一步计划。这些日志累积起来可能很长但它们构成了任务的完整状态。万一执行中断后续可以从日志恢复不用从头再来。不过这里我要泼点冷水上下文长不等于效果好。我试过让智能体不做任何压缩地跑长任务结果到了后期它开始在冗长的历史里迷路反复纠结早期已经解决的问题。后来改成保留完整日志但在每轮开头显式声明当前阶段目标和已排除的路径效果才稳定下来。长上下文是给你更多操作空间的不是让你偷懒不做状态管理的。4. 我踩过的几个坑长输出任务里最容易翻车的地方4.1 前三分之一惊艳后三分之一开始注水这是最普遍也最气人的问题。前面几节写得有细节、有数据、有观点到中间开始变得笼统到最后基本是综上所述该方案具有重要意义这种空话。我一开始以为是温度太高调低了还是这样以为是上下文太长缩短了也没根治。后来想明白了这是训练数据分布的问题。人类写作本来就是开头认真、中间疲惫、结尾草率模型学到的也是这个分布。对抗它的办法不是调参数是改变任务结构把一个大任务拆成多个有明确验收标准的小任务每个小任务都是开头模型就会一直保持开头的认真度。具体到实操我会在提示词里给每一节设定硬性要求比如本节必须包含至少两个具体案例每个案例要有背景、做法、结果三要素禁止使用显著提升有效改善这类无信息量的表述。有了这种可判定的约束注水就很难藏身。4.2 约束条件在中途蒸发长输出跑到后半段模型会慢慢忘掉你在开头定的规矩。开头说全文用第二人称写到中间变成我们认为开头说每个结论必须标注来源后半段就开始裸奔开头说不要用被动语态后面全是被动句。这个现象在长上下文里更明显因为早期的指令被中间大量内容稀释了。解决办法有两个我一般一起用。第一个是锚点复述每完成一个逻辑段落让模型用一句话复述我接下来要遵守的三条核心约束是什么再继续写。这个动作看着多余实测对维持一致性非常有效。第二个是把约束写进输出格式与其在提示词里说每个结论要标来源不如要求输出的每条结论都必须带一个source字段字段为空就说明违反了。让约束变成结构的一部分比让它停留在自然语言指令里靠谱得多。4.3 账单和超时两个被严重低估的隐性成本先说账单。输出 Token 的单价通常比输入高不少百万级输出意味着这一项成本会占大头。我吃过一次亏给一个批量任务设了 generous 的 max_tokens结果模型在每条结果后面都附一段解释性文字本来一条五十 Token 的活干成了三百 Token账单直接翻了五倍。教训是给长输出任务设的 max_tokens 要贴着实际需要别留太大余量。同时在提示词里明确只输出结果不要输出解释、不要复述要求、不要加开场白和结束语。这两条加起来能省下的量很可观。超时是另一个坑。不同客户端、不同网关的默认超时时间差别很大有的是 60 秒有的是 300 秒。长输出任务跑到一半被客户端掐断服务端还在继续算继续计费你这边却什么都没拿到。解决办法是客户端超时设得足够长或者干脆用异步任务接口并且在应用层做心跳检测确认连接还活着。4.4 格式崩坏为什么大 JSON 数组是个坏主意如果你让模型输出一个包含上万条记录的 JSON 数组做好心理准备它大概率会在中途某个位置少一个逗号、多一个括号或者干脆换行位置不对导致整个结构解析失败。而且失败的位置往往在很后面前面的内容全白费。我现在的做法是改用NDJSON每行一个独立的 JSON 对象或者用明确的分隔符把记录隔开。这样单条记录解析失败只影响那一条其余全部可用容错性完全不是一个级别。如果业务上确实需要一个大 JSON就在客户端解析完 NDJSON 之后再拼装把拼装的责任从模型手里拿回来。同理让模型输出 Markdown 表格也要小心列数多了之后对齐很容易乱。我一般限制在六列以内超了就拆成两张表。4.5 校验成本最容易忽略的那笔账百万级输出拿到手你怎么知道它对不对这个问题我在项目初期想得太简单以为抽检几段就行。实际做过一次才发现人工校对几万字的产出时间成本可能超过自己写的成本。所以现在我在设计长输出任务时校验方案跟提示词是一起设计的。能不能自动校验决定了这个任务值不值得用长输出。代码类任务可以做语法检查、类型检查、单元测试结构化数据可以做 schema 校验、字段完整性检查、数值范围检查文档类任务最难自动校验只能做术语一致性检查、章节完整性检查、长度检查这些形式化的东西内容质量还是得人看——这也是我建议长文档任务不要一次拉满、要分章交付的原因。5. 让长输出变得可控提示词、分片与验收的写法5.1 约束前置加上周期性的锚点复述提示词的结构对长输出质量的影响比在短输出里大得多。短输出模型能全局记住你的所有要求长输出里靠前的指令会被稀释。所以我把最重要的约束放在最前面用最简短、最不容歧义的方式写避免长篇大论的需求描述淹没关键规则。一个我常用的模板骨架先用三到五行说明角色和任务目标然后用编号列表列出硬性约束格式、口径、禁止事项接着给输出结构分几个部分、每部分包含什么最后才是素材和参考资料。这个顺序很重要——模型对开头和结尾的内容注意力最集中把最不能违反的东西放在两头。锚点复述的具体写法是在每个大段落的末尾加一句继续之前确认当前仍然遵守一、不使用第一人称二、每个数据点标注来源三、不引入素材中未出现的事实。这句话本身不产出内容但它把约束重新拉回了模型最近的位置。我实测下来加了这句之后后半段的约束违反率下降得很明显。5.2 大纲先行两段式调用比一次拉满更稳我现在几乎不用一次性生成全部这种打法除非任务特别简单。标准流程是两段式第一段调用只让它出大纲包括章节标题、每章要覆盖的要点、预计篇幅、章与章之间的逻辑关系。这一步输出很短成本几乎可以忽略但你可以在这里把所有结构性问题解决掉——章节重复、逻辑跳跃、重点缺失改大纲比改正文便宜一百倍。第二段调用按大纲逐章生成每次生成时带上完整大纲、已完成章节的摘要、以及本章的具体要求。上下文里始终有全局视图又不用一次性扛住全部输出的压力。策略单次拉满大纲 逐章生成结构可控性差改一处要重跑全部好大纲阶段即可纠偏单次失败损失全部产出仅当前章节前后一致性中前期好后期衰减靠摘要维持稳定总调用成本较低无重复输入略高重复传大纲和摘要适合场景结构简单、篇幅中等结构复杂、篇幅很长成本这一项确实是大纲法的劣势每次调用都要重传大纲和摘要输入 Token 会累积。但比起重跑全部产出的代价这点输入成本我认为完全值得。5.3 用结构化分隔符代替自然语言分段长输出要能被机器处理就必须有可靠的边界标记。自然语言的分段接下来我们看第二部分对人是清晰的对解析脚本是灾难。我的做法是给每一段加固定的包裹标记比如用三个特定符号包住块名或者干脆要求输出 HTML 注释形式的边界。标记要满足两个条件一是足够独特正常内容里不会出现二是纯文本不依赖任何渲染。这样正则表达式一抓一个准落盘、切分、校验全部自动化。顺带说一个细节块名里把序号带上。BLOCK:03:refactor-plan这种格式既能排序又能校验完整性比纯名字好用。5.4 验收清单把写得好翻译成能检查最后这一步是很多人的盲区。长输出任务如果没有一份可执行的验收清单质量就完全靠运气。我给自己定的清单通常包含这几项输出块数量是否等于预期、每个块的必填字段是否齐全、字数是否在范围内、术语是否统一用脚本搜几个关键术语的变体写法、有没有出现明显的占位符残留比如此处省略待补充、引用来源是否都有对应条目。这些都能脚本化跑一遍几秒钟。内容层面的验收没法完全自动化我一般抽三段开头一段、中间随机一段、最后一段。最后一段尤其重要因为质量衰减都发生在那儿。如果最后一段还挺扎实整篇基本可以放心。6. 该不该用成本、延迟与替代方案的取舍6.1 长短调用组合的成本对照百万输出不是免费的午餐。我拿一个实际做过的任务算过账把一份约八万字的素材整理成结构化报告方案 A 是一次调用直接输出方案 B 是分成十二次每次处理一个主题。方案 A 的输入 Token 只有一份输出八万字总成本最低但耗时将近一小时中途失败就得重来而且后半段质量明显下滑。方案 B 每次输入要带上全局大纲和已完成部分的摘要输入 Token 翻了一倍多总成本反而高了约四成但每段质量稳定单次失败只损失几千字总耗时因为可以并发跑而缩短到二十分钟以内。结论很清楚成本敏感、结构简单、能接受质量波动就用长输出质量敏感、结构复杂、需要容错就用分段并发。这两个不是替代关系是不同权衡下的选择。真正需要百万级输出的场景其实不多大多数任务的瓶颈不在输出上限而在任务拆解的设计。6.2 什么时候值得一次拉满我总结了几条判断标准符合两条以上才考虑一次拉满任务内部有强依赖分段写会导致前后不一致且这种不一致靠摘要无法弥补比如需要严格保持叙事线索的长篇创作单次调用的输入非常大重复传输的成本高于分段带来的额外开销产出本身就是一次性交付物不需要增量可见也不需要中途干预失败重来的成本可以接受或者有可靠的断点续写机制后续处理完全自动化不需要人工逐段校对反过来只要出现需要人工审阅这一条我就倾向于分段。人工审阅的节奏和机器生成的节奏对不上一次给你八万字你也是分几天看完那还不如让机器也分几批给。我在实际使用中的体会是输出上限这个指标的价值更多体现在它把某些以前根本做不了的事情变成了能做而不是让你把所有事情都改成一次拉满。就像货车的载重量从五吨提到五十吨真正受益的是那些原本要拆成十趟运的大件而不是让你以后买个菜也开货车去。分清哪些是大件比盯着载重量数字本身重要得多。