流式推理原理：Token 级流式输出的工作机制
大家好，我是你们的老朋友。今天咱们来聊聊流式推理。
说实话，我第一次接触流式推理这个概念时，脑子里想的是「这不就是边算边输出吗？有啥难的？」。结果真上手做项目，才发现坑不少。嗯，今天我就把这块掰开了揉碎了讲清楚。
非流式推理：等全部算完再给你
先说说传统的非流式推理。你想想看，大模型生成文本时，其实是一个 token 一个 token 往外蹦的。但非流式模式下，模型会憋着一口气，把所有 token 都算完，然后一次性返回给你。
举个例子：
用户输入："请写一首关于春天的诗"
模型内部计算：
Step 1: 生成 "春"
Step 2: 生成 "眠"
Step 3: 生成 "不"
Step 4: 生成 "觉"
Step 5: 生成 "晓"
...
Step N: 生成 "。"
最终返回："春眠不觉晓，处处闻啼鸟。"
看到了吗？用户得干等着，直到最后一个 token 生成完毕。我在项目中遇到过，用户等个几十秒，界面一片空白，体验极差。
流式推理：边算边吐，Token 级输出
流式推理就不一样了。模型每生成一个 token，立刻通过 HTTP 流或 WebSocket 推送给客户端。客户端可以一边接收一边展示。
还是刚才的例子：
用户输入："请写一首关于春天的诗"
模型流式输出：
Step 1: 输出 "春" → 客户端显示 "春"
Step 2: 输出 "眠" → 客户端显示 "春眠"
Step 3: 输出 "不" → 客户端显示 "春眠不"
Step 4: 输出 "觉" → 客户端显示 "春眠不觉"
...
Step N: 输出 "。" → 客户端显示 "春眠不觉晓，处处闻啼鸟。"
说白了，就是用户不用等到全部算完。第一个 token 出来就能看到，后面的内容像打字机一样逐字出现。我个人习惯把这种效果叫做「打字机效果」。
流式 vs 非流式：内存与延迟的差异
好，接下来咱们用数据说话。我直接上对比表格：
| 对比维度 | 非流式推理 | 流式推理 |
|---|---|---|
| 首 token 延迟 | 等于全部生成时间 | 仅需第一个 token 生成时间（毫秒级） |
| 总延迟感知 | 用户感知 = 全部时间 | 用户感知 ≈ 首 token 时间（后续内容逐步展示） |
| 内存峰值 | 需要缓存完整输出序列 | 只需缓存当前 token 及 KV cache |
| 显存占用 | 较高（需存储完整输出 logits） | 较低（逐 token 释放） |
| 网络传输 | 一次性传输大 JSON | 多次传输小数据包 |
| 适用场景 | 离线批量处理、文档摘要 | 实时对话、代码补全、搜索建议 |
这里我要特别强调一下内存差异。我曾经踩过一个坑：用非流式跑一个 2048 token 的生成任务，显存直接爆了。为什么？因为非流式模式下，模型需要把整个输出序列的 logits 都存下来，才能做 beam search 或者采样。而流式模式下，每生成一个 token，之前的 logits 就可以丢弃了。
流式推理的核心机制：Token 级流水线
流式推理能实现的关键，在于 TensorRT-LLM 内部的流水线设计。我画了一张图，帮你理解这个过程：
从这张图你能看到，流式推理的核心就是「边生成边输出」。每个 token 一旦生成，立刻通过流式通道推送给客户端，不需要等后面的 token。
实际部署中的注意事项
好了，理论讲完了，咱们聊聊实战。我在 TensorRT-LLM 中部署流式推理时，总结了几个要点：
- KV Cache 管理：流式模式下，KV cache 是逐 token 增长的。我建议用预分配策略，避免频繁内存分配带来的性能抖动。
- 批处理兼容性：流式推理可以和动态批处理结合。但要注意，不同请求的生成长度不同，需要处理好 padding 问题。
- 超时处理：我曾经遇到过客户端断连后，服务端还在继续生成的情况。一定要加超时机制，避免资源浪费。
- 流式协议选择：我个人推荐用 SSE（Server-Sent Events），比 WebSocket 轻量，而且浏览器原生支持。
最后说一句，流式推理不是银弹。如果你的应用场景是离线批量处理，非流式反而更高效。但如果是实时交互场景，流式推理几乎是必选项。你想想看，ChatGPT 为什么体验那么好？流式输出功不可没。
好，今天就聊到这儿。下一章咱们会深入 TensorRT-LLM 的流式推理 API，手把手教你实现一个流式推理服务。