From Power to Inference—Building a Distributed AI Compute Network

A conceptual infrastructure and routing architecture

Start with a chain of measurable boundaries

A conceptual compute network connects electrical supply, facility distribution, cooling, racks, accelerators, serving engines and application requests. A capacity value at one boundary does not establish output at another. A proposed facility may have a utility discussion before it has commissioned electrical systems; a server may be installed before a model is loaded; a reachable endpoint may still miss a workload's latency objective.

For Aguasto's planned strategy, document each transition with a separate acceptance condition. The educational diagram should show dependencies and measurements, not owned facilities, authorized capacity or existing service regions. A complete development story needs the facility and the delivered-work records to agree.

Distinguish IT energy from facility energy

DOE FEMP defines annual PUE as total facility energy divided by IT-equipment energy. Cooling and other infrastructure contribute to the facility boundary; water efficiency has a separate WUE definition. PUE does not measure model quality or tokens produced.

A simplified scenario can apply facility kW = IT kW × assumed PUE and kWh = kW × hours. For hypothetical 100 kW average IT load, PUE 1.3 and 24 hours, the result is 3,120 kWh of facility energy. This assumes constant load and a representative PUE for the period; it is not an audited annual PUE or a claimed Aguasto operating value.

Keep cooling and hardware assumptions explicit

The proposed rack worksheet should distinguish accelerator rating, server input, networking/storage load, rack input and facility input. Add idle, average workload and peak observations only when measured. Identify the cooling technology and heat-removal boundary, then verify it against the selected equipment and site engineering.

Do not convert a GPU thermal design rating into a whole-facility demand estimate without accounting for the rest of the system. For a future comparison using MLPerf power results, retain the full-system AC boundary and the accompanying workload: MLCommons says those measurements are valid for that benchmark, not a generic device or power-supply rating.

Translate physical resources into completed work

The proposed serving record should attach the exact model, precision, engine, parallelism and load profile to actual completed output tokens. Report failures and latency objectives beside throughput. Compute cost per million completed output tokens as cost USD ÷ actual completed output tokens × 1,000,000, with a strictly positive denominator.

Define the included costs and interval: compute rental, energy, network, software, operations or a narrower subtotal. An electricity-only result must be labeled electricity cost, not total inference cost. Exclude theoretical peak tokens from the denominator. If no observed token count exists, leave the measured-cost result unavailable and keep a hypothetical scenario clearly separate.

Distribute requests, while respecting the workload

A network of regional replicas is conceptually different from splitting one model across tightly coupled devices. The first can direct independent requests to eligible locations; the second depends on the selected parallelism and communication path. Define which form a deployment diagram depicts before choosing network or reliability assumptions.

In the proposed Aguasto architecture, evaluate user latency, eligible data locations, version consistency and spare capacity for each regional workload. Do not assume that distant sites form one training fabric or that moving a request moves its active cache. Geographic distribution should be justified by an application requirement and a tested routing/recovery policy.

Build a delivery record, not a peak-capacity promise

Use a staged evidence record: authorized electrical service, commissioned facility systems, accepted rack configuration, loaded and verified model, representative serving run and monitored application behavior. Each stage should retain date, boundary and unresolved dependency. A later benchmark can then explain how infrastructure resources become useful responses.

Aguasto is developing this infrastructure thesis; it has not substantiated operating regions, GPU inventory or an inference API. This methodology allows a technically meaningful partner discussion now: which equipment, engineering interfaces and workload tests would be needed to validate the next step. It creates no procurement commitment, energy guarantee or operational service claim.