NVIDIA starts taking a cut of the AI clouds it powers

NVIDIA starts taking a cut of the AI clouds it powers

Good morning ๐Ÿ‘‹ NVIDIA didn't just sell more chips this week. It found a way to own a slice of what happens after the sale.

In today's issue:

Get tomorrow's issue in your inbox.

One concise AI brief, sent after the signal clears the noise.


๐Ÿ”ญ THE ONE THING

๐Ÿ’ฐ NVIDIA starts taking a cut of the AI clouds it powers

NVIDIA just quietly became a landlord: its new financing structure pairs AI clouds with NVIDIA infrastructure, and instead of only selling the chips, it now collects a cut of the cloud revenue those chips generate. Sharon AI is first in, committing to 40,000 GB300 Grace Blackwell GPUs, while Firmus is chasing the same terms with a 360-megawatt, 170,000-GPU campus in Batam, Indonesia. No dollar figures were disclosed, which is the tell: NVIDIA is financing its own demand curve so smaller clouds can build capacity they couldn't otherwise afford, then taking a slice of what it earns. That's fine while GPU depreciation outruns the revenue share. The day it doesn't, NVIDIA is holding the hardware and the downside both.


๐Ÿง  MODELS & RELEASES


๐Ÿ”ฌ RESEARCH HIGHLIGHTS


๐Ÿ› ๏ธ TRY THIS

Put a gateway in front of your model calls before the quota fights start

NVIDIA's revenue-share deals are about to pour more GPUs into partner buildouts, which means more tenants sharing the same capacity pool. AWS just published the unglamorous fix for that world: five resilience patterns for LLM inference, tested with LiteLLM sitting in front of Bedrock.

1. Drop a LiteLLM gateway between your app and the model API instead of calling it direct. It's free, runs locally, and handles routing and failover for you.

2. Set a fallback chain (primary model, then a secondary, then a cheaper one) that fires the moment you hit a 429, before a user notices anything's wrong.

3. Give each tenant its own rate-limit bucket. AWS's own test: a caller capped at 3 RPM landed 60% success, while callers at 10 RPM hit 100%. Skip this and one noisy tenant starves everyone else.

4. Hammer your primary model in staging until it throttles, then confirm the fallback catches it silently. If your app throws instead, the config's wrong, not the model.

Prompt: Review this LiteLLM config for resilience gaps. Confirm every primary model has a fallback, check that rate limits are set per tenant instead of globally, and flag any single point of failure: one region, one account, one model.

Worth a look


๐Ÿ”— QUICK LINKS


See you tomorrow.

Pradeep Perugu

Get inovAIte in your inbox.