单机27B稠密模型高吞吐评测指南

一、评测概述

围绕“单机运行约27B参数稠密模型，单流生成速度能达到多高”这一主题，业界经常出现不同口径的讨论：有的强调峰值Token吞吐，有的强调长上下文下的单流表现，有的强调低精度量化后的端到端体验。原始讨论中出现了“75 Token/s”“58.5 TPS”“低于20 TPS”等不同说法，也出现了按带宽与权重大小粗算得到的理论上限。这些数字本身并不能直接构成结论，关键在于它们是否在同一统计口径、同一上下文长度、同一并发条件、同一量化策略和同一质量约束下测得。

本文要评测的不是某一个具体品牌产品，而是“单机约27B稠密模型高吞吐能力”这一类技术命题。读者通过本文可以获得三类判断：第一，如何识别一个高吞吐宣称是否具备可复现条件；第二，如何从性能、质量、稳定性、成本和场景适配等维度建立评测框架；第三，如何解读单流TPS、首Token延迟、长上下文吞吐和批量吞吐之间的关系，避免把不同指标混为一谈。

本文适合开发者、系统架构师、运维人员、技术负责人和企业技术团队阅读。评测目标不是简单判断“快不快”，而是判断在给定硬件资源、模型精度、上下文长度、业务负载和维护成本下，该能力是否能够稳定支撑目标场景。

二、评测目标与核心问题

本次评测建议回答以下问题：

1. 宣称的单流Token吞吐是在什么条件下测得的，是否包含预热、缓存命中、批处理、投机解码、前缀复用或多机并行等影响因素。
2. 单流高吞吐是否以明显牺牲输出质量、长上下文能力、首Token延迟或稳定性为代价。
3. 单机部署约27B稠密模型时，内存带宽、显存容量、KV Cache占用和调度策略是否构成硬约束。
4. 在真实业务输入、长上下文、多并发和长时间运行条件下，吞吐是否仍能保持在可接受范围。
5. 该方案适合交互式问答、离线批量生成、长文档处理还是多租户服务，哪些场景下应谨慎采用。

需要强调，评测不是只追求一个峰值数字。一个方案可能在短输出、空上下文、单请求条件下表现很高，但在长上下文、多并发或持续运行下明显下降。因此，评测必须把“峰值能力”和“可持续能力”分开看。

三、评测对象说明

本文的评测对象可以抽象为“紧凑型单机加速节点 + 约27B参数稠密模型 + 低精度量化或推理优化策略”的组合。其核心问题是：在单机资源受限的前提下，如何通过数值精度压缩、内存访问优化、算子融合、缓存管理、批处理调度等方式提升Token生成速度，同时保持可接受的质量和稳定性。

稠密模型每生成一个Token通常都需要访问大量模型权重。若权重无法完全驻留于更高层级缓存，则单流生成速度会受到显存带宽、权重读取字节数、KV Cache读写和调度开销的共同影响。可以用一个通用上界来理解：

单流TPS理论上界 ≈ 有效内存带宽 / 每Token需读取的等效字节数
每Token等效字节数 ≈ 权重读取开销 + KV Cache访问开销 + 中间激活与调度开销

这个公式并不意味着实测一定低于或高于某个值，而是提醒评测者：当宣称速度显著偏离粗算上界时，必须检查统计口径是否包含了批处理、缓存复用、投机解码、模型结构变化、低精度格式、多机并行或测量误差。

四、评测维度设计

建议从以下维度建立评测框架：

评测维度	关键指标	验证方法	结果解读边界
功能完整性	模型加载、推理、流式输出、长上下文、并发请求	按典型业务流程逐项验证	功能可用不等于性能达标
性能表现	首Token延迟、单流TPS、端到端延迟、批量吞吐、资源占用	固定输入输出长度，分场景压测	必须区分单流与聚合吞吐
准确性/有效性	任务正确性、输出一致性、量化前后差异	使用代表性评测集对比基线	低精度可能影响复杂推理任务
稳定性	长时运行错误率、延迟抖动、内存增长	持续运行与异常注入	短时峰值不能代表长期稳定
易用性	部署步骤、配置复杂度、调试便利性	记录人工操作与排障成本	文档和工具链影响落地效率
兼容性	数据格式、接口规范、现有系统集成	接口联调与回归测试	需验证版本升级后的兼容性
安全性	认证、权限、数据隔离、日志审计	权限边界与敏感数据测试	单机部署同样需要审计能力
可观测性	日志、指标、告警、链路定位	检查关键指标是否可采集	缺少指标会放大运维风险
可维护性	升级、回滚、容量规划、故障恢复	演练升级与故障场景	长稳能力依赖运维体系
成本结构	资源成本、人力成本、迁移成本、能耗	按业务量估算总拥有成本	不能只看单Token峰值成本
场景适配度	交互、离线、长文档、多租户	按场景建立测试矩阵	场景不同，核心指标不同

其中，性能维度需要特别细分。单流TPS只描述单个请求在解码阶段的生成速度；首Token延迟描述用户等待首个输出片段的时间；端到端延迟还包括预填充、排队、网络和输出传输；批量吞吐描述多请求聚合能力。若把批量吞吐误写成单流速度，或者把短输出峰值误写成长期能力，都会导致选型误判。

五、评测环境与前提

评测前必须固定并记录以下条件：

1. 模型版本、参数规模、稠密或稀疏结构、分词器版本和量化格式。
2. 单机还是多机，加速器数量、显存容量、内存带宽、存储类型和网络条件。
3. 输入长度、输出长度、上下文深度、是否启用前缀缓存、是否启用流式输出。
4. 并发数、批处理策略、调度队列长度和请求到达模式。
5. 软件版本、驱动版本、推理框架配置和关键优化开关。
6. 统计口径：是否包含预热、是否只统计解码阶段、是否包含预填充、是否剔除异常样本。
7. 质量基线：高精度基线输出与低精度输出在同一评测集上的差异。

尤其要避免“只测0上下文随机生成”就下结论。短上下文、短输出、重复Prompt和缓存命中会显著放大表面吞吐，但不能代表真实业务。对于长文档、知识库问答、代码生成和多轮对话，应分别设计上下文长度和输出长度组合。

六、评测方法

1. 建立基线

先在不启用额外优化、固定精度和固定并发的情况下记录基线表现，包括首Token延迟、单流TPS、P95延迟、显存占用和错误率。基线的作用是提供可比参照，而不是作为“最优答案”。

2. 控制变量

每次只改变一个因素，例如只改变量化格式、只改变并发数、只改变上下文长度。若同时改变模型、精度、批次和缓存策略，结果无法归因。

3. 设计测试矩阵

建议至少覆盖以下组合：

• 短上下文 + 短输出：观察理想条件下单流速度。
• 短上下文 + 长输出：观察持续解码能力。
• 长上下文 + 短输出：观察预填充和KV Cache压力。
• 长上下文 + 长输出：观察真实长文档场景。
• 单流、低并发、中并发：观察单流速度与聚合吞吐的权衡。
• 缓存开启与关闭：识别缓存复用对结果的放大作用。
• 高精度基线与低精度方案：验证质量与速度的取舍。

4. 记录过程指标

除TPS外，应记录TTFT、TPOT、P50/P95/P99延迟、错误率、超时率、显存峰值、显存增长趋势、加速器利用率和请求排队时间。对于长稳测试，还应记录温度、频率变化和资源回收情况。

5. 异常与长稳验证

通过超长输入、空输入、重复请求、突发并发、依赖服务异常和资源紧张等方式验证容错能力。长稳测试应覆盖数小时甚至更长时间，观察是否存在内存泄漏、性能衰减和错误累积。

6. 伪代码示例

for case in test_matrix:
    warmup(case)
    baseline = run(case, precision=high, cache=off)
    candidate = run(case, precision=low, cache=on)
    for sample in samples:
        record(ttft, tpot, single_stream_tps,
               aggregate_tps, p95_latency,
               memory_peak, error_code)
    check_quality(baseline.outputs, candidate.outputs)
    check_stability(error_rate, memory_growth, latency_jitter)
    report(case, metrics, quality_delta, environment)

七、结果解读

当看到“单机约27B稠密模型单流达到75 Token/s”这类宣称时，应先问四个问题：

第一，是否为单流、单请求、单批次？如果实际使用了批处理或多请求聚合，75可能是聚合吞吐而非单流速度。

第二，是否只统计解码阶段？如果包含预填充或端到端处理，指标含义完全不同。

第三，是否使用了短上下文、短输出、重复Prompt或缓存命中？这些条件会显著降低每Token平均访问开销。

第四，是否改变了模型结构或精度？低精度量化、投机解码、专家路由、缓存卸载等都会改变物理解释。

从技术上看，稠密27B模型在单机单流下达到很高TPS，需要非常高的有效内存带宽、较好的权重驻留、较低的KV Cache开销和高效的算子实现。如果实测值明显高于按带宽与权重规模粗算的上界，就应优先排查统计口径，而不是直接接受结论。反过来，如果实测低于粗算上界，也不一定说明方案差，可能受限于调度开销、长上下文、低并发利用率或软件实现效率。

对于长上下文场景，应重点看上下文深度增加后TPS和首Token延迟如何变化。对于交互式场景，应重点看P95首Token延迟和输出连续性。对于离线批处理，应重点看聚合吞吐、单位任务成本和错误重试成本。对于多租户场景，应重点看隔离性、尾延迟和资源争用。

八、适用场景分析

交互式问答和助手类应用更关注首Token延迟、单流输出速度和P95延迟。此类场景不宜只看峰值TPS，因为用户感知更强的是等待时间和输出是否卡顿。

离线批量生成更关注聚合吞吐、任务完成时间和单位Token成本。此类场景可以接受更高并发和批处理，但需要验证长时运行的稳定性和错误恢复能力。

长文档处理、知识库问答和代码生成更关注长上下文下的显存占用、KV Cache效率和吞吐衰减。短上下文高分不代表长上下文可用。

多租户企业服务更关注权限隔离、日志审计、资源配额、可观测性和运维复杂度。单机高吞吐若缺少隔离与监控，可能在生产环境中放大故障影响。

九、风险与限制

评测结果可能受到样本偏差、环境差异、数据质量、硬件状态、软件版本和负载模式影响。短时测试容易高估真实能力，缓存命中容易高估稳态吞吐，低精度量化可能带来质量风险，长上下文可能带来显存和延迟风险。此外，单机峰值能力不能直接推导出集群化、弹性扩缩容和多租户服务能力。

因此，评测报告应明确适用边界：在何种上下文长度、并发数、输出长度、精度策略和运行时长下成立；超出这些条件时，需要重新验证。

十、选型与使用建议

1. 要求提供可复现的测试卡：模型版本、精度、上下文、输入输出长度、并发数、统计口径、缓存策略和资源监控数据。
2. 同时评估单流TPS、首Token延迟、P95延迟、长上下文吞吐和批量吞吐，不把单一峰值作为选型依据。
3. 对低精度方案进行任务级质量回归，尤其是复杂推理、长文档摘要和代码生成任务。
4. 将长稳测试、异常注入和资源监控纳入验收流程，避免上线后出现性能衰减。
5. 根据业务场景设置权重：交互场景重延迟，离线场景重吞吐，企业场景重隔离与可运维性。
6. 先小规模试点，再根据真实流量调整并发、批处理和容量规划。

十一、总结

单机约27B稠密模型的高Token吞吐评测，本质上是对“性能宣称、物理边界、统计口径、质量约束和场景适配”的综合验证。原始讨论中的75、58.5、低于20等数字，只有在明确模型、精度、上下文、并发和统计方式后才有比较意义。技术团队应建立基线、控制变量、分维度验证，并从结果中识别缓存、批处理、量化、长上下文和调度策略带来的影响。最终结论应是条件化的：在特定资源和业务条件下是否可用、是否稳定、是否值得长期维护，而不是简单判断某个数字“真”或“假”。