本地大模型推理速度怎么测：指标、矩阵与解读

简介：本文给出本地大模型推理速度的可复现评测方法，包括tokens/s的统一计数口径、预热与重复测试规则、长上下文与长时间稳定性测试矩阵，以及结果解读的三级判定和选型验证清单。读者可据此判断一份自测数据能否用于选型。

一、先统一指标口径

同一个模型的速度数字，常因计数方式不同而无法比较。评测前应先固定指标定义。

Prefill 速度：处理输入提示词的速度，单位 tokens/s，等于输入 token 数除以从请求发出到首个输出 token 之前的耗时。它决定长提示词场景下的等待时间，编码 Agent 和文档问答对它最敏感。
Decode 速度：逐个生成输出 token 的速度，单位 tokens/s。只统计输出 token，不计入输入。常用算法是用输出 token 数减一，再除以首个 token 到末个 token 之间的耗时。
TTFT（首 token 延迟）：从发出请求到收到第一个输出 token 的时间。
TPOT（每输出 token 耗时）：decode 阶段平均每个 token 的耗时，约等于 decode 速度的倒数。
资源指标：测试期间的显存峰值、内存峰值、功耗和温度。

token 数应来自推理引擎返回的 usage 字段或同一分词器的计数。按字符数或单词数估算的 tokens/s 不能与其他数据直接比较。

本文的样本是一则未具名的用户自述，涉及三类内容：一个 27B 参数的稠密模型，一个总参数约 35B、每次激活约 3B 的稀疏混合专家（MoE）模型，以及一个声称支持超长上下文的版本。本文不复述样本中的速度数字，也不对其作背书，只把这些数字当作待验证的假设。

缺少环境记录的数字不能用于横向比较。每次测试至少记录以下内容。

对比时应固定采样参数。建议把 temperature 设为 0，或固定随机种子。输出长度也要固定。部分引擎支持忽略结束符的参数，支持时打开即可。不支持时，应选用能稳定生成足够长输出的提示词，避免模型提前结束，导致每次的输出 token 数不一致。

单用户延迟测试使用 batch=1。多并发测试单独进行，结果不与单用户数据混在一起。

MoE 模型的显存占用主要由总参数决定，每个 token 的计算量主要由激活参数决定。专家路由、专家在显存与内存之间的换入换出，以及多卡通信，都会改变实际速度。因此，表面上的总参数和激活参数数字，不能直接推算出速度。

按以下步骤执行。

冷启动：记录模型加载耗时，以及加载完成后的显存占用。冷启动数据单独报告，不混入稳态结果。
预热：完成至少 2 次结果丢弃的请求，让 CUDA 图、KV 缓存分配和内核编译稳定下来。
正式测量：同一配置至少重复 3 次，每次记录 prefill 速度、decode 速度和 TTFT。样本少于 10 次时，报告最小值、中位数和最大值。样本数太少，计算 P95 没有意义，强行给出 P95 会掩盖真实波动。
资源监控：与请求同步采样，每秒一次，并与请求时间戳对齐。

以 NVIDIA 显卡为例，可以用下面的命令记录温度、功耗、显存和 SM 时钟：

nvidia-smi --query-gpu=timestamp,temperature.gpu,power.draw,memory.used,clocks.sm --format=csv -l 1 > gpu_log.csv

如果使用 llama.cpp，可以用 llama-bench 的 -p、-n、-r 参数分别指定输入 token 数、输出 token 数和重复次数，并把模型路径与全部参数写入测试记录。

模型、量化、上下文、并发、运行时长五个维度全部做笛卡尔积，工作量过大。建议采用单因素变化的方法，每次只改变一个维度，其余维度保持固定。

长上下文测试需要注意两点。第一，输入长度要用分词器实际计数确认，不能只按字数估算。第二，速度只在输出正确时才有意义。每个目标深度都应抽查输出质量，例如在长文本中埋入一个已知事实，再让模型回答。能加载、能输出，不等于在该长度下速度与质量可接受。

长时稳定测试要求连续运行 60 分钟以上，每隔固定间隔（例如每分钟）发送同一请求，并记录 decode 速度、温度、SM 时钟、功耗和显存占用的时间序列。