想象你开了一家餐厅：菜谱是 AI 模型，后厨是芯片。训练模型就像研发菜谱——反复试味、调整用料，最后定稿；推理则像照着菜谱出菜——顾客下单，后厨动手，越快越好。可市面上的芯片五花八门，GPU、ASIC、CPU 各说各话，都说自己“出菜最快”。到底信谁？这就需要一套“业界公认的测评标准”。MLPerf 推理基准，就是 AI 芯片界的“米其林指南”：它规定统一的菜谱（模型）、统一的食材（数据集）、统一的规则（服务质量约束），让所有后厨同台竞技。比赛分三场：单流——贵宾包间点一道菜做一道，看多久上桌；多流——多桌同时开席，看在每桌都按时上菜的前提下能同时招待几桌；服务器——全天候高峰接待，看 99% 的客人都能按时上菜时，一天最多出多少单。读懂这三场考试，你就看懂了 AI 芯片推理性能的全貌。

岗位关联

掌握 MLPerf 推理基准的三大场景与评分逻辑，AI 从业者才能在硬件选型、容量规划和性能优化时看懂权威数据，不被厂商宣传话术带偏。

目录
  1. 可视化演示
  2. 推理评测缘起
  3. 评测方法论
  4. 单流场景
  5. 多流场景
  6. 服务器场景
  7. 结果解读
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示MLPerf推理基准单流串行处理、多流并行QoS约束及服务器高吞吐对比三种核心模式，直观呈现AI推理硬件标准化评测的完整技术框架。

本节配有交互动效（进入视口后自动加载，约 3KB）。

SingleStream单流场景 单流模式逐个处理查询测量纯单次推理响应能力 90百分位延迟(p90)作为核心评分指标约束QoS Latency_p90 ≤ QoS_target 单流场景模拟实时AR等交互式推理应用

推理评测缘起

开餐厅，菜谱是灵魂。AI 世界里，菜谱就是深度学习模型：训练阶段如同研发菜谱，厨师（训练算法）反复调整配料和火候，最终得到一套固定的参数。一旦菜谱定稿，真正的考验才开始——后厨能不能在顾客点单后迅速把菜端上桌？这个“按菜谱出菜”的过程，就是推理。用户打开手机里的语音助手、刷脸支付、AI 相机，体验到的全是推理速度。可市面上的后厨——GPU、ASIC、CPU——各有绝活，有的擅长大火爆炒，有的擅长文火慢炖，没有统一标准时，每家餐厅都自称“传菜速度行业第一”。

于是，MLCommons 这个“餐饮行业协会”出场了。它由 NVIDIA、Intel、Google、Arm 等全球主流芯片与系统厂商联合组成，于 2020 年正式发布 MLPerf 推理基准，宗旨很简单：用同一套菜谱、同样的食材、明确的规则，让所有后厨公平赛马。基准中的“菜谱”是统一的神经网络模型，如 ResNet-50 图像分类、SSD 目标检测、BERT 自然语言理解；“食材”是标准化数据集，如 ImageNet、SQuAD；“火候”是精度要求，比如 FP32 模型必须达到参考实现的 99% 精度。任何厂商想参赛，都得遵守这套规矩。

为什么要如此大费周章？因为推理性能直接决定产品体验和成本。同一个模型，在不同芯片上的延迟可能相差数倍，而延迟每增加 100 毫秒，用户流失率可能上升几个百分点。没有权威基准，采购者只能靠厂商 PPT 纸上谈兵。MLPerf 推理基准的出现，就像米其林指南统一了餐厅评级标准——从此，后厨强不强，比一比就知道。

评测方法论

米其林评审有自己的评分卡：菜品、环境、服务，每一项都权责分明。MLPerf 推理基准的评测方法论同样如此，它规定了四个核心维度。第一是负载模型：基准选用 ResNet-50、SSD、BERT、GPT 等具有代表性的模型，覆盖图像分类、目标检测、自然语言处理等主流 AI 任务，就像评审既吃粤菜也吃川菜。第二是数据集场景：每个模型绑定标准数据集，保证所有参赛者面对同样的“食材”。第三是精度目标：芯片厂商不能通过牺牲精度换取速度，FP32 精度必须达到参考模型的 99% 以上，INT8 等量化精度也有对应要求，相当于“菜可以快，但不能夹生”。第四是性能度量：延迟与吞吐量是核心指标，而延迟的度量方式藏着关键学问。

延迟为什么不能只用“平均值”？想象餐厅有 100 桌客人，99 桌 10 分钟上菜，1 桌等了 2 小时，平均值才 11 分钟，看起来不错，可那桌客人早已差评。AI 推理同理，偶发的超慢请求会直接毁掉用户体验，比如自动驾驶遇到一次迟到的识别结果就可能酿成事故。因此，MLPerf 采用百分位延迟来描述真实体验。

类比米其林评审记录每桌的上菜时间，P90 就是“九成顾客都能接受的最长等待时间”。这套方法论奠定了三大场景的评分基础——单流、多流、服务器场景都以百分位延迟作为 QoS 约束，只是考察的角度不同。

L90=min⁡{l∣P(L≤l)≥0.9}\displaystyle L_{90} = \min\{ l \mid P(L \le l) \ge 0.9 \}
通俗说：把 100 次请求的延迟从小到大排队，第 90 名那个时间点就是 P90 延迟。它回答的是“九成请求都能快到这个程度”。
  1. 收集样本先积累大量请求的延迟观测值，记为随机变量 $L$。
    L∼{l1,l2,…,ln}\displaystyle L \sim \{ l_1, l_2, \dots, l_n \}
  2. 按大小排序把所有延迟从小到大排成有序序列。
    l(1)≤l(2)≤⋯≤l(n)\displaystyle l_{(1)} \le l_{(2)} \le \dots \le l_{(n)}
  3. 定位索引计算 90% 分位对应的排名位置。
    k=⌈0.9×n⌉\displaystyle k = \lceil 0.9 \times n \rceil
  4. 读出 P90第 $k$ 个值就是 90% 分位延迟。
    L90=l(k)\displaystyle L_{90} = l_{(k)}

单流场景

单流场景像是餐厅的“贵宾包间服务”：一次只接待一位客人，点一道菜，后厨全力做一道，做完再接待下一位。整个过程中不存在并发，只关心一件事——这道菜从下单到上桌要多久。在 MLPerf 推理基准中，SingleStream 场景正是如此：系统每次只提交一个推理请求，等待上一个请求完成后，再提交下一个，完全串行执行。这种负载特征对应着真实世界里延迟最敏感的应用，比如在线翻译、实时语音识别、交互式对话，用户按一下按钮，就等着结果弹出来。

单流场景的 QoS 约束非常直接：90% 分位的延迟必须低于目标延迟阈值。每个模型都有对应的目标值，例如某些图像分类模型要求 P90 延迟在 20 毫秒以内。评分方法也简单——直接把这个 P90 延迟值作为成绩，数值越小越好。如果 P90 超过了目标阈值，这次测试就不及格。

贵宾包间考验的不是“同时能接多少客”，而是“每一道菜是否都足够快且稳定”。单流场景就像给芯片做了一次“单线程压力测试”——它不关心芯片的总吞吐能力，只关心在低并发下，每一个请求是否能被快速响应。某些芯片在单流场景表现优异，却在多流场景中败下阵来，说明它“单打独斗”很强，“团队协作”不足。

Rsingle=L90=min⁡{l∣P(L≤l)≥0.9},Rsingle≤Ttarget\displaystyle R_{\text{single}} = L_{90} = \min\{ l \mid P(L \le l) \ge 0.9 \}, \quad R_{\text{single}} \le T_{\text{target}}
通俗说：单流成绩就是“九成请求的最坏延迟”，它必须小于目标红线，比如 90% 的翻译请求在 20 毫秒内返回。
  1. 串行执行系统依次处理请求，每次只允许一个请求在途。等待时间累积起来，就是每次请求的延迟。
    Li=tend,i−tstart,i\displaystyle L_i = t_{\text{end},i} - t_{\text{start},i}
  2. 计算 P90对所有请求延迟求 90% 分位，得到本场景评分。
    Rsingle=L90\displaystyle R_{\text{single}} = L_{90}
  3. 与阈值比较将 P90 与模型预设的目标延迟做比较，判断是否达标。
    Rsingle≤Ttarget\displaystyle R_{\text{single}} \le T_{\text{target}}

多流场景

餐厅到了聚餐旺季，包间不够用了，大厅里十几桌同时开席。每桌客人点了自己的菜，后厨同时开工，但要保证每一桌的菜都能在承诺时间内上齐。这就是多流场景的写照。在 MLPerf 推理基准中，MultiStream 场景模拟的是多路摄像头视频流、多个传感器数据流等应用：系统固定开启 $N$ 个并发流（stream），每个流内部依次发送请求，多个流之间并行执行。流与流之间互不干扰，就像每桌客人有自己的菜单。

多流场景的 QoS 约束比单流更严格：每个流内请求的 99% 分位延迟都必须低于目标上限。为什么是 P99？因为多流场景往往服务于安全相关的应用，比如自动驾驶同时处理多个摄像头画面，任何一路画面的识别延迟超标都可能造成危险。评分方法是“递增策略”：从 1 个流开始测试，若延迟达标，就增加到 2 个、4 个、8 个……直到某一路流的延迟超过上限为止，记录下能达标的最大流数 $N_{\max}$。

多流场景就像考验后厨的“并行协调能力”——菜刀、灶台、烤箱不能打架，每一桌的进度都不能拖后腿。值得强调的是，多流的成绩不是某个固定的吞吐数字，而是“最大并发流数”，这反映了芯片在处理多路并行任务时的稳定性。如果一个芯片单流表现出色，但四路并发时就乱了阵脚，它的多流分数就会很难看。

Nmax⁡=max⁡{N∣∀ i∈[1,N],    L99(i)≤Ttarget}\displaystyle N_{\max} = \max\left\{ N \mid \forall\, i \in [1, N],\;\; L_{99}^{(i)} \le T_{\text{target}} \right\}
通俗说：想多接待几桌客人，但每桌 99% 的菜都必须在限时内上齐——在满足这个前提下的最大开席桌数，就是多流场景的最终成绩。
  1. 开启 N 个流初始化 $N$ 个并发请求流，每个流按自己的节奏发请求。
    streami,i=1,2,…,N\displaystyle \text{stream}_i,\quad i = 1, 2, \dots, N
  2. 分流计算延迟对每个流分别统计请求延迟的 99% 分位。
    L99(i)=percentile(L(i),0.99)\displaystyle L_{99}^{(i)} = \text{percentile}(L^{(i)}, 0.99)
  3. 全校验所有流的 P99 都低于目标延迟，本次 $N$ 才算通过。
    ∀ i:L99(i)≤Ttarget\displaystyle \forall\, i: L_{99}^{(i)} \le T_{\text{target}}
  4. 递增找极限逐步增大 $N$，找到仍能全部达标的最大值。
    Nmax⁡=max⁡{N∣全流通过}\displaystyle N_{\max} = \max\{N \mid \text{全流通过}\}

服务器场景

如果说单流是包间、多流是大厅，那服务器场景就是“商业中心美食街的黄金档餐厅”：没有预约，顾客随时推门而入，点单请求像潮水一样不断涌来。后厨必须一边接单一边做菜，偶尔来一大波客人，订单就瞬间堆积。MLPerf 推理基准中的 Server 场景正是模拟这种在线服务的真实负载：请求按照泊松过程随机到达，系统需要持续响应，并在后台对请求进行排队调度。

服务器场景的 QoS 约束核心是“达标占比”：在目标延迟区间（例如 250 毫秒）内完成的请求必须占总请求数的 99% 以上。这允许极少数请求超时，但超时比例不能超过 1%。在这个约束下，基准测试逐步加大请求到达速率，寻找系统能稳定支撑的最大吞吐量，即有效吞吐，单位是每秒处理的查询数（QPS）。它衡量的是“99% 的客人都能按时上菜时，这家餐厅一小时最多能接待多少单”。

服务器场景是三场考试中最接近真实业务的一场。它考验的不是峰值爆发力，而是“持续高压下的稳定性”。有些芯片单流延迟很低，但一旦请求像潮水般同时涌来，调度器就会手忙脚乱，有效吞吐远低于纸面算力。这也是为什么云厂商在选购推理服务器时，最关心的就是服务器场景的 QPS 数据——它直接决定了同样数量的 GPU 能服务多少在线用户。

Qeff=max⁡{q  |  Nok(q)Ntotal(q)≥0.99}\displaystyle Q_{\text{eff}} = \max\left\{ q \;\middle|\; \frac{N_{\text{ok}}(q)}{N_{\text{total}}(q)} \ge 0.99 \right\}
通俗说：把请求速率一点点调高，直到系统开始“忙不过来”、超时请求超过 1% 为止。前一个还能保持 99% 达标的速率，就是服务器的有效吞吐。
  1. 模拟随机到达请求按泊松过程随机到达，速率为 $\lambda$，也就是平均每秒来 $\lambda$ 个请求。
    到达间隔∼Exponential(λ)\displaystyle \text{到达间隔} \sim \text{Exponential}(\lambda)
  2. 记录响应时间系统处理每个请求，统计在目标延迟 $T_{\text{target}}$ 内完成的请求数。
    Nok=∑j=1NtotalI(Lj≤Ttarget)\displaystyle N_{\text{ok}} = \sum_{j=1}^{N_{\text{total}}} \mathbb{I}(L_j \le T_{\text{target}})
  3. 计算达标率达标请求数除以总请求数，判断是否满足 99% 约束。
    NokNtotal≥0.99\displaystyle \frac{N_{\text{ok}}}{N_{\text{total}}} \ge 0.99
  4. 最大化速率不断增大 $\lambda$，直到达标率跌破 0.99，取之前最大速率为有效吞吐。
    Qeff=max⁡{q∣达标率≥0.99}\displaystyle Q_{\text{eff}} = \max\{ q \mid \text{达标率} \ge 0.99 \}

结果解读

米其林榜单公布后，食客们会翻着榜单挑选餐厅，但聪明的食客会看细节：这家餐厅是专做粤菜还是法餐？人均消费多少？排队多久？MLPerf 推理结果的解读同样需要“看细节”。首先，榜单按提交者（submitter）分组，同一个厂商可以提交多套系统，每套系统都列明硬件配置、软件栈和功耗；其次，结果按系统类型和应用场景分类展示，比如数据中心区的服务器场景和边缘设备的单流场景，不能混为一谈，更不能拿边缘芯片的分数去对比数据中心 GPU。

纵观历届 MLPerf 推理结果，可以看到清晰的格局：NVIDIA 的 GPU 在数据中心服务器场景中持续领跑，凭借 CUDA 生态和 TensorRT 优化，在 BERT、GPT 等大模型推理上展示了最高的有效吞吐；Google 的 TPU 在自家负载上表现亮眼，但在通用模型的灵活性上略逊一筹；Intel 等厂商的 CPU 在低延迟的单流场景仍有独特价值，尤其适合对成本敏感、并发不高的业务；各类 ASIC 芯片则在特定模型上能实现极高的能效比。值得一提的是，推理结果还提示了一个重要趋势：延迟与吞吐往往不可兼得——追求极致吞吐需要增大批处理，而批处理会推高单请求延迟。厂商要在服务质量约束下寻找两者的平衡点，这个平衡点正是榜单分数的意义所在。

在实际选型时，不妨把榜单当成“体检报告”而非“排名奖牌”：先明确自己的业务属于哪种场景——是交互式 AI 助手（单流）、多路视频分析（多流），还是大规模在线服务（服务器）——再对应查看该场景下的吞吐量和延迟数据，同时结合功耗、芯片采购成本和软件适配成本综合决策。毕竟，米其林三星法餐厅固然好，但你家楼下需要的是出餐快、性价比高的面馆；选 AI 推理芯片，从来不是在排行榜上选第一名，而是在自己的业务约束下选最优解。

AI 应用场景

推理服务器选型

阶段：硬件选型与部署

解决的问题：芯片厂商宣传材料往往强调“最高算力”或“理论性能”，但这些指标在真实推理负载中可能严重失真。MLPerf 推理基准用统一模型和规则提供可对比的延迟与吞吐数据，帮助采购方在 GPU、ASIC、CPU 之间做出理性选择。

具体案例：某互联网公司计划上线智能客服系统，候选芯片为 NVIDIA H200、AMD MI300X 与 Intel Gaudi 3。工程师参考最新 MLPerf 推理结果中服务器场景 BERT 模型的 QPS 数据，对比三者的有效吞吐、P99 延迟和单卡功耗，最终选择了在目标延迟约束下 QPS 最高且功耗更优的方案，避免了“纸面算力高、实际吞吐低”的坑。

在线推理服务容量规划

阶段：运维与容量规划

解决的问题：线上推理服务面临流量波动，GPU 集群配置过多则浪费成本，配置过少则高峰期延迟超标。利用 MLPerf 服务器场景的 QoS 约束方法论，可以在部署前推算单卡能承载的 QPS，实现精准扩容。

具体案例：某视频审核平台预估双十一高峰期请求量为 5000 QPS，参考 MLPerf 服务器场景中该模型在单卡上的有效吞吐（假设 800 QPS），工程师计算出至少需要 7 张卡，再按 20% 冗余规划到 9 张卡。实际运行中，P99 延迟始终低于设定目标，集群成本比经验性配置节省了约 30%。

推理性能瓶颈定位

阶段：模型部署与性能优化

解决的问题：单流场景模拟了用户交互式请求的延迟体验，开发者在优化推理服务时，可以复现单流测试方法，用 P90/P99 延迟分布定位瓶颈究竟在模型计算、数据加载还是显存拷贝环节。

具体案例：某团队部署大语言模型对话服务时发现用户感知的首 token 延迟偏高。他们参考单流场景的方法，构建延迟采集管线，绘制 P90 延迟分布，发现瓶颈不在模型解码而在 KV Cache 的显存分配。针对性优化后，P90 首 token 延迟从 480 毫秒降至 220 毫秒。

Python 演示

python60 行
import random class LatencyBench:    def __init__(self, seed=42):        random.seed(seed)        self.base_mean = 18.0        self.base_std = 4.0     def gen_latencies(self, n):        return [max(0.5, random.gauss(self.base_mean, self.base_std))                for _ in range(n)]     def p90(self, lats):        s = sorted(lats)        idx = int(0.9 * len(s)) - 1        return s[max(0, idx)]     def single_stream(self, target_ms=20.0):        lats = self.gen_latencies(100)        p = self.p90(lats)        return p, p <= target_ms     def multi_stream(self, max_flows=16, target_ms=22.0):        best = 0        for n in range(1, max_flows + 1):            ok = True            for _ in range(n):                p = self.p90(self.gen_latencies(50))                if p > target_ms:                    ok = False                    break            if ok:                best = n            else:                break        return best     def server(self, reqs=500, target_ms=25.0, qos=0.99):        served = 0        for _ in range(reqs):            lat = self.gen_latencies(1)[0]            if lat <= target_ms:                served += 1        ratio = served / reqs        qps = ratio * 1000.0        return ratio, qps  def main():    bench = LatencyBench()    p, passed = bench.single_stream(20.0)    print('单流场景: P90=%.2f ms, 达标=%s' % (p, passed))    n = bench.multi_stream(16, 22.0)    print('多流场景: 最大并发流数=%d' % n)    ratio, qps = bench.server(500, 25.0, 0.99)    print('服务器场景: 达标率=%.3f, 有效吞吐=%.1f qps' % (ratio, qps))  if __name__ == '__main__':    main()
目的：用蒙特卡洛方法模拟一个推理芯片在单流、多流、服务器三个 MLPerf 场景下的延迟采样与评分计算，帮助理解各场景的 QoS 逻辑。
  1. class LatencyBench定义了一个“基准测试台”，内部封装延迟生成与三类场景的评分方法。
  2. self.base_mean = 18.0设定芯片的“基础上菜时间”为 18 毫秒，作为延迟采样的平均值。
  3. random.gauss(self.base_mean, self.base_std)用高斯分布模拟请求延迟的随机波动，就像每道菜的实际出菜时间有快有慢。
  4. def p90(self, lats)实现百分位延迟计算：先排序，再取第 90% 位置的值，对应文章中的 P90 公式。
  5. sorted(lats)把延迟样本从小到大排队，方便定位分位数。
  6. idx = int(0.9 * len(s)) - 1算出 90% 分位在排序数组中的索引，相当于公式里的 $k = \lceil 0.9 \times n \rceil$。
  7. single_stream模拟单流场景：串行取 100 个延迟样本，计算 P90 并与目标阈值比较。
  8. multi_stream模拟多流场景的递增策略：从 1 流开始逐级增加，直到某流的 P90 超标为止。
  9. server模拟服务器场景：统计 500 个随机请求中延迟达标（≤25ms）的占比，并换算成有效 QPS。
  10. if __name__ == '__main__':作为程序入口直接运行三种场景，输出评分结果。

常见误区

误区我看了榜单，某款芯片单流场景 P90 延迟只有 5 毫秒，比别家快一倍，那它的推理性能肯定全面领先，直接选它准没错。

正解单流场景只考察“一次一个请求”时的延迟，完全不反映高并发下的吞吐能力。就像一家只能一对一服务的私房菜馆，顾客一多就彻底瘫痪；而真正的云服务往往需要同时处理成百上千个请求。单流低延迟只说明“单打独斗”强，还要结合多流和服务器场景的综合表现来判断。

为何常见：单流数字最直观、最好理解，厂商在宣传时也最爱把最低延迟挂在嘴边，用户很容易被单一指标带偏。

误区多流场景分数是最大流数，那流数越大肯定越难，芯片撑不住是正常的，能跑到 4 流已经很不错了。

正解多流场景的流数上限通常由并行度和延迟共同决定。结论反直觉的地方在于：有些芯片单流延迟很低，但多流一开就互相抢占资源，流数稍增 P99 立刻超标；而有些吞吐型芯片虽然单流延迟一般，却能稳定撑到 8 流甚至 16 流。难易与否取决于芯片架构与调度能力，而不是单纯的主观判断。

为何常见：人们习惯用“多少路并行”来直观衡量能力，忽略了多流场景本质上是“在每流延迟约束下的并行稳定性测试”。

误区服务器场景的成绩就是 QPS，谁家 QPS 高谁就强，所以只看榜单第一名的吞吐数字就够了。

正解服务器场景的 QPS 是“在 99% 请求延迟达标的 QoS 约束下”的有效吞吐，脱离了 QoS 谈吞吐毫无意义。如果某芯片把批处理拉到最大，QPS 虚高，但 P99 延迟冲到几秒，在真实在线服务中早就把用户逼走了。解读成绩时必须同时关注达标率与延迟分布。

为何常见：吞吐是决策者最关注的“硬指标”，而 QoS 需要看细则，容易被忽略，导致“唯 QPS 论”。

误区MLPerf 推理榜单上某芯片的 QPS 是 2000，那我买来部署，线上也能达到 2000 QPS。

正解MLPerf 是受控环境下的标准化测试，实际部署还受到网络传输、数据加载、前后处理、框架版本、热量功耗墙等因素影响，性能通常会有折损。基准的作用是提供可比较的参照系，而非精确的容量预测。正确做法是参考榜单做初步筛选，再用自己的业务流量做压测验证。

为何常见：排行榜的数字天然带有“确定性”的暗示，人们容易把它当成出厂性能标定，忽略了测试环境与实际环境的巨大差异。

误区单流场景 P90 是 20ms，服务器场景 P99 是 250ms，说明这个芯片在服务器场景下更慢，性能有退化。

正解三类场景的负载模型、并发方式、QoS 约束完全不同，分数之间没有可比性。单流测的是串行低负载延迟，多流测并行稳定性，服务器测随机到达下的持续吞吐——它们回答的是不同问题。跨场景比较分数，就像拿餐厅的包间翻台率去对比外卖平台的出单量，毫无意义。

为何常见：三套分数都叫“延迟”和“吞吐”，名词上的相似掩盖了评测语义的差异，初学者极易混为一谈。

面试题

Q1. MLPerf 推理基准包含以下哪一组标准场景？

单选题 · easy

  • A.单流、多流、服务器← 正确答案
  • B.离线、训练、微调
  • C.云端、边缘、终端
  • D.单卡、多卡、集群

答案：A。MLPerf 推理基准定义了三个标准场景：SingleStream（单流）、MultiStream（多流）和 Server（服务器），分别对应低延迟交互、多路并行和在线持续服务三类负载。B 中训练与微调属于训练阶段而非推理场景，C、D 是按部署位置的旧分类。

Q2. 单流场景的核心评分指标是下列哪一项？

单选题 · easy

  • A.90% 分位请求延迟← 正确答案
  • B.全部请求平均延迟
  • C.最快请求返回时间
  • D.最大并发请求数量

答案：A。单流场景一次只处理一个请求，QoS 约束是 90% 分位延迟低于目标阈值，最终成绩就是 P90 延迟值。平均延迟会被少数慢请求拉低感知，最快请求时间没有代表性，单流场景本身也没有并发，所以 B、C、D 都不对。

Q3. 服务器场景的核心竞争力指标是什么？

单选题 · easy

  • A.满足 QoS 的最大有效吞吐← 正确答案
  • B.芯片的最高理论浮点算力
  • C.单次请求的最低延迟
  • D.模型参数存储容量

答案：A。服务器场景模拟在线请求随机到达，要求在 99% 请求延迟达标的 QoS 约束下，找到最大可支撑的吞吐量（QPS）。理论算力与实际吞吐往往差距悬殊，单次延迟不是场景重点，显存容量更是无关选项。

Q4. 多流场景中“最大流数”指的是什么？

单选题 · mid

  • A.满足延迟约束的最大并发流← 正确答案
  • B.芯片支持的硬件线程最大数
  • C.测试时使用的数据批次大小
  • D.服务器网卡支持的最大连接

答案：A。多流场景从 1 个流开始递增，在每一个流的 99% 分位延迟都低于目标上限的前提下，能达到的最大 N 就是成绩。“最大流数”是评测语义，与硬件线程数、批次大小、网卡连接无关。

Q5. P90 延迟 = 20ms 的正确含义是什么？

单选题 · mid

  • A.90% 的请求延迟不超过 20 毫秒← 正确答案
  • B.所有请求延迟都低于 20 毫秒
  • C.10% 的请求延迟恰好等于 20 毫秒
  • D.请求的平均延迟是 20 毫秒

答案：A。P90 是 90% 分位延迟，意味着把延迟从小到大排序后第 90% 位置的值是 20ms，即九成请求都不超过它。它既不保证全部请求达标，也不描述平均值，C 选项对分位的解读是错的。

Q6. MLPerf 推理基准的评测组成要素包括哪些？

多选题 · mid

  • A.统一的神经网络模型← 正确答案
  • B.标准化的测试数据集← 正确答案
  • C.明确的精度下限要求← 正确答案
  • D.固定的硬件采购价格

答案：ABC。MLPerf 推理基准通过统一模型（如 ResNet-50、BERT）、标准数据集、精度目标（如 FP32 参考实现精度的 99%）来保证公平对比。硬件价格不在评测要素之中，它与性能无关，是选型时另行考虑的因素。

Q7. 关于训练与推理的区别，下列说法正确的是？

单选题 · mid

  • A.训练更新权重，推理用权重做预测← 正确答案
  • B.推理需要更多的标注数据
  • C.训练过程只能在 CPU 上运行
  • D.推理不依赖于神经网络结构

答案：A。训练阶段通过反向传播不断更新模型权重，相当于研发菜谱；推理阶段使用固定权重对新输入做前向预测，相当于按菜谱出菜。推理不需要额外标注数据，训练在 GPU 上更常见，推理当然依赖模型结构。

Q8. 服务器场景测得延迟达标率为 98.5%，未达到 99% 的 QoS 约束，正确的操作是什么？

单选题 · hard

  • A.忽略 0.5% 偏差直接上报结果
  • B.降低请求速率重测，取达标时的最大吞吐← 正确答案
  • C.只统计最快的 99% 请求重新计算
  • D.把目标延迟阈值调小后再测一次

答案：B。服务器场景的评分逻辑是在 QoS 达标的前提下追求最大吞吐。98.5% 意味着当前速率超出系统能力，应当降低请求速率重新测量，直到达标率回到 99% 以上，并以此时在的速率为有效吞吐。A 违背评测规则，C 属于篡改数据，D 调小阈值只会让达标更难。

Q9. 解读 MLPerf 推理排行榜时，正确的关注点有哪些？

多选题 · hard

  • A.查看提交者及系统配置明细← 正确答案
  • B.确认场景与模型是否匹配自身业务← 正确答案
  • C.综合考虑功耗、成本等非性能因素← 正确答案
  • D.只认排行榜第一名，直接照搬配置

答案：ABC。排行榜需结合提交者、软硬件配置、场景模型与自身业务匹配度来读，选型还要考虑功耗和成本。直接照搬第一名配置忽略了业务负载差异，D 正是典型误区。

Q10. 多流场景中，延迟 QoS 约束通常考察的是哪个统计量？

单选题 · extreme

  • A.每个流内的 99% 分位延迟← 正确答案
  • B.所有流合并后的 90% 分位延迟
  • C.所有请求的平均响应时间
  • D.系统达到峰值吞吐时的瞬时延迟

答案：A。多流场景为每路流设置独立的 P99 延迟上限，要求每一路流的 99% 分位延迟都达标，而不仅是全局合并后的统计。这是因为多流场景模拟多路安全关键型应用，任何一路的超标都不可接受，合并统计会掩盖个别流的延迟恶化。