ExpertsFM

Dylan Patel — Deep dive on the 3 big bottlenecks to scaling AI compute

Dwarkesh Podcast · March 13, 2026

5 Selected Lessons:

framework · 2 heuristic · 2 reasoning_pattern · 1
CapEx-to-online-compute timing model
framework based on: data cited Dylan Patel

Source

Dwarkesh Podcast — Dylan Patel — Deep dive on the 3 big bottlenecks to scaling AI compute (March 13, 2026) · at 0:00 ▸

When this applies

when evaluating any large capital announcement to figure out how much is actually productive capacity this year versus future setup spend

The takeaway

Decompose any big reported spending figure into the portion that produces output now versus the portion that is prepayment for future capacity.

Why it works

Large capex figures bundle immediate deployable spend with deposits, construction, and purchase agreements for multi-year future capacity, so the headline number overstates current-year output.

One level up

Headline financial totals should always be time-decomposed before drawing conclusions about current capability.

Where it stops holding

This stops working when a company's capital spending is genuinely all short-cycle (no long lead-time components), making the decomposition trivial or unnecessary.

Detail

procedure:
  • Identify the total announced capex figure
  • Separate out spend tied to this year's incremental capacity (chips, immediate construction)
  • Separate out spend that is deposits/prepayments for future years (turbines for '28/'29, construction for '27, PPAs)
  • Recognize that the actual new capacity added this year is a fraction of the headline spend
benchmarks: {"2026_US_incremental_capacity":"~20 gigawatts","google_capex":"$180B spanning multiple future years"}
rationale: Phased deployment and long lead times mean capex is always partly forward-looking.

In their words

A portion of this is not spent this year. A portion of that capex is actually spent the prior year.
Applying the Alchian-Allen effect to compute pricing and model quality choice
framework based on: reasoning Dwarkesh Patel / Dylan Patel

Source

Dwarkesh Podcast — Dylan Patel — Deep dive on the 3 big bottlenecks to scaling AI compute (March 13, 2026) · at 19:39 ▸

When this applies

when a fixed cost increase is applied uniformly to a cheap and an expensive version of a good

The takeaway

When a fixed cost is layered on top of tiered goods, the relative premium for the top tier shrinks, nudging demand up-market.

Why it works

Adding the same fixed cost to both a cheap and expensive good shrinks the relative price gap between them, so the marginal cost of upgrading to the better good falls, pushing buyers toward the higher-quality option.

One level up

Economic shocks that raise base costs uniformly don't just raise prices — they restructure relative incentives toward quality.

Where it stops holding

This stops working when the fixed cost increase is NOT proportionally uniform across tiers, or if there's no willingness/ability to pay the now-smaller premium at all.

Detail

procedure:
  • Identify two quality tiers of a good sharing a rising fixed input cost
  • Note that fixed cost increase is same absolute amount for both
  • Observe the relative price ratio between tiers compresses
  • Predict demand shifts toward the higher-quality tier
rationale: The hopper went from $2 to $3; if it can make a million tokens of Opus and two million of Sonnet, the price differential between Opus and Sonnet decreases as GPU price rises.

In their words

Right. So the hopper went from $2 to $3 and if the hopper can make a million tokens of Opus and it can make 2,000,000 tokens of SONNET, the price differential between Opus and SONNET has decreased because the price of the GPU has increased by a dollar from 2 to 3.
Centralizing intelligence in the cloud rather than on-device for cost/power reasons
reasoning_pattern based on: reasoning Dylan Patel

Source

Dwarkesh Podcast — Dylan Patel — Deep dive on the 3 big bottlenecks to scaling AI compute (March 13, 2026) · at 2:24:14 ▸

When this applies

when deciding how to distribute computation between many edge devices and a centralized server in any resource-constrained deployment

The takeaway

When compute is scarce and expensive, concentrate the most capable processing centrally and batch it, pushing only lightweight interpolation/execution to the edge.

Why it works

Centralizing the most capable models in the cloud lets you batch-process across many devices (amortizing compute cost), use larger/more-capable models than would fit on any single device, and avoid consuming scarce leading-edge chips and power budget on low-power edge hardware that AI data centers also need.

One level up

Resource scarcity favors centralization of intelligence/compute over distribution, because centralization enables batching and avoids duplicating scarce hardware across many edge nodes.

Where it stops holding

This stops working when latency requirements are too strict for cloud round-trips, network connectivity is unreliable, or when chip/power scarcity eases enough that distributing intelligence no longer competes with data center capacity.

Detail

approach: Push high-level planning and long-horizon reasoning to a large cloud model running at high batch size; limit on-device models to low-power, low-intelligence interpolation of received directives.
signals:
  • on-device processing can't batch, increasing per-unit cost
  • edge devices would otherwise need leading-edge chips, competing with data center chip demand
  • cloud models can simply be made larger/more capable than any edge-deployable model
rationale: If you do all of the processing on the device, I believe it would be more expensive because you can't batch... we're in a semiconductor shortage world, and any robot you deploy needs leading edge chips.

In their words

So now that 200 gigawatts gets lower if deploying millions of humanoids.
Demand destruction cascades down the value chain by margin thinness
heuristic based on: data cited Dylan Patel

Source

Dwarkesh Podcast — Dylan Patel — Deep dive on the 3 big bottlenecks to scaling AI compute (March 13, 2026) · at 1:21:00 ▸ · at 1:23:41 ▸

When this applies

when a shared input cost shock propagates through a market with firms of varying margin cushions and contract durations

The takeaway

An input cost shock disproportionately destroys demand in the low-margin, short-contract segment of a market before it meaningfully affects the high-margin, long-contract segment.

Why it works

Firms with thin margins and short-term supply contracts absorb cost shocks fastest and most severely by cutting volume, while firms with fat margins and long-term contracts absorb the shock slowly through price increases rather than volume cuts.

One level up

Shared cost shocks don't distribute evenly; they concentrate damage wherever margin buffers and contract protection are weakest.

Where it stops holding

This stops working when low-end firms have alternative substitutes or can pass costs through just as easily as high-end firms (e.g., via brand loyalty or price-insensitive customers).

Detail

rule: Expect demand destruction to concentrate in low-margin segments during a shared cost shock.
threshold: Xiaomi and Oppo cutting low-end/mid-range smartphone volumes by half; global smartphone volumes projected to fall from 1.4B to possibly 500-600M within a couple years.
rationale: Low end gets cut by more than half, high end gets cut by less than half because high-end buyers will buy them even if they get a little bit more expensive.

In their words

It's like low end gets cut by more than half, high end gets cut by less than half because you and I will buy, know, the high end phones that cost north of a thousand dollars, we'll buy them even if they get a little bit more expensive.
Supply chain capacity expansion lags because incumbents aren't 'pilled' on demand until it's undeniable
heuristic based on: reasoning Dylan Patel

Source

Dwarkesh Podcast — Dylan Patel — Deep dive on the 3 big bottlenecks to scaling AI compute (March 13, 2026) · at 46:07 ▸ · at 53:12 ▸

When this applies

when an entire supply chain systematically under-forecasts a fast-emerging source of demand because incumbents aren't yet convinced it's real

The takeaway

A supply chain's capacity ceiling reflects the least-convinced participant's belief about future demand, not the most bullish buyer's actual need.

Why it works

Each layer of a supply chain builds capacity based on its own belief about future demand; if upstream suppliers aren't convinced ('pilled') about a downstream secular shift, they underbuild relative to what buyers believe they'll need, creating a persistent 'whip' lag where capacity chronically undershoots real demand.

One level up

Systemic underinvestment in a fast-growing sector persists as long as any critical layer of its supply chain remains unconvinced of the sector's trajectory, regardless of how convinced end-demand participants are.

Where it stops holding

This stops working once every layer of the supply chain becomes equally convinced and races ahead to overbuild, or when actual demand turns out to be lower than believed, vindicating the cautious suppliers.

Detail

rule: Expect systemic capacity shortfall as long as any critical upstream supplier remains unconvinced of secular demand growth.
threshold: OpenAI/Anthropic know they need X; NVIDIA builds X-1; downstream suppliers build X-2 or X/2.
rationale: You end up with the time lag for this whip to react... the sort of AI pilledness and desire to increase production is so long.

In their words

OpenAI and Anthropic, they know they need x. NVIDIA is not quite as AGI pilled, and they they're building, you know, x minus one, and you go down the supply chain, everyone's doing minus one.