每当人们谈起NVIDIA DGX Spark，首先想到的往往是两件事。第一是它的核心规格：一台售价约4,000美元的桌面级设备，却配备了128GB的统一内存。即使在两年前，这样的配置也让人难以置信。第二是设备背面的200GB网络接口。桌面设备上拥有真正的数据中心级网络架构，这才是真正吸引人的地方，因为它不仅仅意味着一台速度更快的单机工作站，更意味着可以连接多个Spark服务器并进行物理复制，这种多节点部署方式过去只能在机架中实现。
本次评测旨在考察该能力。我们对所有三个 OEM Spark 实现（均基于 200 Gb 的互连网络）进行了分布式推理基准测试，测试对象包括我们手头的三个 OEM Spark 实现，并将它们两两配对组成双节点集群。测试涵盖了不同的模型变体和三种工作负载类型。此外，我们还特意采用了一种不同于 NVIDIA 默认建议的模型分配方法，并用数据加以论证。不过，在此之前，有两个关键因素会影响后续的讨论：首先是实现集群的网络，其次是用户可能选择或不选择使用集群的原因。
200 GB Fabric
我们在之前的 DGX Spark 评测中详细介绍了网络实现，但基本原理值得重申，因为本次评测的所有内容都基于此。每台 Spark 的背面都配备两个 QSFP56 插槽，由集成的 NVIDIA ConnectX-7 智能网卡驱动。理论上，这两个插槽可提供 400Gb 的总连接容量，但 PCIe 才是真正的瓶颈：ConnectX-7 位于两条 Gen5 x4 链路之后，无论插槽如何连接，该平台的可用带宽上限均为 200Gb。单个 QSFP56 插槽即可提供设备支持的全部 200Gb 带宽，因此第二个端口的作用更多在于拓扑结构的灵活性，而非额外的吞吐量。
这种灵活性体现在三种常见配置中。最简单的配置是使用一个 200 Gb 端口作为 Spark 之间的直接链路，NVIDIA 验证的双节点设置就采用了这种配置，这也是我们本次评测所使用的配置。第二种配置是使用两个 100 Gb 端口在 Spark 之间建立环形拓扑结构，无需交换机即可实现集群。第三种配置是角色分离配置，其中一个端口连接到用于集群的对等 Spark，另一个端口连接到通过 NVMe-oF 协议传输的高速存储设备，这种配置在工作数据集无法放入 Spark 内部 NVMe 存储时非常有用。
NVIDIA 销售的 Spark 提供三种配置，分别对应不同的网络使用场景。单 Spark 适用于个人桌面工作；经过验证的双 Spark 集群通过 200 Gb 的互连架构直接连接，适用于扩展型机型；而今年 GTC 大会上，NVIDIA 还公开展示了四节点配置，以响应用户突破双节点限制的需求。双 Spark 配置是 NVIDIA 积极推广的配置，也是大多数读者实际部署的配置，我们认为它代表了该硬件在生产级推理方面的合理上限。本次评测也正是基于此配置进行端到端基准测试。
为什么首先要使用集群火花？
Spark集群的显而易见的优势与其他任何集群一样：一台128GB的服务器无法容纳所有重要的模型。将一个120亿参数的模型扩展到两台服务器上，可以运行一些原本无法处理的工作负载。这是Spark集群最主要的用例，也是演示最多的用例。
不太明显的原因，但对于NVIDIA在该平台上的实际客户群来说，或许更为重要，那就是学习。NVIDIA将Spark定位为入门级产品。 官方文件示例笔记本和合作伙伴手册将这套设备视为教学工具。它们提供了一流的指南，涵盖了从在本地聊天界面后启动预构建模型、到针对托管端点运行编码助手、再到微调小型模型以及使用 PyTorch 和 JAX 构建端到端应用程序等方方面面。其理念是，即使是从未编写过 CUDA 内核的人，也能在周末内从零开始搭建一个可用的 AI 工作流程。对于非机器学习领域的工程师来说，如果他们想要一个完全可控的独立沙箱环境，也能轻松实现。双 Spark 集群将教学范围扩展到了多节点领域：同一个人现在还可以学习张量并行、流水线并行和集体通信库的实际运行方式，并且该网络足够真实，能够暴露真正的瓶颈。
然而，NVIDIA 自身的产品定位中却明显缺少了“Spark 适用于生产级推理服务”这一说法。过去几年，Jensen 几乎在每次主题演讲中都谈到了软硬件协同设计，而这一原则同样适用于 Spark。每个 NVIDIA 平台都针对特定的工作负载进行了优化，Spark 针对的是独立的探索和学习，而非流量服务。我们之前的 Spark 评测已经表明，该平台在大多数推理任务中都严重受限于内存带宽，而一旦进行集群，网络带宽的限制就会更加明显。虽然 200 Gb 的单条链路对于桌面级来说已经相当不错，但与单个机箱内的 PCIe Gen5 x16 连接相比，速度明显更慢。在数据中心 GPU 之间通过 NVLink 桥接流畅的集体通信模式，一旦迁移到 200 Gb 的网络架构，就会产生明显的延迟损失。
这正是NVIDIA长期以来将官方支持的配置限制在两台Spark的真正原因，也是GTC大会上四台Spark的演示是为了响应用户需求而非产品自然扩展的原因。软件栈完全可以运行在四台或八台节点上，许多用户和媒体也发布了更大规模集群的测试结果。但这些实验的性能数据通常并不理想：节点间互连成为主要的性能瓶颈，整体性能急剧下降；此外，对于任何足以支撑集群规模的用户模型，在这些配置的末端，每个用户的吞吐量都可能降至每秒个位数令牌。此时，这套系统实际上更像是一个学习实验室，而非服务平台。
这并非否定Spark集群。Spark集群确实是一种极佳的方式，能够帮助我们培养对分布式推理和训练的直觉，而这种直觉通常需要价值数十万美元的数据中心硬件才能实现。能够在自己拥有的系统上实际观察流水线气泡、全归约瓶颈和并行权衡等问题，其教育价值非常显著。我们原本计划更进一步，在双Spark集群上从零开始训练一个小型1亿参数或小于1亿参数的模型。我们选择的设置尽可能地模拟真实分布式预训练运行的条件，以便准确展示此类集群的适用范围和局限性。目前，由于我们正在处理其他一些您可能已经看到的内容，并且等待新的800Gb实验室核心交换机的光纤到货，该项目暂时搁置。我们预计在实验室搭建完成后会重新开始研究。
接下来将重点介绍双 Spark 配置最适用的用例：对规模足够大、需要两台设备才能运行的模型进行分布式推理，并对我们手头所有三家 OEM 厂商的实现方案进行了基准测试。在给出每个模型的具体数据之前，下一节将解释为什么我们采用流水线并行配置而非 NVIDIA 官方文档通常默认的张量并行配置来报告这些数据。
性能测试
为什么我们报告的是流水线并行，而不是张量并行？
英伟达发布的 DGX Spark 指南 他们的大部分参考资料都依赖于张量并行（TP）来描述如何在两个 Spark 服务器上扩展模型。TP 将每个矩阵乘法运算分配到两个 GPU 上，因此每一层都在两个设备上同时运行，并且在每个注意力机制和 MLP 模块之后，通过 all-reduce 操作将部分结果合并。流水线并行（PP）则采用了不同的方法：它按层将模型一分为二，将前半部分放在一个服务器上，后半部分放在另一个服务器上，然后在它们之间传输激活值。每个请求仍然会流经整个模型，但在任何给定时刻，只有一个服务器在处理给定标记的计算，而另一个服务器则在处理下一个微批次。
权衡的关键在于网络传输的数据量。双 Spark 堆栈通过 ConnectX-7 200 GbE 链路连接两个系统，这条链路对于网络链路来说速度很快，但与单个 Spark 的内存带宽相比却很慢。TP 的 all-reduce 操作在每个 Transformer 层触发两次，因此，一个运行 TP=2 的 80 层模型对于每个输出令牌都会生成 160 次跨盒交换，而每次交换都会阻塞下一次计算。PP=2 则每个令牌只在模型两部分之间的连接处传递一次激活。在延迟不低的 200 GbE 链路上，这种差异会压倒其他所有因素。
我们的 GPT-OSS-120B 测试结果清楚地证实了这一点。除了批处理大小为 1 的情况（此时工作负载过小，无法掩盖两种策略的开销）之外，PP=2 始终领先，并且随着并发量的增加保持领先优势。在 Equal ISL/OSL 工作负载下，TP=2 在批处理大小为 128 时达到 252.01 tok/s，而 PP=2 在相同硬件上则攀升至 554.69 tok/s，优势高达 2.20 倍。Prefill Heavy 也呈现出类似的趋势，PP=2 的最终速度为 310.63 tok/s，而 TP=2 为 164.99 tok/s。Decode Heavy 场景是三种场景中最接近的，但 PP=2 在批处理大小为 8 到 64 时仍然领先，只有在批处理大小为 128 时略微落后，这是因为 8K 的长输出放大了流水线气泡的成本。
TP=2 的确存在一个优势明显的窗口期。在所有场景下，当批处理大小为 1 时，TP 都能带来虽小但切实的优势：在 Equal 场景中为 39.55 tok/s 对比 28.79 tok/s，在 Prefill Heavy 场景中为 37.97 tok/s 对比 29.60 tok/s，在 Decode Heavy 场景中为 39.42 tok/s 对比 30.28 tok/s。由于只有一个请求正在处理，没有第二个微批处理来保持空闲流水线阶段的运行，因此 PP 需要为每一步的空闲槽位付费，而 TP 则可以利用两个 GPU 处理唯一的令牌。NVIDIA 的 TP 指南正是针对这种情况而设计的：交互式单流服务，其中第一个也是唯一一个请求的延迟比总吞吐量更为重要。如果部署真正是聊天式的，每个设备只有一个用户，并且 TTFT 目标很严格，那么 TP=2 是正确的选择，这也与 NVIDIA 对 Spark 的看法一致。
对于大规模服务于基础设施的工作负载，如果采用批量推理和大量并发请求，那么在跨服务器扩展时，管道并行（Pipeline Parallelism）是更合适的选择，尤其是在不使用专家并行（Expert Parallelism）等策略的情况下。200 GbE 网络无法在不造成计算资源闲置的情况下支持管道并行（TP）的逐令牌全归约流量，而一旦批处理大小达到 4 或 8，专家并行（PP）的初始开销就会融入到稳定流中。因此，本文后续部分中每个模型的计算结果均基于 TP=1 和 PP=2 的配置。这种配置能够真实反映双 Spark 部署在实际工作中能够达到的性能水平。
我们特意选择 GPT-OSS-120B 作为 TP 与 PP 对比图表的主角，因为它展现了最大的差距。然而，我们也想说明，并非所有模型都如此，而且这些参数取决于模型的具体参数。BF16 上的 Llama-3.1-8B-Instruct 模型则呈现出更为保守的情况。该模型规模较小，因此每一层的计算速度都很快，TP 的 all-reduce 流量也相应较低。相比之下，PP 的每步协调成本是固定的，与模型规模无关。因此，在几乎整个批次扫描过程中，TP=2 都保持领先。在 ISL/OSL 相等的测试中，TP=2 从批次大小 1（23.2 对 13.4 tok/s）到批次大小 32（388.7 对 349.3 tok/s）都保持领先，仅在批次大小 64（524.8 对 638.2 tok/s）和 128（679.2 对 1,047.1 tok/s）时落后于 PP=2。预填充重型测试也遵循同样的模式，TP=2 在批次大小 32 之前一直领先，之后 PP=2 在批次大小 64 和 128 时反超。解码重型测试的结果最为显著：TP=2 在所有批次大小下都胜出，在批次大小 128 时以 366.7 tok/s 的速度领先于 PP=2 的 330.5 tok/s。
这个反例强化而非否定了其背后的机制。PP=2 只有在批次大小足够大，能够填满流水线并完全摊销气泡成本，且模型本身足够小，使得 TP 的每层全归约成本很低时才能胜出；这个临界点会被进一步推迟。解码密集型测试的结果也与之一致：更长的输出序列意味着更多的解码步骤，更多的流水线气泡需要连续支付，以及 PP 弥补差距的时间窗口更小。换句话说，PP 在批次大小为 128 时在 GPT-OSS-120B 上取得 2.20 倍优势的物理机制，也解释了为什么它在 8B 模型上只在前两个批次大小下胜出，并且从未在解码密集型测试中获胜。
GPT-OSS-120B
在 ISL/OSL 相等的测试中，戴尔的初始速度为 67.06 tok/s，批次大小为 64 时可达 927.93 tok/s。技嘉的初始速度略低，为 65.77 tok/s，但最终以 994.53 tok/s 的成绩收尾，而惠普则以 1,009.75 tok/s 的速度领跑。在整个测试过程中，各厂商之间的差距一直很小，惠普从批次大小 32 开始逐渐领先。
在预填充重型打印模式下，各厂商的吞吐量全面大幅提升。戴尔的吞吐量从 164.42 tok/s 提升至 2,097.80 tok/s，技嘉从 162.96 tok/s 提升至 2,086.72 tok/s，而惠普的表现最为突出，从 165.95 tok/s 跃升至 2,208.16 tok/s。惠普几乎在所有批次大小下都处于领先地位，而戴尔和技嘉的吞吐量则非常接近，尤其是在批次大小为 32 和 64 时。
在解码密集型任务中，整体性能较低，这与解码工作负载的预期相符。戴尔的解码速度范围为 41.20 tok/s 至 563.98 tok/s，技嘉为 40.83 tok/s 至 617.96 tok/s，惠普为 41.63 tok/s 至 593.56 tok/s。技嘉在批处理大小为 64 时表现最佳，惠普在中等性能水平上领先，戴尔紧随其后，但在更高并发量下略逊一筹。
GPT-OSS-20B
在 ISL/OSL 相等的测试中，戴尔在大部分测试中都处于领先地位，其处理速度从批处理大小为 1 时的 88.73 tok/s 提升至批处理大小为 64 时的 1,953.55 tok/s。技嘉紧随其后，处理速度从 88.42 tok/s 提升至 1,904.62 tok/s，而惠普的处理速度则在 83.49 tok/s 至 1,831.45 tok/s 之间波动。戴尔的整体性能保持着最强的高端扩展性，尤其是在批处理大小从 16 开始。
在预填充重载测试中，三款系统的吞吐量均呈现快速增长。戴尔在此测试中表现最佳，批次大小为 64 时，吞吐量从 216.05 tok/s 提升至 4,261.96 tok/s。技嘉紧随其后，吞吐量为 4,011.86 tok/s，惠普则达到 3,785.25 tok/s。在较小的批次大小下，三款系统的性能差距并不大，但从批次大小 16 开始，戴尔开始拉开差距，并在后续测试中保持领先优势。
在解码重任务中，性能提升较为平缓，但在所有平台上均保持强劲势头。戴尔的性能从 54.88 tok/s 提升至 1,173.31 tok/s，技嘉从 55.24 tok/s 提升至 1,181.94 tok/s，惠普则从 53.20 tok/s 提升至 1,082.23 tok/s。在最高批处理大小下，技嘉略胜戴尔一筹，而惠普在高并发级别下则落后于这两家系统。
Llama 3.1 8B 指令基础
在 ISL/OSL 相等的测试中，戴尔在批处理大小为 64 时，性能从 27.69 tok/s 提升至 1,376.38 tok/s，略微领先于技嘉（27.23 tok/s 至 1,372.27 tok/s）。惠普在整个测试过程中略微落后，性能从 26.89 tok/s 提升至 1,235.32 tok/s。在批处理大小为 16 之前，三款系统的性能非常接近，之后戴尔在更高的并发级别下开始略微领先。
在预填充重型打印任务中，随着批次大小的增加，吞吐量显著提升。戴尔的吞吐量从 68.60 tok/s 增长到 2,575.25 tok/s，而技嘉的表现最为出色，在批次大小为 64 时，吞吐量从 67.49 tok/s 提升至 2,694.25 tok/s。惠普的吞吐量达到 2,315.15 tok/s，保持了一定的竞争力，但在较高批次大小下始终落后于戴尔和技嘉。技嘉在高端市场占据领先地位，尤其是在批次大小为 64 或更大时。
在解码重任务测试中，各平台的性能提升幅度保持稳定。戴尔的解码速度范围为 17.19 tok/s 至 726.22 tok/s，技嘉为 16.96 tok/s 至 720.57 tok/s，惠普为 16.79 tok/s 至 663.31 tok/s。在大部分测试过程中，戴尔和技嘉的性能几乎不相上下，仅在并发量较高时戴尔略占优势。而惠普在大批量处理时性能则略逊一筹。
Llama 3.1 8B 指令 FP4
在 ISL/OSL 相等的测试环境中，戴尔在批处理大小为 64 时，性能从 69.71 tok/s 提升至 2,849.20 tok/s，而技嘉略胜一筹，性能从 70.92 tok/s 提升至 2,912.03 tok/s。惠普的性能也保持竞争力，范围在 69.52 tok/s 至 2,821.50 tok/s 之间。这三款系统在整个工作负载下性能表现都非常接近，只有在高并发级别下才出现微小的差距。
在预填充重负载测试中，性能扩展性显著提升，尤其是在较大批次规模下。戴尔的吞吐量从 170.09 tok/s 提升至 4,417.65 tok/s，而技嘉的表现最为出色，在批次规模为 64 时，吞吐量从 173.55 tok/s 提升至 4,767.43 tok/s。惠普的吞吐量也从 170.12 tok/s 提升至 4,214.57 tok/s。技嘉在批次规模达到 32 后开始与其他厂商拉开差距，在该工作负载下实现了最高的吞吐量。
在解码重任务测试中，三款系统在大部分测试时间内性能依然保持接近。戴尔的性能范围为 43.19 tok/s 至 1,260.24 tok/s，技嘉的性能范围为 43.53 tok/s 至 1,258.05 tok/s，惠普的性能范围为 42.54 tok/s 至 1,178.74 tok/s。戴尔和技嘉的性能会根据批处理大小交替领先，而惠普在最大并发量下略逊于这两款系统。
Llama 3.1 8B 指令 FP8
在 ISL/OSL 相等的测试中，戴尔在批处理大小为 64 时，性能从 46.93 tok/s 提升至 2,206.52 tok/s，而技嘉则从 46.16 tok/s 提升至 2,175.44 tok/s。惠普紧随其后，性能从 46.40 tok/s 提升至 2,149.15 tok/s。整个测试过程中，三款系统的性能差距始终保持在较小范围内，在批处理大小达到 32 之前，它们的性能提升表现几乎完全相同。
在预填充重载测试中，随着并发数的增加，吞吐量提升更为显著。戴尔的吞吐量从 115.85 tok/s 增长到 3,794.52 tok/s，而技嘉的整体表现最为出色，在批处理大小为 64 时，吞吐量从 113.34 tok/s 提升至 4,133.76 tok/s。惠普的吞吐量达到 3,624.73 tok/s。技嘉在高批处理大小下，尤其是在批处理大小从 32 开始，优势更加明显。
在解码重载任务中，三款系统在低并发水平下性能接近，但在高并发水平下才出现细微差距。戴尔的性能范围为 29.11 tok/s 至 1,077.07 tok/s，技嘉的性能范围为 28.64 tok/s 至 1,068.92 tok/s，惠普的性能范围为 28.68 tok/s 至 1,000.20 tok/s。戴尔在大部分工作负载下保持着微弱的领先优势，技嘉紧随其后，而惠普在大批量处理时略逊一筹。
米斯特拉尔小号 3.1 24B
在 ISL/OSL 相等的测试中，戴尔在批处理大小为 64 时，性能从 10.41 tok/s 提升至 498.56 tok/s，而技嘉在性能上限略胜一筹，从 9.76 tok/s 提升至 509.18 tok/s。惠普的性能略逊于这两款系统，范围在 9.25 tok/s 至 477.25 tok/s 之间。在整个工作负载范围内，各系统之间的差距始终相对较小，尤其是在中低并发水平下。
在预填充重载任务中，三个系统的扩展性均显著提升。戴尔的性能从 25.91 tok/s 提升至 1,079.19 tok/s，技嘉的性能也从 24.25 tok/s 提升至 1,071.07 tok/s。惠普在批处理大小为 64 时达到了 988.82 tok/s。在大部分测试阶段，戴尔和技嘉的性能几乎不相上下，仅在最高并发级别下戴尔略占优势。
在解码密集型任务中，整体吞吐量仍然显著降低，这与预期相符，毕竟解码工作负载集中在较大尺寸的机型上。戴尔的吞吐量范围为 6.49 tok/s 至 297.82 tok/s，技嘉为 6.10 tok/s 至 297.23 tok/s，惠普为 5.77 tok/s 至 276.55 tok/s。戴尔和技嘉在整个测试过程中表现不相上下，而惠普在大批量处理时始终略逊于这两家系统。
Qwen3 编码器 30B A3B 基地
在 ISL/OSL 相等的测试条件下，戴尔在批处理大小为 64 时，速度从 59.05 tok/s 提升至 817.82 tok/s，而技嘉的速度范围为 59.81 tok/s 至 809.88 tok/s。惠普的性能略逊于这两款系统，速度从 56.51 tok/s 提升至 780.21 tok/s。在大部分测试条件下，戴尔和技嘉的性能几乎完全相同，仅在高批处理大小下出现微小差异。
在预填充重负载测试中，吞吐量随着并发数的增加而显著提升。戴尔的吞吐量从 144.81 tok/s 增长到 1,756.99 tok/s，而技嘉的整体扩展性最强，在批处理大小为 64 时，吞吐量从 147.55 tok/s 增长到 1,862.40 tok/s。惠普的吞吐量达到 1,751.17 tok/s，保持了竞争力，但在高端性能上略逊于其他两款系统。技嘉从批处理大小约为 32 开始建立起一定的领先优势，并在测试的最后阶段保持了这一优势。
在解码密集型任务中，三款系统在大部分工作负载下性能依然非常接近。戴尔的性能范围为 36.69 tok/s 至 427.48 tok/s，技嘉的性能范围为 36.92 tok/s 至 417.42 tok/s，惠普的性能范围为 35.30 tok/s 至 403.32 tok/s。在最大批处理大小下，戴尔略占优势，而惠普在以解码为主的工作负载下略逊于戴尔和技嘉。
Qwen3 程序员 30B A3B FB8
在 ISL/OSL 相等的情况下，戴尔在批次大小为 64 时，吞吐量从 98.65 tok/s 提升至 1,379.26 tok/s，而技嘉的吞吐量范围为 100.20 tok/s 至 1,308.79 tok/s。惠普始终保持竞争力，吞吐量从 97.06 tok/s 提升至 1,354.23 tok/s。惠普在一些中低批次大小下曾短暂领先，但戴尔最终凭借其整体最强劲的高端吞吐量脱颖而出。
在预填充重型打印任务中，三款系统的吞吐量均实现了显著提升。戴尔的吞吐量从 240.43 tok/s 增长至 3,041.72 tok/s，而技嘉的整体表现最为出色，在批次大小为 64 时，吞吐量从 245.92 tok/s 增长至 3,088.62 tok/s。惠普的吞吐量达到了 2,857.80 tok/s。技嘉从批次大小为 4 开始就建立了明显的领先优势，并在整个测试过程中保持了这一优势。
在解码重负载测试中，戴尔的整体高端扩展性最强。戴尔的解码速度范围为 60.91 tok/s 至 705.77 tok/s，技嘉为 61.53 tok/s 至 639.80 tok/s，惠普则从 59.85 tok/s 提升至 635.25 tok/s。惠普在小批量处理时曾短暂领先，但戴尔在高并发水平下更胜一筹，最终以最高的解码吞吐量领跑该组。
双火花塞系统峰值输出概要
下表总结了在戴尔、技嘉和惠普双Spark系统上进行分布式PP=2测试时观察到的峰值令牌输出吞吐量。每个值代表在测试批处理大小下，该工作负载场景所达到的最高测量输出吞吐量（tok/s）。粗体数字表示在该特定工作负载场景中性能最佳的系统。
| 型号 | 场景（BS – 64） | 戴尔峰值输出 | 技嘉峰值输出 | 马力峰值输出 |
|---|---|---|---|---|
| GPT-OSS模型 | ||||
| GPT-OSS-120B | 等同于ISL/OSL | 463.97 吨/秒 | 497.26 吨/秒 | 504.88 吨/秒 |
| GPT-OSS-120B | 预填充重型 | 419.56 吨/秒 | 417.34 吨/秒 | 441.63 吨/秒 |
| GPT-OSS-120B | 解码重 | 451.18 吨/秒 | 494.37 吨/秒 | 474.85 吨/秒 |
| GPT-OSS-20B | 等同于ISL/OSL | 976.77 吨/秒 | 952.31 吨/秒 | 915.72 吨/秒 |
| GPT-OSS-20B | 预填充重型 | 852.39 吨/秒 | 802.37 吨/秒 | 757.05 吨/秒 |
| GPT-OSS-20B | 解码重 | 938.65 吨/秒 | 945.55 吨/秒 | 865.78 吨/秒 |
| 羊驼模特 | ||||
| Llama-3.1-8B-指导 | 等同于ISL/OSL | 689.53 吨/秒 | 687.48 吨/秒 | 618.87 吨/秒 |
| Llama-3.1-8B-指导 | 预填充重型 | 515.45 吨/秒 | 539.27 吨/秒 | 463.39 吨/秒 |
| Llama-3.1-8B-指导 | 解码重 | 581.43 吨/秒 | 576.91 吨/秒 | 531.07 吨/秒 |
| Llama-3.1-8B-FP4 | 等同于ISL/OSL | 1427.39 吨/秒 | 1458.86 吨/秒 | 1413.51 吨/秒 |
| Llama-3.1-8B-FP4 | 预填充重型 | 884.22 吨/秒 | 954.23 吨/秒 | 843.57 吨/秒 |
| Llama-3.1-8B-FP4 | 解码重 | 1008.98 吨/秒 | 1007.23 吨/秒 | 943.73 吨/秒 |
| Llama-3.1-8B-FP8 | 等同于ISL/OSL | 1105.42 吨/秒 | 1089.85 吨/秒 | 1076.68 吨/秒 |
| Llama-3.1-8B-FP8 | 预填充重型 | 759.50 吨/秒 | 827.40 吨/秒 | 725.51 吨/秒 |
| Llama-3.1-8B-FP8 | 解码重 | 862.33 吨/秒 | 855.81 吨/秒 | 800.78 吨/秒 |
| Mistral 和 Qwen 模型 | ||||
| 米斯特拉尔-小型-3.1-24B | 等同于ISL/OSL | 249.77 吨/秒 | 255.09 吨/秒 | 239.09 吨/秒 |
| 米斯特拉尔-小型-3.1-24B | 预填充重型 | 216.01 吨/秒 | 214.38 吨/秒 | 197.92 吨/秒 |
| 米斯特拉尔-小型-3.1-24B | 解码重 | 238.44 吨/秒 | 237.97 吨/秒 | 221.41 吨/秒 |
结语
本轮测试中最有价值的发现与哪家OEM厂商在哪项工作负载下表现更佳关系不大。在我们测试的所有型号和工作负载类型中，戴尔、技嘉和惠普的三款Spark产品性能相差无几。在特定批次规模下，各平台略有优势，但没有哪款平台完全胜出，也没有哪款平台始终落后。因此，消费者在三款产品中做出选择时，应该更多地考虑机箱设计、散热性能、保修条款和售后支持，而不是基准测试的差异。因为基准测试的差异更接近于任何桌面级系统在持续负载下运行时的波动。
更有趣的结果在于方法论层面。在连接两台 Spark 的 200 GbE 网络上，张量并行和流水线并行之间的选择比三家 OEM 厂商之间的任何差异都更为重要；对于任何合理并发量的批量推理，流水线并行都是更佳选择。TP=2 的每层全归约流量无法在 ConnectX-7 链路上传输而不导致计算资源闲置，而 PP=2 的流水线气泡成本会在批次填满流水线后立即摊销到稳定流中。NVIDIA 的文档默认使用 TP 是有充分理由的：他们将 Spark 的主要定位放在具有严格 TTFT 的交互式单流服务上，而这正是 TP=2 完全胜出的唯一场景。一旦工作负载看起来像是服务基础设施而不是聊天界面，情况就完全相反了。
这种反转强化了 Spark 的本质和非本质特征。双节点 Spark 集群是一个开发和学习平台，它允许单个工程师在足够快的网络环境下直接观察分布式推理行为，该网络速度足以模拟真实的数据中心架构，同时又足够有限，可以暴露生产部署大规模运行时所面临的瓶颈。
更大规模的 Spark 配置值得单独研究，需要针对其规模开发合适的工作负载和并行策略，我们已将这项工作列入路线图。此外，排在本实验之后的下一个实验将从推理转向训练：在双 Spark 集群上从头开始训练一个参数量小于 1 亿的模型，该集群的配置旨在模拟规模更大的系统的分布式预训练条件。由于我们正在等待新的 800 Gb 实验室核心交换机的光纤到位，这项工作暂时暂停，我们预计在新核心交换机上线后发布相关成果。
Amazon