超时后的部分结果怎么处理？半截答案

大模型生成到一半赶上超时，已产出的半截答案是扔还是留，处理得当能省一次从头再来的算力。长生成任务迟早会撞上几次，处理策略提前想好才不慌。

半截答案是怎么留下的

流式生成时每出一个字都已发往下游，超时触发时服务端并不清空现场：已生成的标记序列被截取保存，附带状态说明它停在哪个位置。进来的是超时信号，发生的是现场截留，出去的是一段带断点的半成品。截留动作要快，超时信号一到就冻结现场，拖久了下游已经开始等下一条，现场就不干净了。

留多少也有讲究：停在句子中间的尾巴读不通，有的实现会回退到最近的完整句或段落边界，宁可短一点也要拿得出手。

断点状态里最值钱的是 KV 缓存：前半段算好的缓存若能一起保住，续写时几乎零重复计算；保不住就只剩文本，续写要重新消化前文，省下的算力打折。

留还是扔的判定

判定看三件事：内容是否可用、断点是否体面、重新生成的成本多高。问答类内容断在哪都勉强能读，代码类断在半行就是废品。体面程度还有一条标准：断点后文是否能独立成段，读起来不像被腰斩。进来的是半成品与元信息，发生的是可用性评估，出去的是保留或丢弃的决定。

超时原因也要一并看：网络抖动导致的中断值得续，模型本身卡死产生的残段不值得留。把原因、断点、内容三条信息一起记进日志，事后复盘才知道留得对不对。判定还要看下游：结果要交给程序解析的，半截结构化输出就是废品；给人读的，残段至少能说明进展，同一截半成品，用途不同价值天差地别。判定也要有时间维度：高峰期的超时可能是排队导致，同样的残段在空闲时段重试反而能续上，处置前看一眼当时的水位。

续写和重开的取舍

保留下来有两条路：一是续写，把半截答案连同断点状态交回模型接着生成，省掉前半段的重复计算；二是重开，扔掉残段完整重生成，结果更连贯但多花一遍算力。成本账要算全：续写省的是前半段计算，但断点状态保存与恢复本身也有开销，短答案重开反而更省。

续写有个隐患：断点处的上下文状态未必能完整恢复，接出来的后文可能风格突变。你在 Kimi、腾讯元宝里遇到回答中途卡住再续上时，前后语气偶尔有细微断层，多半就是续写的痕迹。要不要续，权衡的是省下的算力和接缝的质量。续写还有一道提示工序：把已生成部分原样放进上下文，再加一句接着写的要求，模型才能接住语气，接缝处理得好，多数读者看不出中断过。重开还有个好处：可以顺手升级提示词，让第二次生成比第一次更好，失败反而成了改进的机会。

三条处置路线的账，按省下的算力和接缝质量分开算。

• 自查清单：断点落在完整句？内容单独看能读？超时原因是暂时性网络？短答案直接重开？四条过完再决定去留。

中断处理和别的环节咬合紧密：重试的退避是怎么算的？越等越久决定多久后再试，降级时的小模型是怎么顶上的？机制细节全梳理提供换挡续命的路，异步调用是怎么通知完成的？回调与轮询把长任务挪到后台避开超时，上下文超限的报错是怎么触发的？则是另一类要提前拦的坑。

关于部分结果的三个常问问题

• 半截答案会直接给用户看吗？：看产品策略，有的先展示再补续，有的等续完一次性替换，替换时注意用户已读内容的一致性。
• 续写能保证和原文无缝吗？：不能保证，断点状态恢复不完整时会有接缝，关键场景建议重开。
• 为什么不干脆把超时调长？：等待上限受网关与用户耐心约束，无限等下去体验更差，上限通常是网关链路层层叠加后的结果。