一、预处理阶段的延迟分析与优化

1. Tokenizer 的隐蔽开销

Tokenizer 是将自然语言文本转换为模型可处理的 Token ID 序列的组件。在大模型推理中，Tokenizer 的耗时往往被严重低估——对于长文本输入（如数千 Token 的上下文），分词操作本身可能占用数十毫秒。

分词延迟主要由两个因素决定：算法复杂度和实现效率。BPE 和 WordPiece 等主流分词算法在最坏情况下需要对输入文本进行多次扫描合并。实际工程中可以通过以下方式降低分词延迟：

分词缓存：对常见的系统提示词模板做预分词并缓存 Token ID 序列——用户输入中前置的系统提示词部分无需每次重新分词。

批量分词：当多个请求共享相同的系统前缀时，仅对差异部分执行增量分词。

高效实现：对比 Python 原生实现，使用 Rust 或 C++ 编写的分词器在处理长文本时可以有数倍的速度差异。

2. 上下文构建的流程优化

分词完成后的 Token ID 序列需要与对话模板、系统提示词、历史对话记录合并为完整的输入上下文，再进行填充或截断以满足模型的最大上下文长度限制。

这一阶段的优化重点在内存预分配和零拷贝拼接。Token ID 缓冲区可以预先分配为模型最大上下文长度的尺寸，新请求的 Token 序列直接写入缓冲区，规避反复的数组重新分配和复制。对于流式对话场景，每次追加新消息时不需要重新构建全部历史——仅追加增量部分，在缓冲区中维护历史与增量的指针即可。

3. 输入校验与安全扫描

预处理阶段还包含输入的合法性校验和安全扫描。校验的范围通常包括：Token 长度是否超出限制、是否包含特殊控制字符、是否触发敏感词过滤规则。安全扫描的延迟取决于规则集的规模和匹配算法的效率——对于数百条规则的关键词匹配，基于 Aho-Corasick 自动机的多模式匹配算法可以将扫描耗时控制在微秒级。

二、推理计算阶段的延迟优化

1. 首 Token 延迟与逐 Token 生成

大模型推理的延迟分为两个关键指标：

TTFT（Time To First Token）：从请求到达到第一个输出 Token 生成的延迟。TTFT 包含了完整的输入预处理和 prompt 处理阶段——模型需要一次性地处理整个输入上下文，计算所有位置的注意力。TTFT 对用户体验影响较大，用户等待第一个字的出现往往是焦虑感最集中的时段。

TPOT（Time Per Output Token）：首 Token 之后每个后续 Token 的生成时间。这一阶段是自回归的解码过程，每个 Token 的生成依赖前一个 Token 的注意力状态，计算量相对恒定。

优化策略需要区分这两个指标：TTFT 的优化侧重于 prompt 处理的并行度（增大预填充的批次或使用分块预填充），TPOT 的优化侧重于单步解码的计算效率（算子融合、KV Cache 管理）。

2. KV Cache 的显存管理

KV Cache 是 Transformer 解码过程中缓存的历史 Key 和 Value 矩阵，用于在生成每个新 Token 时规避重复计算。KV Cache 的显存管理直接影响推理服务的吞吐量和延迟：

预分配与动态扩展。为每个请求预分配固定大小的 KV Cache 空间——空间大小等于最大上下文长度乘以每层的 KV 维度再乘以层数。对于实际上下文较短的请求，预分配造成了显存浪费。动态分配策略根据实际上下文增长按需扩展 KV Cache，在显存效率上更优，但需要精细的内存管理以规避碎片化。

跨请求共享。对于使用相同系统提示词的多个请求，其系统提示词部分的 KV Cache 完全可以共享——不必为每个请求单独计算和存储。这一优化在 API 服务场景中效果显著：数百个请求共享一套系统提示词的 KV 状态，节省的显存和计算量相当可观。

3. 连续批处理

传统的批处理模式下，一个批次中的所有请求必须同时完成——最长的那个请求决定了整个批次的完成时间。连续批处理打破了这一限制：当某个请求生成了终止符、达到了最大长度或触发了早停条件时，立刻将其从批次中移除，同时注入等待队列中的新请求。

连续批处理的效果是将 GPU 的利用率从长板约束中解放出来。在请求时长分布差异较大的生产场景（短请求几秒完成、长请求持续数十秒），连续批处理可以将 GPU 利用率从很低的区间拉到接近满负荷。

三、输出交付阶段的延迟优化

1. 流式输出的协议选择

流式输出是降低用户感知延迟的最直接手段——在第一个 Token 生成后即刻发送到客户端，而非等待全部内容生成完毕。流式传输的协议选择影响传输效率：

SSE（Server-Sent Events）：单向文本流的简洁协议，浏览器原生支持 EventSource API，适合 Web 端的流式对话。协议开销极低——每个事件仅需少量前缀和换行符。

WebSocket：全双工通信，支持客户端中途取消请求。在需要双向通信（如语音对话、多模态交互）的场景中更为合适。

分块传输编码：在 HTTP/1.1 中通过分块传输实现流式响应，HTTP/2 和 HTTP/3 原生支持数据帧的分段发送。通用性最好的方案，适合 API 而非浏览器直连的场景。

2. 输出 Token 的解码与格式化

Token ID 从模型输出后需要经过解码器转换回可读文本。解码器的效率直接影响 TPOT 之后的"最后一跳"延迟。关键优化点在于：

增量解码：不对全部已生成的 Token 序列重新解码——仅解码最新生成的 Token，将其追加到已解码文本的末尾。

特殊 Token 过滤：在流式输出中自动过滤表示对话角色切换、对话结束等特殊控制 Token，仅向用户交付可读文本。

3. 后处理与内容过滤

输出文本在发送前可能需要经过格式校验、敏感词过滤、Markdown 转义等后处理步骤。这些步骤需要以流式方式执行，而非等待全部文本生成完毕——否则就抵消了流式输出的延迟优势。

流式后处理的核心思路是窗口式处理：维护一个滑动窗口，窗口内的文本已经过完整的后处理，可以安全发送。新生成的 Token 不断追加到窗口尾部，窗口头部不断移出已发送的文本。窗口尺寸在延迟与准确性之间做出取舍——窗口越小处理越快，但某些过滤规则需要跨 Token 的上下文。

大模型推理的延迟优化是一个贯穿整个请求生命周期的系统性工程。预处理阶段的 Tokenizer 加速和上下文复用减少了"计算开始前"的等待，推理阶段的 KV Cache 管理和连续批处理提升了"计算进行中"的效率，输出阶段的流式交付和增量解码缩短了"结果抵达用户"的路径。三个阶段的优化叠加，才能让推理服务既快又稳，将 GPU 算力真正转化为用户的即时体验。