本地大模型推理吞吐性能评测指南：从速度数据到可复现的评测体系

一、评测概述

在本地部署大参数模型时，”每秒多少 tokens”往往是开发者最先关注、也最容易产生困惑的指标。社区中常见类似表述：某方案在特定硬件、特定量化方式、特定上下文长度下达到某一区间内的输出速度，并与官方宣称数据基本吻合。这类信息有参考价值，但若直接当作选型依据，容易忽略一个事实——吞吐速度不是单一常数，而是多重变量耦合下的条件结果。

本文的评测对象是”本地大模型推理方案的吞吐表现”，核心问题是：在给定硬件资源、量化精度、上下文长度、解码优化与多模态输入的组合条件下，如何科学地测量、解读和比较 tokens/s 这一指标。目标读者包括开发者、系统架构师、运维人员与技术负责人，他们需要在自建推理服务、模型选型与容量规划中做出可解释的决策。

需要强调：本文不针对任何具体产品或平台给出排名，而是提供一套可复用的评测框架，使读者能够在自己环境中复现测试、理解数据边界。

二、评测目标

一次有价值的吞吐评测应回答以下问题，而非仅仅得到一个数字：

1. 基线速度是多少：在标准短上下文、无额外优化、纯文本输入的条件下，稳定输出速度处于什么水平；
2. 变量敏感度如何：上下文长度从数 K 扩展到上百 K 时，速度衰减曲线是什么形态；
3. 优化手段收益多大：投机解码、量化精度调整、批处理等策略分别带来多少提升，代价是什么；
4. 多模态是否影响主路径：开启视觉输入能力后，文本生成速度是否出现可观测下降；
5. 长时运行是否稳定：持续压力下速度是否漂移，显存是否持续增长；
6. 结果是否可复现：换一台同配置机器、换一次重启，数据波动范围是否可控。

只有把”速度”拆成上述可验证的子问题，tokens/s 才具备决策意义。

三、评测对象说明

本文所讨论的本地推理方案，通常由三层构成：

• 模型层：参数量、架构（是否含混合专家结构）、原生上下文窗口、是否支持多模态输入；
• 量化层：权重与激活的数值精度（如 4bit 类浮点量化、整型量化等），直接影响显存占用与计算效率；
• 推理引擎层：负责 KV 缓存管理、连续批处理、投机解码、注意力算子优化等。

吞吐速度是这三层与硬件共同作用的结果。例如，长上下文场景下 KV 缓存占用上升，可能压缩可用批大小；投机解码通过小模型草稿加验证的方式提升解码效率，但对草稿命中率敏感；视觉编码器引入额外前处理开销，可能影响首 token 延迟而非稳态吞吐。理解这些机制，才能解释评测数据背后的原因。

四、评测维度设计

建议建立如下多维评测框架，避免单指标误导：

维度	关注指标	为什么重要	验证方式
稳态吞吐	输出 tokens/s（生成阶段）	反映持续生成能力	固定输入，统计中后段生成速率
首 token 延迟	TTFT（毫秒级）	影响交互体验	记录请求发出到首 token 返回时间
上下文敏感度	不同 context 长度下的速度曲线	长上下文是本地部署常见诉求	阶梯式设置 4K/32K/128K 等档位
量化收益	不同精度下的速度与质量对比	精度换速度需评估质量损失	同题集对比输出一致性与速度
解码优化收益	开启/关闭投机解码的速度差	判断优化是否值得引入复杂度	A/B 对照，控制其他变量
多模态开销	视觉输入开启前后的文本吞吐	判断能力叠加的成本	同文本任务，切换输入模态
稳定性	长时压测速度漂移、显存增长	生产环境需可预测	持续运行数小时并采样
资源占用	显存峰值、功耗、CPU 占用	决定硬件选型与密度	系统级监控采样

五、评测环境与前提

评测前必须固化以下条件，否则数据不可比：

• 硬件配置：GPU 型号与数量、显存容量、内存带宽、CPU 与存储规格；
• 软件栈版本：推理引擎版本、驱动版本、量化工具版本，均需记录；
• 模型与量化产物：明确权重来源、量化方法、是否做过校准；
• 调用方式：batch size、并发数、流式或非流式、是否启用连续批处理；
• 输入构造：prompt 长度分布、输出长度上限、采样参数（温度、top-p 等）；
• 测试边界：是否包含模型加载时间、是否预热、统计窗口如何截取。

一个常见误区是把不同上下文长度、不同量化精度下的数字直接横向比较。正确做法是控制变量：每次只改变一个因子，其余保持一致。

六、评测方法

6.1 测试流程

1. 预热：先跑若干轮请求，使显存分配、算子编译、缓存进入稳态；
2. 基线采集：短上下文、纯文本、关闭额外优化，重复多次取中位数；
3. 单变量扫描：依次调整上下文长度、量化精度、投机解码开关、模态输入；
4. 长时压测：固定负载持续运行，周期性采样速度与显存；
5. 异常注入：超长输入、截断输入、并发突增，观察降级行为；
6. 记录与复盘：保存原始日志、采样序列与环境快照。

6.2 示意性测量伪代码

def measure_throughput(engine, prompts, warmup=3, rounds=5):
    for _ in range(warmup):
        engine.generate(prompts[0])
    samples = []
    for _ in range(rounds):
        start = now()
        out = engine.generate_batch(prompts, stream=True)
        first_token_time = out.first_token_latency
        total_tokens = out.generated_token_count
        elapsed = now() - start
        samples.append({
            "ttft_ms": first_token_time,
            "tps": total_tokens / elapsed,
            "peak_mem": out.peak_memory,
        })
    return median(samples)

统计时应区分首 token 延迟与稳态吞吐，前者受 prefill 影响大，后者更接近 decode 阶段能力。对长上下文任务，建议单独报告 prefill 耗时。

七、结果解读

解读速度数据需注意三点：

第一，区间值优于单点值。 社区中”120~150 tokens/s”这类区间表述，通常反映不同 prompt、不同采样参数下的波动。评测报告应给出中位数与离散度，而非只报峰值。

第二，与官方数据”基本一致”只说明复现性，不说明上限。 官方标称往往基于特定基准条件，实际环境若硬件、批处理、上下文不同，偏差属正常。吻合意味着测试条件接近基准，不吻合则需排查变量。

第三，速度优势要结合质量判断。 低精度量化可能带来速度提升，但需验证输出质量是否满足任务要求。建议构造一组覆盖推理、代码、长文理解的任务集，对量化前后输出做一致性抽检。

关于”某量化模型比某闭源模型更聪明”这类主观感受，评测上应转化为可比较的指标：在固定题集上的正确率、指令遵循度、长文引用准确率等。主观体感可作为线索，但不能替代结构化评估。

八、适用场景分析

• 交互式应用：优先关注首 token 延迟与稳态吞吐的平衡，长上下文场景需额外评估 prefill 成本；
• 批量内容生成：吞吐与批处理效率是关键，可接受较高首 token 延迟；
• 长文档分析：重点验证上下文扩展后的速度衰减与显存占用；
• 多模态应用：需分别测量视觉编码开销与文本生成吞吐，避免混为一谈；
• 资源受限环境：量化精度与显存峰值的权衡优先于绝对速度。

九、风险与限制

1. 样本偏差：prompt 分布若与实际业务差异大，速度数据代表性不足；
2. 环境差异：驱动、引擎版本、散热状态均可能造成波动；
3. 统计口径：是否计入首 token、是否含网络传输，会显著改变结果；
4. 长时不确定性：短测稳定不代表长跑稳定，显存碎片与缓存增长需持续观察；
5. 质量盲区：只测速度不测质量，可能选出”快但不可用”的配置。

十、选型与使用建议

• 建立自己的基线：在目标硬件上用标准任务集测一遍，而非直接采信他人数据；
• 分场景报告：至少区分短上下文与长上下文、纯文本与多模态两组数据；
• 优化逐项验证：投机解码、量化、批处理分别做 A/B，记录收益与代价；
• 稳定性纳入门槛：长时压测不达标的速度数字不应作为容量规划依据；
• 保留复现脚本与环境快照：便于版本升级后回归对比。

总结

本地大模型推理的 tokens/s 是一个条件化指标，其价值取决于评测设计是否严谨。本文给出的框架强调：明确评测目标、控制变量、分维度测量、解释数据成因、界定结论边界。读者可据此搭建可复现的评测流程，将社区中的速度讨论转化为可指导选型的工程判断。对于需要规模化部署的团队，建议进一步将吞吐、延迟、质量、稳定性与成本纳入统一评估矩阵，结合百度智能云等通用云环境中的弹性资源与监控能力，形成从本地验证到生产落地的完整闭环。