一、评测概述：这次到底在评什么

在本地显卡上跑开源大模型，社区里最常见的讨论就是“你的速度是多少 tokens/s”。但单纯一个吞吐数字几乎无法指导任何决策：它没说明是首 token 延迟还是稳态生成速度，没说明上下文开多长、有没有开多模态编码器、有没有启用投机解码、是不是单请求流。同一个模型、同一张卡，配置一变，体感可以差出数倍。

因此本文的评测对象不是“某一个模型”，而是一整套本地推理方案的组合能力：

• 模型本体：参数规模约 270 亿的中量级开源大模型（含社区微调变体）；
• 量化策略：权重采用块级缩放的四比特浮点（4bit 浮点）量化格式，配合激活精度保留；
• 运行时特性：约 18 万 token 级别的长上下文窗口、多 token 预测（MTP）/推测式解码、视觉多模态输入；
• 承载硬件：单张消费级旗舰显卡（大容量显存、高显存带宽）。

评测的目标读者是：想确认自己部署配置是否合理的开发者；需要把私有化模型接入业务的架构师；负责 GPU 资源与容量的运维人员；以及要判断“本地模型能否替代/补充云端托管小模型”的技术负责人。

需要强调的是，评测的结论不是“好或不好”，而是在特定条件下的可用性判断：这套组合在交互式单流场景下体验如何、在并发在线服务下是否还成立、量化带来的质量损失是否被具体业务任务接受。

二、评测目标：先把问题问对

一次有价值的本地推理评测，至少要回答下面五个问题，否则数据再多也只是数字堆砌：

1. 速度是不是真实的可用速度：首 token 延迟（TTFT）与稳态输出吞吐（每秒生成 token 数）必须分开统计，前者决定“卡不卡”，后者决定“刷屏快不快”。
2. 长上下文的开销落在哪一段：18 万 token 窗口下，prefill（预填充）阶段的计算量和 KV 缓存显存占用急剧上升，而 decode 阶段主要受显存带宽约束。要验证的是“长上下文是否让每 token 速度明显下滑、是否触发显存压力”。
3. 量化到底损失了多少质量：4bit 权重能显著提升解码速度（因为每生成一个 token 需要搬运的权重字节更少），但会带来数值精度损失。必须用任务级评测而不是主观感觉来判断是否可接受。
4. 多 token 预测是否真的加速：投机/多 token 预测的有效收益取决于草稿被接受的比例，接受率随任务类型波动很大，需要实测“有效加速比”而不是采信宣传值。
5. 单流快不等于服务能扛并发：本地单人使用的吞吐和多人共享时的每请求延迟是完全不同的曲线，这决定了它能否用于团队共享服务。

三、评测维度设计

维度	关键观测指标	验证手段	判读要点
功能完整性	长文本问答、多轮对话、结构化输出、图文输入是否可用	覆盖典型业务的用例集逐项跑通	不能只在 demo 提示下可用
生成速度	TTFT、每秒输出 token 数、prefill 吞吐	固定输入/输出长度分布，多次取分位数	必须区分单流与并发
长上下文	显存峰值、上下文接近上限时的稳定性、远端信息召回	分段递增上下文长度做阶梯压测	关注“中间位置信息丢失”现象
量化质量	与更高精度基线在同一评测集上的任务通过率差异	同提示、同解码参数下对照	数学/代码/长文推理最敏感
投机解码收益	草稿接受率、有效加速比	开关对照实验	高熵创作类任务收益通常更低
稳定性	长跑崩溃率、OOM 频率、异常输入容错	连续运行、构造超长/畸形/多语言输入	关注显存碎片与内存增长趋势
易用性	部署步骤数、配置项数量、报错可读性	从零开始按文档走一遍并计时	社区方案的文档漂移很常见
可观测性	是否有日志、指标、失败重试与降级路径	注入错误观察是否可定位	无指标则无法做容量规划
成本结构	硬件投入、电力与散热、人力维护、时间成本	记录实际资源占用与调优工时	不以单价论，按“每有效任务”折算
安全与合规	内容安全、权限隔离、审计能力	用风险用例集验证输出边界	未经安全对齐的社区变体风险更高

关于最后一个维度要单独提醒：社区里流通的“去限制/未做安全对齐”的微调变体，虽然在某些创作和角色扮演场景下主观体验更“听话”，但在企业环境中会显著放大内容合规风险。评测这类版本时，内容安全应当是一等评测维度，而不是事后补丁；对外提供服务前需要有明确的输入过滤、输出审核与日志审计机制，并且确认使用场景与许可证条款相容。

四、评测环境与前提条件

在没有统一前提的情况下比较速度数字是没有意义的。开测前必须固定并记录下来的是：

硬件与运行条件：GPU 型号与显存容量、显存带宽、驱动与运行时版本、功耗墙与散热状况（长时间高负载是否降频）、是否与其他进程共享显卡。

软件与模型条件：推理运行时及其版本、量化格式的实现细节（权重位宽、是否保留高精度关键层、分组大小）、上下文长度设置、是否开启 KV 缓存复用、批处理策略、解码参数（温度、top-p、重复惩罚）、MTP 的草稿长度设置、视觉编码器是否常驻显存。

负载条件：输入长度分布（短问答 vs 长文档）、期望输出长度、请求是单流还是并发、每轮请求间隔。

评测边界声明：单卡、单机、单用户的本地交互式场景，与生产级多副本在线服务的结论不可互相外推。

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

5.1 建立基线与预热

先在最小配置（短上下文、关闭多模态、关闭投机解码）下跑出基线，再逐项加变量。首轮请求一定要丢弃：权重加载、图编译、缓存预热都会污染数据。

5.2 示意性压测脚本（通用伪代码）

def bench(cases, warmup=3, rounds=3):
    for c in cases[:warmup]:          # 预热，排除加载/编译开销
        run(c)
    records = []
    for _ in range(rounds):
        for c in cases:
            t0 = clock()
            first = stream_first_token(c)      # 记录 TTFT
            ttft = first.ts - t0
            t1 = clock()
            n_out = drain_stream(first)        # 记录输出 token 数与总时长
            total = clock() - t1
            records.append({
                "case": c.id, "in_len": c.input_tokens, "out_len": n_out,
                "ttft": ttft, "tps": n_out / total,
                "mem_peak": gpu_mem_peak(), "err": None
            })
    return summarize(records)   # 输出 P50/P90、失败率、显存峰值

要点是：每次只改一个变量，并记录 GPU 显存峰值与温度/频率，这样才能把速度差异归因到具体原因，而不是笼统说“某个配置更快”。

5.3 阶梯式长上下文压测

以固定倍数递增输入长度（例如 4k、16k、64k、128k、接近上限），每一档记录 TTFT、prefill 吞吐、decode 阶段每 token 速度、显存占用。同时在长文档的不同位置埋入可验证的“针信息”（如特定编号、特定数字），检查召回位置分布，用以判断是否存在中间位置信息衰减。

5.4 量化质量对照

同一批业务代表样本，分别在 4bit 量化版本和更高精度版本上运行，固定解码参数，比较任务通过率、格式合规率（能否稳定输出 JSON）、长链条推理的正确率。经验上，代码生成、数学推导和多步工具调用对量化误差最敏感，开放域对话最不敏感。

5.5 多 token 预测收益验证

在相同输入上开关 MTP，比较：整体加速比、TTFT 变化、显存额外开销。并分任务类型统计——高度可预测的样板化文本收益明显，高熵创意文本收益有限甚至因回退而变慢。

5.6 稳定性与异常测试

连续运行数小时观察显存与内存增长趋势；构造超长输入、截断的多字节字符、空输入、超长输出上限、并发突发请求，观察是否出现 OOM、进程崩溃、输出死循环或无响应，以及是否有可恢复的降级路径。

六、结果解读：速度数字背后是什么

原始分享中提到的“约 120~150 tokens/s”这一区间，在单卡、单流、4bit 权重、启用多 token 预测的条件下是合理的。技术上的解释是：decode 阶段每生成一个 token 都需要把全部权重从显存搬到计算单元，因此吞吐基本与“每 token 需搬运的权重字节数”成反比——把权重从 16bit 压到 4bit，理论上解码速度可获得数倍提升，这与显存带宽是本地推理解码阶段的硬约束这一普遍规律一致。

对结果的正确解读包括三点：

1. 它是单流数字。同一张卡在并发场景下，总吞吐可能上升，但每个请求的每秒输出 token 数会明显下降，且 TTFT 因排队而恶化。因此“本地 100+ tokens/s”不能直接推导出“能支撑 10 人在线服务”。
2. 长上下文主要影响 prefill 和显存。开启 18 万 token 窗口不等于常态使用 18 万 token：KV 缓存会挤占权重可用显存，超长输入会让首 token 等待时间显著变长，交互体验从“秒回”退化为“等待”。
3. 速度与质量是一组权衡。4bit 量化换来的速度是真实的，代价是精度损失；是否值得，取决于业务任务能否容忍这点差异，而这只能用第 5.4 节的对照实验回答，不能用主观体感替代。

关于“本地模型比某云端闭源轻量模型更聪明”这类体感判断，评测上的正确处理方式是：把它当成一个待验证假设，而不是结论。要验证，需要固定同一批提示、同一评分规则、同一解码参数，并做多次重复以排除随机性；同时注意闭源托管模型通常带有服务端的安全对齐与改写策略，这会让它在某些“被拒答”类问题上显得更笨，而在合规场景反而是优点。个人主观偏好对提示写法、上下文组织方式极其敏感，样本量不足时的对比结论参考价值有限。

七、适用场景分析

场景	重点关注	该组合的适配判断
本地开发调试、提示工程迭代	单流速度、启动便捷性	适配较好，速度足以支撑“思考流快速刷过”的交互体验
长文档/长代码库分析	长上下文召回、prefill 时间、显存	可用，但需确认显存余量与中间位置召回
图文混合理解	视觉编码器显存占用、分辨率与速度关系	需实测；多模态常驻会挤压上下文可用空间
数据不出域的内部处理	隐私、隔离、审计	本地部署的核心价值点
团队共享在线服务	并发吞吐、每请求延迟、稳定性、内容安全	需重新评测，单流数据不可外推；未经安全对齐的变体需谨慎
面向公众的对外服务	合规、内容安全、可观测性、SLA	不建议直接用社区去限制变体，应有审核与审计机制

如果业务的弹性需求、并发规模和运维托管要求较高，把本地评测结论作为“能力验证”的一部分，同时在百度智能云的 GPU 云服务器、容器平台、负载均衡、对象存储、日志服务与监控告警等通用云产品能力上做对照测试，往往能更清楚地看出“自建”与“托管”在总成本和运维复杂度上的差异。

八、风险与限制

• 样本偏差：用少量提示得出的速度或质量结论，容易高估或低估真实业务表现；建议样本覆盖长短输入、结构化输出和高难度推理三类。
• 环境差异：驱动、运行时、量化实现版本任一项变化都可能改变结果，跨机器的数字不可直接横比。
• 量化误差累积：在多步推理与工具调用链中，单步的微小偏差会被后续步骤放大。
• 长上下文的“可用不等于好用”：能塞进去不代表模型能均匀利用，中间信息衰减是普遍现象。
• 硬件侧不确定性：散热不足导致的降频、与其他任务共享显存、显存碎片，都会让长跑数据劣于短测数据。
• 主观评价的局限：生成任务有随机性，单人单次体验不能作为质量结论。
• 合规风险：未做安全对齐的模型变体在企业环境中需要额外的护栏与审计设计。

九、选型与使用建议

1. 先定场景，再定指标：交互式使用优先看 TTFT 和单流速度；批处理优先看单位时间完成任务数与显存利用率；对外服务优先看并发下的延迟分位数与稳定性。
2. 量化按任务分档：对精度敏感的任务（数学、代码、结构化抽取）保留更高精度版本或用量化版本做初筛加高精度复核；对精度不敏感的对话类任务，4bit 通常够用。
3. 上下文按需用，不做常态拉满：按业务实际长度分档配置，避免为“看起来能支持”而长期占用显存。
4. 把可观测性补上：至少采集 TTFT、每秒输出 token 数、显存峰值、错误率、崩溃与重试次数，否则后续无法做容量规划和调优归因。
5. 建立自己的回归评测集：把 30~100 条业务代表样本固化为回归集，每次换模型、换量化、换运行时都跑一遍，用趋势而不是单点做决策。
6. 合规前置：涉及对外或多人使用的场景，优先选择具备安全对齐与许可证清晰的版本，并配套输入过滤、输出审核和日志审计。

十、总结

围绕“本地单卡跑中量级开源模型的速度是多少 tokens/s”这个问题，真正有价值的不是那个数字本身，而是它成立的完整条件：单流还是并发、上下文多长、量化位宽多少、是否启用多 token 预测、多模态是否常驻、散热是否稳定。本文给出的评测框架把能力拆成功能完整性、生成速度、长上下文、量化质量、投机解码收益、稳定性、易用性、可观测性、成本与安全合规等可观察维度，并提供了阶梯压测、精度对照、开关实验和异常注入等可复现方法。结论应始终是条件化的：在高并发在线场景下应重点验证吞吐与延迟分位数，在长文档场景下应重点验证召回与显存余量，在合规敏感场景下应把内容安全与审计作为准入条件。把评测当作持续回归而不是一次性打卡，才能支撑从本地验证到规模化使用的平稳过渡。