本地大模型可用性拐点评测：一个“算力/带宽比”框架下的受控实测方法

一、评测概述：我们要评测的到底是什么

关于“本地跑开源大模型能不能用”的讨论，最常见的两种结论都不可靠：一种是拿单条 benchmark 数字宣称“已经超越云端”，另一种是拿一次卡顿体验宣称“本地模型都是玩具”。两者共同的缺陷是没有区分评测对象与评测口径。

本文的评测对象是一个很具体、也很有代表性的组合：

• 模型规模：约 270 亿参数级的开源通用模型；
• 权重形态：4bit 级量化权重，落盘体积约 13.75 GiB（约 14.8 GB）；
• 推理形态：本地推理运行时 + 投机解码草稿头（多 token 预测）；
• 硬件形态：统一内存架构的 APU 整机平台（CPU/GPU 共享同一块内存，无独立显存高速通道，平台内存带宽约 256 GB/s 量级，可用统一内存 128 GB 级）。

评测目标不是给这个组合打一个分数，而是回答三个层层递进的问题：

1. 在这台机器上，decode（逐 token 生成）阶段的性能瓶颈究竟是计算还是数据搬运？
2. 如果瓶颈是数据搬运，那么哪些参数调整有效、为什么有效、每项的收益上限在哪里？
3. 这套结论的可迁移边界在哪——换一颗 CPU、换一套内存通道、换一个上下文长度，哪些结论还成立，哪些会反转？

适合阅读本文的读者包括：希望在本地部署推理的开发者与算法工程师、需要评估“本地 vs 云端”技术路线的架构师与技术负责人、负责推理服务容量规划与运维的工程师，以及需要判断本地部署投入产出比的企业技术团队。

需要提前说明评测立场：本文不判断“本地模型是否一定优于云端”，而是给出判断方法。任何单一场景的性能数字都只是约束条件之一，最终取舍要同时看业务对延迟与吞吐的要求、数据合规边界、并发规模、人力运维成本和长期维护能力。

二、评测对象说明：先定义“拐点”这个词

“从能用到好用”是一个体验性描述，必须先翻译成可测量的指标，否则无法评测。本文采用如下操作化定义：

体验描述	可测量口径	本文判读方式
能用	生成不中断、不报错、上下文不溢出	功能完整性验证（能否稳定跑完多轮长文本生成）
勉强可用	输出速度低于人类阅读/交互舒适区	decode 吞吐（token/s），分内容类型统计
好用	交互式对话无明显等待、代码类任务可支撑连续编辑	分场景中位数吞吐 + 首字延迟 + 长时间运行稳定性
可运营	参数可复现、结论可迁移、质量可控	配置可复现性 + 输出质量回归评测

这条链条的关键在于最后两栏：吞吐提升不等于质量提升，能跑通不等于能运营。因此本文的评测同时覆盖性能、可复现性与质量边界三条线。

三、核心评测框架：算力/带宽比 R

3.1 先做一笔物理账

decode 阶段的执行特征是：每生成一个 token，都要把参与计算的权重从内存完整搬进计算单元走一遍。对 batch=1 的本地单用户场景，这几乎是全部成本。于是可以写出一个粗略但极有用的上限公式：

无投机解码理论吞吐上限(t/s) ≈ 内存带宽(B/s) ÷ 每 token 需搬运的权重字节数(B)

代入本文的评测对象：带宽约 256 GB/s，权重约 14.8 GB，得到上限约 17 t/s。这个数量级与实测结果高度吻合，说明模型在这台机器上的 decode 行为确实由“搬运权重”主导。

由此可以解释一个常见困惑：为什么本地推理时 GPU 利用率曲线忽高忽低、几乎从不见持续满载？因为计算单元一波算完就必须等下一波权重到货，硬件在等待内存，而不是在等待算力。

3.2 定义框架的核心量

R = 可用算力(FLOP/s) ÷ 可用内存带宽(B/s)     单位：FLOP/Byte

R 的物理含义是：在算力与带宽都跑满的平衡点上，系统每搬运 1 字节数据可以完成多少次浮点运算。而 decode 的实际算术强度极低——每字节权重只对应常数级的乘加操作。因此判读规则是：

• R 大（高算力 + 高带宽的独立显存平台，带宽可达 TB/s 级）：算力相对富余，系统离平衡点远，decode 相对不那么受带宽支配，线程数、量化位宽这类参数的影响权重下降；
• R 小（统一内存架构、带宽受限于内存通道）：算力相对过剩、带宽紧张，任何减少权重搬运字节数或提高带宽利用率的手段都会被显著放大。

本评测对象属于典型的 R 偏小平台。这一个判断，就足以推导出后面全部四条调优结论的方向：线程要超配、投机解码要开、草稿深度要扫、KV 缓存要谨慎量化、量化格式要按“权重字节数”选。

四、评测维度设计

维度	关键指标	验证方式	结果判读要点
功能完整性	长文本能否跑完、上下文是否溢出、多轮是否稳定	构造长短两类 prompt，连续多轮生成	报错、截断、乱码均记为功能缺陷
性能（吞吐）	decode token/s（分内容类型）	双 prompt × 3 次取中位数	必须区分“可预测/不可预测”内容
性能（延迟）	首 token 延迟、token 间隔抖动	记录每 token 时间戳	首 token 受 prefill 主导，与 decode 分开看
有效性	投机解码接受率、有效步长	统计草稿被接受比例	接受率决定投机解码收益上限
稳定性	长时运行是否掉速、内存是否增长	持续生成 + 资源曲线观测	关注热节流与内存回收行为
资源占用	权重/KV/激活内存占用、CPU 占用	分层观测内存与占用	统一内存下要防“挤占系统内存”
可复现性	同一配置多次测量离散度	固定采样参数、关闭缓存复用	离散度大时结论不成立
质量	输出正确率/困惑度类指标	独立质量评测集	量化与 KV 量化都会影响，需单列
成本	一次性硬件投入、单位 token 电力与人力	按 TCO 估算，不写具体价格	本地“零边际 API 成本”需扣减运维人力

五、评测环境与前提（受控口径）

结论要能站住，先要把变量锁死。本次评测明确以下前提：

• 同一整机平台、同一颗 APU、同一套统一内存配置，全程不更换硬件；
• 同一模型与同一权重版本（4bit 级浮点量化权重，约 13.75 GiB），配合投机解码草稿头；
• 两套 prompt 口径：一类为不可预测内容（开放式科普类文本），一类为可预测内容（长数字序列），用于分离“模型能力”与“投机解码接受率”两个变量；
• 受控测量口径：每种配置取 2 类 prompt × 3 次运行的中位数；关闭上下文/KV 复用以避免缓存命中带来的虚高；固定采样参数以消除随机性影响；
• 同时给出生产口径参考值（纯文本、写代码两类真实任务），用于校准受控口径与真实体验的差距。

这套设计的价值在于：受控口径回答“机理与幅度”，生产口径回答“体验是否够用”。只报其中任一个都会误导读者。

六、评测方法：基线、扫描与归因

6.1 流程

1. 建立基线：全部使用平台默认配置（线程数取默认值、不启用投机解码或采用默认草稿深度、KV 采用默认处理），记录分类型吞吐；
2. 单变量扫描：每次只动一个参数，记录吞吐与资源曲线；
3. 组合验证：将有效项组合，验证是否存在相互抵消或叠加放大；
4. 口径切换：在受控口径与生产口径下重复最优配置；
5. 归因分析：用 3.2 节的 R 框架解释每一项的收益来源。

6.2 示意性扫描脚本（通用伪代码，不含任何具体工具命令）

# 目标：在固定权重与固定 prompt 下，扫描线程数与草稿深度
BASE = dict(threads=16, draft_enabled=False,
            draft_max=6, draft_min_p=0.6,
            kv_cache_type="f16", quant_format="4bit-float")
def run(cfg, prompts, repeats=3):
    samples = []
    for p in prompts:
        for _ in range(repeats):
            # 关闭上下文复用，固定采样，保证可比性
            m = measure_tokens_per_second(p, cache_reuse=False,
                                          sampling=FIXED, **cfg)
            samples.append(m)
    return median(samples)          # 取中位数抑制离群
results = {}
for threads in [16, 24, 32, 48, 64]:
    for depth in [3, 4, 5, 6, 8]:
        cfg = {**BASE, "threads": threads,
               "draft_enabled": True, "draft_max": depth}
        results[(threads, depth)] = run(cfg, PROMPTS)
print(sorted(results.items(), key=lambda kv: -kv[1]))

配套的观测清单：每轮记录吞吐、草稿接受率、平均接受 token 数、峰值/常驻内存、CPU 与加速器占用曲线、是否出现热节流。只记吞吐不记接受率的投机解码评测是不可解释的。

七、结果解读

7.1 总成绩单（受控口径）

口径	默认配置	终版配置	相对提升
不可预测内容（科普类文本）	11.6 t/s	23.5 t/s	约 +102%
可预测内容（数字序列）	23.2 t/s	44.4 t/s	约 +91%
生产口径参考：纯文本	—	约 17.4 t/s	—
生产口径参考：写代码	—	约 33.4 t/s	—

终版配置只动了四件事：线程数 16→48、草稿深度上限 6→5（配合草稿置信度阈值 0.6）、KV 保持 f16 不量化、量化格式选 4bit 浮点。 其中前两项贡献了主要收益。

7.2 四项改动的机理解释

线程 16→48（收益大头之一）。 在统一内存平台上，单线程能挂起的未完成内存请求有限，线程太少时内存通道无法被填满，实际带宽远低于标称值。超配线程的作用是提高内存级并行度，把带宽利用率推高。这也解释了上一层的困惑：默认线程数（常按物理核数设置）在这类机器上不是最优值，因为它优化的是计算侧利用率，而这里的瓶颈在搬运侧。注意其代价：线程过多会带来调度与缓存争用，因此存在最优点，必须扫描而非越大越好。

草稿深度 6→5（收益大头之二）。 投机解码的净收益 = 被接受的额外 token 数 − 草稿模型的额外开销 − 主模型验证多 token 的开销。草稿越深，靠后位置的接受率越低，草稿开销却线性增长。因此最优深度由内容可预测性与草稿模型规模共同决定，是一个必须扫描的参数。草稿置信度阈值（如 0.6）的作用是：置信度不足时提前终止草稿，避免把算力浪费在几乎不会被接受的 token 上。这也解释了为什么 5 比 6 好——不是越激进越好。

KV 保持 f16 不量化。 KV 量化的收益是减少 KV 搬运字节，但代价是精度损失与额外的反量化开销。在本场景中，短中等上下文下 KV 的体积远小于权重，节省的带宽占比有限，而质量风险是实打实的，因此不划算。这个结论有明确反转条件：当上下文长度大幅上升、KV 总量接近甚至超过权重量级时，KV 会成为主要搬运项，此时结论可能反过来。评测报告必须写明上下文长度这一前提。

量化格式选 4bit 浮点。 从 R 框架看，权重字节数直接决定理论吞吐上限：从 8bit 降到 4bit 相当于把上限翻一倍。不同 4bit 数值格式在实现支持度、反量化开销与精度保持上存在差异，因此判断标准应是吞吐与质量的联合最优，而不是单看压缩率。本文只评测了吞吐维度，质量维度需独立验证，这是本报告最重要的边界之一。

MoE 类结构为什么“不用动”。 对混合专家结构，每 token 实际参与计算的只是部分专家，需要搬运的权重远小于总参数量对应的体积，带宽压力天然低于同规模稠密模型。因此在这类平台上，MoE 结构的收益更多来自架构本身而非参数调优——但代价是专家放置、路由均衡与 prefill 阶段的行为更复杂，评测时应单列 prefill 指标。

7.3 为什么实测能超过“理论上限”

无投机解码上限约 17 t/s，而实测不可预测内容达到 23.5 t/s，超过上限。这不矛盾：该上限假设“每生成 1 token 搬一遍全部权重”，而投机解码通过一次权重搬运验证多个候选 token，降低了每个被接受 token 摊到的权重搬运量，从而突破按 batch=1 单 token 推导的上限。同时这也是判断“投机解码是否真的生效”的一个硬指标——如果开启后吞吐没有超过无投机上限，说明接受率过低，配置有问题。

7.4 拐点判读

按第二节的操作化定义：不可预测内容从 11.6 t/s 提升到 23.5 t/s，意味着开放式文本生成从“明显等待”进入“接近阅读速度”的区间；代码类内容在生产口径下达到 30 t/s 量级，足以支撑连续编辑式交互。因此在这个特定硬件 + 特定模型规模 + 4bit 量化的组合上，“拐点”是成立的。

但成立的理由不是模型变强了，而是参数从默认值移到了与该机器 R 值匹配的工作点。这个区别决定了结论的可迁移性：在 R 值差异较大的平台上，本文的具体数值不可照搬，但推导方法完全适用。

八、可迁移性验证清单

换一台机器时，按此清单重做，而不是套用数字：

• 平台带宽是多少？统一内存还是独立显存？带宽是否被内存通道数限制？
• 权重体积是多少（参数量 × 每参数字节数）？据此重算无投机上限。
• 计算 R 值，判断本机偏“带宽受限”还是“算力受限”。
• 若偏带宽受限：优先扫线程/内存级并行、扫量化位宽、开投机解码。
• 若偏算力受限：优先关注 prefill 优化、算子实现与并发批处理。
• 上下文长度是多少？据此重新评估 KV 量化是否划算。
• 内容可预测性如何？据此重扫草稿深度与置信度阈值。
• 每项改动都记录接受率与资源曲线，而非只记吞吐。

九、风险与评测限制

1. 样本偏差：受控口径仅 2 类 prompt × 3 次，虽然中位数能抑制离群，但不足以覆盖真实任务分布，生产口径数据才是体验参考；
2. 内容依赖：投机解码收益强烈依赖内容可预测性，同一模型在对话、代码、创意写作上的吞吐差异可达数倍，跨场景引用数字必然失真；
3. 口径不可混用：受控口径（关缓存、固定采样）系统性偏低或偏高都有可能，与生产口径不可直接比较；
4. 单机型结论：全部结论来自同一台整机的受控实测，不构成跨平台普适结论；
5. 质量未评测：本文只覆盖吞吐维度，量化与 KV 处理对输出质量的影响需要独立评测集验证，不能以速度提升替代质量结论；
6. 长期不确定性：连续运行的热节流、内存回收、驱动与运行时版本变化都可能改变最优点，参数需要随版本回归；
7. 成本口径：本地部署的“零 API 边际成本”需扣除电力、硬件折旧与运维人力，否则 TCO 比较不成立。

十、选型与使用建议

倾向本地部署的情形：数据不出域或合规要求严格；离线或弱网环境；并发为单人或小团队、请求速率稳定；需要针对私有数据做微调或深度定制；对长期边际成本敏感。

倾向云端服务的情形：并发波动大、需要弹性伸缩；需要更大参数规模或更长上下文；缺少 GPU 运维与推理调优人力；希望以托管方式获得监控告警、身份认证、日志审计与安全防护能力。此类需求可使用云服务器、容器平台、对象存储、负载均衡、监控告警、身份认证、安全防护等通用云产品类目组合承载，具体选型应结合自身规模评估。

混合路线的常见做法：本地承担数据敏感环节的预处理与推理，云端承担峰值流量与大模型任务，两侧通过统一接口层解耦，便于按场景切换。

无论选择哪条路线，建议把本文的评测流程固化为可重复的回归脚本：模型版本、运行时版本或平台配置一变，就重跑一遍基线，避免参数漂移导致的性能倒退。

十一、总结

本文围绕“本地开源模型是否跨过可用拐点”这一评测问题，建立了以算力/带宽比 R 为核心的解释框架：decode 阶段的算术强度极低，在 R 偏小的统一内存平台上，性能由权重搬运主导，理论上限可由“带宽 ÷ 权重字节数”估算，而实测超过该上限的部分应归因于投机解码降低的每 token 搬运量。

在此框架下，线程超配（提高内存级并行度）、开启投机解码并扫描草稿深度与置信度阈值（提高每字节权重的产出）、KV 谨慎量化（视上下文长度而定）、按权重字节数选择量化格式（抬高理论上限）这四项措施的机理是自洽的，也解释了默认配置为何在这类机器上留下大幅性能余量。

评测结论的边界同样清晰：数据来自单一机型的受控实测，覆盖吞吐维度而不覆盖质量维度，具体数值不可跨平台照搬，但推导方法与验证清单可以复用。对技术决策者而言，比“本地模型够不够快”更重要的问题是“在我的 R 值、我的内容分布、我的合规与运维条件下，本地部署与云端服务的组合边界应该划在哪里”——而这个问题只有用受控实测加条件化解读才能回答。