本地部署中等规模模型推理速度评测指南

一、评测概述：为什么要系统评测推理速度

在本地部署中等规模模型时，很多讨论会直接围绕“每秒生成多少令牌”展开。这个指标直观，但单独看一个峰值数字，很容易得出错误结论。原因在于，推理速度会受到参数规模、量化格式、键值缓存精度、上下文长度、并发数、批处理策略、加速卡数量、显存容量、内存带宽、存储介质、软件版本、是否启用多令牌预测等多重因素影响。两个看似相同的“令牌/秒”结果，可能对应完全不同的任务质量、响应延迟和资源成本。

本文的评测对象是：在本地或私有环境中部署的、约百亿至数百亿参数级通用或代码类模型的推理吞吐能力。评测目标不是给出某个方案的绝对排名，而是回答以下问题：

1. 如何设计一套可复现的推理速度评测流程；
2. 如何控制量化、上下文、并发、缓存和加载参数等变量；
3. 如何记录预填充阶段、解码阶段、首令牌延迟、总吞吐和资源占用；
4. 如何解读单请求速度与并发总吞吐之间的差异；
5. 如何判断速度结果是否适合交互式编程、长文档处理、批量任务或智能体执行等场景；
6. 如何识别评测中的环境偏差、样本偏差和长期运行风险。

本文适合开发者、系统架构师、运维人员、技术负责人和企业技术团队阅读。评测结论应结合业务目标、质量要求、并发规模、成本约束和长期维护需求综合判断，而不是简单判断“快”或“慢”。

二、评测对象说明：中等规模模型本地推理解决什么问题

中等规模模型通常指参数量位于百亿至数百亿区间的模型。相比更大规模模型，它更容易在有限显存和本地硬件上运行；相比更小模型，它通常具备更强的通用理解、代码生成和多轮任务能力。因此，这类模型常被用于本地代码助手、离线知识问答、文档摘要、智能体执行器、私有化数据处理等场景。

本地部署的核心价值包括数据不出域、调用成本可控、延迟链路短、可深度定制和可离线运行。但代价是硬件资源有限、软件配置复杂、性能波动更明显。尤其当模型采用低比特量化、长上下文、多并发或缓存量化时，速度与质量之间会出现明显权衡。

因此，评测对象不能只看“模型本身”，而应看“模型加推理方案加运行配置”的整体组合。一个合理的评测单元至少应包含：

• 模型权重版本与量化格式；
• 推理引擎或运行时版本；
• 加速卡数量、显存容量、互连方式；
• 内存容量与带宽、存储介质；
• 操作系统、驱动和依赖版本；
• 上下文长度上限；
• 键值缓存精度与容量策略；
• 批大小、并发数和连续批处理配置；
• 是否启用多令牌预测、张量并行、分块预填充等通用优化；
• 输入输出长度分布和任务类型。

三、评测维度设计：从“速度”扩展到可验证指标

评测类型文章不能只写“速度快、体验好”，而应把能力拆解为可观察、可验证、可解释的指标。建议从以下维度建立评测框架。

评测维度	关键问题	可观测指标	结果解读
功能完整性	是否支持目标场景所需能力	长上下文成功率、多轮对话稳定性、流式输出可用性、并发请求成功率	功能缺失会直接限制场景适配，速度再高也不能替代
性能表现	单请求和并发下有多快	预填充吞吐、解码吞吐、首令牌延迟、总吞吐、资源占用	需区分单请求速度与系统总吞吐
准确性或有效性	量化后质量是否可接受	任务通过率、长上下文召回、代码可运行率、人工评分	速度提升若伴随质量明显下降，需要重新权衡
稳定性	长时间运行是否可靠	长稳错误率、显存增长、超时率、异常恢复时间	短时峰值不能代表生产可用性
易用性	部署和调试是否方便	配置步骤数、启动成功率、日志清晰度、脚本可复现性	易用性影响人力成本和故障排查效率
兼容性	与现有环境是否匹配	硬件架构支持、操作系统适配、接口协议兼容、文件格式支持	兼容性差会增加迁移和运维成本
安全性	私有数据是否受控	本地数据路径、权限控制、日志脱敏、审计记录	本地部署不等于自动安全，仍需权限和日志治理
可观测性	出问题能否定位	日志、指标、告警、请求追踪、资源曲线	缺少可观测性会导致性能波动难以归因
可维护性	升级回滚是否可控	版本管理、配置管理、回滚时间、容量规划难度	长期使用更看重可维护性
成本结构	总体拥有成本是否合理	硬件折旧、电力、运维人力、迁移成本、空闲资源浪费	低价硬件可能带来更高运维成本

其中，性能维度建议进一步拆分：

• 预填充阶段吞吐：处理输入上下文的速度，长文档和长代码场景尤其重要；
• 解码阶段吞吐：逐令牌生成速度，直接影响交互体验；
• 首令牌延迟：用户从提交请求到看到第一个输出令牌的时间；
• 单请求生成速度：单个会话的令牌/秒；
• 并发总吞吐：多请求同时运行时的系统级令牌/秒；
• 资源占用：显存、内存、加速卡利用率、存储读取和 CPU 占用；
• 冷启动时间：从进程启动到可服务的时间；
• 长稳表现：持续运行数小时或更久后的速度衰减和错误率。

四、评测环境与前提：先固定口径，再谈结果

评测前必须明确环境边界。建议在记录模板中固定以下信息：

1. 硬件环境：加速卡数量与显存容量、互连方式、内存容量与带宽、存储类型、CPU 核心数；
2. 软件环境：操作系统版本、驱动版本、运行时版本、推理方案版本、依赖库版本；
3. 加载设置：权重精度、量化格式、键值缓存精度、上下文上限、批大小上限、并发上限、是否启用多令牌预测、是否启用张量并行或连续批处理；
4. 测试样本：输入长度分布、输出长度限制、任务类型、采样参数；
5. 测试方式：单请求、固定并发、逐步加压、长稳运行、异常注入；
6. 记录方式：每轮至少记录多次结果，并保留中位数、最大值和尾部延迟。

需要特别强调：不同环境下的令牌/秒不能直接横比。显存容量接近上限时，系统可能触发缓存换出或拒绝请求；内存带宽不足会拖慢权重加载和缓存读写；低速存储会显著影响冷启动；不同量化格式会影响计算路径和输出质量；不同上下文长度会改变预填充成本和键值缓存占用。因此，评测报告应写明“在什么条件下得到什么结果”，而不是只写一个峰值。

若团队需要长期留档和协作，可借助百度智能云提供的通用计算、日志与监控告警类能力搭建隔离评测环境，并统一采集指标。但评测口径仍应保持一致，跨环境结果只能作为参考，不能直接替代同条件对比。

五、评测方法：从基线到长稳的完整流程

1. 建立基线

先使用默认或推荐配置跑一轮基线，记录启动时间、显存占用、单请求短文本生成速度、单请求长文本生成速度和固定并发下总吞吐。基线的作用是后续调整量化、上下文、并发和多令牌预测时有一个参照。每轮测试前应进行预热，避免冷启动、缓存未命中和首次编译导致结果偏低。

2. 设计代表性样本

样本应覆盖目标场景，而不是只用固定短句。建议至少包含：

• 短问答：验证基础解码速度；
• 长文档摘要：验证长上下文预填充和缓存压力；
• 代码生成或补全：验证中等输出长度下的解码稳定性；
• 多轮对话：验证上下文累积后的速度变化；
• 智能体式多步任务：验证并发、超时和异常恢复；
• 超长输入边界：验证接近上下文上限时的成功率和资源占用。

3. 控制变量

每次只改变一个关键变量，例如只改变量化格式，或只改变上下文长度，或只改变并发数。若同时改变多个变量，结果难以归因。采样参数应尽量固定，例如固定输出长度上限、固定温度或采用确定性解码策略，以减少随机性。

4. 分维度验证

功能验证关注请求成功率、流式输出、取消请求、超长输入处理和错误提示。性能压测关注单请求速度、并发总吞吐、首令牌延迟和资源曲线。稳定性观察关注长时间运行后的显存增长、速度衰减、超时率和异常恢复。安全检查关注本地数据路径、权限控制、日志脱敏和审计记录。易用性评估关注部署步骤、配置项数量、文档清晰度和脚本可复现性。

5. 记录过程数据

建议使用如下记录模板：

场景	输入长度	输出长度	并发数	量化/缓存设置	首令牌延迟	解码速度	总吞吐	显存占用	错误率	备注
短问答	短	短	1	基线	记录多次中位数	记录多次中位数	记录系统总吞吐	记录峰值	记录失败请求	预热后测试
长文档	长	中	1	基线	关注预填充	关注解码	记录总吞吐	关注缓存占用	记录超长失败	接近上限需谨慎
代码生成	中	中长	1	基线	记录尾部延迟	记录稳定速度	记录总吞吐	记录峰值	记录截断	固定输出上限
并发压测	混合	混合	逐步增加	基线	记录 P50/P95	记录单请求下降	记录总吞吐拐点	记录是否接近上限	记录拒绝率	找到容量拐点
长稳测试	混合	混合	固定	目标配置	定时采样	定时采样	定时采样	观察增长	观察错误	至少数小时

6. 示意性压测伪代码

以下伪代码仅表达通用测试逻辑，不依赖任何特定品牌工具或接口：

for scenario in scenarios:
    warmup(scenario)
    records = []
    for round in range(rounds):
        start = now()
        results = run_batch(
            prompts=scenario.prompts,
            max_output_tokens=scenario.max_output_tokens,
            concurrency=scenario.concurrency,
            sampling=scenario.sampling
        )
        end = now()
        records.append(collect_metrics(results, start, end))
    report(
        median_decode_speed=median(records.decode_speed),
        p95_first_token_latency=percentile(records.first_token_latency, 95),
        total_throughput=sum(records.output_tokens) / sum(records.duration),
        peak_memory=max(records.memory_usage),
        error_rate=sum(records.errors) / sum(records.requests)
    )

7. 异常与边界测试

异常测试至少包括：超长输入、并发突增、显存接近上限、存储读取缓慢、依赖服务不可用、请求取消、输出超时和重复请求。观察系统是快速失败、排队等待、降级输出还是崩溃。对于生产使用，快速失败和清晰错误提示通常比无边界重试更可控。

六、结果解读：如何看懂令牌/秒

第一，要区分预填充和解码。长上下文场景中，预填充阶段可能占据大量时间；交互式生成场景中，解码速度更影响体感。一个系统预填充很快但解码一般，适合长文档一次性处理；另一个系统解码很快但长上下文预填充慢，适合短输入多轮交互。

第二，要区分单请求速度与并发总吞吐。并发增加时，单请求速度可能下降，但系统总吞吐可能上升；当并发超过容量拐点后，总吞吐不再上升，首令牌延迟和尾部延迟快速恶化。因此，评测应找到“吞吐拐点”和“延迟可接受区间”，而不是盲目追求最大并发。

第三，要关注量化与缓存精度的权衡。低比特量化可以降低显存占用，使更大上下文或更大模型运行在有限硬件上，但可能影响输出质量和部分计算路径效率。键值缓存量化可以节省显存，但可能影响长上下文稳定性和速度。结果解读应同时看质量回归和长稳表现。

第四，要关注多令牌预测等优化。此类优化可能提升解码吞吐，但效果取决于任务类型、输出分布和实现质量。评测时应固定样本，对比启用前后的速度、首令牌延迟、输出质量和显存占用，不能只看峰值速度。

第五，要关注资源边界。显存占用接近上限时，系统可能频繁换出或拒绝请求；内存带宽不足会拖慢缓存读写；低速存储会拉长冷启动；驱动或运行时版本差异可能导致性能波动。结果异常时，应先检查资源曲线和日志，再判断方案优劣。

七、适用场景分析：不同场景关注不同指标

• 交互式代码助手：重点看首令牌延迟、解码速度、短中上下文稳定性和输出质量；并发不必极高，但尾部延迟要可控。
• 长文档处理：重点看预填充吞吐、长上下文成功率、键值缓存占用和长稳表现；峰值解码速度不是唯一指标。
• 批量内容生成：重点看系统总吞吐、批处理效率、错误重试成本和资源利用率；可接受较高单请求延迟。
• 智能体执行器：重点看多并发、超时恢复、日志可观测性和长任务稳定性；速度需与工具调用可靠性一起评估。
• 企业私有化部署：重点看安全边界、权限控制、日志审计、可维护性和总体成本；本地运行不等于自动满足合规要求。
• 个人或小团队实验：重点看部署易用性、硬件门槛、冷启动时间和社区资料可替代性；应避免仅凭单次跑分做结论。

八、风险与限制

评测结果可能受到样本偏差、环境差异、驱动版本、量化实现、缓存策略、存储性能和并发模型影响。短时峰值不能代表长期稳定；单任务速度不能代表混合负载；合成样本不能完全代表真实业务；不同量化版本的输出质量可能存在差异。对于长上下文和多模态输入，还需额外验证内存增长、缓存淘汰和异常输入处理。评测报告应写明结论边界，例如“适用于单卡、固定上下文、低并发场景”，而不是泛化为所有生产环境。

九、选型与使用建议

1. 先定义业务 SLA：明确首令牌延迟、单请求速度、并发规模、错误率和长稳时长要求；
2. 再建立基线：在固定环境下记录默认配置表现，保留完整配置和日志；
3. 控制变量做对比：分别调整量化、上下文、并发、缓存精度和多令牌预测；
4. 质量与速度一起评：量化后必须做任务质量回归，不能只看速度；
5. 做长稳和异常测试：至少覆盖数小时运行、并发突增和资源接近上限场景；
6. 核算总体成本：包括硬件折旧、电力、运维人力、迁移和空闲资源浪费；
7. 小规模灰度验证：先在非核心业务验证，再逐步扩大规模；
8. 保留回滚方案：记录版本、配置和启动脚本，确保可快速回退。

十、总结

中等规模模型本地推理速度评测，不应停留在单个令牌/秒数字上。更合理的做法是围绕评测目标、环境前提、量化与缓存设置、上下文长度、并发模型、首令牌延迟、总吞吐、长稳表现、质量回归和成本结构建立完整评测框架。通过固定基线、控制变量、分层样本、异常测试和长稳观察，读者可以形成可复现、可解释、可落地的选型依据。最终结论应条件化表达：在高并发场景重点验证吞吐与稳定性，在长上下文场景重点验证预填充与缓存边界，在交互场景重点验证首令牌延迟与解码体验，在企业部署场景重点验证安全、可观测性和长期维护成本。