本地大模型推理吞吐评测：量化与显存权衡

一、评测概述：为什么要评测“生成吞吐”

在本地部署中等规模（约200亿至300亿参数）大语言模型时，用户最先感知、也最容易被误读的指标就是生成速度，通常以 tokens/s（每秒生成词元数）表示。它直接决定了交互式问答的等待时间、批量任务的处理周期，以及单位时间内可完成的工作量。但生成速度并非孤立指标：它同时受模型量化等级、显存容量与带宽、上下文长度、KV Cache 精度、批大小、推理后端以及是否启用投机解码等多重因素影响。因此，脱离测试条件谈“多少 tokens/s”没有工程意义。

本文的评测对象是“中等规模模型在单机本地环境下的推理吞吐表现”，评测目标是回答三个问题：第一，如何设计一套可复现的生成速度测试方法；第二，如何理解量化等级、显存占用与速度之间的三角权衡；第三，不同硬件档位（集成核显、消费级独显、专业级独显、双卡配置）分别适合什么场景。本文适合开发者、架构师、运维人员和技术负责人阅读，尤其适合正在做本地推理硬件选型、或需要为团队制定模型部署基线的人群。

需要强调的是，本文不是“跑分排行榜”，而是评测方法论与结果解读框架。具体数值会随驱动、内核、推理框架版本、模型文件与提示词内容变化，读者应把本文给出的量级作为参考区间，把测试流程作为可复用的模板。

二、评测对象说明：被评测的系统由哪些部分组成

一次本地推理的“速度”，实际上是整条链路的综合结果，至少包括以下层次：

• 模型层：参数量、量化方案（如 8bit、6bit、4bit、3bit 等不同精度等级）、是否采用混合量化（对不同层使用不同精度）。
• 推理引擎层：后端类型（如通用 GPU 计算后端）、是否启用 Flash Attention 类注意力优化、批处理大小、线程数、是否启用投机解码（draft 模型或自投机）。
• 内存与显存层：权重常驻显存还是部分卸载到内存、是否使用内存映射、KV Cache 的容量与量化精度。
• 硬件层：显存容量、显存带宽、功耗墙、GPU 核心架构。
• 系统层：操作系统版本、内核版本、图形驱动与计算运行时版本。

评测时必须把这些变量显式记录下来，否则不同人报告的“58 tps”与“40 tps”可能根本不是同一件事。一个常见的误区是只报模型名和显卡型号，却忽略了上下文长度与 KV Cache 精度——而在长上下文场景下，这两项对显存和速度的影响非常显著。

三、评测维度设计

围绕本地推理吞吐，建议建立如下评测框架：

维度	关注点	验证方式	结果解读
功能完整性	模型能否正确加载、对话模板是否生效、推理是否可中断	冒烟测试、多轮对话	加载失败或输出乱码说明配置有误
生成吞吐	首词元延迟、稳态生成速度	固定提示词多次采样取中位数	需区分“含首词元”与“纯解码”速度
准确性/有效性	量化后输出质量是否可接受	与高精度基线做一致性对比	关注语义漂移而非逐字一致
显存占用	权重 + KV Cache 峰值	监控显存曲线	决定可支持的最大上下文与并发
稳定性	长时间运行、长上下文、异常输入	持续压测、边界输入	观察是否 OOM、是否降速
易用性	配置复杂度、参数数量、调试便利性	人工评估	参数越多，复现成本越高
兼容性	与现有系统、驱动、框架版本适配	多环境验证	驱动/内核差异可能导致显著偏差
成本结构	硬件采购、功耗、运维	定性 + 功耗估算	需结合使用时长折算

其中“生成吞吐”与“显存占用”是本文重点。建议同时记录首词元延迟（Time To First Token）与稳态解码速度，因为交互式场景对前者敏感，批量生成场景对后者敏感。

四、评测环境与前提：控制变量是可信度的前提

在开始测试前，需要固定以下条件，并在报告中完整披露：

1. 硬件配置：GPU 型号（以“某消费级 GPU”“某专业级 GPU”“某集成核显”等中立方式描述）、显存容量、显存带宽、功耗上限、CPU 与内存容量。
2. 软件栈：操作系统发行版与内核版本、图形驱动与计算运行时版本、推理框架版本与编译选项。
3. 模型文件：参数量、量化方案标识、文件来源（仅描述为“某模型仓库”）。
4. 推理参数：上下文长度（如 16K、64K、256K）、批大小、GPU 卸载层数、线程数、是否启用内存映射、是否启用注意力优化、是否启用投机解码及其草稿长度、推理强度档位。
5. 测试输入：固定一组提示词，包含短问答、长文档理解、代码理解等类型，避免用单一提示词代表全部。

一个容易被忽略的细节是 KV Cache 的显存开销。以约 270 亿参数模型为例，在 16K 上下文下，未量化的 KV Cache 约占 1GB 显存；扩展到 256K 上下文时，可增至约 16GB。若对 KV Cache 做 8bit 量化，同样条件下可降至约 0.5GB 与 8GB。这意味着：上下文长度是显存规划的第一变量，而不是模型权重本身。很多“跑不动”的案例，实际是上下文开得过大导致 KV Cache 挤爆显存。

五、评测方法：一套可复现的测试流程

建议按以下步骤执行，并保留原始日志：

第一步：建立基线。 在最短上下文（如 4K）、默认量化等级下跑通一次完整对话，确认功能正确，记录首词元延迟与稳态速度，作为后续对比的基线。

第二步：固定提示词集。 准备 5 至 10 条提示词，覆盖短问答、长文摘要、代码理解（例如让模型解释一段经过混淆处理的代码逻辑）。每条提示词重复 3 至 5 次，取中位数，剔除首次加载的冷启动影响。

第三步：分维度扫描。 依次改变单一变量：上下文长度（16K → 64K → 256K）、量化等级（高精度 → 中精度 → 低精度）、是否启用投机解码、批大小。每次只改一个变量，其余保持不变。

第四步：记录资源曲线。 在测试过程中周期性采样显存占用、GPU 利用率、功耗与温度。显存峰值决定能否稳定运行，功耗与温度决定能否长时间运行。

第五步：稳定性观察。 连续运行 30 分钟以上，或在长上下文下反复请求，观察是否出现显存泄漏、速度衰减或进程崩溃。

示意性伪代码（通用表达，不含具体工具名）：

for ctx in [16K, 64K, 256K]:
    for quant in [high, medium, low]:
        load_model(quant, ctx)
        warmup()
        for prompt in prompt_set:
            t0 = now()
            first_token = generate_first()
            t1 = now()
            rest = generate_remaining()
            t2 = now()
            record(ttft=t1-t0, decode=(len(rest)/(t2-t1)))
        record_peak_vram()

第六步：结果对比与边界标注。 将结果整理为表格，并明确标注“该结论仅在当前驱动版本、当前框架版本、当前上下文长度下成立”。

六、结果解读：如何理解量化、显存与速度的三角关系

从工程经验看，本地推理存在一条普遍规律：量化等级越低，权重大小越小，显存压力越小，速度通常越快，但输出质量损失越大。以常见的混合量化方案为例，不同等级与高精度基线的一致性大致呈现如下梯度（此为通用量级参考，非特定产品承诺）：

量化等级	相对质量保持	质量损失	适用判断
8bit 级混合量化	约 99%	约 1%	接近无损，适合对质量敏感的场景
6bit 级混合量化	约 98%	约 2%	轻微损失，通用场景可用
4bit 级混合量化	约 96%	约 4%	广泛使用，性价比区间
3bit 级混合量化	约 92%	约 8%	勉强可用，建议仅用于资源受限场景

需要说明，“Top-1 词元一致率”只是质量评估的一种代理指标，它衡量的是与高精度模型在每一步预测的首选词元是否相同，并不完全等价于任务效果。对于代码理解、逻辑推理等任务，建议补充人工抽检或任务级准确率验证。

在速度侧，硬件档位决定了上限。以同核心架构的消费级与专业级 GPU 为例，二者显存带宽相近，但专业卡显存容量翻倍、功耗上限更高，因而能容纳更高量化等级与更长上下文。经验上，约 270 亿参数模型在 4bit 级量化下，专业卡可达到 50 tps 以上的量级；6bit 级（接近 8bit 精度）约 40 tps 量级；双卡配置则可直接上 8bit 级近乎无损的量化，并把上下文拉满到 256K 仍有富余。这些量级应理解为“同一档硬件下的合理预期”，而非跨平台的固定值。

集成核显的定位则完全不同。以某类轻薄本处理器搭配的统一内存架构核显为例，运行 4bit 级量化的同规模模型，速度大约在 10 tps 量级。这个速度足以支撑离线问答、文档摘要等非实时任务，但不适合高交互频率场景。由此还可以做一个粗略的横向推算：若某类桌面级 SoC 的统一内存 GPU 性能与该核显相当，则其 10 核 GPU 版本约为 10 tps，20 核约 20 tps，40 核约 40 tps，80 核约 80 tps。注意这是线性外推的估算，实际会受内存带宽、调度与散热限制，不能当作实测结论。

七、适用场景分析

• 集成核显/统一内存设备：适合个人学习、离线文档处理、低并发实验。重点评测首词元延迟与长时间运行的温控表现。
• 消费级独显（16GB 级显存）：适合个人开发者与小团队，4bit 至 3bit 量化下可跑中等上下文。重点评测显存峰值与长上下文稳定性。
• 专业级独显（32GB 级显存）：适合需要较高质量（6bit 至 8bit）与较长上下文的团队。重点评测质量一致性与并发能力。
• 双卡配置：适合对质量近乎无损、上下文接近上限有要求的场景。重点评测多卡通信开销、显存均衡与故障恢复。

八、风险与限制

第一，样本偏差：单一提示词或单一任务类型无法代表整体速度，长输出与短输出的解码速度也可能不同。第二，环境差异：内核、驱动、框架版本的细微差异可能带来明显偏差，跨环境对比需谨慎。第三，数据质量：量化质量评估若只依赖代理指标，可能高估或低估实际任务表现。第四，长期不确定性：短时压测无法暴露显存泄漏与热降频问题。第五，估算外推的风险：基于核显性能线性推算其他芯片的吞吐，只能作为数量级参考。

九、选型与使用建议

1. 先明确任务类型：交互式问答优先看首词元延迟，批量生成优先看稳态吞吐。
2. 再明确上下文需求：上下文长度直接决定 KV Cache 显存，应优先按最大上下文规划显存，再考虑量化等级。
3. 然后确定质量底线：对质量敏感的任务选择 6bit 以上量化，对成本敏感的任务可接受 4bit 级。
4. 最后验证稳定性：任何选型都应在目标环境下做不少于 30 分钟的连续压测。
5. 建议在百度智能云等通用云环境中先做小规模基线验证，再决定本地硬件投入规模，以降低试错成本。

十、总结

本文围绕本地中等规模模型的生成吞吐评测，给出了从评测目标、维度设计、环境控制、测试流程到结果解读的完整框架。核心结论是：tokens/s 不是单一数字，而是量化等级、显存容量、上下文长度、推理参数与硬件档位共同作用的结果。读者在参考任何速度数据时，应同时核对测试条件；在做选型时，应先锁定上下文与质量底线，再反推硬件档位。评测的价值不在于给出一个“最快”的答案，而在于让每个团队都能在自己的约束条件下，得到可复现、可解释、可维护的部署基线。