From Power Redundancy to Dependable GPU Service

The engineering question

Installed capacity is not GPU service availability

Consider a hypothetical islanded AI campus with five 25 MW generator units and 100 MW of nominal demand. Four units have sufficient nameplate capacity in simple arithmetic. But a shared fuel disturbance may affect several units, a switchgear fault can interrupt downstream power, and a cooling or control failure may interrupt useful computation even while electrical power is available.

The reliability boundary should therefore extend from sources to the actual required service: how much GPU capacity remains available, how often is it interrupted, and how long does restoration take?

Five questions for the reliability model

1. What is promised? Define usable GPU capacity, interruption threshold, duration, recovery objectives and the service boundary.
2. What can fail together? Identify shared fuel, protection, switchgear, controls, cooling, communications and site-wide hazards.
3. What happens after a failure? Follow isolation, transfer, storage ride-through, repair and second-failure exposure during degraded operation.
4. Which loads are interrupted? Integrate curtailed load separately across time; partial restoration and repeated interruptions matter.
5. Which indices can actually be justified? Combine event frequencies and distinct conditional outcomes without double counting; withhold system indices for incomplete event populations.

A capacity illustration—not a reliability result

This hypothetical arithmetic ignores auxiliaries, delivery constraints, losses, operating reserves, dynamic response, fuel, cooling and storage. It is not a model of an actual developer's campus and not an InfraRel network solve.

From stored electrical consequences to probabilistic interruption risk

General Reliability is extending its established SUBREL foundations through InfraRel, a developing platform for joining electrical contingency consequences, load-point interruption chronology and statistical reliability accounting. A locally tested, opt-in postprocessor now evaluates previously solved electrical study records without new network solves.

In a separate synthetic two-transformer substation study, a T-A initiating event is assigned 0.10 occurrences per year. Two declared mutually exclusive outcomes have probabilities 0.90 (successful protection) and 0.10 (stuck breaker). Under an assumed, not observed one-hour transition, each outcome has 10 MW curtailed, giving 10 MWh of energy not served per occurrence.

These are synthetic and qualified results, not field failure rates, a campus RAM result or complete-system EUE. Electrical event stages recorded at zero time do not prove instantaneous physical restoration. The one-hour duration is an explicit synthetic assumption. Physical fault isolation remains unverified in this demonstration. The parent event must not be added again to the conditional family.

Both outcomes have the same assumed ENS, so changing their outcome probabilities alone would not change this family subtotal. To quantify the reliability benefit of improved protection or redundancy, models must demonstrate different credible consequences under the alternatives.

What an AI-campus study must add

An engineering comparison should capture overlapping generator outages and repair exposure; shared fuel and controls; UPS/BESS power, energy and transfer constraints; protection and switching behavior; cooling and thermal ride-through; and partial GPU-service loss. It should quantify interruption frequency, duration and severity for each relevant service boundary, with transparent component data, uncertainty and dependency assumptions.

A defensible analysis may reuse unchanged electrical consequences when only event frequency changes. Repair-duration changes can alter second-failure exposure and may require recomputation. Topology or control changes may require new electrical analysis. Data gaps must produce explicit qualifications, not unsupported precision.

What InfraRel can do today—and next

InfraRel is being developed to link component and protection failures, switching and restoration chronology, and probability-weighted interruption consequences. Its tested local stored-study postprocessor can calculate load-point energy not served, count separate interruption episodes, account for explicitly defined conditional outcomes, and report selected-event EUE without re-solving the network. It preserves input provenance, makes timing assumptions visible, and withholds unsupported complete-system indices.

Next development boundary: extend those methods to integrated generation, fuel, cooling, storage, control and GPU-workload dependencies. Those integrated campus results are not yet validated or available as a production service.

Standards: the foundation, not the finish line

Data-center reliability assessments should start with recognized infrastructure frameworks: Uptime Institute Tier Topology and Operational Sustainability, ANSI/TIA-942-C, and ISO/IEC 22237. Electrical reliability and reliability-economic trade-offs draw on the IEEE 493/IEEE P493 tradition; ASHRAE TC 9.9 provides thermal-environment guidance. ISO/IEC 30134 addresses data-center resource-effectiveness metrics, including PUE, rather than a universal GPU-service availability guarantee.

Facility classifications and equipment redundancy are important, but do not by themselves compute application or GPU-workload interruption frequency, duration or economic consequence. The Uptime Tier classifications do not assign universal expected annual downtime figures. InfraRel is intended as an independent quantitative complement, not a standards certification or conformity assessment.

What does an outage actually cost?

A design study should count more than capital cost, maintenance and fuel. A serious interruption may create repair and recovery expenses, stranded generation and compute capacity, contractual service credits, deferred work, lost revenue, damaged trust, and losses borne by downstream users. These categories must not be added twice where one is merely a transfer payment or overlaps another. Costs should be tied to the affected service and the actual duration and severity of disruption.

For disjoint event outcomes, a useful first model is expected annual service-loss cost = sum of (annual event frequency × consequence cost for that outcome). The consequence function can depend on time, curtailed GPU capacity, workload type, recoverability and users affected. It must also distinguish an operator's financial liability from a customer's real loss, and from societal or safety effects that may require constraints rather than monetary pricing.

Which service matters most? There is no universal ranking of electricity, connectivity, compute and data. A remote worker might prefer a brief local power interruption with functional mobile connectivity over prolonged loss of digital services. Someone using electrically powered medical equipment might face the opposite priority. Critical medical, financial and public-safety services can depend on both. The engineering task is to define and protect the relevant end-user service, not to presume that all interrupted megawatt-hours have the same value.

For context, Uptime Institute's 2026 outage analysis reports that 57% of surveyed respondents said their most recent major outage cost more than $100,000 and about one in five reported costs above $1 million. Those survey proportions are not project-specific input failure rates or a universal cost per hour.

InfraRel development status

Locally demonstrated: per-load chronological curtailment and interruption counting; conditional-event accounting; qualified ENS/EUE calculations from stored electrical results; explicit data and timing provenance; and a stored-study reporting workflow that performs zero additional network solves.

Under development: full integrated generation, fuel, cooling and control models; validated AI-campus RAM results; operational-data updates; and a production Studio interface. InfraRel does not certify availability, approve protection, autonomously control equipment or guarantee GPU service.

← Knowledge & Insights · Data-center reliability · InfraRel