Nvidia’s GPU revenue-share model: access now, economics to verify

Nvidia’s announced GPU revenue-sharing model is an infrastructure arrangement with AI cloud providers—not a published, standard offer for startups to exchange a percentage of their application revenue for GPUs. A founder buying compute needs to understand the cloud contract, not assume Nvidia’s agreement with the provider applies directly to their company. Nvidia’s explanation distinguishes those roles.

As of October 6, 2026, availability needs confirmation. On August 27, Reuters, citing the Wall Street Journal, reported that Nvidia had paused some deals. Nvidia responded that the business model remained in place and continued to evolve. That is neither confirmation that every proposed deal is available nor evidence that the entire initiative was canceled. Reuters’ report makes a current, written capacity offer more useful than the launch announcement.

What Nvidia actually announced

Nvidia described a revenue-sharing and credit-support model that enables AI clouds to procure Nvidia infrastructure. The providers sell Nvidia-powered cloud services; Nvidia earns hardware revenue plus a share of cloud revenue on the supported capacity. Startups, model builders and enterprises are prospective users of that infrastructure. The announcement directs customers seeking capacity to Sharon AI and Firmus. Nvidia’s announcement

The initial plans were substantial, but they did not confirm that all the GPUs were immediately available:

• Sharon AI: a six-year collaboration covering 72 MW of new Australian data-center capacity and up to 40,000 Grace Blackwell GB300 GPUs. Its release describes the same provider-level revenue-sharing and credit-support structure. Sharon AI’s announcement
• Firmus: a partnership running through 2034, anchored by a planned 360 MW campus in Batam, Indonesia, covering up to 170,000 accelerators across several Nvidia platforms through 2027 and 2028. Firmus’ announcement

Together, those plans cover up to 210,000 GPUs. They do not establish a startup’s allocation, delivery date, price or service guarantee.

The financing mechanism addresses a different problem from free compute credits. Reuters reported that Nvidia sought to rent capacity back from providers if they could not sell it, giving them a guaranteed buyer and helping them borrow to fund chip purchases. That supports infrastructure financing; it does not establish that a startup’s own minimum-spend obligation disappears when demand falls. Reuters

Price the contract, not the financing story

First establish who pays whom, and for what. Separate three possible arrangements:

1. An ordinary cloud bill from a provider whose infrastructure has Nvidia financial support.
2. A customer compute contract with deferred payments or usage credits.
3. A customer contract that explicitly takes a share of your revenue.

Do not model the third unless it appears in your proposed agreement. Nvidia’s launch announcement does not publish a standard startup revenue-share rate, repayment schedule or equity requirement.

Reuters subsequently relayed the Journal’s report that proposed provider deals included Nvidia receiving 50% of cloud revenue above a threshold. That reported term is not a 50% claim on every startup’s sales, nor a universal customer price. Reuters’ account

If your actual offer includes revenue sharing, compare the same workload under both contracts. For an additive share:

Monthly deal cost = base compute charges + revenue-share payment + other fees

Check whether the share is additive, replaces a charge, or stops after a repayment cap. Define the revenue base: all company receipts, one product, or only workloads served on the supported capacity? Resolve refunds, taxes, bundled products and reseller sales before forecasting.

Hypothetical example—not Nvidia pricing: suppose a deal reduces monthly compute charges by $10,000 but adds 10% of covered revenue. The saving disappears at $100,000 of monthly covered revenue. Above that, the share costs more than the discount, assuming the same workload and no other differences.

That is why the model should include successful growth and engineering improvements—not just a downside case. If you reduce inference cost through caching or smaller models while the revenue share remains unchanged, the contract can absorb some of the benefit. Track contribution margin after compute, revenue sharing, support and required human review, not just the lower initial invoice.

Five checks before committing

Ask for a term sheet and service schedule that answer:

• Capacity: Which GPU, region, start date and allocation are committed? What remedy applies if delivery slips?
• Performance: Can you benchmark your workload, including latency, throughput, networking and storage costs?
• Cash obligations: What minimum spend, prepayment, credit expiry or deferred-payment liability survives weak usage?
• Control: Are workloads, customers, competing hardware or other cloud providers restricted? Who can change those rules?
• Exit: Can you buy out the share or migrate? Does payment continue after the workload leaves, and what audit or data-access rights survive?

Also separate infrastructure-backed capacity from customer-backed demand. A financed GPU fleet is not proof that your customers will renew at prices covering delivery costs. For the related diligence problem, see AI startup circular revenue red flags.

The deal is worth considering when verified capacity removes a real bottleneck and the all-in economics remain acceptable after growth, optimization and migration. Do not exchange a temporary compute shortage for an uncapped claim on a durable product’s revenue without pricing that trade explicitly.