> For the complete documentation index, see [llms.txt](https://doc.duaer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/guides/total-cost-of-ownership-gigawatt-ai-data-center.md).

# Total Cost of Ownership of a One Gigawatt AI Data Center in 2027

This article from the Duaer documentation site explains why a capital budget figure alone is an unreliable measure of the total cost of ownership of a one gigawatt AI data center. It shows how to build a more credible model that covers capital, power, cooling, hardware refresh, and utilization.

## Why Gigawatt Scale Changes the Way Costs Are Modeled

A one gigawatt AI data center is not simply a larger version of an ordinary server room. At this scale, the question of how much it costs no longer has a single answer. The finance team sees a capital budget, the engineering team sees a grid interconnection request and a cooling system, and the operations team sees a fleet of accelerators that may become obsolete before the building's loans are paid off. Many proposals still show one total for capital expenditure and call it the total cost. That figure usually leaves out operating costs, schedule risk, and the expenses that only appear once the facility is running.

The real problem is that gigawatt projects are often committed years before the first workload runs, and errors in the model are hard to fix afterward. If a team underestimates power costs, or assumes that hardware lasts as long as the building, the result may be a facility that is fully depreciated on paper but still cannot recover its investment. This article explains how to build a total cost of ownership view that is honest enough to support a real investment decision.

At small scale, costs roughly track the number of machines. At gigawatt scale, costs are set by a series of thresholds. Grid connections, substations, transmission upgrades, on-site generation, and backup systems at this size are lumpy investments that do not grow in a straight line with capacity. Doubling the load does not necessarily double the bill, and a one-year delay in grid approval can cost more than a small swing in hardware prices.

The first step, therefore, is to split total cost into three categories and model each one separately: capital costs that are sunk once construction begins, recurring costs that vary with energy and staffing, and refresh costs tied to computing hardware. If these are mixed into a single annual number, the figure hides the fact that each one feeds a different decision. Land and building choices lock in decisions for decades, computing equipment is replaced every few years, and power contracts can be renegotiated but only within the range set when they were signed.

## Where the Capital Actually Goes

A common mistake is to treat the building as the main investment and to regard computing equipment as an add-on purchased later. In modern AI projects, IT equipment is usually the largest single line item, and the infrastructure around it, including power distribution, cooling, and networking, is designed around its scale. If the computing plan changes, the surrounding infrastructure changes with it.

A practical check is to list each capital item and ask whether it was specified for the current hardware plan or for a generic design. A facility designed for one generation of accelerators often needs costly retrofits when rack power density rises. For this reason, electrical and cooling capacity should be specified as a range of densities rather than a single value, and the model should show how costs change when density reaches the upper end of that range.

## Power: Both a Cost and a Schedule Risk

For a facility of this size, electricity is often the largest recurring cost, and it is also the constraint most likely to delay the whole project. A sound model should include the contracted power price, the expected load factor, the cost of any on-site generation, and exposure to price swings in the market. It should also include the cost of waiting. If the facility is finished but cannot receive power for several months, capital sits idle while interest and depreciation keep accumulating.

A common shortcut is to model power as the electricity price per kilowatt-hour multiplied by installed capacity. This approach is too optimistic in two ways. It assumes the facility runs close to full load all the time, and it ignores the cost of backup capacity that must be paid for even when it is not used. A better approach is to model energy consumption as a function of expected utilization, list reserve and redundancy as a separate item, and test a scenario in which the energization date is pushed back.

## Cooling and Efficiency: Reading the Metrics Carefully, and Accounting for Refresh Cycles

Efficiency metrics such as Power Usage Effectiveness (PUE) help compare facilities, but they are easy to misread in a cost model. A good ratio on paper does not always mean lower total electricity costs, because the metric depends on how it is measured and on the local climate. In some regions, cooling also raises water use, and water availability can affect both permitting and operating costs.

A more practical approach is to model total energy consumption for the facility rather than rely on the ratio alone. Convert the design into an annual energy estimate under real weather and load profiles, and add water costs where they apply. Compare cooling options on the same basis, including their capital costs and the maintenance regimes they require. A cooling system with a lower upfront price but frequent specialist maintenance may cost more over the facility's full life.

The most important mismatch in gigawatt-scale planning is the difference in service life between the building shell and the computing equipment. The building and major electrical systems may be designed to last for many years, while accelerators are refreshed on a much shorter cycle, and their economic life depends on how quickly newer chips deliver better performance per watt and per dollar.

If the model applies the same depreciation period to every asset, it will distort the economic picture. Divide assets into separate categories, assign each a realistic life, and show equipment refresh spending as a recurring item rather than a one-time purchase. Then test how sensitive the results are to the refresh interval. A short refresh cycle raises annual costs but may improve output per unit of power. A long cycle reduces spending but may keep the facility running older, less efficient equipment for longer. Neither choice is automatically correct, but the trade-off should be visible.

## Utilization Drives Returns: Build the Model Before Trusting the Total

The most common gap between a planned total cost of ownership and actual results comes from utilization. A facility designed for high load but run at a lower average load has a higher cost for each unit of useful work. Idle capacity still carries fixed costs such as financing, staff, maintenance contracts, and part of the energy reserve.

For this reason, costs should be expressed per unit of useful output, such as the cost per available accelerator-hour, or the cost per unit of delivered capacity sold to customers. Then show how that unit cost changes at different utilization levels. This makes it clear how far the return on investment depends on whether the facility can be filled. If readers are interested in returns as well as costs, the same logic applies to [discussions of return on investment for enterprise AI](https://doc.duaer.com/guides/ai-roi-in-business/), where the central question is whether benefits arrive as quickly as the plan assumes.

A usable total cost of ownership model for this kind of facility usually contains the following core elements: capital spending by asset category and realistic life, a power and energy plan with a utilization curve, a refresh schedule for computing equipment, staffing and maintenance costs, financing costs, and a timeline that includes delay scenarios. Every assumption should have a clear source or a stated reason for the value chosen. Run at least three scenarios: a base case, a delayed energization case, and a high density or low utilization case. Report the range of results rather than a single number.

The model must also be readable by people who did not build it. Decision makers should be able to see which inputs drive the results. If changing one assumption moves the outcome more than all the others combined, that assumption needs the closest scrutiny. Teams that want a broader framework for judging AI project costs can also compare this approach with [how enterprise AI adoption costs are commonly estimated](https://doc.duaer.com/guides/enterprise-ai-adoption-cost/), which likewise separates one-time spending from recurring spending.

Teams that want to turn this kind of multi-scenario comparison into a repeatable process, rather than a one-off spreadsheet, can set up a workflow in Duaer that defines inputs, tests scenarios, and shares results. This is a practical option when a team needs the same model to keep updating as power contracts and hardware plans change.

## What to Do This Week, and a Summary

Choose one gigawatt-scale proposal that your team is evaluating and write down its five largest costs, covering both capital and recurring items. For each one, record the single assumption that affects it most, such as the power price, energization date, density, refresh interval, or utilization. Then build a one-page sensitivity table that shows how the total changes when each assumption moves across a realistic range. You will likely find that only two or three inputs dominate. Those are the inputs to verify with suppliers, grid operators, and hardware planners before committing any capital.

If you want to develop that one-page table into a shared model that your team can keep updating, you can visit https://www.duaer.com, sign up for a trial, and build the workflow and test your own scenarios there.

The total cost of a one gigawatt AI data center is the sum of many decisions made under uncertainty, and a single capital figure rarely shows the full picture. A credible view separates capital costs from recurring and refresh costs, treats power as both a price and a schedule risk, reads efficiency metrics with care, matches asset lives to their real economic cycles, and expresses costs per unit of useful output. When the model is built with multiple scenarios from the start, the numbers it produces are ones that decision makers can rely on.

## Questions

### What does the total cost of ownership of a one gigawatt AI data center usually include?

It generally falls into three categories. The first is capital costs that are sunk once construction begins, including the building, electrical systems, cooling, and IT equipment. The second is recurring costs that change with energy and staffing, including electricity, backup capacity, maintenance, personnel, and financing costs. The third is refresh costs tied to computing hardware. Modeling these three separately makes it easier to see how each decision affects the total.

### Why is power both a cost and a project schedule risk?

Electricity is usually one of the largest recurring expenses, and grid connections, substations, and transmission upgrades are often the steps most likely to delay a project. If a finished facility cannot receive power for a long time, the capital still accrues interest and depreciation but generates no revenue. For this reason, a model should include a delayed energization scenario and list backup capacity costs separately, rather than estimating power as the electricity price multiplied by installed capacity.

### How can I assess the effect of hardware refresh cycles on total cost?

Divide the buildings, electrical systems, and accelerators into separate asset categories, assign each a realistic service life, and show equipment refresh spending as a recurring item. Then test the results across different refresh intervals. A short cycle raises annual costs but may improve output per unit of power, while a long cycle lowers spending but may leave older, less efficient equipment in service. The key is to make this trade-off clearly visible in the model.