Every systems discussion eventually collides with physics. Not abstract physics — the kind that shows up in a bill of materials. In modern infrastructure, three semiconductor domains set the outer bound of what software can pretend to be true.
Compute: the obvious bottleneck
GPUs and accelerators dominate the conversation because they are visibly scarce. Training runs are scheduled like launch windows. Inference clusters are capital decisions. When compute is the limit, software adapts by batching, quantizing, and approximating.
But compute alone does not explain why some architectures feel fast while others stall on paper-thin workloads.
Memory: the hidden tax
Memory bandwidth and capacity determine whether a model fits, whether a cache is warm, and whether a pipeline can stay full. Many “software bugs” are memory hierarchy problems wearing a trench coat.
This is why disaggregated memory and high-bandwidth packages matter as much as raw FLOPS. The trinity fails if compute starves waiting for bytes.
Interconnect: the system is the network
Inside a chip, between chips, and across racks — interconnect sets the shape of parallelism. A beautiful algorithm on the wrong topology becomes an expensive serial program.
NVLink, PCIe generations, optical links, and fabric design are not plumbing. They are the grammar of scale.
Reading the trinity together
When evaluating a platform — cloud instance, edge box, or accelerator card — ask three questions:
- Compute: What sustained throughput do I get on my workload, not the benchmark slide?
- Memory: Where does data live, and how often does it cross a painful boundary?
- Interconnect: What breaks first when I add one more worker?
Software trends come and go. The trinity persists. Systems engineers who learn to read it early spend less time arguing about frameworks and more time finding real headroom.