端侧推理性能基准测试

可视化演示

测试准备规划

办咖啡师测评前不能直接开赛。如果A门店用精品豆，B门店用速溶粉，即使同一双手，结果也不公平。所以测评要先制定“同一份菜单、同一批原料、同一台设备状态”，再决定谁去测试。端侧推理性能基准测试也一样。先固定输入集，把问题长度和难度统一；再固定运行环境，包括操作系统版本、CPU/GPU频率、是否关闭后台App；最后建立预热机制，让模型和硬件进入稳定工作状态，而不是冷启动时手忙脚乱的样子。

输入集要覆盖真实场景，不能只用一条短文本。推荐混合短、中、长三种输入长度，让结果有代表性。正式测试前先跑10到20轮预热，让缓存和芯片频率稳定下来；正式轮次建议不少于30次，这样统计才有意义。测试时关闭自动更新、消息推送等后台任务，记录芯片是否降频，因为降频会直接影响延迟和功耗。

这就像统一了咖啡豆、水温和杯型之后，测出来的出杯速度才真正属于咖啡师，而不是属于某家门店的高级设备。

延迟测量方法

顾客开口点单到拿到咖啡，中间要经历确认订单、压粉、萃取、打奶泡多个环节。用户最关心的是“从开口到第一口”的等待时间，而不是后厨里某个单一环节。在生成式AI里，这个概念被拆成两个关键延迟：端到端延迟是从用户提交输入到完整回答结束的时间；首Token延迟则只统计模型生成第一个输出Token的时间，它决定了用户等待第一屏文字出现的体感。

测量延迟并不复杂：给推理调用包一层高精度计时器，按相同流程反复运行，记录每次的耗时。但只看平均数是危险的，因为偶发卡顿会形成长长的尾部。我们需要用百分位数来观察分布，尤其是P95和P99。P95延迟的含义是：在100次请求里，有95次比这个值更快。

把N次延迟从小到大排序，第p个百分点位置上的延迟值，就是Pp延迟。

吞吐量评估

测完单杯出杯速度，还要看咖啡师一整天的出品能力。有的咖啡师一杯杯做很稳，但一次同时做四杯时会更快；可是如果同时涌入八个客人，柜台又会变得混乱。端侧AI也有同样问题：模型的吞吐量通常用每秒生成的Token数来表示，缩写为token/s。吞吐量高的模型，单位时间能服务更多请求，在多用户并发或批处理场景中尤其重要。

测试吞吐量时要固定总的测试任务量。比如一次连续向模型发送大量输入，统计一共生成了多少个Token，再除以总耗时。批处理大小会影响结果：批处理越大，硬件利用率越高，吞吐量通常也越高，但代价是内存占用和单次响应延迟都会上升。所以基准测试要分别记录不同批处理下的吞吐量。

吞吐量等于一定测试时间内完成的Token总数除以总耗时。

内存监控手段

工作台空间决定咖啡师能同时展开多少杯和工具。如果台面被豆子、牛奶、杯具占满，一来新的订单就会手忙脚乱，甚至打翻杯子。手机上的推理同样受内存约束：模型权重加载后占据的空间是静态内存；推理过程中产生的中间激活值、特征图则属于动态内存。运行到某一步时，两者叠加达到最高点，就是峰值内存。

内存监控通常借助系统工具或内存分析库去读取进程占用，例如查看最高地址、RSS或专用内存接口。测试时要故意使用最大输入长度和最大批处理，把峰值逼出来；还要连续跑多轮，观察内存是否一轮比一轮高。如果持续上涨而从不回落，就说明可能存在内存泄漏。

如果峰值内存超出设备可用内存，再快的模型也会被系统杀掉。就像咖啡师技术再好，台面不够，也会在高峰期把柜台炸掉，所以内存峰值是端侧模型能否落地的硬门槛。

功耗测量方案

咖啡师连续工作八小时会腿软、冒汗、心跳加快；手机持续跑模型也会发热、电量下降、触发降频。在端侧AI场景里，功耗不是可有可无的辅助指标，而是决定设备能用多久、会不会烫手的关键。功耗测量通常通过电流电压采集工具或设备电池监控接口完成，记录平均功耗、峰值功耗，再换算成能效比。

平均功耗反映整个测试周期的耗电水平；峰值功耗反映瞬时高负载对供电和散热的压力。更常用的是“每Token能耗”，它把速度和功耗统一到一个数字上：能耗越低，说明模型在省电的同时还不耽误干活。

每Token能耗等于测试期间平均功耗乘以总时长，再除以生成的Token总数。

平台对比策略

比较两个门店的咖啡师，一个用商用咖啡机，一个用家用小机器。如果菜单、杯子、流程都不一样，测出来的差距是人的还是设备的，根本说不清。因此必须让所有咖啡师用同一张试卷。端侧AI也面对同一个问题：不同手机SoC、不同内存带宽、不同系统调度策略，都会让同一个模型跑出完全不同的成绩。

公平对比的核心要求是：同一模型、同一量化精度、同一组输入、同一线程数、同一测试脚本。还要记录每台设备的芯片型号、大核频率、内存余量和温度状态。设备是否降频直接影响结果，所以不能只看宣传跑分，必须实测。为了让不同量级的指标可以横向比较，可以把每个平台的延迟、吞吐、内存、功耗换算成归一化得分。

通过“同一张试卷”，赢的人才是真正的强者。否则你分不清到底是模型更优，还是仅仅因为那台手机芯片更贵、散热更好。

数据分析处理

多次比赛不能只看最好成绩。某一次豆子刚好在最佳状态，成绩特别高；另一次有人突然进来问路，咖啡师分心多花了五秒钟。这些偶然因素在基准测试里叫“抖动”。如果只看平均值，一次极端卡顿就可能把整体印象带偏。所以在延迟、吞吐、内存、功耗的原始记录出来后，要先看时序图和分布，再看中位数、均值、标准差和置信区间。

统计上常用的做法是给出样本均值和95%置信区间，说明“真实平均水平大概率落在哪个范围”。清理异常值时也要小心，不能没有理由地删数据。如果设备在测试中途降频，应当把降频前后的数据分开报告，因为它们的硬件状态不同，混在一起会掩盖真实规律。

置信区间用样本均值和标准差估算真实平均值的可能范围，z通常取1.96代表95%置信水平。

基准报告编写

比赛结束后，老板需要一份总结：用的什么豆子、什么机器、测了多少轮、谁胜出、怎么复现。这份报告决定要不要录用这位AI咖啡师。如果只留下一句“A比B快”，下次换一台新手机就完全无法对照。因此，一份合格的端侧推理基准测试报告必须让别人能在相同条件下重新得到相近结果。

报告的标准结构应包括：测试目的、设备环境、系统版本、模型名称与量化配置、输入数据描述、预热轮次与重复次数、指标定义、原始统计结果、图表和最终结论。还要附上测试日期和使用的脚本版本，最好给出可复现的具体命令。这样任何接手的人都能按图索骥。

没有完整报告，测试数据就像用过就扔的塑料袋，无法沉淀价值。有了报告，每次测评都能变成可追溯的“星级档案”，帮助团队在后续版本里持续回看性能是否倒退。

AI 应用场景

Python 演示

import timeimport mathimport randomimport statisticsimport tracemalloc  def mock_inference(steps=40000):    ""“模拟端侧模型推理，做一段浮点运算以产生可测量的耗时”""    total = 0.0    for i in range(steps):        total += math.sqrt(float((i % 997) + 1))    return total  def main():    input_steps = 40000    warmup = 5    repeats = 30     print(“准备阶段：先加载模型并预热……”)    for _ in range(warmup):        mock_inference(input_steps)     tracemalloc.start()    latencies_ms = []    for _ in range(repeats):        start = time.perf_counter()        mock_inference(input_steps)        cost = (time.perf_counter() - start) * 1000.0        latencies_ms.append(cost)     current, peak = tracemalloc.get_traced_memory()    tracemalloc.stop()     avg_ms = statistics.mean(latencies_ms)    med_ms = statistics.median(latencies_ms)    sorted_ms = sorted(latencies_ms)    p95 = sorted_ms[int(0.95 * len(sorted_ms)) - 1]     mock_tokens = 16.0    throughput = mock_tokens / (avg_ms / 1000.0)    avg_power_w = 2.0    total_time_s = repeats * (avg_ms / 1000.0)    energy_per_token = (avg_power_w  total_time_s) / (repeats  mock_tokens)     print(“平均延迟：%.2f ms” % avg_ms)    print(“中位延迟：%.2f ms” % med_ms)    print(“P95延迟：%.2f ms” % p95)    print(“吞吐量：%.2f token/s” % throughput)    print(“峰值内存：%.2f MiB” % (peak / 1024 / 1024))    print(“每token能耗：%.4f J” % energy_per_token)  if name == "main":    main()

常见误区

面试题