Start with the customer and the unit being sold
A colocation operator may sell space, power and connectivity. A hyperscale-oriented operator may contract large blocks of capacity. A GPU cloud provider may monetize compute by time or reservation.
Understanding the revenue unit is the first step because it determines what utilization means and how costs are recovered.
Colocation economics depend on contracted capacity and service mix
Revenue can reflect power commitment, rack or suite arrangements, connectivity and other services. The quality of a long-term contract can affect financing and predictability, while vacant or underutilized capacity can reduce returns.
Simple comparisons should therefore separate pricing structure from actual occupancy and contract quality.
GPU-cloud economics add a technology cycle
GPU-cloud providers combine infrastructure and compute economics. Hardware utilization, accelerator generation, network design, energy cost and replacement cycles can all affect the business model.
A high nominal hourly rate does not automatically imply high profitability because capital intensity and utilization may also be high.
Capex and opex must be separated
Land, buildings, electrical systems, cooling and compute hardware can create substantial upfront capital requirements. Power, maintenance, staff, network and service costs continue over the asset life.
Business-model pages should show which party bears each cost under different commercial structures.
Utilization and financing can dominate outcomes
Infrastructure businesses often carry high fixed costs. Utilization therefore affects unit economics, while financing cost and contract duration influence project returns.
The ROI calculator should be used to test scenarios rather than turning one assumed utilization rate into a universal benchmark.
Risk differs by model
Colocation may face power, construction and customer-concentration risk. GPU cloud adds hardware obsolescence, pricing competition and utilization risk. Other models may shift more risk to customers or suppliers.
A useful comparison should show these differences and avoid claiming that one model is categorically superior.
Business-model comparison: the same megawatt can monetize very differently
The useful unit of analysis is the relationship between customer, asset, pricing unit and utilization. A colocation operator can monetize space and committed power, while a GPU cloud provider layers compute hardware and usage economics on top of facility capacity. That difference changes capex intensity, technology-cycle risk and the meaning of utilization.
| Model | Typical unit sold | Major fixed-cost exposure | Key utilization question |
|---|---|---|---|
| Retail/wholesale colocation | Rack, cage, suite, kW or MW commitment | Land, shell, electrical and cooling infrastructure | How much built capacity is contracted and occupied? |
| Hyperscale capacity | Large blocks of dedicated capacity | Large project capex and power procurement | How concentrated and durable are customer commitments? |
| GPU cloud | GPU-hour, instance-hour or cluster commitment | Facility plus rapidly depreciating compute hardware | How consistently are expensive accelerators earning revenue? |
| Managed AI infrastructure | Capacity plus software/operations service | Infrastructure and operating platform | Does service revenue justify additional complexity? |
Information-gain contribution: revenue-per-MW is not treated as a universal benchmark because the numerator can include different services and the denominator can represent built, energized, contracted or utilized capacity. A defensible comparison must define both sides of the ratio.
Decision implication: investors and operators should stress-test utilization, customer concentration, financing cost, energy exposure and technology refresh cycles separately. The ROI calculator can model some of these variables, but audited company economics remain the strongest evidence for company-specific claims.
How to test a business model without inventing an industry benchmark
A defensible model starts with unit economics that can be traced to the operator's actual contract structure. For colocation that may mean contracted power, occupancy, recurring rent and pass-through energy charges. For GPU cloud it may mean accelerator utilization, realized price per GPU-hour, ancillary service revenue and hardware depreciation. These are related businesses, but the same ratio can mean different things in each.
The next step is to separate accounting outcomes from operating drivers. EBITDA margin, return on invested capital and free cash flow are useful company measures, but they do not explain why a site performs well. Power cost, customer concentration, construction timing, financing, churn, utilization and refresh capex are the underlying drivers that should be tested.
Where public filings are used later, AIDataCenterHQ should cite the filing near the company-specific claim and preserve the reporting period. Where a scenario uses hypothetical values, the page should label them as assumptions. That distinction allows both readers and AI systems to tell observed evidence from analysis.
- Define the revenue unit.
- Identify fixed and variable costs.
- Measure utilization with the correct denominator.
- Separate observed filings from modeled assumptions.
- Stress-test financing and refresh risk.
Before using a benchmark in a real decision
Check whether the numerator and denominator use the same commercial boundary. A revenue figure that includes managed services cannot be compared directly with a pure colocation revenue figure, and an MW denominator can refer to built, energized, contracted or utilized capacity. The definition should be written next to the metric.
Then identify whether the figure is observed, guided by management, or modeled by the analyst. These categories carry different evidentiary weight. AIDataCenterHQ should preserve that distinction in tables, captions and structured data so a retrieved passage does not lose the qualification.
Evidence and decision notes
The following sources are used as evidence anchors for the decision points on this page. Each source answers a different part of the question, so figures should be interpreted within the source’s geography, date, methodology and scope.
| Evidence anchor | What it supports on this page |
|---|---|
| Equinix 2025 Form 10-K | Reports recurring revenue streams including colocation and interconnection, showing how service mix can materially change data-centre revenue composition. |
| Digital Realty 2025 Form 10-K | Discloses leased-facility exposure and related renewal risk, illustrating how ownership structure can affect operating risk even within a large data-centre portfolio. |
| AWS EC2 Capacity Blocks pricing | Shows accelerator infrastructure sold through capacity reservations with region- and GPU-specific rates, a different monetization model from conventional colocation. |
Implementation and Decision Guidance
- Identify the customer and pricing unit first.
- Separate contracted capacity from actual utilization.
- Map capex and opex to the party that bears them.
- Include financing and technology-cycle risk.
- Use scenario modeling instead of universal profitability claims.
Frequently Asked Questions
How do data centers make money?
Through models such as colocation, large capacity contracts, cloud infrastructure and GPU compute services, each with different pricing units and cost structures.
What is the main economic driver?
There is no single driver, but utilization, pricing, capital cost, power and contract structure are often critical.
Is revenue per MW a reliable benchmark?
Only when the underlying business model, utilization, customer mix and measurement method are comparable.
How does GPU cloud differ from colocation?
GPU cloud monetizes compute capacity and adds hardware-cycle and utilization risk, while colocation primarily monetizes facility capacity and related services.
Why use an ROI calculator?
Because infrastructure economics are sensitive to assumptions that are better tested as scenarios than treated as fixed industry averages.