Check cluster bottlenecks before buying more GPUs
Provides practical criteria for deciding whether low GPU utilization calls for more GPUs or improvements in networking, scheduling, topology-aware placement, and operations software.

Before Buying More GPUs, Check Whether the Cluster Is “Talking Too Far”
In large-scale AI infrastructure decisions, it is no longer enough to ask only which GPU is faster. If training or inference runs across multiple nodes, the more practical question is: Are the GPUs waiting on computation, or are they waiting on communication?
For teams reviewing supplier choices or cluster expansion, that distinction affects spending priorities. If the bottleneck is compute, adding GPUs may be close to the right answer. If the bottleneck is communication, congestion, or placement, adding more of the same GPUs may not improve efficiency in proportion to the spend. In that case, the priority can shift toward the network fabric, NICs, DPUs, scheduler, topology-aware placement, and operations software.
The trend described by TechCrunch is related to this issue. The article says efficiency improvements in new data center systems come not only from more processor cycles, but also from more sophisticated traffic control. That supports a broader view: AI infrastructure competition is not only about standalone GPUs, but also about how the data center works as a system.
Nvidia’s Defensive Line Is Not the GPU, but the “Periphery That Makes GPUs Work”
Based on the cited materials, Nvidia’s system-level approach is clear. Rather than selling only GPUs, it presents training and inference clusters as validated architectures that combine NVLink, Spectrum-X networking, ConnectX SuperNIC, BlueField DPU, storage, CUDA, AI Enterprise, and Mission Control.
The important point is that networking is not treated as a simple accessory. Nvidia describes Spectrum-X as a platform built from switches and SuperNICs, with goals that include low latency and high fabric utilization. It also describes noise isolation between tenants through telemetry-based congestion control. In other words, the product logic is not just “connect fast GPUs.” It is closer to “make GPU-to-GPU data exchange more predictable.”
However, the cited evidence does not support a quantitative comparison of Nvidia’s network control capabilities against specific competitors. The analysis here is narrower: Nvidia’s differentiation appears to be expanding from standalone GPUs toward system integration and traffic control. This is not a claim that Nvidia is best under all conditions.
The Moment the Bottleneck Changes: Distributed Training and Partitioned Inference
The points where networking and scheduling become as important as compute performance are relatively clear.
First is distributed training across multiple nodes. If a training job is placed across distant parts of the data center fabric, extra latency appears whenever gradients are synchronized. If network capacity does not keep pace with growing GPU compute capability, communication can become the bottleneck. Network contention has also been reported as a problem in multi-tenant GPU clusters.
Second is large-model inference. In tensor parallelism and pipeline parallelism, where a model is split across multiple GPUs or nodes, each stage depends on timely inter-device communication. In inference pipelines that separate prefill and decode, movement of KV cache and model data, along with tail latency, can constrain overall response performance. In this setting, placement that ignores NVLink locality or fabric topology is not just an operational detail. It can become a latency cost.
This changes how AI infrastructure purchases should be evaluated. Low GPU utilization should not immediately be read as evidence that there are not enough GPUs. Teams should first separate possible causes: data loading, communication waits, collective communication, inter-tenant contention, and inefficient placement.
Decision Rule: Require Three Types of Evidence Before Expanding GPUs
In practice, the following rules can be applied.
If the communication share is low, as in single-node or small-scale inference. GPU memory or compute is the clear limit, then GPU generation and standalone performance comparisons should take priority. In that case, differences in the network stack may matter less than total cost.
Conversely, if training jobs span multiple nodes and require large, repeated gradient synchronization; if inference models should be partitioned across multiple GPUs or nodes. Or if performance interference recurs in a multi-tenant environment, then system design should be evaluated before GPU unit price. In this range, network congestion control, switch-NIC co-design, DPU utilization, topology-aware scheduling, and operations software should move to the top of the purchasing evaluation scorecard.
When reviewing vendor proposals, ask “how predictable is performance under poor placement and congestion” rather than focusing only on “maximum FLOPS.” Average throughput is not enough. In large-scale inference services, tail latency can shape user experience and capacity planning. In distributed training, synchronization delays reduce overall cluster efficiency.
The phrase “AI infrastructure beyond the GPU” does not mean GPUs have become less important. It means that as GPUs become more expensive and powerful, the value of the network and operations layers that keep them from sitting idle increases. As clusters grow, competitiveness is visible not only in chip peak performance, but also in how well the system handles congestion and poor placement.
Further Reading
- ANTShapes is a benchmark for difficulty control, not performance claims
- What MoganBert-TR signals for Turkish search
- ICVD as a benchmark for NICU video AI
- When Agent-G² is useful for guidance depth
- Evaluating code agents for both functionality and security
References
- Abstract — NVIDIA NVL72 AI Factory - docs.nvidia.com
- NVIDIA Spectrum-X Ethernet Platform for AI Networking - nvidia.com
- Giga-Scale AI and the Ethernet Evolution: How Spectrum-X Ethernet Rewrites the Rules - developer.nvidia.com
- Overview | NVIDIA Topograph - docs.nvidia.com
- Ecosystem Architecture — NVIDIA Enterprise AI Factory Design Guide White Paper - docs.nvidia.com
- techcrunch.com - techcrunch.com
- Isolated Scheduling for Distributed Training Tasks in GPU Clusters - arxiv.org
Get updates
A weekly digest of what actually matters.
Found an issue? Report a correction so we can review and update the post.