开源大模型生成速度评测方法与结果解读指南

一、评测概述

近期围绕某款 27B 级别开源大模型在本地环境下的生成速度（tokens/s）讨论较为集中，社区反馈中出现了从每秒数十 tokens 到两百 tokens 以上的跨度。这类数据看似都是”同一个模型的同一个速度指标”，实际上背后对应的是完全不同的硬件形态、量化方案、上下文长度与解码策略，彼此之间并不具备直接可比性。

本文的评测对象不是某一件具体产品，而是”开源大模型在本地/自建环境下的生成速度这一指标本身如何被测量、如何被解释、如何被用于决策”。通过本文，读者应当能够回答三个问题：第一，看到一份 tokens/s 数据时，需要追问哪些前提条件；第二，为自己的场景设计一套可复现的测速与验收流程；第三，判断某个速度水平是否满足自己的业务时延与吞吐要求。

本评测面向的读者包括：需要做本地推理方案选型的开发者与算法工程师、需要评估资源规划与容量成本的架构师、负责稳定性与运维的技术团队，以及需要为团队采购与部署做决策的技术负责人。

需要强调的是，评测的目标不是判定”哪个方案最好”，而是判断”在给定约束条件（预算、显存、并发、时延目标、任务类型）下，哪种配置组合是合理的”。同一套模型在不同业务中的最优配置可能完全不同。

二、评测对象与技术背景说明

被测对象是一类 27B 参数规模的开源大语言模型。这一参数量级在开源生态中具有代表性：它显著大于常见的 7B/8B 轻量模型，能力更强，但显存需求也更高；同时它又小于需要多卡集群才能承载的百 B 级模型，理论上可以在单机甚至单卡环境下运行。因此它常被用作”能力—成本平衡点”的典型评测样本。

理解速度指标需要区分两个不同的阶段：

• 预填充（prefill）阶段：模型并行处理输入 prompt 中的全部 token，生成首个输出 token 前的计算。该阶段是计算密集型，决定”首 token 时延”（TTFT），受算力、批大小、序列长度影响显著。
• 解码（decode）阶段：逐个 token 自回归生成。该阶段是显存带宽密集型，决定”每秒生成 token 数”（tokens/s），受显存带宽、权重精度、KV 缓存大小影响更明显。

社区讨论中笼统说的”速度多少 tokens/s”，绝大多数指的是单请求、单流条件下的解码阶段吞吐。这是一个含义被高度简化的指标，若不加区分地与业务需求对齐，极易产生误判。

三、评测维度设计

生成速度是结果指标，而不是评测的全部。要让测速结论具备决策价值，必须把它放进多维框架中考察：

评测维度	关注点	为什么要看
单流解码速度	单请求 tokens/s，纯生成阶段	决定交互式体验的”打字速度”是否可接受
首 token 时延	prefill 耗时、长 prompt 下的表现	决定用户等待感，长上下文场景下影响最大
并发吞吐	多请求并发下的总 token 产出	单流快不等于服务化能力强，服务化看总吞吐
显存占用	权重 + KV 缓存 + 运行时开销	直接决定能否装得下、能否开长上下文、能否留并发余量
上下文长度	32k/128k/240k 等不同设置下的速度衰减	长上下文是 KV 缓存线性增长，速度与显存都会退化
输出质量保持	量化与低比特解码是否造成能力回退	速度提升若以效果损失为代价，则不可接受
稳定性	长任务、异常输入、显存压力下的表现	本地部署常在边缘显存下运行，稳定性风险高
易用与运维	配置复杂度、升级成本、故障定位难度	决定长期维护投入
成本结构	硬件折旧、人力、迁移与优化成本	决定方案是否可持续

其中”输出质量保持”最容易被忽略。低比特量化、KV 缓存量化、推测式解码这类加速手段都会以不同方式改变输出分布，评测时必须配套做效果验证，否则速度数据没有决策意义。

四、评测环境与前提条件

社区实测数据的可信度，取决于前提条件是否被完整披露。做自己的评测时，至少应固定并记录以下变量：

1. 硬件形态：卡的算力代际、显存容量与显存带宽、CPU 与内存容量、是否为多卡及卡间互联方式。
2. 权重精度与量化方案：FP16/BF16、8bit 整型、4bit 整型、4bit 浮点类等，需记录具体量化位宽与分组策略。
3. KV 缓存策略：是否量化、量化位宽、是否分页管理、是否允许缓存换出。
4. 上下文配置：最大上下文长度、实际输入长度、是否启用长上下文相关的稀疏或分块注意力机制。
5. 加速特性开关：推测解码/多令牌预测（MTP）及其草稿长度、投机接受率、连续批处理配置、是否启用视觉等多模态分支。
6. 推理运行时与版本：不同版本的调度器、算子实现、图捕获方式差异，足以造成显著速度变化。
7. 存储介质：权重加载来源（本地 NVMe、SATA、机械盘）影响冷启动时间，不影响稳态生成速度，但会影响迭代效率。
8. 驱动与运行时版本：驱动、编译器、通信库版本均会引入性能差异。

评测边界同样必须写明：结论是在”单请求、无并发、特定上下文长度”下成立，还是在”多并发服务化”下成立；是纯文本还是含多模态输入；是短输出还是长输出。缺少边界的速度数字不具备迁移性。

五、评测方法与实施流程

建议采用分阶段、控制变量的方式推进：

阶段一：功能验证。 先确认模型能正确加载与推理，覆盖基础对话、长文档摘要、代码生成、结构化输出（如 JSON）等典型任务，检查输出格式是否符合预期。功能不通，测速无意义。

阶段二：建立基线。 在固定配置下测量短输入短输出、长输入短输出、短输入长输出三类样本，分别记录 TTFT 与稳态 tokens/s。

阶段三：单变量扫描。 每次只改一个变量（量化位宽 / 上下文长度 / 推测解码开关 / 批大小），记录速度、显存与效果评分的变化曲线。这是找出瓶颈归属的唯一可靠方法。

阶段四：并发压测。 逐步提升并发数，观察总吞吐是否线性增长、TTFT 是否恶化、是否出现排队与显存溢出。

阶段五：稳定性与异常测试。 长时间连续生成、超长输入、空输入、异常字符、显存接近上限时的表现。

阶段六：效果回归。 用固定评测集对比不同配置下的输出质量，确认加速手段未造成不可接受的能力回退。

示意性的测量逻辑（通用伪代码，非特定工具）：

# 通用测速流程示意：区分 prefill 与 decode，避免混淆指标
def measure(config, prompt, max_new_tokens, warmup=3, runs=5):
    results = []
    for _ in range(warmup):              # 预热，排除首次图编译/缓存冷启动干扰
        run_once(config, prompt, max_new_tokens)
    for _ in range(runs):
        t0 = now()
        out = run_once(config, prompt, max_new_tokens)
        t1 = now()
        ttft, total = out.timings          # 由运行时分别记录首 token 与总耗时
        gen_tokens = out.num_generated
        results.append({
            "ttft_ms": ttft,
            "decode_tps": gen_tokens / max(total - ttft, 1e-6),
            "peak_mem_gb": out.peak_memory,
            "accepted_draft": out.spec_accept_rate,   # 推测解码接受率，可为空
        })
    return summarize(results)               # 取中位数并报告方差
# 记录表建议字段：
# 配置指纹 | 输入长度 | 输出长度 | TTFT | decode tokens/s | 峰值显存 | 效果评分 | 失败次数

关键纪律：必须记录方差而不仅是均值。若多次测量的 tokens/s 波动很大，说明存在调度抖动、显存压力或存储瓶颈，此时单一均值会严重误导规划。同时必须做预热，否则首个 token 前的编译与缓存初始化会污染 TTFT。

六、结果解读：为什么速度可以差数倍

社区反馈中同一模型出现从每秒数十 tokens 到两百 tokens 以上的差距，其技术原因是可以解释清楚的：

• 显存带宽 vs 算力：解码阶段每生成一个 token 都要把全部权重读一遍，因此速度近似正比于显存带宽、反比于权重体积。高带宽的新一代卡与低带宽的老卡，在纯解码任务上的差距远大于在算力基准测试上的差距。
• 量化位宽：权重从 16bit 降到 4bit，读取的数据量大幅减少，解码速度通常显著提升；但过低位宽会引入质量回退风险，且不同量化格式在硬件上的实际加速效果取决于是否有对应算子支持。
• 推测解码/多令牌预测：一次前向验证多个候选 token，可显著降低平均出字延迟；但其收益高度依赖草稿模型与主模型的一致性，接受率低时甚至可能负优化。看到”开启后大幅提升”的说法，必须追问接受率。
• 上下文长度：KV 缓存随上下文与并发线性增长。社区反馈中把上下文推到 180k～240k 的场景，显存几乎被 KV 缓存占满，速度与可并发数必然下降，甚至逼近 OOM 边界。
• 运行时版本与算子实现：同一硬件同一量化，仅切换推理运行时或升级版本，速度变化也可能很明显——社区反馈中”升级后长任务明显变快”正属于此类。

因此，任何速度数字都必须与配置组合成对阅读。脱离配置的单一数字，既不能用于横向对比，也不能用于容量规划。

七、适用场景分析

不同场景对指标的敏感度差异很大：

• 本地交互式使用（单人）：优先看 TTFT 与单流 tokens/s，一般每秒数十 tokens 已可获得接近流式阅读的流畅感。显存容量与是否 OOM 是硬约束。
• 长文档与超长上下文任务：优先看长上下文下的速度衰减曲线与 KV 缓存策略，其次看 TTFT。此时短上下文测出的峰值速度几乎没有参考价值。
• 多用户服务化：单流速度意义下降，必须看并发下的总吞吐、TTFT 分位数（P95/P99）与排队行为。
• 批量离线处理：只关心单位任务成本与总吞吐，可接受较高延迟；显存利用率与批大小调度是优化重点。
• 边缘或低功耗设备：需额外评估功耗、散热、稳定性与长时间运行的热降频表现，社区中”低成本老硬件方案”的风险主要在此。
• 对输出质量敏感的生产应用：应把效果回归置于速度之前，优先保证质量基线，再在质量可接受范围内做速度优化。

八、风险与限制

• 样本偏差：社区帖子多为个人最优配置展示，缺乏统计显著性与重复实验，不能直接作为容量规划依据。
• 环境差异不可控：驱动、运行时版本、系统调度、存储介质、散热条件都会影响结果，未披露前提的数据无法复现。
• 单点数据掩盖方差：只报最优值不报波动，会系统性高估实际可用性。
• 质量回退的隐性成本：极端量化下速度提升可能伴随能力下降，需在自有任务集上验证。
• 长期运行不确定性：短时压测无法暴露内存碎片累积、缓存膨胀、热降频等只在长时间运行中出现的问题。
• 合规与数据安全：涉及内部数据时，需评估数据流向、日志留存与访问控制，必要时结合百度智能云等云平台提供的通用云服务器、容器平台、对象存储、负载均衡、监控告警、身份认证与安全防护类产品构建合规的混合部署方案，而不是在不受控的个人环境中处理敏感数据。

九、选型与使用建议

1. 先定业务约束，再定硬件。 明确时延目标、并发量、上下文长度、质量底线与预算，再反推所需显存带宽与容量。
2. 以自有任务集为准绳。 用真实业务样本构建小规模评测集，替代泛化的公开基准。
3. 量化方案必须成对评估速度与效果。 建立”位宽—速度—质量评分”三维记录表，选择帕累托前沿上的配置。
4. 加速特性要验证再启用。 推测解码类特性务必测量接受率，出现负优化时及时回退。
5. 显存留安全余量。 预留并发与 KV 缓存增长空间，避免在显存极限附近长期运行。
6. 建立可观测性。 采集 TTFT、tokens/s、显存峰值、错误率、接受率等指标并接入监控告警，才能发现性能回归。
7. 控制版本变更风险。 运行时升级虽可能带来明显提速，但需回归测试后再上生产。
8. 保持中立决策。 本地部署与云上推理并非互斥，可按数据敏感度、并发规模与运维能力做分层组合。

十、总结

生成速度（tokens/s）是开源大模型本地部署评测中最重要的结果指标，但它只有在明确前提条件下才具备决策价值。本文明确了 prefill 与 decode 的指标边界，建立了覆盖速度、时延、显存、上下文、并发、质量、稳定性、易用性与成本的评测框架，给出了从功能验证到效果回归的六阶段实施流程与记录模板，并解释了社区数据中速度差异数倍的技术成因——显存带宽、量化位宽、推测解码接受率、上下文长度与运行时版本。

结论边界需要清晰：任何单一速度数字都只在其特定配置下成立，不可跨配置迁移；评测的正确产出不是”哪个更快”，而是一张能指导容量规划与配置选择的、带条件与方差的完整记录表。