单卡大模型吞吐实测：极限脉冲与日常边界

一、评测概述

本文评测的对象，是在单卡移动计算平台上运行约 270 亿参数级大语言模型时的推理吞吐表现。评测重点不是简单回答“某台设备能不能跑大模型”，而是回答一个更现实的问题：当一台具备较高图形算力和有限显存资源的移动设备，在运行经过低比特量化的大模型时，它所提供的“峰值吞吐”“持续吞吐”“单流速度”和“多并发聚合速度”分别应该如何理解，以及这些数字在什么条件下才具有参考价值。

这类评测对开发者、算法工程师、架构师、运维人员和需要评估边缘侧推理能力的业务团队都有意义。对于希望验证本地推理可行性的团队来说，单卡设备的成本、功耗、便携性和部署复杂度都具有吸引力；但如果只看一个极高的瞬时吞吐数字，很容易误判实际业务可用性。因此，本文采用评测型文章的写法，把极限数字、统计口径、测试条件、影响因素和适用边界分开说明。

需要特别强调的是，评测不是简单地判断“性能好”或“性能差”，而是要结合具体场景进行条件化判断。例如，交互式对话更关注单流首包速度和持续生成能力；批量摘要更关注聚合吞吐；代码补全和智能体任务则更关注接受率、停止条件和输出稳定性。不同场景下，同一个吞吐数字的意义可能完全不同。

二、评测目标

本次评测主要验证以下问题：

1. 极限吞吐能否复现，以及它的真实含义是什么。
   在某些特定条件下，单卡设备可能出现远高于日常体验的瞬时吞吐数字。评测需要区分“引擎窗口峰值”“请求端到端吞吐”和“真实业务持续吞吐”。

2. 并发、草稿深度和接受率如何影响最终吞吐。
   大模型推理吞吐并不只取决于硬件算力，还会受到并发路数、每轮提交 token 数、草稿接受率、停止条件、量化格式和功耗墙等因素共同影响。

3. 高吞吐是否代表日常可用性。
   本文重点区分“极限脉冲”与“日常吞吐”。如果业务场景中的提示词无法达到高度可预测的输出条件，那么极限数字通常不能直接外推到生产环境。

4. 移动单卡设备是否存在稳定瓶颈。
   除了显存容量，显存带宽、功耗限制、散热条件、驱动版本和推理引擎优化程度都会影响实际表现。评测需要判断瓶颈究竟来自算力、显存、功耗还是软件路径。

5. 如何建立一套可复现的评测口径。
   没有统一口径的性能数字容易误导选型。本文强调应分别记录瞬时吞吐、端到端吞吐、实际耗时、接受率、功耗档位和请求长度等关键指标。

三、评测对象说明

本次评测对象可以抽象为三类组合：

1. 单卡移动计算平台
   该平台具备较高的图形计算能力和较大的显存容量，适合在本地环境运行较大参数规模的模型。其核心限制通常包括显存容量、显存带宽、功耗释放、驱动环境和推理引擎适配程度。

2. 约 270 亿参数级大语言模型
   模型经过低比特量化后，权重占用约为 16.78 GiB。该模型适合在 24GB 左右显存容量的单卡设备上运行，但仍需保留一定空间给 KV 缓存、运行时开销、并发请求和系统进程。

3. 某类自研或深度定制的推理服务引擎
   该引擎支持草稿式并行生成、多路并发、低比特量化权重加载以及多种批处理策略。评测中观察到的许多差异，并不来自硬件本身，而来自引擎内部的解码路径、批处理策略、草稿深度配置和状态重放机制。

这类组合具有代表性：它既不是云端大规模集群部署，也不是低端消费级设备的简单体验测试，而是更接近“高规格边缘设备 + 本地推理服务”的工程化场景。因此，评测不仅要看速度，还要看稳定性、功耗、资源占用、错误恢复和长期运行可行性。

四、评测维度设计

为了避免只看单一吞吐指标，本次评测从以下维度建立评估框架：

评测维度	关注点	验证方式	结果解读
功能完整性	是否支持典型推理流程、并发请求、量化模型加载、停止控制	检查服务启动、请求提交、流式输出、异常停止等行为	功能不完整会限制工程化落地
准确性或有效性	输出是否符合预期，是否受量化、采样参数和草稿深度影响	对比不同采样参数、不同提示词下的输出质量	速度过快但输出不可用没有意义
性能表现	单流速度、多并发聚合速度、端到端吞吐、首包延迟	使用固定输入和固定输出长度进行压测	峰值高不等于持续高
稳定性	长时间运行是否掉速、报错、显存泄漏、请求堆积	连续运行、异常输入、高并发持续请求	稳定性不足会放大运维风险
易用性	配置是否清晰，参数是否可解释，日志是否便于排查	检查启动参数、配置项、日志输出和错误提示	参数不透明会影响调优效率
兼容性	是否能适配常见模型格式、推理接口、监控体系和部署环境	测试模型加载、接口调用、服务集成方式	兼容性差会增加迁移成本
安全性	是否包含鉴权、访问控制、日志审计和数据保护机制	检查服务暴露方式、接口权限、敏感信息保护	本地部署也需避免未授权访问
可观测性	是否记录请求耗时、吞吐、错误率、资源占用、草稿接受率	分析日志、指标和运行监控数据	缺少可观测性会导致误判性能瓶颈
可维护性	是否便于升级、回滚、扩缩容和故障定位	检查版本管理、配置管理、故障恢复流程	可维护性影响长期使用成本
成本结构	设备成本、功耗成本、人力成本、运维成本	评估整机功耗、运行时长、维护复杂度和替代方案	不能只看硬件采购价格
场景适配度	是否适合交互、批量、智能体、代码补全等场景	按业务样本分别测试	不同场景关注指标不同

这一评测框架的核心在于：性能指标必须放在功能、稳定性、功耗和可维护性的约束下理解，否则容易产生片面结论。

五、评测环境与前提

为了保证评测结果可解释，测试前应明确以下环境条件：

1. 硬件条件

   • 单台移动计算设备；
   • 单张高性能图形处理器；
   • 显存容量约 24GB；
   • 显存带宽约 896GB/s；
   • 整机功耗释放约 95W；
   • 本地运行，不依赖外部网络传输。

2. 模型条件

   • 模型规模约 270 亿参数；
   • 采用低比特量化格式；
   • 量化后权重占用约 16.78GiB；
   • 使用相同或相近的推理服务框架；
   • 保持采样参数、温度、停止条件和最大输出长度一致。

3. 推理引擎条件

   • 使用具备并行草稿生成能力的推理服务；
   • 支持多路并发；
   • 支持不同草稿深度配置；
   • 记录引擎内部窗口吞吐和请求端到端耗时。

4. 测试样本条件

   • 包含固定模板任务；
   • 包含普通对话任务；
   • 包含代码补全任务；
   • 包含智能体式多步骤任务；
   • 包含简单重复型输出任务，用于观察极限接受率。

5. 统计口径条件

   • 峰值吞吐：仅统计引擎短时间窗口内的输出速度；
   • 端到端吞吐：总输出 token 数除以请求实际总耗时；
   • 持续吞吐：在真实业务样本下连续运行得到的平均速度；
   • 单流吞吐：并发数为 1 时的输出速度；
   • 聚合吞吐：多路并发时的总输出速度。

如果不明确这些前提，性能数字很容易被误解。例如，5 秒窗口内的峰值吞吐不能等同于请求持续吞吐；而请求实际耗时如果被标称时间替代，也会导致吞吐计算严重失真。

六、评测方法

本次评测采用“控制变量 + 分口径记录 + 场景对照”的方法，具体流程如下：

6.1 建立基线

首先，在相同硬件、相同模型、相同量化和相同推理服务条件下，记录基础运行表现：

• 模型是否正常加载；
• 显存占用是否稳定；
• 单请求是否正常返回；
• 首包延迟是否在合理范围；
• 日志是否完整记录请求开始、结束和错误信息。

基线测试的目的不是追求极限数字，而是确认系统处于可复现、可比较的状态。

6.2 设计测试样本

测试样本应覆盖不同业务特征：

1. 高可预测样本
   用于测试引擎极限。例如，提示词中明确写死输出数量、格式和长度，使模型输出高度可预测。

2. 普通对话样本
   用于观察自然语言交互中的真实吞吐。此类样本的输出长度、停止位置和语义分支更复杂。

3. 代码补全样本
   代码任务通常具有较强的结构约束，但也存在多分支、长上下文和频繁停止条件切换的问题。

4. 智能体任务样本
   多步骤任务会产生大量中间结果和状态变化，对推理服务的稳定性、缓存机制和并发调度要求更高。

5. 异常输入样本
   包括超长输入、极端停止条件、空输出、非法参数和重复循环输出，用于验证容错能力。

6.3 分维度压测

性能测试不应只记录一个平均值，而应记录多个口径：

• 并发数：1、2、4、8 等；
• 草稿深度：不同草稿宽度下的输出表现；
• 每轮提交 token 数；
• 引擎窗口峰值；
• 请求端到端耗时；
• 实际请求运行时长；
• 草稿接受率；
• 显存占用；
• 功耗状态；
• 错误率和重试率。

6.4 示意性评测伪代码

以下伪代码仅用于说明评测思路，不包含任何具体厂商命令或专有接口：

for concurrency in [1, 2, 4, 8]:
    for draft_depth in [6, 8, 15]:
        warm_up(engine, model)
        total_output_tokens = 0
        total_actual_time = 0
        accepted_tokens_list = []
        for request in test_samples:
            start = now()
            response = call_inference_service(
                prompt=request.prompt,
                max_new_tokens=request.max_new_tokens,
                concurrency=concurrency,
                draft_depth=draft_depth,
                stop_conditions=request.stop_conditions
            )
            end = now()
            total_output_tokens += response.output_tokens
            total_actual_time += end - start
            accepted_tokens_list.append(response.accepted_tokens)
        sustained_tps = total_output_tokens / total_actual_time
        average_accept_rate = average(accepted_tokens_list)
        record(
            concurrency=concurrency,
            draft_depth=draft_depth,
            sustained_tps=sustained_tps,
            average_accept_rate=average_accept_rate,
            engine_peak=collect_engine_peak_window()
        )

该伪代码的核心不是调用方式本身，而是强调三个评测原则：

1. 必须使用实际耗时，而不是标称耗时；
2. 必须区分引擎窗口峰值和请求端到端吞吐；
3. 必须记录不同业务样本下的表现，而不是只看单一任务。

七、结果解读

7.1 极限脉冲与日常吞吐必须分开看

在该实测记录中，同一台单卡设备、同一个约 270 亿参数模型、同一套低比特量化方案下，出现了几组差异明显的数字：

测试条件	结果类型	数值表现	解读
八路并发、每轮约 16 个 token、接受率约 99.9%	引擎 5 秒窗口峰值	约 1508 tokens/s	极限脉冲，不宜作为持续吞吐
同条件端到端	端到端吞吐	约 1302.9 tokens/s	仍属于高负载特殊条件
单流输出	单流吞吐	约 325.4 tokens/s	更接近交互式单请求观察
普通多智能体任务	日常八路聚合吞吐	约 465 至 490 tokens/s	更接近真实业务持续能力
默认功耗档位	默认八路表现	约 580 tokens/s	保守条件下的可用参考

这些数字说明：性能结果并不是单一属性，而是条件函数。硬件相同，模型相同，量化相同，但提示词、接受率、并发、草稿深度和功耗档位不同，结果可能相差数倍。

7.2 1508 tokens/s 的构成：三个乘数

极限峰值可以近似拆解为三个因子：

峰值吞吐 ≈ 并发路数 × 每轮提交 token 数 × 轮速

在该记录中：

• 并发路数：8；
• 每轮提交 token 数：16；
• 轮速：约 11.8 轮每秒。

因此，约 8 × 16 × 11.8 的计算结果接近 1508 tokens/s。这说明该数字不是单纯的硬件峰值，而是多个工程条件共同叠加出来的结果。

其中，并发路数接近引擎上限，每轮提交 token 数也接近草稿宽度上限，轮速则受到功耗墙、显存带宽和推理内核效率影响。三个因子都已经处于较紧的状态，因此继续提升空间有限。

7.3 草稿深度提升并不一定线性提升收益

在该评测中，一个关键现象是：产品层默认草稿上限为 8，但底层引擎实际支持的草稿宽度域可以达到 15 + 1 = 16。这意味着如果仅从引擎能力看，草稿深度可以进一步加深。

但草稿深度提升会带来两个复杂影响：

1. 草稿接受率不一定同步提升。
   草稿更深，要求模型在更多位置保持高一致性。如果提示词或任务本身无法提供足够强的可预测性，接受率可能下降。

2. 底层计算路径可能变慢。
   当草稿深度超过某些内部快速路径覆盖范围时，推理引擎可能从快速路径回退到通用物化计算路径。此时单位置成本可能上升。

在该记录中，单流每位置成本从约 0.72ms 上升到约 1.08ms。如果只按单流推算，端到端吞吐似乎只能达到约 752 tokens/s。但实际八路下实测端到端约 1302.9 tokens/s，原因在于：虽然单位置成本上升，但固定开销在更大 batch 维度下被摊薄。八路并发时，每位置成本可降至约 0.47ms。

这个结果说明，单卡推理性能不能只看单个位置的计算成本，还要看批量调度是否充分。固定开销、调度开销和内存访问开销在高并发下可能被部分摊薄，从而改变整体吞吐表现。

7.4 接受率的决定因素不只是“可预测”

一个容易误解的结论是：只要内容足够可预测，接受率就一定很高。该实测指出，接受率并不只取决于语义可预测性，还受到提示词约束、停止条件、输出长度上限和任务结构影响。

在该记录中：

• 通过特定约束构造，接受率可从约 84% 提升到约 99.9%；
• 某些高度简单、重复度高的输出，反而因为停止条件过早触发，只跑到约 6.2%。

这说明，草稿接受率并不是简单的“内容越简单越好”。如果停止条件过早命中，模型还没有完成足够长的输出，实际吞吐仍然会受限。换言之，接受率、停止条件和有效输出长度必须一起看。

7.5 口径错误会显著改变结论

该实测还对常见口径错误进行了更正：

1. “八路 1200 / 1269”的误读
   某些数字曾以标称 12 秒作为分母计算吞吐。但请求实际运行时长为 29 至 103 秒，因此真实值应重新计算，约 489.6 tokens/s。

2. “八路 780”的误读
   该数字可能来自 5 秒窗口内的瞬时值，被误当成持续吞吐。窗口峰值并不等于请求持续能力。

这类错误在性能评测中非常常见。若没有统一口径，很容易把瞬时值、标称值和持续值混在一起，导致选型判断失真。

7.6 草稿深度 15 并不适合所有任务

尽管草稿深度加深可以在特定条件下提升峰值，但边界也很明显：在普通内容上，草稿深度 15 并不一定优于 6 或 8。

原因包括：

• 普通对话输出可预测性不足，接受率可能下降；
• 更深草稿可能增加无效计算；
• 停止条件更容易提前命中；
• 某些任务对输出质量、格式和上下文一致性要求更高，不适合过度追求并行草稿；
• 引擎内部状态重放和调度复杂度上升，可能带来额外不稳定性。

因此，草稿深度并不是越大越好。更合理的做法是：在真实业务样本上分别测试不同深度，观察端到端吞吐、接受率、输出质量和错误率，而不是只追求峰值数字。

八、适用场景分析

8.1 交互式对话

交互式对话更关注单流速度、首包延迟和持续输出稳定性。单流约 325.4 tokens/s 可作为较强观察值，但仍需结合真实提示词长度、上下文长度和输出长度判断。若用户更关注即时反馈，应优先关注首包延迟和单流持续速度，而不是八路峰值。

8.2 代码补全

代码补全通常有较强结构约束，但也会有大量停止条件和上下文分支。评测时应重点观察：

• 草稿接受率是否稳定；
• 停止条件是否过早触发；
• 长上下文下是否掉速；
• 错误输入是否导致服务异常；
• 多并发下是否出现资源争抢。

8.3 智能体任务

智能体任务通常包括多步骤生成、工具调用、状态维护和中间结果拼接。此类任务对持续吞吐、稳定性和可观测性要求更高。日常八路约 465 至 490 tokens/s 更接近该场景的可参考范围。

8.4 批量数据处理

批量摘要、批量分类、批量抽取等任务通常可以接受较高并发。若任务长度可控、输出格式稳定，可以更充分利用八路并发。但仍需关注功耗墙和长时间运行掉速问题。

8.5 边缘或本地部署

本地部署的优势是数据可控、延迟可控、无需外部网络依赖。但需要注意的是，移动单卡设备在功耗、散热、显存容量和持续运行方面存在限制。评测时应重点验证：

• 高温环境下是否掉速；
• 低功耗模式下性能损失是否可接受；
• 长时间运行是否稳定；
• 显存是否足以支持并发和长上下文；
• 服务是否具备必要的安全访问控制。

九、风险与限制

9.1 样本偏差

如果测试样本过于单一，尤其是只使用高度可预测输出，容易得到偏高的吞吐数字。真实业务样本应包含多种长度、多种格式、多种停止条件和多种任务复杂度。

9.2 环境差异

不同环境温度、供电状态、驱动版本、推理服务版本和模型量化方式都会影响结果。因此，评测结论必须绑定具体环境，不能直接外推到其他设备。

9.3 功耗墙影响显著

在该类移动单卡设备中，真正瓶颈可能不是散热，而是整机功耗限制。若功耗档位较低，八路聚合吞吐可能明显下降。默认档位下约 580 tokens/s 的表现，比极限脉冲更接近保守生产条件。

9.4 量化带来的质量风险

低比特量化可以显著降低显存占用，但可能引入输出质量波动。评测不能只看速度，还需要对输出准确性、格式稳定性和业务可用性进行抽查。

9.5 长时间运行不确定性

短时压测无法完全代表长期运行表现。连续运行数小时或数天后，可能出现显存碎片化、缓存膨胀、调度延迟增加或日志堆积等问题。因此，稳定性测试应包含长周期运行观察。

十、选型与使用建议

基于该评测，可以形成以下中立建议：

1. 不要只看峰值吞吐。
   峰值吞吐适合用于验证引擎极限，不适合作为生产容量规划唯一依据。

2. 区分瞬时吞吐和持续吞吐。
   选型时应要求提供持续吞吐、端到端吞吐和实际请求耗时，而不是只给短时间窗口峰值。

3. 以真实业务样本测试。
   应使用接近业务的提示词、输出长度、停止条件和并发模式进行评测。

4. 关注功耗和散热边界。
   移动设备在高负载下可能受到功耗限制，应测试不同功耗档位和长时间运行状态。

5. 验证草稿深度是否适合任务。
   草稿深度并非越大越好。普通对话、代码补全和智能体任务应分别测试。

6. 记录完整评测口径。
   建议记录：并发数、草稿深度、接受率、首包延迟、端到端吞吐、实际耗时、错误率、显存占用、功耗状态和温度状态。

7. 建立可观测性。
   生产环境需要日志、指标和告警。缺少可观测性时，性能问题很难定位和复盘。

8. 保留评测脚本和原始日志。
   性能评测应可复现。脚本、补丁、原始日志和测试样本越完整，结论越可靠。

9. 结合成本综合评估。
   除了设备采购成本，还要评估功耗成本、运维成本、迁移成本、人力成本和长期稳定性成本。

10. 设置业务安全边界。
    如果用于生产服务，应考虑鉴权、访问控制、日志审计、敏感数据保护和异常请求限制，避免本地服务被未授权访问。

十一、总结

该评测的核心结论不是“某台单卡设备能达到某个极限数字”，而是提醒读者：单卡大模型推理性能必须放在真实条件、真实口径和真实业务中理解。

在这套实测中，极限峰值约 1508 tokens/s 是由八路并发、每轮约 16 个 token、约 99.9% 接受率和约 11.8 轮每秒共同构成的特殊结果。它说明引擎在高并发、高接受率和特定输出约束下具备较强的瞬时吞吐能力，但不能直接代表日常业务吞吐。

日常多智能体场景下约 465 至 490 tokens/s，默认功耗档下约 580 tokens/s，以及单流约 325.4 tokens/s，才是更接近不同业务条件的观察值。评测时还需要重点关注草稿深度、停止条件、接受率、功耗墙、显存占用、稳定性和可观测性。

对于希望评估单卡本地推理能力的团队来说，合理的评测路径应当是：先明确业务目标，再选择样本，随后建立基线，分维度记录数据，区分峰值与持续吞吐，最后结合成本、稳定性和可维护性做选型判断。只有这样，性能数字才能真正服务于技术决策，而不是制造误导性的乐观预期。