E8 · 如何优化模型调用的成本与性能？ - Inference Optimization

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：03 · 如何使用和管理 AI 模型？ - Model Engineering
文档类型：技术原理与工程实践研究
版本：v2.0
更新日期：2026 年 10 月 27 日
核心问题：一次大模型推理的时间、计算、显存和费用消耗从何而来？如何测量 TTFT、TPOT、吞吐、尾延迟和有效任务成本？Prefill、Decode、KV Cache、PagedAttention、连续批处理、前缀缓存、量化、推测解码和 Prefill/Decode 分离如何改善性能，又会引入哪些代价？如何为 Agent System 建立可复现的优化与验收方法？

专题导读

随着 AI 模型逐渐成为应用程序和 Agent System 的核心计算能力，如何在保证任务质量与系统可靠性的前提下，提高模型推理效率、降低响应延迟与运行成本，成为模型工程的重要课题。

本篇围绕 Inference Optimization（推理优化）展开研究，从大语言模型的 Prefill 与 Decode 执行过程出发，系统解释计算资源、显存带宽、上下文长度和并发请求如何影响模型性能，并建立 TTFT、TPOT、吞吐量、尾延迟与有效任务成本等指标体系。

在技术机制部分，深入研究 KV Cache、PagedAttention、Continuous Batching、Prefix Caching、量化、推测解码及 Prefill/Decode 分离等主要优化技术，分析其工作原理、适用条件与性能取舍。

在工程实践部分，进一步研究性能瓶颈诊断、推理服务调度、缓存管理和基准测试方法，并结合多步骤研究 Agent 的实际工作流程，讨论模型调用、上下文增长、工具执行、并发调度与失败重试对整体效率的影响。

最终帮助读者建立从性能测量、瓶颈定位到优化验证的完整工程方法，理解如何将单次模型推理优化扩展为面向 Agent System 的系统级性能与成本管理。

一、研究定位：优化的对象是「完成任务的系统」，不只是 Token 速度

在 E7 中，我们解决了「如何让模型在计算环境中运行并提供服务」；E8 进一步解决「服务已经能运行，如何让它在可接受的质量、延迟、可靠性和成本下运行」。二者的边界是：E7 关注模型文件、运行环境、服务部署与运维；E8 关注执行机制、资源利用、工作负载特征和可测量的优化效果。

推理优化不等于简单提高 Tokens/s。假设优化后单次请求快了 20%，但模型错误率上升，导致 Agent 平均每个任务多调用两次模型，那么最终完成一个合格任务的耗时和费用反而可能增加。因此，优化目标应写成带约束的决策问题：

$$\underset{x}{min}{C}_{\mathrm{task}}(x),\text{s.t.}Q(x)\ge Q_{min},P95(T_{\mathrm{task}}(x))\le L_{max},A(x)\ge A_{min}$$

其中 $x$ 是模型、推理引擎、缓存、批处理、并发和应用策略的组合；$Q$ 是任务质量，$A$ 是可用性。此式是工程建模框架，不是任何服务商保证的性能公式。对于实时对话，可以优先约束首 Token 延迟；对于后台研究报告，可优先优化吞吐和成功任务成本。

本篇采用「执行机制 → 指标 → 瓶颈 → 优化技术 → Agent 场景 → 基准验证」的组织方式。读者应能回答：性能瓶颈在何处、为什么某项优化有效、什么时候无效，以及怎样证明改善真实存在。

二、从一次请求看推理的时间线

以常见的自回归 Transformer 文本生成为例：

客户端发起请求
   │ 网络传输 / API 网关 / 身份验证
   ▼
请求进入队列 ──────────────► 调度器决定何时执行
   │
   ▼
Prefill：处理输入 Token，建立或复用 KV 状态
   │
   ▼
Decode：生成第 1 个 Token → 第 2 个 → ... → 第 M 个
   │                   │
   └──────── 流式返回 / 缓冲 / 后处理 ─────────► 客户端完成接收

**Prefill（预填充）**通常将输入 Prompt 的多个 Token 一起处理，计算注意力相关表示并写入 KV Cache；在长上下文下，注意力计算、内存访问和调度都会显著影响耗时。**Decode（逐步解码）**通常每一步生成下一个 Token，并读取历史 KV；小批量场景常容易受权重读取和显存带宽影响，但具体是算力瓶颈还是带宽瓶颈，要看模型结构、批大小、硬件和内核实现。不能把「Prefill 一定是计算受限、Decode 一定是带宽受限」当成普适定律。[S1][S2]

一条请求的端到端耗时可以拆成：

$$T_{E2E}=T_{client}+T_{network}+T_{gateway}+T_{queue}+T_{prefill}+T_{decode}+T_{postprocess}$$

这里的各项在实际系统中可能重叠，例如流式网络发送与后续 Decode 同时进行；因此它是归因模型，不是严格无重叠的计时恒等式。生产排障时必须先确定测量边界：从客户端发起到收到首个字节，还是从服务端接收到请求到生成首 Token？否则不同服务之间的指标不能直接比较。

2.1 为什么输入长度与输出长度的成本不同

Prefill 一次处理输入序列；Decode 每产生一个新 Token，通常需要对模型再执行一次增量前向计算。相同的 2,000 Token，若属于输入与若属于输出，其延迟和计费可能显著不同。输入还可能受 Prefix Cache 命中影响，而输出长度与交互体验、循环次数密切相关。对于 Agent，长系统提示词、工具结果和历史轨迹会不断增加输入长度；长篇推理、长文生成则会增加 Decode 负担。

2.2 并发改变了最优策略

单用户独占 GPU 时，减少单次请求等待可能最重要；多个用户同时请求时，调度器需要在吞吐、首 Token 延迟和公平性之间权衡。提高并发不保证吞吐线性提高，因为 KV Cache 占用、队列拥堵和设备容量会逐渐成为约束。优化应针对目标流量，而非只针对一条离线请求。

三、性能指标：先统一口径，再比较优化

指标	含义与常见计算口径	容易误解的地方
TTFT（Time to First Token）	从请求起点到首个生成 Token 到达的时间	网络首字节不一定就是模型首 Token；非流式接口无法准确从客户端分离
TPOT（Time per Output Token）	常见口径为 $(T_{last}-T_{first})/(N_{out}-1)$，要求 $N_{out}>1$	不同实现可能报告平均间隔或服务端内部耗时，必须注明口径
ITL（Inter-Token Latency）	相邻输出 Token 到达间隔的分布	平均 TPOT 会掩盖单次卡顿，需看 P95/P99
E2E Latency	完整响应可用的总时间	工具调用、网络重试可能未包含在模型服务指标中
吞吐（Throughput）	请求/s、输入 Token/s、输出 Token/s	三种指标不能混为一谈；负载变化会改变数值
P50/P95/P99	某类延迟的分位数	样本量、负载、失败样本和统计窗口影响结论
Goodput	满足质量、时限等条件的有效工作量	单纯提高 Token/s 未必提高 Goodput
失败率与超时率	错误、超时、取消、重试的占比	忽略失败请求会使性能数据虚高
GPU 利用率/显存占用	设备资源使用情况	高利用率不一定意味着高业务效率
成功任务成本	总资源与调用费用 ÷ 合格任务数	最接近 Agent 业务目标，但需要定义「合格」

示例（纯计算，不是实测）：某次流式请求从发起到首 Token 用 0.8 秒，最后一个 Token 在第 5.75 秒到达，总共收到 100 个 Token，则按照上表口径，TPOT = (5.75-0.8)/99 = 0.05 秒/Token，即约 20 输出 Token/s。不能直接用 100/5.75 替代 TPOT，因为后者混入了首 Token 等待。

一个建议的服务级目标可以写成：在「输入 1k-2k、输出 200-400 Token、并发 16、固定模型与硬件」的流量下，P95 TTFT ≤ 2 秒、P95 E2E ≤ 15 秒、失败率 < 1%。这些数值仅是目标写法示例，不是行业通用标准。必须依据产品和用户需求设定。

四、性能瓶颈诊断：从现象反推资源约束

推理性能首先是一个诊断问题，而不是「把所有优化开关打开」的问题。建议按以下顺序定位：

1. 服务入口：客户端和网关延迟是否显著？是否发生 TLS、代理、跨区域网络开销？
2. 排队与调度：TTFT 在高峰期激增，但空闲时正常，是否是请求积压、KV 空间不足或调度优先级问题？
3. Prefill：长输入的 TTFT 随输入长度急剧增长，是否需要分块预填充、前缀复用、上下文压缩？
4. Decode：首 Token 很快，但后续输出缓慢，是否受权重读取、KV 读取、内核或并发竞争影响？
5. 内存与容量：请求失败、被驱逐、重复计算，是否与 KV Cache 容量、碎片化、最大序列长度和并发有关？
6. 应用调用链：模型本身很快，但 Agent 总任务很慢，是否是串行调用、工具等待、重试、无效上下文导致？

可用简单的性能归因表：

现象	优先检查	不应立即得出的结论
长 Prompt TTFT 高	输入 Token、Prefill、前缀命中、队列	一定需要更快的 GPU
输出 Token 间隔大	Decode、批大小、权重/缓存带宽、调度	一定是网络问题
并发升高后 P99 恶化	排队、KV 容量、抢占、资源争用	吞吐上升就意味着用户体验改善
GPU 显存已满	权重、KV、临时缓冲、碎片化	模型权重一定太大
Agent 费用高	调用次数、上下文、失败重试、工具回路	必须更换最便宜模型

4.1 Roofline 思想的适用范围

Roofline 将计算性能与算术强度（FLOPs/读取字节数）联系起来：当算术强度较低时，带宽可能成为瓶颈；较高时可能受峰值计算能力限制。它适合建立推理的一阶判断，但不能替代 Profiling：实际还受内核启动、通信、调度、Attention 实现、并行策略与不规则负载影响。Prefill 与 Decode 的算术强度随批大小和序列形状变化，因此应根据实测判断。

五、KV Cache：为什么它能加速 Decode，又为什么会吃掉显存

5.1 工作原理

在 Transformer 注意力层中，每个 Token 产生 Query、Key、Value。生成下一个 Token 时，若重新计算全部历史 Token 的 Key/Value，会产生大量重复工作。KV Cache 保存历史 Token 的 K/V 张量，Decode 时只需要计算新 Token 的表示，再读取历史缓存完成注意力。这样减少重复计算，但引入持续增长的缓存内存。[S3][S4]

对于标准、未压缩、未采用滑动窗口的自回归注意力缓存，近似容量为：

$$M_{KV}=2\times L\times B\times S\times H_{kv}\times D\times b$$

其中 $L$ 是 Transformer 层数，$B$ 是并发序列数，$S$ 是每条序列缓存 Token 数，$H_{kv}$ 是每层 KV Head 数，$D$ 是每个 Head 维度，$b$ 是每元素字节数，系数 2 代表 K 和 V。该式忽略块分配、元数据、内存对齐、跨设备副本、暂存和框架开销；不同架构（如混合注意力、滑动窗口、部分层不使用传统 KV）不能照搬。

示例（假设配置）：32 层、8 个 KV Head、Head Dim 128、BF16 每元素 2 字节、单序列缓存 4,096 Token：

$$M_{KV}=2\times 32\times 1\times 4096\times 8\times 128\times 2=\mathrm{536,870,912}\text{bytes}\approx 512\text{MiB}$$

如果 16 条相同长度的序列同时常驻，理想 KV 容量约为 8 GiB，尚未计算模型权重和其他开销。这里的 8 个 KV Head 体现了 GQA/MQA 类结构相对传统多 KV Head 结构的缓存优势；真实模型的配置应读取其配置文件，不应从参数规模反推。

5.2 缓存策略的取舍

• Dynamic Cache 随序列增长分配缓存，通常更节省未使用空间，但动态形状可能影响编译优化。
• Static Cache 预先分配固定空间，有利于固定形状执行与部分编译路径，但可能浪费空间。
• Sliding Window Cache 对适用的注意力层仅保留窗口范围，不能当作任意模型的无损替代。
• Quantized / Offloaded Cache 可减少 GPU 缓存压力或将数据迁移到其他层级，但增加量化误差、传输或管理开销。

这些能力在 Hugging Face Transformers 和 TensorRT-LLM 中有对应实现，具体支持矩阵应按模型架构和框架版本确认。[S3][S4][S5]

5.3 容量优化的真实边界

减小 KV 精度不必然加速：如果解码瓶颈在内存带宽，缓存变小可能有利；如果量化/反量化引入的计算开销更大，速度可能不升反降。将 KV 卸载到 CPU 可以增加可承载的总状态，却可能因 PCIe/NVLink 传输使延迟上升。KV 缓存也不等于永久记忆：缓存生命周期、跨请求复用条件和多租户隔离由服务系统管理。

六、PagedAttention：把 KV 分块管理，解决什么问题？

传统实现若为每条请求预留大块连续 KV 空间，可能出现内部浪费与难以共享的问题。PagedAttention 的关键思想是把逻辑上连续的 KV 序列映射到可不连续的物理 KV 块，按需分配，类似虚拟内存的页式管理。逻辑块与物理块通过映射表关联，调度器可以更灵活地回收、共享或复用块。[S1][S6]

请求 A：逻辑块 [0][1][2] ──映射──► 物理块 [7][3][11]
请求 B：逻辑块 [0][1]    ──映射──► 物理块 [7][3]   （在允许共享的条件下）
物理缓存池： [0][1][2][3][4][5][6][7][8][9][10][11]...

PagedAttention 的直接价值是更高效地管理 KV 内存，可能提高可并发的请求数量和吞吐；它不是让模型权重缩小，也不保证单请求首 Token 延迟一定下降。块大小、碎片率、共享策略、引用计数和调度会影响效果。跨租户缓存共享必须考虑隔离与授权，不能因为两个 Prompt 前缀相同就默认可以跨安全边界共享。

与 FlashAttention 的区别：FlashAttention 主要通过 IO-aware 的 Attention 计算/内核组织减少高带宽显存与片上存储之间的数据移动；PagedAttention 主要处理服务阶段的 KV 存储与寻址。两者可协同使用，不是互相替代的技术。[S7]

七、Continuous Batching 与 Chunked Prefill：让 GPU 处理「变化中的请求集合」

7.1 静态批处理的问题

假设批次中有三个请求，输出分别需要 20、100、300 Token。如果批次固定到所有请求结束，短请求完成后留下的空位不能及时由新请求补充，设备利用率受限；不同长度的 Padding 也可能浪费计算。

7.2 连续批处理的机制

Continuous Batching / In-flight Batching 在生成迭代边界调整活跃请求集合：已完成的请求离开，新请求在资源允许时加入。它使服务系统不必等整个批次结束才接收新任务，提高高并发场景下的资源利用率。[S2][S8]

时间片 1：A A A | B B
时间片 2：A A A | B B | C C（C 入队并被接纳）
时间片 3：A A A | C C（B 完成）
时间片 4：A A A | C C | D D（D 加入）

此图仅表示调度思想，不代表真实 Tensor 形状。具体调度器会考虑 Token Budget、KV 空间、请求优先级、抢占和 Prefill/Decode 混排。

收益条件：有足够并发请求、输出长度分布不均、GPU 有可利用空闲容量。代价：单请求的 Decode 间隔可能受其他请求影响；过高并发造成排队、KV 压力和 P99 恶化。需要以目标负载下的 Goodput 和尾延迟判断，而不是仅看最大吞吐。

7.3 Chunked Prefill

长 Prompt 的 Prefill 如果一次占用大量执行时间，可能阻塞其他请求的 Decode，造成交互式用户感知卡顿。Chunked Prefill 将长输入分块处理，使 Prefill 工作与 Decode 更灵活地交错调度；但块划分、调度和额外管理开销也可能影响性能。其作用不是减少 Prompt 总信息量，而是改善调度粒度和服务质量。[S2][S8]

7.4 反压与排队

当请求到达率 $\lambda$ 长期超过服务处理能力 $\mu$，队列会持续增长。系统必须实施排队上限、并发限制、请求拒绝、超时与取消，而不是无限接收请求。根据 Little 定律，在稳定系统中 $L=\lambda W$（平均在系统中的请求数 = 到达率 × 平均停留时间），可以解释为什么延迟上升会导致更多请求常驻，进一步消耗 KV 容量。该定律描述稳定平均关系，不直接预测复杂非平稳流量的 P99。

八、Prefix Caching：复用重复前缀，和 KV Cache 有什么不同？

KV Cache 是推理过程保留历史 K/V 的基本机制；Prefix Caching 则尝试在多个请求之间复用相同前缀已经计算的 KV 块，减少重复 Prefill。vLLM 的自动前缀缓存以包含前缀信息的块标识来判定可复用的块，并非仅比较某段文本看起来相似。[S6]

Agent 应用中，系统指令、工具定义、固定知识说明经常重复出现，因此可考虑把稳定部分放在请求前部：

稳定系统说明 + 稳定工具 Schema + 共享项目规范
                       ↓ 可能命中 Prefix Cache
本轮用户任务 + 动态检索结果 + 最新工具反馈
                       ↓ 每次可能不同

但实际命中依赖完全一致的 Token 前缀、模型与 Tokenizer、缓存实现、有效期、租户隔离、请求参数及其他约束。调整系统提示词中的一个字符、插入动态时间戳、改变工具排序都可能破坏后续块的复用；不能把语义相近当成缓存命中。缓存复用一般节省重复 Prefill，不会自动减少后续每个 Decode Token 的计算。

8.1 缓存的三种不同层级

层级	复用内容	适合情况	主要风险
KV / Prefix Cache	计算得到的前缀 K/V	相同模型下重复稳定前缀	显存占用、命中失效、隔离
应用响应缓存	整个模型响应或结果对象	幂等、低时效要求、完全相同或安全等价任务	过期、错误结果复用、权限越界
检索/工具结果缓存	外部检索与工具输出	频繁访问稳定数据	数据陈旧、权限、外部状态变化

不能把上述三者混称「Prompt Cache」。不同托管 API 的缓存语义和计费规则也不同，必须按服务商文档核对。

8.2 多租户隐私与安全

缓存键需要纳入模型版本、租户/授权范围、工具权限、数据版本和必要的配置。即便底层引擎可以共享物理块，也不应让未授权请求读取其他租户的私有内容或利用缓存命中时间推断敏感信息。缓存隔离、清除策略、审计日志和数据保留期限是工程设计的一部分。

九、量化：为什么模型变小，不一定推理更快？

量化把权重、激活或 KV 状态从高精度表示转换为低精度表示，例如 FP16/BF16 → INT8/FP8/INT4/FP4。需要明确区分：权重量化（Weight-only）、权重与激活量化（W/A）、KV Cache 量化。它们节省的资源不同，兼容性与精度影响也不同。[S9]

对 $P$ 个参数的稠密模型，权重存储的一阶估算是 $P\times b$ 字节，忽略 Scale、Zero-point、元数据、未量化层和运行时开销。例如 8B 参数在 BF16 下权重约 16 GB（十进制），4-bit 理论裸权重约 4 GB；实际量化文件往往更大。

量化可能带来三个收益：减小权重占用、降低权重/缓存读取带宽、允许更高并发或更大模型进入显存。但它也可能带来三个代价：量化误差影响质量、额外反量化或格式转换开销、硬件/内核缺乏高效低精度路径。因此「更小」不等于「更快」，更不等于「质量不变」。

选型建议：先看硬件是否具备相应低精度算子、推理引擎是否支持该量化格式、模型是否有可靠的量化检查点，再测任务质量、TTFT、TPOT、峰值显存和并发 Goodput。对代码、结构化输出、数学与长上下文任务，应分别进行回归测试，不应只看一组通用问答分数。

十、Speculative Decoding：用额外计算换更少串行等待

自回归生成通常每轮只确认下一个 Token，形成难以消除的串行依赖。推测解码使用较小的 Draft Model 或其他候选生成方法，先提出多个候选 Token，再由目标模型并行验证，尝试一次确认多个 Token。正确设计的接受/拒绝算法可以保持目标分布，具体保证取决于算法和采样设置；不能把所有「一次生成多个 Token」的方法都当作完全等价。[S10]

目标模型逐步解码：  T1 → T2 → T3 → T4 → T5
推测解码：          Draft(T1,T2,T3,T4) → Target 验证 → 接受前缀/纠正 → 继续

收益来自减少目标模型串行前向次数，但并非免费：Draft 也要计算，验证需要资源，接受率可能很低。对于目标模型已经很小、批处理很大、候选接受率差或 Draft/Target 资源争用严重的情况，推测解码可能没有收益。对长输出、低到中等并发且 Target Decode 成本较高的场景，通常更值得评估。

示意性成本判断：若基线每 Token 目标模型耗时 $t$，推测一次需要 Draft 耗时 $d$、Target 验证耗时 $v$，平均确认 $a$ 个 Token，则近似每 Token 耗时 $(d+v)/a$。只有当它显著小于 $t$ 时才值得采用。这个简化模型忽略额外修正、异步重叠、调度和缓存开销，不能用来预测真实加速倍数。

十一、Prefill/Decode 分离与更复杂的服务架构

在传统合并式服务中，同一组 GPU 同时承担 Prefill 与 Decode；两类阶段的资源特征不同，长 Prefill 可能干扰交互式 Decode。Disaggregated Serving 将两类阶段分配到不同的工作节点或 GPU 组，并传输必要的 KV 状态，让资源配置与调度分别优化。[S11]

API Gateway → 请求队列 → Prefill Workers ──KV 状态传输──► Decode Workers → 流式响应
                              │                                  │
                        输入密集型负载                      输出密集型负载

潜在收益是更灵活的资源配比和更好的服务质量隔离；代价是 KV 传输、网络带宽、跨节点调度、容错与运维复杂度。单 GPU 或低流量服务未必需要这种架构。与之相近的优化还有张量并行、流水线并行、专家并行、CUDA Graph 和专用 Attention Kernel，但这些技术的主要工程展开属于 E7 的部署架构和推理框架专题；本篇聚焦其性能取舍和验证方法。

十二、应用层优化：不控制 GPU 时仍然能做什么？

使用托管模型 API 的团队无法直接修改推理引擎，但仍可通过减少无效工作显著改善系统成本：

（1）减少不必要的输入。 只传入与当前任务有关的历史、检索片段和工具结果。E3 研究上下文选择与压缩；E8 研究它对 Token 消耗、TTFT 和缓存命中的影响。过度压缩可能损失必要证据，导致返工。

（2）控制输出规模。 通过明确的交付结构、合理的 max_output_tokens 和任务拆分，避免重复生成大量无用内容。不能为追求省 Token 而强行截断完整答案。

（3）缓存稳定输入和中间结果。 把长期不变的说明放在稳定前缀，避免在前部插入时间戳、随机 ID；对检索和工具结果设置合理 TTL、版本和权限边界。

（4）并行独立任务，串行依赖任务。 独立检索可并发；依赖前一步结果的分析必须等待。并行度需要限流，避免 API 429、排队和集中重试。

（5）按任务选择模型。 E6 负责模型能力评估与路由策略，E8 关注路由是否真的降低成功任务成本。把每个任务都路由到便宜模型，如果造成更多失败和人工审核，并不算优化。

（6）重试必须有预算。 对临时性错误可指数退避并加入抖动；对参数错误、权限拒绝或明确的业务失败，不应盲目重试。为每个 Agent 工作流设定模型调用次数、Token、工具调用和总时长上限。

（7）区分流式与后台任务。 流式输出通常改善「用户多快看到内容」，不必然减少服务端计算总量；异步批处理适合不要求即时响应的任务，但要检查真实服务商的计费与交付保证。

十三、Agent System 的复合成本：一个任务为什么比一次调用贵得多？

设一个研究 Agent 完成任务需要 $n$ 次模型调用，调用 $i$ 的输入/输出 Token 分别为 $I_i,O_i$，缓存命中 Token 为 $K_i$。在一个假设输入价 $p_i$、缓存输入价 $p_{c,i}$、输出价 $q_i$ 的计费方案中，近似模型费用为：

$$C_{model}=\sum _{i=1}^n\frac{(I_i-K_i)p_i+K_i{p}_{c,i}+O_i{q}_i}{{10}^6}$$

再加上检索、工具、网络、存储、重试、人工审核与失败任务摊销：

$$C_{success}=\frac{C_{model}+C_{tools}+C_{infra}+C_{review}+C_{rework}}{N_{accepted}}$$

示例（全部为教学假设，不是现行 API 报价）：一个 Agent 任务有 8 次调用，每次输入 6,000 Token、输出 800 Token。假设输入价每百万 Token 2 元、输出价每百万 Token 8 元，则模型调用费：$8\times (6000\times 2+800\times 8)/{10}^6=0.1472$ 元。若每次输入中有 3,000 Token 可按 0.5 元/百万 Token 计费，其他条件不变，则为 $8\times (3000\times 2+3000\times 0.5+800\times 8)/{10}^6=0.1112$ 元，节约约 24.5%。但如果缓存策略导致任务成功率下降、重试增多，成功任务成本可能仍会上升。

13.1 多 Agent 的关键是关键路径，不是调用次数之和

对于串行步骤，任务延迟约为各步骤耗时之和；对于独立并行步骤，完成时间受最慢分支和后续汇合步骤支配。模型请求总数和 Token 总量影响成本，关键路径长度决定用户需要等待多久。优化多 Agent 工作流应同时画出调用依赖图和成本分布，识别真正的瓶颈。

用户任务
  ├─► 检索 A（3s）─┐
  ├─► 检索 B（5s）─┼─► 汇总（4s）─► 审核（3s）
  └─► 检索 C（2s）─┘

在无资源竞争、无额外调度开销的教学假设下，三项检索并行的总时长约为 5+4+3=12 秒；串行则约为 3+5+2+4+3=17 秒。实际会受到速率限制、工具资源和请求排队影响。

13.2 质量约束是优化的硬边界

对研究系统，应记录：报告通过审核的比例、事实错误率、引用有效率、需要人工返工的时间、总调用次数与完成时间。降低成本后如果事实错误增多，不能只展示 Tokens/s 的提升。与 E4 的结构化输出、E5 的工具调用、E6 的模型路由和 E7 的服务部署共同构成系统级评估闭环。

十四、完整工程实践：设计可复现的推理 Benchmark

这一节给出一个不依赖特定模型服务商的基准方案，重点是实验设计与结果口径。不同服务商的流式事件结构不一致，不能把示意伪代码伪装成通用可运行 API。附录 A 提供可直接执行的 Python 标准库计算脚本，用于分析已采集的逐请求指标；采集器需根据具体 API 协议实现。

14.1 实验问题与对照组

以「连续批处理是否改善研究 Agent 的吞吐且不损害交互延迟」为例：

• Baseline：固定模型、固定权重精度、固定硬件、关闭被研究的优化开关。
• Treatment：仅改变批处理/调度策略，其余条件保持一致。
• 输入矩阵：短输入（约 256-512 Token）、中输入（2k-4k）、长输入（16k-32k），实际以模型支持范围为准。
• 输出矩阵：短输出（64-128 Token）、中输出（256-512）、长输出（1k-2k）。
• 并发矩阵：1、4、16、32；应根据硬件容量调整，不可强行超载后只比较成功请求。
• 工作负载：固定请求集与混合请求集都要测；混合请求集模拟真实长短请求比例。

同一请求集至少测多轮，并区分预热与正式采样。随机化实验顺序，避免「先测基线时 GPU 冷、后测优化时缓存热」造成偏差。对于 Prefix Cache 实验，应明确冷缓存和热缓存两组，并报告命中率。对于量化实验，除了性能必须测任务质量。

14.2 必须记录的环境信息

实验编号 / 时间 / 研究基准日期
模型标识、具体权重版本或 commit、Tokenizer 与 Chat Template
推理框架名称、版本或 commit、启动参数
GPU 型号与数量、显存、驱动、CUDA/ROCm 版本
量化格式、KV Cache 精度、最大上下文、批处理与调度配置
Prompt 集合及 Token 长度分布、输出长度上限
并发、到达率、请求超时、重试与限流策略
每次请求：开始时间、首 Token 时间、结束时间、输入/输出 Token、状态、错误
聚合：P50/P95/P99 TTFT/E2E/ITL、吞吐、Goodput、失败率、成本、质量

14.3 采集与统计的关键陷阱

1. Token 计数：字符数不是 Token 数。优先使用服务端 usage；流式响应未提供时，应采用对应 Tokenizer 统计并标注差异。
2. 首 Token 事件：有些流式协议先发角色、元信息或空字符串。TTFT 必须以第一个实际生成内容 Token 为准，且需注明事件粒度与 Token 粒度的差异。
3. 失败样本：失败和超时不能从分母中悄悄删除。延迟分位数可以只对成功请求计算，但必须同时报告成功率、超时率和超时截断规则。
4. 负载生成方式：固定并发的 Closed-loop 测试与固定到达率的 Open-loop 测试回答不同问题。Closed-loop 容易在服务变慢时自动降低到达率，掩盖过载下的排队问题。
5. 统计不确定性：P99 需要足够样本，低样本量的 P99 极不稳定。报告样本数、运行轮次和波动区间，避免只发布最好的那一次。
6. 热身与缓存：冷启动、模型编译、CUDA Graph 捕获、前缀缓存命中都会影响结果。预热过程与正式采样分开记录。
7. 成本计算：托管 API 使用研究日真实价格表；自托管计算设备、运维和闲置成本；均不能用教学假设代替生产预算。

14.4 如何解释实验结果

假设在相同请求集下，Treatment 的输出 Token/s 增加 35%，但 P95 TTFT 从 1.0 秒升至 3.5 秒。对于后台批量摘要任务，可能仍值得采用；对于实时交互式 Agent，可能不可接受。需要按服务级目标定义 Goodput：例如「成功且 TTFT<2 秒且质量通过」的请求数/秒。只有达到目标的提升才是有效优化。

14.5 优化实验的最小闭环

明确用户体验或成本问题
   ↓
固定模型、数据集、硬件与计量口径
   ↓
采集 Baseline（包含失败与尾延迟）
   ↓
提出单一瓶颈假设
   ↓
只改变一项主要策略
   ↓
复测性能 + 质量 + 资源 + 成本
   ↓
通过门槛 → 灰度发布；未通过 → 回滚并记录原因

十五、优化技术选择矩阵与常见误区

优化手段	首要作用	最适合优先验证的场景	主要代价与边界
Prompt / 上下文精简	减少输入与无效 Prefill	冗长 Agent 历史、重复工具结果	可能丢失证据，影响成功率
Prefix Caching	复用重复前缀的 KV	大量相同系统提示词/工具定义	命中条件严格，隐私与隔离
KV Cache 管理	降低重复计算和内存浪费	长上下文、较高并发	容量、驱逐、精度和传输开销
PagedAttention	高效 KV 分配与共享	变长请求、高并发服务	块管理复杂，单请求不保证更快
Continuous Batching	提高活跃请求混合调度效率	并发多、输出长度差异大	排队和尾延迟可能恶化
Chunked Prefill	减少长 Prefill 对 Decode 的阻塞	长短请求混合、交互场景	调度复杂、分块开销
权重/激活量化	降低存储、带宽与部分计算开销	显存或带宽受限	质量回归、硬件内核兼容性
KV 量化/卸载	增加可承载上下文或并发	KV 容量成为瓶颈	精度、反量化、传输开销
Speculative Decoding	减少目标模型串行解码等待	长输出、较低到中并发	接受率、Draft 开销与调度
Prefill/Decode 分离	资源隔离与独立扩容	大规模混合流量	KV 传输、网络与运维复杂度
模型路由	按任务选择能力/成本组合	任务难度差异大	路由误判与多模型治理（详见 E6）
Agent 调用链重构	减少不必要调用和关键路径	多步骤、多工具工作流	依赖分析、错误恢复与复杂度

误区一：「显存越少一定越快」。 显存占用与计算速度是不同指标；量化和卸载可能降低容量压力，却增加执行开销。

误区二：「吞吐量越高，用户体验越好」。 高吞吐可能来自大批量与长队列，P95 TTFT 和 P99 ITL 可能恶化。

误区三：「缓存命中等于回答正确」。 缓存解决重复计算，不能保证内容时效、事实正确或授权有效。

误区四：「流式输出能减少总计算」。 流式主要改善感知等待时间，通常不会自动减少模型生成的 Token 数。

误区五：「优化一个请求就等于优化系统」。 单请求最优配置不一定是并发最优；真实目标应以工作负载与 SLO 定义。

误区六：「便宜模型必然降低 Agent 成本」。 质量下降、重复调用和人工返工可能使成功任务成本升高。

十六、资料核验、版本与证据边界

16.1 本次资料核验说明

本篇研究基准日与实际检索日均为 2026 年 10 月 27 日。本次检索核对了 vLLM、TensorRT-LLM、Hugging Face Transformers 的在线官方/维护者文档，包括 PagedAttention、Prefix Caching、连续批处理、KV Cache、量化、推理指标与 Prefill/Decode 分离的功能说明。官方文档通常持续更新，本次未锁定全部项目的精确 release tag 或 commit SHA；因此这些部分属于「截至检索日的文档级核验」，不是对所有硬件、模型和版本组合的兼容性验证。文中涉及性能收益的表述均作为机制分析或待测假设，不宣称本次进行了 GPU 基准实测。

16.2 参考资料（按机制归属）

• [S1] vLLM 官方文档（推理服务能力、PagedAttention、连续批处理等）：https://docs.vllm.cc/en/latest/
• [S2] NVIDIA TensorRT-LLM，Paged Attention / In-flight Batching / Scheduler：https://github.com/NVIDIA/TensorRT-LLM/blob/main/docs/source/features/paged-attention-ifb-scheduler.md
• [S3] Hugging Face Transformers，Cache explanation：https://github.com/huggingface/transformers/blob/main/docs/source/en/cache_explanation.md
• [S4] NVIDIA TensorRT-LLM，KV Cache System：https://github.com/NVIDIA/TensorRT-LLM/blob/main/docs/source/features/kvcache.md
• [S5] Hugging Face Transformers，Generation configuration：https://github.com/huggingface/transformers/blob/main/src/transformers/generation/configuration_utils.py
• [S6] vLLM，Automatic Prefix Caching：https://docs.vllm.cc/en/latest/design/automatic_prefix_caching.html
• [S7] Dao 等，FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness（原始论文，2022）：https://arxiv.org/abs/2205.14135
• [S8] NVIDIA TensorRT-LLM，In-flight Batching 机制：https://nvidia.github.io/TensorRT-LLM/advanced/gpt-attention.html
• [S9] NVIDIA TensorRT-LLM，Quantization：https://nvidia.github.io/TensorRT-LLM/latest/features/quantization.html
• [S10] Leviathan 等，Fast Inference from Transformers via Speculative Decoding（原始论文，2022/2023）：https://arxiv.org/abs/2211.17192
• [S11] NVIDIA TensorRT-LLM，Disaggregated Serving：https://github.com/NVIDIA/TensorRT-LLM/blob/main/docs/source/features/disagg-serving.md
• [S12] vLLM，服务指标设计与 /metrics：https://github.com/vllm-project/vllm/blob/main/docs/design/metrics.md
• [S13] Kwon 等，Efficient Memory Management for Large Language Model Serving with PagedAttention（vLLM 原始论文，2023）：https://arxiv.org/abs/2309.06180

来源与结论映射：第 5 章主要依据 [S3-S5]；第 6、8 章依据 [S1][S6][S13]；第 7 章依据 [S2][S8]；第 9 章依据 [S9]；第 10 章依据 [S10]；第 11 章依据 [S11]；第 14 章的指标采集可参考 [S12]。其中实验设计、Agent 成本公式与选型矩阵属于本文工程分析，并非上述资料逐字规定。

16.3 未验证项与不应夸大的结论

• 未运行真实 GPU 推理、量化或推测解码性能测试。
• 未执行真实托管模型 API 端到端请求；没有采集 TTFT/TPOT 的生产样本。
• 未对特定模型/显卡/推理框架组合锁定版本并做兼容性验证。
• 未对多租户缓存侧信道风险进行安全渗透测试。
• 文中涉及费用与性能的数字示例均明确标为教学假设，不是实际报价或基准测试结果。

因此，本篇机制研究与实验方法可用于指导实施，但不能作为某项优化在具体生产环境中必然提升多少性能的证明。实际部署应按第十四章复测。

十七、核心结论与关联研究

推理优化首先要明确优化目标和约束，然后区分网络、排队、Prefill、Decode、缓存与应用调用链的不同瓶颈。KV Cache 减少重复计算，但消耗显存；PagedAttention 优化 KV 分配；连续批处理改善动态负载下的设备利用率；Prefix Caching 复用重复前缀；量化、推测解码和阶段分离分别在存储、串行计算和资源隔离上寻找收益。它们的适用条件不同，也可能互相影响。

对于 Agent System，最重要的不是某个 GPU 的峰值 Tokens/s，而是在质量、权限和时延要求内完成一个合格任务的成本与时间。必须同时观察模型调用、工具等待、重试、上下文增长、任务关键路径和最终审核结果。任何优化都应遵循「基线-假设-单变量改动-质量回归-尾延迟与成本评估-灰度/回滚」的闭环。

关联专题：E1 Model API（调用与网络边界）；E3 Context Window（上下文预算）；E4 Structured Outputs（输出结构和失败恢复）；E5 Function Calling（工具循环与执行）；E6 Model Routing（任务到模型的选择）；E7 Model Deployment（推理服务环境）。后续 Agent Runtime、Orchestration 与 Observability 章节可继续展开多 Agent 关键路径和生产指标治理。

附录 A：可运行的性能统计与成本计算示例（Python 标准库）

配套文件 e8-inference-metrics-demo.py 与下方脚本一致，只分析已经采集到的样本数据，不假装连接真实模型。示例包含：TTFT、TPOT、E2E、分位数、失败率、Goodput、KV 容量与教学成本计算。验证状态：本地可运行；本次生成时执行基础断言检查，见附录 B。

from dataclasses import dataclass
from typing import Optional
from math import ceil
from statistics import median

@dataclass(frozen=True)
class Sample:
    start: float
    first_token: Optional[float]
    end: float
    output_tokens: int
    success: bool

def percentile(values, q):
    if not values:
        raise ValueError("empty sample")
    if not 0 <= q <= 1:
        raise ValueError("q out of range")
    xs = sorted(values)
    pos = (len(xs) - 1) * q
    lo, hi = int(pos), min(int(pos) + 1, len(xs) - 1)
    return xs[lo] + (xs[hi] - xs[lo]) * (pos - lo)

def summarize(samples, ttft_slo=2.0):
    if not samples:
        raise ValueError("no requests")
    good = [s for s in samples if s.success]
    ttft = [s.first_token - s.start for s in good
            if s.first_token is not None and s.output_tokens > 0]
    e2e = [s.end - s.start for s in good]
    tpot = [(s.end - s.first_token) / (s.output_tokens - 1)
            for s in good if s.first_token is not None and s.output_tokens > 1]
    valid = sum(s.success and s.first_token is not None
                and s.first_token - s.start <= ttft_slo for s in samples)
    wall = max(s.end for s in samples) - min(s.start for s in samples)
    return {
        "requests": len(samples),
        "success_rate": len(good) / len(samples),
        "p95_ttft_s": percentile(ttft, .95) if ttft else None,
        "p95_e2e_s": percentile(e2e, .95) if e2e else None,
        "median_tpot_s": median(tpot) if tpot else None,
        "goodput_req_s": valid / wall if wall > 0 else None,
    }

def kv_mib(layers, batch, tokens, kv_heads, head_dim, bytes_per_element):
    return (2 * layers * batch * tokens * kv_heads * head_dim
            * bytes_per_element) / (1024 ** 2)

def api_cost(input_tokens, output_tokens, input_price_per_m,
             output_price_per_m):
    return (input_tokens * input_price_per_m +
            output_tokens * output_price_per_m) / 1_000_000

if __name__ == "__main__":
    assert abs(kv_mib(32, 1, 4096, 8, 128, 2) - 512) < 1e-9
    assert abs(api_cost(6000, 800, 2, 8) - 0.0184) < 1e-9
    assert abs(percentile([1, 2, 3, 4, 5], .5) - 3) < 1e-9
    assert abs(percentile([1, 2, 3, 4, 5], .95) - 4.8) < 1e-9
    report = summarize([
        Sample(0, .8, 5.75, 100, True),
        Sample(1, 2.0, 7.0, 101, True),
        Sample(2, None, 8.0, 0, False),
    ])
    assert report["requests"] == 3
    assert abs(report["success_rate"] - 2/3) < 1e-9
    assert abs(report["median_tpot_s"] - .05) < 1e-9
    print(report)

实现注意：percentile 使用线性插值定义，其他统计库可能采用不同分位数算法；goodput_req_s 仅按 TTFT SLO 与成功状态筛选，实际业务还应加入任务质量与完整响应时限。示例输入时间戳是教学数据，真实流式事件需要单独采集。上面的 ceil 导入未使用，不影响运行，但生产代码应清理无用导入。

附录 B：单篇质量审核与验证记录

审核项目	本篇状态	说明
核心问题覆盖	已覆盖	Prefill/Decode、指标、KV、PagedAttention、调度、缓存、量化、推测解码、成本与评测
机制与边界	已覆盖	每项解释作用机制、收益条件和代价；未把理论收益当成实测
工程实践	已提供	完整 Benchmark 设计与本地统计脚本；未连接生产 API
来源与时效性	部分核验	本次核对官方在线文档；未锁定所有具体发布版本
代码验证	本地基础断言	标准库脚本可运行；真实服务未测
与 E3/E6/E7 边界	已审阅	上下文管理、路由、部署分别归属其他专题
生产效果保证	不作保证	必须在目标硬件和真实工作负载下复测

交付状态：v2.0 单篇整合修订版，供读者验收；可作为知识库研究文档使用，但不应将未经实测的性能判断作为生产性能承诺。