At Chiplet Summit 2026, Dr. Nasrullah framed AI’s power problem in terms nobody in the room could wave away: a 10GW challenge. Not a benchmark, not a latency target, a power budget the size of a national grid commitment. His answer was a design framework built on chiplets, with node mixing among the four techniques he laid out. My reaction, as somebody who spends most days wiring up bots and watching inference bills climb: finally, an energy conversation that starts at the silicon instead of ending with “just batch your requests better.”
I write tutorials and architecture notes for people building agents and bots. That work lives downstream of decisions like this one. When the accelerator underneath my API calls gets more efficient per joule, my cost per token moves, my concurrency ceiling moves, and the architecture I recommend to readers changes shape. So chiplet co-design is not an abstraction to me. It is the floor my stack stands on.
What co-design actually changes
The pitch behind chiplet co-design is that you stop treating the accelerator as one monolithic die and start treating it as a set of parts chosen together. A University of Michigan technical paper published September 19, 2026, reports that this approach cuts both energy and design costs for AI accelerators. Two numbers that usually fight each other moving in the same direction is the part worth paying attention to. Normally you buy efficiency with engineering effort, or you buy fast turnaround with wasted power.
The Fengshui work puts numbers on what happens when the chiplets in your pool are co-optimized rather than assembled by accident. From a pool of just eight chiplets spanning different dataflows, processing-in-memory, and network switches, the paper reports a 48.5% reduction in energy, plus reductions of 88.1%, 93.0%, and 97.8% across related energy and energy-delay-product metrics. Eight parts. Not eighty. That detail matters more than the percentages, because it says the win comes from choosing the right small set, not from building an enormous catalog.
Why a small pool is the interesting result
Anybody who has built a modular system knows the failure mode. You add parts to cover every case, then spend the rest of the project managing combinations. A pool of eight co-optimized chiplets is a design constraint that happens to produce better results than a sprawling one. That is a familiar pattern from software architecture:
- A small set of well-matched components beats a large set of loosely related ones
- Optimization at the boundaries matters as much as optimization inside each part
- Reuse only pays off when the pieces were designed with reuse in mind
- Flexibility that costs power is not flexibility you can afford at scale
Chiplet co-design is that pattern expressed in packaging and interconnect. The framework optimizes for power efficiency and design flexibility at the same time, which is the combination that has historically forced tradeoffs.
The ecosystem is moving, not just the papers
Research alone would be easy to file away. But the supporting structure is visible too. Public semiconductor programs are backing chiplet ecosystem development, and the U.S. CHIPS National Advanced Packaging Manufacturing Program explicitly includes chiplet ecosystems and co-design in its scope. On the commercial side, Cadence Chiplet Platform Solutions target the business and engineering problems teams hit when designing chiplet-based SoCs. There is also an open benchmark now evaluating AI thermal models for 2.5D packaging, which tells you the field has reached the stage where people argue about measurement methodology. That is usually a sign a technology is getting serious rather than getting hyped.
What I am taking into my own builds
I am not going to pretend a bot builder can act directly on a packaging paper. What I can do is adjust assumptions. Three of mine are shifting.
Stop assuming hardware efficiency is flat
I have been writing cost models that treat per-token energy as a fixed input. If co-design delivers energy reductions at the scale these papers describe, that input is a moving target, and architectures I rejected as too expensive may become reasonable.
Expect heterogeneity to show up in the API
A pool that mixes dataflows, processing-in-memory, and network switches is a heterogeneous machine. Heterogeneous hardware tends to surface as different instance types, different pricing tiers, and different performance profiles for the same model. Bot architectures that assume one uniform backend will need routing logic.
Treat energy as a first-class design metric
The 10GW framing is the useful part of Nasrullah’s talk. If the people designing silicon are budgeting in gigawatts, the people designing agent loops should stop treating redundant calls as free. Caching, early exits, and smaller models for easy requests are energy decisions now, not just latency ones.
Chiplets have been described as inevitable for years. What changed is that the co-design frameworks now come with published numbers, public program support, and benchmarks to argue over. That is the point where a hardware trend starts showing up in the tools the rest of us use.
🕒 Published: