课程导入：学习目标、课程结构、吞吐量定义与重要性

1.1 学习目标与课程定位

大模型推理服务的吞吐量，直接决定了单位时间内的服务请求处理能力，也决定了单次推理的边际成本。在生产环境中，模型精度固然重要，但若吞吐量无法支撑业务峰值，再高的精度也无法转化为实际可用性。本课程聚焦于吞吐提升的核心策略，不泛谈分布式训练，也不深入底层算子优化，而是围绕推理服务端到端的性能链路，系统拆解影响吞吐的关键因素与工程化手段。

完成本章及后续章节学习后，你将能够：

• 准确理解吞吐量的定义、计算口径及其与延迟、并发、批大小的关系；
• 掌握从模型层、框架层、调度层到硬件层的吞吐优化方法体系；
• 能够使用压测工具定位吞吐瓶颈，并基于 profiling 数据制定优化方案；
• 理解连续批处理、PagedAttention、KV Cache 复用等核心机制的原理与适用场景；
• 具备在生产环境中平衡吞吐、延迟与成本的经验判断力。

1.2 吞吐量的定义与计算口径

在推理服务场景中，吞吐量（Throughput）通常定义为单位时间内系统成功处理的请求数或生成的 Token 数。但仅此还不够，业界更关注的是有效吞吐——即满足延迟约束前提下的吞吐。例如，一个系统每秒能处理 100 个请求，但其中 60% 的响应时间超过 2 秒，那么对于要求 p95 延迟低于 1.5 秒的业务而言，这 100 req/s 并不具备实际价值。

常用的吞吐量度量口径包括：

需要特别强调的是，吞吐量与延迟并非简单的反比关系。在低并发下，增加并发可以提升吞吐而几乎不损害单请求延迟；但当并发超过某个阈值后，排队延迟和显存竞争会导致延迟急剧上升，此时吞吐的提升会以牺牲延迟为代价。因此，吞吐优化的本质是在延迟约束下最大化资源利用率。

1.3 为什么吞吐量是核心生产指标

从成本结构来看，大模型推理服务的硬件成本占据总运营成本的 70% 以上。以 8×A100 80GB 的节点为例，单节点月成本可达数万元。若吞吐量提升 2 倍，意味着在相同硬件上可以服务 2 倍的请求量，单位请求成本直接减半。这种规模效应在千亿参数模型上尤为显著——吞吐优化是降低推理成本最直接、最可量化的路径。

从用户体验角度，吞吐量间接影响服务质量。当系统吞吐不足时，请求排队时间增长，表现为用户感知的“卡顿”或“超时”。即使单次推理本身只需 200ms，若队列中积压了 50 个请求，用户实际等待时间可能超过 10 秒。因此，吞吐量不仅是成本指标，更是体验保障的基础。

1.4 吞吐优化的核心矛盾与误区

吞吐优化面临的核心矛盾是：GPU 算力利用率与内存带宽/容量之间的不平衡。大模型推理时，每个 Token 的生成都依赖完整的模型权重参与计算，但实际计算量远小于权重读取所需的访存量。这种“访存密集”特性导致 GPU 算力经常处于饥饿状态，而显存带宽成为瓶颈。

常见的吞吐优化误区包括：

• 误区一：盲目增大 batch size。 虽然大 batch 能提升吞吐，但超过显存容量后会导致显存溢出或触发 CPU offload，反而大幅降低吞吐。
• 误区二：只关注模型推理时间，忽略前后处理开销。 Tokenizer、模板拼接、日志序列化等 CPU 操作可能占据端到端延迟的 30% 以上，成为隐藏瓶颈。
• 误区三：认为动态 batching 是银弹。 动态 batching 需要精确的调度策略，若请求到达率波动大，频繁重组 batch 反而增加开销。
• 误区四：忽略 KV Cache 的内存管理。 不合理的 KV Cache 分配策略会导致显存碎片化，实际可用 batch 远小于理论值。

1.5 吞吐量评估的典型场景

为了帮助理解吞吐量在不同业务形态下的表现差异，我们对比三类典型场景：

从上述对比可以看出，不存在一种放之四海而皆准的吞吐优化方案。在线对话场景需要优先保证低延迟，因此批大小通常被限制在 8～32 之间；而离线批量任务可以将 batch 提升到 64 甚至 128，以最大化吞吐。理解业务特征，是选择优化策略的前提。

1.6 本章小结与学习路径建议

本章建立了吞吐量优化的整体认知框架。核心要点可归纳为：

1. 吞吐量的度量必须结合延迟约束，有效吞吐（Goodput）才是生产环境真正关心的指标；
2. 吞吐与延迟之间存在“先升后降”的权衡曲线，最优工作点位于拐点左侧的饱和区域；
3. 吞吐优化的本质是提升 GPU 资源利用率，核心瓶颈通常是显存带宽而非算力；
4. 不同业务场景对吞吐和延迟的偏好不同，优化策略需要场景化定制。