流式输出的顺序是怎么保证的？分片组装

大模型流式输出时，文字一段一段到达你的屏幕，顺序却从不出错。多路分片、网络乱序、断线重连都拦在中间，顺序不会自己变对，全是机制在兜底，这套机制叫分片组装。

分片是怎么编号的

服务端把生成流切成小片，每片带序号，像寄快递一样贴上单号。进来的是连续的生成流，发生的是切片与编号，出去的是一串有序的小包。切片大小有讲究：切太大一片延迟高，切太小头部开销重，通常按几百毫秒的输出量切一刀。

编号是顺序的根基：下游不关心到达先后，只认序号归位。没有编号，乱序一到就只能靠猜；有了编号，乱序只是到得早晚的问题。编号从零起还是从一起、断线后从哪里续，这些约定要双方一致，属于协议的一部分，改约定就得双方同时升级。

序号的载体还要防损坏：每片带序号加校验值，接收端先验校验再入座，坏片直接丢弃等重发，不占座位不占渲染，屏幕上永远只见完好内容。

乱序到达怎么归位

网络传输不保证先发先到：相邻两片可能颠倒次序抵达。接收端维护一个按序号排座的缓冲区，先到的先入座，缺号的空着等，序号连续了才往外放。进来的是乱序小包，发生的是按号入座，出去的是严格有序的输出流。

归位只是基础，展示端还要做增量渲染，序号连续的内容才允许上屏，屏幕上看到的永远是连续的。等不等得起有个时限：缺的那片迟迟不来，接收端按超时策略请求重发，而非无限干等。等待窗口太短频繁重发，太长卡住输出，两头都要拿捏。缓冲区要有上限：缺号等太久，缓冲堆积会吃内存，到顶就主动断开重连，用对账机制恢复，比无限缓冲更可控。归位过程对用户透明，偶尔的网络抖动只表现为输出稍顿一下，不会出现前后句对调。

断流补块怎么做

断线重连是更极端的情况：连接断了，已发送的片段不能丢。断点续传靠确认机制，接收端定期回报自己收到的最大连续序号，重连后服务端从这个序号之后补发。进来的是重连请求，发生的是对账补发，出去的是无缝续上的输出。对账机制也保护服务端：没有确认就不知道补发范围，重复发整段既费带宽又容易出错。

你在 Kimi、腾讯元宝里流式读长回答时切换网络，内容从断处接着走而非重头再来，背后就是序号、缓冲、确认三件套在配合。顺序保证并不神秘，靠的是规矩。补发也有粒度：从缺号处逐片补，或按窗口整段补，整段补实现简单、浪费一点带宽，逐片补省带宽、状态管理复杂，按团队擅长的来就行。重连后的提示也很关键：界面上短暂显示已恢复，比无声续上更让人安心，机制之外还有一层体验设计。

编号、归位、重发、续传四件事，各自的输入输出与兜底规则。

• 速查：切片必编号；乱序靠缓冲归位；缺号限时补发；重连按最大连续序号对账续传；上屏内容永远连续。

组装是流式链路的最后一环，前面还有：保首字还是保整段？两种服务策略决定要不要流式，提示缓存的失效是怎么发生的？关键步骤一次讲清关系重复内容的速度，多租户的隔离是怎么做的？互不干扰保证各家的流不串台，思考预算是怎么在推理时执行的？则管着流的上游产出节奏。

聊聊流式组装的常见疑问

• 乱序是网络坏了吗？：不算，多路径传输下顺序颠倒很常见，编号机制本来就为它准备。
• 输出会重复一段吗？：去重靠序号，同号只收一次，重复到达会被丢弃。
• 组装缓冲会拖慢显示吗？：缓冲只在缺号时等待，序号连续就即时外放，正常无感，卡顿只出现在缺号等待时，缓冲区大小看设备能力，弱机型更要设小。