AI Infrastructure Investment: Following the Budget Through the Supply Chain

An AI deployment budget reaches several suppliers before a workload becomes usable. A facility must provide power and cooling; compute and networking must arrive and work together; software and integration must put the capacity into service. A delay in one layer can defer spending in another.

For a supplier or investor, the question is where a defined buyer's programme creates an order, for whom and in which period. This article maps those layers and their commercial boundaries using disclosures available by December 2025. It keeps the final buyer's investment separate from the revenues reported along the supply chain.

Define the buyer and spending endpoint

“AI infrastructure spending” can mean a data-center operator's capital expenditure, an enterprise's technology budget, a cloud customer's usage bill, a public-sector grant, a server purchase, a chip order, or professional-services fees. These units sit at different points in the commercial path. A capital project can create a supplier invoice before a workload runs. A usage bill can arise without a new building. A services engagement can be funded from an operating budget even when the underlying compute is rented from a cloud provider.

Before using a headline market estimate, write down the numerator, denominator, period, and payer. For example, “fiscal-year capex by a named cloud operator,” “monthly GPU consumption by a customer cohort,” and “annual systems-integration bookings for an AI deployment” are interpretable statements. “AI infrastructure market” is not. It can hide whether the page counts hardware shipments, cloud services, electricity, software, consulting, or a mixture of all five.

The target measure should be explicit:

• Customer budget: money authorized for a workload, program, or facility.
• Supplier bookings: signed orders or contracted work, subject to the issuer's definition.
• Recognized revenue: the amount the supplier records for the delivered obligation in a reporting period.
• Cash or capex: payments or additions to property and equipment, which can precede or follow delivery.
• Capacity: power, rack, accelerator, network, or cloud availability that may be unused.
• Reachable opportunity: the portion a named supplier can serve after procurement, geography, qualification, and timing constraints.

These measures can all be useful. They should not be presented as interchangeable market totals.

Map the buyer's budget before mapping suppliers

A buyer normally funds an outcome rather than a particular component. The outcome may be model training, inference latency, data residency, an internal platform, or an AI-enabled application. Procurement then divides the program among internal teams, cloud providers, OEMs, chip suppliers, network vendors, software vendors, and integrators. Some layers are bought directly; others are embedded in a bundled price.

Start the evidence ledger with the buyer and the decision:

1. Workload: training, fine-tuning, inference, retrieval, simulation, or mixed use.
2. Deployment: public cloud, private data center, colocation, edge, or a combination.
3. Commitment: owned equipment, reserved capacity, on-demand consumption, or managed service.
4. Constraint: power, latency, data sovereignty, security, skills, time to deploy, or total cost.
5. Commercial owner: who signs the contract and who receives the invoice.
6. Evidence period: budget year, delivery quarter, usage month, or service term.

The same program can therefore produce a cloud invoice and an integrator invoice while the chip and network revenue is embedded inside the cloud provider's costs. If the analysis starts with supplier categories, it may mistake the visibility of a public filing for the location of the original spend. The buyer-led map keeps the causal path intact.

Power and facilities set the deployment schedule

An accelerator order is not usable capacity until a site can power, cool, connect, and operate it. The 2024 United States Data Center Energy Usage Report estimates historical data-center electricity consumption and provides a scenario range through 2028. Its role in this analysis is to establish that electricity and facility capacity are material constraints; it does not convert projected load into a supplier-revenue forecast.

Separate the physical enablement layers:

• Site and lease: land, building, colocation contract, and expansion rights.
• Utility connection: generation, transmission, substation, interconnection, and demand charges.
• Thermal system: air or liquid cooling, heat rejection, water, and controls.
• Rack and floor capacity: power distribution, cabling, rack density, and physical security.
• Operations: maintenance, monitoring, staffing, spares, and compliance.

These inputs have long lead times and different owners. A utility investment may serve multiple customers. A colocation provider may charge rent and power while the cloud provider owns the servers. A hardware vendor may sell a liquid-cooling system that is bundled into a rack price. Do not allocate the whole facility budget to the accelerator supplier merely because the accelerator is the visible bottleneck.

For a buyer, the right question is often “What capacity can be energized by the required date?” For a supplier, it is “Which funded site, power, or cooling decision creates an order I can fulfill?” Those questions need a location, a delivery date, and a contract boundary before they can support a market calculation.

Cloud services and owned capacity

Cloud providers combine infrastructure ownership with a service that customers consume over time. Microsoft's 2025 Annual Report describes Microsoft Cloud as a bundle that includes Microsoft 365 Commercial cloud, Azure and other cloud services, the commercial portion of LinkedIn, and Dynamics 365. It also describes investments in datacenters and AI infrastructure. The disclosure shows why a cloud-revenue number is broader than an AI-infrastructure-equipment number.

Build two linked ledgers:

Capacity ledger

• data-center region and ownership model;
• committed power and available rack capacity;
• accelerator, CPU, storage, and network inventory;
• reservation or lease term;
• depreciation, financing, and maintenance treatment.

Consumption ledger

• customer, workload, and service tier;
• accelerator-hours, tokens, storage, network egress, or another billable unit;
• reserved, committed, or on-demand price;
• discounts, credits, and minimums;
• recognized cloud revenue and period.

Capacity can be purchased before demand is visible, while consumption can grow on installed equipment without a new hardware sale in the same period. Conversely, a customer commitment can be signed before a region is fully operational. A forecast that multiplies announced capacity by a single utilization rate should be labelled as a scenario and should show the evidence for that rate.

Compute, components and rack-scale systems

The accelerator layer is more than a GPU die. NVIDIA's fiscal 2025 Form 10-K describes a data-center platform that brings together GPUs, CPUs, DPUs, interconnects, switch chips, systems, networking adapters, software, libraries, models, and services. It also identifies OEMs, ODMs, system integrators, distributors, cloud providers, enterprises, and startups among its customers.

That disclosure supports a platform map, not a claim that every platform component is separately monetized. For analysis, split the layer into:

• Compute silicon: GPU, CPU, accelerator, or custom XPU.
• Memory and bandwidth: high-bandwidth memory, local memory, and storage paths.
• Interconnect: scale-up links, network adapters, cables, and switches.
• System assembly: boards, chassis, racks, and validated configurations.
• Software entitlement: drivers, libraries, enterprise software, support, or subscriptions.

If a supplier sells a complete system, its recognized revenue may include several of these layers. If a chip company sells to an OEM, the OEM later reports a system sale to the cloud provider. The system sale is not a second end-customer budget; it is another transaction in the same chain. Preserve the supplier's reported boundary and do not decompose a bundled platform into invented component prices.

Keep foundry, memory, and packaging in their own layer

Design ownership and manufacturing revenue are different positions in the chain. TSMC's 2024 Form 20-F describes robust demand for advanced technologies used in high-performance computing, alongside advanced packaging and three-dimensional chip-stacking services. It explains the foundry role and the capacity planning relationship between TSMC, its customers, and their customers.

A value-chain model should therefore identify:

• the chip designer or custom-silicon owner;
• the wafer foundry and process node;
• memory supplier and high-bandwidth memory stack;
• advanced packaging, interposer, and chip-stacking provider;
• assembly, test, and qualification provider;
• geographic plant, capacity reservation, and lead time.

One AI server can embody revenue from several manufacturing steps, but the steps are not additive measures of end demand. A foundry's wafer revenue may be recognized when wafers are delivered, while the system vendor's revenue appears later. Packaging capacity can constrain shipment even when chip demand is strong. A buyer deciding whether to fund a new cluster needs delivery probability and qualification evidence, not a sum of every upstream company's forecast.

Distinguish rack-scale systems from component revenue

An OEM or system builder converts components into an installable unit. Dell's fiscal 2025 Form 10-K separates AI-optimized servers from traditional servers and networking, storage, and services. It describes AI-optimized servers for training, fine-tuning, and inference and notes that services revenue includes support and maintenance associated with products sold in prior periods.

This is a useful boundary for opportunity sizing. A system order can contain:

1. compute and memory;
2. storage and data movement;
3. network adapters, switches, optics, and cables;
4. rack, power distribution, and cooling;
5. firmware, management software, support, deployment, and financing.

The buyer may see one purchase order. The supplier may report product and services revenue on different schedules. A distributor or integrator may also appear between the OEM and end customer. Record whether a data point is a unit shipment, an average selling price, a product invoice, a service contract, or a delivered rack. Do not multiply server units by a headline GPU price unless the configuration, discount, warranty, and scope are known.

Networking and integration around the workload

AI clusters require more than compute. Scale-up and scale-out traffic, storage access, multi-cloud connectivity, security, and operations can require switches, optical links, adapters, cables, software, and support. Broadcom's 2025 Form 10-K describes custom-silicon solutions for AI and high-performance computing, as well as Ethernet switching and routing products for AI data centers. It distinguishes custom accelerators and XPUs from switching silicon and connectivity products.

Arista's 2024 Form 10-K describes data-driven networking for large AI and data-center environments and a strategy that connects AI centers, data centers, campus centers, and wide-area networks. It also describes software and services that manage network state and operations. These disclosures support a topology-led analysis:

• Scale-up fabric: links within a tightly coupled accelerator system.
• Scale-out fabric: switching and routing between servers or racks.
• Storage and service network: movement to storage, databases, and external services.
• Optical and physical layer: transceivers, cables, optics, and signal integrity.
• Network software and support: operating systems, observability, automation, and maintenance.

The addressable network opportunity depends on cluster size, architecture, protocol, redundancy, distance, and procurement choice. A company can have strong AI-network exposure without selling the accelerator, while an accelerator platform can include proprietary networking. Count each supplier's disclosed boundary once and state where bundled network revenue is unknown.

Place software and integration after infrastructure commitments

Physical infrastructure creates a need for software, data engineering, security, model operations, migration, training, and managed support. Accenture's 2025 Form 10-K describes consulting work that uses cloud, enterprise platforms, security, AI, data, and change capabilities, and it describes systems integration and operations services across client environments.

Integration is a service layer with its own buying triggers. It can start before equipment is delivered, run in parallel with deployment, or continue after the workload is live. The supplier may be paid for design, implementation, migration, security, data preparation, application changes, training, or managed operations. Some work is performed by the cloud provider, system vendor, specialist consultancy, or the buyer's own team.

Do not estimate integration revenue as a fixed percentage of hardware spend without evidence. Instead record:

• the work package and acceptance milestone;
• internal versus external delivery;
• named platform, data, security, and application dependencies;
• contract value, duration, and renewal or managed-service terms;
• supplier eligibility, geography, skills, and procurement route.

The same cloud migration can create consulting bookings for one provider and consumption revenue for another. Those are related opportunities, not a single revenue pool to be claimed by both suppliers.

The timing and boundaries of supplier revenue

Timing is a central source of false precision. A customer may authorize capital expenditure in one fiscal year, pay a deposit in another, receive equipment later, and consume a managed service over several years. A supplier may recognize hardware revenue at shipment, subscription revenue over a term, and integration revenue as milestones are accepted.

Use a period bridge with at least these columns:

• budget approved;
• purchase order or contract signed;
• deposit or invoice issued;
• shipment or capacity made available;
• service delivered or usage consumed;
• cash collected;
• recognized revenue;
• remaining obligation or backlog at period end.

The period bridge should also preserve the seller's accounting boundary. For example, product revenue, service revenue, and cloud consumption can have different recognition rules. A backlog or remaining-obligation figure is a contracted future amount under the issuer's scope; it is not current-period revenue and does not prove that capacity has been used.

Prevent value-chain double counting

Double counting usually enters through one of four shortcuts:

1. Adding suppliers: summing chip, server, network, cloud, and integrator revenue as though each were a separate final sale.
2. Mixing periods: combining a chip shipment, a system delivery, and a cloud forecast from different years.
3. Mixing units: adding power capacity, server units, cloud dollars, and services bookings without a conversion rule.
4. Mixing scopes: combining one company's AI-specific disclosure with another company's entire data-center segment.

Use a transaction graph to avoid the errors. Each edge should identify payer, payee, product or service, contract boundary, date, and whether the amount is gross or net. A supplier may be a customer of an upstream vendor while also selling to a downstream buyer. The model can show both relationships, but the executive total should use one defined endpoint.

When an issuer does not disclose an AI-specific split, mark the value unavailable. Do not infer it from a product name, a press release headline, or a competitor's ratio. A transparent “not disclosed” cell is more useful than a precise-looking allocation that cannot be audited.

Use a buyer-specific capture model

Market opportunity is not the same as reachable opportunity. A supplier's capture depends on its product, qualification, contract route, geography, lead time, capacity, channel, and competitive position. The same AI program can be reachable for a cloud provider but not for a component vendor that is not qualified in the buyer's architecture.

Build the capture model in stages:

Stage 1 — Eligible demand. Identify funded workloads, deployment locations, required capacity, and decision dates.

Stage 2 — Technical fit. Test accelerator type, memory, interconnect, rack design, power, cooling, software, and security requirements.

Stage 3 — Commercial access. Check approved-vendor status, channel, contract vehicle, financing, support coverage, and delivery terms.

Stage 4 — Delivery capacity. Confirm supply, packaging, rack integration, site readiness, staffing, and acceptance milestones.

Stage 5 — Economic capture. Separate booked value, recognized revenue, recurring usage, services margin, and expansion potential.

The output should be a range or a set of cases when input evidence is incomplete. It should show which missing field changes the decision. A supplier with a technically attractive component may still have zero reachable share if the buyer has an exclusive platform, an unready site, or a contract already committed to another channel.

A procurement example and its unresolved inputs

The following bridge is deliberately fictional. It demonstrates the calculation structure and does not represent a market share, company forecast, or recommended budget.

Conceptual value-chain flow for analysis only. The boxes do not represent market shares or proportional spend.

Assume a buyer has a funded AI program with one outcome, one deployment date, and a defined procurement owner. The analyst records the budget as a starting node, then tests each edge:

Scroll horizontally to compare all columns.

The table is intentionally asymmetric. Public disclosures can describe what a supplier does, but they rarely reveal how one buyer allocates a budget across every layer. That missing allocation is the research question. It should not be filled with the supplier's total revenue.

Turn evidence gaps into research questions

An evidence gap is actionable when it is tied to a decision. Use the following conversion:

• Unknown site readiness → request utility, lease, and commissioning milestones.
• Unknown accelerator mix → request workload, model, precision, memory, and performance requirements.
• Unknown network topology → request cluster size, scale-up and scale-out design, optics, and redundancy.
• Unknown cloud utilization → request committed capacity, actual usage, minimums, credits, and egress.
• Unknown integration scope → request work packages, acceptance criteria, internal staffing, and external suppliers.
• Unknown supplier capture → request approved-vendor lists, contract vehicles, delivery windows, and renewal terms.

The best research brief keeps the question close to the buyer's choice. “How large is AI infrastructure?” is too broad to guide procurement. “Which portion of an inference expansion planned from the 2025 baseline can be delivered in the target region, by which qualified suppliers, at what committed and variable cost?” is testable. It identifies the population, period, unit, and decision owner.

A supplier opportunity is strongest when a named workload, ready site, approved configuration and procurement timetable align. When they do not, show the constraint and the expenditure it delays. The result should be a map of eligible contracts at the chosen supply-chain layer, rather than an aggregate of overlapping cloud, server and component totals.