Your AI team wants guaranteed compute because a product launch cannot wait in a queue. Finance sees a long-term obligation. Infrastructure leaders see deployment risk. The board sees an asset that could lose economic value before demand arrives. Each view is valid, but none is enough to make the decision.

The real question is not how many accelerators you can finance. It is whether you will retain enough control over capacity, allocation, economics, and exit to support the product strategy you are financing.

A capital headline is not a capacity plan

On August 10, NVIDIA said it was working with Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs, and KKR on independent financing platforms intended to mobilize more than $500 billion of third-party capital over time. The arrangements were memoranda of understanding subject to final agreements. The announcement did not disclose how much capital had been committed, how much would be debt, what the financing would cost, which guarantees would apply, or who would absorb the first loss on individual projects.

For your planning purposes, $500 billion is evidence that a financing architecture is being attempted. It is not evidence that a particular accelerator, in a particular region, will be available to your workload on a particular date.

A financing announcement and usable AI capacity are separated by five gates:

1. Capital intent: potential participants agree to explore a financing structure.
2. Committed financing: signed terms identify the capital, conditions, guarantees, losses, and responsible parties.
3. Funded project: money is drawn and placed behind a defined site, operator, equipment order, and customer case.
4. Commissioned infrastructure: accelerators, power, cooling, networking, storage, and operating systems work together.
5. Accepted workload capacity: your representative workload meets its required throughput, latency, reliability, location, and quality conditions, and your organization has the contractual right to schedule it.

Only the last gate belongs in a committed product roadmap. The preceding gates belong in the risk register until their conditions are satisfied.

Define capacity through an acceptance test rather than a hardware count. A credible acceptance schedule names the approved hardware or equivalent, deployment location, start date, workload benchmark, surrounding infrastructure, availability expectations, scheduling rights, and remedies for failure. Raw accelerator-hours are not enough when different hardware and software stacks produce different amounts of useful work.

Benchmark the application you intend to operate. For customer-facing inference, that may mean completed requests at the required latency and quality. For training, it may mean time to a defined checkpoint under an agreed configuration. For batch processing, it may mean accepted records processed inside the required window. You are buying productive output, not a data-center inventory count.

Financing rearranges control across several parties

Traditional procurement can make ownership and control look like the same thing: the company buys equipment, installs it, and decides how to use it. Infrastructure financing can separate those rights. A project company may own the assets, a lender or lessor may finance them, an operator may run the cluster, and one or more customers may contract for capacity.

That separation is not inherently bad. It can bring more capital into infrastructure without requiring every AI company to fund an entire build from its own balance sheet. It does mean you must stop using ownership as a proxy for control. A financier does not necessarily run the daily scheduler, and an operator that runs the scheduler does not necessarily have the unrestricted right to allocate the capacity. Contracts distribute those powers.

Control layer	Question to answer	What can fail if it is unclear
Capital	Who funds later phases, and what conditions can stop or delay that funding?	Your roadmap assumes an expansion that never becomes financed.
Asset	Who owns the accelerators and supporting infrastructure, and what claims apply to them?	A restructuring, sale, or default changes access to assets your product depends on.
Operational	Who accepts the system, schedules workloads, plans maintenance, and responds to incidents?	Nominal capacity exists, but your team cannot use it when needed.
Commercial	Who can reprice service, approve substitutions, transfer contracts, or prioritize another customer?	Your cost or service level changes without a matching change in product economics.
Strategic	Who controls expansion, portability, resale, termination, and the exit path?	The infrastructure arrangement begins to dictate the product roadmap.

Draw a one-page control map before negotiating price. Put every relevant party on it: your company, the asset owner, project company, operator, equipment provider, cloud or hosting provider, capital provider, and any anchor customer whose commitment supports the financing.

Then assign a named decision-maker for each material action:

• funding the next deployment phase;
• accepting capacity as production-ready;
• scheduling and preempting workloads;
• approving maintenance windows;
• substituting hardware or changing architecture;
• changing price or minimum-volume obligations;
• transferring the project or customer agreement;
• maintaining service during financial distress; and
• moving workloads, data, and permitted artifacts to an alternative environment.

Ask who controls each action during normal operations, a delivery delay, and a default. The answer can change across those states. If a decision is described only as something the parties will handle cooperatively, it is not yet a control right.

Synchronize the asset, contract, and demand clocks

Compute financing works when three clocks remain close enough that productive demand arrives while the capacity is economically useful and the financial obligation is still supportable. A gap between the clocks is where an infrastructure strategy turns into a balance-sheet problem.

The asset clock

The asset clock includes ordering, site readiness, commissioning, acceptance, productive operation, maintenance, and eventual migration or retirement. Its economic usefulness can change as hardware, software, and workload design change the amount of output produced per dollar.

Do not use delivery as the start of productive life unless delivery and acceptance are actually the same event. Equipment can be present while power, networking, storage, software, or workload integration is still incomplete. Tie the start of minimum payments and long-term commitments to an acceptance condition wherever the deal permits it.

The contract and financing clock

This clock includes deposits, construction funding, reservation charges, minimum purchases, lease or debt obligations, renewal dates, covenants, and termination rights. Some cash can become irreversible before the system produces useful output.

Record the date and amount of every obligation, along with the condition that triggers it. A single total-contract-value number hides the difference between cash at risk before acceptance, committed spend after acceptance, optional expansion, and charges that can be reduced when demand changes.

The product-demand clock

This clock starts with product readiness, not the infrastructure order. It moves through launch, adoption, repeated usage, monetization, retention, and workload optimization. Forecast demand is weakest when a product is new, yet that is often when teams feel the most pressure to reserve capacity.

Separate demand into evidence classes. Contracted customer obligations are different from repeatedly observed production usage. Both are different from qualified pipeline, an approved roadmap, or an exploratory product idea. Do not let sales pipeline or a launch target silently become the demand guarantee behind a fixed infrastructure obligation.

Put all three clocks on one timeline. Mark cash-at-risk dates, infrastructure acceptance, product release, the expected demand floor, renewal or refinancing decisions, and the last practical date to begin migration. A project with an attractive steady-state cost can still fail if payments begin well before acceptance, adoption is late, or migration must start before the product has recovered its commitment.

Model at least three internally defined demand cases without pretending they are equally likely:

• Defensible floor: demand supported by contracts, repeated production behavior, or an operational requirement the business has already accepted.
• Operating case: demand supported by the current product plan and explicit assumptions about launch, adoption, and workload efficiency.
• Growth case: demand that appears if adoption or workload intensity exceeds the operating case.

For each case, calculate all-in committed cash, accepted productive output, overflow requirements, idle-capacity exposure, and the date an expansion or reduction decision must be made. Include reservation charges, power, networking, storage, operations, financing, integration, and migration where those costs apply.

Two internal measures are especially useful. Effective cost per accepted workload unit is all-in committed cost divided by production units that met the application’s acceptance conditions. Committed-capacity coverage is the defensible demand floor divided by the capacity you are obligated to pay for. These measures force finance and product to discuss the same output rather than comparing a contract total with an aspirational usage forecast.

A discounted cash-flow model cannot repair a missing control right. Treat acceptance, allocation, portability, and termination as decision constraints first. Run the financial model only after those constraints have acceptable answers.

Underwrite workloads and negotiate their failure modes

Build a workload ledger before a capacity forecast

A fleet-level utilization target is too coarse for a financing decision. Build a workload ledger that connects product value to infrastructure behavior. Every material workload should have:

• a product and accountable owner;
• a business outcome, revenue stream, contractual obligation, or verified cost avoided;
• a demand evidence class and the assumption that could invalidate it;
• a representative workload benchmark and accepted output unit;
• latency, throughput, quality, availability, and geographic requirements;
• power, network, storage, and software dependencies;
• interruption and scheduling tolerance;
• a lower-cost or alternative execution path, if one exists;
• the work and elapsed time required to migrate; and
• a stop, resize, or expansion trigger.

This ledger prevents a common allocation error: treating every accelerator-hour as equally valuable and every workload as equally inflexible. Customer-facing inference with a contractual service expectation may need reserved capacity. A batch evaluation or checkpointable training job may tolerate a queue or interruption. An experiment may belong on variable capacity until it produces evidence of durable demand.

Organize the portfolio into three commercial pools:

• Committed base: capacity supported by the defensible demand floor and workloads that cannot tolerate interruption.
• Variable capacity: burst, on-demand, or otherwise flexible supply used when actual demand rises above the base.
• Experimental capacity: a governed budget for discovery, evaluation, and new products that have not earned a long-term infrastructure commitment.

Do not copy a generic percentage split. Derive the base from observed or contracted demand, derive the variable pool from plausible peaks and service requirements, and fund experimentation as an explicit portfolio choice. If the base commitment requires the growth case to be economical, the financing is carrying product-market risk that should be visible to the investment committee.

Negotiate the contract around predictable failures

The best time to negotiate a failed commissioning test, capacity shortage, provider restructuring, or migration is before any of those events occur. Use the control map and workload ledger to examine these terms:

1. Capacity definition and acceptance: Specify the representative benchmark, surrounding infrastructure, measurement method, acceptance authority, and point at which payment obligations begin.
2. Delivery dependencies: Name which party is responsible for equipment, power, cooling, network, storage, software, and site readiness. A date without dependency ownership is not a complete delivery commitment.
3. Delay and performance remedies: Define cure periods, fee treatment, replacement capacity, and termination rights. Service credits may reduce an invoice without replacing the product capacity you lost.
4. Hardware substitution: Require an approved equivalent to pass the workload benchmark. A similar specification sheet does not prove equivalent output for your application.
5. Scheduling and priority: Define priority classes, preemption rules, maintenance treatment, incident authority, and what happens when several customers need the same constrained capacity.
6. Volume flexibility: Examine ramp timing, step-down rights, transfers, resale, and optional expansion. Confirm whether unused capacity can serve another approved workload or customer.
7. All-in economics: Identify reservation, usage, power, networking, storage, support, financing, egress, integration, and migration charges. Keep fixed obligations separate from variable charges and options.
8. Portability: Define access to the data, checkpoints, caches, configurations, and other artifacts you are entitled to move. Record supported formats, egress paths, assistance obligations, deletion requirements, and the party paying migration costs.
9. Distress and change of control: Examine notice, cure, continuity, assignment, lender consent, step-in, and termination provisions. Determine what happens to service if the project company, operator, asset owner, or customer defaults.
10. Expansion and exit: Keep future phases distinct from the initial commitment. Define the decision date, evidence required, price mechanism, and exit test for every additional tranche.

A compute-capacity agreement can create material financial and legal exposure. Commercial presentations are not a safe basis for interpreting guarantees, collateral, default remedies, lender rights, or termination liability. Have finance and qualified legal counsel review the actual agreements before treating any of those protections as available.

Govern capacity as a product portfolio after signing

The commitment is not finished when procurement closes. Review the portfolio frequently while infrastructure is being delivered and align the steady-state review with the product planning cadence. A useful scorecard includes:

• contracted, commissioned, accepted, and schedulable capacity as separate measures;
• productive utilization based on accepted workload output;
• effective cost per accepted workload unit;
• demand by evidence class;
• queues, service misses, and unused reserved capacity;
• concentration by provider, region, hardware, and operating layer;
• upcoming funding, renewal, expansion, and migration decision dates; and
• the current status of fallback and portability tests.

Attach an action to every threshold in the investment memo. If demand falls below the approved floor, pause expansion and use available reduction or transfer rights. If accepted performance deteriorates, invoke the benchmark and cure process. If demand exceeds the operating case, activate variable capacity before making the next fixed commitment. If a portability exercise misses its required window, treat the gap as an operational risk with an owner and funded remediation.

Key takeaways

• A capital target is not schedulable compute. Track the chain from financing intent to accepted workload capacity.
• Ownership, operations, allocation, and strategic control can sit with different parties. Map each right for normal operations, delays, and default.
• Put the asset, contract, and product-demand clocks on one timeline. Most hidden exposure sits in the gaps between them.
• Finance the defensible demand floor, not the entire optimistic forecast. Preserve variable capacity for growth and uncertainty.
• Define capacity through representative workload output, acceptance conditions, and remedies rather than accelerator count alone.
• Price matters only after acceptance, priority, portability, distress, and exit rights are workable.

Before your next term sheet, put product, infrastructure, finance, procurement, and legal around one page containing the accepted output, demand floor, control map, downside cash exposure, and exit test. A blank field is a negotiation issue, not a post-signature implementation detail. My default is to commit only the demand floor the product case can defend and preserve options for the rest, even when flexible capacity costs more per unit. That premium buys time to learn; a rigid commitment spends it in advance.

References

• Nate Jones’s Substack — Executive Briefing: NVIDIA and Six Banks Now Decide How Much AI Capacity You Get

---