Imagine a team announcing a new AI computing campus. The slide deck lists accelerators, model ambitions and a target launch date. Then the project meets a less glamorous document: the grid-connection application. How much power will the site draw, at what hours, with what backup, and when can the network deliver it? Suddenly the biggest obstacle in the room is not a chip.
That scene is illustrative, but the constraint is real. A GPU purchase can have a lead time that is measured in months; a transmission upgrade may require planning and construction that follows a very different calendar. A site can have the financing for an impressive cluster and still lack a viable route to operating it. That is why I am increasingly skeptical of infrastructure announcements that name the hardware without explaining the electricity.
The International Energy Agency estimated that data centres consumed roughly 1.5% of global electricity that year. The share sounds modest until demand is concentrated on a particular substation. 1
The first engineering question is therefore not simply how many accelerators will fit in a rack. It is what connection capacity is actually available at the chosen location, what upgrades may be necessary and which costs fall on the operator. A site may have an attractive land price and excellent network connectivity while remaining a poor candidate for high-density compute. Conversely, a smaller location close to dependable power and suitable cooling may support a useful service sooner. These are project-specific judgments; a spreadsheet of chip prices alone cannot make them.
A global number is a poor substitute for a local connection study. The same megawatt load has different consequences depending on the state of the grid, other customers in the area, transmission bottlenecks and available generation. Electricity may exist somewhere in the country without being deliverable to the chosen site. The IEA makes that geographic concentration central to its analysis. 2
What the site really has to buy
A grid connection is not merely a socket with a quoted price. Connection agreements can depend on the amount of firm capacity requested, expected demand patterns, available network upgrades and who bears the cost when those upgrades are needed. A proposal that assumes all these conditions will be settled on the same timeline as a hardware delivery is carrying schedule risk from its first day. The responsible planning document should make those dependencies visible: not because electricity projects are always slow, but because the local network has constraints that the model vendor cannot negotiate away.
The accelerators are the most recognizable item on the invoice. Around them sits the work that makes them usable: transformers, switchgear, power distribution, uninterruptible supply, networking, fire protection, physical security and an operating team. Cooling has to carry away the heat created by the equipment. None of those supporting systems is optional just because the press release calls the project a software investment.
There are also two kinds of reliability to pay for. The first is the ability to keep the facility running: redundant components, competent maintenance and an acceptable response to a power interruption. The second is the ability to keep the actual service useful. A model endpoint with excellent hardware uptime can still fail customers if capacity is misallocated, thermal throttling is ignored or a batch training job crowds out urgent inference.
It is tempting to assume that improved chip efficiency will make the physical constraint disappear. Efficiency changes how much computation a watt can buy, which is important, but lower costs can also encourage more use. The operator still has to distinguish peak demand from average demand and identify which workloads can shift safely. A model that is fast enough on a benchmark may be inefficient for an ordinary high-volume task. A smaller specialist model, caching layer or scheduled batch process may reduce the actual energy bill without changing the outcome experienced by the user.
Training and batch processing
Some jobs can tolerate a queue, a different operating window or temporary throttling. Moving them may reduce peak pressure if the workflow and deadlines allow it.
Customer-facing inference
A live service has latency, availability and data-handling obligations. You cannot casually switch it off whenever electricity becomes expensive. Treating both workloads alike produces poor capacity plans.
This difference should be visible in the software stack. Scheduling, quotas, caching, model routing and resource isolation change how much useful work the facility produces from its available capacity. An operator should know whether a workload is achieving a business outcome, not only whether its GPUs are busy. An accelerator running at a high utilization figure is not automatically doing valuable work. 23
The heat does not disappear in a dashboard
The same caution applies to expansion plans. If a site opens with an initial block of capacity and expects to multiply it later, the first installation should not assume that the next block of power will become available just because demand is growing. Transformers, cooling distribution, physical space and network redundancy have their own upgrade paths. Designing modularly can reduce the penalty of uncertainty, but it does not conjure capacity. A staged project with honest utilization measurements may give its investors more useful information than a grand completion date that ignores physical interdependencies.
Cooling illustrates the distance between laboratory performance and operational reality. An engineer may see a throughput drop and start profiling software while a facility operator is responding to a cooling alarm or unusual ambient conditions. Effective troubleshooting needs shared telemetry: rack temperatures, power draw, throttling, queue latency and customer-visible reliability viewed over the same period. This does not mean the application team should operate pumps. It means performance is now a joint property of code, equipment and the environment, and those teams should have enough context to diagnose it together.
Every watt the computing equipment consumes eventually becomes heat that must be managed. Higher-density racks make the cooling design harder, and the trade-offs are different in a hot region with constrained water supply than in a cooler location with mature utility infrastructure. Air cooling, liquid cooling and hybrid designs each demand maintenance capabilities. Thermal faults can present themselves as intermittent performance problems long before they become obvious outages.
Power usage effectiveness is useful for understanding facility overhead, but a good PUE does not tell the whole story. It says little by itself about water use, the carbon intensity of supply, idle hardware or whether the service is worth the energy consumed. A responsible performance review considers all of them together. Industry survey work also shows why operational maturity matters alongside facility design. 4
That last question matters for governments and institutions pursuing AI sovereignty. Owning a building is not the same as controlling a service. The hardware may depend on overseas components, proprietary management tools, specialist contractors and energy arrangements that are difficult to replace. Equally, using some capacity across borders does not automatically mean surrendering control of every dataset or decision. The useful question concerns keys, contractual authority, data routes, continuity and the real costs of operating locally.
The race worth winning
The political language surrounding AI sovereignty can further confuse the procurement decision. A country may legitimately need local data processing for certain public services, while benefiting from internationally hosted capacity for experimentation or non-sensitive workloads. The dividing line should be explained in terms of lawful data access, control of encryption keys, recovery options and service availability. Building local infrastructure to satisfy a slogan, without checking who can administer it and whether it can be sustained, risks replacing one dependency with another that is less visible.
There is also a public-interest question that can disappear when the debate stays inside technology budgets. New demand arrives on a grid already serving households, factories, hospitals and public services. The practical impact depends on the regulatory structure and the source of new supply. A large customer might help finance an upgrade, or it might compete for scarce capacity; the answer cannot be assumed in the abstract. Decisions about flexibility and redundancy therefore involve local institutions as well as engineering teams. A sustainable project has to be legible to the community sharing the infrastructure.
I would rather see an institution begin with a smaller facility that is reliably powered, heavily used and accountable to actual services than a spectacular cluster that spends months waiting for a connection. Some organizations will have a legitimate need for large dedicated training capacity. Others will accomplish more with distributed inference, narrower models and better scheduling. The answer depends on what must work, not on which announcement sounds most ambitious.
Useful AI capacity is not the number of chips inside a building. It is the amount of reliable work the institution can keep delivering.
There should also be a plan for what the operator will do when actual use differs from the forecast. If demand arrives slowly, can idle equipment be reassigned to useful research or shared workloads? If demand spikes, which services have priority, and who authorizes spending or temporary external capacity? If grid reliability changes, which workloads can wait and which require a costly backup route? Those are governance and product decisions as much as technical settings. The ability to answer them gives an infrastructure investment flexibility without pretending that its physical constraints have vanished.
Electricity does not make the compute race less important. It makes the race more physical, more local and more consequential for everyone who shares the infrastructure. Once that is understood, the discussion moves naturally from accelerator counts toward deliverable power, cooling, operating discipline and the services people will actually receive.
Sources and further reading
