Why GPU Compute and Storage Networks Need Separate Sizing
Independent technical selection guidance. No claim of a SwitchInfra installation, supplied batch, certified performance or customer outcome.
Why GPU Compute and Storage Networks Need Separate Sizing
Why GPU Compute and Storage Networks Need Separate Sizing
Begin with traffic behavior
A GPU server exchanges collective traffic with other workers while reading input data and writing checkpoints. Those flows can have different burst patterns, congestion sensitivities and fault domains. Start by measuring input size, checkpoint bursts, worker count and the training communication pattern before choosing a NIC family or network speed.
A public operator example
CoreWeave describes H200 infrastructure with a separate ConnectX-7/Quantum-2 GPU fabric and BlueField-3 Ethernet storage path. Its B200 production announcement separately identifies one BlueField-3 DPU and eight ConnectX-7 HCAs per eight-GPU instance. These are operator-reported family-level architecture examples. They do not identify the missing catalog order codes and do not establish a SwitchInfra delivery.
Turn the example into a selection method
Define compute-fabric and storage-fabric requirements independently. For the compute path, evaluate collective traffic, rail count, topology and oversubscription. For the storage path, evaluate concurrent reads, checkpoint writes, failure recovery and contention. Then map the required interfaces to the exact server slots, DPU or NIC codes, interconnects and supported software.
Keep benchmark scope intact
A storage benchmark can test aggregate file-system throughput without measuring end-to-end training speed or a single adapter’s benefit. Preserve the operator’s method and hardware configuration when discussing a result. Use the full case article for workload and measurement conditions; never turn a platform outcome into a guaranteed per-SKU performance promise.
Deliver a deployable bill of materials
For each path, capture the exact order code, protocol, port configuration, connector, cable or optic, host-interface capability, power and thermal qualification, and firmware identity. Add a commissioning test that checks the intended traffic pattern under realistic concurrency. This makes the architecture example useful without implying that a family name alone determines the final design. Independent technical selection guidance. No claim of a SwitchInfra installation, supplied batch, certified performance or customer outcome.
Public references
- CoreWeave: Distributed File Storage for Model Training
- CoreWeave HGX B200 general availability
- NVIDIA BlueField-3 Networking Platform User Guide | NVIDIA BlueField-3 Networking Platform User Guide
- NVIDIA ConnectX-7 Adapter Cards User Manual | NVIDIA ConnectX-7 Adapter Cards User Manual
- NVIDIA ConnectX-8 SuperNIC User Manual | NVIDIA ConnectX-8 SuperNIC User Manual