本地270亿参数模型推理速度评测指南

一、评测概述

社区里“大家的速度都是多少 tokens/s”这类提问，几乎无法直接比较。原因是决定解码速度的变量至少有六个：模型规格、量化档位、推理引擎与计算后端、硬件容量与带宽、上下文长度与 KV Cache 配置、以及解码策略（批大小、并发、投机解码）。任何一项不同，tps 数字就不可比。

本文的评测对象不是某一个模型或某一块加速卡，而是一条完整的本地/私有化推理链路：在自有硬件上加载约 270 亿参数级开源基座模型的量化权重，通过通用推理服务对外提供流式生成能力，并观察其速度、时延、容量、质量与稳定性表现。

适用读者：需要本地编码辅助的开发者、要做出选型与容量规划的架构师、负责部署与监控的运维人员、需要判断预算与风险的技术负责人。

需要强调的是：本文不回答“哪块卡最好”，而回答“在我的任务类型、时延容忍度、预算与运维能力下，哪一组模型规格 + 量化档位 + 硬件平台 + 上下文配置是可行的，以及这个判断在什么条件下成立”。

二、评测目标：先明确要回答的问题

一次有价值的评测，应当能回答以下问题，否则指标再多也无法指导决策：

1. 目标任务的端到端时延是否可接受（首字延迟 + 生成速度）；
2. 权重、KV Cache 与运行时缓冲之和，能否装进现有显存或统一内存；
3. 所选量化档位的质量折损，是否落在业务可容忍范围内；
4. 长上下文（32K 以上乃至 256K/512K）是否真正可用，速度衰减有多快；
5. 长时间运行、并发、异常输入下是否稳定；
6. 总拥有成本（硬件 + 电力 + 人力 + 迁移）与运维负担是否可接受。

三、评测对象拆解：决定速度的六个变量

变量	对速度的影响机制	评测时必须记录
模型规格	总参数量与激活参数量决定单步计算量；注意力与层结构影响长上下文表现	模型标识、参数规模、是否为轻量/优化版本
量化档位	权重位宽直接决定权重体积，从而决定解码时每步需读取的字节数	具体档位标识与权重文件大小
推理引擎与计算后端	通用计算后端与厂商运行时在算子实现、内存管理、批处理策略上差异明显	引擎版本、后端类型与版本、关键启动参数
硬件平台	显存/内存容量决定可行性，带宽决定速度上限，功耗墙决定持续性能	容量、带宽、功耗上限、散热形态
上下文与 KV Cache	KV Cache 随上下文线性增长，既占容量又增加每步读取量	上下文长度、KV 量化位宽、缓存策略
解码策略	连续批处理提升总吞吐；投机解码用一次权重读取验证多个词元	批大小、并发数、是否开启投机解码及草稿长度

四、为什么“带宽优先”是估算速度的正确起点

解码阶段是典型的内存带宽受限过程：每生成一个词元，通常要把全部权重读取一遍。因此一阶估算为：

tps_upper ≈ 有效显存带宽 ÷ (权重字节数 + 每步 KV Cache 读取字节数)
权重字节数 ≈ 参数量 × 每权重比特数 ÷ 8

以约 270 亿参数、640GB/s 带宽平台做一阶估算：4bit 档（约 4.5bit/权重，权重约 15GB）上限在 40 tps 量级；3bit 档（约 12GB）上限在 50 tps 量级；6bit 档（约 22GB）上限降至 30 tps 以内。

解读这一估算要注意三点：

• 实测可能高于一阶估算：开启投机解码后，一次权重读取可验证多个词元，有效吞吐因此突破“单步读一遍权重”的朴素上限。这也解释了为什么记录中会出现 3bit 档实测速度逼近甚至超过按权重量估算的上限。
• 实测可能明显低于估算：KV Cache 读取随上下文线性增长、功耗墙与温度导致降频、后台进程抢占、引擎实现差异，都会拉低实际值。
• 更合理的指标是效率：把“实测 tps ÷ 带宽估算上限”当作引擎效率指标横向比较，比直接比较绝对 tps 更有意义。

五、评测维度设计

维度	观测指标	验证方式	解读要点
生成速度	解码 tps（P50/P95）、端到端 tps	固定提示词与最大输出长度，预热后多次取中位数	必须声明是否开启投机解码
首字延迟	TTFT	按 1K/8K/32K/128K 分档输入测试	Prefill 是计算密集型，长输入下 TTFT 常成为主瓶颈
吞吐与并发	并发 1/2/4/8 下的 tps 与延迟	并发梯度压测	连续批处理提升总吞吐，但会抬高单请求延迟
容量占用	权重 + KV + 缓冲的峰值占用	逐档递增上下文，观察 OOM 临界点	容量先决定“能不能跑”，带宽才决定“跑多快”
上下文可用性	可用最大上下文与速度衰减曲线	4K→32K→128K→256K 分档	能塞进去 ≠ 用得准
质量一致性	与高精度基线的 Top-1 一致率、任务成功率	固定样本集、贪心解码、基线对比	词元级一致率不等于任务可用
稳定性	连续运行时长、错误率、延迟抖动 P99	长时压测 + 异常输入	热降频、内存碎片、长会话增长
易用性	部署步骤数、参数可调项、报错可读性	由未参与部署者按文档复现	反映团队接手成本
可观测性	是否输出词元计数、prefill/decode 耗时分解、资源指标	检查服务输出与日志	不可观测则无法定位“为什么慢”
安全性	服务鉴权、日志脱敏、模型来源校验	配置检查 + 暴露面扫描	本地部署不等于安全
成本结构	硬件、电力、人力、迁移与机会成本	按项目周期折算	看总拥有成本而非单价

六、评测环境与前提：必须锁定的控制变量

• 模型标识与量化档位一致（同一权重文件、同一分词器）；
• 上下文长度、批大小、并发数固定；
• 测量前执行预热，排除首次加载与缓存冷启动；
• 统一词元计数口径（不同引擎的 token 统计方式可能不同，导致同一输出得到不同 tps）；
• 关闭无关后台进程，记录室温、风扇策略与功耗墙设置；
• 记录引擎、计算后端、量化实现的版本号；
• 明确记录是否开启投机解码及其草稿长度。

一个很有说服力的例子是：同一测试者在把平台内存规格与代际下调后，改用同系列的轻量推理优化版本，在 512K 上下文下峰值约 21 tps，而此前在更高规格平台上使用原规格 3bit 档约为 58 tps。这说明跨记录直接比较 tps 几乎不可行——模型规格与上下文配置的变化，影响量级不亚于硬件差异。

七、评测方法：五步流程与示意性代码

步骤 1：建立基线。 单请求、短输入（约 1K）、长输出（约 512 词元），预热后重复 3~5 次取中位数。
步骤 2：分档扫描。 上下文 4K→32K→128K→256K；并发 1→8；量化档由高到低逐档测试。
步骤 3：稳定性观察。 连续运行数小时，记录 P50/P95/P99、错误率与资源曲线。
步骤 4：质量抽检。 固定样本集覆盖代码理解、混淆或压缩后代码的语义还原、指令遵循、结构化输出。
步骤 5：记录与复盘。 全部结果表格化，结论一律带条件。

单请求解码速度测量（示意性伪代码，接口路径与字段名以实际服务为准）：

CONFIG = {"max_tokens": 512, "temperature": 0, "stream": True}
def measure_once(prompt, endpoint, repeat=3):
    runs = []
    for _ in range(repeat):
        t0, ttft, out_tokens = now(), None, 0
        for chunk in stream_request(endpoint, prompt, **CONFIG):
            if ttft is None:
                ttft = now() - t0            # 首字延迟
            out_tokens += count_tokens(chunk)  # 统一计数口径
        total = now() - t0
        runs.append({
            "ttft_ms": ttft * 1000,
            "decode_tps": out_tokens / max(total - ttft, 1e-6),
            "overall_tps": out_tokens / total,
        })
    return median_by_key(runs)               # 取中位数，抗抖动
# 并发梯度：观察总吞吐与 P95 延迟的权衡
for concurrency in (1, 2, 4, 8):
    report(concurrency, run_concurrent_load(prompts, concurrency))

八、结果解读：如何把 tps 翻译成“能不能用”

在“单用户交互式、流式输出、上下文不超过 32K、量化不低于中档”的前提下，可参考如下经验性分档（属定性判断，需用自身任务重新校准）：

解码速度	体验定性	典型适配
≥ 40 tps	接近人工阅读上限	边生成边审的长代码、长文档分析
20~40 tps	交互可用，长输出等待感明显	编码辅助、复杂推理
10~20 tps	适合短输出与辅助问答	需分段生成长文
< 10 tps	不适合实时交互	离线批处理、定时任务

公开测试记录中的一组参考值（已去品牌化，属不可复现的单点记录，仅作量级参照）：

方案	平台特征	量化档位	记录速度
方案A	消费级独显，16GB 显存 / 640GB/s / 220W	3bit 档，开启投机解码 + 低思考档	约 58 tps
方案B	专业级加速卡，32GB 显存 / 640GB/s / 300W	4bit 档	50+ tps
方案B’	同上	6bit 档	约 40 tps
方案C	轻薄本集成显卡 + 统一内存	4bit 档	约 10 tps
方案D	集成 GPU，核数由 10 递增至 80	4bit 档	约 10 / 20 / 40 / 80 tps（线性外推）
方案E	内存规格下调的平台	同系列轻量推理优化版本，512K 上下文	峰值约 21 tps

三点解读：其一，容量与带宽是硬约束，同带宽下更高档位因权重体积更大而速度下降，符合带宽受限模型；其二，集成 GPU 的核数线性外推只能作量级参考，实际受带宽、缓存层级与调度开销限制，通常呈次线性；其三，方案E说明在弱平台上通过降低模型单步计算量来换取超长上下文能力，是一种合理的工程取舍，但必须重新做质量抽检。

九、量化档位：速度与质量的联合评测

公开记录给出的词元级一致率参考值：

档位	Top-1 一致率（记录值）	质量损失（记录值）	使用建议
8bit 档	约 99%	约 1%，近乎无损	容量允许时优先
6bit 档	约 98%	约 2%，轻微	容量与质量平衡较好
4bit 档	约 96%	约 4%，广泛使用	速度与质量的常规折中
3bit 档	约 92%	约 8%，勉强可用	仅作兜底，必须任务级验证

关键方法论：词元级一致率高不等于任务可用。误差会在长链式推理与结构化输出中累积。因此应做任务级抽检：固定样本集、贪心解码保证可复现、与高精度基线逐项对比、必要时人工评分，重点观察代码语义还原、多步推理、严格格式输出的完成率，并对同一提示多次采样观察稳定性。

十、上下文与显存预算评测

容量预算的基本关系：

峰值占用 ≈ 权重体积 + KV Cache + 计算/激活缓冲 + 运行时开销

据公开记录推算，KV Cache 与上下文长度呈线性关系：未量化 KV 约 64KB/词元，8bit 量化 KV 约 32KB/词元。对应 16K 上下文约需 1GB / 0.5GB，256K 上下文约需 16GB / 8GB。

评测方法：从 4K 开始逐级递增上下文，记录 OOM 临界点、速度衰减曲线与 TTFT 变化；同时确认长上下文的实现方式（是否使用窗口化、分层缓存或稀疏注意力）及其对召回质量的影响。工程上，超长上下文通常需要配合检索、摘要或分段策略，评测应包含“上下文压缩后任务完成率是否回升”的对照实验。

十一、投机解码的专项评测

需观测的指标：接受率、平均每次验证接受的词元数、开启前后的 tps 提升幅度、不同草稿长度下的收益拐点、不同任务类型的差异（代码、数学与高度结构化文本通常接受率较高，开放式创作与低频领域词接受率较低）。

注意事项：报告速度时必须声明是否开启；草稿长度增大并不必然更快；开启后应与关闭时对比输出质量，确认输出分布未发生实质性偏移。

十二、稳定性、安全、易用性与运维

稳定性：连续运行下的性能衰减、温度与功耗墙导致的降频、显存碎片、超长会话的内存增长、异常输入（超长文本、非法编码、二进制内容）的容错、并发下的延迟抖动。记录错误率、恢复时间与 P99 延迟比记录峰值 tps 更有决策价值。

安全：推理服务默认往往不带身份认证，不应绑定到公网可达地址。应启用访问控制与调用方配额、对提示词与生成内容做日志脱敏（其中常含敏感信息）、校验模型文件来源与完整性。本地化部署只解决数据边界的一部分问题。

易用性与可观测性：参数是否可解释、启动失败原因是否可读、服务是否输出来源指标（词元计数、prefill 与 decode 耗时分解、KV 与显存占用）。缺少这些指标，性能问题只能靠猜。

十三、成本结构与选型建议

成本应拆为：硬件一次性投入、电力与散热、人力（调参、运维、版本升级）、迁移成本（量化转换、格式适配、接口改造），以及与云上按量推理的机会成本——利用率长期偏低时自建更划算，负载波动大时按量更灵活。此处只做结构拆解，不涉及具体价格。

条件化建议：

• 先用容量判定可行性（目标量化档 + 目标上下文是否装得下），再用带宽判定速度是否达标；
• 交互式编码与长文分析场景，优先保证中高档量化 + 足够带宽，低档仅作兜底并完成任务抽检；
• 需要 256K 级上下文时，显存容量与 KV 量化是前提，先测出拐点再谈可用性；
• 多用户共享场景关注并发吞吐与 P95 延迟，而非单请求峰值；
• 边缘与轻薄设备优先降低模型规格（同系列轻量推理优化版本），而非在原规格上硬撑；
• 采购前用同规格样机完成不少于 2 小时的实测，不要采信单一社区数值。

十四、风险与限制

样本偏差（单点记录不代表普遍水平）、不可复现（引擎、后端与版本持续漂移）、外推风险（核数线性、跨代平台对比）、量化质量与任务分布不匹配、环境干扰（温度、功耗墙、后台进程）、长期运行衰减，以及口径不一致（词元计数方式、是否含首字延迟、是否流式）。任何 tps 数字都应附带这些条件才可引用。

十五、结论

评测本地运行约 270 亿参数模型，可以归纳为四句话：以容量定可行性，以带宽定速度，以任务抽检定质量，以长时运行定稳定性。带宽受限决定了速度上限的量级，量化档位在速度与质量之间做交换，上下文与 KV Cache 决定容量的实际边界，而投机解码与批处理策略决定最终能逼近上限多少。

最有价值的产出不是某一个 tps 数字，而是一套可复现的评测模板：固定的样本集、统一的计数口径、完整的条件记录、条件化的结论。建立这套模板之后，无论是更换硬件、升级引擎版本还是切换量化档位，都能快速判断变化是否真正带来收益。