大模型推理性能基准与关键指标解读

可视化演示

讲的是怎么评测大模型推理硬件的性能，重点看吞吐量、延迟和首token时间这几个核心指标。你会学到MLPerf基... 切换模式查看不同维度。

基准测试入门

你的餐厅想证明后厨实力，不能请自家伙计打分，得请独立的米其林评审员。评审员会定规矩：同一道菜、同一份菜谱、同一种验收标准。MLPerf 就是 AI 推理界的“米其林评审”——一个由 MLCommons 组织维护的权威基准测试体系，专门用来衡量不同 AI 芯片跑大模型推理时的真实水平。

MLPerf Inference 的“规矩”包括：跑什么模型（比如 GPT-3、GPT-J 这类公开模型）、用什么数据集、batch size 设多少、精度用 FP16 还是 INT8。所有参测硬件都必须在同一套规则下比赛。就像米其林评审指定“做一道麻婆豆腐”，不管你是三星餐厅还是街边小馆，豆腐、肉末、花椒都得按同一份标准来。这样得出的分数才有横向可比性。

MLPerf 推理测试主要有三种场景，对应不同的“营业模式”：

• Offline（离线）：把整个测试集一次性喂给芯片，看它火力全开时的最大吞吐——好比后厨全力出菜，一小时最多出多少道。

• Server（服务器）：请求按现实中的随机节奏到达，看系统在并发压力下的综合表现——好比晚高峰客人随机涌入的餐厅。

• Single Stream（单流）：一次只处理一个请求，测纯粹的延迟——好比只服务一桌客人时上菜有多快。

解读测试结果最忌讳只盯一个数字。同一款芯片，Offline 吞吐可能很漂亮，但 Server 场景下可能因排队导致延迟爆表；换了精度，成绩天差地别。看评测报告要像看米其林评分一样：菜品、环境、服务综合看，还要确认“评审用的菜谱”是否贴近你的业务。

$$\displaystyle \text{吞吐量} = \frac{N_{\text{生成的 token 总数}}}{T_{\text{总耗时（秒）}}}$$

1. N 的分子（生成的 token 总数）：所有被评测的请求加起来，模型一共输出了多少个 token。一个 token 可以粗略理解为一个“词”，8 个 token 大约等于一句中文短句。

$$N_{\text{tokens}} = \sum_{i=1}^{R} L_i$$

2. T 的分母（总耗时）：从第一个请求开始处理，到最后一个请求完成的秒数。排队等待、prefill、decode 的时间全算在里面，相当于餐厅从开工到打烊的整个营业时段。

$$T = T_{\text{结束}} - T_{\text{开始}}$$

3. 两者的比值（每秒产出率）：用总 token 数除以总秒数，得到“平均每秒吐出多少 token”。数字越大，说明芯片在给定工作负载下的“产能”越高。

$$\text{Throughput} = \frac{N_{\text{tokens}}}{T}$$

米其林评审给出的不是“好吃”这种主观评价，而是一套可复现的分数。MLPerf 也一样：有了统一规则和明确的吞吐公式，不同芯片、不同厂商才能真正坐到同一张桌子上比试。下一节我们深入看看吞吐量这个“出菜产能”还有哪些门道。

吞吐量指标

一家餐厅好不好，厨师长最关心的是“高峰期一小时能出多少道菜”。这个数字决定了餐厅能接多少桌客人、能赚多少钱。在推理服务里，对应的指标就是吞吐量——单位时间内模型能处理的请求数或生成的 token 数。一句话：吞吐量衡量“产能”，延迟衡量“体验”。

技术定义上，吞吐量通常写作 tokens/s（每秒生成 token 数）。要读懂这个数字，必须理解 batch size（批次大小）的作用。GPU 是个“大团队”：处理 1 个请求时它开全员大会，处理 64 个请求时它还是开全员大会——会议时间几乎不变，但产出翻了 64 倍。这就是为什么把 batch 从 1 提到 64，吞吐量可能提升好几倍。

$$\displaystyle \text{吞吐量} = \frac{B \times L_{\text{每请求输出长度}}}{T_{\text{每批耗时}}}$$

1. B（批次大小）：一次送进 GPU 一起处理的请求数量。离线评测中，测试方会把成千上万个请求打包成大 batch 一次性塞进去，模拟“厨房一次接 100 桌的菜”。

$$B = \text{Requests per batch}$$

2. 每请求输出长度：这批里每个请求平均生成多少 token。输出越长，整批产出的 token 总数越多。

$$L_{\text{batch}} = \sum_{j=1}^{B} L_j$$

3. 每批耗时：GPU 处理完整批请求的时间。它包含 prefill（备菜）和 decode（出菜）两个阶段。batch 变大时耗时增加，但远没有请求数增加得快——这就是吞吐能大幅提升的原因。

$$T_{\text{batch}} = T_{\text{prefill}} + T_{\text{decode}}$$

天下没有免费的午餐。batch 越大，排在这一批里的每个请求等待时间越长，单个请求的延迟跟着变差。这就是推理领域最经典的“吞吐-延迟权衡”：想把产能拉满，就得让客人多等；想让每桌都快，就得牺牲产能。现实中服务商通过调节并发数寻找平衡点，下一节的延迟指标将展开讲这个矛盾。

延迟指标

吞吐量是老板视角的指标，客人的视角完全不同。客人坐下后只关心一件事：我的菜什么时候上齐？有的店是“大食堂”——产能惊人但每桌等得久；有的店是“私房菜”——一桌一桌慢慢做。评价推理服务两者都得看：吞吐量决定成本，延迟决定口碑。

端到端延迟（end-to-end latency）指用户发出请求到收到完整回复的总时间。它由两部分构成：等待第一个 token 的时间（TTFT）加上后续每个 token 之间间隔（ITL，inter-token latency）的累加。大模型回答是“流式”吐出来的，用户先看到第一个词，再看着回答慢慢变长，所以整体延迟 = 首 token 时间 + 剩余所有 token 的生成时间之和。

$$\displaystyle L_{\text{端到端}} = T_{\text{TTFT}} + \sum_{i=1}^{N-1} \text{ITL}_i$$

1. T_TTFT（首 token 等待）：从请求发出到第一个 token 返回的耗时。用户对“系统有没有反应”的判断几乎完全来自这段时间，类比客人点完菜后等第一道菜上桌的时间。

$$T_{\text{TTFT}} = t_{\text{首token到达}} - t_{\text{请求发出}}$$

2. ITL_i（相邻 token 间隔）：第 i 个 token 与第 i+1 个 token 之间的时间差。decode 阶段每生成一个 token 都要完整跑一遍神经网络前向，所以这个间隔基本等于“单步解码耗时”。

$$\text{ITL}_i = t_{i+1} - t_i$$

3. 累加 N-1 次：第一个 token 由 TTFT 覆盖，后续 N-1 个 token 各有一个间隔，全部加起来才是整段回答的时长。回答越长，decode 部分占的比重越大。

$$\sum_{i=1}^{N-1} \text{ITL}_i = t_N - t_1$$

评测延迟时还有个大陷阱：平均值会骗人。100 个请求里 99 个 1 秒完成，1 个卡了 60 秒，平均才 1.59 秒，看起来很美，但那位等了 60 秒的客人早就投诉了。所以专业的评测报告看百分位：P50 代表“一半请求比它快”，P95 代表“95% 的请求比它快”。服务商定 SLO（服务水平目标）时通常写“P95 延迟小于 X 秒”——意思是只有 5% 的客人可以忍受等待超过红线。这就像餐厅承诺“95% 的桌次在 30 分钟内上齐”而不是吹“平均 15 分钟”。

首Token时间

客人等菜时最焦虑的是哪一段？是点完菜之后盯着厨房的那几分钟。第一道菜上得快的餐厅，哪怕后面匀速上菜，客人也会觉得“这家店利索”。大模型交互同样如此：用户按下回车，如果 0.5 秒内看到第一个字，就会觉得系统“很跟手”；如果 3 秒还没动静，就会怀疑是不是卡死了——哪怕后续生成飞快。

TTFT（Time To First Token，首 token 时间）衡量的正是“从请求发出到收到第一个 token”的耗时。它与模型的 prefill 阶段直接相关：prefill 要先把用户输入的整个 prompt 从头到尾处理一遍，才能生成第一个输出 token。输入越长，prefill 时间越长；并发越高，排队时间越长。这两个因素叠加，构成了 TTFT 的主体。

$$\displaystyle \text{TTFT} = T_{\text{排队}} + \frac{L_{\text{prompt}}}{v_{\text{prefill}}}$$

1. T_排队（排队等待）：请求到达后，在 GPU 调度队列里等待被处理的时长。并发高时 GPU 全被占着，新请求只能排队，好比晚高峰店里没空桌，客人先在大堂等着。

$$T_{\text{排队}} = t_{\text{开始处理}} - t_{\text{请求到达}}$$

2. L_prompt（prompt 长度）：用户输入的提示词包含多少个 token。prompt 越长，prefill 需要读的内容越多，“备菜的食材”越多。

$$L_{\text{prompt}} = \text{输入文本的 token 数}$$

3. v_prefill（prefill 速度）：每秒能并行处理多少 prompt token，由芯片的计算能力决定。prefill 高度并行，就像几十个师傅同时切菜，人多手快。

$$v_{\text{prefill}} = \frac{L_{\text{prompt}}}{T_{\text{prefill}}}$$

优化 TTFT 是推理服务的头号工程目标。常见手段包括：把 prefill 和 decode 拆到不同 GPU 池运行，避免 decode 阶段的长请求堵住新请求的 prefill；用流式输出让第一个 token 一生成就立刻返回，而不是等整段回答完成；用 KV cache 预分配等手段缩短 prefill 耗时。对聊天、搜索、Copilot 这类交互式应用来说，TTFT 就是用户留存的生命线。

两阶段性能

前几节反复提到 prefill 和 decode，这两个阶段就像餐厅后厨的“备菜”和“出菜”，是整场推理的两幕好戏。理解它们的差异，是看懂一切推理性能数据的钥匙。

prefill（备菜）：拿到用户整个 prompt 后，模型对其进行一次完整的并行前向计算。这个阶段的特点是“一次处理全部输入”——就像后厨拿到菜谱，几十个帮厨同时把几十道菜的食材切好码齐。它吃的是计算力，是典型的计算密集型任务，GPU 的算力可以充分跑满。

decode（出菜）：从第一个 token 开始逐字生成后续输出。每个 token 的生成都依赖之前所有 token 的结果，所以无法并行，只能一步一个 token 串行推进。更关键的是，每走一步都要把大模型的全部权重从内存里搬运一遍——真正卡住进度的是内存带宽，而不是纯算力。这就是常说的“访存密集”或“带宽受限”。

$$\displaystyle T_{\text{total}} = T_{\text{prefill}} + (N_{\text{output}} - 1) \times T_{\text{decode\_step}}$$

1. T_prefill（备菜耗时）：一次性并行处理整个 prompt 的时间。因为并行度高，输入长度对耗时的贡献被“多个工人同时干活”摊薄了。

$$T_{\text{prefill}} = \frac{L_{\text{prompt}}}{v_{\text{prefill}}}$$

2. N_output - 1（还需生成的个数）：第一个输出 token 在 prefill 的末尾就顺带产出了，所以剩下的 N-1 个 token 要逐个 decode。输出 50 个 token，就要串行走 49 步。

$$N_{\text{decode}} = N_{\text{output}} - 1$$

3. T_decode_step（单步耗时）：每生成一个 token 需要的时间。它主要受内存带宽限制：权重越大、带宽越窄，这一步就越慢，与算力强弱关系不大。

$$T_{\text{decode\_step}} = \frac{\text{模型权重规模}}{\text{内存带宽}}$$

正是这种“prefill 吃算力、decode 吃带宽”的差异，造就了推理评测中一个反直觉的现象：号称峰值算力很高的芯片，跑 decode 阶段未必快。一些高端 AI 芯片专门设计 prefill/decode 分离架构或超大显存带宽，就是为了同时喂饱这两幕戏。反过来你也能理解，为什么单纯看“TFLOPS 算力”选芯片会踩坑——那是备菜的速度，不是出菜的速度。

并发场景影响

把时间拨到晚上七点，你的川菜馆迎来晚高峰：三十桌客人同时举杯，门口还有十桌排队。这时后厨的行为模式跟平时完全不同——这正是并发对推理性能的塑造。并发数（concurrency）就是同时处于处理状态的请求数量，它是评测中最容易被误读的变量。

低并发下，GPU 处于“饥饿”状态：一两个请求占不满算力，吞吐量很低，但每个请求独享资源，延迟很漂亮。随着并发升高，更多请求把 GPU 喂饱，吞吐量快速上升——这是“多接客”带来的收益。但好景不长，当并发超过某个临界点，GPU 算力和显存带宽都被占满，新请求只能排队，吞吐量趋于饱和，而延迟和 TTFT 开始急剧恶化。这就是经典的“吞吐饱和、延迟爆炸”曲线。

$$\displaystyle C = \lambda \times L$$

1. C（并发请求数）：系统里同时处于“排队或处理中”状态的请求总数。类比餐厅里等待和正在用餐的桌数之和。

$$C = \text{系统内在途请求数}$$

2. λ（到达率）：每秒新到达的请求数量。晚高峰 λ 猛增，就像推门进店的客人一波接一波。

$$\lambda = \frac{\text{新请求数}}{\text{时间间隔（秒）}}$$

3. L（平均延迟）：每个请求从进入系统到处理完成的平均耗时。餐厅里就是客人从落座到结账的时长。

$$L = \frac{\sum \text{各请求延迟}}{R}$$

4. 乘积联动：三者不是独立的。假设延迟翻倍而到达率不变，系统里积压的在途请求就会翻倍；如果系统容量有限，积压最终会变成排队和超时。

$$C \propto \lambda \times L$$

理解并发下的指标变化，对评测和选型有直接指导意义：任何“吞吐 X tokens/s”或“延迟 Y 毫秒”的数字都隐含了前提——在什么并发下测的。专业的评测报告会画出“吞吐-并发”曲线和“延迟-并发”曲线，并标出满足 SLO 的最大并发点。这个点就是容量规划的基准：超过它服务就雪崩，低于它硬件又在浪费。

硬件对比选型

逛完评测报告，终于要回答那个实际问题：该买哪款芯片？这就像餐厅打算升级厨房设备——不能光看设备多贵、功率多大，得让厂商按你的菜单试菜。硬件选型是推理性能评测的终极应用场景。

MLPerf 榜单相当于“米其林指南”，但读榜单有三条铁律。第一，看测试条件：榜单上每一行都注明模型版本、精度、batch 大小、卡数。用 8 张卡跑出来的成绩和 1 张卡直接对比，等于拿 8 个厨师的后厨跟 1 个厨师比出菜量。第二，看场景匹配：你的业务是聊天机器人还是离线批量任务？前者要盯 Server 场景的 TTFT 和 P99，后者直接看 Offline 吞吐。第三，算性价比：最贵的芯片不一定最划算，要把性能换算成成本。

$$\displaystyle \text{每千 token 成本} = \frac{\text{每小时总拥有成本}}{\text{每小时吞吐量（token）}} \times 1000$$

1. 每小时总拥有成本：硬件采购价按折旧年限摊到小时，加上电费、散热、机房租金。好比一套厨房设备的“每小时租金”。

$$\text{TCO}_{\text{hour}} = \frac{\text{采购价}}{365 \times 24 \times \text{折旧年限}} + \text{每小时电费}$$

2. 每小时吞吐量：芯片在目标模型和 batch 条件下实测的吞吐，换算成每小时产出的 token 数。

$$\text{Tokens}_{\text{hour}} = \text{Throughput(tok/s)} \times 3600$$

3. 比值与放大：每小时成本除以每小时产出，得到单个 token 的成本，再乘以 1000 就是“每千 token 成本”。A 卡比 B 卡贵一倍，但吞吐高 2.5 倍，每千 token 成本反而更低。

$$\text{每千token成本} = \frac{\text{TCO}_{\text{hour}}}{\text{Tokens}_{\text{hour}}} \times 1000$$

选芯片就像选厨房设备：米其林榜单（MLPerf）告诉你各家后厨在统一菜谱下的表现，但最终决定权在你——你的菜单（业务场景）是什么？翻台目标（SLO）是多少？预算（TCO）有多少？理解了吞吐、延迟、TTFT 三件套，看懂了 prefill 与 decode 的两幕戏，掌握了并发曲线的拐点，你就拥有了从“看热闹”到“看门道”的完整能力。下次再看到一张推理性能榜单，你已经能从数据里读出那家“后厨”的备菜速度、出菜节奏和晚高峰的真实表现了。

AI 应用场景

Python 演示

"""大模型推理性能模拟器: 演示TTFT/延迟/吞吐与并发的关系"""  class InferenceEngine:    """简化推理引擎: prefill并行快, decode串行慢"""     def __init__(self, prefill_tok_per_ms=100, decode_tok_per_ms=20):        # prefill: 每毫秒可并行处理100个prompt token        # decode: 串行模式, 每毫秒只能产出20个token        self.prefill_speed = prefill_tok_per_ms        self.decode_speed = decode_tok_per_ms     def run_one(self, prompt_len, output_len):        """单请求: 返回(TTFT毫秒, 端到端延迟毫秒)"""        prefill_ms = prompt_len / self.prefill_speed        decode_ms = output_len / self.decode_speed        ttft = prefill_ms        latency = prefill_ms + decode_ms        return ttft, latency     def run_concurrent(self, conc, prompt_len, output_len):        """并发场景: 排队与带宽争抢让延迟上升, 吞吐趋于饱和"""        prefill_ms = prompt_len / self.prefill_speed        # decode是共享瓶颈, 并发越高每个请求的decode越慢        decode_ms = output_len / self.decode_speed * conc        total_ms = prefill_ms + decode_ms        throughput = conc * output_len / (total_ms / 1000)        # 排队导致TTFT随并发恶化        ttft = prefill_ms * (1 + 0.5 * (conc - 1))        latency = prefill_ms + decode_ms        return ttft, latency, throughput  if __name__ == "__main__":    eng = InferenceEngine()    p, o = 200, 50  # prompt 200 token, 输出 50 token    print("=== 单请求基准 ===")    t, lat = eng.run_one(p, o)    print(f"TTFT={t:.1f}ms, 端到端延迟={lat:.1f}ms")    print("\n=== 并发扩展测试 ===")    print(f"{'并发':>4} | {'TTFT(ms)':>9} | {'延迟(ms)':>9} | {'吞吐(tok/s)':>12}")    for c in [1, 2, 4, 8, 16, 32]:        tt, lt, tp = eng.run_concurrent(c, p, o)        print(f"{c:>4} | {tt:>9.1f} | {lt:>9.1f} | {tp:>12.0f}")

1. self.prefill_speed = prefill_tok_per_ms记录 prefill 阶段每毫秒能并行处理多少 prompt token。
2. prefill_ms = prompt_len / self.prefill_speed整个 prompt 一次性并行处理，耗时只算一次。
3. ttft = prefill_ms首 token 时间近似等于 prefill 耗时，因为第一个 token 在“备菜”完成后立即产出。
4. decode_ms = output_len / self.decode_speed * concdecode 串行且共享带宽，并发越高每个请求生成越慢。
5. throughput = conc * output_len / (total_ms / 1000)并发请求的总输出除以总耗时，得到每秒 token 数。
6. for c in [1, 2, 4, 8, 16, 32]:遍历不同并发数，观察指标随并发升高如何变化。

常见误区

面试题