3. 推理服务核心概念
在正式进入大模型推理服务的部署与调优之前，我们必须先建立一套统一的度量语言。无论是选择GPU型号、设计服务架构，还是编写压测脚本，最终都要回归到几个核心指标上：吞吐量、延迟、首延迟、生成速率，以及并发与批处理之间的关系。这些指标不是孤立的，它们相互制约、彼此影响，构成了推理服务性能评估的底层坐标系。如果对这些概念的理解出现偏差，后续的容量规划、成本控制和SLA制定都会失去依据。本章将逐一拆解这些核心概念，并重点剖析它们之间的数学关系与工程权衡。
上图展示了推理服务性能指标之间的核心关系。从左侧的并发请求进入，经过动态批处理引擎的调度，最终在GPU推理核心上执行，并输出一系列关键指标。值得注意的是，这些指标之间存在明显的“跷跷板效应”：追求高吞吐量往往意味着牺牲单请求延迟，而严格保障低延迟则可能限制吞吐量的提升。理解这种权衡关系，是进行推理服务调优的第一步。
3.1 核心指标定义与测量方法
3.1.1 吞吐量（Throughput）
吞吐量衡量的是推理系统在单位时间内能够处理的请求数量或生成的数量。在工程实践中，我们通常使用两个维度来度量：Requests Per Second（RPS）和Tokens Per Second（TPS）。RPS适合衡量短请求或对话轮次较少的场景，而TPS则更适合衡量长文本生成任务，因为它不受输出长度波动的影响，更能反映GPU的计算效率。
测量吞吐量时，需要注意一个关键陷阱：输出长度对TPS的影响。假设两个请求的输入长度相同，但一个生成100个，另一个生成500个，后者的TPS会显著高于前者，但这并不代表系统性能更好。因此，在对比不同配置的吞吐量时，必须固定输入输出长度分布，或者使用标准化后的指标（如每GPU每秒生成的数）。
3.1.2 延迟（Latency）与首延迟（TTFT）
延迟是用户可感知的等待时间，通常分为两个阶段：首延迟（Time To First , TTFT）和间延迟（Time Per Output , TPOT）。TTFT衡量的是从请求发出到接收到第一个的时间，它主要由Prefill阶段（预填充阶段）决定，即模型处理输入Prompt并生成KV Cache的时间。TPOT则衡量的是后续每个生成的平均间隔时间，它由Decode阶段（解码阶段）决定。
在交互式应用（如聊天机器人）中，TTFT直接决定了用户的第一印象。如果TTFT超过3秒，用户会明显感到“卡顿”。而在离线批处理任务中，TPOT则更为重要，因为它决定了整个任务的完成时间。测量时，建议使用P95或P99分位数而非平均值，因为平均值容易被少数极快请求拉低，无法反映真实体验。
3.1.3 生成速率（ITL / TPOT）
生成速率通常用Inter- Latency（ITL）或TPOT来表示。ITL是相邻两个生成的时间间隔，而TPOT是生成一个的平均耗时。在流式输出场景中，ITL直接决定了打字机效果的流畅度。例如，如果ITL为50ms，则每秒可输出20个，用户会感觉输出非常流畅；如果ITL达到200ms，则每秒仅输出5个，用户会明显感到等待。
需要特别注意的是，ITL并非恒定值。在Batch Size增大时，由于GPU需要分时处理多个请求，单个请求的ITL会相应增加。例如，当Batch Size从1增加到8时，ITL可能从30ms增加到80ms，但整体吞吐量却提升了3倍。这种“个体变慢、整体变快”的现象，是批处理调优的核心矛盾。
3.2 并发与批处理的工程机制
3.2.1 并发（Concurrency）与并行（Parallelism）的区别
在推理服务中，并发指的是系统同时处理的请求数量，它由客户端连接数、服务线程数和GPU计算能力共同决定。而并行则是指GPU在同一时刻执行多个计算任务的能力，这依赖于GPU的SM（Streaming Multiprocessor）数量和Tensor Core的并行度。一个常见的误区是认为“并发数越高，吞吐量就越高”。实际上，当并发数超过GPU的并行能力时，请求会在队列中排队，导致延迟急剧上升，而吞吐量可能不再增长甚至下降。
3.2.2 动态批处理（Continuous Batching）
传统的静态批处理需要等待所有请求到达后才开始推理，这会导致GPU空闲等待。而现代推理框架（如vLLM、TensorRT-LLM）采用动态批处理机制：当一个请求完成生成后，其占用的显存和计算资源会立即释放，并分配给新到达的请求。这种机制极大地提高了GPU利用率。
动态批处理的核心参数是max_batch_size和调度策略。max_batch_size决定了GPU显存中最多能同时容纳多少个请求的KV Cache。调度策略则决定了当请求到达时，是优先插入现有批次，还是等待当前批次完成。常见的策略包括SJF（Shortest Job First）和FCFS（First Come First Serve），前者优先处理输出长度短的请求，以降低平均延迟。
| 参数名称 | 典型值 | 影响 | 调优建议 |
|---|---|---|---|
| max_batch_size | 8 ~ 64 | 增大可提升吞吐量，但增加显存占用和单请求延迟 | 根据GPU显存容量和延迟SLA设定，建议从16开始测试 |
| max_waiting_time | 10ms ~ 100ms | 控制请求在队列中的等待时间，影响TTFT | 交互场景设为10ms，离线场景可放宽至100ms |
| 调度策略 | SJF / FCFS | SJF降低平均延迟，FCFS保证公平性 | 混合场景建议使用SJF，并设置最大等待时间防止饥饿 |
3.3 实战案例：从压测数据到容量规划
下面通过一个实际案例来演示如何利用这些指标进行容量规划。假设我们有一个在线客服机器人服务，目标SLA为：P95 TTFT < 1.5秒，P95 TPOT < 100ms（即每秒至少输出10个）。我们使用单张NVIDIA A10G（24GB显存）进行压测。
压测配置：使用wrk或Locust模拟50个并发用户，每个用户发送请求后等待完整响应再发送下一个请求。输入Prompt平均长度为300 ，输出平均长度为150 。压测结果如下：
初始压测结果（Batch Size=8）:
- 吞吐量: 850 TPS
- P95 TTFT: 1.2s ✅
- P95 TPOT: 85ms ✅
- GPU 显存占用: 18.2GB
- GPU 利用率: 72%从数据看，当前配置满足SLA，但GPU利用率仅72%，存在提升空间。我们尝试将Batch Size提升至16，观察变化：
调整后压测结果（Batch Size=16）:
- 吞吐量: 1,240 TPS (+46%)
- P95 TTFT: 1.8s ❌ (超出SLA)
- P95 TPOT: 120ms ❌ (超出SLA)
- GPU 显存占用: 23.1GB (接近上限)
- GPU 利用率: 91%虽然吞吐量大幅提升，但延迟指标均超出SLA。此时我们需要权衡：如果业务对延迟不敏感（如离线分析任务），可以接受此配置；但对于在线客服场景，必须回退。进一步分析发现，TTFT超标的根因是Prefill阶段的计算争抢——当Batch Size过大时，多个请求的Prefill计算被串行化，导致首个生成变慢。
优化方案：我们采用“Prefill与Decode分离”的策略，将Batch Size保持在16，但通过框架配置将Prefill阶段的计算优先级提高。具体操作是在vLLM中设置--preemption-mode为recompute，并调整--max-num-seqs为16。优化后结果：
优化后结果（Batch Size=16 + Prefill优先）:
- 吞吐量: 1,180 TPS
- P95 TTFT: 1.4s ✅
- P95 TPOT: 95ms ✅
- GPU 利用率: 88%最终，我们在满足SLA的前提下，将吞吐量提升了约39%。这个案例说明，指标调优不是简单地增大Batch Size，而是需要结合业务SLA，找到吞吐量与延迟的最佳平衡点。
3.4 常见误区与复盘
在推理服务的性能调优中，以下几个误区最为常见：
- 误区一：只关注平均延迟，忽略P99。平均延迟容易被少数极快请求掩盖，而P99能反映最差体验。在SLA制定中，应明确使用P95或P99作为基准。
- 误区二：认为并发数等于吞吐量。并发数只是输入条件，吞吐量由GPU计算能力和Batch Size共同决定。盲目增加并发只会导致请求排队，增加延迟。
- 误区三：忽略输入输出长度分布。如果压测数据与真实业务分布差异过大，结果将毫无参考价值。建议从生产环境采集真实的请求日志，提取输入输出长度分布，用于压测脚本。
- 误区四：将TTFT和TPOT混为一谈。两者由不同的计算阶段决定，优化手段也不同。TTFT主要受Prefill计算量和Batch Size影响，而TPOT主要受Decode阶段的显存带宽和Batch Size影响。