Every lesson in this module has fed the same appetite: more matrix engines, more ray-tracing units, more HBM stacks, more GPUs on the fabric. The obvious next move — just make the die bigger — runs into a wall that is not economic but physical: the lithography scanner that patterns a chip exposes one fixed field at a time, roughly 26 × 33 mm. Beyond that reticle limit of about 800 mm², there is no die to make bigger. You cannot pattern it. Flagship GPUs have been parked against this wall for years.

And even approaching the wall hurts, because of an equation you met in the packaging lesson: yield falls roughly exponentially with die area, Y \approx e^{-AD} — area A times defect density D, sitting in the exponent. Reticle limit meets yield economics meets unbounded appetite, and the resolution is this lesson: stop building one die. Build several, and make the package pretend they are one. The chiplet GPU is where the packaging module stops being background and becomes the main event.

The yield arithmetic that forces the split

Put numbers in the exponent. At a defect density of 0.1 defects/cm², a monolithic 700 mm² (7 cm²) die yields e^{-0.7} \approx 50\% — every second die is scrap, and each scrap die takes 700 mm² of paid-for wafer with it. Split the same silicon into four 175 mm² dice and each yields e^{-0.175} \approx 84\%; better still, a defect now kills one small die, not the whole assembly. The expected cost per good mm² can fall by a third or more — that margin is what pays for the fancy packaging.

So the flagship GPU dissolves into parts, each sized and fabbed on its own terms:

• Compute chiplets — the shader-engine arrays, on the newest, most expensive process node, kept small enough to yield well;
• IO / memory dice — memory controllers, PHYs, media blocks, on an older, cheaper node (analog and IO barely shrink with process anyway);
• Stacked cache — SRAM dice bonded vertically (3D) under or over the compute dice, buying tens of MB of extra last-level cache with no footprint;
• all mounted on a 2.5D interposer or bridge beside the HBM stacks.

This is not a paper exercise. MI300-class datacentre parts stack compute dice on top of IO base dice with eight HBM stacks alongside; dual-die flagships fuse two reticle-limit dice over a 10 TB/s die-to-die link and sell the pair as a single GPU. The package, not the die, is now the unit of product design.

The fabric between the dice — and the energy hierarchy

What crosses between chiplets is not polite, occasional traffic — it is coherent memory traffic: cache lines, ownership requests, the L2's internal conversation, now walking between dice. A load issued on one compute die must reach an L2 slice on another and come back as if the seam did not exist. The die-to-die fabric (UCIe-class links, or proprietary equivalents) therefore runs at on-package energies and enormous width — and yet it is not free. Here is the hierarchy that rules every partitioning decision:

Read it as a law: every seam multiplies the energy of the traffic that crosses it by roughly ten. On-package beats the board by an order of magnitude — that is why chiplets work at all — but on-die beats on-package by another order — that is why where you cut matters more than whether you cut. A partition that forces the L2's hottest traffic across a seam burns the yield savings in the power budget.

Watch the package become the die

Step through the assembly. Every layer is a separately fabbed, separately yielded chip — the interposer included — and the finished package presents itself to software as one GPU.

The hard part: NUMA inside "one GPU"

The marketing says one GPU; the physics disagrees. A thread running on compute die 0 reaches the HBM stack beside die 0 faster — and at higher bandwidth — than the stack beside die 1. Cache lines homed in a remote L2 slice cost extra hops and extra picojoules. That is non-uniform memory access, the classic multi-socket server disease, now living inside the package. The countermeasures are classic too, re-implemented in the GPU's hardware and driver: locality-aware placement (schedule a kernel's blocks on the die whose HBM holds their data), locality-aware allocation (put a buffer in the stack nearest its consumer), and interleaving for traffic with no locality to exploit.

Above it all sits a promise of software transparency: existing programs must run unchanged, seeing one device with one memory. Vendors mostly keep the promise — at the cost of enormous engineering in the fabric and scheduler — but the tuning guides tell the truth: peak numbers arrive only when data and compute land on the same die. And stacking brings a thermal bill: a compute die dissipating hundreds of watts sits on top of other silicon, so stacked cache hides under the coolest regions and power delivery must thread up through the stack.

The consolation payoffs are real. Mixed nodes: only the compute dice pay leading-edge wafer prices. Reuse: the same compute chiplet ships in four SKUs — two dice here, eight there — and the same IO die serves two generations. The die was a compromise forced on us by lithography; the package is a portfolio.

Run the crossover

Here is the whole economic argument as a loop: a monolithic 700 mm² die versus four 180 mm² chiplets carrying 15% packaging overhead, swept across defect density. Watch the crossover — and notice which side wins when the fab is mature (low D) versus early in a node's life (high D).