The September 16 MLPerf release, covered by Wccftech and documented by MLCommons, spans a far wider range of hardware than the headline race between AMD and NVIDIA suggests. AMD submitted MI355X clusters through Crusoe; NVIDIA entered GB200, GB300 and Vera Rubin NVL72 systems; Intel expanded both Xeon 6 and Arc Pro B70 entries. For organizations running Windows workstations, Linux inference servers, hybrid clusters, or cloud-hosted model serving, the useful takeaway is less “who won MLPerf” than where each result was run, at what scale, and whether the hardware can actually be procured.
MLCommons says version 6.1 drew a record 30 submitting organizations and introduced two workloads intended to make the suite less of a pure accelerator contest: an end-to-end retrieval-augmented generation test and an Edge Agentic Inference test. It also added support for speculative decoding on selected interactive benchmarks. Those changes matter because LLM serving increasingly involves retrieval, reranking, embedding, KV-cache management, orchestration, and networking—not simply generating the maximum number of tokens on an isolated GPU.
AMD’s 512-GPU result is a scale demonstration, not a node-buying guide
AMD’s standout result came from Crusoe’s 512-accelerator MI355X deployment. The system reached 5.75 million tokens per second in the Offline scenario and 5.39 million in Server for GPT-OSS-120B, while its DeepSeek-R1 result reached 2.90 million Offline tokens per second and 2.41 million Server tokens per second. AMD and Crusoe describe the GPT-OSS score as the highest aggregate token throughput yet submitted to MLPerf.
Those are real results, and MLCommons’ public release confirms that Crusoe was among the round’s first-time submitters. Still, a 512-GPU total cannot answer the question most infrastructure teams are actually asking: whether to buy an eight-GPU node, a 72-GPU rack, or cloud capacity by the hour. Aggregate throughput rises partly because the test system contains vastly more accelerators. Dividing the reported DeepSeek-R1 Offline result by 512 yields roughly 5,668 tokens per second per GPU; that is useful context beside a rack-scale result, though it is not a complete measure of system efficiency, latency, power, memory capacity, or cost.
The operational result is more meaningful than the raw total. Crusoe says it scaled the MI355X deployment over Ethernet and maintained more than 90% of ideal scaling from eight to 512 GPUs. AMD separately reports 95% scale efficiency from eight to 72 MI355X GPUs on GPT-OSS-120B. If independently repeatable in customer deployments, that points to a credible path for organizations that need to add capacity in predictable chunks without watching interconnect overhead consume much of the added compute.
But the MLPerf record does not disclose enough to turn that into a total-cost-of-ownership recommendation. Public results tell buyers about validated benchmark performance; they do not establish cloud price, electricity use, model availability, queueing behavior, failure recovery, or the labor required to operate a 64-node inference service. AMD’s numbers establish that MI355X can scale to this level. They do not establish that a 512-GPU MI355X cluster is cheaper to acquire or run than an equivalent GB300 or Rubin service.
Vera Rubin arrives with an important availability caveat
NVIDIA’s Vera Rubin NVL72 made its first MLPerf appearance in version 6.1. MLCommons explicitly classifies NVIDIA Rubin and Vera Rubin NVL72 as preview platforms, while identifying AMD’s MI350P and Intel’s Arc Pro B70 as available hardware. That classification is not cosmetic: MLPerf’s availability rules require preview submissions to become rentable or purchasable by a later benchmark deadline, but the category is not proof that a typical enterprise can order and deploy the submitted configuration today.
Wccftech’s reproduced DeepSeek-R1 figures show a 72-GPU Vera Rubin configuration reaching 1,183,326 tokens per second Offline and 1,175,890 in Server. The matching 72-GPU GB300 result shown in the same comparison reached 689,961 Offline and 603,023 Server. The resulting difference is substantial, but it varies by scenario: about 71% higher in Offline and nearly 95% higher in Server. That is why a blanket claim that Rubin is “95% faster” needs the scenario attached to it.
The smaller 36-GPU Vera Rubin submission is also revealing. Its 591,368 Server score exceeds the cited 72-GPU GB200 Server result of 426,796, but its Offline advantage over that GB200 entry is only a few percent. A reader looking only at the headline could conclude that half as many Rubin GPUs routinely replace a GB200 rack. The data supports a narrower conclusion: on this DeepSeek-R1 Server submission, the 36-GPU Rubin system outperformed the cited 72-GPU GB200 result. It does not make the systems universally interchangeable across model types, service-level targets, memory footprints, or procurement timelines.
NVIDIA says its Vera Rubin preview delivered up to 2.5 times GB300 throughput on DeepSeek-R1 and up to 3.7 times on the Qwen3 vision-language benchmark. StorageReview independently reported those as NVIDIA comparisons tied to different workloads and software stacks. They should not be read back onto the DeepSeek-R1 chart alone, where the quoted 72-GPU figures show a smaller Offline gain and a near-doubling in Server.
NVIDIA also submitted a 288-GPU GB300 configuration spanning four NVL72 racks and reports 99% scaling efficiency. That is a useful indicator that Blackwell Ultra remains a mature, deployable rack-scale option while Rubin is still passing through the benchmark’s preview gate. For buyers with projects scheduled before Rubin’s broad availability, GB300 results are not obsolete simply because a first Rubin submission has appeared.
Blackwell still leads several practical-sized comparisons
The v6.1 results do not show a single vendor leading every model and every scale. At 72 GPUs in GPT-OSS-120B, Wccftech’s table shows GB300 at 1.20 million Offline tokens per second and 1.16 million Server tokens per second, ahead of a 72-GPU MI355X result at roughly 1.04 million and 964,468. At eight GPUs, GB300 also led MI355X in the same GPT-OSS test, 132,236 versus 117,804 Offline tokens per second.
NVIDIA’s lead is clearer in the submitted Llama 2 70B data. An eight-GPU GB300 system produced 132,253 Offline tokens per second, compared with 103,792 for MI355X. In Llama 3.1 8B, the cited GB300 eight-GPU result was 171,114 Offline tokens per second, against 158,458 for MI355X—an advantage of roughly 8%, not the 17% figure suggested by a broad reading of the source material. The Server results produce a larger gap: 173,950 versus 148,563, or about 17%.
These distinctions are inconvenient for marketing, but useful for capacity planning. Offline testing measures total completed work under a throughput-oriented scenario. Server testing imposes latency and scheduling constraints intended to resemble multi-user serving. Neither score alone tells an administrator how a model will behave behind a Windows-based internal application, an API gateway, a Kubernetes ingress, or an enterprise identity layer. Together, they show whether a configuration sustains its advantage once responsiveness is part of the test.
The deeper message from the AMD and NVIDIA submissions is that software is still moving performance materially within a single hardware generation. NVIDIA says optimizations in its v6.1 stack improved some results by as much as 1.6 times over v6.0. AMD says newer ROCm work improved the same MI355X hardware between rounds. Those vendor claims align with the benchmark’s basic premise: the system under test is hardware, framework, driver, runtime, model implementation, and configuration—not a GPU in isolation.
Intel’s Arc Pro B70 and Xeon entries broaden the useful part of MLPerf
Intel’s submissions are the counterweight to the rack-scale headlines. The company entered four-Arc Pro B70 systems with 128GB of combined graphics memory for Llama 3.1 8B, Llama 2 70B, GPT-OSS-120B, Whisper, and the new end-to-end RAG workload. Wccftech’s charts show these systems well below MI355X and Blackwell rack figures, as expected, but they place workstation-class accelerators into standardized tests involving models that would otherwise require expensive datacenter hardware.
Intel says the same four-GPU Arc Pro B70 platform improved GPT-OSS-120B by 36% in Server and 27% in Offline compared with its v6.0 submission. Intel also says Quanta Cloud Technology and Supermicro supplied the first partner B70 submissions, while Oracle made its first Intel-based entry and Red Hat made its first Xeon CPU inference entry. The added partner participation is significant because it moves the evidence beyond an in-house benchmark configuration.
For small departmental inference deployments, four Arc Pro B70 cards offer a different proposition from a 72-GPU rack: much lower absolute throughput, but a 128GB pool of VRAM in a conventional server or workstation form factor. The v6.1 Llama 3.1 8B figures list 4,977 Offline tokens per second and 4,122 Server tokens per second for the four-GPU B70 setup. That is not competitive with eight GB300 or MI355X GPUs for hyperscale serving. It may be sufficient for internal document search, prototype RAG, local transcription, or a limited number of concurrent users where keeping data on-premises matters more than maximizing tokens per second.
Intel broadened Xeon 6 participation from two processor SKUs in v6.0 to five in v6.1. It says Xeon remains the only standalone server CPU represented in the inference submissions. That makes the CPU data more useful as a deployment baseline than as a GPU substitute. A four-socket Xeon 6788P result in the Llama 3.1 8B table reached 2,068 Offline tokens per second and 1,030 in Server—far below the accelerator configurations, but potentially relevant where a separate GPU tier is impractical or where the CPU is already handling adjacent retrieval and orchestration work.
The new RAG test changes what future comparisons should measure
MLCommons’ new end-to-end RAG benchmark is the most important structural change in v6.1. It tests the chain behind a production answer: embedding a query, retrieving passages from a vector database, reranking candidates, and producing a final response with one or more language models. Intel’s submission split that chain across a Xeon 6787P processor and four Arc Pro B70 GPUs, assigning retrieval-oriented stages to the CPU and LLM generation to the GPUs.
That structure reflects a limitation of token-throughput headlines. A system that generates tokens fastest can still disappoint users if embeddings, vector search, reranking, storage access, or application-side request handling become the bottleneck. Windows and enterprise administrators evaluating local AI should treat a GPU benchmark as one component of a capacity model, then test the full workflow with their own document corpus, security controls, concurrency pattern, and latency requirement.
MLPerf v6.1 shows AMD can scale MI355X well beyond a conventional rack, NVIDIA’s Rubin architecture has produced its first peer-reviewed performance record, and Intel is making a credible case for mixed CPU-GPU and workstation-scale inference. The immediate purchasing consequence is straightforward: do not use the 512-GPU AMD total or NVIDIA’s preview Rubin peak as a proxy for the system you can deploy this quarter. Match the result to the model, scenario, GPU count, availability category, and full application pipeline before treating it as a buying signal.