3、性能基准测试核心概念：理解吞吐量、延迟、首令牌时间（TTFT）、令牌间延迟（ITL）、并发数、批处理大小等关键指标

大模型部署的性能基准测试，本质上是对服务系统在特定负载下的行为进行量化观测。与传统的Web服务或数据库性能测试不同，大模型推理具有生成式、长尾计算、显存敏感等特性，因此其核心指标也呈现出独特的层次结构。本章将系统梳理吞吐量、延迟、首令牌时间（TTFT）、令牌间延迟（ITL）、并发数、批处理大小这六个关键指标，厘清它们之间的数学关系与工程权衡，并给出在实际项目中如何选取、测量与解读这些指标的方法论。

3.1 核心指标定义与数学关系

3.1.1 延迟类指标：TTFT 与 ITL

首令牌时间（Time To First Token, TTFT）是指从客户端发送请求到收到第一个输出令牌之间的耗时。它主要由预填充（Prefill）阶段决定，该阶段需要对整个输入提示词进行并行计算，属于计算密集型操作。TTFT 直接决定了用户感知的"响应速度"，在交互式应用（如聊天机器人、实时助手）中尤为关键。经验法则是：TTFT 应控制在 200ms~2s 以内，超过 3s 用户会明显感到卡顿。

令牌间延迟（Inter-Token Latency, ITL）是指生成阶段相邻两个输出令牌之间的时间间隔，即解码（Decode）阶段每个令牌的耗时。ITL 反映了模型"吐字"的流畅度，其倒数即为单请求的生成速率。例如 ITL=50ms 意味着每秒生成 20 个令牌。ITL 主要受显存带宽、批处理大小和模型参数量影响，属于访存密集型操作。

端到端延迟（E2E Latency）与 TTFT、ITL 的关系为：E2E = TTFT + ITL × (N - 1)，其中 N 为输出令牌总数。这一公式揭示了延迟的构成，也说明了为什么长输出场景下 ITL 比 TTFT 更重要。

3.1.2 吞吐量指标

吞吐量（Throughput）通常有两种度量方式：令牌吞吐量（Tokens/s，每秒生成的令牌总数）和请求吞吐量（Requests/s，每秒完成的请求数）。令牌吞吐量更能反映硬件利用率，而请求吞吐量更贴近业务视角。两者关系为：Requests/s = Tokens/s ÷ 平均输出长度。在基准测试中，应同时报告这两个数值，并注明平均输入/输出长度，否则数据无法横向对比。

3.1.3 负载控制指标：并发数与批处理大小

并发数（Concurrency）指同时处于处理状态（包括排队中）的请求数量。它模拟了真实用户同时访问的压力。并发数并不等于线程数，而是指在途请求数。当并发数超过系统处理能力时，请求开始排队，延迟随之上升。

批处理大小（Batch Size）指推理引擎在单次前向传播中处理的序列数量。现代推理框架（如 vLLM、TensorRT-LLM）支持连续批处理（Continuous Batching），即动态地将不同进度的请求组合进同一批次，从而显著提升 GPU 利用率。批处理大小越大，吞吐量越高，但每个请求的 ITL 也会相应增加，因为显存带宽被更多请求共享。

3.2 指标测量方法与操作流程

3.2.1 测量工具与数据采集

性能基准测试的测量工具选择直接影响数据可信度。推荐使用以下工具组合：

• 负载生成器：使用 wrk、ghz 或自研 Python 脚本（基于 aiohttp）模拟并发请求。对于流式输出场景，必须使用支持 SSE（Server-Sent Events）的客户端，否则无法准确测量 TTFT 和 ITL。
• 服务端监控：通过 Prometheus + Grafana 采集推理引擎的批处理大小、GPU 利用率、显存占用、队列长度等指标。
• 日志埋点：在推理引擎中记录每个请求的接收时间、Prefill 完成时间、每个令牌的生成时间戳。vLLM 和 TensorRT-LLM 均支持通过环境变量开启详细时间日志。

3.2.2 标准测量流程

1. 预热阶段：以低并发（如 1~4）发送 20~50 个请求，使 CUDA 上下文、页缓存、模型权重加载完成，避免冷启动影响数据。
2. 阶梯加压：从并发数 1 开始，按 1→2→4→8→16→32→64 逐步增加，每个并发级别持续运行 3~5 分钟，记录稳定后的指标。
3. 数据记录：对每个并发级别，记录 P50/P90/P99 的 TTFT、ITL、E2E 延迟，以及平均/峰值吞吐量。
4. 重复实验：每个配置至少重复 3 次，取中位数，排除偶发网络抖动或系统噪声。

# 流式请求测量 TTFT 和 ITL
import time, requests

url = "http://localhost:8000/v1/completions"
payload = {"model": "llama-3-8b", "prompt": "..." * 100, "max_tokens": 200, "stream": True}

start = time.perf_counter()
resp = requests.post(url, json=payload, stream=True)
first_token_time = None
token_times = []

for line in resp.iter_lines():
    if line and first_token_time is None:
        first_token_time = time.perf_counter() - start
    if line:
        token_times.append(time.perf_counter() - start)

ttft = first_token_time * 1000  # ms
itl = [(token_times[i+1] - token_times[i]) * 1000 for i in range(len(token_times)-1)]
print(f"TTFT: {ttft:.1f}ms, Avg ITL: {sum(itl)/len(itl):.1f}ms")

3.3 案例拆解：某智能客服系统的性能基准测试

3.3.1 背景与目标

某金融科技公司计划部署一个基于 7B 参数模型的智能客服系统，硬件为单张 NVIDIA A10G（24GB 显存）。业务要求：TTFT ≤ 1s（P95），ITL ≤ 80ms（P95），单机吞吐量 ≥ 500 tokens/s。团队需要确定最优的并发数和批处理配置，并验证硬件是否满足需求。

3.3.2 初始测试与问题发现

使用 vLLM 框架，默认配置（最大批处理大小 256，并发数 32）进行测试。结果如下：

分析发现：P95 TTFT 超标的主要原因是排队延迟。当并发数为 32 时，请求到达速率超过 Prefill 阶段的处理能力，导致请求在队列中等待。通过监控日志确认，平均队列深度为 8~12 个请求。

3.3.3 调优过程与结果

采取以下措施：

1. 降低并发数至 16：减少排队，TTFT P95 降至 1.1s，但仍略超目标。
2. 启用 vLLM 的 --max-num-seqs 限制为 64：限制单批次最大序列数，避免 Prefill 阶段因批处理过大而阻塞。
3. 调整调度策略：设置 --preemption-mode 为 recompute，优先保证 TTFT。

最终配置（并发 16，max-num-seqs=64）测试结果：

代价：吞吐量从 680 降至 540 tokens/s（下降 20%），但换来了 TTFT 的显著改善。团队最终接受了这一权衡，因为客服场景对首响延迟更敏感。

3.3.4 复盘经验

• 并发数不是越大越好，超过拐点后延迟会急剧恶化，而吞吐量增长趋缓。
• TTFT 超标时优先检查队列深度和批处理大小，而非 GPU 算力。
• 性能调优是多目标优化，必须结合业务 SLA 确定优先级。

3.4 常见误区与总结复盘