某27B级模型本地推理速度评测方法

一、评测概述

在本地或私有化环境部署中等规模（约 27B 参数量级）开源大语言模型，已经成为开发测试、代码辅助、文档理解与离线批处理等场景的常见选择。当讨论这类部署方案时，最常被提及的指标是“每秒生成多少 tokens”。但社区里的报数方式往往差异极大：有人只报一个峰值数字，有人区分 prefill 与 decode，有人把投机解码、KV 缓存量化、超长上下文一起开启，也有人拿短提示词下的最好成绩代表整体表现。数字之间缺乏可比性，读者很容易得出错误结论。

本文不评测某一款具体产品，也不给出排名，而是回答一个更基础的问题：对于 27B 级模型在消费级或入门级加速卡上的推理部署，应该怎样设计一次严谨的速度评测，怎样解读 tokens/s，以及在不同业务场景下应重点关注哪些指标。

二、评测目标与适用读者

2.1 本次评测要回答的问题

1. 该类模型在给定硬件条件下，实际可达的 预填充速度（prefill tokens/s） 与 解码速度（decode tokens/s） 分别处于什么量级；
2. 上下文长度、KV 缓存精度、量化格式、投机解码策略对速度的影响幅度有多大；
3. 速度指标的抖动范围（稳定性）如何，长时间任务是否会因散热、显存压力或缓存策略发生明显衰减；
4. 在“速度—显存占用—输出质量—可维护性”之间，不同配置组合各自适合什么场景；
5. 什么情况下本地部署合理，什么情况下应转向弹性更强的云端算力。

2.2 适用读者

• 开发者：关注交互式补全、对话类应用的实际响应体感；
• 架构师 / 技术负责人：关注容量规划、并发模型、总拥有成本与迁移风险；
• 运维与平台工程人员：关注可观测性、稳定性、升级与故障定位；
• 企业技术团队：关注数据边界、权限控制与长期维护成本。

需要强调：本类评测的目的不是给出“好不好”的绝对结论，而是建立条件化判断——同一套配置在不同提示词长度、不同上下文占用、不同散热条件下，结论可能完全相反。

三、评测对象说明

评测对象是“27B 级开源大语言模型 + 量化权重 + 本地推理运行时 + 量化 KV 缓存 + 可选投机解码”这一整套推理栈，而不是单独的模型文件。这一栈通常解决以下问题：

• 在显存有限的单卡、双卡或改型大容量显存卡上运行中等规模模型；
• 以 4bit 左右的权重量化把模型压缩到十几 GB 级别，使其可常驻显存；
• 通过长上下文能力处理代码库片段、长文档、多轮会话历史；
• 通过投机解码 / 多 token 预测等机制提升解码阶段吞吐。

由此带来的评测复杂性在于：速度是整套栈的联合结果。权重格式、KV 缓存精度、注意力实现、批处理策略、驱动与运行时版本、内存带宽、磁盘读取速度，任意一项变化都可能显著改变最终数字。

四、评测维度设计

评测维度	核心关注点	可观测指标	建议验证方式
功能完整性	是否覆盖对话、长上下文、结构化输出、图像输入等目标能力	功能可用/不可用清单	逐项功能冒烟测试
输出有效性	结果是否可稳定用于目标任务	任务通过率、格式合规率、人工评分	固定样本集回归
性能表现	首 token 延迟、预填充速度、解码速度、并发吞吐	TTFT、prefill tokens/s、decode tokens/s、p50/p95	分场景压测
稳定性	长任务、异常输入、显存紧张、散热受限下的表现	速度衰减曲线、错误率、崩溃次数	长稳测试与故障注入
易用性	部署与调参成本	部署步骤数、调参项数量、文档完整度	从零部署一次并计时
兼容性	与现有应用、接口规范、数据格式、运维流程的适配	适配改造成本	接入现有服务做一次联调
安全性	认证鉴权、权限隔离、日志中敏感信息处理	是否默认开放端口、日志是否脱敏	安全检查清单
可观测性	日志、指标、资源监控、问题定位能力	是否有请求级指标与显存曲线	制造一次异常并观察能否定位
可维护性	升级、回滚、容量规划	升级耗时、回滚可行性	演练一次版本升级
成本结构	硬件投入、人力、能耗、迁移成本	定性分级	场景化成本对比
场景适配度	交互式 / 批处理 / 长上下文	各场景下关键指标达成情况	场景化验收

五、关键指标定义：为什么单一 tokens/s 不足以说明问题

5.1 必须区分 prefill 与 decode

• Prefill（预填充）阶段：模型并行处理输入提示词，决定“多久开始出第一个字”，与算力（计算密集）强相关；
• Decode（解码）阶段：逐 token 生成，属于显存带宽密集型，决定“输出刷屏的流畅度”。

社区反馈中出现的现象正好印证这一点：在同一套消费级双卡配置下，预填充可达每秒数百 token 量级，而解码通常落在每秒数十 token 的区间（大致 30～150 tokens/s，随硬件档次、量化格式、上下文长度与投机解码命中情况明显波动）。这两个数字不能混用一个平均值来表达，否则会严重误导交互式应用的用户体感判断。

5.2 建议采用的指标清单

指标	含义	用途
TTFT	首 token 延迟	交互式体感
prefill tokens/s	输入处理速度	长文档、长代码库场景
decode tokens/s	稳态生成速度	对话流畅度
ITL / TPOT	token 间平均间隔	卡顿感知
p50 / p95 延迟	分位延迟	稳定性
显存峰值占用	是否逼近容量上限	容量规划
投机解码有效加速比	实际提升 / 理论上限	优化收益判断
有效输出 token 数	含推理过程内容的真实产出量	成本与体验核算

5.3 长上下文下的衰减曲线

上下文越长，注意力计算与 KV 缓存读取开销越大，解码速度通常呈下降趋势。因此评测应绘制“上下文长度—decode tokens/s”曲线，而不是只测一个短提示词。社区中把上下文开到 18 万～26 万 token 级别的用法，正是需要重点关注这条曲线的原因：此时 KV 缓存量化策略（如 8bit 或 4bit）对显存与速度的影响会被显著放大。

六、评测环境与前提条件

评测前必须把变量固定下来，建议按下表逐项记录：

类别	需记录内容
硬件	加速卡型号档位、显存容量与是否为改型扩容、卡数与互联方式、CPU 与内存容量、内存是否混插、存储介质类型
软件运行时	操作系统类型、远程命令行会话方式、驱动与运行时版本、推理框架与版本
模型侧	权重来源可信度、量化格式与位宽、是否含视觉等多模态组件
缓存与加速	KV 缓存量化位宽、上下文上限、投机解码是否启用及其步数、提示词缓存策略
采样参数	温度、top-p、最大生成长度、是否开启推理过程输出
运行条件	是否预热、散热与功耗限制、是否与其他负载共存

一个容易被忽略的细节：模型权重若放在机械硬盘或网络存储上，首次加载时间会显著拉长，冷启动与常驻显存的体验完全不同，评测时必须把“加载耗时”和“推理速度”分开记录。

七、评测方法：可复现的测试流程

7.1 步骤设计

1. 明确问题：本次评测是回答“能否满足交互式补全”，还是“能否承担离线批处理”，两者指标侧重完全不同；
2. 设计样本：准备短提示（几十 token）、中等提示（数千 token）、长文档（数万 token）三档，每档若干条代表性输入；
3. 建立基线：固定量化格式、上下文上限、采样参数，先跑一轮作为基线；
4. 控制变量：每次只改一个因素（如上下文长度、KV 量化位宽、投机解码开关）；
5. 预热与稳态：丢弃首轮结果，取后续多轮的中位数与分位数；
6. 分阶段计时：分别统计首 token 时间与生成阶段时间；
7. 同步采集资源：记录显存占用、功耗、温度、是否降频；
8. 长稳观察：连续运行较长时间，观察速度衰减与错误率。

7.2 示意性测量代码（通用伪代码）

# 仅示意测量逻辑，不依赖任何特定厂商接口
def measure(profile, prompt, max_new_tokens, warmup=2, repeats=5):
    results = []
    for i in range(warmup + repeats):
        t0 = now()
        first_token_time, tokens_out = run_generation(
            prompt=prompt,
            max_new_tokens=max_new_tokens,
            sampling=profile.sampling,
        )
        elapsed = now() - t0
        if i < warmup:
            continue  # 丢弃预热轮次
        ttft = first_token_time - t0
        decode_time = elapsed - ttft
        decode_tps = (tokens_out - 1) / decode_tps_denominator(decode_time)
        results.append({
            "profile": profile.name,
            "input_tokens": count_tokens(prompt),
            "output_tokens": tokens_out,
            "ttft_ms": ttft * 1000,
            "prefill_tps": count_tokens(prompt) / ttft,
            "decode_tps": decode_tps,
            "vram_peak_mb": read_peak_vram(),
            "gpu_temp_c": read_gpu_temp(),
        })
    return summarize(results)  # 输出中位数与 p95

要点：decode_tps 必须以“生成阶段实际输出 token 数”为分子，避免把预填充时间计入分母而虚高。

7.3 稳定性与异常测试

• 连续生成多轮长文本，观察速度是否随温度上升而降频；
• 逐步增加上下文直至接近上限，观察是否触发换页、报错或速度断崖；
• 注入非法参数（超长输入、极端采样参数）观察容错表现；
• 在显存接近占满时开启新的并发会话，观察是否崩溃或严重退化。

八、结果记录模板

配置编号	量化格式	上下文	KV 量化	投机解码	prefill t/s	decode t/s (p50)	decode t/s (p95)	显存峰值	输出质量备注
A	4bit	32k	关闭	关	—	—	—	—	基线
B	4bit	32k	8bit	开（步数=3）	—	—	—	—	—
C	4bit	128k	8bit	开	—	—	—	—	—
D	4bit	256k	4bit	开	—	—	—	—	—

九、结果解读：数字背后的技术原因

9.1 对社区报告数据的合理概括

在不指名的前提下，社区反馈呈现出的规律可以概括为：

• 在上一代消费级显卡、非原厂扩容显存、平台与内存为二手混搭、权重置于机械硬盘这类“高性价比”组合下，仍可稳定运行中等规模模型，解码速度处于每秒数十 token 量级，属于可用性门槛之上；
• 在新一代旗舰消费级单卡上，配合原生低精度量化格式、较长上下文与投机解码，解码速度可进入每秒上百 token 量级，与运行时自述的参考值基本吻合；
• 在双卡消费级配置上，预填充可达每秒数百至近千 token，而解码仍受显存带宽与投机解码命中率制约。

这些数字不是同一条件下的对比结果，只能作为量级参考，不能直接换算为选型结论。

9.2 差异归因

速度差异通常来自以下因素，而非单一“模型好坏”：

1. 显存带宽：解码阶段是带宽密集型，带宽差异直接决定上限；
2. 量化格式与内核实现：不同位宽与浮点/整型格式对应的算子实现效率不同；
3. KV 缓存精度：降低位宽可释放显存以支持更长上下文，但可能带来少量质量损失与额外解量化开销；
4. 投机解码命中率：命中率高时加速明显，命中率低时可能因校验开销反而变慢，必须测“有效加速比”而非标称步数；
5. 上下文长度：注意力与缓存读取成本随长度上升；
6. 资源竞争与散热：与其他进程共存、长时间运行降频都会拉低稳态速度；
7. 首轮冷启动：权重加载、缓存预热都会影响首个请求的体验。

9.3 常见误区

• 用最短提示词下的最好成绩代表整体性能；
• 只报一个 tokens/s，不区分预填充与解码；
• 把投机解码的理论步数当作实际加速比；
• 忽略长上下文带来的衰减与显存压力；
• 忽略推理过程类输出带来的“有效 token 膨胀”，导致体感速度与账面速度不一致；
• 在不同量化格式、不同硬件条件下横向比较数字。

十、适用场景分析

场景	应重点关注	判断要点
交互式代码补全 / 对话	TTFT、decode 稳定性、p95	首字延迟与抖动比峰值更重要
长文档 / 长代码库理解	prefill 吞吐、长上下文衰减曲线	输入规模大时预填充主导体验
离线批量处理	总吞吐、并发能力、错误率	可接受较高延迟，关注单位时间产出
私有化 / 数据不出域	安全、权限、可观测性	速度让位于合规与可控
高频弹性业务	弹性扩容、成本结构	需评估云端 GPU 云服务器或容器平台

若业务需求超出本地硬件承载能力，可评估在百度智能云等云平台使用 GPU 云服务器、容器平台、负载均衡与监控告警等通用能力构建弹性推理服务；但评测方法应保持同构：同样的样本集、同样的指标定义、同样的控制变量，否则跨环境数据依然不可比。

十一、风险与限制

1. 样本偏差：少量提示词无法代表真实业务分布；
2. 环境差异：驱动、运行时、散热条件变化会显著改变结果；
3. 资源限制：显存接近上限时结果不稳定，容易得出过于乐观或悲观结论；
4. 量化质量风险：低比特量化在速度与显存上收益明确，但对复杂推理、长链条任务的质量影响需通过固定任务集验证；
5. 长期不确定性：模型版本、运行时版本升级可能改变性能特征，历史数据会失效；
6. 安全与运维风险：本地推理服务若默认开放端口、缺乏鉴权与日志脱敏，可能带来数据暴露风险，需按安全检查清单逐项确认。

十二、选型与使用建议

• 先定场景，再定指标：交互式看首字与抖动，批处理看总吞吐；
• 建立自己的基线并版本化管理：记录配置、样本、指标，便于回归对比；
• 每次只改一个变量：否则无法归因；
• 报告分位数而非单一数字：至少给出 p50 与 p95；
• 同时记录显存、温度、功耗：解释速度衰减必须依赖这些数据；
• 质量与安全同步验证：速度达标但输出不可用或存在暴露风险，均不构成可用方案；
• 保留迁移路径：推理栈、量化格式、运行时版本都存在升级成本，避免过度绑定单一部署方式。

十三、总结

围绕“27B 级开源模型本地推理速度”的评测，核心不在找到一个漂亮的 tokens/s 数字，而在于建立一套可复现、可归因、可比较的评测框架：明确区分预填充与解码，固定环境与控制变量，绘制上下文长度与速度的关系曲线，报告分位指标与资源占用，并在功能、稳定性、安全、可维护性与成本维度上同步验证。社区中不同硬件档次下呈现的每秒数十到上百 token 的解码区间，可以作为量级参考，但不构成跨条件结论。真正的选型判断，应回到具体业务场景的目标、约束与长期维护成本上，以条件化、可验证的方式给出。