RTX PRO 6000 Blackwell Max-Q vs 600 W Workstation: Complete AI and CUDA Benchmarks

We tested eight 300 W RTX PRO 6000 Blackwell Max-Q Workstation GPUs against four 600 W RTX PRO 6000 Blackwell Workstation GPUs, then added a four-Max-Q equal-card-count view. The short answer: 600 W wins per-card compute-heavy throughput, four Max-Q cards win efficiency, and eight Max-Q cards win most aggregate workloads at the same nominal 2.4 kW GPU power envelope.

On this page

1. The short answer
2. Systems and methodology
3. Raw compute, memory, PCIe, and P2P
4. Single-GPU image, video, and training
5. DeepSeek-V4 DSpark
6. Qwen3-4B serving
7. Image, video, and training replicas
8. Synchronized DDP training
9. Scientific CUDA workloads
10. Energy efficiency
11. Power cost and TCO
12. Burn-in, thermals, and stability
13. Runtime compatibility findings
14. Deployment recommendations
15. Limitations
16. FAQ

RTX PRO 6000 Max-Q vs 600 W: the short answer

The 600 W card does not deliver twice the performance of the 300 W Max-Q card. Across isolated dense GEMM, it is 1.40-1.54x faster per GPU. Device-memory and PCIe bandwidth are effectively equal. In applications, the gain ranges from nearly zero for short-context Qwen3 TP1 serving to roughly 25-35% for training and generative AI.

*The 4x600 W Wan2.2 output is performance-valid but failed the strict thermal health gate.

Chart 1. Simultaneous BF16 throughput

Test systems and benchmark methodology

What was controlled

Models, revisions, prompts, tensor shapes, benchmark scripts, warmup rules, measured durations, and result validation were matched wherever the runtime allowed it. GPU power limits and ECC settings were not altered to improve a result. The documented NVIDIA P2P override was enabled on Max-Q before its measured DeepSeek retries; the 600 W host retained its different, container-controlled P2P configuration. Neither baseline was changed after measurement began, and every failed diagnostic was retained.

What differs

This is a system comparison, not a laboratory isolation of one GPU SKU. GPU count, CPUs, motherboards, NUMA layout, drivers, and CUDA builds differ. Equal power means the same nominal 2.4 kW configured GPU board-power envelope for 8x300 W and 4x600 W, not equal wall-socket power for the complete servers.

Validation

Measured application work was bounded with CUDA synchronization. Generated PNG and MP4 files were decoded and hashed. Training required finite loss and a measurable parameter update. Compute required known-answer preflight and deterministic output samples. Health gates compared PCIe AER, NVIDIA thermal-time and power-brake counters, telemetry, logs, and exit status. The comparison container could not expose the host kernel journal, so its validation relies on the other evidence.

Raw compute, memory, PCIe, and P2P performance

Dense matrix multiplication is where the 600 W card has its clearest per-GPU advantage. The extra 300 W raises clocks and compute throughput, but not memory or host-interface bandwidth.

Chart 2. One-hour sustained BF16 plus VRAM validation

PCIe and NUMA topology

Same-NUMA P2P payload bandwidth is approximately 52-56 GB/s. Cross-NUMA paths fall to about 35-40 GB/s on the Max-Q host and 34-38 GB/s on the four-GPU host. The comparison host's GPU 3 sits on the second socket, creating an asymmetric three-plus-one topology. This is central to DeepSeek TP scaling and DDP efficiency.

Single-GPU image generation, video generation, and training

Both GPU variants expose the same 96 GB-class VRAM. Qwen-Image-2512 and Wan2.2 T2V-A14B ran fully resident without CPU or model offload.

Chart 3. SDXL throughput by batch size

LoRA is not automatically faster than full fine-tuning. It updates fewer parameters, but the base model still performs dense forward, activation-gradient, and backward work. In this Qwen3-4B test, full batch 2 was the throughput optimum.

DeepSeek-V4 DSpark inference benchmarks

The DeepSeek-V4-Flash-DSpark model used a pinned 166.9 GB weight set and immutable DSpark v10 image. We measured Lucifer CUTLASS and B12X A8 at TP2, TP4, and TP8 across decode concurrency, coding probes, and 8K/64K/128K prefill.

*TP2 Lucifer used a 140,000-token serving cap because the 262,144-token contract did not fit its KV and workspace requirements. B12X uses an approximate sparse indexer and did not receive the separately skipped output-quality qualification.

Chart 4. Deployable DeepSeek C64 capacity

One TP8 Lucifer engine reached only 3,121.8 tok/s at C64. Two concurrent TP4 engines reached 6,410.2 tok/s, 2.05x TP8 by the matched steady-state rate definition. Their host wrapper also recorded 5,506.4 tok/s common-wall throughput, but no corresponding TP8 common-wall value was captured, so no mixed-boundary ratio is claimed. TP8 also collapsed at C1 and coding. Per-GPU power fell as TP increased, showing a PCIe and cross-socket collective bottleneck rather than a thermal or power limit.

Only optimized TP2 Lucifer decode is directly comparable between the 300 W and 600 W hosts. The 600 W card improved matched C1-C64 decode by about 7-13%. Driver 590 forced other comparison-host DeepSeek paths into eager mode, which characterizes compatibility rather than an optimized hardware ceiling.

Qwen3-4B dense LLM serving

Qwen3-4B provides a portable dense-model baseline across TP1, TP2, TP4, 1K/8K/32K context, and concurrency 1/4/8. FlashInfer and standard NCCL were used on both systems because the driver-590 host rejected prebuilt FlashAttention PTX and the DSpark custom all-reduce patch was not compatible with generic Qwen tensor parallelism.

Chart 5. Qwen3 TP1 replica capacity

TP4 provides only 1.85-1.89x TP1 throughput at 1K/C8 while consuming four GPUs. Use TP2 or TP4 when one endpoint needs greater long-context output throughput. Use independent TP1 replicas for aggregate capacity.

All-GPU image, video, and independent training capacity

Independent replicas avoid motherboard and all-reduce effects. They are the cleanest way to compare system capacity for multi-tenant inference, parallel media generation, hyperparameter search, and unrelated fine-tuning jobs.

Chart 6. SDXL and Qwen-Image system throughput

Chart 7. Wan2.2 all-GPU video capacity

Chart 8. Independent Qwen3-4B full training

Synchronized Qwen3-4B DDP training

DistributedDataParallel adds NCCL gradient all-reduce, CPU scheduling, PCIe, NUMA, and motherboard behavior. We measured world sizes 8 and 4 on Max-Q and world size 4 on the 600 W host with identical batch 2 and sequence 4096 per rank.

Chart 9. Qwen3 DDP global training throughput

The balanced four-GPU Max-Q NUMA island has the smallest synchronization penalty. The comparison host's three-plus-one GPU placement has the largest. These results are system- and motherboard-dependent, not a pure GPU-SKU collective benchmark.

Scientific CUDA benchmarks: FFT, Cholesky, SpMV, stencil, N-body proxy, and Monte Carlo

The scientific suite covers a 16.8 million-point complex FFT, 256-cubed 3D FFT, 8,192-square FP32 Cholesky, CSR sparse matrix-vector multiplication with 16.8 million nonzeros, a 384-cubed seven-point stencil, 16,384-body pair distance, and 67.1 million-sample Monte Carlo pi estimation.

Chart 10. Aggregate scientific CUDA throughput

These are independent per-GPU kernels, not distributed scientific applications. They do not include domain decomposition, halo exchange, or communication-heavy multi-GPU solvers. Scientific phase energy was not measured.

Energy efficiency per image, frame, token, and FLOP

Energy is the trapezoidal integral of NVIDIA's sampled board-power field. Generation and training exclude model load and artifact export. The sampling window includes blocking boundary queries; DDP also includes the synchronization barriers around timed optimizer steps. These are board-energy results, not wall-socket measurements.

Chart 11. Energy per completed unit, lower is better

In the ten-minute dense-compute phase, eight Max-Q cards delivered 873.7 GFLOP/J versus 589.9 GFLOP/J from four 600 W cards. For Qwen serving, Max-Q used 26.5-27.8% less energy per output token at TP1/TP2/TP4. Serving energy covers the complete measured-client wrapper, including readiness and teardown, while the denominator includes benchmark-reported measured output tokens. Tensor parallelism increased energy per token for this 4B model even when it improved one endpoint's throughput.

Power cost and TCO tradeoffs

Electricity is only one part of GPU total cost of ownership, but it is the part most directly connected to these measurements. The examples below are planning illustrations, not a full TCO framework. They exclude hardware purchase price, financing, demand charges, taxes, maintenance, software licensing, staffing, and network or storage costs.

Indicative business electricity-price bands

Actual industrial rates vary by contract size, time of use, demand charges, taxes, grid constraints, and exchange rates. These bands are directional examples rather than quotations for a specific facility.

Always-on GPU-board electricity cost

A simple GPU-only anchor is GPU kW x 8,760 hours x electricity price. Four Max-Q cards expose a 1.2 kW nominal GPU-board envelope. Eight Max-Q cards and four 600 W cards both expose 2.4 kW. This calculation assumes 100% utilization and excludes PUE and all non-GPU server power.

How PUE and server overhead change the result

Power usage effectiveness multiplies total IT energy, not just GPU board power. A useful facility estimate is total IT kW x 8,760 x PUE x $/kWh. CPU, RAM, storage, networking, power conversion, and server fans must be added before applying PUE.

• Same GPUs, different facility: at $0.14/kWh, a 2.4 kW GPU load costs about $3,385/year when attributed through PUE 1.15 and $4,121/year at PUE 1.40. That $736 difference appears before adding non-GPU IT power.
• Lower board power can outweigh worse PUE: 1.2 kW of Max-Q GPU power at PUE 1.40 costs about $2,060/year at $0.14/kWh, versus $3,385 for a 2.4 kW GPU load at PUE 1.15.
• System overhead is material: an illustrative 0.6 kW of CPU, memory, fans, storage, and networking adds about $883/year at PUE 1.20 and $0.14/kWh. The actual overhead should be measured at the wall or rack PDU.

A few practical TCO tradeoffs

• Hardware acquisition: eight Max-Q GPUs require twice as many cards as a four-GPU system. Their 44-57% aggregate throughput advantage only offsets that higher acquisition cost when the extra replicas or training jobs remain utilized. Actual GPU and platform prices were not measured here.
• Latency versus energy: four 600 W cards are about 25-35% faster than four Max-Q cards on image, video, and full-training workloads. Four Max-Q cards use roughly half the nominal GPU board power and 31-34% less measured energy per completed application unit. Paying for 600 W can still make sense when job latency or an SLA has more value than electricity savings.
• Rack density and cooling: four 600 W GPUs provide more compute per slot, but concentrate heat. Eight Max-Q GPUs need more slots and potentially more chassis or platform infrastructure. The tested Max-Q host showed much lower GPU core temperatures and fan percentages, but facility cooling cost depends on the actual rack design and PUE.
• Per-GPU licenses and operations: software licensed per GPU, spare inventory, and component count can make eight cards more expensive even at equal aggregate board power. Conversely, more independent GPUs provide finer scheduling and smaller capacity loss when one card is offline.

GPU burn-in, VRAM integrity, thermals, and one-hour stability

The one-hour soak combined sustained BF16 tensor-core work with approximately 76.25 GiB of patterned VRAM per GPU. Every GPU completed 59 full-region readbacks. Across both hosts that is 708 GPU-level readbacks with zero mismatches, zero deterministic compute-output changes, and zero AER increments.

Chart 12. Peak temperature under sustained workloads

The retained Xid 43 incident

An early burn-in harness used integer torch.linspace for deterministic sample indices. Endpoint rounding generated one out-of-range index and triggered Xid 43 on all eight GPUs. The arithmetic was corrected, every GPU was reset without reboot, and all subsequent compute, VRAM, PCIe, thermal, and one-hour health gates passed. This was a software-harness failure, not evidence of hardware damage.

Driver, CUDA, vLLM, FlashAttention, and DeepSeek compatibility findings

Compatibility was part of the benchmark, not hidden setup work. Important retained findings include:

• Driver 590 rejected the image's prebuilt FlashAttention PTX with cudaErrorUnsupportedPtxVersion; matched Qwen tests used FlashInfer.
• The DSpark generic custom all-reduce signature was incompatible with Qwen TP; standard NCCL passed.
• InstantTensor failed on the driver-590 comparison runtime; verified safetensors loading passed.
• Captured DeepSeek prefill hit an assertion and required eager mode on driver 590.
• Optimized TP2 B12X C64 and TP4 Lucifer C64 missed transient workspace allocation by only tens of MiB. The OOMs were retained instead of tuning around them.

These distinctions are operationally important for vLLM on Blackwell, CUDA 13 attention backends, FlashInfer, DeepSeek DSpark on driver 590, and Qwen NCCL tensor parallelism. Eager compatibility results should not be presented as optimized hardware ceilings.

Deployment recommendations by workload

Limitations and reproducibility boundaries

• This is a complete-system comparison. CPU, motherboard, NUMA topology, driver, CUDA build, and GPU count differ.
• Equal power means nominal configured GPU board power, not complete-server wall power.
• The direct 600 W host used Workstation Edition. Public Server Edition DSpark data are external reference points.
• Only optimized TP2 Lucifer DeepSeek decode passed in directly comparable optimized mode on both hosts.
• TP2 Lucifer used a 140K serving cap; other Max-Q DeepSeek rows retained 262,144.
• B12X uses an approximate sparse indexer. Its separate quality suite was skipped by request.
• NCCL motherboard microbenchmarks were skipped; topology conclusions rely on P2P and application scaling.
• Training used deterministic synthetic token IDs and excludes storage, tokenization, collation, and data loading.
• Generated files were decoded and validated, but perceptual image/video quality was not scored.
• Wan2.2 was measured at 832x480, not 720P.
• Energy uses sampled GPU board power, not wall-socket instrumentation.
• Scientific workloads are independent kernels, not distributed communication-heavy applications.
• ECC was disabled and GDDR memory temperature was not exposed on the workstation configuration.

Frequently asked questions

Reproducibility summary

All reported models used pinned revisions. DeepSeek used a pinned DSpark v10 image and model commit; Qwen-Image-2512, Wan2.2 T2V-A14B, Qwen3-4B, and SDXL used verified local snapshots. Raw JSON, summary text, worker logs, telemetry, media hashes, health counters, harnesses, diagnostics, and final host states were retained. Core three-configuration charts are generated from the publication dataset; detailed matrices remain traceable to their named raw artifacts.

Benchmark dates: 2026-07-13 to 2026-07-14. Direct host comparison: RTX PRO 6000 Blackwell Max-Q Workstation Edition at 300 W versus RTX PRO 6000 Blackwell Workstation Edition at 600 W. Public Server Edition data, where mentioned, are external references.