分析 LLM 流水线：推理之外的性能瓶颈

你的团队刚刚花了三周时间优化推理。你们换成了量化模型，调整了批处理策略，成功缩短了 12% 的首字延迟 (TTFT)，然后上线了。接着你查看了实际的面向用户的延迟，发现几乎没有变化。

这就是“推理陷阱”。它是 LLM 应用中最常见的性能分析失效模式，其发生的原因是工程师们习惯于测量那些容易测量的指标——GPU 利用率、推理吞吐量、每秒 Token 数 (TPS)——而不是真正缓慢的部分。在一个典型的 RAG 流水线中，如果包含所有涉及 GPU 的环节，推理大约占延迟的 80%。但剩下的 20% 通常分布在六七个没人追踪的阶段中。孤立地看，每一项似乎都很小，但它们共同占据了主要的优化空间。

真实流水线延迟预算剖析

要了解时间花在了哪里，你需要的是端到端链路追踪 (trace)。不是 GPU 分析器。也不是单阶段计时器。而是一个分布式追踪，它能捕获从用户查询到达时刻到最后一个 Token 流式返回的每一个阶段。

在一个具有代表性的生产级 RAG 系统中，延迟分解大致如下：

• LLM 生成：650ms (81%)
• 开销 (上下文组装、编排、序列化)：70ms (9%)
• 向量检索：45ms (6%)
• 查询嵌入 (Embedding)：35ms (4%)

乍一看，这似乎证实了“推理优先”的直觉——81% 的时间花在生成上，所以要优化生成。但看看你面对的是什么：从生成中削减 10% 可以节省 65ms。而完全消除序列化开销可以节省 70ms——且通常所需的工程工作量更少。与此同时，通过一个简单的异步重构将检索和嵌入阶段改为并行运行，可以将它们完全从关键路径中剔除。

真正的关键问题不在于“哪个阶段耗时最长？”，而在于“考虑到每工程周的投资回报率 (ROI)，哪些阶段值得攻克？”

隐藏的瓶颈在哪里

文档预处理与摄取

大多数团队只对 LLM 调用添加了计时监控，其他一概全无。检索上游的阶段——文档解析、分块 (chunking)、格式转换、去重——都是不可见的。这是第一个意外发生的地方。

文档预处理是 CPU 密集型的，通常在流水线其他部分开始之前同步运行。如果你的摄取流水线在生成嵌入之前需要解析 PDF、规范化空格、按段落边界拆分并过滤噪音，那么在任何 I/O 请求发出之前，你就已经在处理数十毫秒的串行任务了。在一个每秒有 50 个请求到达的高吞吐量系统中，这种 CPU 争用就会变成排队。

常见的错误是逐个文档地将分块内容加载到嵌入模型中，而不是批量处理。即使是中等规模（16–32 个文档）的批量嵌入请求也能显著降低单个文档的开销，但团队往往默认采用顺序处理，因为这样写起来更简单。

Token 计数重复运行

在生产流水线中反复出现的一种特定反模式是：对同一段文本进行两次 Token 化。团队在调用模型之前会验证提示词 (prompt) 长度（以避免超过上下文限制），然后推理库在内部又会进行一次 Token 化。在提示词由许多检索到的分块组装而成的流水线中，这种双重 Token 化增加了可感知的开销——而且这完全是无用功。

修复方法是将预计算的 Token 计数传递给客户端库或缓存 Token 化结果，但只有当你意识到双重处理正在发生时，你才能进行修复。如果没有逐阶段追踪，你永远发现不了它。

同步检索阻塞生成

在大多数 RAG 流水线中，影响力最大的单项修复是并行化独立阶段。一个典型的顺序流水线串行运行五个阶段：接收查询、嵌入查询、检索文档、组装提示词，然后调用模型。第二和第三阶段都是网络 I/O，且互不依赖。从查询到达的那一刻起，它们就可以并发调度。将它们转换为异步并行调度可以从关键路径中消除嵌入和检索的延迟总和，取而代之的是两者中的最大值。

如果嵌入需要 35ms，检索需要 45ms，顺序执行耗时 80ms。并行执行耗时 45ms。你没有动模型、索引或嵌入服务——你只是改变了调用顺序。

这是每小时工程时间能带来最高延迟收益的架构变更，而在你拥有延迟瀑布图追踪之前，它是不可见的。

流水线阶段之间的序列化

智能体 (Agents) 和多阶段流水线经常需要对中间结果进行序列化以便在阶段间传递——例如对检索到的分块进行 JSON 编码、封送 (marshaling) 工具调用结果，或者为子智能体之间的交接打包上下文。这些操作单独看很快，但在具有多个跳步 (hop) 的流水线中会产生累加效应。一个在每个边界都进行序列化和反序列化的五阶段智能体，会给每个请求增加一项可观的固定税。

修复方法很少会有多复杂：当阶段处于同一进程中时直接传递结构化对象，只在真正的服务边界处进行序列化。但只有当序列化在你的追踪中显示为一个 span 时，你才会知道自己面临的问题。

加载中…