一、评测概述

在端侧设备上运行大模型，吞吐能力是最受关注的指标之一。但“吞吐”一词往往被笼统使用，不同口径下的数据可能相差数倍。本文评测的核心问题不是“某款模型能否跑起来”，而是“在单台笔记本、单张显卡的硬件条件下，大模型推理引擎的吞吐能力如何被准确评估”。通过一组完整实测记录，拆解吞吐构成因子，并解释为什么不同测试方法会得到差异巨大的结论。

本文适合以下读者：

• 正在选型端侧推理方案的开发者；
• 需要对比不同模型压缩格式、推理引擎或硬件配置的技术负责人；
• 对性能测试数据持谨慎态度、希望理解数据背后口径的架构师；
• 从事 Agent 应用或多路并发场景开发的工程师。

二、评测目标

本次评测重点回答三个问题：

1. 端侧单卡推理的极限吞吐由哪些因素决定？
2. 为什么相同的硬件和模型，在不同测试条件下会产出差异巨大的吞吐数据？
3. 如何设计一套可复现、可解释的评测流程，避免被瞬时峰值或错误统计口径误导？

评测不追求“跑出一个好看的数字”，而是希望建立一套区分“极限脉冲”“持续吞吐”“单流体验”的评测语言，帮助研发团队在真实业务场景中合理设定性能预期。

三、评测对象说明

被评测对象可以抽象为以下三部分：

• 端侧推理引擎：一套针对笔记本环境自编译的推理服务，支持多路并发请求调度，并实现了基于草稿（draft）的推测解码加速机制。
• 量化模型：一个参数量约 270 亿的开源语言模型，权重采用 4-bit 浮点量化格式（NVFP4），权重体积约 16.78 GiB，可被装入 24 GB 显存的笔记本显卡。
• 硬件环境：一台搭载 24 GB 显存、显存带宽约 896 GB/s 的笔记本，显卡功耗上限被限制在 95 W（TGP）。该环境代表当前高端笔记本的典型推理能力，而非数据中心服务器。

评测的核心机制是“草稿深度”。推理引擎可先让模型快速生成草稿 token，再由目标模型并行验证。草稿深度越大，单轮提交的 token 数越多，但也会引入额外的计算成本。如何选择合适的草稿深度，是吞吐优化的关键。

四、评测维度设计

端侧推理吞吐评测不能只看单一数字，至少需要覆盖以下维度：

维度	说明	为什么重要
聚合吞吐	多路并发下，引擎整体每秒生成的 token 数	反映系统整体处理能力，是资源利用率的直接体现
单流吞吐	单条请求的生成速度	反映用户体验，尤其在交互式场景中至关重要
峰值窗口	短时间窗口内的瞬时最大吞吐	用于理解引擎的脉冲能力，但不能代表持续性能
接受率	草稿 token 被验证通过的比例	影响实际有效提交 token 数，是推测解码的核心指标
稳定性	长时间运行或多轮请求后吞吐是否衰减	避免因功耗墙、缓存失效等因素导致性能高开低走
资源消耗	显存占用、功耗、温度变化	笔记本场景下直接决定能否持续运行

五、评测环境与前提

为了保证评测结果可解释，必须在固定前提条件下进行测试：

• 硬件与模型固定：同一台笔记本、同一张显卡、同一个模型权重文件。任何硬件或模型变化都会导致数据不可对比。
• 引擎版本固定：同一套自编译推理服务。不同版本可能改变调度策略、kernel 实现或内存管理，结果差异可能非常大。
• 并发路数明确：并发路数是引擎的设计上限，需要预先确认。例如实测案例中引擎硬上限为八路，超过该路数需要修改底层调度逻辑。
• 请求内容特征：吞吐与输入内容的可预测性高度相关。代码补全、自然语言对话、结构化模板等不同内容，会直接影响模型对草稿的接受率。
• 统计口径一致：必须区分“5 秒窗口峰值”“端到端平均吞吐”“单流吞吐”等概念，并在报告中标注清楚。

六、评测方法

完整评测流程建议分为以下步骤：

1. 建立基线

在单路请求下测量基础吞吐和首 token 延迟，作为后续所有对比的基线。此时不存在并发干扰，能够反映引擎单流处理能力。

实测基线数据：单流吞吐约 325.4 token/s。注意该数据与草稿深度、内容可预测性相关，不能直接推广到所有模型。

2. 调节草稿深度

分别设置草稿深度为 6、8、15，保持并发路数和请求内容不变，观察端到端吞吐变化。草稿深度并非越大越好。在普通内容（如混合代码与自然语言）上，草稿深度 15 可能不如 6 或 8；而在高度模板化、可预测的内容上，深度 15 可以显著提升吞吐。

关键发现：在八路并发条件下，将草稿深度从 8 提升到 15，端到端吞吐从约 858.5 token/s 提升到 1302.9 token/s。这说明草稿深度是影响聚合吞吐的最敏感参数之一。

3. 并发路数压测

从一路开始逐步增加并发请求数量，记录每路请求的延迟、聚合吞吐以及显存/功耗变化。实测中，八路并发达到引擎设计上限。继续增加并发需要修改底层调度回放的行数几何，说明硬件资源对并发路数存在硬约束。

注意：并发路数越高，单流延迟会相应增加。需要综合考虑聚合吞吐与业务对延迟的容忍度。

4. 内容可预测性测试

设计多组不同内容的请求样本：

• 高度可预测的模板内容（如重复固定结构）；
• 包含明确数量约束的指令（如“生成 10 条”）；
• 自由形式的自然语言对话；
• 代码补全任务；
• 字母重复类特殊输入。

在相同参数下分别测量接受率。实测结果显示，接受率并非由内容“是否可预测”简单决定。例如，仅重复单个字母 “a” 的内容，由于输出存在 stop token 约束，接受率反而很低；而带有明确数量要求的 prompt，哪怕内容并不简单，也能获得接近 99.9% 的接受率。这一结论颠覆了“内容越模板化，接受率必然越高”的直觉。

5. 功耗与稳定性监控

记录连续运行过程中的 GPU 功耗、温度与吞吐曲线。笔记本场景下，功耗墙往往比散热更能限制性能。实测中，默认功耗档位下八路并发吞吐仅约 580 token/s；而在手动解除功耗限制后，同一环境可达到更高的持续吞吐。因此，评测报告中必须包含功耗设置这一关键变量。

6. 错误统计口径排查

检查测试脚本中的分母和计时方式。需要确认：

• 请求实际耗时是完整的首 token 到最终 token 的耗时，还是包含了排队等待时间？
• 并发窗口是固定时长，还是等待所有请求完成？
• 瞬时峰值是否被当作持续吞吐使用？

实测过程中曾经出现过两处统计错误：一处将标称时长（12 秒）误当作实际耗时（实际请求跑了 29 至 103 秒），导致计算出的“八路 1200/1269”远高于真实值 489.6；另一处将 5 秒窗口的瞬时值直接当作持续吞吐，得出“八路 780”的虚高数据。这些例子说明，相同的日志如果统计口径不同，可能得出数倍差异的结论。

七、结果解读

1. 极限吞吐的三因子模型

端侧推理引擎的吞吐量可以拆解为三个因子：

聚合吞吐 ≈ 并发路数 × 每轮提交 token 数 × 轮速

其中：

• 并发路数：引擎同时处理的请求数量，受限于显存、调度器设计和底层实现；
• 每轮提交 token 数：草稿深度 × 接受率。草稿深度越高，单轮可验证的 token 越多；接受率越低，无效计算越多；
• 轮速：每秒能执行多少轮草稿生成与验证循环，受限于 GPU 计算能力、显存带宽和功耗墙。

实测中，并发路数为八路，草稿深度为 15，接受率高达 99.9% 时，引擎在 5 秒窗口内的峰值达到 1508 token/s，端到端平均为 1302.9 token/s。而将草稿深度降低到 8 时，端到端降至 858.5 token/s。峰值的三个因子都已经接近当前硬件与引擎的极限，进一步提升的空间不大。

2. 为什么草稿加深反而更快

理论上草稿深度增加后，验证阶段的计算量会线性增加，单次请求的延迟应该变差。但实测并非如此。原因在于，草稿更深时，单个请求的 Materialized 慢路径固定开销会增大，但在多路并发下，这个固定开销被 batch 维度摊薄，单位 token 成本反而下降。也就是说，相同硬件条件下，并发路数越多，越能掩盖慢路径带来的额外成本。

3. 接受率才是关键杠杆

接受率从 84% 提升到 99.9% 能大幅提升吞吐，但这与内容是否“简单”没有必然关系。实测表明，prompt 中写死数量要求（如“列出 5 个要点”）能够显著提升接受率，因为输出长度和结构更容易被草稿精准预测。相反，看似简单的重复字符任务，可能因为模型必须输出特殊终止 token 而导致草稿验证失败。

八、适用场景分析

不同业务场景对吞吐和延迟的敏感度不同，应关注不同的指标组合：

场景	重点关注指标	评测验证重心
单用户对话	单流吞吐、首 token 延迟	在低并发下验证模型生成速度是否满足交互等待
多 Agent 协作	聚合吞吐、并发稳定性	重点测试多路并发时的吞吐衰减和资源争抢
代码补全 IDE 插件	首 token 延迟、接受率	使用真实代码片段测试，关注草稿深度对代码结构的适配度
批量离线生成	端到端吞吐、成本	可接受较长延迟，重点测试最大化吞吐时的功耗和稳定性
笔记本移动办公	功耗、温度、续航	在电池供电和不同功耗档位下分别测试

九、风险与限制

• 数据样本偏差：吞吐数据高度依赖请求内容。不可预测的自由对话无法达到高接受率，因此“极限吞吐”只能在特定 prompt 设计下复现，不能代表真实业务。
• 硬件平台限制：不同显卡的显存带宽、算力和功耗设计差异巨大。本文描述的环境代表高端笔记本，不能外推到桌面级 GPU 或云端实例。
• 瞬时峰值 vs 持续吞吐：峰值数据用于理解引擎能力上限，但部署到生产环境时，应以持续吞吐和长时间稳定性为准。
• 引擎实现差异：自编译推理引擎的调度策略、kernel 优化和内存管理方式直接影响结果。换用其他引擎可能导致完全不同的数据和最优参数。
• 功耗墙的不确定性：笔记本功耗管理策略可能随温度、负载变化自动调节。评测时需固定功耗档位，否则数据不可复现。

十、选型与使用建议

1. 不要只看单一峰值。至少同时记录峰值窗口、端到端平均、单流吞吐和接受率，才能形成对引擎能力的完整判断。

2. 根据内容特征调参。如果业务内容高度模板化（如 JSON 结构化输出、固定列表生成），可以适当增大草稿深度；如果内容自由度高（如开放式聊天），草稿深度不宜过大，否则验证成本可能超过收益。

3. 重视功耗设置。笔记本场景下，TGP 限制是影响吞吐的最大瓶颈之一。如果追求持续性能，需要明确测试时是否解除功耗墙，并将其作为部署配置的一部分。

4. 排查统计口径。对所有吞吐数据，必须确认计时起点、并发窗口、请求完成判据。统一口径后再做方案对比，否则可能出现数倍误差。

5. 以场景验证收尾。最终选型应使用真实业务样本进行回归测试，记录 p50/p95 延迟和聚合吞吐，并预留 20% 以上的性能余量。

十一、总结

端侧大模型推理吞吐是一个多因子耦合的系统性问题，评测时不能只记录一个数字。本文通过一组笔记本单卡实测案例，拆解了并发路数、草稿深度、接受率和功耗墙之间的关系，并强调了统计口径对结果的决定性影响。读者在评估类似系统时，应当采用本文提出的评测框架：固定环境变量、区分峰值与持续吞吐、围绕内容可预测性设计测试样本、确认脚本统计口径，最终基于真实业务场景选择合理配置。

评测的最终目的不是验证一个数值，而是建立对系统行为深层的理解和边界感。只有这样，才能在模型迭代、硬件升级或引擎更换时，快速判断新方案是否真正适合自己的业务负载。