分布式推理性能评测：加速器与通信优化方法

一、评测概述：为什么要评估分布式推理性能

在大规模模型推理场景中，性能并不是单一计算单元“算得快”就能决定的。尤其当模型规模超过单张加速器显存容量，需要跨多张加速器、多台服务器进行分布式部署时，端到端性能会同时受到模型并行策略、显存带宽、加速器间互联、节点间网络、缓存传输、批处理调度、请求长度分布和框架实现效率等多因素影响。

因此，评估分布式推理能力时，不能只看某一次测试脚本输出的峰值数字，也不能只依赖短期、低负载、单请求场景下的“快照性能”。更合理的做法是建立一套可复现、可解释、可映射到生产环境的评测方法。本文所讨论的评测对象，是加速器集群或云化环境中的大规模模型分布式推理能力，重点关注预填充吞吐、解码时延、通信开销、互联效率、稳定性以及整体部署成本。

通过本文，读者可以明确以下问题：分布式推理性能应该评测哪些维度、如何设计测试负载、如何建立基线、如何解读吞吐与时延指标、如何判断优化是否真正改善生产体验，以及在什么条件下某项优化收益最明显。

二、评测目标：不是判断“好不好”，而是判断“在什么场景下更好”

分布式推理评测的核心目标，不是简单给出一个“强”或“弱”的结论，而是回答以下具体问题：

1. 性能提升是否可复现：优化后的吞吐、时延和稳定性是否能够被重复验证，而不是依赖特定脚本、特定时间点或特定缓存状态。
2. 是否缓解预填充瓶颈：对于长输入、大上下文、多轮请求等场景，预填充阶段往往是端到端时延的主要瓶颈。评测需要验证并行结构、计算调度和通信优化是否真正降低预填充开销。
3. 是否改善通信效率：分布式推理中，张量并行、专家并行、流水线并行以及缓存传输都会引入通信。评测需要判断通信是否与计算重叠，通信气泡是否减少，网络利用率是否提升。
4. 是否改善交互体验：对于在线推理服务，用户感知通常来自首 token 时延、token 间时延、输出速率和长请求稳定性，而不仅是平均吞吐。
5. 是否具备生产可用性：包括长时间运行稳定性、异常恢复能力、可观测性、资源利用率、运维复杂度和成本可控性。
6. 是否适配目标业务：不同业务对短请求、长上下文、高并发、低时延、批量离线推理的要求不同，评测结论必须结合场景解释。

三、评测对象说明：分布式推理中的关键系统能力

本文讨论的评测对象，是加速器集群上运行大规模参数模型时的分布式推理系统。该类系统通常需要解决以下工程问题：

• 模型切分与并行执行：当模型参数、激活值和 KV 缓存超过单卡容量时，需要使用张量并行、流水线并行、专家并行等方式拆分模型。
• 通信与计算协同：分布式执行会引入节点内互联、节点间网络传输、缓存同步、专家分发与聚合等通信操作。
• 预填充与解码差异：预填充阶段处理较长输入，通常计算密集；解码阶段逐 token 生成，更依赖显存带宽、缓存访问和低时延调度。
• 多租户与并发服务：在线服务通常需要支持多请求并发、批处理、流式输出和优先级调度。
• 成本与资源效率：大规模推理部署中，加速器利用率、网络带宽利用、显存占用和请求排队情况都会直接影响单位请求成本。

在上述背景下，一些优化方向值得重点评测，例如并行结构重构、通信与计算重叠、低时延通信底座、自适应内核选择、统一流量控制以及缓存传输优化等。这些能力本身并不是单一“功能点”，而是会共同影响端到端吞吐、时延和稳定性。

四、评测维度设计：从功能、性能到成本的系统框架

为了避免评测结论片面，建议从多个维度建立指标体系。下表给出一个通用评测框架。

评测维度	关注问题	可观察指标	验证方法
功能完整性	是否支持典型推理流程	模型加载、批处理、流式输出、错误恢复是否可用	功能冒烟测试、流程验证
有效性	输出是否符合预期	响应正确性、任务完成率、格式符合度	固定输入样本回归测试
性能表现	吞吐、时延、并发能力	首 token 时延、token 间时延、每秒 token 数、每加速器吞吐	压测、基线对比、多并发扫描
预填充能力	长输入处理是否高效	预填充吞吐、首 token 时延、长输入请求耗时	不同输入长度对比测试
通信效率	分布式通信是否成为瓶颈	通信占比、网络带宽利用率、节点间时延、重叠比例	分阶段计时、通信与计算对照分析
稳定性	长时间运行是否可靠	错误率、崩溃次数、延迟抖动、资源泄漏	长时压测、异常注入
可扩展性	增加资源是否带来收益	扩展效率、吞吐变化、通信开销变化	单节点、多节点、多集群对比
兼容性	是否适配现有系统	框架、驱动、网络、数据格式、调度系统兼容性	环境适配测试
易用性	部署和调试成本	配置复杂度、日志清晰度、问题定位速度	人工操作评估
安全性	是否满足安全要求	鉴权、权限、隔离、传输加密、审计能力	安全检查、权限验证
可观测性	问题是否容易定位	日志、指标、追踪、告警完整性	监控面板、链路追踪验证
成本结构	是否经济可控	资源利用率、单位请求成本、运维投入	资源账单模拟、容量规划分析

其中，性能维度尤其需要避免只看平均吞吐。对于在线推理，建议至少观察以下指标：

• 首 token 时延：反映用户发出请求后多久看到第一个输出，是交互体验的关键指标。
• token 间时延：反映生成过程中的稳定性，影响流式输出流畅度。
• 每秒生成 token 数：反映持续输出能力。
• 每秒预填充 token 数：反映长输入处理能力。
• 每加速器吞吐：用于衡量单位硬件资源带来的处理能力。
• P95/P99 时延：反映长尾请求体验，避免只被平均值掩盖。
• 资源利用率：包括加速器利用率、显存占用、网络带宽占用、计算单元利用率等。
• 有效吞吐：在满足时延目标的前提下，系统真正可交付的请求处理能力。

五、评测环境与前提：控制变量是结论可信的基础

分布式推理评测最容易受到环境差异影响。如果硬件、驱动、网络拓扑、模型精度、请求长度分布或框架版本不一致，性能结论可能失去可比性。因此，评测前必须明确以下前提。

1. 硬件环境

需要记录加速器的显存容量、计算能力、节点内互联方式、节点间网络带宽、网络拓扑和交换机结构。不同互联结构会显著影响张量并行、专家并行和缓存传输的效率。若评测目的是比较优化前后差异，应确保硬件环境一致或至少具备同代同规格条件。

2. 软件环境

推理框架、通信库、驱动、固件、编译器、容器运行环境和系统内核版本都可能影响性能。建议固定软件栈版本，并在评测记录中明确版本信息。对于通信优化类能力，尤其要关注远程直接内存访问、共享内存传输、节点间消息传递等底层路径是否稳定。

3. 模型与精度设置

模型规模、并行策略、量化精度、KV 缓存配置、批处理策略和上下文长度都会影响结果。例如，FP8、INT8、BF16 等不同精度在计算和带宽消耗上存在差异；不同输入输出长度组合会改变预填充与解码阶段的比例。

4. 负载设计

建议至少覆盖以下几类负载：

• 短输入短输出：验证低并发场景下的响应速度和调度开销。
• 长输入短输出：验证预填充能力和长上下文处理能力。
• 短输入长输出：验证解码阶段吞吐、缓存访问和持续生成能力。
• 长输入长输出：验证混合压力下系统稳定性。
• 混合并发：模拟真实在线业务中不同长度请求混合到达的情况。

5. 基线建立

评测应建立至少三个基线：

1. 优化前的基线版本；
2. 仅开启基础并行能力的版本；
3. 优化后版本。

只有在相同或相近条件下对比，才能判断优化带来的真实收益。同时，应记录基线运行时的错误日志、资源使用和时延分布，避免只保留最优结果。

六、评测方法：从功能验证到压力测试的完整流程

一个可复现的分布式推理评测流程，通常包括以下步骤。

第一步：明确评测问题

在开始压测前，需要先明确评测要回答的问题。例如：

• 优化是否主要改善预填充？
• 优化是否降低首 token 时延？
• 优化是否提升高并发吞吐？
• 优化是否降低通信气泡？
• 优化是否改善长上下文稳定性？
• 优化是否带来资源成本下降？

如果评测问题过多，指标会失控；如果问题过少，又可能遗漏关键风险。因此，建议每次评测围绕一个主目标和若干辅助目标展开。

第二步：准备代表性样本

输入样本应尽量接近业务分布。若无法获取真实业务数据，可以使用合成数据覆盖不同长度、不同并发、不同请求间隔。样本设计应避免单一长度，否则容易得出片面结论。

第三步：执行功能验证

在性能压测前，先确认基本功能可用。包括模型加载、请求提交、流式输出、错误重试、超时处理、批量请求处理、缓存命中和日志记录等。如果功能不稳定，性能数据意义有限。

第四步：建立性能基线

在相同硬件、相同软件、相同模型、相同请求分布下，记录基线版本的吞吐、时延、资源占用和错误率。基线不应只取一次结果，建议多次重复并取稳定区间。

第五步：分场景压测

可按照以下场景逐步加压：

1. 单请求测试：观察最小负载下的响应路径。
2. 低并发测试：观察基础性能和调度开销。
3. 中并发测试：观察批处理收益和缓存复用情况。
4. 高并发测试：观察队列、限流、资源争抢和尾时延。
5. 长请求混合测试：观察预填充、解码和通信交错情况下的稳定性。

第六步：记录过程数据

建议记录每次测试的完整上下文，包括请求时间戳、输入长度、输出长度、开始时间、结束时间、首 token 时间、每个 token 间隔、错误信息、资源利用率和网络状态。若只记录汇总结果，后续很难定位性能波动来源。

第七步：异常与稳定性测试

生产环境不会始终处于理想状态，因此需要模拟异常情况：

• 网络短时抖动；
• 某个加速器或节点异常退出；
• 请求输入超长或格式异常；
• 高并发下缓存压力过大；
• 后台任务抢占资源；
• 依赖服务超时；
• 日志或监控服务延迟。

稳定性评测的关键不是“不失败”，而是失败后能否恢复、是否影响其他请求、是否能定位问题。

第八步：结果汇总与回归

评测结果应形成可对比报告，包括基线、优化版本、指标变化、适用条件和限制说明。对于持续优化的系统，建议将评测脚本纳入回归流程，避免后续版本出现性能回退。

七、示意性评测脚本：如何组织可复现测试

以下是一个通用伪代码示例，仅用于说明测试流程，不涉及任何特定工具或专有接口。

workloads = [
    {name: "short-short", input_len: 512, output_len: 128},
    {name: "long-short", input_len: 8192, output_len: 128},
    {name: "short-long", input_len: 512, output_len: 1024},
    {name: "long-long", input_len: 8192, output_len: 512}
]
concurrencies = [1, 8, 16, 32, 64]
for workload in workloads:
    for concurrency in concurrencies:
        warmup()
        start_test()
        collect:
            request_latency
            first_token_latency
            token_interval_latency
            tokens_per_second
            prefill_tokens_per_second
            accelerator_utilization
            memory_usage
            network_throughput
            error_rate
        stop_test()
        save_result()

在实际执行中，还需要注意测试时长、预热次数、缓存状态清理和请求间隔。若每次测试都依赖相同缓存或相同队列状态，结果可能偏高，不能代表真实生产表现。

八、结果解读：哪些结果说明优化有效，哪些结果需要谨慎判断

1. 预填充吞吐提升的含义

如果某次评测中，长输入场景的预填充吞吐明显提升，且首 token 时延下降，通常说明并行结构重构、计算调度或通信重叠优化开始发挥作用。例如，在某一受控测试中，某类大规模模型在 FP8、8K 输入、1K 输出配置下，每加速器吞吐可由约 2K tokens/s 提升到约 3K tokens/s，并接近或超过约 2.2K tokens/s 的公开基线。

这类结果值得关注，但仍需结合以下条件判断：

• 该提升是否在多次运行中稳定出现；
• 尾延迟是否同步改善；
• 高并发下是否仍然有效；
• 是否以增加显存占用或网络压力为代价；
• 是否只适用于特定输入长度分布。

如果预填充吞吐提升但首 token 尾延迟恶化，说明优化可能改善了平均处理能力，却没有改善用户体验，需要继续分析调度队列和批处理策略。

2. 通信重叠提升的含义

通信重叠优化的价值，在于将部分通信开销隐藏在计算过程中，减少通信气泡。若评测显示通信占比下降、节点间带宽利用率更平稳、端到端时延下降，且计算阶段没有被过度拖慢，则说明重叠策略有效。

但需要注意，通信重叠并不总是越激进越好。如果为了重叠通信而增加同步复杂度，可能导致异常场景下恢复困难。因此，通信优化应与稳定性测试一起观察。

3. 低时延互联与专家并行优化的含义

对于大规模稀疏模型，专家分发与聚合往往带来额外通信。如果评测显示专家并行通信耗时下降、网络争抢减少、节点间带宽利用更充分，且整体吞吐提升，则说明低时延通信底座和统一流量控制具备价值。

此类优化在高并发、多节点、跨网络环境中更容易体现。如果测试环境只有单节点或低负载，收益可能不明显。因此，解读结果时必须说明环境边界。

4. 平均值、分位数与业务体验

性能评测中，平均值容易掩盖问题。例如平均首 token 时延很低，但 P99 可能很高；平均吞吐很高，但部分长请求被长时间排队。对于在线服务，建议同时观察：

• 平均首 token 时延；
• P95 首 token 时延；
• P99 首 token 时延；
• 平均 token 间时延；
• P95 token 间时延；
• 超时率；
• 限流触发率；
• 请求丢弃率；
• 满足服务等级目标的有效吞吐。

只有这些指标综合改善，才能较有把握地判断优化真正提升用户体验。

九、适用场景分析：不同业务应关注不同指标

1. 长上下文问答与文档理解

此类场景输入较长，预填充阶段占比较高。评测应重点关注预填充吞吐、首 token 时延、长请求稳定性、KV 缓存效率和显存占用。若优化主要改善预填充，该场景收益通常较明显。

2. 高并发在线对话

此类场景请求多、输出长度不一，关注点是低时延、批处理效率、队列管理和尾延迟。评测应重点验证中高并发下的 token 间时延、P99 首 token 时延、错误率和资源稳定性。

3. 代码生成与结构化输出

此类场景可能输出较长，且对格式稳定性要求高。评测应关注持续生成吞吐、长输出下的显存变化、输出一致性和超时率。

4. 稀疏专家模型推理

若模型采用专家并行结构，通信开销和流量争抢会更复杂。评测应重点验证专家分发、聚合、跨节点通信、网络优先级和流量控制能力。

5. 离线批量推理

离线批量推理更关注总吞吐和资源利用率，对单次请求时延容忍度较高。评测可使用更大批量、更长时间和更高并发，观察系统饱和后的稳定处理能力。

6. 多租户平台

多租户环境下，除了性能，还要关注隔离性、配额管理、权限控制、日志审计、监控告警和公平性调度。单个租户的压力不应显著影响其他租户。

十、风险与限制：评测结论不能脱离条件

分布式推理评测存在天然复杂性，任何结论都应注明适用条件。常见风险包括：

1. 样本偏差：如果测试请求长度过于集中，可能高估或低估某一优化收益。
2. 环境差异：硬件代次、互联拓扑、驱动版本、网络拥塞情况都会影响结果。
3. 缓存影响：重复测试若未清理缓存，可能得到偏乐观结果。
4. 脚本偏差：某些测试脚本可能只覆盖理想路径，无法反映生产异常。
5. 资源竞争：评测期间若存在其他任务占用网络、显存或计算资源，结果会波动。
6. 长期稳定性未知：短时间压测无法完全暴露内存泄漏、连接堆积、日志膨胀等问题。
7. 业务映射不足：技术指标改善不一定直接转化为业务收益，例如吞吐提升但首 token 时延未改善，对交互式应用意义有限。

因此，评测报告应避免使用“绝对最好”“完全领先”“必然适合所有场景”等表述，而应说明结果成立的条件。

十一、选型与使用建议：基于场景做出条件化判断

在评估某类加速器分布式推理优化能力时，可以参考以下建议：

1. 如果业务以长输入为主，应优先验证预填充吞吐、首 token 时延、KV 缓存传输效率和长请求稳定性。
2. 如果业务以高并发在线交互为主，应重点观察 token 间时延、P95/P99 延迟、队列管理、限流策略和持续吞吐稳定性。
3. 如果模型采用专家并行或稀疏结构，应重点评估专家通信开销、网络争抢、流量优先级和跨节点带宽利用。
4. 如果部署在多个节点或多个集群，应重点关注远程内存传输效率、网络拓扑适配、故障恢复和跨节点可观测性。
5. 如果用于生产云环境，可结合百度智能云通用云服务器、容器平台、负载均衡、监控告警、日志服务等能力，建立环境一致性、可观测性和安全审计体系。
6. 不要只看单次峰值：应建立长期回归测试，观察不同负载、不同时间点和不同版本下的表现。
7. 不要只看吞吐：在线业务应更关注用户感知指标，例如首 token 时延、输出流畅度和错误率。
8. 不要忽略成本：性能提升若伴随显存、网络、运维人力或迁移成本明显增加，需要综合评估总体拥有成本。

十二、总结

分布式推理性能评测的关键，不是寻找一个孤立的“最快数字”，而是建立一套可复现、可解释、可映射到生产业务的评估方法。围绕加速器平台上的大规模模型推理，评测应覆盖预填充吞吐、解码时延、通信重叠、互联效率、专家并行通信、缓存传输、稳定性、可观测性和成本结构。

在结果解读上，应区分平均指标与尾延迟指标，区分理想压测与真实负载，区分单次优化与长期稳定收益。只有当吞吐、时延、稳定性、资源利用和业务体验共同改善时，才能较有把握地认为某项优化具备生产价值。

对于开发者、架构师和运维人员而言，更合理的做法是把分布式推理评测当作持续工程实践：固定环境、明确负载、建立基线、控制变量、记录过程数据，并根据业务场景选择重点指标。这样得到的结论才更接近真实系统能力，也更能支撑部署决策与长期优化。