Building as a Computer: Higher Stakes, Harder Choices

Building as a Computer
5
Min Read
November 12, 2026
Share Article

AI infrastructure is getting exponentially productive. However, realizing its full potential requires coordinated investment in compute, power, cooling, networking and software. Designing these elements together around the workloads they must serve turns the data center itself into an integrated computing system: the building as a computer.

This approach meets growing AI demand more efficiently, but also raises the stakes for capital allocation. A factory can achieve strong technical performance and still underperform financially if it enters service late, cannot allocate its installed capacity effectively or requires substantial reinvestment to support the next workload.

The challenge is to capture the gains of the system as whole while preserving the ability to deploy, allocate and upgrade capacity economically. The difficult choices begin early: how much to build before customers commit, whether to buy more compute or make existing capacity usable, and how much to spend today to reduce future upgrade costs.

More AI Output from Every Megawatt

NVIDIA’s progression from Hopper to Blackwell to Rubin demonstrates the gains from increasingly integrated compute, interconnects and software.

SemiAnalysis’s agentic inference comparison puts Blackwell at 12.6 times and Rubin at 26.3 times Hopper’s throughput per megawatt.

For a site with a fixed power allocation, higher throughput lets you serve more demand. Simultaneously, these gains are being passed on to end customers. Epoch AI estimates that the price of achieving a given level of AI performance fell by about 47% per quarter across its study, equivalent to a 13-fold decrease per year. In the long run, sustaining affordable AI requires a closer look at the business of producing it.

Affordable AI Needs Durable Production Economics

Full-utilization projections tell only a part of the story. Returns depend on the time required to reach that utilization and the cost of adapting capacity as demand changes.

Integration makes these choices interdependent. A configuration optimized for the initial customer may deliver excellent performance but need additional networking, cooling or software changes to serve the next one.

Three decisions determine much of that exposure:

  • Deployment scale and timing: how much capital to commit before revenue and when to bring each increment of capacity into service.
  • Capacity allocation: how to combine and reassign resources to serve the customer mix without leaving expensive assets idle.
  • Adaptation and refresh: which parts of the system must change for a new workload or hardware generation, and at what cost.

Evaluating these questions together makes the tradeoffs visible. The lowest initial unit cost is not necessarily the lowest cost of serving customers across successive deployments and upgrades.

The First Test Is How Soon Capacity Can Start Earning

Deployment size determines how much capital the business commits before it can begin recovering that investment.

A large first phase can meet an anchor customer’s requirements and spread infrastructure costs across more compute. Smaller phases can bring revenue forward and defer expenditure, but may carry a higher cost per megawatt or limit the scale of workloads available at launch.

Neither approach is inherently superior. The choice depends on committed demand, the cost of each usable deployment and the expense of adding capacity later. The financial model should show returns under both the expected customer ramp and a slower one.

A phase is commercially useful only when it can deliver the contracted service. Completing construction or installing GPUs does not advance revenue if power, cooling, networking or software remains unready.

Hardware orders require the same analysis. Ordering early secures supply but creates inventory and financing costs when facility readiness slips. Procurement needs to protect the service date without committing capital materially ahead of the system’s ability to earn.

Radiant’s Drax partnership illustrates the role of long-duration capital in phased development. Its value depends on aligning financing, engineering and customer commitments around the capacity each phase can bring into service.

The Second Test Is Turning Installed GPUs into Sellable Capacity

Installed GPU count is an incomplete measure of commercial capacity. Customers require connected resources that meet specific performance, isolation and availability requirements.

A factory can have enough idle GPUs to meet a reservation in aggregate, yet be unable to assemble them into a suitable cluster. The devices may sit across incompatible network domains, or the required racks may lack sufficient power or cooling.

This is the idle tax: the cost of infrastructure that cannot serve available demand. 

The response depends on the constraint. Better placement can reduce fragmentation. Faster reprovisioning can shorten the interval between customers. Insufficient bandwidth or electrical capacity requires a physical investment.

Three actions address these sources of underutilization:

  • Use topology-aware placement. Allocate workloads according to network connectivity while preserving suitable groups of GPUs for larger commitments.
  • Target the limiting resource. Compare additional fabric, power distribution or cooling with the revenue it enables from existing compute.
  • Shorten reassignment times. Automate secure wiping, verification and reprovisioning so released servers return to service sooner.

Radiant’s secure GPU-sharing architecture addresses the interval between customers, with FlightDeck tracking each server’s readiness for its next allocation.

The Third Test Is Adapting Without Rebuilding

An integrated system contains assets with different useful lives. Compute can require a refresh while electrical and cooling infrastructure remains suitable for continued service. Workload changes can also require reconfiguration before the hardware needs replacing.

For example, a cluster designed for a large training reservation may later support smaller inference deployments. Longer contexts change memory and storage requirements. Agent workloads alter demand across CPUs, GPUs and networking, as Radiant’s analysis of agentic AI infrastructure explores.

Specialization is justified when the customer commitment supports the investment. The residual-value assessment must then establish which other workloads the capacity can serve, the modifications required and the time needed to make the transition.

Hardware refreshes require an equally explicit assessment:

Changes System requirements to reassess Investment implication
Higher-density racks Electrical distribution and cooling capacity Determine whether the refresh requires upstream investment
Different cooling requirements Liquid temperatures, flow rates and connections Establish which parts of the cooling system remain usable
New cluster topology Fabric bandwidth, ports and cabling Include network changes in the deployment budget
Additional compute block Available power, cooling and network capacity Include enabling infrastructure and any interruption to existing services

Preserving an upgrade path does not require purchasing future equipment in advance. It requires defining technical limits, reserving space and access where justified, and identifying what can remain in service. Radiant’s work on repeatable factories and infrastructure interfaces follows this principle. 

Optimize the Return on the Whole Factory

Building as a computer requires investment decisions to reflect their effect on the complete service. A component’s purchase price is only part of its economic impact.

For example, a low-cost storage option can leave GPUs waiting longer for data exchange, reducing output from a much larger compute investment. A scheduling policy can increase GPU activity while pushing inference response times beyond the customer’s service commitment. Both improve a local metric while weakening the service the business sells.

Capital allocation therefore needs a consistent basis for comparison. For inference, assess the cost of serving the same workload at the required quality and latency. For reserved clusters, assess the cost of delivering the contracted configuration, performance and availability. Include deployment costs, operating expenditure and the effect of upgrades on revenue.

This approach changes investment priorities. Additional networking may produce a greater return than additional GPUs when communication limits output. Retaining an older compute generation may be preferable for workloads it serves profitably when replacement gains do not justify the transition cost.

What the Building as a Computer Must Deliver

Radiant’s integrated model brings facility engineering, power availability, compute, software and financing into a common investment process. The objective is to capture the performance of an integrated system while retaining economical options for deployment and change. That means designing for the demand the factory serves today and accounting for the investment required to serve what comes next.

Token industrialization has begun and the building as a computer changes what and how much an AI factory can produce. But it’s the design that determines how long that advantage pays.

Related Articles