流式输出是怎么分片的？服务端边算边发

大模型的流式输出，是服务端每生成一小段就发送一小段的传输方式。解码本身是一个字一个字进行的，流式做的事就是把这个节奏透传给用户：屏幕上文字持续出现，而不是等整段写完才一次性给到，等待感因此被大幅摊薄。

分片的单位是什么

分片的单位通常是若干 token 组成的小块。模型每写完一个 token，服务端就把它并入手头的小块，攒够大小或等够时间就发一次，不纠结单次发多少。

块太小，网络包数量暴涨，连接开销不划算；块太大，又会在屏幕上造成一顿一顿的感觉。分片大小就是在流畅感与传输开销之间找平衡，不同产品的手感差别主要来自这里。

网络质量也在这个环节起作用。同样的分片策略，网络抖动会让到达节奏忽快忽慢，屏幕上出现一顿一顿的观感，用户常把这种网络造成的停顿误判成服务变慢。判断方法简单：换个稳定网络再试一次，观感恢复顺滑就说明问题在链路不在服务。顺带一提，弱网下某些产品会自动加大分片，宁要连贯不要逐字，这也是手感差异的来源之一。

服务端怎么边算边发

解码循环每转一圈产出一个新 token，服务端在这个循环上加了一个发送动作：算出即发送，发完继续算下一圈。计算与传输因此可以重叠进行，不必互相等待。

这种重叠摊薄了延迟。整段写完再发送，用户等待的是全部生成时间；边算边发，用户从第一个字就开始阅读，总感知时间明显缩短，长回答的差距尤其大。

分片大小的影响

分片大小影响两件事：界面的流畅程度和连接的负担。小分片更接近逐字效果，大分片更像几句一顿，两种手感在不同产品里都能见到，没有统一标准。

另一个隐藏影响是取消的及时性。分片发得越勤，中断信号越容易在两次发送之间生效，用户按停止时画面收尾越干脆，这也是流式交互体验的细节来源。分片策略还会影响中断信号的传播时机，两片之间是信号生效的天然窗口，发送间隔越规律，取消的收尾越干脆。窗口规律也解释了为什么停止按钮有时立竿见影、有时慢半拍。

与一次性返回的差别

一次性返回把整段结果写完再给用户，好处是内容完整、便于程序处理，代价是等待期内界面没有任何反馈，用户不知道系统是死了还是在想。流式输出用完整性换即时感。

两条路线的账按四个方面并排，差别一眼可见。

选择哪种方式取决于场景：给人看的对话适合流式，给程序用的接口适合一次性，两者也可以混合，比如先流式给摘要，再一次性给完整结果。在豆包、Kimi 等产品的对话界面里，打字机效果就是流式的典型呈现。日常体验里还有一个细节值得留意：复制正在生成的答案，往往只能复制到已显示的部分，这也是流式的自然结果，等收尾完成再复制才完整。想进一步了解传输与调度的关系，可以读连续批处理调度、请求队列怎么排和流式下的中途取消。

速查表：

• 分片单位？若干 token 组成的小块
• 为什么快？计算与传输重叠，边算边发
• 手感由什么决定？分片大小与发送节奏
• 适合谁？给人看的对话，程序接口另说

关于流式输出，问得最多的三个

• 流式输出会更费流量吗？：会略增，包数量变多，但增量很小，相比体验提升通常划算，不必为此关掉流式。
• 为什么不同产品吐字节奏不一样？：分片大小与发送策略不同，这是产品工程选择，不是模型快慢的差别，别拿它比模型性能。
• 流式输出支持中途取消吗？：支持，而且分片越勤取消越及时，这也是它相比一次性返回的体验优势之一。