When Dario Amodei left OpenAI to start Anthropic in early 2021, the viral release of ChatGPT was over 18 months away and the commercialization of LLMs was practically zero. Just a few short years later, Anthropic and OpenAI combine for ~$100B of ARR and a clear winner emerged in the profitable monetization of AI models in 2026 as Claude Code took the software development world by storm.

Anthropic confidentially filed for IPO on June 1^st. Over 1 month later, equity raises from hyperscalers loom, and a reported OpenAI push out of their own IPO until 2027 has led some to question the ability of the labs to raise. However, Anthropic is the clear clubhouse leader in capturing the B2B market today and is doing so in a profitable manner against an unfocused and money-burning competitor.

With this lead, we expect Anthropic to take advantage of their superior business model and margins to invest in further in new models that help extend their lead and monetization over closed and open source competitors. Anthropic has the ability to truly make OpenAI dance and we see Anthropic as the first $6T company as a base-case possibility if they continue to execute. Pricing power, gross margins, business model, and profitability are all reasons for Anthropic to IPO first and put the impetus on OpenAI to open their financials and raise the necessary capital to compete and fund the massive AI buildout still to come.

We’ve already seen 2 AI Labs IPO this year (Zhipu and Minimax from China), but Anthropic would be the first AI lab of this scale to do so. A confidential filing means there are no public numbers disclosed. Fortunately, the Tokenomics team at SemiAnalysis works to build the financials from the bottom-up by SKU, tier, and customer type. Recently, a WSJ article on Anthropic’s financials confirmed the accuracy of the work our Tokenomics team does across labs and hyperscalers to help investors, corporates, and other stakeholders understand the economics and financials of the AI Ecosystem.

In this article, we’ll dive deep into the work our team has done in the Tokenomics Model and walk you through the financial details of Anthropic, how that compares to OpenAI, where we see the market moving, and implications for the value chain and broader AI market. While other SemiAnalysis work focuses on the technical aspects of AI Labs, this piece will focus solely on the current and future financials, margin economics, and long-term outlook for Anthropic.

Read more

AI Debt Financing will become a multi-trillion-dollar credit market, with over $7T of debt outstanding by 2029 driven both by AI IT Capex and AI Datacenter Capex needs for Neoclouds, datacenter builders, and even hyperscalers. This will make it the second largest asset backed debt market after the US mortgage-backed financing market at just over $13T.

Annual AI Capex – including GPUs, networking, storage and attached CPU compute as well as for the Datacenters to house AI compute – will be well north of $2T in 2028. Cumulative AI Capex from 2024 to 2029 will reach ~$11.1T, and credit markets will be the main funding source for this buildout.

The surge in borrowing requirements to date has driven by briskly growing demand from AI labs and hyperscalers, and the construction of AI clusters to service this demand was made financeable by long-term take-or-pay compute contracts backed by hyperscalers, with the most common offtake period being 5 years. Though this article will mainly focus on financing AI IT Capex - that is, GPUs and related capex like storage, networking and CPUs attached - there is much that also needs to be done to support the growth of datacenter capex financing. A much more detailed breakdown of both AI IT Capex and AI Datacenter Capex can be found in our AI TCO Model and AI Datacenter Model respectively.

Executing on any AI Compute buildout requires assembling all three legs of what we call the AI Project Trinity – Capital, Offtake, Datacenter:

• Capital: As of today, lenders require an offtake contract or a backstop from an investment grade hyperscaler before they will provide debt financing.

• Offtake: To secure an offtake, you first need equity capital to demonstrate you can place deposits for the required IT equipment, but to raise equity – one needs to demonstrate that they have an offtaker and lenders in place!

• Datacenter: Lastly, an aspiring Neocloud must either have a solid offtaker and lending lined up in order to convince datacenter operators to rent colocation to them, or the Neocloud must build a datacenter themselves.

Yet this is far from an impossible trinity, and many Neoclouds have been executing on cluster build-outs. Deals have been happening, but they come together thanks to clever structuring of one or more legs of the Trinity, close sponsorship of or matchmaking by capital providers like private equity firms that have been serial providers of capital to Neoclouds and Datacenters, and of course, some good old-fashioned risk taking on the part of everyone involved.

Our forecasts for GPU shipments and datacenter capex for the next few years imply that the total outstanding AI debt financing needs will quickly surpass the size of all other US asset backed markets.

But growing this debt market from hundreds of billions in 2024 and 2025 to ~$7.1T by 2029 is no mean feat – there are a number of significant obstacles that must be overcome for the debt market to reach this size and for the compute market to serve more than just hyperscalers and large AI labs:

• Hyperscaler backstops are not infinite: Hyperscaler balance sheets will not be able to backstop trillions of dollars’ worth of compute, yet outside of the four corners of a 5-year hyperscale backstopped compute deal, the appetite to lend drops off almost entirely. If the lending market does not evolve beyond this template, once hyperscalers exhaust their capacity to backstop deals, there will be no further projects to lend to.

• Lenders are still on the learning curve: Private credit and private equity have led the charge on lending to the first batch of large Neoclouds, but as spreads compress over time, and as capital needs increase, a broader set of lenders will need to be tapped, yet most banks still have a nascent understanding of AI Cluster total cost of ownership, the AI compute market as well as tokenomics and end demand and still hide behind the shield of an investment grade offtake or backstop.

• Capital providers lack tools for pricing and managing risk: There are very few well-constructed price indices for GPU rental outside of our own SemiAnalysis GPU Rental Pricing Index. GPU rental transactions are all on a bilateral basis and not generally publicly available, and there is no active derivatives market to provide a pricing signal or a good reference for GPU residual value.

The current Neocloud market structure has a few other issues. The most pressing problem to solve is broad-based access to compute for renters other than hyperscalers and large AI labs, as well as the limited supply of shorter-term rentals given that most lending is for the 5y backstop template.

For example, VC-backed AI startups and inference providers may be cash rich, but they want large clusters on short term contracts so they can quickly get to their next round of funding and reload on compute. With most Neoclouds thus far preferring to stick with doing large 5y offtakes, these startups are forced to take on larger prepayment or longer contracts than they want, rent fewer GPUs than they need, end up using different GPUs than they would prefer, and often have to settle for start dates far into the future.

Inference providers in particular are very contracted time sensitive compared to training focused AI Labs. While AI Labs are able to commit for longer periods like 3 years and beyond, inference providers are completely unwilling to sign for longer than 1y and would rather forego access to compute than take the risk of committing for any extended period of time.

When it comes to shorter-dated rentals for everyone else, it is still a seller’s market. At this point, we are only aware of a few Neoclouds that are still offering 1y rentals, and they are setting aggressive terms for rental – sometimes requiring prepays of up to 100% of the total contract value. Neoclouds have so much demand for their GPUs that they are able to solve for a prepay amount that can entirely fund the cluster capex, meaning a theoretically infinite IRR as they can stand up a cluster with no cash out the door on their part!

Enter: The Nvidia Backstop

In 2025, we wrote extensively about how datacenter capacity was the bottleneck for AI compute growth. By early 2026, the datacenter supply situation improved considerably, but it became clear that chip production was now the limiting constraint. Now – mid-way through the year – it is clear that financing will now be one of the most significant obstacles to ramping large scale compute broadly available to everyone.

This is why Nvidia has stepped in and has started backstopping GPU rental offtakes themselves. In the backstop program, Nvidia provides a take-or-pay commitment to Neoclouds – a minimum revenue guarantee on the underlying GPU capacity. In exchange for this backstop, Nvidia also shares in a portion of the Neocloud’s revenue earned above the backstop level.

The Neocloud is of course free to rent to any other customer they would like for any term length they deem commercially reasonable and indeed the intent is for the Neocloud to never actually have to invoke the backstop.

Nvidia’s backstop program has a few key objectives:

1. To broaden compute availability: This objective has two dimensions, to open up the compute market well beyond just a few large hyperscalers and AI labs and to ensure rental contracts of varying contract terms (tenor) are available and not just 5y terms – particularly short terms of less than 1 year,

2. Support evolution of the GPU financing market: To ease lenders into funding Neoclouds with a varied book of clients and rental contract tenors by buying time for lenders to get up the learning curve and adopt tools to price and manage risk,

3. Grow Neoclouds: Provide early support so Neoclouds can grow rapidly and establish a track record and demonstrate the viability of their business model and client books so that they can become platforms that can be banked on attractive terms as well as take up datacenter obligations with greater ease. This broadens the base of buyers beyond just a few hyperscalers that will pit their own custom silicon solutions against Nvidia’s systems.

With this backstop in hand – the Neocloud can much more easily assemble the AI Project Trinity:

• Capital: Lenders look to Nvidia’s backstop and its AA/Aa2 investment grade credit rating and are satisfied to lend matching the length of the backstop. With a viable go to market plan and an Nvidia backstop, equity can be raised to fund deposits to secure equipment and the various payments needed to start developing the cluster.

• Offtake: Having the backstop in hand and with funding for the cluster, Neoclouds can then tap previously unaddressed offtake demand outside of just the typical 5-year AI lab or hyperscale offtake.

• Datacenter: However, even with the backstop in place, securing the final leg of the Trinity and obtaining datacenter capacity remains challenging absent a creative datacenter rental structure or resorting to a self-built datacenter. Here, Nvidia is diving even deeper, as it has started backstopping datacenter leases.

The incremental revenue from the backstop program will be significant, but Nvidia stands to gain far more from these backstops than this additional revenue. They aim to do nothing less than entirely reshape the structure of the GPU market itself. We have already discussed how the TAM they can sell into will become bottlenecked very soon if a 5y hyperscaler backstopped offtake is the only viable deal structure.

In January 2026 for institutional subscribers, we first discussed how Nvidia was becoming the Central Bank of AI. A central bank exists to supply liquidity when others in the banking system are unwilling to step in, supporting economic activity until others are ready to take over.

Most in the neocloud ecosystem are unable to raise enough debt for large GPU buildouts unless they lease to the big hyperscalers directly. Nvidia doesn't want the market to be the same handful of concentrated buyers. The small buyers want GPUs, can pay for them, but they can't offer credit ratings to creditors funding the build out. In mid-2026, Nvidia is clearly showing it stands ready to offer this support as the central bank.

How Nvidia’s Backstops are Structured

Nvidia’s backstop program is typically six years in length, and during these six years, Nvidia stands ready to purchase compute at pre-agreed price levels that vary over the time period. Each Neocloud is expected to negotiate the backstop terms individually, and we can expect that different Neoclouds may end up with different revenue share and backstop schedules. The below table is an illustrative example to explain the basic terms of the program – we present a backstop pricing curve that we believe to be on the lower end of the backstop range – in this case at an average of $2.36 over the six-year period, but we expect that most Neoclouds will negotiate higher backstops.

Let’s start by exploring Neocloud economics under the backstop program by considering a few different scenarios. In the first scenario, the Neocloud focuses on a customer base that rents at a 1-year or lower tenor, so we model the 1-year rental price for a GB300 starting at $6.75/hr for the first year before decaying over time as the overall market cost of compute declines. As with any business that is operating a “curve trade” – that is investing long and renting out on shorter tenors – we should expect that in theory the average realized rental price over the project lifetime should be slightly higher than the current 6y fixed price of ~$4.00. This is to compensate the Neocloud for taking on future price risk.

In any given year, the Neocloud will earn 100% of the rental price up to the backstop amount, but in respect of the amount which the rental price exceeds the backstop, the Neocloud will share a portion of this revenue with Nvidia.

In the table below, we show workings for this scenario. Let’s walk through an example of how to calculate the Neocloud’s revenue share. In the case where Nvidia earns 40% revenue share, we see that in year 1, the Neocloud will charge its customers $6.75/hr on average. Of this, the Neocloud earns the full amount up to Nvidia’s year 1 backstop of $3.68/hr, but for the difference between $6.75/hr charged to customers and the $3.68/hr backstop amounting to $3.07/hr, Nvidia will earn $1.23/hr and the Neocloud will earn $1.84/hr. In total, the Neocloud will realize $5.52/hr for the first year, which of course is lower than the $6.75/hr that they would have earned without the backstop. Over the six years of this scenario, the Nvidia take rate works out to be about 18% on average, but without the backstop, there would be no cluster!

Our second scenario analysis illustrates how the backstop math would work with a 6-year fixed price offtake. This scenario is admittedly an oxymoron – if you can get a 6-year fixed price offtake, then you of course do not need an Nvidia backstop and would thus would certainly not want to pay the revenue share out to Nvidia. Turning around and renting out compute on a 6-year contract would also be against the spirit of Nvidia’s backstop program as this deal would do nothing to further the objective of supplying compute for shorter tenors to a variety of different buyers, especially emerging workloads.

It is important to highlight that while Nvidia does have meaningful internal compute needs, neither Nvidia or the Neoclouds have any intention of using the backstop, and thus it is not surprising that the backstop levels would result in a typical Neocloud earning a zero or slightly negative project IRR.

In the table below, we illustrate the economics of renting to Nvidia under the backstop. This scenario would only materialize if the Neocloud is unable to find sufficient third-party customers at market-clearing rental and must activate the backstop.

That said, this scenario is exactly why the structure is financeable. Though the IRRs earned under this scenario will turn out to be near zero or even slightly negative, the Neocloud will at least still be able to cover debt payments, making lenders comfortable with this structure. Loan underwriting for clusters with an Nvidia backstop will evaluate debt service coverage ratios in the scenario in which the backstop is triggered to determine how much funding can be provided.

The table below summarizes the return profiles under the various scenarios discussed above as well as displaying the economics of a Neocloud renting at the same prices but without any backstop.

We see that the short-term 1y rental book scenario clearly offers the best IRR among the backstopped scenarios at 25.4%, and these IRRs could realize even higher if the rental market turns out to be strong enough such that 1y and shorter rental rates decay by less than we modeled in the curve below. As expected, the IRRs are higher without a backstop – reaching as high as 40.7% when renting for 1y tenors with no backstop. But if Neoclouds activate the backstop and rent to Nvidia at those prices, they can expect to earn zero or negative IRRs.

How to Price a GPU Loan

Many lenders are already being sounded out on the Nvidia backstop structure. They use the typical hyperscale backstopped compute deals as a starting point for their credit assessment but instead substitute Nvidia’s credit rating.

Let’s briefly review how the GPU financing market works before we explain how this market is evolving to cater to the Nvidia backstop. Pricing for Neocloud financing with a long-term offtake is heavily driven by credit spreads for the hyperscaler or other company that is providing the offtake as opposed to following the Neocloud’s credit spreads. Instead – the Neocloud’s execution risk is what drives the spread above the underlying hyperscaler’s credit spread.

Readers may notice the huge gap between CoreWeave 5y unsecured bonds at ~10% and the 5.9% that CoreWeave paid for the fixed-rate tranche of their DDTL 4.0 $8.5B delayed-draw term loan, which was backstopped by Meta. This 5.9% yield works out to about 90 basis points wider than Meta’s 5y bond yield of ~5.0%. This can be interpreted as the market pricing CoreWeave’s execution risk with respect to that particular project at 90bps.

We breakdown the main type of financing we see today in the table below from lowest credit risk to highest credit risk.

A natural question to ask is why has financing not evolved outside the four walls of 5-year IG offtake take-or-pay contracts? Neocloud financing has been challenging because it involves financing a complicated and novel stack of infrastructure and IT equipment where end demand for tokens is still new, not well understood by lenders, and lacks a long history from which to draw insights on risk management from. For lenders, it is much easier to focus on the hyperscaler offtake or backstop as there is no need to dive deep into tokenomics or rapidly evolving AI models and delve into the minutia of which scale-up network topologies perform best on the all to all collective – at the end of the day, it is hyperscaler risk.

Neoclouds have also had a strong incentive to stick with this recipe. To fund a cluster that they intend to rent on shorter terms with a broad book of customers, a Neocloud would have to fall back on unsecured funding. For a top Neocloud, this would mean paying an additional 4% interest, which would significantly impact the economics of the deal given the 70-80% loan to value ratios used to finance GPUs. In our modelling, we show that increasing funding from an all-in cost of 5.62% to an all-in cost of 10% drops PBT margins from 14.8% down to only 5.4%. Unsecured lending to a top Neocloud would probably be around 10%, but expect even more expensive unsecured financing for smaller Neoclouds with a shorter track record.

Lastly, let’s discuss how banks will size lending to Neoclouds.

The most important debt ratio that lenders look at is the debt service coverage ratio (DSCR). DSCR is calculated as the ratio of the project’s cash generation divided by total debt interest and principal payments in each period, and it is a measure of how well covered the debt payments are by the cash flow of the business.

When it comes to the Nvidia backstop, banks look at the DSCR ratios assuming revenue earned under the scenario where the backstop is activated. They are looking for a DSCR of at least 1.3x, particularly for the first few years of GPU financing agreement and size their loans to ensure that this bar is met. This typically corresponds to a 70-80% loan to value (LTV) ratio.

Great Expectations – How the GPU Financing Market will Come of Age

GPU financing will have to rapidly evolve if it is to meet the staggering capital needs we outlined earlier in this article, and financing Nvidia backstopped clusters is the vanguard of this huge shift. Lenders in the past were not comfortable financing projects with price risk and have wanted a long-term offtake from a strong credit, a residual value cushion, a parent guarantee, a vendor backstop or some other floor under the asset. However, lenders are now starting to look deeper into Neoclouds’ business models, with our assistance and due diligence consulting services. Even though they have the Nvidia backstop in their back pocket, the highest quality lenders are now utilizing SemiAnalysis to scrutinize Neoclouds’ operational quality, go to market plan, customer book and pricing strategy.

This is a healthy development – and the Nvidia backstop provides the support that lenders need to get up the curve and prepare for the era when they will finance Neoclouds as a standalone platform basis without any external backstops or guarantee, just like they would understand any other business they lend to that invest in the long term yet are exposed to shorter-term price risk – be it petrochemical companies, memory chip manufacturers and the like.

We think that initial lending will be at a wider spread than the current 5y backstopped hyperscale deals which come in at around SOFR + 225bps (roughly equivalent to a Z-spread of 195bps, or about 5.9% total yield) but at a tighter spread than CoreWeave’s 5-year unsecured corporate bond which has a yield of ~10% (roughly equivalent to Z-spread of 600bps).

Tools that GPU Lenders Will Need

Lenders will also need tools to price and manage risk in the new GPU lending world order. They will need a good GPU rental price index, a way to forecast GPU rental prices into the future and a model for estimating and tracking GPU residual value over time. They will need some way to differentiate among operator quality and a framework for understanding the differences in operator capability. They will also need to be able to model end demand, and how token demand maps into GPU demand.

Luckily – at SemiAnalysis, we have already launched products that address many of these needs!

Our GPU Rental Pricing Index tracks bilateral contract prices across the entire term structure, from on-demand to 5-year deals, across all major GPU SKUs, giving lenders and investors a transparent, transaction-validated benchmark where none previously existed. The H100 1y index is freely available for public use!

Meanwhile, our AI TCO Model has been forecasting GPU rental prices since 2023 and provides a complete three statement financial model complete with return metrics like IRR, return on invested capital, debt service coverage ratio and more. In our consulting practice, where we have provided technical and consulting due diligence to clients that have provided tens of billions in capital to Neoclouds, we have used the AI TCO model as a tool to validate many of their commercial assumptions and help underwrite the investment cases. The AI TCO Model also includes a framework for calculating GPU residual values and much more.

ClusterMAX is the only Neocloud rating system in the industry. Our ClusterMAX rating system evaluates GPU cloud providers across 10 criteria including reliability, networking, and pricing, giving capital providers a standardized quality framework to assess counterparty and collateral risk. We do significant custom diligence as ClusterMAX cannot be used for commercial purposes without our authorization.

Our tokenomics practice tracks end token demand and consumption closely across hyperscalers and AI labs with a focus on SKU and model level ARRs for all key labs, model performance, token pricing, and more.

Lastly, our InferenceX benchmarking product continually measures and tracks real-world GPU inference throughput and token efficiency across inference systems, models and software configurations, enabling lenders and operators to quantify the productive output, and therefore the revenue-generating capacity, of a cluster they are financing. It is an important resource for mapping token demand into GPU demand.

Current and Future Backstop Activity

Nvidia’s backstop program is only getting started, and we see announcements coming faster every quarter. Many Neoclouds are already deep in negotiations with Nvidia, and there are still others that are considering engaging with the backstop program. Let’s briefly discuss the deals that have been announced to date – all of which are in the Asia Pacific region so far.

The first is SharonAI’s 72MW AI factory in Australia. Announced in June 2026, the deal has SharonAI scaling up to as many as 40,000 GB300s under a six-year backstop. Sharon disclosed a total backstop value of $4.88B, which works out to an implied floor of about $2.33/hr/GPU on average over the six year period. Sharon AI’s footprint is now set to grow to 132MW with 102MW contracted, and the company guides to reaching more than 55,000 Nvidia GPUs in total (inclusive of the 40,000 GB300s backstopped) by mid-2027.

Firmus’s 360MW AI Cluster in Batam, Indonesia is the next major project announced with an Nvidia backstop. It will likely be housed in a DayOne facility in Kabil Industrial Tech Park (KITP). Announced just recently on June 29^th, 2026, this project shows the scale at which Nvidia is rolling out the backstop program. Firmus’ first clusters were based in Singapore and focused on H100s deployed using immersion cooling. The next key cluster launched was the 18,000 GB300 cluster in Melbourne, Australia housed in a 42MW self-built datacenter. This project was financed using a $10B USD facility led by Blackstone (Tactical Opportunities, Credit and Insurance) and supported by Coatue.

The Nvidia backstop allows Firmus to grow their business by an order of magnitude. As per Nvidia’s key objectives that we outlined above, the focus of this cluster will be to open up compute to a variety of AI Natives, Enterprises and Inference Providers, with many different rental tenors to be offered. Firmus announced that they expect $25B to $30B of customer revenue over the six years. We expect a portion of the revenue above the backstop level will be shared with Nvidia as per the structure we outlined earlier today.

Beyond this – Firmus also announced a 600MW firm-energy deal with Gunvor that will also underwrite 1.2GW of new renewables development and 1.5GWh of storage in South Australia by 2032. Firmus will still need to identify a datacenter provider or build their own datacenters before they can deploy GPUs.

We have seen many other neoclouds having backstops, but many are not public yet.

Nvidia is not the only merchant GPU vendor to utilize backstops. AMD has already been providing backstops starting last year. We wrote in our AMD article from June 2025 that AMD offered AWS, OCI, Digital Ocean, Vultr, Tensorwave, Crusoe and other Neoclouds a backstop deal, whereby in exchange for customers’ willingness to buy more AMD GPUs, AMD will stand ready to rent back a significant chunk of this capacity in the form of long-term contracts for internal AMD software development purposes if the Neocloud isn’t able to full sell their capacity.

There are many more deals in the works and we believe that many of the clusters announced to be built in partnership with Nvidia will later be confirmed to be built atop an Nvidia backstop. In the next section, we will explore how this revenue backstop will affect Nvidia’s balance sheet and income statement.

What this Means for Nvidia’s Financials

Read more

Meta’s capacity under construction just keeps accelerating. We show below Meta’s two largest campuses – these two pictures represent 2.5GW of capacity under construction! By the way, if you believed the laughable headlines that “half of US datacenters and delayed and only 5GW are under construction”, we show you here that just two datacenters are half of this. Read our piece “Stop Saying Half of US Datacenters Are Delayed” for more on why these headlines are completely off.

Of course, this naturally raises the questions of what Meta will do with this compute, and whether they’re going to flood the market with all of this supply if they turn into a Neocloud. Broadly speaking we see four major high-value use-cases, which are all differentied and very different relative to what traditional Neoclouds do:

1. Frontier AI Models: Meta has NOT given up on training frontier models. The bulk of incremental capacity still goes to Meta Superintelligence Labs, and we think the team is currently excited about their progress. A follow-up report will dive into MSL, their unique data strategy, and discuss their chances of catching up with Anthropic and OpenAI. Of course, our Tokenomics Model subscribers already know our takes and have access to all of this real-time.

2. RecSys: We believe Meta thinks they can scale up Ads recommendation systems by >10x in complexity to accelerate revenue growth. That requires both inference & training compute for their RecSys models. They can also do more generative targeted ads.

3. (SemiAnalysis Exclusive) We believe that Meta is in final talks with Anthropic to get access to private instances of Claude. This would be akin to Bedrock, Foundry, Vertex from other hyperscalers (read our deep dive here). There are multiple use-cases for Meta, ranging from internal usage, to building the premier Sales & Marketing SaaS powered by Frontier AI Agents. We expect Meta to launch a token-as-a-service endpoint and increasingly move up the stack, leveraging its network and distribution. Initially it will be their own models externally and Anthropic internaly, but over time we believe they will serve Anthropic and OpenAI models externally

4. We expect Meta to strike a few “SpaceX-type” deals. Elon is a sales genius, and he created a brand new market segment: large-scale on-demand compute at a huge pricing premium. We think Meta wants in, but selectively. After all, just a couple hundred MWs can already drive >$10B of yearly revenue! We expect a ten billion dollar Anthropic deal to kick off the flywheel.

This high optionality, with four high-value-add options, makes it easy for Meta to keep aggressively contracting compute. Meta Superintelligence remains the core engine, but if it doesn’t work out, there are many high-margin alternatives to sell compute. It is essentially a CFO’s dream and makes it very easy to go all-in on compute – we bet Susan did a 180° flip when she saw the pricing of SpaceX compute deals! Meta won’t be a normal bare-metal IaaS vendor with ~30% gross margins – all its options are high value, and enable to easily afford paying a margin to other Neoclouds in order to accelerate their fleet buildout - even if MSL doesn’t work out.

Our Datacenter Model breaks down quarter by quarter their capacity additions across selfbuild, datacenter leasing, and cloud renting. After nearly 10GW of deals signed since early 2024, the bulk of their capacity additions are now through 3^rd parties. We expect this to continue and believe that Meta will be a huge source of RPO growth for the likes of Coreweave, Nebius and others.

Our model also breaks down, quarter by quarter, Meta’s capacity into MSL, other AI, and non-AI. While MSL’s huge growth is understandable (they need to keep up with Anthropic & OpenAI!), the surge of Other AI in 2026 suggests plenty of optionality to monetize compute across RecSys, “SpaceX equivalent”, and Bedrock-type token as a service. If RecSys scales a bit less than expected, they have other options. Of course, if MSL fails, Cloud capacity will skyrocket.

Let’s now dig into these four options. We start with the SpaceX-like deal, and the Bedrock-type ambition. Then, behind paywall, we discuss the outlook for MSL and for RecSys.

SpaceX dreams – Elon’s genius deals

Elon Musk shocked the AI infrastructure world when he announced the first Anthropic deal. He double-shocked the world when he came up with the Google deal. The reason is simple: the revenue per MW of these deals are respectively triple and quadruple what peers are charging, as shown below. The profit per MW gap is, of course, even larger given the cost structure is roughly the same.

SpaceX’s pricing on the Google deal is even higher than what we observe on the on-demand or short-term rental market. Elon essentially invented a new market segment. Our AI Cloud TCO model team tracks hundreds of GPU cloud deals every year, including all contract terms like SLA, pricing, contract length etc. That’s why we have, by far, the world’s best information on GPU pricing by contract length – see a preview in our free dashboard here.

We have never ever seen a deal that large, and that short: the deal is three years, but with option to cancel from both parties within 90 days – so it’s effectively a 3-month deal with automatic renewal.

The reason this has never happened is because very few companies can do it. The financing burden excludes all the Neoclouds from participating in that market – for large clusters, they need to secure an offtaker over multiple years. The top 3 hyperscalers could’ve done it… but they all see higher-value long-term options, such as Microsoft getting OpenAI’s IP in exchange for equity investments & compute, Amazon focused on increasing the adoption of Bedrock and Trainium, Google similarly with TPUs and Vertex (now Gemini Enterprise Platform).

This effectively leaves only two companies that can truly capitalize on this new market: Oracle and Meta. For the former, we see this as a massive blow. It’s yet another piece of evidence that they could’ve done a much better job at monetizing all of their gigawatts of compute. A look at the valuation trajectory of Oracle vs SpaceX illustrates the massive divergence. For both, Gigawatts are an increasing portion of their valuation, and a large driver of that evolution within the last year.

Enter Meta. Given their laser-focus on building Superintelligence, they probably didn’t put enough thought into the Cloud option. SpaceX and Elon paved the way for them. At $50B/Gigawatt of annual revenue, it becomes an easy call. Just allocating 200MW of compute to an external customer drives $10B/yr of revenue, at sky-high margin. And the ability to cancel that contract within 90 days makes it even easier – if they want to give MSL more compute, they can, in short notice.

That’s also a perfect match for Meta’s datacenter construction strategy. A year ago, we were the first to track their new “tent” ultra-fast datacenter design. Since then, Meta tents have been popping up all over the US! By bringing datacenters online fast, even if “lower quality”, it’ll be easier for Meta to monetize compute in a SpaceX fashion.

As such, we expect Meta to announce such a deal soon. It’s a great way to get the flywheel started. Anthropic is our prime suspect, but others could step in as well, such as OpenAI or Google.

Will Meta build the new Bedrock?

Another great option for Meta is to strike a deep partnership with frontier labs to sell their models with Meta’s own compute. As said earlier, we believe they are in final talks with Anthropic to get private access to their LLMs, just like Amazon has through Bedrock (agreement explained in detail here). This means that for Meta, another way to monetize their compute will be to sell Claude. We see three main paths:

1. Part of it could be for internal usage only. Meta needs Claude tokens, and Anthropic can’t keep up with demand. There are also security & privacy layers. In the future, we could see other very large enterprises striking such deals, e.g. a JPMorgan probably won’t go all-in on Claude if they don’t have the security and privacy guarantees that private instances enables (in their own datacenters).

2. Meta could sell Claude as a service in the same way Bedrock does. They have capacity and own the full stack, from CPU to GPU to networking, with high security. However, as a new entrant, it’ll be tough to create all the enterprise relationships that AWS has. But Meta has the option to leverage their customer base of advertisers and better integrate frontier agents and LLMs into their suite, creating a new large-scale distribution path.

3. Meta could go even more vertical and start building applications. As one of the world’s largest advertising platforms, they have a path to building a Sales & Marketing powerhouse. Integrating frontier models and agents would increase their odds of building a world class solution.

There is, of course, also the opportunity to distribute models to free social media users, and to the broader Meta ecosystem including things like connected glasses. It appears more likely that they will prioritize use of their own models, but it’s good to keep the optionality, and they likely have a great path to monetization. The huge distribution potential and network effect means that the likes of OpenAI and Anthropic are likely seeing this as highly strategic, and ready to make concessions to get a piece of the pie.

Scaling Ads Recommendation systems: how much can Meta accelerate?

For Meta, the key AI story is how RecSys is contributing to revenue acceleration at massive scale. At the end of 2022 and early 2023, the market widely saw the company as entering a stage of maturity and low growth amongst an investment cycle. Today, it’s crystal clear that Meta has dramatically re-accelerated revenue growth, in large part due to GPU investments. They have been a key trigger, both on training and inference: RecSys models for ads have been getting bigger and more expensive to run, but much smarter, driving better yields for advertisers as seen in the ability for advertisers to pay higher prices while still seeing strong ROAS. At the same time the RecSys models for content have led to more time on platform across the Family of Apps, improving the monetizable surface area and leading to strong ad imprssions growth.

The key question on everyone’s mind is now – is this sustainable? How much can Meta accelerate core revenue growth? While Meta is playing catching up on the frontier lab side, the non-Meta SuperIntelligence AI chip fleet is producing outstanding ROI. We cover this split compute split between RecSys AI, Meta SuperIntelligence, and other Meta LLM products in our Tokenomics Model.

Behind paywall, we discuss the outlook for RecSys scaling, and then for Meta Superintelligence Labs.

Read more

ECTC is the industry’s premier conference for all things packaging. This year’s disclosures were closely aligned with upcoming commercial products. Intel provided an overview of EMIB-T integration, package scaling and future roadmaps. Marvell showed how custom HBM can move interface logic off the accelerator while shortening package routing. TSMC and Microsoft pushed coolant directly into silicon, while Marvell and Lightmatter brought optical interconnects onto the package.

This roundup covers ECTC 2026 technologies most likely to shape AI accelerator packages over the next several years.

Intel EMIB-T

Intel was the largest corporate presenter at ECTC. The key disclosure was EMIB-T. This is the next generation of EMIB with through-silicon vias (TSVs). After the initial announcement, Intel has filled in more of the architecture and roadmap, including tighter bump pitch, larger packages and on-bridge capabilities. Their disclosures show why EMIB-T is expected to be used in Google’s TPU v9, and why it is the most credible alternative to TSMC’s CoWoS platform for large-package AI accelerators.

EMIB-T scaling test vehicle with 2× reticle silicon content. Top-down SEM images show 110, 55 and 36 µm mixed bump pitches. Source: Intel, “Scaling the EMIB-T Advanced Packaging Technology to Address the Future HPC/AI Demand,” ECTC 2026

Intel has validated EMIB-T at a 36/35 µm bump pitch on a package with 2× reticle-sized silicon. This is a reduction over the 45 µm pitch used in Granite Rapids, and a 65% increase in bump density. Granite Rapids-AP is a large package, measuring 70 mm × 105 mm, or slightly less than 9 reticles of area. Validation for 36/35 µm bump pitches is now expanding to 4.5× reticle silicon packages, with certification targeted by the end of 2026.

The next pitch step is also underway, with Intel testing 25 µm bump pitch on a vehicle with two 1-reticle silicon dies connected through a single 3 mm × 18 mm EMIB-T bridge.

Further scaling gets harder. Below 25 µm, the solder volume in each bump becomes very small. Shorts, opens, and assembly-driven yield loss become much more likely. EMIB-T can keep scaling, but the limiter shifts from bridge routing density to bump formation, placement accuracy, and assembly yield.

Intel also showed how large EMIB-T packages can become. Full panel-sized packages are possible, but Intel framed quarter-panel packages as the practical target. It showed a 240 mm × 240 mm test vehicle, equivalent to roughly 67 reticles of area. However, we observed that the sample at the booth exhibited severe warpage. At that size, the bridge is only one part of the problem. Substrate handling, warpage, overlay, and panel-level patterning become first-order constraints. Intel is also evaluating advanced lithography approaches to keep overlay tight enough for these large substrates at quarter-panel and even full-panel scale.

While bump pitch and package size are important, the bridges matter just as much. EMIB-T is much more complex than the EMIB used in current products. It adds TSVs, more metal layers, a power mesh, and MIM capacitor layers so the bridge can carry both high-density signals and vertical power delivery. Intel showed a cross-section with 10 metal layers, including 4 routing layers, and MIM capacitors between M1 and M2. Intel focused on its improvements for HBM4E.

The “T” in EMIB-T is for TSV. Their job is power delivery. In conventional EMIB, power is delivered vertically through the substrate in non-bridge regions, but power delivery near the bridges must spread laterally through the package and die-side routing. With TSVs in the bridge, power can be delivered directly through the bridge, reducing the current path distance significantly. Intel claims that DC voltage drop can be reduced by 68-80% with these TSVs.

HBM4E is difficult because the interconnect must scale both signal density and power delivery at the same time. HBM4 doubles the pin count versus HBM3, and the PHY needs additional power rails such as VDDQ and VDDQL. These rails take routing area away from signals, raising signal density in the remaining space.

To combat this, Intel did not route every HBM channel the same way. It placed the longest signal paths on cleaner routing layers. On M9, only ~28% of the longest channel length runs through the tightest routing region, while on lower layers such as M3, that number rises to ~84%, but those channels are shorter. This keeps crosstalk and insertion loss from being dominated by the worst routes.

Power delivery is also moving into the bridge. EMIB-M introduced metal-insulator-metal (MIM) capacitors between M1 and M2, and EMIB-T builds on that approach. Intel disclosed a capacitance density of 500 fF/µm², or 500 nF/mm², roughly comparable to Intel 18A MIMs. Intel claims these on-bridge capacitors improve power delivery network (PDN) AC impedance by more than 82% versus an EMIB-T package without bridge MIM capacitors.

Intel also simulated EMIB-T with HBM4E. At 12 Gb/s, Intel showed ~67% UI eye width without receiver equalization. With a one-tap decision feedback equalizer (DFE), that improves to ~72.5%. A DFE is a receiver-side circuit that reduces interference from prior bits after the signal passes through the package channel.

Intel also simulated higher speeds of 12.8 Gb/s, 14 Gb/s and 16 Gb/s. The UI eye width remained above 60% at all tested speeds, with modest pad capacitance reduction.

Intel’s EMIB roadmap goes beyond passive bridges with only routing and capacitors. Future versions include higher-density on-bridge MIM capacitors, larger high-aspect-ratio bridge dies, sub-25 µm bump pitch, active bridges, and embedded voltage regulators inside EMIB dies. Intel has also disclosed substrate-core embedded deep-trench capacitor (DTC) concepts and >2.5 µF/mm² eMIM-T capacitors embedded below the base die, although we have not seen either in shipping EMIB products.

EMIB-T is still behind TSMC’s CoWoS platform on several vectors. TSMC has already deployed DTC/eDTC integration and is further along on integrated voltage regulators and active local silicon interconnect (LSI). EMIB-T narrows the gap, but Intel is still catching up to an ecosystem that has been executing in volume for years.

Marvell Custom HBM

At Marvell’s 2024 Industry Analyst Day, Marvell announced custom HBM. At the time, it was a vague claim with few technical details. HBM had been built around JEDEC compatibility: standard DRAM stacks from the memory vendors, standard HBM PHYs on the accelerator, and a fixed wide interface between them. At Hot Chips 2025, Marvell showed the floorplan of the custom base die. At ECTC, it finally provided the package-level details for custom HBM4E.

The JEDEC specification fixes the interface between the HBM stack and host. That is good for interoperability: any memory vendor’s HBM can be paired with any compliant host. However, it is bad for power, performance and area. The host ASIC must implement the standard HBM PHY and route a very wide, parallel interface with standardized pad placement and breakout rules. As packages get larger and HBM speeds rise, that fixed boundary makes it harder to optimize shoreline, routing density, power delivery and signal integrity.

Custom HBM keeps the DRAM core dies unchanged. Instead, a custom base die, with an optimized die-to-die interface, is fabricated on an advanced logic process. The custom base die can integrate the HBM controller, management and monitoring capabilities, custom logic, and expansion interfaces.

Marvell claims this reduces the host ASIC footprint dedicated to HBM PHYs and associated logic by ~60%, directly freeing up area for more compute, cache or I/O. The custom interface moves much of the memory-side interface into the HBM base die.

Marvell’s example uses 1024 channels at 32 Gb/s, reaching 4.1 TB/s, equivalent to a 2048-bit JEDEC HBM4(E) interface at 16 Gb/s.

The package also gets easier to route, with the custom interface shortening the interposer channel length from 6.5 mm to 1.5 mm, allowing Marvell to keep the same 9 routing layers and 2/2 µm line/space (L/S) while increasing bandwidth.

Marvell’s example uses an organic redistribution layer (RDL) interposer instead of silicon, reducing packaging costs. Organic RDL is limited to much coarser L/S than the silicon interposers in CoWoS-S or the silicon bridges in CoWoS-L and EMIB-T, which makes layout harder. Marvell relies on customized shielding and routing patterns in different sections to maximize bandwidth density while controlling crosstalk.

At GTC, Nvidia announced that Feynman would use custom HBM. Nvidia’s reasons are likely similar to Marvell: higher bandwidth, lower power, and less accelerator die area dedicated to HBM. We estimate that ~16% of Rubin GPU die area is dedicated to HBM-related logic and PHYs. Custom HBM allows Nvidia to offload much of that burden onto the HBM base die.

Custom HBM also enables expansion interfaces beyond the standard HBM link. Instead of forcing all memory traffic through the limited accelerator die shoreline, the base die can act as a secondary memory controller and fan out to additional memory. That memory could be higher-capacity, lower-bandwidth LPDDR, or even a second layer of HBM. This gives the accelerator a path to add capacity without consuming the valuable die shoreline needed for external I/O. This is relevant to AMD’s upcoming MI450 and future MI500 GPUs, which will support LPDDR for increased memory capacity.

Samsung HBM Interposer

Samsung also presented its solution for HBM4E on interposers. HBM4E pushes data rates to 12 Gb/s and above, and doubles the number of I/O pins, increasing routing complexity. HBM4E could require 2× the interposer layers versus HBM3E and 5× as much as HBM2. Due to the increased I/O count and higher data rates, power consumption is also expected to increase by 86% versus HBM3E, and 5.6 times versus HBM2.

Samsung proposed an 8-layer silicon interposer which it says reduces the layer count by 20% versus the estimated requirement. The interposer stack uses a repeated two-signal / one-ground staggered arrangement to shield high-speed signals, with 75% of the layers being allocated for signal routing.

Another key aspect of the interposer is the ultra-high-density capacitors (UHCs). Samsung does not spell out the exact capacitor structure, but they are likely similar to Intel EMIB-T MIM capacitors or TSMC CoWoS DTCs. The UHCs can only be placed on the M1 layer, which is also heavily used for signal routing. Thus, the available area is limited.

If routing is unbalanced, the capacitors get pushed to one side of the interface, creating uneven PDN behavior between the logic and HBM sides. Samsung’s layout redistributes the routing across M1 and the other layers so that UHCs can be placed more evenly across the entire interface. This reduces PDN impedance and voltage noise while keeping routing density manageable.

Samsung HBM Hybrid Bonding Thermals

Samsung also discussed HBM thermals, particularly with hybrid bonding. HBM stacks are getting faster and taller, while the logic die underneath is also consuming more power. With 16-hi HBM, the thermal resistance is still acceptable, but with future generations moving to 20-hi and 24-hi HBM, new approaches are needed.

Samsung compared thermal compression bonding (TCB) and hybrid copper bonding (HCB) for HBM on 2.5D GPU packages with 2 GPU dies and 8 HBM stacks, similar to Nvidia Blackwell. The internal HBM thermal resistance drops by 12.2% with air cooling and 12.9% with liquid cooling. Total HBM thermal resistance drops by 3.5% with air cooling and 7.7% with liquid cooling.

The improvement is uneven as HCB only addresses part of the thermal network. Samsung separates the path into internal resistance, system-level resistance, and GPU-to-HBM crosstalk. The internal resistance and crosstalk drop by ~12.5% and ~9.8% respectively, but the system-level resistance, including thermal interface materials and cooling, increases by ~2.3%.

As more power moves into the HBM base die, such as in memory-bound workloads, the thermal bottleneck shifts. This is especially relevant for custom HBM, where the memory controller and more logic move into the base die. GPU-to-HBM crosstalk becomes a smaller share of the total thermal resistance, falling from 13% at 1× base-die power to 5% at 3× base-die power.

According to Samsung, moving to HCB could allow for higher inlet temperatures or higher package power. In its estimate, moving to HCB allows inlet temperatures to rise by 1-2 °C at constant package power, or package power to increase by ~4% at constant temperature. Samsung also estimates cooling power would fall by ~7%.

Samsung also isolated the impact of HCB at the stack level. The improvement is much larger here: Baseline HCB reduces stack thermal resistance by ~19% versus TCB. Increasing the HCB pad count raises the reduction to 22.3% at 2× pad density and 29.1% at 4× pad density.

Microfluidic Cooling

TSMC showed direct-to-silicon cooling on a large GPU-like test vehicle on CoWoS-R. CoWoS-R differs from CoWoS-S by using an organic rather than a silicon interposer. CoWoS-R was chosen as it provides better warpage tolerance and process compatibility. The test vehicle uses a 3.3× reticle interposer with 4 SoC dies and 8 HBM stacks. Each SoC die consists of 4 SoC heater groups, which together cover roughly half the interposer area.

TSMC compared three approaches: a conventional lidded cold plate package, a lidless cold plate package, and its micropillar direct-to-silicon design. The lidded and lidless cases still use traditional cold plates and thermal interface material (TIM). For the last variant, micropillars were formed directly onto the backside of the SoC dies.

With conventional cooling at 1-2 liters per minute (LPM), a lidded package dissipated 1.9-2.3 kW while the lidless package dissipated 2.5-3.0 kW, using relatively warm 40 °C DI water. Both solutions saturate beyond 4 LPM because TIM becomes the bottleneck.

The micropillar test vehicle matched the lidless cold plate result at 2 LPM, then pulled ahead at higher flow rates, dissipating 4 kW at 4 LPM and 5.3 kW at 8 LPM. Across the full test vehicle, TSMC reported uniform power dissipation above 5 kW. The micropillars brought the liquid coolant into much closer proximity to the heat source, facilitating this improvement.

However, micropillars are not without downsides. TSMC had to form the micropillars after chip-on-wafer (CoW) processing without damaging the CoWoS-R structure and develop new sealant materials to keep the coolant contained despite package warpage and thermal expansion mismatch. The test vehicle passed moisture sensitivity level 4 (MSL4) with no helium leakage or sealant delamination.

Unfortunately, this was one of only 3 papers by TSMC at ECTC as compared with Intel’s 12 and Samsung’s 11.

Microsoft’s approach differs from TSMC’s in the cooling structure. While TSMC used silicon micropillars, Microsoft used straight microchannels etched into the GPU silicon. Instead of using a thermal test vehicle, Microsoft tested on an actual Nvidia GH200 GPU. This likely allowed Microsoft to capture real thermal distribution and hotspots more accurately. Microsoft tested a variety of workloads on the GPU such as HPCG and HPL, each with different compute and memory stress characteristics.

Across these workloads, Microsoft reports 51-60% lower junction-to-inlet thermal resistance for the GPU at a 1 LPM flow rate. The HBM improved less, at only 27-37%, because it was still cooled through a cold plate and TIM. Overall, this results in a 50% reduction in thermal resistance for the package.

Microsoft also showed some preliminary reliability data. While thermal performance is important, datacenter deployments also require high reliability and low downtime. Over a period of 6 months, Microsoft recorded only 9 potential clogging events across ~4370 observations. The rate declined over time, suggesting early instability after installation, followed by a more stable operating period. Even after 6 months, there was no measurable silicon erosion in the microchannels. At the node level, the GH200 successfully completed 3 weeks of repeated benchmarking followed by a 1-week continuous run at a stable package power. Microsoft is still testing cluster-level mean time between failures (MTBF) and availability.

Marvell Optical Interconnects

Another prevalent theme at ECTC was optical interconnects and co-packaged optics. Marvell had several papers in this area, primarily on its Optical Multi-Chip Interconnect Bridge (OMIB) and Photonic Fabric, both of which it acquired through its purchase of Celestial AI earlier this year.

While photonic interposers have been discussed for a few years, Marvell showed off a more localized version at ECTC. Fabricating a multi-reticle photonic interposer will likely prove challenging for yields, especially due to reticle stitching. Marvell also noted that a photonic interposer may lack features available in conventional silicon interposers such as high-density capacitors.

Marvell’s approach has a photonic integrated circuit (PIC) embedded in the organic RDL interposer only where it is needed. In other regions where optical interconnects are not required, an electrical bridge can be used instead.

As the PIC is embedded in the RDL, its grating couplers would normally be obstructed after overmolding. Marvell places a silicon/glass optical block over the grating region before molding to maintain an optical path to the top, where the fiber array unit (FAU) can be attached.

Marvell’s OMIB test vehicle has one primary XPU die and six EIC dies on top. Embedded in the interposer are six PICs (big blue rectangles), six electrical bridges (thin blue rectangles) and 12 DTC dies (small blue squares). The roughly 2×-reticle RDL interposer uses four layers at 2/2 µm L/S.

Marvell also showed off a conceptual multi-die XPU with optical chip-to-chip interconnects to reduce latency and hop count. Marvell claims that OMIB removes the shoreline limitations, since the same bridge can route both on-package die-to-die links and external optical interconnects. Marvell cites a bandwidth density of 1.8 Tbps/mm² with this approach.

The process flow shown by Marvell is chip-last, similar to TSMC’s CoWoS-L. Marvell builds an organic RDL interposer with embedded bridges, OMIB PICs, DTCs, and other components, with C4 bumps connecting it to the package substrate. Bridge TSVs and tall copper pillars connect to the RDL, and the ASIC dies and EICs are attached last.

In the near term, vertically stacked optical engines like TSMC’s COUPE are more achievable than OMIB-style connections or a full photonic interposer. Marvell connects the EIC and PIC using microbumps at 50 µm pitch, then mounts the resulting engine to either the package substrate or an interposer.

The substrate configuration can use a UCIe-S-like parallel bus at a coarse 130 µm C4 pitch, while the interposer configuration can use a UCIe-A interface at a tighter ~40-45 µm pitch. Marvell favors the substrate approach due to its simplicity and better thermal isolation.

Marvell tested an optical engine using a 5 nm (likely TSMC N5) EIC, with four 56 Gb/s TX-RX pairs for 224 Gb/s in each direction. The design uses electro-absorption modulators (EAMs) instead of the micro-ring modulators (MRMs) preferred by other companies, citing better thermal stability and a wider operating wavelength range. While these advantages are real, we believe that EAMs will prove difficult to manufacture at scale.

Marvell also compared the thermal characteristics of an optical engine connected via UCIe-S on substrate and UCIe-A both on a silicon interposer and over a silicon bridge. Under full XPU load, the PIC temperature rose by less than 5 °C on the substrate, versus ~25 °C on the interposer and ~20 °C with the bridge. The organic substrate’s low thermal conductivity and relatively large millimeter-scale air gap isolate the PIC. In both UCIe-A configurations, the fine-pitch silicon close to the XPU provides a low-resistance thermal path. There is also a much smaller air gap, at only ~100 µm, which contributes to the heating of the PIC.

The thermal transients occur within ~30 ms of an XPU power-state change. The PIC heats at ~10 °C/s on the organic substrate, versus ~100 °C/s with the bridge and ~120 °C/s on the interposer. Marvell argues that the EAM bias voltage can be adjusted electronically fast enough to track these changes, while ring modulators require heater-and-feedback loops, which are constrained by slower time constants.

Lightmatter Passage M1000

Lightmatter has previously detailed the Passage M1000’s architecture and optical interconnects, and has outlined its manufacturing approach. At ECTC, it provided a much deeper look at the assembly process, fiber attachment, and packaging results for integrating the multi-reticle photonic interposer with ASIC chiplets.

The test vehicle uses chip-on-wafer assembly to attach 15 ASIC chiplets to a four-tile M1000 interposer. We estimate the interposer measures ~2100 mm², about half of the 4000 mm² eight-tile configuration shown at Hot Chips 2025. The M1000 is highly configurable to different sizes and tile counts depending on the needs of the product.

Each of the four tiles has 32 optical waveguides at 127 µm pitch. Electrical signals and power travel from the substrate to the ASIC chips through the C4 bumps at ~176 µm pitch, two backside RDL layers, and 126 µm deep TSVs with a 10 µm width before reaching the ASIC chiplets through microbumps. The ~2100 mm² interposer occupies less than one-third of the 7200 mm² organic substrate. This ratio is closer to the logic area to package size ratio than the package-spanning interposer area of an equivalent silicon or organic RDL solution. It is unclear whether this is a consequence of the optical architecture or a design choice specific to this test vehicle.

Attaching a silicon interposer of this size to an organic substrate creates severe warpage. The module reached ~59 µm of warpage at the 260 °C reflow temperature, and ~56 µm after cooling back down to room temperature. With a 118 µm-thick interposer and C4 bumps at ~176 µm pitch, this is enough to compromise joint formation. Lightmatter used a magnetic fixture to hold the substrate flat during attachment and reported >95% electrical assembly yield, with healthy microbump and C4 joints across the package.

Lightmatter used a thermal test chip with four independently powered quadrants, each dissipating 170 W. This resulted in a power density of 1.47 W/mm² across the 369 mm² active area. At this power, the photonic interposer reached approximately 100 °C using a 25 °C coolant flowing at 1.8 LPM/kW. This validates cooling 680 W from a concentrated test-chip area in a package designed for more than 900 W across nearly three reticles of ASIC silicon.

Other Highlights

Hybrid Bonding

Hybrid copper bonding still delivers the finest pitch and highest I/O density for HPC applications. The open problem is keeping the interface extremely flat and clean while reducing the bonding temperature. Two material approaches stood out this year.

The first uses organic dielectrics, whose mechanical compliance increases tolerance to particles and surface roughness while reducing bonding stress. Mitsui Chemicals and ASE demonstrated pressure-less Cu/polymer bonding at 200 °C and 10 µm pitch. TOK and NYCU demonstrated a 10-second bonding process at 150 °C. Samples bonded at 200 °C maintained stable resistance through reliability testing.

The second approach uses fine-grain copper. Its higher grain-boundary density accelerates copper diffusion at lower temperatures, and subsequent grain growth increases conductivity. Intel combined fine-grain copper with a low-temperature dielectric stack, achieving uniform wafer bonding after 175 °C and 200 °C anneals. Electrical yield was around 60% in two of three samples, although Intel described these results as a lower bound due to test vehicle and probing limitations. The experiments used wafer-to-wafer (W2W) test vehicles rather than the die-to-wafer (D2W) process targeted by the technology.

The most aggressive pitch came from Applied Materials and EV Group, which demonstrated 450 nm pitch wafer-to-wafer bonding at 98% yield across a chain of 20 million links. Failure analysis associated open links with carbon-rich benzotriazole (BTA) residue at the copper interface. A PVD TaN/Ta barrier stack significantly improved yield. CEA-Leti separately achieved greater than 97% yield after a 100 °C anneal without plasma activation.

Together, these results show that reducing pitch and bonding temperature requires the copper, dielectric, CMP, surface preparation, and annealing to be co-optimized to achieve hybrid bonding with low warpage and no cracking. We expect continued refinement by material suppliers and equipment vendors to improve post-bond yield from 2027 onward.

Interposer Alternatives

As package sizes outgrow the practical limits of circular silicon interposers, more vendors are proposing interposer-less integration schemes beyond Intel’s EMIB-T.

Intel and SPIL placed an SRAM chiplet in the embedded-bridge layer of a fan-out embedded bridge (FO-EB) package, connecting it vertically to the logic die through 25 µm pitch microbumps. The test chip reached more than 265 GB/s/mm² at 0.24 pJ/b.

Panel-scale organic interposers provide another route around the size limits of silicon. Resonac demonstrated the individual process modules for a dry-film embedded-bridge interposer on a 320 mm × 320 mm panel, including 5 µm microvias and 2/2 µm L/S. ASE fabricated an RDL on a 600 mm × 600 mm panel, then divided it into four 300 mm × 300 mm panels for assembly with existing equipment. Its test vehicle used three RDL layers at 5/8 µm L/S.

IBM took a more localized approach with Direct Bridge Multi-die (DBrM). Chiplets are first joined along their edges, creating a mechanically rigid subassembly around a 30 µm pitch silicon bridge. The subassembly withstood more than 30 N in bending tests, versus 0.2 N for IBM’s previous underfill-only structure. This is a positive result for reducing warpage.

Unimicron modeled an even simpler structure requiring neither an interposer nor embedded bridges. Two chiplets connect through a thin silicon bridge mounted beneath them while attaching directly to the substrate. Unimicron’s simulations show that underfill between the chiplets and bridge is necessary to control microbump strain.

While TSMC’s CoWoS-R and CoWoS-L remain limited by the circular wafer on which their RDLs are fabricated, constraining package size and wafer utilization, these alternatives shift integration to panel-level or reconstituted formats or eliminate the interposer entirely. We expect similar architectures to begin appearing in ASICs over the next several years.

Thermal Interface Materials

In advanced thermal solutions, TSMC and its partners continue to dominate the show. TSMC’s direct-to-silicon cooling removes TIM1 entirely, but most near-term systems will still need better materials between the silicon and heat spreader. TSMC’s OSAT partner, SPIL, tested gallium-based liquid-metal (LM) composites, a silicone-based HS-TIM and a carbon fiber HCF-TIM, in a 55 mm × 55 mm FO-EB package. Their measured conductivities were 5.7 W/m·K and 10 W/m·K respectively, and both produced lower thermal resistance than a commercial silicone TIM at 4 W/m·K.

The two TIMs exhibited drastically different reliability outcomes, with HCF-TIM maintaining 95% coverage after 1000 hours at 150 °C while HS-TIM fell to only 75% as its silicone matrix hardened and partially delaminated. Both LM-based TIMs reduced thermal resistance relative to conventional S-TIM, with HCF-TIM delivering the best performance and reliability.

Purdue, the University of Aveiro, and UCLA took a different approach, embedding Cu/Sn microbumps in nanocrystalline diamond. The resulting interconnect layer reached an effective in-plane thermal conductivity of 500 to 600 W/m·K, around twenty times that of conventional microbumps with underfill. This is not a TIM1 replacement, but a way to spread heat laterally through the interconnect layer of a 3D stack. The process remains early, with the paper only using a single-sided test structure rather than an assembled 3D stack.

On the other hand, we saw little discussion on SiC as TIM1 or part of thermal solutions, implying a relatively long way till maturity.

Glass Substrates

Glass’s aurora dimmed somewhat this year, with fewer innovative papers presented at ECTC. However, the unsolved problem is still SeWaRe, the lateral crack that begins at a diced glass edge under RDL stress. Georgia Tech characterized the failure experimentally. Corning used finite element analysis (FEA), peridynamics, and analytical fracture mechanics to model its propagation, showing that stiff copper layers drove cracks towards the glass midplane, while compliant polymer layers changed the crack path. Corning also found that low-CTE polymers combined with appropriate glass selection could reduce the failure risk.

STATS ChipPAC investigated the assembly and reliability of large glass-core packages. Its 74 mm × 74 mm glass-core packages failed every test segment without edge coating, while the edge-coated packages completed assembly and reliability testing without abnormalities. The edge coating also reduced warpage by 33.5% relative to the uncoated glass-core package. Build-up pull-back and edge coating increasingly look like requirements for reliable glass-core substrate assembly.

On a positive note, Intel demonstrated an industry-first 510 mm × 515 mm, 24-layer glass-core panel with fully copper-filled through-glass vias (TGVs), two embedded EMIB bridges, and optical waveguides co-formed between the TGVs. The large prototype was displayed at Intel’s booth. It was processed on existing organic-substrate lines, while singulated units showed no SeWaRe after thermal shock testing.

As OSAT adopters, Amkor and STATS ChipPAC measured 30-40% lower substrate-level warpage with a thinner glass core than their organic references, although assembly defects and TGV filling problems show that the process remains immature.

Glass is making real progress, but this year’s data still support manufacturing development rather than high-volume adoption.

RDL Scaling

Finally, RDL L/S continues to shrink even as package sizes grow. The primary driver is UCIe 3.0, which supports speeds of up to 64 GT/s for future ASIC-to-ASIC and ASIC-to-HBM links. These high-speed die-to-die interconnects tighten signal integrity requirements as organic interposers grow larger and denser.

The roadmap has progressed from 10/10 µm line/space around 2015 to 2/2 µm today, with 1/1 µm emerging as the next target. Reaching the submicron era will require major changes to both RDL routing architectures and manufacturing processes. The process is shifting from semi-additive plating towards damascene for sub-2 µm copper, where CMP planarization and low-shrinkage dielectrics become the key gating steps.

Resonac used polymer damascene and panel CMP to form 2/2 µm wiring on a 320 mm × 320 mm glass panel, including a four-layer via-and-trench structure. imec and Fujifilm pushed damascene to 1/1 µm on 300 mm wafers. Ushio resolved 1.5/1.5 µm L/S over an 18-reticle field without stitching, with 16 exposures covering a full 510 mm × 515 mm panel. Sumitomo Bakelite and Georgia Tech showed a fully imidized liquid dielectric with only 4% cure shrinkage at a relatively low temperature of 200 °C and a fine 2/2 µm L/S.

As the most advanced RDL manufacturer, TSMC also collaborated with GUC to present their work on 8-layer RDL scaling, which is believed to be the near-term limit of the CoWoS-R platform. GUC demonstrated an STCO-based design and validation flow for integrating a 64-bit UCIe-A interface fabricated on TSMC N3 and integrated on an 8-layer CoWoS-R RDL.

Its STCO framework uses ground-signal-ground interleaved transmission lines to control crosstalk and skew, while simulations show that C4-side IPDs provide localized decoupling and reduce voltage fluctuation at the chiplet microbumps.

The design targets 16-36 GT/s with a 64-bit, 10-column UCIe-A interface at 45 µm bump pitch. Signal traces were routed at 2/2 µm across six layers, with the seventh reserved for power delivery. The test chip achieved a measured on-die eye width of 0.77 UI at 32 GT/s, while simulations showed an eye width of 0.74 UI at 36 GT/s. The results show that organic interposers can meet the signal and power integrity requirements for heterogeneous chiplet systems.

Stacked Memory

Samsung showed an approach to DRAM stacking that avoids TSVs entirely. Vertical Cu post Stack (VCS) connects four stacked memory dies through <56 µm-pitch, <30 µm-wide high-aspect-ratio copper posts embedded in molding compound, rather than etching vias through silicon, while also replacing the package substrate with an RDL. Shortening the interconnect cut power consumption by 41% versus a conventional wire-bonded stack, from 0.646 W to 0.384 W at iso-speed. Samsung also reported better signaling, with maximum data rate rising from 8.6 Gb/s to 11.8 Gb/s with only 8% higher power consumption.

The form factor also improves substantially, with package height and footprint each reduced by 40% while bandwidth increases 2.6× and I/O count 6×. Although Samsung’s focus is on mobile platforms like smartphones, this approach is also promising for higher-power workloads. We believe VCS and similar approaches could help future AI accelerators reach higher bandwidth at lower power and a smaller footprint, while also enabling higher-density memory modules like SOCAMMs for server CPUs.

Read more

• Widely reported responses to Tokenmaxxing budgets from companies like Meta and Uber are overstated and stem from poor incentives and employee allocation we didn’t find present at other organizations

• Budgets are now the new norm, but there’s no consensus number with budgets starting at $250 and going up to tens of thousands a month.

• Companies are downgrading default models and turning off premium tiers while employees’ game subscription M365 Copilot usage to stretch their token allowance.

Rise and Fall of Tokenmaxxing

Tokenmaxxing started earlier this year when companies like Meta and Salesforce began encouraging their employees to consume as many AI tokens as possible to boost productivity. At Meta, an employee even built a “Claudeconomics” dashboard that ranked the top 250 power users in the company. The results showed that Meta employees consumed over 60T tokens over a 30-day period, with the single highest individual accounting for roughly 280B tokens. Employees started competing for rankings like “Token Legend” and “Cache Wizard” by having agents do research for hours simply to burn tokens.

The dashboard was shut down 2 days later after The Information reported the spend.

That episode was just one amongst others in the enterprise tokenmaxxing trend in 1H26. Companies are now shifting focus from tokenmaxxing to token budgeting. Most recently, Uber made headlines for burning through their Claude Code and Codex annual budget in four months. In response, the company imposed a $1,500/month/employee limit, with over-limit requests allowed and approved on a case-by-case basis. To see if the news reports on early 2026 tokenmaxxing and now tokenbudgeting were true, the SemiAnalysis team conducted on-the-ground conversations at the Databricks AI Summit and talked with large enterprises to understand the trends.

Our View of the Data & Narrative

There are many news stories out there on tokenmaxxing and resulting budget blowouts. However, in our work in the Tokenomics Model, we estimate that 90^th+ percentile customers make up most of the revenue and are at very little risk to API revenue cuts through the rest of the year. Even Meta, who was burning through 70T tokens per month in February and is spending close to at least $50,000/year per employee (at list price) is only a 3-5% customer for Anthropic per our estimates. Ramp data shows a similar trend amongst the top customers. 99^th percentile customers spend almost $90,000/yr per employee while 90^th percentile customers spend ~$7,300. This is a stark contrast to the median Ramp customer spending just $136. Note Ramp customers are generally way more tech forward so it's already a high spend skewed distribution. The media fortune 500 is well below $100 per employee still.

Our conversations with enterprise customers, including many Fortune 500s, followed this split. Many tech forward Fortune 500s spend well under $2,000/year per employee in AI, with the larger spend mostly in the engineering and data science departments. This suggests that the s-curve of growth in enterprise usage still has plenty of runway. Today’s market is driven by the coding vertical explosion and other VC-backed AI companies whose products build on top of Anthropic or OpenAI models (90^th-99^th percentile customers who are seeing their revenue accelerate too).

What the coding market has done to AI Lab ARR will be repeated with Cyber (Mythos re-release dependent) at an even faster pace than Claude Code and again with white-collar knowledge work as Cowork, CoPilot, Codex, and Computer type products penetrate the enterprise.

The Tokenomics Model estimates coding related spend at the AI Labs on a 1^st and 3^rd party basis and ARR and margins at the application layers (companies like Cursor, Loveable, GitHub CoPilot, and more) to help investors and corporates track growth of and within the vertical. We believe that over 70% of ARR today across OpenAI and Anthropic can be attributed to coding use cases with Anthropic spend higher than OpenAI’s given the difference in B2B vs B2C mix (Anthropic 90%+ B2B vs OpenAI 60%).

Still, cheap tokens are in widespread demand. We see massive growth in spend across both the for the Token-as-a-Service (TaaS)/API Endpoint Market for both frontier models and open-source models. Our estimates for AWS Bedrock this quarter drive our total AWS growth rate number well above street. The Tokenomics Model also forecasts massive demand for TaaS providers like Together, Fireworks, Baseten, and others who make up over $4B of ARR today.​

Thus, to say, our work suggests that headlines are overblown, enterprises continue to spend, and new use case/verticals for demand and token consumption are keeping the AI train moving forward at an aggressive pace.

Budgeting: Pick a Number, Any Number

Most companies we talked with (n>50), also impose a hard cap on AI usage - though there doesn’t seem to be a token number that companies are converging towards. At the lower end, we spoke with the head of AI at a top 3 US aerospace and defense manufacturer and one of the world’s largest pharmaceutical companies which cap employees at $250 and $500 a month, respectively. At the higher end, our conversations with companies like Workday and Stripe revealed that their employees’ budgets are about $2000 a month.

A subset of companies has not yet imposed any limit at all, for what seems like two possible reasons:

1. Employees’ access to AI tools is so limited that cost simply isn’t a concern; or

2. The company has derived enough additional output from employees to justify the spend.

The financial industry is a clear example of the former. Much of it has been slow to adopt AI, and those that have moved have done so minimally. In conversations with various data scientists, analysts, and AI leads across a range of asset managers, regional banks, and auto-finance firms, the same pattern kept surfacing: employees boxed into the tools provided through Microsoft’s platform.

The ROI, where it exists, can be dramatic:

• A recruiter at Amazon responsible for scouting and placing principal engineers within the company noted that the process from initial screening call to team placement used to take 6-9 months, but with AI tools to take interview notes and create reports, that timeline been cut in half.

• An employee at a data and analytics provider serving 85% of the Fortune 500 said what used to take them a week to do, can be done in just a few hours now.

The most mature companies are implementing a soft limit, which should be viewed by employees as guidelines rather than a hard rule. At a public cybersecurity company, the Director of Analytics, who oversees all developers and data scientists, said they set a “limit” of $800 a month for juniors and anywhere from $1,600-$4,000 a month for more senior staff. Data scientists are given the largest budget, as they tend to work with larger datasets requiring more tokens, a pattern that recurs across companies with flexible budgets. Should employees exceed their allowance, managers are alerted to have a conversation rather than cutting them off until the count resets.

The Art of Token Conservation

With rising token spend and increasing executive consciousness towards that spend, employees are starting to learn to adapt. When that same aerospace and defense manufacturer first introduced its $250/month limit, some of the power users burned through it in four days. Employees can now request a higher budget, but that was not always an option. Employees now must get creative to conserve tokens. The company has disclosed that although employees have access to Claude, it has “turned-off” Opus 4.8 and Fast-Mode deeming it unnecessary. Management believes that handing employees larger token budgets would push them to automate tasks that shouldn’t be automated at all, like writing emails. We believe this anti-automation view by management teams is naive. Email, much like Slack with connectors from the AI Labs, will become more automated and AI native over time enabling greater productivity, visibility, and collaboration throughout the organization.

One global travel-tech company took a slightly lighter-touch approach. With 800 engineers out of 1,500 total employees who collectively spend a little under $10M a year on AI, it recently switched the default Claude model for all staff from Opus to Sonnet. Opus remains available but using it now requires a conscious choice. Most employees have a $200/month budget by default, though it can be increased to tens of thousands of dollars depending on seniority and role, with expected budget increases coming soon.

As more companies impose limits, many employees are unbothered as they don’t come close to the cap. Our conversations with customers at the Databricks AI Summit and in research calls showed that at many organizations most employees do not come close to the limit.

This mirrors the power usage we see here at SemiAnalysis where a handful of employees spend 4 to 5 figures per day, and others spend close to 0. Those who approach or exceed it have found ways to stretch their tokens. We have not impossed limits as the top performers are the ones utilizing a lot of tokens.

Employees of companies on the Microsoft 365 Enterprise subscription receive free, unlimited access to the standard Copilot chatbot. Because that usage isn’t tracked against the monthly budget, employees can game the system by using Copilot’s 365 chat to draft and synthesize ideas first, before spending metered tokens on Claude or Codex.

AI As Headcount Lever

The cost of AI tools sits with the company, but so does the benefit. A big 3 US airline stands apart from the others we met with in how it budgets. Its token allocation is tied to the specific project and the revenue that project is expected to bring in. When a project comes in, the financing team decides what percentage of revenue is set aside for expenses like travel and contractor fees, and now that same budget must cover token usage as well.

This reframes AI spend entirely. Companies that hand out generous allowances do so on the expectation that employees will work faster. Output expectations rise to match spend, and many workers have found themselves putting in even longer hours than before. Across over 50 conversations with medium to large enterprises, one thing became clear: the headline Uber, Meta, and other Fortune 500 tokenmaxxing stories were a result of poor incentives and lax oversight rather than an absence of high ROI activities/projects to spend those tokens on. The clearest expression of the ROI dynamic is at Amazon. Despite its widely reported layoffs, the company is hiring at a much faster pace due to efficiencies unlocked by AI tools.

Budgeting Here to Stay

Caps, soft limits, and conservation tricks are all ways of managing the bill at the end of the month. In contrast to the high numbers of token spend in the news flow, Anthropic’s own documentation says the average Claude Code usage per developer is between $150-$250 per month, and only 10% of users spend over $30 per day. One thing is clear after our on-the-ground work talking with customers: there is not a material risk present to 2H26 AI budgets and we expect Anthropic and OpenAI’s API business to continue to grow at their current net new rates m/m for the foreseeable future.

To learn more about the Tokenomics Model, including our estimates on AI Labs and Hyperscaler financials, email sales@semianalysis.com

Summary of Selected Conversations

We’ve added below a summary of selected conversations with enterprises:

Read more

Today, we go deeper and model US Grid capacity to understand the shortfall that must be filled by Behind-The-Meter solutions for datacenters.

Let’s start with key numbers: first, we continue to see a record datacenter buildout in the US, going from +21GW in 2026 to +84GW by 2030. We explained in detail last week why Datacenter Delays headlines are often overblown.

Our research suggests that BTM will power well over half of new US datacenters in 2028+, and the Total Addressable Market (TAM) for DC BTM equipment to cross 50GW/year by 2029. New Grid Capacity isn’t growing fast enough, and also needs to serve non-datacenter load growth.

The chart above shows the three core building blocks of our forecast: Expected Datacenter US Gross Power Demand, available US Grid Capacity, and New Grid Supply. We use the best of SemiAnalysis industry-leading insights to build this forecast.

The first block, datacenter demand, comes from a bottom-up forecast powered by a building-by-building model, supported by chip-by-chip AI demand forecast of the Accelerator Model, and validated by our Tokenomics Model which tracks the economics of the buildout and answers the “bubble” question.

The second building block of our Energy Model, grid headroom, analyzes supply & demand dynamics in each major part of the US grid. Our model follows the methodologies of all ISOs & RTOs and models UCAP/ICAP reserves, supply & demand growth, reliability risks, etc.

The third block forecasts new grid supply, through a bottom-up forecast produced by our new Energy Model. We track 40,000 generation assets in the US and forecast quarter by quarter Commercial Operation Date (COD) for all fuel types. We then estimate the “true” capacity value of power plants via our proprietary ELCC model, adapting to the specifics of each ISO and major non-ISO region.

Our forecast points to barely 15GW of net-new ELCC capacity being added annually, with a rising trend towards 20GW+ by the end of the decade. This is effectively all the firm capacity being added to the system that a grid operator can recognize to serve firm datacenter load - as well as other firm load like industrial plants, semiconductor fabs, etc.

Netting that accredited supply against peak demand and required reserve margins is what yields headroom itself, the spare accredited capacity a market has left to host new load after covering its own peak demand and required reserve margin. On this basis, available headroom is already approaching zero and turns negative by 2027, based on our analysis of required reserve margins across the country.

As such, we expect power generation to be a major bottleneck to grid-connected datacenter load growth (transmission is another one and will be the topic of a follow-up deep dive). All datacenter operators have already seen this firsthand: a utility tells you it can meet a 2027 load-ramp schedule, e.g., 500MW, and later comes back saying they can only deliver that load only in 2029 because the long-lead equipment grid interconnection requires, from main power transformers (MPTs) to high-voltage breakers and, in some cases, network upgrades, simply is not available any sooner. Worse, the burden increasingly falls on the buyer: securing grid-connected power now often requires developers to post substantial letters of credit, security deposits, or sign take-or-pay commitments to fund the generation built to serve their load. Switch Datacenter, for instance, closed a multi-billion-dollar performance letter-of-credit facility in 2026 to back exactly these obligations. And in many cases, despite billion-dollar commitments, the utilities don’t even face any penalties for not delivering on time.

Subscribe now

These generation and transmission constraints, combined with inadequate market incentives, makes Behind-The-Meter often the most attractive solution for GW-scale newbuilds. And we’re already observing that many top-tier developers are planning 5GW+ behind-the-meter facilities in Texas, where permitting onsite gas is easier. Our Datacenter Model covers this in extreme detail, separating the few «real» 5GW+ campuses from those that show no sign of credible development under the hood.

This is, of course, a material tailwind for BTM solutions and providers. However, key beneficiaries aren’t the usual suspects. A few months ago, we were the first to flag the risk of temporary peak gas turbine orders. Read our Core Research report “Grid Power Bad, BTM Good” – Peak Gas Turbine Orders, IPPs Challenged, But Grid Equipment Demand Accelerating” for more details.

Our new Energy Model is the best tool to forecast and understand relative market positioning by company: we track manufacturing capacity, equipment lead times, installation lead times, major deal announcements, and much more. We’ve also covered recent secondary-market developments in depth, with notably surging turbine availability.

Let’s dig in. Our argument runs in three steps, and this report walks through them in order: grid supply is structurally constrained, that constraint pushes the marginal buyer behind the meter, and that shift reshuffles the winners and losers across equipment OEMs and IPPs as the market grows across fully islanded and hybrid BTM setups.

First, we establish the supply constraint: drawing on our new Energy Model, we explain how we forecast power-plant additions, how we estimate the true capacity value of each fuel via ELCC, and how we measure the grid headroom that results.

Next, we turn to the buyer’s decision: the relative attractiveness of BTM versus grid for the largest buyers of power and compute, broken down by use case.

Finally, we examine the practical bridge between them: the hybrid co-location structures emerging in ERCOT — codified by the Batch Zero process — that blend on-site generation with continued grid access, and where we think the early winners are taking shape. We explain more on this later.

Note that this article focuses on grid constraints and behind-the-meter as a solution, but there are alternatives, like Load Flexibility. These will be the focus of future deep dives, and out of scope for this one. We briefly explain later in this article why we think BTM will be the prominent solution over alternatives like Load Flexibility.

Forecasting Power Plants: No Gas Until 2028

Our analysis of 40k generators reveals one of the core challenges for the US grid: the lack of firm, dispatchable capacity added to the market over the next two years. Our nameplate capacity forecast shows that the US industry will add less than 10GW of gas per year in 2026 and 2027, with additions only picking up in 2028 and beyond.

To achieve this forecast, we replicate our Datacenter Model methodology: it starts with an extensive analysis of construction timelines, with hundreds of thousands of empirical datapoints analyzed, backed by real-time satellite imagery. We simply don’t see enough power plants in advanced construction stage that would enable a 2026-27 delivery.

The 2026–27 shortfall isn’t the product of one bottleneck but a stack of them. First, institutional and queue friction: the intrinsic slowness of key grid stakeholders like utilities, and overcrowded generation interconnection queues. In PJM, the queue itself is no longer the binding constraint — conversion is: roughly 57GW has cleared studies and been offered or executed interconnection agreements, yet since 2020 about 24GW of projects with fully executed agreements (including 13.5GW of gas) terminated before reaching commercial operation, largely due to permitting denials, supply-chain delays, and financing that could not close. Permitting alone accounted for 29% of project milestone changes between January 2023 and January 2026, versus 23% for supply-chain delays (Powering Reliability through Market Design).

Second, the technology mix works against speed: the bulk of the gas capacity ordered by utilities is made up of CCGTs and combustion turbines. As we’ve explained in depth in our Onsite Gas deep dive, CCGTs are the most efficient way to burn gas for power, but their build is the slowest of any generation technology — construction and time from planning to COD run 4–6 years in some ISOs. Faster technologies like Fuel Cells and RICE are being aggressively secured directly by datacenter operators for onsite generation.

Third, the supply chain stretches every timeline further. Gas turbine and generator step-up transformer lead times have each extended to three to four years, versus a historical norm of roughly 18 months. That pushes total gas-plant development from a ~24-month baseline to at least four years even under optimistic assumptions, with CCGTs at the long end of the 4–6-year range.

Finally, a project may also slip for reasons beyond the plant itself such as increased equipment costs, community pushback, availability of labor, financing concerns, etc.

Renewables, Storage and ELCC

Of course, gas isn’t the only fuel that matters for the US grid. Renewables and storage are taking on an increasing share, as our Energy Model tracks in great detail. We see solar and BESS each adding over 20GW nameplate per year in coming years, as shown in the chart above. However, from a grid perspective, their value is significantly lower. As shown below, on an ELCC basis (Effective Load Carrying Capability), their contribution is minimal. We’ll explain this concept in more depth just below.

For renewables, the cause is simple. Not only are these energy sources intermittent, they’re also highly correlated. Solar’s famous Duck Curve is the best example. As you add more solar to the system, the marginal value of adding new solar declines very sharply because all plants generate electricity at roughly the same hours. In ERCOT, the rapid build-out of solar and wind has compounded this by pulling the two price signals in opposite directions. The 4CP window — the four 15-minute intervals across June-September that set transmission charges for the following year — used to sit in the late-afternoon load peak. But as renewables flatten daytime net load, it has drifted later into the evening, closer to sunset. The curtailment peak has moved into the later hours of the day, when solar output falls off and the steep net-load ramp leaves the grid short of supply. The result is a wider, steeper evening ramp that batteries have to carry until gas can pick up.

Quantifying this declining, weather-dependent value requires a dedicated metric. Utilities and grid planners rely on the concept of ELCC to do exactly that. ELCC estimates the ’true’ capacity value of a power plant to the overall system. It is also a useful gauge of available capacity headroom in a market: where excess ELCC capacity exists, the system has room to absorb a new large load, so a datacenter can interconnect — whereas a market without it does not. These entities think of their resources from a system perspective, and because each system is unique, each ELCC methodology is unique as well. Our Energy Model shows below how diverse solar ELCC is across regions.

Let’s pick a few examples to better understand how ELCC works and how it differs across regions.

PJM uses a complex formula called Marginal ELCC to account for the value of different energy resources. FERC accepted PJM’s shift to marginal ELCC accreditation in early 2024, replacing the prior Equivalent Forced Outage Rate (EFORd) method for thermal units and average ELCC for intermittent resources, alongside an hourly risk model that better captures correlated outages during extreme weather. For more details on PJM and some of their specificities, read our deep dive on PJM vs ERCOT market designs and their impact on household power prices.

Subscribe now

Methodologies diverge sharply across markets. MISO accredits resources seasonally under its newer seasonal resource-adequacy construct, reflecting how scarcity risk concentrates differently in summer versus winter; ERCOT, an energy-only market with no centralized capacity market, relies on a reliability standard and its own effective-capacity measures rather than a centralized ELCC accreditation. The practical result is that the same solar or storage asset can be credited very differently depending on the ISO. ERCOT illustrates the extreme: in some congested zones and segregated transmission corridors, planners now leave solar’s capacity contribution out of local reliability modeling altogether — a de facto ‘no-solar scenario’ that credits incremental solar at essentially zero when sizing firm capacity needs.

Everything so far has concerned solar and wind. Storage is the other half of the renewables build-out — so what about BESS? Our forecast points to a rising penetration of 2hr and 4hr BESS, which naturally have a higher ELCC value than 1hr. Longer duration BESS has more room to provide relief to the system in times of constraints.

However, Storage also fundamentally suffers from declining marginal ELCC, and increasing duration doesn’t change that fact. The reason is that a given duration of BESS solves a specific pain point of the grid: for example, 4hr BESS increases the reliability of the grid for events with a duration of 4hrs or below. But as more 4hr BESS is added to the system, the <4hr grid risk becomes nullified, which reduces the value of incremental BESS. The grid reliability risks shift to >4hr events, which must be addressed by other fuels (or by 8hr+ BESS, which will initially have high ELCC, but will again see its ELCC decline as 8hr events get derisked). As a result, on most grids today incremental 4hr BESS adds little marginal ELCC.

Our point is not that renewables don’t matter, they are, and will remain, an important part of the AI buildout, just not its most important one. It is that nameplate badly overstates what they add to firm capacity: on an ELCC basis, each incremental GW of solar, wind, and storage is accredited at a steep and widening discount as the risk it addresses gets saturated. That gap between nameplate and accredited capacity is exactly what determines how much new load a market can actually host — which is the subject of the next section: grid headroom.

US Grid Headroom goes red by 2027

Grid headroom is the capacity a market has left to absorb new load once it has covered its own peak demand and required reserve margin. We model it subregion by subregion — each ISO and large non-ISO market — from local accredited supply and reserve requirements. Headroom goes “red” when a market’s reserve margin falls below its required target: at that point there is no spare accredited capacity to host an incremental large load like a datacenter without eroding reliability. Across a growing set of subregions, our analysis shows that threshold being crossed by 2027.

Fundamentally, the headroom calculation is simple: total accredited supply, minus peak demand, minus required reserves. As a live example, PJM’s 2027/2028 Base Residual Auction cleared roughly 134,478MW of unforced capacity (UCAP), yielding a 14.4% reserve margin against a 20% target — a physical deficit of about 6,517MW UCAP. The strain is not PJM-specific: NERC’s 2025 Long-Term Reliability Assessment flags 13 of 23 North American assessment areas as facing resource-adequacy shortfalls over the next decade. Required reserves are a regulatory artifact, set by either grid planners or vertically integrated utilities, depending on the territory, and can change year by year but tend to be fairly stable.

There are typically two types of reserve margins:

• ICAP reserves: ICAP means Installed Capacity and is a proxy for nameplate capacity. A fairly common requirement across ISOs is 15-20% required ICAP reserves. PJM, for instance, sizes its capacity requirement to a 1-in-10 loss-of-load-expectation (LOLE) standard, which currently translates to an installed reserve margin (IRM) target of roughly 20%.

  

• UCAP reserves: the most critical for a true headroom calculation… but also sometimes biased by the policies of ISOs and utilities. UCAP means accredited capacity and incorporates the failure risk of dispatchable generation and the ELCC values of storage and renewables. Because it nets out both forced-outage risk on thermal units and the steep ELCC discounts on solar and storage, the UCAP view of headroom is materially tighter than the ICAP view — and it is the UCAP picture that turns red first.

Note that estimating true headroom is more complicated than that. Utilities themselves often struggle to understand their headroom, and the smartest datacenter developers can successfully navigate the environment by finding “hidden” headroom. We‘ll dig much deeper into this in the future deep dive.

Why BTM wins over grid-connected: speed and certainty of timelines are key

With grid supply structurally constrained — too little firm capacity, too little effective capacity from renewables and storage, and vanishing headroom — the decision now sits with the buyer. And we think BTM is now the most attractive option. This statement might shock some stakeholders, but we base our view on the fundamental drivers of demand: AI labs. Companies like OpenAI, Anthropic now make up the bulk of demand, directly but also often indirectly as they represent a significant portion of the datacenter capacity added by companies like Amazon, Microsoft, and Oracle. Our Tokenomics and Datacenter models both quantify this quarter-by-quarter and have successfully called out major deals and shifts ahead of the headlines, such as the Anthropic TPU rise and the Oracle/OpenAI RPO surge.

The key advantage of BTM vs Grid is speed and certainty on the timeline of power. On speed, onsite generation can be energized in a fraction of the grid-interconnection timeline — requested BTM in-service dates cluster around 2027–28, against grid timelines that routinely slip toward 2030. On certainty, the schedule sits in the buyer’s hands rather than the utilities. As explained earlier, timelines provided by utilities are notoriously unreliable and they often push back or revise down the load that they promised datacenter operators… with little to no penalties at all.

This doesn’t work for AI Labs, for which access to large scale compute is the lifeblood of their business. They need power both to generate revenue (inference) and to fuel future revenue growth (training). In addition, as we cover in extreme depth in our AI Cloud TCO Model, power as a percent of total TCO is mostly insignificant, meaning that any amount of power secured by an AI Lab is actually worth billions. For example, our Tokenomics Model susbcribers know very well the margins Anthropic is currently making on API, and the implied tens of billions of dollars of annual revenue per GW. Given the cost of GW-scale DCs and revenue potential, it simply doesn’t work if it risks multi-year delay, or if the load-serving entity faces no symmetric dollar penalties for being delayed.

In the grid vs BTM debate, another key factor is redundancy and uptime, historically a major advantage provided by the grid. As explained in our Datacenter Electrical Systems deep dive, the playbook to reach five nines of uptime was simple, and came in two steps: first, connect to a substation with N+1 redundancy, which on its own delivers roughly three to four nines depending on assumptions; then add backup power covering more than 100% of nameplate load demand — backup generators and batteries — to close the gap to five nines.

However, AI labs and some hyperscalers have relaxed those requirements as there is now a lower uptime tolerance applied to both inference and training, not just training. Many of Meta’s self-built AI datacenters, for example, target just two nines of uptime and forgo backup generators entirely, as detailed in our Industrials Model.

Source: Meta Prometheus datacenter has no gensets; SemiAnalysis Industrials Model

This removes historical cost barriers to BTM adoption. As we alluded to in our onsite gas deep dive, the main challenge and driver of cost overrun is redundancy and reliability. The grid manages this at the macro level, while an onsite power plant must do it for the much narrower purpose of serving one (large) datacenter alone. Providing four or five nines of redundancy at a BTM site is a recipe for unbearable costs. But now that customers are willing to accept lower redundancy, the economics of grid vs BTM are much more balanced.

Nevertheless, practice varies — some operators add gensets to their BTM-to-FTM bridge builds, while many omit them altogether on a grid connected datacenter.

In our view, it can make sense to add gensets if you plan to connect to the grid in the near future and can redeploy the generation equipment elsewhere, or if you’re exploring a grid-connected BTM solution (more on this later). Most BTM sites are not planned to be islanded forever; they are bridges while the interconnection queue clears. However, if the queue is expected to clear — say 5 years from today — it’s hard to justify ~$1mm/MW in capex for a backup genset fleet, especially since the realized uptime gain is on the order of a single nine once human-factor and recovery-time failures (not power-source outages) are what actually dominate downtime.

Ultimately, the call comes down to the tenant’s design requests, SLAs, and how long the site expects to run off grid.

We’ve seen the following: Where BTM is a short bridge — on the order of two years or less to interconnection — operators tend to spec the gensets at initial build and project financing package, since grid energization and the backup role that follows are close at hand. Where a site expects to stay off-grid for far longer, or effectively permanently, that rationale weakens: primary on-site generation already carries the load with its own redundancy, so a grid-backup stack that sits idle for years is capex worth deferring. Meta is the clearest case — its Ohio campus is designed never to connect to the PJM grid, and its El Paso and Louisiana sites are built around dedicated, utility-scale gas rather than a near-term interconnection. We understand Cipher’s AWS-leased Black Pearl site and several of Fluidstack’s build-outs follow similar logic, deferring or skipping the genset-as-grid-backup route altogether.

Now, none of this means the grid is being written off and that the uptime and reliability requirements of a datacenter are no longer of importance. Rather, it reflects our view of how market participants are adapting to meet the rampant power needs of AI DCs – and it’s our view that tenants are becoming more lenient with these requirements as they have nowhere to go.

Also, there are many promising solutions to enable the grid to absorb more datacenter load growth, and we believe that would be the best outcome for all: lower power costs and higher reliability for everyone. Here are a few solutions outside of today’s article’s scope:

• Load flexibility: if grid-connected DCs could curtail a determined amount of hours per year, tens of GWs could be easily unlocked. PJM characterizes this flexibility concretely as workload shifting, on-site backup-generation dispatch, and battery discharge, and notes it could bridge the gap while new generation clears interconnection queues and supply chains — provided it is integrated into market dispatch rather than accessible only through manual action during emergencies. We remain cautious in the near-term however, given commercial and regulatory constraints which slow down broad-based adoption. This topic is worth an entire SemiAnalysis dedicated deep dive.

• Interconnection Queue and market incentive reforms: a more capitalistic approach to the power buildout would likely trigger more risk-taking behavior by utilities. But it is an extremely tough balance of priorities between protecting American households and taking a directional bet on AI growth. We don’t foresee a big enough change anytime soon. Watching PJM’s struggles best exemplifies this: the various stakeholders can’t agree on the best solutions and end up making the whole process even slower than it already was. That said, there are early signs of reform. FERC moved first on the demand side: its December 2025 order directed PJM to create clear co-location rules and new transmission services for data centers sited at power plants, and — at the DOE’s direction — it opened a rulemaking (Docket RM26-4) on the faster interconnection of large loads above 20MW. PJM’s tariff has since followed: on June 12, 2026, FERC accepted revisions establishing an Expedited Interconnection Track (EIT), a roughly 10-month accelerated generator interconnection study process aimed at near-term resource adequacy after the 2027/2028 Base Residual Auction cleared about 6.6GW short of PJM’s reliability requirement. ERCOT’s shift to a batch-style large-load interconnection process is another attempt to bring more order here. We’ll dig into both in a forthcoming deep dive, alongside a load tracker that follows which datacenter loads we expect to firm up in the batch process.

• Renewed transmission buildout: building more transmission could enable both more generation and load growth, but that market remains over-regulated and slow. We think the 2030s will likely witness a major transmission buildout as the largest power offtakers become creditworthy enough — able to post parent guarantees — to offtake and underwrite whole transmission projects. But for now, building new bulk transmission is simply too slow for the pace of the AI buildout. In practice, only a handful of US transmission corridors could physically support load growth at this scale, and meeting NERC’s reliability requirements on the necessary timeline is itself a binding constraint.

All these topics will be covered by future SemiAnalysis energy deep dives. Stay tuned.

The Hybrid Structures Bridging BTM and Grid Interconnection in ERCOT and a likely Winner

To deal with the limited grid headroom, the market is settling onto a spectrum of hybrid structures — particularly in ERCOT — that blend on-site generation with continued grid access, and this is where we’ve been observing a large share of deal activity and interest. Regulators are racing to write the rules, with FERC at the federal level and ERCOT and the PUCT in Texas updating their frameworks quickly.

In ERCOT, the Batch Zero process is codifying these structures. At its core is a single number for every large load — a maximum withdrawal limit, the amount the site may draw from the grid independent of any on-site generation. The governing framework (NPRR1325 and PGRR145, approved by the ERCOT board on June 1, 2026 and effective July 11) added two new co-location constructs alongside the long-established Private Use Network (PUN). The cleanest way to make sense of the landscape is to separate the two questions these structures answer: how a site interconnects and meters with the grid (as a PUN, WLPUN, or PCLR), and how it may sources its power (from existing generation under an NMA, newly built generation under BYOG). We take each in turn.

Powering your Datacenter

NMA (Net-Metering Arrangement) — sourcing from existing generation. An already-operating generator co-locates with a new large load and nets that load against its on-site output behind a single meter, so only the residual — what the load draws above what the co-located unit supplies — settles against the grid, with any surplus exported. The defining feature is vintage: the generator was already operating before September 1, 2025, the statutory trigger under Texas’s SB6. That brings the arrangement under regulatory review through ERCOT’s net-metering arrangement process (PUCT Project 39169) and a 120-day transmission security assessment. ERCOT studies the system impact — including the effect of pulling that capacity off the grid to serve the load — and the PUCT can approve, deny, or condition the arrangement, for instance by requiring the load to curtail during grid emergencies or the generator to make capacity available when the system is tight. Because the generation already exists and was already supporting the grid, the central regulatory question is whether re-pointing it to a private load leaves the rest of the system whole.

The bulk of announced ERCOT co-location activity to date sits in this existing-generation bucket. Below are a few datacenter examples — roughly 2,885 MW of reported projects in the co-location segment, with likely more beyond these.

Crusoe — Goodnight Campus (net-metering arrangement)

• Two load co-location agreements from the same POI (265.5 MW + 260 MW = 525.5 MW total) are expected to serve a ~1 GW IT campus.

  • Crusoe also has a TCEQ air-permit filing for up to 933 MW of gross nameplate gas generation, of which we expect ~665 MW is the 19x GE Vernova LM2500 turbines (~35 MW each)

AWS — Comanche Peak (net-metering arrangement)

• 1,200 MW co-located load adjacent to Vistra’s Comanche Peak nuclear plant (Somervell County); 20-year PPA, ramping to full capacity by 2032.

CyrusOne — Thad Hill Energy Center (net-metering arrangement)

• Two phases — 190 MW (Phase 1) plus 210 MW (Phase 2), 400 MW total — adjacent to Calpine’s Thad Hill plant (Bosque County).

CyrusOne / Constellation — Freestone Energy Center (net-metering arrangement)

• 760 MW campus potential (380 MW contracted, with an exclusive option on a second 380 MW phase), via Calpine/Constellation.

BYOG (Bring Your Own Generation) — sourcing from new generation. Rather than wait on grid upgrades to serve its full load request, a large load builds, co-develops, or contracts new co-located generation to secure a near-term path to energization. ERCOT evaluates the project on three parallel tracks: a Batch Study sets the grid withdrawal limit (what the site may draw independent of on-site generation), Generation Interconnection sets the export limit (what the on-site units may push back to the grid), and Transmission Planning identifies any network upgrades required. The site’s achievable load is therefore its withdrawal limit plus available on-site generation, subject to system-stability limits, and energization is staged accordingly: the site draws up to its withdrawal limit (say, 100 MW) from day one and ramps toward full capacity as each generation unit comes online. The distinction from an NMA is one of category and vintage — BYOG describes how a site sources its power, by adding its own newly built generation, and because that generation is new it sits outside SB6’s net-metering review.

Metering & connecting your datacenter

A Private Use Network (PUN) places an entire campus — load plus its co-located generation — behind a single point of interconnection, so ERCOT meters only the site’s net exposure with the grid rather than each individual resource. Building on that base, Batch Zero introduced two new constructs:

• Withdrawal-Limited Private Use Network (WLPUN): a load that brings its own new generation can connect more megawatts than transmission alone could support, in exchange for an enforced cap on grid withdrawal — for example, 1,000 MW of load that never pulls more than 100 MW from the grid, leaning on its on-site generation for the rest and exporting any surplus through SCED. ERCOT is explicit that this is not a faster interconnection; it is a way to energize more of the desired load sooner within existing transmission limits.

• Provisional Controllable Load Resource (PCLR): a dispatchable, flexible load that needs no on-site generation. It connects at its full requested size, but ERCOT can dispatch it down in real time during transmission constraints (for instance, a 150 MW load backing down to 100 MW), with the cap relaxing toward a defined exit date as transmission is built out. That makes PCLR the explicit bridge-to-firm path.

Winners and Losers of the rise of Behind-The-Meter

Let’s now turn our attention to winners and losers. We’ll discuss turbine manufacturers like GEV, fuel cell and RICE vendors like Bloom and INNIO, IPPs like NRG. We first called out Bloom in December 2024 for Core Research subscribers as the biggest beneficiary.

Read more

Our latest on memory can be seen here:

Or other older but excellent memory or China compute pieces below:

1. Huawei Ascend Production Ramp: Die Banks, TSMC Continued Production, HBM is The Bottleneck

2. Huawei AI CloudMatrix 384 – China’s Answer to Nvidia GB200 NVL72

3. Scaling the Memory Wall: The Rise and Roadmap of HBM

4. The Memory Wall: Past, Present, and Future of DRAM

5. Scaling Laws - O1 Pro Architecture, Reasoning Training Infrastructure, Orion and Claude 3.5 Opus “Failures”, Inference Tokenomics of Test Time Compute

CXMT, established in 2016, is going to be listed on China’s STAR Market. Now the leading DRAM player in China, its history shows an interesting path of technology transfer, talent flows, and the patience of state-venture capital, together of which are turning the company toward indigenous innovation.

The Silicon Valley Returnee

Zhu Yiming, the founder of CXMT, earned his undergraduate degree in physics at Tsinghua University in 1994 and came to SUNY Stony Brook for his graduate study in electrical engineering. He then worked in Silicon Valley and became a project lead at MoSys (Monolithic System Technology) around 2001. In 2005, he went back to China with a set of SRAM patent and US$100,000 in seed money, founding GigaDevice, which later became well known for its SPI NOR flash and microcontrollers, a fabless design house that grew into one of the world’s top NOR flash suppliers. But the global NOR flash market is much smaller compared to DRAM or NAND flash. Zhu Yiming always dreams big, and not surprisingly he chose to march into the DRAM business.

DRAM, however, is not a design-house game in which one can stay fabless. DRAM is capital-devouring, IP-fortified, and manufacturing-bound, and by 2016 the whole industry was dominated by three survivors, Samsung, SK Hynix, and Micron, fortified by four decades of patents and capital that no newcomer had breached. Zhu’s SRAM patents and GigaDevice’s NOR franchise gave him neither a DRAM cell, nor a DRAM process, nor any cover from the incumbents’ patents. Thus, when Zhu and the Hefei municipal government launched the DRAM venture in 2016, the “506” project that became CXMT, the core technology had to come from somewhere else entirely.

It came from a dead company in Germany.

The DRAM Foundation: Inheriting Qimonda

The dead company was Qimonda. Though the company went bankrupt in January 2009 due to the 2008 Global Financial Crisis and the following dramatic memory downcycle, it was then the leading DRAM player in Europe. A subsidiary of Infineon, which originated from Siemens, it offered a rare alternative: a deep DRAM patent base and a cell architecture, both originating outside the dominant Samsung-SK Hynix-Micron triangle. In June 2015, Polaris Innovations, a subsidiary of WiLAN, a Canadian patent-monetization firm, bought roughly 7,000 Qimonda patents and applications from Infineon for about 30 million euros. In December 2019, Polaris and CXMT signed an agreement: a license to a large set of DRAM patents. CXMT leaders once publicly claimed that they obtained roughly 2.8 TB of Qimonda technical documentation, which became the basis for CXMT’s DRAM business.

A major technology CXMT inherited from Qimonda and then developed its 46nm-class BWL (buried wordline) cell, which CXMT scaled toward the 10nm class. BWL is the load-bearing idea. Instead of routing the access transistor’s gate across the wafer surface, BWL sinks it into a trench beneath the bitline. It pulls the gate off the surface so the cell collapses to a 6F² layout (versus 8F²). It also lengthens the channel without spending surface area, suppressing the short-channel leakage that wrecks retention. And it cuts gate-to-bitline parasitic capacitance. Buried wordline plus stacked capacitor is the architecture all three leading players run today. The trench holdout died holding the stacked/BWL escape hatch, and that is exactly what CXMT picked up.

Talent Flows: From a Frozen Blueprint to Living R&D

Besides patents, the more durable thing CXMT pulled out of Qimonda’s collapse was its engineers. Qimonda’s Xi’an R&D center, with 400-500 engineers, was one of the largest Qimonda built outside Germany. After Qimonda’s collapse, though the whole Xi’an R&D center was acquired by Tsinghua Unigroup, the wider diffusion of individual talents benefited CXMT. In addition, CXMT successfully attracted Karl-Heinz Kuesters, a senior engineer, from Qimonda’s German site to Hefei, China. Kuesters had spent 24 years as a VP of technology and pre-development across Siemens, Infineon, and Qimonda. The pre-development line Kuesters ran was the stacked-capacitor work, the architecture CXMT actually builds on. He joined CXMT as a technical consultant, for which the EE Times called Kuesters the company’s “ace in the hole.” What Kuesters brought was the part of Qimonda’s legacy that neither the patents nor the 2.8 TB of documents carry: the tacit know-how. Having led DRAM development for two decades, Kuesters could tell CXMT’s engineers which of Qimonda’s design choices to keep and which to discard, and how to move a cell that worked only in the lab into volume production, the integration and yield judgments that no patent records.

The American side shows the same pattern. Ping Er-xuan, CXMT’s VP for future-technology assessment and the public face of its roadmap (the “46nm to the 10nm class” framing), came not from Qimonda but from a US career at Micron, SanDisk, and Applied Materials, where he ran memory and materials technologies. Ping brought process-and-materials depth and an emerging-memory view: individual mobility.

CXMT has also recruited heavily from Korea and Taiwan. Korean prosecutors have charged former Samsung employees with leaking technology to CXMT, and dozens of Korean engineers are reported to have worked there. Similarly in Taiwan, there is constant talent poach with attractive compensation package for top-tier engineer across equipment and process development.

This is the part that bears on where CXMT is heading. The Qimonda patents were always a finite, expiring asset. What lets CXMT keep moving, from G4 to G5 and now into HBM, is the assembled capability of domestic talent, Chinese nationals who worked at foreign companies and returned, as well as some experts from foreign firms, not the documents. The inheritance only got it started. The talent turned a foreign legacy into in-house R&D juggernaut. However, it took nearly a decade for CXMT to generate profits. The question is who has patiently funded CXMT’s development and borne its near-decade losses?

The Patience of State-Venture Capital

It is difficult to not attribute at least part of CXMT success to the strong support of local and central government in China. Hefei municipal government is one of the great examples. Hefei is one of the tech innovation hubs in China, well known for its patient state-venture capital nurturing successful companies over the past two decades, from BOE (the world’s leading display panel maker) to NIO (a leading EV maker) and now to CXMT. In particular, the Hefei municipal government did two things for CXMT. First, the Hefei government helped CXMT build a local supply chain around its fab. Hefei’s playbook is to take a large equity stake in an anchor “link-leader” and then draw the rest of the chain in around it. The city did that for BOE in displays and NIO in EVs, and from 2016 it replicated the same playbook for CXMT. Surrounding CXMT’s plant in Hefei’s airport-zone industrial park, the government produced a dense local cluster. Two packaging-and-test houses, Peyton and Xinfeng, are located within a street or a wall of CXMT’s fab, with Xinfeng booking over 99% of its revenue from CXMT. An on-site bulk-gas plant run by Guanggang supplies most of CXMT’s needs, while wafer-reclaim capacity from Zhiwei Semiconductors a subsidiary of Zhichun Technology (至纯科技), is located in Hefei’s Xinzhan Hi-Tech District. The state-venture-capital vehicles have also taken outright control of an upstream chip-molding equipment maker, Wenyi Technology. Such a local supply-chain cluster gives CXMT a localized industrial base.

In addition, Hefei’s state-venture capital could afford to lose money for a very long time. Unlike a private venture-capital fund answerable to LPs that expect a return on a fixed timetable, Hefei’s state-venture capital, ultimately backed by the city’s municipal and development-zone state entities, faced no such clock. They kept funding a company that, even after turning its first annual profit in 2025, still carried an accumulated deficit of roughly RMB 36.65 billion built up over nearly a decade. The original “506” project, launched in 2016, began with Hefei’s state-venture capital funding about 80% of the project’s first phase (RMB 14.4bn of 18bn). Across successive rounds Hefei’s vehicles were diluted, but they never sold down and never walked away. By the IPO, the largest holder, Hefei’s Qinghui Jidian, at 21.67% and state-venture capital vehicles together holding over 30%. That willingness to treat a fab as a decade-long bet rather than a fund-cycle return is the catalyst that the technology and the talent both depended on.

From Inheritance Toward Independence

Put the three threads together and CXMT’s first decade resolves into a single arc. Qimonda supplied the foundation, with a licensed patent base and a cell architecture from outside the incumbent triangle. Talent supplied the motion, with key figures like Kuesters and Ping as well as the returnees from the American majors, and the contested hires out of Korea. Those people turned a frozen blueprint into a process that could keep scaling. Then the Hefei government supplied what the other two needed but could not generate on their own: capital, patience, and a localized supply chain. None of the three would have produced a DRAM maker alone; together they did.

In the following section, we will be discussing CXMT’s financials, technology, equipment ecosystem.

Next Step after 10 Years: An IPO in the Supercycle

The past decade of CXMT’s history, while impressive, may prove to be only an early chapter in the company’s longer-term story. The company is now preparing for what will become one of China’s largest semiconductor IPOs of the past decades, and potentially the most closely watched semiconductor listing globally this year. In December 2025, CXMT officially entered the IPO filing stage when the Shanghai Stock Exchange accepted its STAR Market listing application, following a prolonged period of market reports throughout 2024 and 2025 suggesting that the company was preparing to go public. More recently, CXMT’s application advanced further through the review process by submitting the formal CSRC (China Securities Regulatory Commission) registration on May 27 and currently under final review, moving closer to a landmark listing.

While understanding strategically important, unlisted Chinese companies such as CXMT and YMTC has never been easy, CXMT’s move toward a public listing has been helpful for us to understand more details about the company given its IPO prospectuses that have shed meaningful light on the company’s historical performance, future trajectory, financial profile, market positioning, and technology roadmap. By combining these disclosures with our Memory Model, we can develop a more accurate view of CXMT’s current position and a more robust forecast of its future performance.

At a high level, CXMT is clearly the fourth biggest DRAM maker globally by almost every metrics while expanding its lead over legacy memory suppliers. For the full year, CXMT revenue increased 156% YoY to ~$8.6 billion, up from ~$3.3 billion in 2024 and ~$1.2 billion in 2023. Net income also turned positive for the first time, reaching $1 billion, underscoring the company’s rapid scale-up and improving profitability. Even with such impressive results, CXMT’s CY25 revenue is still materially behind Samsung (~$72.3B), SK Hynix (~$52.1B), and Micron’s (~$37.2B) DRAM revenue.

In 1Q26, CXMT reported revenue of $7.3 billion, representing roughly 700% YoY growth and already approaching the company’s full-year revenue in 2025. Operating margins also expanded sharply, reaching approximately 70%.

But we think this is just the beginning. We estimate the company to do even better if not explosive in the next two years at least. Just based on its filing, the company’s 1H26 revenue is expected to be 7x y/y and reached to more than 16 billion. For full-year 2026, we believe CXMT’s revenue could exceed $50 billion. If achieved, this would suggest the company has more than doubled revenue every year since 2023, and more than 6x its revenue in 2026 year over year basis, with its earnings trajectory accelerating meaningfully as both scale and profitability improve.

In our view, such significant upside to CXMT’s earnings is clearly driven more by the cycle itself than company’s technology or market positioning. When we take a closer look into the correlation of CXMT’s ASP trajectory and bit shipment. Company’s bit shipments increased by only 11% in 1Q26, while ASPs rose by roughly 57%, following QoQ ASP increases of 63% and 68% in 3Q25 and 4Q25, respectively. In other words, what really drove up company’s earnings is really the explosive ASP growth rather than significant market share gains over its peers in global DRAM end-market. By bit shipment, we model CXMT’s market share will increase from 9% in 2025 to 12% in 2027. While a 3% market share gain sounds minimal, it is significant for a market we size at close at $1T in 2027.

Surprising enough, the strong pricing uplift coming to CXMT is not an exception. We have been observing similar dynamics across both leading-edge and legacy memory suppliers in the DDR5, DDR4, and even DDR3 markets over the past year or so. As noted in our February memory piece, where we described the memory market as entering a “once-in-four-decades shortage,” we believe DRAM pricing remains on track to double again this year driven by sustained supply-demand imbalance across these product categories. Since February, we have become even more confident in this view and believe it could potentially exceed our expectations by year-end.

What may be more interesting to readers who have not yet followed CXMT or the memory market closely is how the company’s pricing compares with industry leaders. Based on our Memory Model, CXMT’s DRAM ASP challenges the common misconception that Chinese memory is structurally cheaper and will flood the market, thereby pressuring global pricing. While this may have been true in some cases in the past, we believe it is somehwat inaccurate in this cycle, and the latest company data points support the same conclusion.

Taking 1Q26 as an example, CXMT’s DRAM ASP was only slightly below Samsung, SK Hynix, and Micron — by roughly 5–10% — in the same quarter. And as we model it out throughout 2026, we think this will still to be the case directionally although the gap will gradually expand. We believe this widening gap over the coming quarters will be driven less by inherent pricing differences but more by the change of product mix. Leading suppliers continue to benefit from a higher server DRAM mix in their bit shipments, as well as a more favorable pricing outlook for server DRAM compared with consumer DRAM.

As such, we expect this mix to increase further over the coming quarters as server becomes a larger share of DRAM end-market demand. By the end of 2027, we expect server DRAM and HBM account for well more than 50% of the total DRAM end-market. Given that server DRAM and HBM carry higher $/GB than other memory end markets, this should allow leading memory suppliers widen their ASP gap versus CXMT as server DRAM mix increases, especially considering the expected material price increase for HBM in 2027 (we have 2027 HBM pricing in our Accelerator & HBM Model and Memory Model). We also have details on LTAs for major memory buyers such as hyperscalers and Nvidia.

Strong ASP tailwind has materially improved the company’s margin profile. CXMT’s FY25 gross margin reached 37.8%, moving closer to Samsung at 39.4% and Micron at 39.8%. However, it remains far below SK Hynix at 60.4%, as SK Hynix benefits from a much higher HBM mix, which carries higher ASPs and margin last year. CXMT’s ~38% margin is a significant swing from -113% in FY23 and -4.7% in FY24. Last year is not only the year CXMT reaches a record-high gross margin, but also the first year that the company achieves a positive margin profile.

With DRAM ASP continues to increase in 2026, CXMT’s margin profile has improved further. Its operating margin reached 70% in 1Q26, compared with SK Hynix at 73%, Samsung at 81%, and Micron at 84% in the same period. Besides the strong ASP growth, firm’s margin improvement also needs to thanks to company’s near-total exposure to commodity DRAM, which effectively has higher margin now vs. HBM. Based on its filing, nearly all of company’s bit sales are conventional LPDDR and DDR products. HBM is still a very minimal contributor to the company’s revenue and earnings.

This becomes clearer when we run a simple cost-per-bit analysis on DDR5 products across four memory suppliers. For DDR5, we find that CXMT’s cost per bit remains meaningfully higher than that of the three leading suppliers, by more than 30%. However, because DDR5 pricing was already exceptionally strong in 1Q26, we believe this still lifted CXMT’s gross margin to over 70%.This suggests that the improvement in CXMT’s margin profile is primarily driven by pricing, rather than by a material improvement in product competitiveness or cost structure.

In addition to printing record-level earnings, we believe company is gaining ground from the capacity perspective. By the end of 2026, we expect CXMT to reach roughly 350 kwspm, which is only modestly below Micron’s estimated ~385 kwspm. This would position CXMT close to becoming the industry’s third-largest memory supplier, if ranked only by wafer capacity.

However, CXMT remains materially behind the two leading DRAM suppliers, Samsung and SK Hynix, which we estimate at approximately 720 kwspm and 595 kwspm, respectively. Next year, with the initial ramp of Shanghai Phase 1 and the full ramp of Hefei and Beijing, CXMT capacity could reach the 420kwspm range if capacity in year-end, representing ~17% of global DRAM capacity, up from ~13% in 2025. In terms of bit shipments, CXMT’s share of global bit shipment is expected to rise from 9% to 12% in 2027.

CXMT’s global capacity share could increase further as its Hefei site reaches full operation and the two phases of its Shanghai site continue ramping through 2028. We believe the company will reach 500kwspm of wafer capacity by the end of 2028, accounting for ~17% of global DRAM supply, up from 11% in 2025.

Given CXMT’s expanding role in global DRAM capacity, as in past cycles, investors are concerning about potential supply-demand disruption from Chinese players. While these concerns are understandable, we believe they are likely overplayed at least for the next two years. We factor in incremental wafer capacity and bit shipments from CXMT and other memory suppliers—and assuming utilization rates in the high-90% range—we continue to see DRAM as extremely supply constrained. We constantly update our wafer add numbers, demand numbers, and pricing assumptions in our memory model, much faster than trendforce or sell side banks.

Looking solely at CXMT’s wafer additions, we do see meaningful capacity expansion when compared with other suppliers. We expect CXMT to add roughly 85kwspm, 70kwspm and 80k each year from 2026 to 2028, versus Samsung at 15k/50k/110k, SK Hynix at 60k/60k/90k, and Micron at 30k/90k/115k. Even with these wafer additions, we expect DRAM to remain undersupplied by a high-single-digit percentage this year, widening to a low- to mid-teens in bit undersupply next year. We addressed in detail in our previous piece why DRAM is likely to remain undersupplied through potentially 2028, even with these incoming incremental wafer additions.

We see little ability for the company to irrationally accelerate capacity expansion beyond its current pace in a way that would meaningfully disrupt a market now providing an extremely favorable pricing environment because fab construction timelines are so long. This pricing backdrop has been the primary driver of the company’s explosive earnings growth–which the company hopes to see it continues. Based on the fab buildout we are tracking, we also not yet see the sign of this possibility although we would like to stress that the total wafer capacity of Shanghai site could have over 400kwspm of wafer capacity in a full-ramp status.

Specifically on its wafer capacity, we see quite limited wafer allocation toward HBM. By reconciling with CXMT’s IPO-related filings to date, we find that wafer allocation to HBM has been very limited, even until today. By the end of 2025, we believe only ~5 kwspm of CXMT’s ~265 kwspm of capacity is allocated to HBM. We think this figure will increase to nearly ~30 kwspm and ~55kwspm by the end of 2026 and 2027 respectively. This capacity trajectory seems better align with CXMT’s filings indicate that roughly 99% of revenue consists of DDR and LPDDR products in 2025, as discussed earlier.

This wafer allocation dynamics could change, however. We believe China’s broader push for self-sufficiency in AI compute could conflict the company’s strategic priorities, and we believe this push could intensify over time, given the HBM supply constraints discussed earlier and government’s determination to address this issue.

To that end, in our estimates, we factor in government influence for CXMT to allocate more wafer capacity to HBM overtime. As a result, we expect CXMT’s HBM wafer capacity to accelerate materially in 2027 and 2028 with its HBM technology improvement, supported by continued growth in China’s domestic compute market. We estimate CXMT’s HBM wafer capacity will reach 55kwspm and 100kwspm in 2027 and 2028, respectively. This would increase the company’s share of global HBM wafer supply from 1% in 2025 to 12% in 2028.

It is important to remember that CXMT, unlike other memory suppliers, is not only an economically and technologically important company for China, but also a strategic asset that the country can leverage to advance prioritized policy objectives.

Strategically though, it does make sense for CXMT to allocate more DRAM wafer capacity to commodity DRAM over HBM in near term. The commodity DRAM currently offers materially higher margins than CXMT’s HBM products, while also delivering more than 3x the bits per wafer on a like-for-like basis.

Given that CXMT has not yet fully matured its HBM technology, allocating significant wafer capacity to HBM would likely generate limited profit while consuming scarce DRAM wafer capacity that could otherwise support higher-margin commodity DRAM at greater volume. In this context, prioritizing commodity DRAM is both economically rational and better aligned with CXMT’s current manufacturing capabilities and pricing environment. China must allocate to HBM though as sales of HBM to China are somewhat limited besides some loopholes that allow Korean vendors to keep shipping to China.

On technology readiness, we believe CXMT is still struggling to stabilize supply for HBM3 8-hi, with even greater challenges in 12-hi. On the front end, the company appears to have made progress stabilizing production of its Gen 4 (G4), or 1z-equivalent DRAM. We believe the majority of CXMT’s DRAM output this year will be fabricated on the company’s G4 process node. Yet, front-end wafer-sort yield should still be materially lower for the core DRAM die used in HBM, given its larger die size, more demanding cell performance, overall performance requirements versus commodity DRAM. We think the front-end wafer sort yield remain a major challenge for the company, and its gap versus its peers here is still large. While we believe yields on CXMT’s G4 node have improved, we suspect it still lower than industry standard of 85-90% mature yield level for 1z given the lower margin we saw throughout 2024 and 2025. This might suggest that equipment limitations and manufacturing know-how remain persistent obstacles that CXMT will need to overcome.

For its next process node, the company’s G5, or 1a-equivalent DRAM node, while can theoretically continue advancing without EUV akin to Micron in 1a process node, but it will face increasing fabrication and design challenges. These challenges will only add further manufacturing and design pressure when the node is applied to both DRAM dies for HBM. The lower yield and more challenging ramp-up schedule could impact company’s bit output as well despite the company can compensate the yield loss by adding more wafers.

On top of this, we believe die stacking remains the major obstacle for CXMT’s HBM. HBM stacking usually introduces significant technical hurdles, including thermal stress, die cracking, warpage, bonding defects, and yield loss across multiple stacked dies. Our understanding is that these issues become even more severe as the company attempts to move from HBM3 8-hi to HBM3 12-hi, and eventually HBM3E, given company’s yet sufficient enough of know-how and manufacturing experience for 12hi or above HBM.

Die stacking is not a challenge unique to CXMT. Even leading memory suppliers are encountering difficulties. For 12-high HBM4, we understand that suppliers continue to face significant stacking-related issues, including die cracking, thermal management challenges, and yield loss.

These challenges become even more pronounced as memory suppliers seek to manufacture 16-high or even 20-high HBM. For next-gen HBM4E, we note that one reason Rubin Ultra is expected to use 12-high HBM4E rather than 16-high is supply: 16-high HBM requires higher DRAM wafer intensity and involves a more difficult manufacturing process, which can lead to greater wafer loss and lower effective supply of DRAM bits. These conditions put both memory suppliers and customer in a very tough spot given highly supply-constrained environment in DRAM.

We think there is an increasing possibility that CXMT will skip HBM3 and focus instead on HBM3E 8-hi and 12-hi. We believe this potential roadmap change is driven by two factors: 1) customer demand for more competitive HBM products in ’27 timeframe, and 2) mainstream accelerators will equip with HBM3E, HBM4, and HBM4E.

On the back end, while it remains debatable whether CXMT is using MR-MUF or TC-NCF, we believe the packaging challenge should be relatively more manageable, as the company and its back-end partners face fewer export control constraints. CXMT has been working closely with leading OSATs such as Tongfu Microelectronics for some time, and we believe its back-end capabilities should have gradually improved, though a gap likely remains versus leading memory manufacturers.

Given these existing manufacturing challenges, we model CXMT’s HBM3 8-hi’s front-end and back-end yields at roughly 35% and 70%, respectively, implying an overall yield of only around 25%. We think this number should be lower when company attempts to produce HBM3 12hi or HBM3E 12hi given higher difficulty in die stacking and bonding. At these yield levels, CXMT’s HBM output would be even more limited on the same DRAM wafer capacity than leading memory suppliers. More importantly, the resulting HBM would likely carry very low margins, especially compared with commodity DRAM in the current pricing environment.

CXMT’s HBM struggles continue to be reflected in its limited product presence and slow penetration within China’s AI accelerator market. We think only Huawei, Cambricon, and select emerging Chinese AI chip startups are likely to adopt CXMT’s HBM, though we suspect adoption rates will be large. We actually believe domestic AI accelerator vendors would still prefer foreign HBM3, or even HBM3E, if they can secure supply through any available channel or stockpiled inventory before the export controls in December 2024. As China’s domestic CSP capex and broader compute buildout are surging, there is little doubt that domestic HBM demand is also growing rapidly and should continue to increase.

With that said Huawei and CXMT will have custom HBM that is not based on the slow JEDEC standards and phys, so it will be able to close the bandwidth disadvantage.

We believe China could face a more severe HBM supply constraint than what would be implied by slow domestic HBM development alone. This constraint is likely to be further exacerbated by tight supply across all three major HBM suppliers, each of which is already restricted from selling HBM2E-equivalent or more advanced HBM products into China under the U.S. export controls announced in December 2024. Given the tight supply environment, these suppliers are likely to have even less willingness to risk violating export controls to sell into China.

However, HBM re-export and smuggling could complicate this conclusion. We understand that some Chinese companies continue to obtain HBM3 from memory suppliers, a dynamic we reported on last year and that has since been corroborated by other leading media outlets. We believe this remains the case today.

Based on our conversations with industry participants, re-export through foreign offices or partner companies located in third countries remains one pathway through which Chinese companies can access HBM. In addition, some downstream OSATs or intermediaries in third countries appear to facilitate these flows. Some entities may ship partially assembled systems or modules in forms that are not treated as fully manufactured GPUs or ASICs and are therefore still permitted to be shipped into China. The HBM can then be recovered and repackaged onto domestic Chinese GPUs or ASICs.

What the IPO Structure Reveals

CXMT could become one of China’s largest semiconductor IPOs, and its ownership structure matters more than the headline financials. CXMT reported RMB7.14B of consolidated FY2025 net income, yet only RMB1.87B was attributable to parent shareholders, with 74% attributable to minority interests. The reason is the ownership architecture. CXMT holds 30.68% of the economics of Changxin Xinqiao and 31.72% of Changxin Jidian Beijing while controlling 73.01% and 75.32% of the votes through long-term acting-in-concert arrangements. That lets the company consolidate fabs it mostly does not own, so the consolidated figure overstates what public shareholders will actually receive by roughly four times.

That same voting structure undercuts the company’s declaration that it has no controlling shareholder and no actual controller, which the prospectus lists as a formal governance risk. CXMT exercises majority voting control of its fabs through acting-in-concert pacts, and state vehicles including National IC Fund Phase II, Hefei, and Anhui together hold well over 30% even after the listing. The arrangement looks designed to manage export-control and foreign-investor perception at a moment when CXMT’s ties to the Chinese state draw the most scrutiny.

The raise that will get reported badly understates the listing. CXMT plans to deploy RMB29.5 billion, or about $4.1 billion, while issuing 10% to 15% of its post-IPO shares. Fully funding those uses through the IPO implies a price of roughly RMB4.41 at 10% dilution or RMB2.78 at 15%, versus RMB2.63 in the June 2025 financing. The low end represents barely any per-share appreciation despite 1Q26 revenue of $7.3 billion and net profit of $4.8 billion. At RMB2.78, CXMT would be valued at about RMB197 billion, or $27 billion, equivalent to just 1.8 times annualized first-half 2026 parent earnings. This arithmetic floor sits well below a realistic book-building valuation. This is too cheap and should be much higher valuation in our opinion.

The allocation reinforces CXMT’s current priorities. Of the RMB29.5 billion in planned net proceeds, RMB20.5 billion, or 69.5%, funds wafer-production-line and DRAM technology upgrades, while RMB9 billion, or 30.5%, supports forward-looking DRAM research. The prospectus discloses no dedicated HBM project and does not mention HBM. Its project descriptions focus on newer process platforms, product iteration, and the migration of existing lines toward mid-to-high-end DRAM. The IPO therefore primarily strengthens CXMT’s core DRAM manufacturing and technology base, with no disclosed funding commitment to a near-term HBM expansion.

The size of the earnings move deserves a flag on cycle timing. CXMT guided in its December 2025 filing to an FY2025 parent loss of RMB 0.6 to 1.6 billion. Five months later the prospectus reported a RMB 1.87 billion profit, with consolidated income running past double the earlier high-end estimate. It also shows how quickly peak DRAM pricing moves the valuation denominator in either direction.

Finally, Alibaba’s place on the cap table changes how to read CXMT’s demand. Alibaba Cloud is at once the anchor hyperscaler customer, a near-4% holder, and an endorser, sitting alongside GigaDevice, chairman Zhu Yiming’s own fabless house, at 1.8%. Domestic volume is effectively guaranteed in a way the Korean incumbents did not have in their home markets, which matters more than the small percentages suggest.

For paid subscribers, we will take a deep dive into CXMT, China’s broader WFE ecosystem, the impact of export controls, and the implications for China’s memory and compute ambitions. We will also discuss HBM in more detail.

CXMT’s Equipment Ecosystem Under Export Controls: Domestic vs Foreign, and the Domestication Curve

Read more

We find these claims quite amusing. We’ve consistently been first to call-out high-profile delays, like Core Scientific ahead of Coreweave’s Q3’25 earnings in our industry leading datacenter tracking model. We update the dataset by reviewing every site dozens of times a year. However, over the last 6 months, our YE2026 NA Hyperscaler Self-build forecast only moved by ~1%, and NA colocation <5%. What is causing the discrepancy?

In our view, the culprit is obvious: the data sources behind these claims of “50% of 2026 datacenters are delayed” are essentially uninformed vibe-coded datacenter forecasts that take announcements at face value, without any bit of critical judgement. We’ve seen more and more Claude Coded datacenter models and estimates crop up, all of them wrong. Thankfully, that’s not how we built our model, which is trusted for billion-dollar investment decisions by all the world’s largest tech companies in the world, as well as energy and industrials giants, and all the largest investors on Wall Street.

Claude Code pulls press releases, views unfounded GW-scale announcements as ground truth, misunderstands construction timelines and grid complexities, and compiles a terribly inaccurate report. As resident Claude Code users spending $170K+ in just one week, we are very familiar with how to use Claude, and the mistakes others are actively publishing.

Let’s be clear, delays and cancellations are occurring. Our Datacenter Model flagged the STACK Infrastructure / Oracle permitting impasse months before Bloom Energy stepped in. We caught the Nebius New Jersey delays, which are still persistent. We nailed the Core Scientific datacenter delays ahead of Coreweave’s Q3 earnings. However, we then successfully predicted Coreweave’s 1.7GW of Active Power by end of 2026 (exactly the Company’s guide) as we determined that other datacenters were on time (no, not everything is delayed!). Our data also predicted ~35B of RPO to be signed by Q1 2026 via our industry-first method to forecast RPO based on datacenter signals.

And most recently, we’ve determined STACK Infrastructure/Oracle’s site has now been delayed to 2029, due to a lack of gas pipeline and the ensuing burdensome regulation. We’ve flagged many many others, some of which have materialized, but many others which aren’t realized yet and the market is still misunderstanding. Check our Datacenter Model for full information.

There are two main reasons the headline narrative is wrong.

First, the headline number is built on a hugely flawed denominator, off by multiples. Bloomberg’s data comes from Sightline Climate, which estimates that of the roughly 12 GW expected to come online in the US in 2026, only about 5 GW is currently under construction. Checking against our Vision Model, trained on hundreds of thousands of satellite images, even their Under Construction figures are off by multiples. Taking ONLY the top-two hyperscalers alone gives us a higher Under Construction capacity than 5GW. And that’s self-build only, it doesn’t include the many GWs of capacity under construction by 3rd party developers.

Sightline’s dataset clearly doesn’t track every datacenter under development; it likely tracks the large, publicly announced projects. That skews the basis heavily toward the kind of speculative megaprojects from unexperienced datacenter developers most likely to slip in the first place. The “50% cancelled or delayed” figure isn’t really a statement about the US datacenter pipeline, but rather about the slice of the pipeline most prone to slipping.

Second, even taking the Bloomberg/Sightline number at face value, almost all of what’s getting flagged sits in the early-stage, or pre-construction “announced” bucket. These are speculative MW that weren’t going to land on a 2026 timeline with any rigorous analysis. We’ve been writing for months that the market is in structural oversupply of early stage projects, with developers and landowners announcing projects on preliminary power estimates, often without financing, interconnection studies, or equipment orders in place.

Instead of falsely declaring them as 2026 projects, they rather show up in 2028+ in our model. In December 2025, we flagged that over half a Terawatt is in the large load queue in the US, and that number is now over a Terawatt. The vast majority are highly speculative, yet some developers make high profile announcements without much to show for. We do not put low probability datacenters in our datacenter timelines.

We will start by covering how common these questionable announcements are, and then display what real delays look like. We then cover the noise fueling the misled delay narrative, and close with why none of it has moved our numbers, for datacenters or for the equipment suppliers.

Let’s Begin With Real Delays.

The Anatomy of a Datacenter Delay

We have three broad buckets to categorize datacenter delays, which we examine in depth below:

• Overly aggressive announcements by new players with speculative projects. The provided timelines are often simply unrealistic and should be discounted (which vibe-coded datacenter forecasts struggle with).

• Advanced projects but with too optimistic construction timelines, often carried by new datacenter developers who lack the experience. We dodge this via our extensive analysis of construction timelines. These developers typically don’t account for traditional sources of delays, which are broad-based and can range from supplier late deliveries to weather-related issues to equipment issues, as well as many other construction and commissioning issues.

• Permitting and overall NIMBY (Not In My Backyard) issues slowing down an advanced project, forcing to change things like power sources or datacenter design.

1. Aggressive Announcements by Newer Datacenter Developers

New entrants in the space commonly try to give themselves some publicity by announcing massive GW-scale datacenters with aggressive timelines, despite their project being early stage. But it can take more than 4 years from land purchase to datacenter delivery. When we see a brand-new announcement in 2025 saying 2026 operational from a new “unknown” developer, it should raise some red flags. And for flagship multi-GW announcements, we often find that deeper analysis reveals these projects are very early, and sometimes don’t even have long lead time equipment ordered. We are not denigrating these operators, but rather promoting caution on interpreting headline announcements correctly - which vibe-coded forecasts often struggle with. Let’s look at a few examples.

Data City, unveiled by Energy Abundance, boasted a 5GW campus, of which 300MW would launch in 2026. Looking again, the Energy Abundance website has very little except a “Contact Us” button. There has been no news since the announcement, and satellite imagery doesn’t show any evidence of physical progress. While AI-generated datacenter forecasts likely consider this as 2026 delayed capacity, any serious forecast would’ve taken this with some skepticism.

In June 2025, APR Energy announced a potential 400MW datacenter campus in Texas, where “The first phase of the project’s development is slated for early 2026.” At the same time, they were “currently seeking data center developers, hyperscalers, and AI partners to partner on the development of the facility.” No customer yet, a new developer, targeting a <1-year timeline needs to be approached with more scrutiny. There’s been no news since.

Another example is the Cloudburst facility in San Marcos, TX. It was announced as a 1.2GW facility, of which 50MW live by Q3 2026 (then pushed to Q4 2026). When announced in February 2025, that Q3 2026 timeline was unrealistic given many approvals weren’t secured yet. The company is now making good progress, and got the go-ahead by the local county in April 2026 for a >10B project - congrats to Cloudburst. They broke ground in November 2025 for that first 50MW phase, but the Q4 2026 timeline remains too aggressive based on real-time imagery, since shell construction hasn’t started yet. However, it’s easy to see how Claude Coded forecasts could get confused and assume 1.2GW is delayed. Some publicly available estimates out there claim that the site is planning to deliver 1.2GW by 2026 - which is not even consistent with the company’s own statements.

These are just a few examples of headlines, there are many more. If you look closely at the Claude Coded estimates, you will find many of these announcements are taken at face value. This is not a knock on the developers — as these projects may still be realized later - but an egregious error in many estimates’ methodology.

2. Advanced Projects With Overly Optimistic Construction Timelines

Many do not understand what it takes to construct a datacenter, and there’s plenty of new(er) operators with ambitious plans. Our forecast accuracy is the most reliable because we have refined our timelines extensively. We review every single type of datacenter design, both through local filings, and extensive satellite imagery. The vibecoded datacenter models have not learned what true timelines are, and instead mislead everyone.

Nebius’ 300 MW New Jersey Flagship Datacenter

Nebius’ flagship campus in New Jersey, built by developer DataOne, is a great example of the challenges of constructing a datacenter. In March 2025, DataOne was targeting a 4 month delivery for its first 50 MW phase despite the developer having no prior datacenter track record in the US. The schedule relied on precast materials and extensive prefabrication to compress the build. To be clear, we think this approach was highly innovative and we are big fans, but things are always more challenging than initially expected, especially for a new datacenter developer.

The first challenge arose in the equipment procurement. Per a LinkedIn post of an executive leading the development, late deliveries from a few suppliers pushed the first phase from 4 months to 6, i.e. a 2 month slip on its own.

Then, commissioning and installation proved longer than expected. Satellite imagery shows the shell going up remarkably fast, but setting up the MEP took far longer than the shell itself. In September 2025, the executive still claimed that he would imminently deliver the full facility. But our December 15th capture shows the chillers serving the second 25 MW still not in place, meaning the initial 50 MW building wasn’t complete almost three months after delivery was declared imminent.

Putting the full sequence together makes the slippage easy to see (timeline from DataOne’s own public disclosures, Nebius earnings calls, and our satellite tracking):

• March 2025: targets set at announcement, per the DataOne CEO’s public posts, later eacho’ed by Nebius. 25 MW by July, 50 MW by September, 100 MW by year-end 2025.

• June 2025: first delay acknowledged publicly, delivery pushed to August.

• September 2025: the 50 MW building declared imminently delivered, 4 months becoming 6. Our satellite imagery shows only the first batch of chillers, enough for 25 MW, going onto the roof that month.

• ~October 2025: first 25 MW delivered, seen by the installed chillers.

• Mid-December 2025: our December 15th capture shows the second batch of chillers still being installed. Roughly 25 MW energized against the 100 MW promised for year-end.

• January or February 2026: full 50 MW complete on our estimates, much later than the targeted 4 month delivery. To be clear, a 10-11 month delivery is still very fast relative to industry standards - so congratulations to Nebius and DataOne.

To understand whether the site will be on time for 2026 delivery and Nebius meet its ARR guidance of $7-9B by year-end, check our Datacenter Industry Model.

Core Scientific’s Denton Campus

Shown in our graph as one of the newer operators with impressive plans, Core Scientific ran into issues that an experienced operator would have likely accounted for when projecting timelines. Let’s walk through a quick timeline.

1. In 3Q2024 earnings, they planned to "begin delivery of powered infrastructure for HPC hosting by the end of the first half of 2025". This was in reference to all CoreWeave contracted locations, including Denton.

2. 4Q2024, they planned to expand Denton by 70MW, but also saw a delay coming: “These factors introduced several permitting challenges, which we resolved in collaboration with CoreWeave.” CORZ now guided 250MW delivered to CoreWeave by end of 2025.

   1. In addition, infrastructure redesign due to GB200 redesign issues were cited as delay reasons. These reasons had become very well-known in the neocloud world.

   

3. Their 2Q2025 10-Q then vaguely stated delays were arising due to weather and construction, and further pushing timelines out to end of 2025.

   1. Moreover, we suspect supply chain challenges partially came from a transformer exploding.

Couple this with satellite imagery of a multiple buildings with no chillers installed, this was clear that the 250MW by YE2025 timeline was going to be missed.

Following this, we promptly informed our clients that we see delays coming for CoreWeave.

These challenges are not always avoidable, but experienced operators typically account for them in both timeline and budget.

3. Well-Capitalized Projects Facing Permitting and Local Opposition Issues

Oracle/STACK New Mexico: Permits, a Pipeline, and Pushback

Rather than waving our hands about “regulatory challenges,” let’s detail another project in specific: the STACK Infrastructure/Oracle location that we have delayed to 2029. The following information was published to our Energy Model and Datacenter Model clients, of which the Energy Model is available as a $0 bundle for limited time. Oracle’s June 10 earnings call guided 1H2027 customer delivery for this campus: a timeline FERC records do not support, nor our estimated construction timelines.

Three things went wrong here. The project tried to thread permitting limits with a two microgrid design, each sitting very close to the major-source threshold. It required a large infrastructure buildout, including a brand new gas pipeline. And organized local opposition slowed every step along the way.

In our March Datacenter Model note, we flagged the Oracle/STACK New Mexico Stargate campus (Project Jupiter, in Doña Ana County) with a delay due to its onsite power system was neither finally permitted nor solidified. The entire campus depends on two behind-the-meter gas microgrids, East (NSR 10732) and West (NSR 10734), filed with the New Mexico Environment Department by Acoma, LLC. NMED received both applications on November 17, 2025 and ruled them complete on January 22, 2026, but each microgrid was being squeezed in as an individual PSD-minor source rather than one major source.

NMED’s December 2025 incompletion letters found East could emit up to 521 tpy NOx against a requested 248.90 tpy cap and West up to 388 tpy against 249.97 tpy, both too close to the 250 tpy major-source threshold to be enforceable. On March 23, 2026, NMED pushed both reviews from the April 22 target to July 21, 2026, ordered a public hearing, and cited roughly 7,155 comments plus the applicant’s intent to imminently amend the filings, leaving the public schedule of Q4 2025 construction and Q4 2026 operations untenable.

Meanwhile, the onsite gas generation systems had still not been locked in. In the West Microgrid, for example: “These thirty-four (34) turbines will consist of a combination of GE TM2500 and Mitsubishi FT8 natural gas fired turbines depending on availability for purchase.” Depending on availability for purchase with turbine lead times extending multiple years did not make a great case.

Our Energy Model note “Oracle’s New Mexico Stargate Gas Pipeline Delayed: No Bloom Without Gas” published in May found new developments. With the gas turbines unable to clear permitting in time, Oracle withdrew the East and West turbine applications on April 27, 2026 and filed for Bloom Energy fuel cells instead, targeting ~37 tpy NOx. However, this didn’t solve the binding constraint: the 400,000 Dth/d of gas to arrive in one unprepared pipeline.

A September 2025 precedent agreement between Green Chile Ventures (likely Oracle subsidiary) and Transwestern baked an August 15, 2026 in-service date into the contract, and Transwestern filed the Green Chile Pipeline at FERC (CP26-80-000) on January 29, 2026 seeking an expedited blanket certificate. That route ran into compounding obstacles: on March 20, the New Mexico State Land Office denied right-of-way across state trust land, forcing a reroute, and on April 13, 2026 FERC staff filed its own protest over the missing New Mexico State Historic Preservation Office (SHPO) sign-off while multiple environmental intervenors filed to intervene, starting a 30-day cure window.

Oracle and Transwestern's May 1–4 attempt to extend the cure deadline went nowhere, the window lapsed on May 13 with no SHPO clearance, and on May 15 FERC's Office of Energy Projects opened a formal Section 7 review demanding a full alternative-route analysis avoiding state lands. Transwestern's subsequent sworn filings confirmed no viable alternative route exists and no path around Section 7. The contractual August 15 in-service date became infeasible, and our base case moved first power off 2027 entirely and out to 2029.

NIMBYism rarely kills a capitalized project of this scale outright, but adds months to permits, hearings, and rights-of-way, enough to delay a project past strict deadlines and into large consequences.

Subscribe now

What Is Fueling All This Panic?

If those are what real delays look like, the headlines driving the narrative look very different. Most of what circulates as evidence of a datacenter pullback falls into three buckets: moratoriums, organized local opposition, and announcements with timelines that were never realistic to begin with. None of them survive contact with the actual pipeline.

Moratoriums

A datacenter moratorium is a legislative freeze on new construction permits, designed to give jurisdictions time to assess environmental, energy, and economic impacts before approving more capacity. As of April 2026, at least 12 states have filed moratorium bills, and Indiana alone has at least four counties (Fulton, Marshall, Putnam, and White) that have enacted them. These make for alarming headlines until you look at what they actually cover: none of them had datacenters, and we had nothing in our model beyond early stage.

The most dramatic example is Maine, where the Governor vetoed LD 307 in April, which would have been the first statewide datacenter ban in the US. A statewide ban sounds like ominous for the buildout, except Maine has less than <5MW planned. The pattern holds across the moratorium map: these measures land overwhelmingly in inconsequential areas, or if not, the projects were already too early stage for 2026 anyway.

Not-In-My-Back-Yard (NIMBY)

NIMBYism can be very impactful, as seen with the STACK/Oracle example. The distinction is that opposition slowing a real, capitalized, underway project is rare, and opposition killing a speculative rezoning that existed only on paper is common. The Compass withdrawal in Prince William County, the rejected rezonings in Georgia, the pulled proposals across 20+ states: nearly all of it sits in the announcement layer, where the projects had no equipment ordered, no interconnection agreement, and no 2026 delivery to lose.

Unfounded Announcements

The third bucket is the announcements themselves like we showed above. Most pipeline estimates, including the ones underlying the “half of 2026 capacity will be delayed or canceled” framing, rely on announcement-stage data: a press release, a real-estate filing, sometimes a non-binding LOI, none of which is binding in any meaningful sense.

ERCOT is the cleanest illustration of how this can pile up. As of April 2026, ERCOT was assessing more than 410GW of large-load interconnection requests, over 87% of them from datacenters. Texas’s all-time peak demand is about 85 GW, so the queue is nearly five times the size of the grid itself. However, tracking the veritable projects as we do, there’s 311GW of Phantom Datacenter demand.

When Texas Senate Bill 6 introduced a real filter (site control documentation, a $100,000 minimum study fee, mandatory curtailment terms), speculative filings started to slow down, exactly as a sorting mechanism should work. When the press reports that a meaningful share of the pipeline has been “delayed or canceled,” much of what is actually being canceled are megawatts that never had the site control, the financing, or the interconnection work to clear those gates in the first place.

All three of these generate fear in headlines and roughly nothing in delivered 2026 megawatts. They concentrate in the early stage layer we already treat as structurally oversupplied, they were in our numbers long before they reached financial media, and that is why our estimates have not moved.

Why Hasn’t Our 2026 Outlook Moved?

We have walked through the constraints above and continue to track them closely. The question worth answering is why our 2026 outlook holds despite the headlines.

The short version is that the cancellations and delays cluster in a layer of the pipeline we already treat as structurally oversupplied. The veritable 2026 projects, meaning the ones with site control, equipment on order, interconnection agreements signed, and/or vertical construction underway, continue to progress on schedule. Hyperscalers, whether its self-build or colocation tenancies, are routing around the constraints in ways that announcement-stage tracking does not pick up.

Early Stage Projects Are Structurally Oversupplied

The bulk of project cancellations occur at the earliest stages of development, before projects have cleared the hurdles required to move toward execution. These are typically announcements rather than fully formed developments, projects that lack critical elements such as permitting approvals, committed tenants, vertical construction progress, or secured grid interconnection. In our Datacenter Model, this segment of the pipeline is intentionally treated as structurally oversupplied, seen later in 2028.

The volume of announced capacity at the early stage exceeds what can realistically be delivered, and we view that imbalance as a normal feature of the market. It reflects the asymmetry between low barriers to announcing projects and real constraints on building them. A project generally begins to move beyond this higher-risk phase once it has secured at least two, but preferably three, of the following:

• Secured land: completed acquisition, a signed purchase agreement, a long-term ground lease, an exclusivity agreement, or affiliate/shell entity control.

• A defined power solution: grid interconnection or onsite generation procurement.

• Approved permits: construction approvals and, where relevant, air permits for onsite generation.

Ordering long lead time equipment is also crucial, and that requires deposits and capital.

Subscribe now

Leading Operators Are Adept At Navigating All Constraints

Hyperscalers and leading operators know how to operate in these markets. Land banking multiple locations is the baseline move, but development happens via two parallel playbooks: one political, one physical.

The political playbook: permitting and community

The political playbook is really about permits and zoning. Operators with years of history in a place know who to call and what they need to file. They have the local land-use lawyers on retainer, working relationships with the utility VPs and economic-development staff who keep the project moving, and a track record of having delivered prior projects. Those relationships are maintained through ongoing community investment, from PILOT structures and operator-branded workforce programs to capital infrastructure that doubles as public utility, like the $31M Microsoft put into the Quincy Water Reuse Utility before leasing it back to the city for $10 a year. By the time the public hearing rolls around, the developer has heard every concern before and knows how to sell the project around them.

When the political playbook alone is not enough, the project rarely dies. Developers increasingly withdraw proposals ahead of a formal vote rather than hand opposition groups a public rejection that other counties can cite, then relocate to a friendlier jurisdiction, refile a modified design, or shift to brownfield and unincorporated land where the approval steps are fewer. There’s plenty of times hyperscalers don’t progress with sites, not just the ones that are publicly canceled. The site still dies, but it dies quietly, and the project moves somewhere else. Hence the many landbanks.

The physical playbook: energy and equipment

Grid connection lead times have stretched into 7–10 years in multiple metro areas, and equipment lead times for critical SKUs remain 1y+. The market has evolved adaptations on both axes.

On energy, the playbook has expanded from a single grid-connection path to multiple:

• Pay directly into the grid. Oracle’s deal with DTE to supply BESS systems to support their load, or Meta’s deal with Entergy where Meta pays for the full construction and operation of their dedicated power plant.

• Powered Land. In constrained markets like Europe and US metros, businesses are now selling or leasing grid-connected (or soon-to-be-connected) land outright. Lancium, Cloverleaf, and others are performing remarkably well in this market.

• Behind-the-meter (BtM) generation. One by one, hyperscalers and AI Labs and leading developers are giving up on the grid and going offsite. Read our onsite gas deep dive for more details.

On equipment, three adaptations have moved from edge cases to standard practice over the last 12 months:

• Long-lead procurement in the scoping phase. Hyperscalers now lock in transformers, MV/LV switchgear, and other long-lead SKUs well ahead of vertical construction. Our Industrials Model stays on top of the rising bottlenecks, and after Computex Taipei, we’ve flagged a specific equipment for cooling that likely becomes the next big bottleneck. Contact us for more information at sales@semianalysis.com .

• Chinese OEMs in the supply chain. Few will admit it publicly, but Chinese OEMs are quietly alleviating bottlenecks at the high end of the equipment stack. xAI, for example, likely uses Sieyuan transformers/breakers. Multiple US companies now broker for Chinese OEMs, and in some cases hyperscalers purchase directly. The trend has accelerated meaningfully over the last 12 months.

• Modular and prefabricated builds. Old news in the Chinese markets, new to American AI datacenters. Prefab condenses supply-chain complexity into a single product and dramatically reduces the skilled-labor intensity of onsite assembly, and the same hyperscalers paying inflated wages and onsite housing in Abilene are increasingly the ones leaning on prefab to sidestep that crunch on the next site. We have a dedicated deep dive forthcoming; for now, the takeaway is a meaningful pressure-release valve on equipment and labor constraints simultaneously.

The political playbook secures the first right to build, and the physical playbook ensures the build progresses accordingly.

Subscribe now

What Do We Do Differently?

With all the above challenges and the varieties of workarounds, how are we able to determine veritable delays? Some projects may die on local opposition, some might pass and see the approving council members ousted. Labor is a challenge, or you can import from across the country. Even behind-the-meter sites are still a novel solution.

Our research agents monitor thousands of municipal, county, state, and utility portals — most poorly structured, many actively resistant to scraping, some still publishing in scanned PDFs and handwritten exhibits. We parse them in parallel and reconcile every signal against live satellite imagery, which is how we generate forward-looking delay calls across the full US pipeline rather than just the highest-profile projects.

Where we go beyond what’s public

• Tasking custom satellite captures on specific sites, on specific days for faster cadence than commercial imagery providers default to.

• Scraping social media presence of NIMBY coalitions, construction firms, and local community pages for sentiment shifts before they reach local press.

• On-the-ground site visits and direct outreach to regulators for documents that were never digitized.

The full stack is not disclosed publicly.

The Datacenter Model methodology is coupled with the Industrials and Energy teams tracking the power and equipment/labor markets respectively. When every angle is tracked in parallel, it becomes straightforward to identify which projects carry real cancellation or delay risk, and which apparent “delays” are simply the market culling speculation that was never going to deliver in 2026. Behind the paywall, we discuss another veritable delay coming up, what we are watching, and the players set to benefit.

The Equipment Supplier Narrative Is Wrong Too

We said at the top we would come back to the equipment suppliers. The fear priced into names like Vertiv is that the wave of datacenter delays and cancellations will start eating into record orders and backlog. However, our Datacenter Model capacity forecast shows quarter by quarter delivery, and it’s clear to us that delivered MWs are accelerating.

Equipment lead times remain long. Reinhausen tap-changer bushings, which are a single subcomponent inside a transformer but gate delivery of the entire large HV stack, are now quoted at three to five years. Things have stabilized somewhat over the past year, though most critical SKUs are still running over a year, and several of the major manufacturers, including GE Vernova, Hitachi Energy, and Mitsubishi Electric, are booked out three to four years on their main equipment lines.

Capacity relief is slow to arrive, since production expansion can take two to three years; Hitachi Energy’s new South Boston plant, announced in September 2025, is not expected to be operational until 2028. So in the meantime, the way capacity actually gets allocated is through prepayments. Buyers wire money up front to hold a slot in the queue, which boxes out players with less capital. For behind-the-meter systems, we have heard prepayments in the 10 to 15% range are now standard practice for securing a queue position. AI demand has lifted the pure-play datacenter electricals, Vertiv and Schneider among them, to margins above 20% on the strength of that same imbalance.

Subscribe now

Now run the cancellation fear against that backdrop. The projects getting canceled sit in the early stage layer that never placed equipment orders in the first place; a speculative announcement dying in a county commission hearing removes zero orders from anyone’s books. The projects that do sit in OEM backlogs have prepaid for queue position, locked in long-lead SKUs during scoping, and in many cases already broken ground. And in the rare case a real order does fall away, a queue running three to four years deep means the slot is reallocated to the next buyer in line rather than vanishing.

Our Industrials Model tracks more than 550 datacenter equipment suppliers across 75 equipment subcategories, mapped to over 6,000 facilities globally, and maps every major supplier’s exposure project by project, which is how we separate backlog at risk from backlog that is locked.

What we’re watching into 2H26

Read more

Coding assistants are the greatest B2B SaaS application the world has ever seen: a $30B+ ARR market across the six largest players today, on track to clear $100B by year end, per our tokenomics model.

The agentic coding capabilities of those assistants don’t come from pre-training alone. Post-training, and reinforcement learning (RL) in particular, is what elicits these capabilities from such pre-trained models. Concretely, Claude Opus 4.8 scores 69.2% on SWE-bench Pro and 74.6% on Terminal-Bench 2.1, and RL training is a major part of what drives the score.

Dario Amodei, Anthropic’s CEO, has described RL as showing the same kind of scaling pre-training once did, where performance climbs log-linearly with how long you train (link). However, that scaling is enormously expensive, which makes RL system efficiency critical: it sets how much RL you can afford, and with it how far model capabilities can go.

What governs the efficiency of an RL training system? In this article, we conducted RL training experiments on open models with open-source RL frameworks, and compared pricing to hosted RL training solutions such as Tinker. We show that system efficiency comes down to matching trainer and generator throughput.

Acknowledgements

We’d like to thank the following for close collaboration:

• Prime Intellect: Matej Sirovatka, Ameen Patel, Sami Jaghouar, Johannes Hagemann. We thank their help with providing recipes, hardware resources, and article feedback

• Modal: Peyton Walters, Nan Jiang, Erik Dunteman. We also thank Modal’s API credit sponsorship

• vLLM / Inferact: Kaichao You, Ao Shen

• verl developers: Xibin Wu, Yuyang Ding, Yan Bai

• slime developers

• Verda: Provided compute for experiments

We’d also like to thank the following for reviewing and offering feedback:

• Linden Li, Applied Compute: Gave great advice, and whose AIE talk inspired the article

• Periodic Labs: Dennis van der Staay, Byron Hsu

• Randy Ardywibowo, Perplexity AI

• λux, Non-Euclidean Pasture

• Simon Guo, Thinking Machines Lab

The Three Actors

An open-source RL training system has three actors: the generator, the RL environment, and the trainer. The generator performs inference on prompts from the dataset, generating a rollout: a prompt and a model’s generated response. Unlike in pre-training, the dataset only provides prompts, not the full target. Instead, the system generates the training signal. To generate rollouts, the generator interacts with the RL environment. The RL environment produces a reward based on the rollout. For example, a code environment executes the generated code in a sandbox and gives reward scores based on the test case pass rate. Then, the trainer ingests rollouts and rewards generated by the generator and trains the model, producing new model weights. Finally, the trainer pushes the new weights to the generator, closing the loop of an RL training step.

The RL Algorithm, Just Enough

Unlike pre-training, which maximizes the log-likelihood, RL training maximizes the expected reward. Group-Relative Policy Optimization (GRPO) is the open-source standard, and most open-weight models train with some variant of it.

GRPO samples multiple completions for each prompt, forming a group of rollouts. We assign each rollout a reward, a score of the rollout. We then compute each rollout’s advantage: its reward relative to the group’s average, capturing how much better or worse it did than a typical rollout for that prompt. Rollouts above the group average get reinforced, and those below get suppressed.

If every rollout in a group gets the same reward, each one equals the group average, so every advantage is zero and the group produces no training signal. This is governed by the group’s reward distribution: a group only teaches the model something when its rollouts show different behaviors. The extreme case is a uniform distribution, which happens when a task is too easy (every rollout passes) or too hard (every rollout fails), i.e. when the solve rate is near 100% or near 0%.

From Synchronous to Asynchronous RL

Classic policy gradient algorithms (which GRPO is based upon) assume the rollouts in a group come from the same policy, i.e., the model with the same set of weights. In the context of the training system, this means the generator cannot update weights until it finishes the current batch of rollouts. As a result, if the trainer finishes a training step, it’ll have to wait for the generator. This leads to synchronous execution of training and generation, greatly reducing system efficiency.

PipelineRL introduces asynchrony into the system by allowing the trainer to push new weights to the generator while rollouts are still in progress (in-flight weight updates). This way, the trainer can overlap its execution with the generator’s rollout. However, this comes with a cost. A sample, the unit a trainer consumes, is defined as a rollout and the reward the RL environment assigned to it. With in-flight weight updates, each sample is generated by a mixture of old and new policies. We refer to the phenomenon as policy staleness.

PipelineRL shows that RL algorithms can tolerate policy staleness to an extent. Samples too stale degrade model learning. Synchronous execution wastes too much compute to be practical at scale, and async techniques are essential. In effect, PipelineRL is a throughput-matching scheme with bounded policy staleness. It allows the trainer and generator to run at different speeds, capped by how stale samples can get. This is why PipelineRL has become the de facto implementation in open-source RL training.

The RL Environment and Sandbox

The RL environment provides feedback to the model for the model to learn how to do a task. Practically, the RL environment is implemented as a sandbox, a containerized runtime for code execution. Depending on the complexity of the RL environment, it could range from lightweight Firecracker micro-VMs (micro-Virtual Machines) to full-blown QEMU VMs.

Sandboxes for RL environments have unique system challenges. The interaction latency between the generator and the RL environment is critical to the end-to-end rollout latency, and sandbox startup latency is one of the major overheads. Sandbox service companies like Modal optimize the startup latency with techniques like content-addressed caching.

Serving at scale is also challenging: sandboxes scale along with the number of concurrent rollouts, and the number of live sandboxes fluctuates greatly as rollouts are pruned or completed.

Finally, sandboxes need to be robust against system failures. During learning, a model’s unexpected behaviors may deplete a sandbox’s designated resources. For instance, creating a million files can cause the sandbox to run out of memory. Sandbox orchestration needs to be able to detect and recover from those system failures.

The Throughput-Matching Framework

Quantifying Trainer and Generator Throughput

We view the RL training system as a queue: the generator produces rollouts into a queue, and the trainer consumes from it. When the generator is slower than the trainer, the queue empties and the trainer starves, idling between steps. When the generator is faster, the queue grows and its samples age, causing policy staleness issues.

We model the system efficiency through the lens of matching the producer (generator) and consumer (trainer) throughputs. In an ideal RL training system, the trainer consumption rate should be roughly equal to the generator production rate. The trainer consumes samples, performs a training step, and then broadcasts weights to the generator. We measure the training step time, including the idle time waiting for new samples, the compute time, and the weight broadcast time. We further derive the sample throughput (samples / compute time) to represent the trainer consumption rate. We also calculate FLOP/s per GPU and model FLOPs utilization (MFU) to characterize hardware efficiency.

The generator produces samples through LLM inference and RL environment interactions. Since the straggler, the longest rollout in a group, sets the group's completion time, we measure end-to-end latency to estimate the average sample throughput. We can derive the sample throughput (samples / end-to-end latency) to represent the generator production rate.

We further break down the latency into LLM inference time and RL environment interaction time. RL environment interaction involves sandbox startup latency and sandbox execution time.

Throughput Constraints

Multiple factors constrain the upper and lower bound of the throughput. The trainer consumption rate is samples per step / training step time.

Factors that affect the number of samples include:

• Group size: N samples per prompt, N is usually 8 or 16. Depending on the task difficulty, we increase N to strengthen the advantage signal, e.g., setting N=64 for GPU kernel writing tasks. Larger groups increase the samples per step

• Reward distribution and advantage filtering: Reward distribution of a rollout group affects the sample advantage, and it reduces the samples per step under different advantage filtering strategies. For example, task difficulty: Tasks being too easy or too hard leads to uniform reward distribution (All zero or all full rewards), causing zero advantage. If we drop zero-advantage samples, it reduces the samples per step.

• Batch size: There’s a minimum effective batch size that enables stable learning. We typically deploy the trainer on sufficient GPU nodes to hold those batches

Factors that affect the training step time include:

• Model: Model architecture, including model size, activation size, model precision, dictates the memory usage, setting a minimum GPU count to perform forward and backward pass without running out of memory. It also determines what operations the GPU executes, affecting the training step time

• Parallelism and memory configurations: Tensor/Pipeline/Data/Expert Parallelism, Fully-Sharded Data Parallelism (FSDP), memory offloading, activation checkpointing. They are affected by the GPU count and determine the system efficiency and the training step time

On the generator side, we define the generator production rate as the number of concurrent rollouts / end-to-end latency.

Factors that affect end-to-end latency include:

• Inference throughput: Recipe tuning for the inference engine, including parallelism strategies, KV cache quantization, PD disaggregation, and speculative decoding

• Sandbox latency: Sandbox startup time and execution time

• Reward modeling type: Math and coding tasks may have lightweight verifiers as reward models, while writing tasks may use LLM judges. Reward model types determine the rollout evaluation latency: lightweight verifiers are fast, and LLM judges are comparatively slow

• Reward shape: Process Reward Models (PRMs) may evaluate the rollout per turn, whereas some reward models evaluate only the full rollout. This determines the reward assignment latency

Concurrency, or the number of concurrent rollouts, is limited by KV cache memory space and average sequence length. The aggregate memory capacity of generation nodes - model weights and activations are the space for KV cache. KV cache dictates the maximum number of tokens the generator can hold, and dividing it by the average sequence length gives us an estimate of max concurrency.

Not all generated samples are consumed by the trainer due to training signal quality differences. We further define the effective generator production rate as acceptance rate × generator production rate. Factors that affect the acceptance rate include:

• Early pruning: We prune rollouts before completion based on heuristic length caps, value functions, or intermediate-result verifier checks. This dynamically reduces the number of concurrent rollouts

• Adaptive sampling: We reject rollouts based on criteria, such as online advantage filtering

Policy Staleness

Staleness is the gap between the policy version that produced the sample and the one that the trainer uses when it applies the gradient. Staleness is a byproduct of async training: the trainer pushes weight updates in-flight while rollouts are being generated.

Staleness happens at different granularities. At the trajectory level, staleness is the gap between the policy that the rollout starts generating with and the newer policy the trainer updates, e.g. the trainer is at version t+k while the trajectory started from version t. Token-level staleness occurs when in-flight weight updates happen mid-rollout, so different policy versions generate different parts of a rollout. Policy staleness also happens at an environment state-level, which we explain more in the Partial Rollout and Stateful Sandbox Design section.

Policy staleness means the trainer trains the model on off-policy signals, which can destabilize training, so we typically set a policy staleness budget. The policy staleness budget bounds how stale a sample can be, i.e. how far the generator is allowed to run ahead of the trainer before its samples are rejected. This in turn caps the gap between the generator’s production rate and the trainer’s consumption rate, which is what lets the two run at different speeds.

The policy staleness budget limits the max difference between the trainer consumption rate and the effective generator production rate. Concretely, it limits how many steps the generator can be ahead of the trainer, so the RL algorithm can tolerate the max staleness in samples.

The Moving Target: Model Capability and Behavior

Model capability and behavior are first-class system variables in RL training. Model capability determines how well the model can solve a task, measured by solve rate: what percentage of the rollouts in a group passes the verification. When the solve rate is near 0 or near 100%, the reward distribution is uniform, leading to zero advantage, and collapses the training signal. This drives decisions including group size and advantage filtering strategies. It also shapes the curriculum: the order of tasks being presented to the model. The curriculum is chosen to keep the solve rate at a productive middle band, so the tasks are neither too easy nor too hard for the model’s current capabilities.

A model's token usage behavior affects the output length, which indirectly determines the max concurrent rollouts in the generator. RL training typically elicits Chain-of-Thought reasoning, causing a model to generate long reasoning traces. This behavior drives the average output length, which increases KV cache usage. Under the same memory budget, this reduces the max concurrent rollouts and increases the sample generation end-to-end latency.

A model’s tool call behavior affects the sandbox time in the end-to-end latency. Concretely, more tool calls increase the sandbox time, and unexpected tool call operations strain the sandbox infra. We measure the tool call behavior with the number of tool calls and the sandbox error rate.

Both model capability and behavior shift during RL training. Model capability improves, and behavior drifts. The constraints move with them, and the training system has to adapt to ensure efficiency.

Case Studies

We ran experiments to ground our theory, and we shared our experiences with open-source RL frameworks.

We select the following configurations:

• Model: We chose Mixture-of-Experts (MoE) models since SoTA open-source models are mostly MoEs

• RL environment and tasks: We chose agentic coding tasks for its popularity and its sandbox workload complexity, allowing us to see sandbox performance characteristics

• Node count: We aim for experiments with at least 10 nodes to show the trainer-generator dynamics and fit training MoEs

Long Model Response and Early Exploration Training Phase

Setup

• Model: Qwen3-235B-A22B-Thinking-2507. We use BF16 precision for training and the FP8 variant for sample generation, a common setup in RL training

• Trainer: 64 H200 GPUs, FSDP, EP8, CPU-offloaded optimizer states and activations

• Generator: 192 GPUs, 24 inference instances: Each DP1, TP8, EP8

• Batch Size: 512 samples

  • Group Size: 16 rollouts per problem

  • Problems per batch: 32 problems

• Max sequence length: 32K

• Maximum policy staleness: 16 steps

• RL environment: Mini SWE Agent Plus, with Prime Intellect Sandboxes

• RL framework: Prime RL

• Code: Recipe coming soon in repo’s main branch. Original commit here

Analysis

In this case study, we show how two factors influence the system efficiency: how the model produces long responses with long thinking traces, and how well the model learns the task.

The model’s long response behavior is the dominant driver of LLM inference time, which makes up the majority of sample generation time. Long-response variance also drives severe tail latency within each rollout group, which forces a system-side mitigation: oversampling. With oversampling the generator launches more concurrent rollouts than the trainer needs per batch and it discards unfinished or errored ones as soon as the target count is reached. In this run we discard a relatively high 60% of dispatched rollouts, reflecting how skewed the latency distribution becomes when the responses are long.

On the model capability side, the curriculum is slightly too hard for the base model. We observe the number of rollout groups that produce zero solutions jump sharply after the first training step, but average reward and pass@16 are slowly recovering. These are signs that the early RL exploration pushed the policy away from previously solvable problems before it could relearn them.

The combined effect is a generation-bound system: the queue runs dry and the trainer starves. To mitigate this issue, we trade off trainer efficiency for generator efficiency. The trainer consumes samples at 2.75 sample/s, waits 30% of the wall-clock time, and runs at 10.5% MFU. On the other hand, the generator delivers 1.95 sample/s and uses 3x the trainer’s compute. This underscores how much inference efficiency matters during RL training.

Frequent Tool Use and Easy Task

Setup

• Model: GLM-5. We use BF16 precision for training and the FP8 variant for sample generation

• Trainer: 128 H200 GPUs, FSDP, CP2, EP8, CPU-offloaded optimizer states

• Generator: 128 H200 GPUs, 2x 64-GPU inference replicas

  • PD Disaggregation: 32 prefill GPUs, 32 decode GPUs, both DP32 and EP32

  • 1TB KV cache offload per node

• Batch Size: 512 samples

• Group Size: 16 rollouts per problem

• Problems per batch: 32 problems

• Max sequence length: 64K

• Maximum policy staleness: 16 steps

• RL environment: Mini SWE Agent Plus, with Prime Intellect Sandboxes

• RL framework: Prime RL

• Code: Recipe coming soon in repo’s main branch. Original commit here

Analysis

In this run, we see two factors set the system efficiency: model behavior drift and the curriculum being too easy for the model.

We observe both the average response length per turn and the number of tool calls (20 to 51) triple over the run. Together they push sequence lengths up and shift the workload toward a prefill-heavy profile. This supports our choice of disaggregated serving, which improves the worst-case time-to-first-token (TTFT) for prefill requests.

On the capability side, the curriculum is too easy for the model. On average, 55% of problems have a 100% solve rate, i.e., every rollout in the group passes. A rollout group where every rollout has the same reward produces zero advantage and contributes no training signal. As a result, average reward stays flat. The curriculum mismatch reduces the effective training samples and subsequently the effective generator production rate.

All the effects result in a heavily generation-bound system. The queue fills up fast, but a large portion is filtered out, so the output is low. LLM inference dominates end-to-end generation time and keeps growing as training progresses. The trainer spends 74% of the wall-clock time waiting, and its consumption rate is 5× the generator’s delivered production rate.

Sandbox Scaling Challenge

Setup

• Model: Qwen3 235B A22B Instruct 2507, both FP16

• Hardware: GB300

• RL framework: verl + uni-agent rollout

• RL environment: SWE-bench-style env, with Modal sandbox

• Algorithm: GRPO

• Max sequence length: 128K

Training Stages

1st Stage:

• Trainer: 32 GPUs, TP16 / EP32, CPU offload

• Generator: 24 GPUs, 6 replicas, TP4

• Group size: 8

• Number of concurrent rollouts: 96

2nd / 3rd Stage:

• Trainer: 48 GPUs, TP4 / CP4 / PP3 / EP16, CPU offload

• Generator: 24 GPUs, 6 replicas, TP4

• Group size: 8

• Number of concurrent rollouts: 256 (2nd) / 360 (3rd)

Analysis

The training dynamics were roughly in line with our other Qwen3 235B training runs. The run was generation-bound: trainer idled 30% to 60% of the time. Generation length grew aggressively: 3 to 8% of the samples hit max sequence length 128K, and for similar reasons, the tail latency blew up to 7500s for a noticeable straggler on step 9.

The unique part of this case is that we pushed the concurrent rollouts and encountered sandbox scaling issues. Scaling concurrent rollouts is critical to sample generation throughput. It enables higher batch size, more reward signal variance, and subsequently provides a better training signal. However, each rollout corresponds to at least one sandbox, and scaling rollout concurrency challenges the sandbox infrastructure reliability. In this case, we experimented with concurrent rollouts ranging from 96 to 960. At 960, once we pushed past our account's configured limits, we encountered sandbox initialization dead errors and straggler 1-hour sandbox spin up latency, and to mitigate that, we scaled down to 96, but then observed low rollout efficiency. This experiment shows how critical sandbox scaling is to RL training efficiency.

We thank Ao Shen and Kaichao You from vLLM / Inferact for helping conduct this experiment. The detailed writeup of errors and attempts is here, the WandB logs of the final stage training are here, and the code repo is here (verl, uni-agent).

Partial Rollout and Stateful Sandbox Design

Setup

• Model: Qwen3-235B-A22B-Thinking-2507-FP8 (FP8 generation, BF16 training)

• Trainer: 32x H200 GPUs, TP4 / CP4 / PP2 / EP8

• Generator: 64x H200 GPUs, 8 replicas, TP8 / EP8

• 32K max sequence length, global batch size 64

• Algorithm: GSPO, group size 8

• RL framework: slime

• Async setup: Fully asynchronous + partial rollout

• RL env: SWE-Bench Verified and Lite, with OpenHands harness and Modal sandbox

• Code repo: slime SWE Bench example

Analysis

Overall, this experiment has system characteristics similar to other Qwen3 235B runs: generation-bound with 60% trainer wait ratio, long 12K response length per turn, a moderate average 12 tool calls per sequence, and a relatively low resolve rate.

We’d like to highlight slime’s partial rollout feature and how the sandbox design has to adapt to support it. Partial rollout allows the straggler rollouts to be saved into a buffer and restarted in a later batch. This mitigates the long tail latency of straggler rollouts, which improves system efficiency.

In slime, partial rollout marks straggler rollouts as aborted, saves them to a replay buffer, and puts them into the queue in future batches. This creates challenges for the sandbox:

• Sandbox needs to persist across rollout batches, since SWE-Bench problems can be stateful: a partial rollout may be in the middle of editing files. This also means we need additional logic to track the sandbox ID and sample mapping

• Sandbox needs to be lazily created: sample processing logic is coupled with sandbox creation, but there may be cases where the sample fails to emit tool calls, and creating a sandbox in that case would be wasteful

• Sandbox robustness to failure: If sandbox fails during the time between a sample being aborted and being restarted, we need extra logic to ensure correctness. Since we didn’t figure out how to do failure resumption on Modal, we opted to mark the sample as failed

Slime triggers partial rollout abortion in two situations: when a target rollout batch is filled (64 samples in our case), and when the trainer pushes a weight update. This leads to an interesting dynamic of partial rollout count in the replay buffer. We see the number increase after steps 5, 10, and 15, since we update weights every 5 intervals. We also see the number spikes at step 7 and 17, and we believe it’s due to the previous step (step 6 and 16) completing as soon as it reaches the target rollout batch, leaving a big backlog.

Unlike PipelineRL, slime’s SGLang configuration evicts the KV cache for aborted rollouts. This means resumed rollouts are essentially large prefill requests, which is exactly the workload type that benefits the most from PD disaggregation.

Partial rollout is where environment state-level staleness shows up. When an aborted rollout resumes in a later batch, the trainer has pushed new weights in between, so the resumed rollout faces not only the policy gap, but a state gap that’s specific to stateful environments. In our SWE-Bench case, the sandbox it wakes up in is not a fresh repo. The sandbox holds the half-applied edits, created files, and working-directory state that the old policy produced over its earlier turns. The newer policy now must continue from a situation it didn’t create and wouldn’t necessarily have created itself. This can corrupt the training signal: during training, the advantage gets attributed to a trajectory the current policy only partially owns. Seeing the high resume rollout count after weight updates, we suspect environment state-level staleness contributes to the run’s low resolve rate.

In summary, partial rollout rescues the stragglers to maintain the queue-filling throughput, but it comes at the cost of stateful-sandbox complexity and explicit environment state-level policy staleness.

Software User Experience

Prime RL

Prime RL has great user ergonomics. Users perform most commands with uv and configure setups in the .toml files. Prime RL also comes with agent skill files, allowing users to use AI agents more smoothly when working with the repo.

Regarding system design, we appreciate that Prime RL has an “orchestrator” actor to clarify who manages the trainer-generator dynamics. We love the hub of RL environments Environments Hub and look forward to it continuing to grow. Prime RL uses Torch Titan for training, vLLM for generation, and their in-house Prime Sandbox for hosting RL environments. Prime RL also supports PD disaggregation for the generator, which greatly boosts performance on agentic RL training. Overall, the codebase is lean and has most state-of-the-art techniques.

However, we also encountered some rough edges. Prime RL’s heavy reliance on uv assumes users have great familiarity with uv. We spent a lot of time compiling and re-installing flash attention 3 because we couldn’t figure out why uv uninstalled it. We encourage Prime Intellect to provide more resources to educate users on how uv works, in addition to the docs saying what uv commands not to execute.

Although Prime RL assumes it runs on a SLURM cluster, it assumes jobs run on bare metal instead of Pyxis. When we ran into CUDA library version mismatch for DeepGEMM libraries, running jobs in containers would solve the issue more easily.

We also had a lot of failed runs that turned out to be Prime Sandbox failures. We had a hard time parsing through Prime Sandbox’s error messages, which usually happens late into the run.

Errors include dangling sandboxes using up sandbox quota, out-of-resource errors, out-of-credit issues, many of which can be detected before launching a run. Prime Sandbox is still in beta, so we expect it to improve in the future.

We thank Prime Intellect for supporting the effort, including software and hardware resources. Prime Intellect provided training recipes based on this PR (Commit hash here).

slime

slime is known for its clean and minimal abstractions, and we believe it lives up to the hype. We particularly like slime’s hook abstractions. They allow us to write customized functions for rollout processing, reward functions, and metric logging utilities. The function signature and contracts are clear, and it’s a breeze to integrate and add new features during development.

We also want to highlight how friendly and helpful slime’s developer team is. Zilin, slime’s core maintainer, has offered guidance on configuration tuning and answered slime design questions.

Our main gripe is slime’s focus on co-located mode, and as a result sparse documentation of asynchronous modes. We figured the difference between async and fully async and the mechanisms of partial rollout mostly through trial and error. We hope slime can provide better documentation on those topics.

Modal

Modal has great API documentation: We referenced Modal’s Sandbox API extensively when implementing the sandbox integration in slime, and the documentation is clear and helpful. Modal services have also been relatively robust throughout our experiments. Under small scale, Modal has been reliable, and creating / terminating sandboxes is easy and responsive. The Modal team has also been very friendly and helpful. Modal offered support early on in our effort with API credits, and Modal’s slime integration team Peyton and Nan offered great advice and feedback on our experiment results.

The main challenges for Modal arose when we ran many concurrent sandboxes. As we reported above, we saw dead initialization errors and long-tail sandbox start-up latencies. We suspect this was our own misuse of the API rather than a hard limit in Modal, but we couldn’t pinpoint the root cause on our end during training. We later reached out to Modal and collaborated on identifying the issue. It turned out to be the resource limit on our account, and we were able to verify the stability of high sandbox concurrency after Modal raised our limits (Reproduction code here). We appreciate the responsiveness of Modal’s developer team, and we hope Modal can offer more sandbox observability tools and more documentation on how to scale sandboxes in the future.

History of Open-Source RL Frameworks

The release of DeepSeek R1 sparked the open-source community effort to reproduce the algorithm and infrastructure. One of the early efforts is OpenRLHF, a large-scale RL training framework that implemented PPO, REINFORCE++, and then GRPO. OpenRLHF profoundly influenced the subsequent RL framework developments. Numerous OpenRLHF maintainers later developed popular RL frameworks, including slime and verl. These frameworks created vibrant Chinese communities of RL training, which we believe positively contributed to recent advances of Chinese models. These open-source frameworks also enabled academic researchers to develop new algorithms and techniques, bringing RL research within reach of academia.

We thank Kaichao, who led vLLM’s early-stage RL integration in OpenRLHF, verl, etc., for sharing this history. We hope this shows that sincere collaboration and sharing, rather than hostile competitions and information hiding, propels science forward.

Conclusion

RL training system efficiency is a matter of queue health. Oversampling, early pruning, and partial rollout controls what enters the queue, adaptive sampling and policy staleness controls what leaves the queue, and in-flight weight updates allow trainer and generator to operate at different rates.

RL training is as much of an infrastructure problem as an algorithm one. In this post, we focused on systems, explaining how system and algorithm designs are intertwined, and grounding them with real-world experiments. We hope this ignites interest in RL infrastructure and bridges RL algorithm researchers with system engineers.

We plan to continue exploring the systems and infrastructure of RL training in our future articles. We will explore in depth techniques such as PD disaggregation and speculative decoding, and system challenges of large-scale RL training such as training Nemotron 3 Ultra. We are also looking into benchmarking sandbox infrastructure and analyzing model rollout traces.

If you’re interested in working on these topics, we’re hiring! Please contact us at letsgo@semianalysis.com . Attach your resume and ask us questions about this article.

For our last section, we present a TCO analysis of RL training, and we compare it to RL training platforms Tinker from Thinking Machines Lab. We quantify how much more cost efficient Tinker is, and we hypothesize the reasons behind it.

RL Training TCO Analysis

Read more

The headline is true, but an incomplete cherry picked metric. N+3 reaches the density of TSMC N6 through aggressive DUV multi-patterning and design-technology co-optimization (DTCO), but it pays for that in complexity, efficiency and process control.

We found this and more in our reverse engineering and teardown where we cover SMIC’s N+3 process technology, Huawei’s packaging, memory, architecture, and other exciting features. SemiAnalysis has been building a state-of-the-art teardown lab in Oregon capable of analyzing the world’s most advanced and important chips over the last year and a half. We have already generated revenue on advanced datacenter chip teardowns including our recent reverse engineering of a major TSMC customer’s COUPE CPO optical engine + EIC 3D stack.

This is the first public report from the SemiAnalysis Teardown Engineering & Evaluation Lab, or STEEL for short. The lab is aggressively scaling up and out and we’re excited to announce it publicly. This is a bit of inconvenient timing for TechInsights as they are private equity owned and currently being sold while having enjoyed virtually no credible competition for decades. This has led to TechInsights underinvesting in CAPEX.

SemiAnalysis exceeds TechInsights in revenue despite no venture or private equity ownership and being founded only 6 years ago. Because we have no external investors and are founder-led, we move faster, build faster, and we can release client chip teardowns for free regularly, while focusing on datacenter for our major clients.

Here’s the first public image from our lab, the HiSilicon Kirin 9030 Pro SoC:

This report will detail our teardown of the Kirin 9030 and our findings on SMIC’s N+3 process, the most advanced in China. For comparison, we’ll show our teardown of the MediaTek Helio G99, made on TSMC N6. Through this comparison, we can look at the effect of export controls – SMIC N+3 and TSMC N6 are comparable nodes, but one is heavily export-controlled, the other free to use the West’s most advanced equipment.

Here we see both China’s progress and constraints. SMIC N+3 reaches TSMC N6-class logic density, but it requires far more aggressive DUV multi-patterning, so it does not match N6 on process maturity or cost. The Kirin 9030 Pro performs similarly to three-year-old Android flagships, and trails far behind the current flagship SoCs from Apple, Qualcomm, MediaTek, and Samsung. The efficiency gap is even wider.

Export controls have not stopped Huawei and SMIC from shipping advanced silicon, but they have forced a different path. Without EUV, SMIC is leaning harder on DUV multi-patterning, DTCO, and increasingly complex integration. The roadmap continues forward through tighter design rules and backside power, but each step adds cost and process risk. Huawei’s τ scaling and LogicFolding show another path: stacking active logic and recovering density through advanced packaging and system-technology co-optimization (STCO).

Die Shot & Floorplan

To understand the Kirin 9030, we must first understand Huawei’s SoC history. HiSilicon is Huawei’s chip design arm, responsible for the Kirin smartphone SoCs, Kunpeng server CPUs, Ascend AI accelerators, and switch/router networking silicon.

Before export controls, Huawei was one of TSMC’s largest customers – the only customer on TSMC’s first EUV node, N7+, and among the first on N5, alongside Apple. That ended in late 2020. Huawei switched to Qualcomm SoCs in its flagship smartphones, though export controls limited them to 4G-only variants.

In late 2023, Huawei returned to in-house silicon with the Kirin 9000s, a successor to the Kirin 9000, fabricated on SMIC N+2 instead of TSMC N5. In the following years, they released the Kirin 9010 and 9020 on the same N+2 process. These chips used Huawei’s in-house TaiShan CPU cores and Maleoon GPU.

We have not torn down a Kirin 9020 ourselves, so the predecessor die shot is from Kurnal. The die shots show how Huawei spent its silicon budget: which functional blocks are where, and how their areas compare to the predecessor.

First, a quick guide to the major blocks on the die.

The total die area is nearly identical, but the 9030 uses that area more aggressively. A denser process lets Huawei fit an extra middle CPU core, more GPU and NPU cores, and larger caches into the same footprint.

In contrast, the Helio G99 is a much smaller, low-cost SoC, built for budget smartphones rather than a flagship device. While the Kirin 9030 is ~140 mm², the G99 is only ~29 mm², roughly one-fifth the area. The underlying TSMC process technology, however, is directly comparable as a baseline for analyzing SMIC’s.

Architecture & PPA

The Kirin 9030 is an evolutionary refresh, not a clean-sheet design. Its CPU, GPU and NPU cores carry over the 9020’s families, and the gains come from three levers: the SMIC N+2-to-N+3 process step, DTCO and floorplan work, and incremental microarchitecture. Area is where the first two show up, and the 9030 scales well here. Performance and efficiency are the harder test. Huawei’s design holds up better than its node would suggest, but the chip still trails, both because N+3 sits behind the leading-edge nodes and because its cores, while competent, remain a few generations behind the newest designs.

The new prime core is an incremental update. The main changes are a 10% frequency increase from 2.5 GHz to 2.75 GHz and a doubling in the L2 cache from 1 MiB to 2 MiB. Despite the increased cache, the core size decreased by 7.6%. Excluding the private L2 cache, the core size decreased by 21%. This is a large reduction for an incremental node.

Compared with the TaiShan New V120 core in the Kirin 9020, the Kirin 9030’s middle core is almost unchanged architecturally, yet each core shrinks by ~22%. Most of that comes from the move from N+2 to N+3, with layout likely accounting for the rest.

Visually, the most noticeable change is the increase from 3 middle cores to 4. There is also a 20% increase in the shared L3 cache of the big cluster. This helps to improve multi-core performance without sacrificing much in terms of area.

Even with each core shrinking, the big CPU cluster’s total area is essentially unchanged. The per-core savings went back into an additional middle core and larger caches.

The tiny cores shrank less than the prime core (excluding its L2 cache) and less than the middle cores. This is likely because fixed overhead is a larger share on a small core. We cannot resolve any architectural changes from the die shot alone, but the per-clock and efficiency gains shown below point to more than pure process and layout scaling. The area reduction was offset by a doubling of the shared L2 cache from 2 MiB to 4 MiB, leaving the total tiny CPU cluster area slightly larger.

Area is the easiest improvement to see from a die shot, but it is only one part of PPA (power, performance, area). For modern logic, power and performance matter just as much, and often more. Since Dennard scaling broke down in the mid-2000s, voltage and frequency have not scaled in step with transistor dimensions, so each node has had to fight harder for gains in performance and efficiency.

The starkest comparison is not Kirin 9020 versus Kirin 9030 Pro. Apple’s efficiency cores run circles around Huawei’s prime core. Apple’s low-power core delivers 20% higher integer performance while drawing only 1 W, compared with 4.5 W for Huawei’s prime core. N+3 matches TSMC N6, but N6 is several generations old. Apple and Qualcomm build on N4 and N3P, which are denser and sit on a better voltage-frequency curve, giving them a larger transistor budget and more performance per watt.

The 9030’s own cores did improve. The middle and tiny cores gained 17% and 14% in per-clock integer performance over the 9020, with floating-point flat on the middle core and up 11% on the tiny. The tiny core improves cleanly, with performance rising while power falls and efficiency increases by 45% in integer and 24% in floating point. The middle core is mixed: integer performance rises but power rises faster, cutting integer efficiency by 7%, while lower power lifts floating-point efficiency 16%.

Per-clock gains at the same or lower frequency are microarchitectural, so the cores are tuned, not just shrunk. Both also failed to hold their rated maximum frequencies, pointing to thermal, power, or stability limits. Per clock, the middle core sits around Arm Cortex-A720 and the tiny core near the Cortex-A520; absolute performance trails because Huawei clocks them much lower.

The prime core is roughly Cortex-X2 class per clock, a 2021 design. Apple’s 2020 M1 Firestorm core is still 35% higher per clock and 57% faster in absolute integer performance at a similar 4.5 W. The current leading edge is further ahead again: the Apple M5 P-core is 60% higher per clock and 2.7× faster, the Arm C1 Ultra 45% higher and 2× faster.

Matching older high-end cores per clock is a genuine design achievement. What Huawei cannot match is the voltage-frequency curve and transistor budget of leading-edge nodes, which let Apple, Qualcomm and others spend more transistors in the same area on wider cores, larger caches and deeper buffers while running at lower voltage.

Huawei’s LogicFolding roadmap is one answer, stacking active logic to recover density and shorten signal paths. We return to it later.

The GPU compute units (CUs) changed more visibly than the CPU cores, moving to a more rectangular layout for both the arithmetic logic unit (ALU) clusters and the CU overall. Even with ray-tracing support added, a CU shrank ~28%.

However, that shrink is offset by the increase from 4 to 6 CUs and the area outside the CUs grew 33%. Overall, the GPU cluster is larger by ~10%.

The GPU is where Huawei makes its biggest gains. The Maleoon 935 is not competitive with current flagships, but it is a large step up from the 920 and reaches older-flagship territory. In 3DMark it is 70% faster in Wild Life Extreme (WLE) and 79% faster in Steel Nomad Light (SNL) than the 920; with 11% higher clocks and 50% more CUs, the ~67% theoretical uplift roughly matches WLE and is beaten by SNL.

It edges ahead of the Snapdragon 8+ Gen 1 in WLE and SNL, and the Dimensity 9200 and Apple A16 in WLE, but stays far behind newer parts: the Snapdragon 8 Elite Gen 5 and Dimensity 9500 are ~2.4–2.6× faster in WLE and ~3.2× faster in SNL.

The Maleoon 935 is Huawei’s first GPU with hardware-accelerated ray tracing; there it lands slightly ahead of the Exynos 2200, and on par with the Apple A16, with current flagships up to 3.7× faster.

The Neural Processing Unit (NPU) saw the largest structural changes of any block, moving from a Lite and a Tiny core in the Kirin 9020 to a Lite and two Tiny cores in the Kirin 9030. Both core types also show significant layout changes.

This is a reversal in Huawei’s NPU design. The Kirin 9000 5G, its last flagship chip on TSMC N5, used two Lite and one Tiny core. The series of SoCs on SMIC N+2 moved to one Lite and one Tiny core, likely for area savings. With the Kirin 9030, Huawei has shifted back toward a larger multi-core NPU cluster, but with the additional area going to a Tiny core rather than a Lite core.

We’re diving deep into the most advanced datacenter and AI hardware hitting the market. To learn more about what’s in the pipeline or to commission a custom teardown, contact sales@semianalysis.com. Interested in joining us on this ride and think you can be a difference maker? Check out our Careers page.

Before diving into the process stack, the package and memory are worth separating from the SoC itself.

Memory

The Pro variant of the Kirin 9030 carries 12 GB of Samsung DRAM, with two stacks of four dies each. The dies were identified as the K4L2E165YD, a 12 Gb LPDDR5X-9600 device fabricated on Samsung’s 1a node, the fourth generation of its 10 nm-class DRAM after 1x, 1y and 1z. 1a has shipped in volume since 2022, so this is current memory rather than older-node inventory.

The 16 GB Pro Max variants we obtained were found with both CXMT and Samsung packages. The CXMT package is marked CXDD7JEDM, with two stacks of four dies, packaged in week 45 of 2025. The inferred die dimensions from X-ray computed tomography (CT) are consistent with a known density of ~0.3 Gib/mm² for the CXMT G4 process, roughly equivalent to other manufacturers’ 1z processes.

Packaging

The Kirin 9030 uses a typical integrated package-on-package (iPoP) stack: multiple DRAM dies in a memory package sit above an organic redistribution layer (RDL) interposer, which sits above the SoC and package substrate. The full package is then mounted to the printed circuit board (PCB) through ball-grid array (BGA) solder bumps.

The memory package substrate is a thin bismaleimide-triazine (BT) laminate carrying the LPDDR5X stack. The organic RDL interposer over the SoC routes the PoP signals around the die and carries possible dummy thermal copper pillars. The package substrate, a thicker Ajinomoto Build-up Film (ABF) build-up over a BT core, fans the flip-chip bumps out to BGA pitch and embeds the power planes.

The whole stack is organic. The only silicon is the SoC and the LPDDR5X dies; there is no silicon interposer. Keeping it all-organic brings the package’s coefficient of thermal expansion (CTE) close to the PCB’s, reducing board-level warpage, and avoids the cost of a silicon interposer the SoC’s bandwidth does not need.

In an iPoP stack, the memory package connects to the organic RDL interposer through an array of solder bumps. Underfill fills the gap around those bumps, adding stiffness and protecting the joints from mechanical stress. The Pro and Pro Max variants differ here, which we cover behind the paywall.

Process

The die shot and architecture tell us how Huawei allocated its silicon budget. The process tells us what SMIC can manufacture. We use the Helio G99 as the process reference for TSMC N6. Both SMIC N+3 and TSMC N6 are evolutions of previous 7 nm-class nodes.

We used targeted TEM cross-sections through logic and memory regions, imaged in both fin-cut and gate-cut directions. Each cross-section caption gives its horizontal field width (HFW), the real width of the imaged area. We start at the transistor fins, then move up through standard cells, local interconnect, and SRAM.

SMIC has not overtaken Intel or TSMC. It uses aggressive DUV scaling and DTCO to reach N6-class density, but that density doesn’t translate into comparable performance and efficiency, for two reasons: the node gap to leading-edge nodes, and Huawei’s core designs.

Fin Profile

One of the most important knobs in a FinFET process is the fin profile: the shape of an individual fin and the channel where current passes from source to drain. The ideal fin is tall, narrow, and nearly vertical. A taller fin increases effective channel width, while a narrower fin improves electrostatic control by thinning the body the gate must control. Push either too far, and the process pays for it: weaker drive current, fragile fins, taper, footing and line-edge variation that hit yield and device variability.

The Intel 22 nm, 14 nm, and 10 nm fin cross-sections show how FinFET nodes have improved over time. 22 nm fins were a first-generation structure, relatively short, wide and strongly tapered. The shape limits current density and reduces gate control uniformity across the height of the fin. At 14 nm and 10 nm, Intel pushed the fins taller and narrower while also making the sidewalls more vertical. Rather than shrinking the device, these changes increase the effective channel width per fin and improve electrostatic control. The trade-off is that taller fins at tighter pitches are much more difficult to manufacture.

Now, let’s compare the Helio G99 on TSMC N6 with the Kirin 9030 on SMIC N+3. Both processes are in the same class, with fin pitch of 30-32 nm on N+3 and 34 nm in our N6 cross-section. The pitch for N6 is especially interesting as N7’s HD library is generally listed with a 33 nm fin pitch, and N6 did not shrink pitches directly. Its density gains came from DTCO instead of tighter pitches. The 34 nm pitch was stable across our sampled region and serves more as a comparison against the SMIC N+3 we have not investigated further.

Pinning down N+3’s fin patterning scheme takes more than one core unit. The CPU cores show a dense ~32 nm pitch, with the pitch between N-P fin pairs alternating between 78 and 88 nm. Logic alone may be consistent with dual-pitch mandrels of 120 and 110 nm, but this is a complex and unusual approach. Combining the pitch from the the 8T SRAM, which has more complex repeat unit, with the CPU core sequence allows us to reverse engineer the patterning steps with more confidence.

As both the logic and SRAM should share the same base grid, a single CD mandrel lithography pattern with 128 nm pitch undergoing SAQP produces a die-wide ~32 nm grid (128 nm/4), which supports the pitch sequencing seen in both logic and SRAM cells.

In the sampled cross-sections, N+3 shows a taller, narrower, higher-aspect-ratio fin than N6. The measured fin aspect ratio is ~9.5:1 on N+3 versus 7.8:1 on N6. N+3 also shows less top rounding, with an estimated radius of ~2 nm, compared with 2.8 nm on N6. Even though the fin widths differ, the ratio of top rounding to fin width tells the same story, with N+3 at 0.37 and N6 at 0.44. In a geometric sense, lower is better; a perfectly rectangular fin would have no top-rounding penalty.

These are single-digit-nanometer features measured from a handful of cuts, so treat the absolute numbers as approximate. The important result is the relative gap: N+3’s fins are consistently taller, narrower and less rounded than N6’s.

We’re diving deep into the most advanced datacenter and AI hardware hitting the market. To learn more about what’s in the pipeline or to commission a custom teardown, contact sales@semianalysis.com. Interested in joining us on this ride and think you can be a difference maker? Check out our Careers page.

Standard Cell

A standard cell is the basic building block of chip layout: a fixed-height row pairing one NMOS and one PMOS transistor that share a gate, tiled in a grid to build logic blocks. The key dimensions are contacted gate pitch (CGP), cell height (CH), fin count, and the lower-metal routing grid.

To measure density, we use the Bohr metric: a weighted average of NAND2 gate area (60%) and scan flip-flop area (40%). This represents a realistic mix of combinational and sequential logic. This metric has its limitations, especially for complex cell layouts like TSMC’s FinFLEX, which alternates cells with different fin counts. Even so, it is the best metric for a pure process-level comparison.

Another important measurement is the fin pitch; it refers to the distance between two fins of the same transistor. In a FinFET process, multiple fins are used in each transistor to increase the drive current and thus performance.

TSMC N6 ships both a high-density (HD) library with 2 PMOS and 2 NMOS fins per cell, and a high-performance (HP) library with 3 of each. More fins under the shared gate mean more effective channel width. HP cells switch harder at the cost of area. Designers mix the two on a die, primarily spending HP cells on timing-critical paths, and matching their PPA targets.

In the Cortex-A55 core of the Helio G99, we found a cell height of 240 nm for the HD cell. MediaTek has used HD cells in the G99 to minimize die size and thus cost. As an SoC for budget smartphones at ~$100, this is essential.

By contrast, we found only one library in the Kirin 9030, with 2 NMOS and 2 PMOS fins. This suggests a narrower library strategy than TSMC N6, where both HD and HP libraries are widely used. This likely reflects the smaller customer base and the more constrained domestic design and electronic design automation (EDA) ecosystem.

In all three CPU cores of the Kirin 9030, we found cell heights of 228 nm, 5% smaller than on N6. This is also a reduction of 9.5% over SMIC N+2’s cell height of 252 nm.

SMIC N+3 and TSMC N6’s HD library both feature a CGP of 57 nm. For SMIC, this is a 9.5% shrink over N+2.

In the past, CGP and cell height alone may have been enough to compare transistor density. Now, however, we must consider scaling boosters and DTCO as well. SMIC’s density gain does not come from EUV. It comes from using every available DTCO booster aggressively.

First is fin depopulation: reducing the number of NMOS and PMOS fins in each cell. The first FinFET nodes started with 3 or 4 fins for each transistor. SMIC N+3 and TSMC N6 HD both use only 2 fins per transistor, trading drive strength for density.

Next is contact over active gate (COAG). By landing the gate contact directly over the active gate, instead of out over the isolation region, the cell height drops. N+3 integrates COAG while N6 does not. Our N+3 gate-cut cross-sections indicate COAG, with the gate contact sitting over the active region, while N6 shows an off-gate contact.

Last is single diffusion break (SDB). Diffusion breaks are inserted between cells in the same row to provide electrical isolation, but they also introduce local layout effects (LLE), layout-dependent shifts in electrical characteristics. In the past, a double diffusion break was used, consuming the space of two CGPs. SMIC N+3 and TSMC N6 instead use SDB, saving area but increasing LLE sensitivity. This must be controlled at the process level and accurately modeled in the process design kit (PDK) so that EDA tools can account for it.

Overall, SMIC N+3 has a transistor density of 113.4 MTr/mm², slightly above TSMC N6 at 107.7 MTr/mm². Even without EUV, SMIC has achieved density beyond TSMC’s mature N6 node which utilizes EUV.

Metal Stack

The smallest critical dimension in the teardown is M0; SMIC N+3 uses a 32.5 nm local metal pitch. That is smaller than the 36 nm M0 pitch on Intel 18A in Panther Lake. However, this does not mean that SMIC has a better process than Intel 18A or TSMC N3P. M0 is a local intra-cell routing layer. Its usefulness depends on the full interconnect stack: M1 and M2 pitch, track count, via and line resistance, design rules, mask count, overlay control, and routing flexibility.

The 32.5 nm M0 is consistent with self-aligned quadruple patterning (SAQP), whose four-population line-width loading we read coarsely as alternating widths of 21.5 to 24 nm; M1 and M2, at 38 and 40 nm, are consistent with self-aligned double patterning (SADP), a single A/B split. On TSMC N6, M0, M2, and M3 sit at a relaxed ~40 nm and are consistent with SADP-class double patterning, with no need for quadruple patterning. That said, we measure M2 for example at ~43 nm, likely inflated by sparse routing. We do not assign any specific layer to EUV from our cross-sections; the distinction we can draw is double versus quadruple patterning, not lithography wavelength.

Transistor-level density in the front-end-of-line (FEOL) sets an upper bound, but the design is ultimately limited by what the interconnect stack can route. The lowest metals are the most important for standard-cell density, but the semi-global and global layers determine how usable that density is at the block and chip level.

Two axes are commonly used for chip cross-sections: the fin-cut and the gate-cut. The micrograph above is a fin-cut and shows metals 0 through 3. This axis lets us see the even-numbered metals, with M0 right above the fins.

There are two kinds of M0 lines. The first are the power rails; these are wide wires for the VDD and VSS running horizontally at the top and bottom edges of each standard cell. The wide wires measure 55 nm across, more than double the other M0 lines. Their width minimizes resistance and reduces IR drop. The second kind are intra-cell wires, short segments within the cell that connect terminals to M1. These have alternating widths between 21.5 and 24 nm.

The M0 pitch is 32.5 nm, a 19% reduction versus N+2 and N6. At this pitch, DUV patterning requires more aggressive multi-patterning, increasing mask count, overlay sensitivity, process complexity and cost.

M0 is below what a single DUV-defined spacer (SADP) can resolve, so SMIC cascades a second spacer step (SAQP). The cross-section reflects the cost: the M0 trenches are visibly more re-entrant (narrower at the bottom than the top) than M1 or M2 on the same chip and carry a bright barrier-rich foot where the trench meets the etch-stop layer. That shape is partly the intended damascene profile, as a slightly narrow bottom helps void-free copper fill, but its magnitude at M0 is driven by the tight pitch and the higher trench aspect ratio.

Intel 18A supports an M0 pitch of 32 nm, although Panther Lake has only shipped with a looser 36 nm pitch. This is due to Intel’s heavy usage of HP libraries. Among leading-edge nodes, 18A has the loosest M0 pitches due to PowerVia. With power routing moving to the backside, congestion is reduced, and the entire front-side metal stack can be used for signal routing.

M2 is the first true inter-cell routing layer. It runs horizontally like M0 but spans across multiple cells to carry block-level signals. The M2 pitch sets the cell’s track height – the number of M2 tracks that fit between the VDD and VSS rails, defining what the library calls a 6-track or 7.5-track cell. This layer is the most important, limiting the routing of entire blocks.

SMIC N+3 features a 5.7-track cell. The M2 pitch is 40 nm, a 5% decrease over N+2 and the same as N6. This shrink keeps the pitch at the edge of what is possible with double patterning. Future nodes will need to increase the number of masks for M2 as reducing the number of tracks is much harder due to the limitations in routing.

The micrograph above is in the perpendicular direction, the gate-cut, and shows metals 0 through 4. This allows us to see and measure the odd-numbered vertical metal layers.

The M1 pitch is 38 nm, 9.5% less than N+2 and 33% less than N6. The M1-to-gate ratio matters because it sets local routing flexibility. N+2 and N+3 use a 3:2 ratio, while N6 uses a 1:1 ratio, explaining the huge differences in M1 pitch. The more M1 lines there are compared with the gates, the more flexibility there is for power and signal crossing within the cell. Routing flexibility enables more complex and better cells. Clean fractional ratios are also preferred as a grid is periodic and improves layouts. The 3:2 ratio gives SMIC more local routing flexibility than a strict 1:1 grid, but it also complicates layout and patterning. This is a DTCO choice, with SMIC increasing process complexity to recover density and routability without EUV.

This 3:2 ratio is not very popular in the leading-edge nodes. TSMC has only used it on N7+, the N5 family, and the short-lived N3(B). They have switched back to a 1:1 ratio for N3E. Intel has only used it on the 10 nm/Intel 7 family, with Intel 4, 3 and 18A all using a 1:1 ratio. Samsung is the only one still using a 3:2 ratio at the leading edge, using it in the SF4 and SF3 families. It remains to be seen if SMIC will remain at a 3:2 ratio or move to a 1:1 ratio with its future nodes.

The industry is still actively exploring these local-routing ratios. At VLSI 2026, imec will be presenting work on even higher ratios, including a 2:1 scheme that can reduce area by up to 14%. We will be covering the conference in a future newsletter article.

Subscribe now

We’re diving deep into the most advanced datacenter and AI hardware hitting the market. To learn more about what’s in the pipeline or to commission a custom teardown, contact sales@semianalysis.com. Interested in joining us on this ride and think you can be a difference maker? Check out our Careers page.

The final local interconnect layer for N+3 is M3, with a pitch of 44 nm. The M3 pitch is the same as on N+2 and 10% larger than on N6.

The semi-global layers carry the majority of block-level signal routing. They have a coarser pitch than the lower local layers. On leading-edge nodes, they are designed to sit at the limit of DUV single patterning.

M4 through M11 pitches were found divided between 80–82 nm (M4–M6), 128 nm (M7–M10), and 148 nm (M11). Given limited sampling, it is possible these are divided further in dense routing areas. At the top are two giant metal layers, M12 and M13. These have kept the same pitches as N+2 at 1920 nm and 4600 nm respectively.

While the lower layers’ pitches are generally fixed by the process and library, the upper layers vary much more in pitch and count, depending on the design. Even two smartphone SoCs on the same process can have wildly different metal stacks. The Helio G99 carries fewer routing layers, reaching coarse metal pitches of 850 nm by M9, while the larger and higher-performance Kirin 9030 keeps fine pitches until M11.

SRAM

At the leading edge, SRAM is much more difficult to scale than logic. TSMC’s latest nodes have seen little to no bitcell scaling, while logic still has more DTCO levers to pull.

While looking for other logic libraries in the GPU compute units, we stumbled upon the SRAM. The most common type of SRAM has 6 transistors (6T), but this cell had 8 transistors (8T) instead.

8T SRAM adds two transistors to form a dedicated read port. Unlike a 6T cell, where reading disturbs the storage, the decoupled read port removes read-disturb, improving read stability and letting the cell be pushed harder for performance.

At first glance, the cut looked like an unusual logic library, with each cell row having 3 fins of one polarity and 5 fins of another. The rows also alternated in orientation.

Energy-dispersive X-ray spectroscopy (EDS) resolved our confusion. The cut had not landed on the GPU logic, but on the SRAM macro beside it. The unusual fin pattern was due to the SRAM library. We return to EDS in the process flow analysis behind the paywall.

SRAM libraries are not like traditional logic libraries. Due to the unequal number of PMOS and NMOS transistors, they require specialized rules and layout libraries. They do not need the flexibility of logic libraries, so they are hyper-optimized for one purpose: dense, reliable memory.

The SRAM cell we found is a 1:2:2-2:2 cell. This means there is 1 fin per pull-up (PU) PMOS transistor, and 2 fins per pull-down (PD) and pass-gate (PG) NMOS transistor. These 2 PU, 2 PD and 2 PG transistors would usually form a single 6T high-current cell (HCC). An 8T HCC adds a read-pull-down (RPD) and a read-pass-gate (RPG) NMOS transistor, each with two fins.

We measured a cell height of 406 nm, which brings the bitcell size to 0.0463 µm². That is a theoretical peak density of 21.6 Mib/mm². We estimate that a 6T HCC would have a cell height of 292 nm and a size of 0.0337 µm². This is ~12% larger than a 6T HCC on Intel 3 and 4.

We also estimate the 6T high-density cell (HDC) to have a cell height of 228 nm and a size of 0.0260 µm². This is coincidentally the same as the logic standard-cell height measured earlier. The estimate puts the cell near Samsung 7LPP/5LPP and slightly below TSMC N7/N6. That is a theoretical peak density of 38.5 Mib/mm². 6T HDC is arguably the most important cell as it is used for the largest caches in a chip, the L3 caches and system-level cache (SLC).

Both the Kirin 9020 and 9030 have split the SLC into 4 banks to raise total SLC bandwidth. In the Kirin 9030, the SLC increased from 2 MiB to 3 MiB per bank. Correspondingly, the number of arrays within the bank also increased by 50%, from 16 to 24. Each array can store 128 KiB and forms an orderly pattern on the die shot.

From the Kirin 9020 to the Kirin 9030, the area of a 128 KiB SLC array decreased from 0.0477 mm² to 0.0392 mm², an 18% shrink. The achieved density is 25.5 Mib/mm², 66% of the theoretical maximum.

While the SLC was quite similar across both chips, the L3 has seen some major changes, particularly in terms of its layout. The total capacity also went up from 10 MiB to 12 MiB. Much like the SLC, the L3 is also split into 4 banks.

In the Kirin 9020, an L3 bank consisted of 16× 128 KiB arrays and 16× 32 KiB arrays. However, an L3 bank in the Kirin 9030 instead consists of 48× 64 KiB arrays.

In the Kirin 9020 L3, a 128 KiB array was 0.0513 mm² and a 32 KiB array was 0.0154 mm². The size of the 128 KiB array is different on the L3 and SLC as the assist circuitry for the two arrays differs depending on their purpose.

In the Kirin 9030 L3, a 64 KiB array is 0.0210 mm². Although not a like-for-like comparison, normalized for capacity, it is 18% smaller than the 9020’s 128 KiB L3 array and 31% smaller than its 32 KiB L3 array. The achieved density is slightly lower than the SLC, at 23.8 Mib/mm², 62% of the theoretical maximum.

Unlike the L3 and SLC, the prime cores’ private L2 cache uses a 2-bank design. As the prime cores’ L2 is latency-critical, it likely uses 6T HCC instead of 6T HDC. The 9020 has 16 arrays in each bank while the 9030 has 32. Each array has a capacity of 32 KiB.

A 32 KiB array in the L2 shrank from 0.0171 mm² to 0.0142 mm², ~17% smaller. The density is 17.6 Mib/mm², ~59% of the theoretical maximum for 6T HCC.

SRAM scaled well from N+2 to N+3, shrinking by ~19%, close to the theoretical logic shrink. The caveat is that N+2’s bitcells were unusually large, bigger than comparable 7 nm-class nodes, so part of the gain is catch-up rather than true scaling.

With the insights from STEEL’s teardowns, we will be doing a deep dive into SRAM in a future newsletter article.

Subscribe now

Everything above came out of a single STEEL teardown: die annotation, block-level area analysis and TEM cross-sections through logic and SRAM. We’re diving deep into the most advanced datacenter and AI hardware hitting the market. To learn more about what’s in the pipeline or to commission a custom teardown, contact sales@semianalysis.com.

Future Roadmap

The same cross-sections that pin down N+3 also show where SMIC can go next. Although N+3 is already close to the practical limits of DUV multi-patterning in several layers, SMIC still has a few scaling levers left.

A theoretical N+4 would likely start with cell height. N+3 uses 5 M0 tracks between its power rails. Moving to 4 M0 tracks, as on SMIC N+2 and TSMC N6, could reduce cell height by roughly 15%. The routing grid is only one side of the shrink; the front end also must fit into the smaller cell.

One possible FEOL lever is reducing the p-to-n isolation spacing from two diffusion grid units to one. Intel used this scaling booster on Intel 4, and TSMC did so on its N3 family. This path trades layout flexibility for density. Fewer M0 tracks reduce local routing resources, while tighter p-to-n spacing raises integration and design-rule difficulty.

M2 is also constrained by the cell height shrink. For SMIC to maintain a ~5.7-track cell, M2 would need to move toward ~35 nm. That would move another layer into SAQP territory.

SMIC could also reduce the CGP from 57 nm to 54 nm. Intel reached a similar CGP on Intel 10 nm/Intel 7 without EUV. The local interconnect is also tougher. If SMIC keeps the 3:2 M1-to-gate ratio, M1 would need to shrink to 36 nm and would likely require SAQP as well. If SMIC moves to a 1:1 ratio, M1 could relax to 54 nm, but it would give up routing flexibility.

Under this theoretical path, we estimate that SMIC N+4 could reach a cell height of 198 nm and a CGP of 54 nm, implying a Bohr density of 137.8 MTr/mm², on par with TSMC N5 or Samsung SF4. However, the difficulty is cumulative. Each step is individually plausible, but together they make N+4 harder than the transition from N+2 to N+3. It will likely take longer, cost more, and carry less process margin.

A theoretical N+5 would require a larger integration shift. One possible path is backside contacts (BSCon), moving power routing and source/drain contacts to the backside, which would reduce front-side routing pressure and enable another reduction in cell height.

The front-side metal pitches could relax to reduce the process complexity. M0 would likely relax slightly to ~34 nm, and M2 and M4 pitches could relax further. CGP is unlikely to shrink much further. Even with EUV, 48 nm has been the practical limit for yield and process control.

This approach would allow N+5’s cell height to fall to 170 nm and its CGP to 53 nm. This implies a Bohr density of 163.6 MTr/mm², on par with Intel 18A’s HP library. However, this would not make N+5 cost-competitive with the leading edge. It would reach a similar density through a much more expensive route. The integration difficulty rises sharply, with new process flows for backside alignment, wafer thinning, contact reveal, and backside metallization.

Past this point, standard density and interconnect scaling become increasingly unattractive. That is where Huawei’s roadmap stops looking like a normal foundry roadmap and starts looking like a packaging roadmap.

Huawei’s τ Scaling Law

At ISCAS 2026, Huawei unveiled its tau (τ) scaling law, reframing process scaling in the time domain. τ is the time cost of data movement and processing: switching delays in transistors, RC signal propagation delays in circuits, compute, memory, and networking latency. Outside Huawei’s terminology, this is called system-technology co-optimization.

This is Huawei’s answer to its lack of EUV lithography. Without EUV, planar density cannot keep pace with TSMC, Intel, or Samsung. If transistor density cannot shrink further, Huawei’s alternative is to shorten wires, reduce buffering, and stack logic vertically.

“LogicFolding”, Huawei’s implementation of this new scaling idea, is, in practice, an aggressive 3D stacking approach. AMD V-Cache places SRAM above or below a CPU die. AMD’s MI350X places active interposer dies (AIDs) underneath accelerator and compute dies (XCDs), with the AIDs handling cache, IO interfaces, the network-on-chip (NoC) and embedded metal-insulator-metal (MIM) capacitors. With LogicFolding, parts of the same logic block are split across multiple active dies bonded face-to-face at ultra-fine pitch. This allows Huawei to shorten some critical paths and reduce buffer overhead, not merely add cache capacity or offload the IO and interconnect.

Shortening wires is where the higher clocks come from. A large share of a modern core’s delay and energy budget goes into driving long interconnects and the repeater buffers along them. LogicFolding distributes a block’s critical-path gates across multiple stacked tiers bonded at a very fine pitch, so the bond interface behaves like an additional metal layer and the longest paths get shorter. That is how Huawei expects to recover frequency and efficiency it cannot get from the process alone.

Huawei’s roadmap shows its intent. Prime core frequency is targeted to rise from 2.75 GHz in the Kirin 9030 to roughly 5 GHz by 2031, far beyond what planar scaling alone could deliver. Prime cores with 3.1 and 3.39 GHz clocks are being tested in its labs, although their power consumption is unknown. Beyond that, chips are in the design, simulation or pathfinding phase, meaning the frequencies are targets. However, the direction matters more: LogicFolding also helps with performance, not just density.

The catch is that Huawei’s density claim is not directly comparable to foundry densities. A stacked design can report more transistors per package footprint by adding active layers, even if each patterned die remains well behind TSMC or Intel in front-end density. This is how Huawei can claim to reach foundry 14A-equivalent density by 2031.

This is not a like-for-like foundry comparison, with Huawei using stacked logic and measuring density per package footprint. On a normalized Bohr-density basis, SMIC N+3 is ~114 MTr/mm², 38% less than Intel 18A’s HD library. Huawei’s 3D roadmap closes the gap by stacking active logic, reaching 215 MTr/mm² by 2030. In 2031, the roadmap density jumps to 295 MTr/mm², implying either a third active layer, partial EUV insertion or aggressive planar DUV scaling.

Huawei’s methodology makes other foundries look much denser as well. Applying it to AMD’s MI450X with an N2 top die on an N3P base die yields a theoretical density of 460.2 MTr/mm² in 2026, compared with Huawei’s 295 MTr/mm² in 2031.

This Kirin 9030 does not use LogicFolding, remaining in a conventional mobile SoC package. Instead, it forms the baseline for how far Huawei and SMIC can push planar scaling. Future teardowns of Kirin and Ascend chips will show both planar logic density and Huawei’s hybrid bonding solutions.

Export Controls & Future Scaling

Export controls changed China’s optimization problem rather than ending it. EUV restrictions raised the cost and complexity of leading-edge manufacturing without freezing it. SMIC reaches N6-class logic density through DUV immersion, SAQP and DTCO, while Huawei shifts more of the burden onto architecture, packaging and system-level integration.

Future nodes will be tougher. N+3 still had room to tighten local metals and reduce cell height and CGP. Further scaling without EUV leaves fewer levers. More aggressive multi-patterning adds masks and overlay error. SMIC can keep pushing DUV, but each step will get more expensive and less forgiving.

The design side is just as critical. Huawei had domestic EDA tools and flows before the Kirin 9030, with the Kirin 9000s, 9010 and 9020 making that clear. Huawei was able to ship multiple consumer SoCs on SMIC N+2 and N+3 while cut off from the Western EDA stack.

US export controls restricted EDA tools for advanced chips in 2022 but did not target tools for more mature chips. In 2025, the US government briefly placed much broader restrictions on EDA software from Synopsys, Cadence, and others, before lifting them less than two months later as part of a trade deal tied to rare earths. Huawei has been unable to access those tools because it remains on a US trade blacklist.

That forced Huawei, SMIC and Chinese academic institutions to build their own tools and flows. Researchers at Peking University recently announced a prototype EDA tool for Huawei’s LogicFolding architecture, which requires a new flow to handle the multilayer layout and floorplan. This is not the same as replacing the full Synopsys or Cadence stack, but it shows where domestic EDA is headed: toward tighter co-optimization between architecture, process and packaging.

These advances are also diffusing into the Chinese ecosystem. SMIC is licensing its N+2 and N+3 processes to HLMC/Hua Hong at the government’s direction rather than by choice. If the same process learning feeds into Ascend accelerators for AI training and inference, the choke point shifts from one named fab to an ecosystem. Alibaba’s T-Head silicon arm and Cambricon, a Chinese AI chip designer that is expected to supply ByteDance, could also be major beneficiaries. Sanctions aimed at SMIC alone become less effective once the manufacturing knowledge has spread to other fabs and design houses.

China is not closing the gap with Intel, Samsung and TSMC. The teardown shows the opposite in several places: no EUV, no backside power, higher process complexity, and visible trade-offs.

But China is still advancing. If domestic chips become good enough for phones, inference, networking and security-sensitive workloads, they can matter strategically without matching TSMC at the leading edge.

Behind the paywall, we show what else STEEL can do, with material and process flow analysis of SMIC N+3, and analysis of the Kirin 9030 package.

We’re diving deep into the most advanced datacenter and AI hardware hitting the market. To learn more about what’s in the pipeline, access the full Kirin 9030 and SMIC N+3 analysis or to commission a custom teardown, contact sales@semianalysis.com.

Read more

Franky Yeary just stepped down from the board after 17 years, and now the new board is filled with people who actually understand the industry, and not financial engineering. The new chair is ex-Qualcomm, Lip Bu Tan is the CEO, and Steve Sanghi of Microchip, Stacey Smith, Eric Meurice of ASML are all there. The board actually understands technology. But while Intel’s turnaround has partially begun, there is a lot more on this long road to a completely revitalized Intel. Today we think that Intel should make another large strategic bet with their fresh board, and it’s instead of buying back shares, it’s time to issue enough shares to fix Intel’s finances for good.

Lip Bu Tan has taken Intel back from the brink, and has raised ~20 billion dollars from the government stake, Softbank, Altera and Nvidia’s strategic investments. They should not stop partially, and capitalize on share prices. They were large net buyers of shares during the bad years, it’s time to issue equity into strength, and if they do it right, it will make Intel’s turnaround that much more successful.

Dilution Here Rewards The Investors Who Already Bet

Look at where that capital came in. The U.S. government took up to 433 million shares at $20.47, a 9.9% stake at signing, with 149 million still in escrow at the end of Q1. SoftBank paid $23.00, Nvidia paid $23.28. Every one of those holders is already above water.

So the instinct that a raise punishes the people who just showed up runs the wrong way. Issuing stock at today’s price, well above those entry marks, lifts book value per share and hands the government, SoftBank and Nvidia a gain. That 10% sovereign anchor is also the reason a large offering clears cheaply in the first place. Intel is one of the very few companies on earth that can sell size into a hot tape with the U.S. government holding the floor, and that is leverage worth using while it exists.

Intel Needs Capital for Execution

Intel has pretty much never traded this expensive on a trailing twelve month basis since the 2000 bubble. While we believe there is a bright future, one of the most critical things it will take is capital, and the share price is not discounting real execution risk.

What’s more, even in the best of cases from the new renewed demand from Agentic CPU, Intel cannot pay for the best of upsides even. We think it’s time for Intel to do a reverse buyback, and issue equity during this equity demand window.

Equity Is Now The Cheapest Money Intel Can Get

The objection will be that Intel has other ways to fund a fab. It tried all of them, and just told us they don’t work. Apollo put $11.2B into 49% of the Fab 34 joint venture. Brookfield structured the Arizona build. Silver Lake took 51% of Altera at an $8.75B enterprise value, netting Intel about $4.3B. Intel sold its NAND business to SK hynix in stages and sold additional Mobileye shares. Smart Capital was the whole identity.

Then, on March 31, 2026, Intel agreed to buy Apollo’s 49% of Fab 34 back, closing April 8 for $14.2B, roughly $7.7B of cash and a $6.5B bridge loan. Management called the unwind accretive, and they were right, which is the whole point. If buying a fab stake back is accretive, then selling fab economics to a partner was expensive money all along. A SCIP hands a sponsor a permanent cut of your best asset in exchange for capital that costs more than it looks, and Intel has now shown with its own checkbook that it would rather own the fab and carry the debt.

So cross the alternatives off. More SCIPs are the option management just spent $14.2B reversing. More debt stacks on top of the $45.0B already on the balance sheet, roughly $51.5B once the Apollo bridge is in. The largest asset monetizations have already been substantially harvested. Intel sold control of Altera and has monetized part of Mobileye, while retaining approximately 48% and 78%, respectively. Further sales remain possible, but these are no longer untouched sources of capital at the scale previously available. Against this valuation, equity remains Intel’s cheapest scalable source of capital.

The foundry business is just beginning with their large Terafab announcement as well as overflow demand from the great N3 shortage. To truly capitalize on this special moment, Intel must be the great supplier of the rest of the industry hungry for leading edge wafers. And that huge bet requires capital well in excess of their ability to fund from operations today.

Just a 4-5% dilution would raise ~$25 billion dollars and easily allow for the most bullish supply capacity story to come true during this critical time.

Agentic CPU Demand Ain’t Enough to Pay for Terafab

SpaceX and Tesla as well as Terafab is the large customer commit that solves the 14A capacity issue. And the initial target of 100k WSPM scaling to 1 million (going to be hard) is going to be extremely rough in terms of capital. This needed to happen, as Lip Bu Tan has publicly told the market he would shut Foundry down if there were no customers. And now that a customer has come, its time to build.

Beyond the Terafab partners, the order book is filling in. Nvidia’s DGX Rubin NVL8 lists dual Intel Xeon 6 host CPUs. Google signed a multiyear deal covering Xeon and custom IPUs. SambaNova came in on inference. The wafer volumes behind these wins are not all disclosed, but capital markets fund a visible book far more cheaply than they fund a turnaround story, and Intel finally has one to point at. An equity raise sold against signed demand prices very differently from one sold against a promise.

Intel has been working it’s absolute hardest to defer capex on lower than expected demand for CPU, but it’s time to bet the farm again ala Gelsinger style. This is the critical moment for silicon sovereignty, and its time to press.

The full multi-phase project for Intel is going to cost up to $119 billion dollars, and while SpaceX is putting up the initial capital, Intel has to contribute meaningfully. Even a marginal amount of capital matching means that this is 10s of billions of dollars that were not in the capex decision matrix just a month ago.

It’s time to undo a decade of financial engineering and issue equity now. Because while the ramp is exciting, it’s going to cost a lot. The equity issuance window is the biggest it’s been in a moment, and if Cerebras can raise 5.55 billion, Intel can raise 25. The point only gets stronger, since Intel’s roughly $498B market cap easily supports a far larger follow-on. The window as we see it seems to be wide open, here’s some stats from other issuance recently.

How Big The Agentic CPU, Terafab, and 14A Ramp Needs to Be

Read more

In section 2 of our blog post, we do an comprehensive analysis of DeepSeekv4’s inference on Day 0 Huawei Ascend 950DT. This article serves is the first analysis of Ascend 950DT DeepSeekv4 inference and we breakdown the compute<>communication lap & the different compute streams that Huawei did to optimize performance.

A key goal of InferenceX, especially during a model’s Day 0 release window, is to record each SKU’s performance using open-sourced images and recipes across as many frameworks as possible, regardless of how well these images and recipes perform. This enables us to track improvements over time, which we believe best reflects the real, deployable performance of each chip. The video below shows iterative improvements for non-MTP configs from Day 0 onward for vLLM/SGLang, respectively. visit inference.com to see the MTP configs from day 0 onwards too.

The graphics reflect the thousands of engineering hours that went into tuning DeepSeek v4 inference performance and most of the optimizations are merged into the master branch of SGLang/vLLM. One of the north star goals of InferenceX is to highlight the iterative improvements to performance over time, instead of just snapshots of performance, after all when it comes to engineering, the things you learn along the way are often just as important as the end result.

In the early days of DeepSeek v4 Pro, CUDA vLLM and CUDA SGLang and CUDA vLLM disaggregated prefill worked great out of the box, proving the strength of the vLLM and SGLang open ecosystems. These inference engines are so fundamental to the global ML ecosystem that both teams have started their own company, Inferact and RadixArk, with each raising hundreds of millions of dollars to continue to fuel the growth of their open-source inference engines.

Huawei Ascend has also described and demonstrated Day 0 inference performance support for DeepSeekV4 in their documentation. China currently dominates the open model landscape, with Kimi K2.6 still beating Jensen’s Nemotron Committee Coalition’s Nemotron 3 Ultra on coding. Furthermore, Nvidia’s in house TensorRT-LLM did not work well for DeepSeek v4, and we at SemiAnalysis had to fix their open source mHC kernel launch code. Thank you for NVIDIA engineers for rebasing and merging our patch!

ROCm did not work well either in the first couple of days of DeepSeek v4’s launch. That said, the AMD SGLang engineering team, under the technical leadership of HaiShaw, massively improved performance in the first month - achieving a more than 100x performance by Day 26. We will talk more about the good, & the bad, of AMD software progress in our upcoming, comprehensive State of AMD 2026 article.

All performance tracking is documented in our open-source GitHub repo. Feel free to give us a star if you find the repo useful: https://github.com/SemiAnalysisAI/InferenceX.

Our full DeepSeekV4 performance dashboard can also be found here.

The SemiAnalysis InferenceX inference initiative is supported by many in the ML community, including OpenAI, Oracle, Microsoft, Weka, PyTorch Foundation, vLLM, SGLang, and CoreWeave, among others.

The InferenceX team is hugely thankful for the ongoing engineering efforts carried out by the vLLM community maintainers, Inferact, as well as all of the SGLang maintainers around the world at RadixArk, Meta, and elsewhere. We would also like to shout out to and thank Nvidia engineers Kedar Potdar, Ankur Singh, Xin Li, Alec Flowers and many other Nvidia engineers for their Day 0 support for this project. We would also like to extend our appreciation to the AMD engineering team for their Day X support of DeepSeek v4 Pro on the ROCm stack.

Unfortunately, our GB300 cluster happened to be down when DeepSeek v4 was released. Luckily, CoreWeave came through and contributed compute to the open source community and maintainers, scrambling to find two spare dev GB300 NVL72 racks. Our GB300 results were only achievable because of their support, and we are using it around the clock to drive further improvements to results.

If you want to work on low-level benchmarking, InferenceX, or other interesting technical work, then send us your resume to letsgo@semianalysis.com with three bullet points demonstrating your engineering abilities. If available, please attach GitHub repo links, websites, or blogs to show off your projects, work, and knowledge.

Section 1: DeepSeekV4 Pro Day 0 Performance

In this section, we will start by discussing DeepSeek v4 Pro’s out of the box performance on Day 0. We will reference throughput-interactivity curves, how different parallelisms favor throughput versus interactivity, and other inference optimizations such as MTP and disaggregated inference, which were explained in the InferenceX V2 article.

Note that to avert a potential Inference World War 3 and prevent another round of vLLM vs SGLang twitter drama/rap battle, for this article, we will not be showing results for both vLLM and SGLang for same hardware SKU on the same graph.

The following two graphs shows all the Day 0 recipes we managed to record, with most recipes using the native model checkpoint utilizing mixed FP4 MoE-FP8 Attention quantized weights (except for the H200 and MI355X SKUs). Because the native FP4+FP8 checkpoint for DeepSeekV4 Pro was not usable on Day 0 for the MI355X, we were only left with the option of using a full FP8 non-native checkpoint.

Unfortunately, AMD SGLang and AMD vLLM distributed inference still does not work on DeepSeekV4 Pro.

Turing to SGLang and vLLM, both supported native DeepSeek v4 Pro on the CUDA platform the moment the model was released publicly. Most advertised recipes, especially for newer SKUs such as B200/B300, worked out of the box without any major issues.

The below graph shows SGLang Day 0 performance:

Let’s now dive deeper into each group of Day 0 results.

Day 0 Multi-Node Disaggregated Prefill on GB200 NVL72

vLLM and Nvidia were very fast in delivering their GB200 distributed inference Dynamo vLLM recipe in srt-slurm. Disaggregated inferencing and wide expert parallelism (WideEP) are inference optimization techniques that can considerably improve performance per dollar - readers can learn more about these techniques in our InferenceX V2 article. The recipe itself was rudimentary: eager on prefill, using NIXL for KV cache transfer. We independently replicated the recipe achieving up to 5x better results than for a B200 run using lower interactivity configs.

This is a great example of the CUDA moat at work: With CUDA, distributed inferencing tends to be supported near Day 0 for the latest open models.

Day 3 Multi-Token Prediction (MTP) Speculative Decoding

The first MTP support delivered for DeepSeek v4 came on Day 3 from SGLang. Using MTP led to a substantial improvement in throughput at higher interactivities. An explanation of MTP and how it benefits memory-bound small batch size decode can be found in our InferenceX V2 article.

Subscribe now

Day 0 ROCm AMD MI355X Disappointment

Turning to ROCm on AMD MI355X, our Day 0 results for DeepSeek v4 were confusing. Most AMD users in the open-source ecosystem were also mired in confusion. The MI355x could only run FP8 on Day 0, and delivered results on the bottom left of the chart below in the overall Day 0 plot. Inference was technically working, but it was an unusable experience given extremely low interactivity levels of only 1-2 tokens per user per second, far below average user reading speeds.

We used the Day 0 WIP recipe provided by an SGLang PR, courtesy of HaiShaw et al at AMD. This was the only working recipe we could find on Day 0. Unfortunately, its performance was disappointing and native FP4+FP8 checkpointing didn’t work - this was likely due to the less mature ROCm ecosystem. However, as we will talk about later in the article, HaiShaw’s team eventually came through, doing an amazing job by improving performance by over 100x from Day 0 through Day 26 through some classic first principles driven engineering work.

Subscribe now

AMD ATOM Inference Engine Disappointment

ATOM did somewhat better on interactivity, but it still falls short for a concurrency of greater than 1. We used ATOM #650 during the early days of DeepSeek v4 hardcoded kv_cache[:1,...], and this meant that the KV cache was pinned to a single sequence slot. With only one slot available, a second concurrent request has nowhere to store its KV state. This was the case because the infrastructure that enables batching possible was not yet in place, so we could only run batch size of one user.

ATOM also ran with almost every hot path on a fallback: the FP4 MoE was forced onto Triton because AITER’s fused_moe was broken on GFX950, and the mHC pre-projection patched to Torch because AITER’s kernel crashed, forcing eager execution.

NVIDIA TensorRT-LLM Bugs and Lack of Day 0 DeepSeekV4 Pro Support

TensorRT did not support DeepSeek v4 out of the box because mhcFusedHcKernel.cu had a single hardcoded FHC_HIDDEN = 4096 constant. This is a problem because SHAPE_K, residual/x TMA descriptors, and the MMA kernel template instantiations were all tied to that hidden size. All previous DeepSeek models and DeepSeek v4 flash have a hidden size of 4096, so this worked for the meantime. But attempting to run inference for DeepSeek v4 Pro resulted in a “mhcFusedHcLaunch: hidden_size=7168 not supported (only 4096)” guard error.

Nvidia engineers also encountered this guard error and instead of adding code to support DeepSeek v4 Pro’s 7168 hidden size, they simply removed the guard. To nobody’s surprise, the error then disappeared.

Because of this “fix”, there was a period of over a week where, unless the env var TRTLLM_MHC_ENABLE_FUSED_HC=0 was used, the kernel would compile exclusively for 4096, with nothing rejecting a 7,168 call. Using default settings (fused HC on by default; B300 = SM10x → MMA path), a stock trtllm-serve of DeepSeek v4 Pro feeds 7,168 tensors into the 4,096-wired kernel. Running inference with these settings results in an inference run without triggering an immediate crash, but there are hidden consequences: the engine ends up corrupting hidden states and producing invalid generations. This was fixed in a PR authored by us, and it was surprising that such a simple problem took a week to be noticed and that it took another few days for the PR to be approved.

In the time it took to diagnose the issue and narrow the problem down to the fused HC hidden size mismatch, we had already reached Day 9 post DeekSeep v4 Pro launch. This episode is a good case study that proves the strength of the open native SGLang and native vLLM engine ecosystems. Thanks to these robust ecosystems, Day 0 support will always come to native SGLang and native vLLM first before it comes to TensorRT-LLM or AMD’s ATOM engine (ATOM, by the way, currently has zero production customers).

In the graphs below, we can see how as of today, TRT-LLM’s performance is superior at higher batch sizes, but it tends to fall behind at higher interactivity levels.

Section 1.5: Performance Over Time

As mentioned earlier in the article, we capture a snapshot of Day 0 performance across the inference engines and recipes as it acts as the baseline against which improvements in performance can be measured over time. With this baseline performance - we are able to measure and present the following data analyzing performance improvements over time.

DeepSeek v4 Pro on MI355X - 100x Improvement in less than 1 Month

On Day 0, DeepSeek v4 Pro was technically working on the MI355X, but it was clearly not deployable into any production workflow. However, the improvement since then have been phenomenal - with the AMD team led by HaiShaw delivering an over 100x improvement in throughput in less than a month post DeepSeek v4 release.

The chart above shows how the throughput pareto-optimal frontier climbed when comparing results from the FP8 build on Day 0 released on 25th April to results from the FP4 build released on the 27th of May. The gain came almost entirely from AMD replacing PyTorch-native fallback paths with real AITER, Triton, TileLang, and FlyDSL kernels.

There are two steps that drive the lion’s share of the gains. The largest percentage improvement actually came from the first commit after the baseline Day 0 submission - the team managed to mop up a ton of low hanging fruit and significantly the first iteration from the FP8 baseline. The next largest improvement came a few days later as the AMD team finally got FP4 weight MoE working, allowing us to switch MoE experts from FP8 to native FP4 (MXFP4), improving expert-weight bandwidth. This also moved FlashMLA and the sparse-attention indexer off the torch fallback onto TileLang kernels and enabled HIP graphs.

The next big improvement we saw came from the introduction of AITER mHC kernels, which are used at every layer. This improvement boosted performance such that we were able to see MI355X exceed H200 performance for DeepSeek v4 Pro at lower interactivity levels for the first time.

Before the windowed-attention kernel can run, it needs to know which KV-cache slots each query’s window covers. This is done by SWA-prepare, and its implementation in Triton also helped with the improvement.

The next big jump came on May 19th as the team retired the remaining fallbacks: FlashMLA moved from TileLang to Triton, and as the AITER FlyDSL FP4 MoE kernel landed. The team also enabled fused hash-topk, DSv4 radix attention, fused store-cache, fused WQA/WKV projection, and fused paged-compress, further boosting performance. The concurrency sweep was also increased to 1024, drawing the high-throughput, low-interactivity end of the frontier that did not exist before.

ATOM also improved drastically, expanding from a single conc=1 point to delivering decent throughput along the whole pareto frontier, with some points beating H200. The first gain came from AITER fix #2916, which corrected the device-allocation bug behind the mHC crash and let ATOM restore that AITER kernel. Next, FP4 experts moved onto AITER’s fused MoE kernel (Triton override removed), the sparse-attention OOM was cleared so eager mode and the single-sequence caps could be dropped. Batching support was also implemented, expanding the sweep from conc=1 to conc 1–512 with much better performance.

MI355X MTP

By Week 4, MTP was working for AMD on all frameworks, delivering multiple-fold is-interactivity throughput improvement. One consistent characteristic we noticed however, is that MTP tends to deliver worse results at higher throughput. This is because MTP exploits the compute slack in memory-bound decode, so compute-bound large batch size decode jobs have an MTP cost that outweighs the benefit that draft tokens would provide.

B300

For B300 on SGLang, DeepGEMM MegaMoE, our results showed a 3x improvement over less than a week thanks to the use of a grouped FP4 MoE GEMM that keeps experts resident and does one mega-dispatch instead of per-expert kernels, as well as from tuning to use EP4 instead of EP8.

B200

Performance for the B200 was relatively similar to that of the B300, with TRT being superior at lower interactivity for the B200. But TRTLLM does not work out of the box, compared to CUDA vLLM & SGLang vLLM which works out of the box.

GB300 NVL72

The most dramatic improvements for GB300 SGLang MTP came on June 2nd from the implementation of W4A4 (MXFP4) MegaMoE. Compared to the non-MTP implementation that was in use on May 7th, the main improvements in the June 2nd version came entirely from a rewrite of the GB300 decode topology rather than touching kernels or precision. While the Day 0 recipe ran at most points with narrow EP=8 fed by one or two prefill workers and capped concurrency at 16,384; the May 20th run widened decode to EP=16, scaled prefill to four–twelve workers per decode worker, and pushed concurrency to 21,504.

Based on the graph and analysis above, we can see that, as expected for a larger world size inference system, Wide EP is the main lever for GB300’s excellent performance which is delivered by amortized weight loading across more GPUs. Read the InferenceX V2 article to find out more about Wide EP.

These results for GB300 were only possible due to CoreWeave’s support.

B200 Tokens Per Megawatt (MW) Improvements

For the B200 with the vLLM engine, token throughput per all-in provisioned utility megawatt reached 300,000 tokens per second per MW for 50 tok/s/user interactivity on Day 0, improving to nearly 500,000 tokens per second per MW by June 5th.

Tokens per all-in provisioned-utility MW is the best figure of merit for considering return on investment at the fleet scale: It adds more information to raw per-GPU token throughput because it reflects PUE and datacenter overhead. Because a B200's all-in utility power envelope is fixed near 2.17 kW/GPU, that ~1.7x jump from ~300k to ~500k tok/s/MW reflects a pure software gain.

The same class of optimizations that pushed the throughput frontier (MegaMoE grouped-FP4 GEMMs, wider EP, the FP4 weight path, scheduler tuning) drop straight through to power efficiency because the all-in utility power in MW is unchanged.

Many organizations approach inference fleets from a perspective of maximizing a scare quantity of utility power. The question is how one can convert provisioned MW into as many billed tokens as possible at a given utilization and price. This analysis is best informed by metrics like revenue per MW, tokens per all-in utility power, capex per MW among others. This is a business case that our Tokenomics model is built to address.

Current Performance As of June 6, 2026

Let’s round out this section on performance improvements by quickly reviewing the best performance across systems and inference engines. When using SGLang, the GB300 continues to dominates and mogs all other inference systems, demonstrating the advantage of the GB300 NVL72’s rack-scale world size.

When we switch on MTP, serving with the GB300 is unbeatable across all interactivity levels we analyzed. The cost per million output tokens for the GB300 reaches $0.156 at 50 tok/s/user assuming 8k tokens input, 1k tokens output. Find out more about how we calculate Total Cost of Ownership (TCO) in our TCO model.

The rack-scale advantage is fundamentally a scale-up domain story. NVL72 puts 72 GPUs in a single NVLink domain, which lets the serving stack run expert parallelism wide enough to keep DeepSeek V4's MoE dispatch/combine all-to-all entirely on NVLink instead of spilling onto the slower scale-out fabric, all while amortizing expert-weight loads across far more ranks.

B200 and B300 in 8-GPU NVLink islands scaled out over InfiniBand hits that wall much earlier, and the MI355X sits further back on both scale-up domain size and collective-stack maturity. Turning these per-rack throughput wins into deployed serving capacity is a separate question that comes down to how many of each SKU are actually online: shipments and ASPs by SKU, plus installed base and effective FLOPS by customer, quarter by quarter, which we track in our Accelerator & HBM model.

ROCm vLLM DeepSeek v4 Pro Disappointment

When it comes to ROCm, progress has been much slower for native vLLM vs native SGLang. Performance of ROCm vLLM is lagging far behind its CUDA vLLM counterpart. Part of the issue is that AMD is re-focusing on ATOM (an inference engine that serves 0 production tokens) instead of focusing on native vLLM (an inference engine that lots of their major customers uses). We will talk more about in our upcoming State of AMD 2026 article (covering the good, the bad, and the ugly when it comes to AMD inference). One of the positive developments we will be covering is that the functional enablement of distributed inferencing on open source out of the box upstream AMD vLLM has finally happened for non-DeepSeekv4 models. It took many months to get there, and there is still much ground for the AMD vLLM team to cover.

What’s next for DeepSeek v4

vLLM

vLLM’s plan is tracked in the DeepSeek V4 roadmap issue (#40902), with landed code in implementation PR #40860 and a description of benchmarking against SemiAnalysis’s InferenceX dashboard. The FP4 Indexer and initial MegaMoE support has already been implemented, and Hopper is now supported. The remaining work for vLLM for DeepSeek v4 spans five areas:

• Core model support: continued MegaMoE work (PR #40833) and NVFP4 support.

• Runtime and parallelism: Model Runner V2 integration, MTP optimizations, prefill/decode (PD) optimizations, and pipeline parallelism support.

• Kernel integration: a paged prefill kernel, a fast top-k kernel, more horizontal fusion, DeepEP V2, and integration with DeepSeek’s own TileKernels.

• KV cache: KV cache offloading, covering PD + CPU offloading (PR #39654) and distributed KV offloading.

• Hardware support: beyond the completed Hopper support, SM120 and AMD support remains as key to-do items.

The focal themes here are on the surrounding systems: a new model runner, pipeline parallelism, KV offloading, and wider hardware coverage.

Upcoming updates to InferenceX, SemiAnalysis’s open source & public’s EcosystemX dashboard will visualize the software evolution & CI coverage & queue times across all major ML open libraries across all major AI chips: NVIDIA, AMD, TPU, Trainium, Huawei, and more.

SGLang

SGLang’s plan lives in performance optimization tracker (#23666) that Nvidia structured around DeepSeek v4’s network diagram, walking it block by block; some items may already be partially covered by the initial support PR (#23600), and community contributions are welcomed.

There are three high-level goals reflected here: CUDA graph support for decode, piecewise CUDA graph support for prefill, and no at-runtime weight processing. In addition, weight prep should happen once rather than per step. Within these three high level goals, the checklist is grouped by V4’s components:

• mHC:trying TF32/BF16 for the fc_hc_fn GEMM (which has a small N dimension and may need a special kernel), a 1/RMS + multiply fusion, single-kernel hc_split_sinkhorn and hc_post, and fusing MulSum + RMSNorm (+ FP8/MXFP8 quant) in the attention and MoE blocks.

• HCA (with Compressor): horizontal fusion of fc_qa + fc_kv into one FP8 GEMM, q-norm/k-norm and RMSNorm+RoPE fusions, a non-sparse MQA path that drops topk_idx, MQA reading directly from the compressed and SWA KV-caches with no copy/concat, single-kernel InvRoPE, a fused Compressor state update (kv-update + ape-Add + score-update), and making HCA, especially the Compressor, CUDA-graph-compatible for decode.

• CSA (Indexer + Compressor): similar direct cache reads for the sparse path, optional (P1) fusions of fc_compressor + fc_idx_compressor and fc_qb + fc_idx_qb, a (RoPE +) Hadamard + MXFP4-quant fusion, an efficient MXFP4 BMM+ReLU kernel (potentially fused with MulSum and even Top-1024), and CUDA-graph compatibility for the Indexer and Compressor.

• MoE: checking TF32/BF16 for the router GEMM, collapsing the routing path (softplus + sqrt + bias-add + Top-6 + gather + norm + multiply) into as few kernels as possible, fusing block-wise FP8 and MXFP8 activation quant, ensuring both shared-expert and routed-expert FC13 are single kernels, and auditing the tiny sorting kernels before the routed experts.

SGLang’s focus is replacing chains of small ops with single fused kernels, making the new attention variants read caches in place, and pulling the decode path fully into CUDA graphs.

Section 2: Huawei 950DT Day 0 DeepSeek v4 Analysis

DeepSeek v4 was the first major open model with first class Day 0 support on the Huawei Ascend, and indeed, part of the DeepSeek official API has been served on Huawei since Day 0. We have Huawei performance numbers on DeepSeek v4 and plan to release a follow up article deep diving into an apples to apples comparison of inference on Huawei vs on the H200 and B200, measuring comparative performance using the same benchmark harness.

Our upcoming public open source SemiAnalysis EcosystemX dashboard will visualize the software evolution and CI coverage across all major ML open libraries, for all major AI chips, including the Ascend stack.

CANN

CANN (Compute Architecture for Neural Networks) is Huawei’s software toolkit for running AI workloads on its own Ascend chips. Starting August 2025, they’ve open-sourced CANN to attract more developers and to “chip” away at Nvidia’s dominance, especially within China given that the US government heavily restricts CUDA chip shipments into China.

On Day 0, CANN released an optimization guide and benchmark figures for Ascend chips. Through it, we can see Huawei’s CANN strategy: To make Ascend competitive through full-stack inference optimization that is aimed at Chinese domestic model releases. Huawei is trying to show the Chinese ecosystem that if DeepSeek releases a new architecture, CANN can ship the kernels, graph path, quantization, serving integration, and deployment recipe.

One interesting methodology of the CANN team that we observed while benchmarking MTP and can’t help but mention was how they dealt with MTP draft token AR(acceptance rate) or AL(acceptance length). Benchmarking MTP is not trivial as the AR/AL of the benchmark may differ from the user’s use case. For example, a benchmark may on average accept two draft token out of three but with deployed use cases being extremely varied, it may end up may only accepting 1.5 tokens out of three on average.

This means that the user may see lower performance compared to the benchmark, and thus wrongly conclude their setup is flawed. We addressed this in our InferenceX v2 article by comparing ARs with MTBench. Future iterations of our benchmark will comprehensively address this gap by using real traces.

To address this quirk, Huawei instead times the full decode step to coincide with the last MTP module, thus recording time per decode step instead of time per token. The final benchmark result published then requires the user to multiply by their usecase’s MTP AL to derive comparable performance metrics, which is a very elegant way to compare performance.

Hey NVIDIA Goliath, There’s a New David in Town - The Ascend 950

Huawei’s internal codename for Ascend 950 chips is “David”, and this codename is referenced multiple times in the CANN codebase. No doubt it is because they believe they are the David to Nvidia’s Goliath.

The SIMT/SIMD 950 chips come in two flavors: 950PR, and 950DT. PR stands for Prefill and Recommendation and are lower cost chips with better cost-performance. DT stands for Decode and Training, and this variant features higher memory bandwidth and higher performance. Both are based on the same Ascend 950 Die, which uses a dual-die UMA architecture, but they are each packaged with different memory. The Huawei roadmap estimates and volumes per quarter of each Huawei chip is available in the SemiAnalysis Accelerator model.

Two major components of the chip architecture that are important to discuss are the AIC(AI Cube) and AIV(AI Vector). AIC is the matrix/tensor core side of Ascend’s AI Core. It is used for dense matrix math: GEMM, matmul, convolution-like tensor ops, attention projections, FFN linear layers, etc. Huawei documentation describes AIC as the matrix-compute core in split AI Core architectures. AIV is the vector core side. It handles elementwise/vector work: activation functions, normalization pieces, masking, reductions, type conversion, layout transforms, post-processing around matmuls, etc.

This is similar to TPU’s MXU. However, Ascend exposes the split between the two functions more directly as separated independent cores, with each able to load its own code segment, and also feature a “dual-master mode,” where AIC and AIV independently run code rather than having the AIV driving the AIC through messages.

The AI CPU is a device-side ARM64 execution unit with direct access to device memory. It is used as a complement to AI Core for the work that maps poorly onto the SIMD/SIMT cores: branch-heavy control flow, scalar logic, dynamic-shape handling, and the value-dependent scheduling/tiling metadata that kernels need before they run. Because the AI CPU lives on the device, Ascend can keep this irregular control-style work local instead of round-tripping work to the host CPU, which is a primary source of latency and pipeline bubbles. The AI CPU is also the unit that historically sat on the older AICore → AICPU → SDMA path for communication orchestration, before the dedicated CCU offloaded that work.

Like the TPU and Trainium, Ascend 950 adds a dedicated CCU communication engine. This engine sits alongside the compute die and handles collective-communication work without consuming AI Core compute capacity by supporting remote-read + reduce + local-write, and local-read + remote-write. The benefit is in lower communication latency, less HBM traffic, fewer user-buffer copies, and freeing compute cores from comm orchestration, avoiding the older AICore -> AICPU -> SDMA path.

Huawei DeepSeekV4 Pro 950DT Profile

The above shows a three step profile of DeepSeek flash v4 on Ascend 950DT, running using a config with a 16-rank DP/EP deployment. It shows 16-rank collective participation plus active MoE dispatch/combine traffic.

As is now standard across most stacks, CANN also uses independent compute and communication operators that can run on multiple streams - performance improves by controlling Cube and Vector core allocation to avoid resource contention. Operations like Prolog, Compressor, and LightningIndexer can be overlapped, C4A Compressor can be completely hidden, and shared expert computation can be hidden under routed expert execution without degrading routed expert performance.

Zooming in into a given decode step, we can see how different components are split into streams. Operations on different streams may run concurrently when the device has free, suitable resources. Models use multiple streams because a layer may not be a single serial chain, and instead can contain branches that only need to synchronize when their results are combined, for instance a shared-expert compute overlapping 100% with routed-expert compute.

Streams 145-148 in the above diagram correspond to metadata streams. These operators fire once per decode pass and precompute value-dependent scheduler/tiling metadata that later kernels reuse. They are the only AI CPU ops in the decode step, the make up a tiny fraction of total time, and are fully overlapped with AI Core compute. The impact is likely larger on longer-context benchmarks, where there is more sequence-length and mask-dependent partitioning to resolve up front.

In DeepSeek v4, Huawei moves the value-dependent scheduler stage for sparse attention and the LightningIndexer onto the AI CPU rather than bouncing it back to the host. These metadata ops build reusable per-core partitioning tensors from runtime sequence-length, mask, and paged-KV information; SparseAttnSharedkv and QuantLightningIndexer then consume them to decide which Batch/Head/Q-block/K-block work each cube core handles, along with the corresponding vector-core reduction tasks. Conceptually, this mirrors FlashInfer’s planning phase on host for paged attention: a cheap, dynamic-shape-aware setup step that runs once and is thus amortized over layers, with the only caveat being that Huawei pushes that same planning work onto the on-device AI CPU instead of the host.

Stream 152 in the daigram above contains the LM head, the last layer, and the second last layer’s o_proj and MoE. This is a decision of the npugraph_ex graph compiler, likely to allow the npugraph_ex runtime to consider the main graph “complete” on stream 144 while the tail work continues asynchronously.

CANN also introduced MC² (merged compute-communication) back in 2024. This is a class of fused operators that are not ordinary kernels nor HCCL collectives. They embed communication and compute into one kernel. In DeepSeek v4 decode, we can see MoeDistributeDispatchV2 and MoeDistributeCombineV2 MC² EP operators being used.

The main takeaway here is that Ascend delivers working, optimized inference infrastructure for DeepSeek v4 on Day 0. The Huawei CANN stack is one of only two stacks with Day 0 Support for DeepSeekV4, the other being Nvidia’s CUDA. As we explained earlier in the article, AMD’s stack unfortunately did not work well on Day 0. This is in stark contrast to last year when DeepSeek v3/R1 released. Back then, only one stack worked on Day 0: the Nvidia CUDA stack.

The biblical story that gave the Ascend 950 its internal codename ends with the giant face-down. But the Goliath in that story stood still and let David sling stones at him, whereas Nvidia’s Goliath is constantly in motion, ships a new architecture every year and improves existing architectures. Huawei has proven it can sling a stone on Day 0; whether it can fell a moving giant is yet to be seen.

DeepSeek V4 Architecture Deep Dive and Co-Design

Inference Optimizations for 1M Context Length

DeepSeek v4 features Compressed Sparse Attention (CSA) and Heavily Compressed Attention (HCA), walking away from Multi-head Latent Attention (MLA). The design is heavily motivated by KV cache size reduction.

In essence, HCA’s KV cache consists of a sliding window of the KV embeddings and a set of compressed KV entries, where each entry compresses key / value into one and across m′ tokens (m′ = 128 for DeepSeek V4 Pro).

CSA uses the same KV cache compression technique as HCA, but with a lower compression rate (m=4). CSA also applies sparse attention on the compressed KV entries by using a lightning indexer to select tokens to attend to. The sparse attention inherits DeepSeek Sparse Attention in DeepSeek v3.2.

By interleaving CSA and HCA, DeepSeek v4 aggressively compressed KV cache size, resulting in 50x KV cache reduction at 1M context length.

However, the novelty of CSA and HCA creates KV cache management challenges for serving frameworks. For example, vLLM’s KV cache memory allocator implements complex strategies to ensure efficient memory loading patterns and support serving features like prefix caching. This includes setting a logical block size that divides the KV compression rates of both CSA and HCA, and a page size bucketing strategy to avoid memory fragmentation due to storing the KV cache, compressor states, indexer KV, each having a different size per entry.

Determinism

To ensure RL training stability, DeepSeek went all in on making computation deterministic. This effort shows when looking into GPU kernels and their rollout infrastructure. DeepSeek wrote custom kernels for all operations to achieve batch invariance by enforcing a specific reduction order regardless of batch size. This includes batch-invariant split KV attention forward, GEMMs, and MoE backward kernels. Batch-invariant kernels come at a performance loss because using them prohibits many popular algorithmic techniques that don’t guarantee deterministic reduction order. DeepSeek mitigates the performance loss by writing kernels that are tailored for their workload, for instance specializing kernels for matrix shapes. On the rollout infrastructure side, DeepSeek focused on fault tolerance to make all rollouts reproducible. DeepSeek built a token-granular write-ahead log for each generation request, so any request preempted during either prefill or decode can be resumed without recomputation.

MegaMoE

The DeepSeek V4 release also included a new fused MoE kernel that achieves better overlap of all of the operations in the MoE layer. MoE with expert parallelism consists first of a token dispatch all-to-all followed by Linear1, Activation, Linear 2, and finally a token combine all-to-all. Linear 1 and Linear 2 are grouped GEMM operations where each expert in a given rank has its weights applied to its routed tokens. The authors mention in the DeepSeek V4 paper that other implementations overlap/interleave the token dispatch with Linear 1 and the Combine with Linear 2, but there is still a sync across all experts at the operation boundaries, between Linear 1, Activation, and Linear 2. MegaMoE instead splits experts into waves and schedules each wave separately, allowing for finer-grained overlapping of each of the operations and resulting in more of the communication latency being hidden. This is reminiscent of compute-comms fusions such as distributed GEMM, where a compute kernel and a dependent communication kernel are overlapped by breaking the workload into smaller pieces and pipelining to hide communication latency.

The paper claims a theoretical speedup of 1.92x over the naive kernel in the DeepSeek v4 Flash configuration, which means that the naive kernel must spend close to 50% of its time on Dispatch and Combine communication!

Now that we have discussed performance benchmarks in detail, let’s discuss total cost of ownership and cost per token when running DeepSeek v4 on H200 and the GB200 NVL72.

Read more

Tesla first unveiled a humanoid in 2022, and while it and other Western players are now producing early humanoids that remain works in progress, we hear Unitree may ship its 10,000th in the coming weeks.

Now, Unitree is tripling revenues YoY on 60% gross margin product lines, planning almost $300M of AI R&D spend, increasingly in-housing portions of manufacturing, all while pricing the cheapest humanoids on the market by far. With their upcoming highly anticipated IPO, Unitree is deservedly dominating the humanoids conversation. But historically, Unitree’s humanoid robots have a reputation for less than perfect reliability, are not viewed as useful beyond entertainment and R&D, and have a reputation for being “cheap.”

Despite this, we believe Unitree's cost structure is one of its greatest advantages over competitors. Unitree has slashed pre-tax pricing from $50K+ to $27.3K over the past 12-18 months. Even at that price, we estimate they still hit 67% gross margins on their flagship G1. With their BoM set to plummet as manufacturing scales, we've already heard pricing well under $20K in some deals.

We developed these BoMs by going through a full design examination of Unitree’s robot, speaking with manufacturers of every component, and verifying items with multiple supply chain buyers/sellers.

And, lastly, despite countless dismissive comments against the company, we argue their G1 humanoids are crossing the viability threshold of real-world deployments.

However, no one understands Unitree’s strategy, cost, and manufacturing as well as concerns of the usefulness of the robots at all. But today we are here to set the record straight. In our research we present the history of Unitree mimicking the BYD and DJI strategy, by generating their own ecosystem, spawning new markets, and then eating said markets. This strategy is in process as we speak. New markets on the horizon means that Unitree’s explosive growth should continue.

Next we examine their specific hardware strategy, and how their QDD actuator design choice led to a potentially structural advantage, and how their actuator has improved into near-deployment grade.

Lastly we argue that Unitree’s improvement and cost advantage is now breaking into the world of economic viability to displace labor. There are likely over 250 Unitrees deployed in labor settings today, and we detail how the deployment math works out. Notably, Unitree has made it this far on the back of the small hobbyist/researcher market. Should Unitree unlock viable deployments and hit critical mass, they may accelerate at unreal speed.

All of this comes at a level of scale and manufacturing that crushes the West’s cost and lead time, and Unitree itself is a standout in the competitive Chinese ecosystem. Behind the paywall we specifically discuss the new robot handmakers that are aiming to unlock more tasks and markets, as well as who will be eaten and who will benefit from the Unitree supply chain.

Unitree’s IPO is the birth of the robotics moment. They are unlocking markets, ecosystems, and are pursuing a strategy of scale that may lead down the path of other Chinese hardware juggernauts. Let’s first turn to the past to understand how Unitree could potentially work out.

The Making of A Chinese Hardware Giant

What does a fully-matured Chinese hardware giant look like in practice? There’s a great example of the carmaker BYD (Build Your Dream) today as the mature expression of Unitree’s strategy: own the most expensive and challenging component in the BoM, use this ownership to compound cost advantage that nobody can match, and create new markets while adding more value from inhousing your supply chain.

BYD initially focused on the battery cell. Batteries can consume around 30-40% of an EV’s BoM (now less, thanks to BYD). BYD was founded in 1994 to make battery cells that Japanese incumbents exited due to toxicity. BYD spent nearly a decade refining their product before entering EVs in 2011, and at first was only a niche player. When BYD launched its first battery-only EV, the e6, to the Chinese market in October 2011, annual EV sales across all of China were just 8,159, or 0.04% of new car sales. There was no EV market, but BYD helped create one.

BYD’s strategy was key.

Owning the cell at increasing automotive volumes passes through demand, creating improved supply and ecosystem, where players like Hunan Yuneng and Shenzhen Dynanonic (LFP cathodes), Inovance (motors and inverters), and Sanhua (thermal management) emerged to supply BYD’s next-generation, improved parts at a lower cost. None of these existed at a meaningful scale in 2010.

BYD has freedom to in-house manufacturing where it compounds for them. They took in house the battery cell, drives, motors, IGBTs and SiC power modules (one of the only companies in the world running an IDM model), the transmission, the chassis and outer body shells, and even the engine itself. By the late 2010s, nearly every component of an EV was being built under BYD’s roof.

This creates a positive feedback loop: owning and improving the right hardware lets BYD create a new product that opens a new market, like their 2020 Blade Battery. Pre-Blade, the battery chemistry (LFP, Lithium Iron Phosphate) was cheap, safe, but low-density, fine for vehicles that never traveled far from a charger, like forklifts that charged during operator breaks or buses that returned to depot every night. However, passenger EVs, which had to handle road trips and unpredictable home charging, saw LFP as unviable.

In 2021, their Blade Battery took a new packaging geometry, pushing battery pack space utilization per kg up 50%. Now, LFPs could remain the same size, while improving distance to a viable threshold. Tesla shifted the Model 3 and Y to an LFP battery, Ford licensed CATL’s LFP technology, and overnight, through meticulous hardware iteration, BYD created the modern affordable EV market to dominate.

Before the Blade Battery, BYD shipped 189K new EVs in 2020. After the Blade Battery in 2021, BYD shipped 600K new EVs, and by 2025, not only did BYD become the #1 EV producer, but they overtook Tesla as the #1 BEV producer (battery only), Tesla’s main product. BYD has now inhoused such a significant portion of its process (75% for the Seal), that their cost-structure is almost untouchable, like the 2023 Seagull model for ~$11,000 (newer models are under $8k in China!) BYD even owns supply chains further upstream with moves like a 2023 refining Joint Venture with Huayou Cobalt and acquiring direct lithium mining rights in Brazil’s “Lithium Valley.”

This scaling outcompeted European EVs so much that VW announced its first-ever German plant closures and Stellantis cut guidance, all citing Chinese EV pressure. Even the United States had to increase its tariffs on Chinese EVs to 100% to protect its domestic industry. Now, BYD has scaled so much they even own their own freight to ship their cheapest, and best EVs in the world.

The DJI Playbook - Niche Researcher/Hobbyist Markets Are Viable Bootstraps

DJI pioneered a playbook different from BYD, and Unitree is running that playbook today, starting with the researcher/hobbyist beachhead, and a low-quality product.

In 2013, “useful consumer drone” wasn’t a category. Parrot’s AR.Drone, the leading product, won its 2010 CES award in the Electronic Gaming Hardware bracket and shipped alongside augmented-reality dogfighting games. The drone had no camera stabilization, no GPS, and only took 640x480p pics/videos. Anyone who actually wanted a useful flying camera had two options: pay $19,995 for a Draganflyer X6, or stitch together frames, motors, flight controllers, and gimbals (stabilizers) from disparate vendors for up to $1,200 in parts, plus dozens of hours of assembly and PID (controller) tuning, usually ending in expensive crashes.

Researchers, hobbyists, and early professional camera workers were a willing market for something new. DJI’s Phantom 1 shipped January 2013 at $679, and was not a fully-fledged product at the time. It had no built-in camera, no gimbal (stabilizer), ten minutes of flight, no live video feed, but it was roughly half the cost of the build-it-yourself drone, with none of the assembly burden. A far cry from DJI’s drones today, but DJI went from $4M in revenue in 2011 to $130M in 2013, after the Phantom 1’s release. This was more than enough to kickstart DJI’s flywheel.

DJI then reaped the fruits of the Shenzhen consumer electronics ecosystem, now huge from the Smartphone boom. GPS prices went from $800 to below $14 from 2003-2013, controllers went from $2,000 to $400 from 2006-2011, and more. From DJI’s boom, there are now over 3,000 drone component suppliers for most anything you desire.

DJI chose to inhouse the most expensive and technically difficult component first: the flight controller. Third-party suppliers were still selling at $200-400 even in batches of thousands in 2014. Later on, DJI brought inhouse the gimbals, motors, and ESCs.

Like BYD, new DJI generations unlocked a new market the previous one couldn’t address. The 2013 Phantom 1 ($679, no camera, 10-minute flight, no live feed) was the bootstrap, engaging hobbyists/researchers. The Phantom 2 Vision+ in 2014 then came with a 3-axis gimbal (stabilizer) into the frame, where previously broadcast-stable aerial video had required a $2,000+ aftermarket gimbal mounted to a hand-built rig, operated by a skilled pilot.

Pre-Vision+, professional aerial photography was the domain of helicopters and Hollywood second-unit teams, but now, small businesses could perform this on their own. As such, whole new markets were unlocked for DJI, like real estate listings, wedding videos, local news, agricultural surveying. By the Phantom 4 in 2016 ($1,399, 4K camera, 28-minute flight, forward obstacle avoidance, 44 mph sport mode), the enterprise market was unlocked: surveying, inspection, first response, and more that we detailed here.

In 2016-17 DJI held roughly 70% global consumer drone share, and global drone shipments hit 6.4 million units and $1.9 billion in revenue, a market that hardly existed before. Multiple competent dronemakers were crushed. 3DR, GoPro’s Karma, and Parrot’s consumer line had all exited or were exiting the category. Chris Anderson, the 3DR CEO, estimated that DJI cut prices by as much as 70% in less than a year during the Phantom era.

For brevity, we’ll call this the “DJI Strategy” throughout the rest of this piece: own one critical component, bootstrap a willing audience, ride the ecosystem, and let each hardware generation unlock the next market. (An earlier version of this framing appeared in our first robotics paper.)

Unitree As An Early DJI

Unitree is a live DJI Strategy case study: own the bottleneck component, bootstrap a willing audience, ride and seed the ecosystem, unlock new markets generation by generation. So far, Unitree has

• Parlayed actuator scaling into quadrupeds, building the most cost-efficient legged platforms in the market.

• Scaled the quadruped program into researcher humanoids, with the G1 becoming the dominant research platform for a surprisingly large market.

• Funded hardware improvements enough to begin real-world deployments, with the threshold being crossed right now.

• Signaled promising improvement on their next generations to compete on performance with Western humanoids.

Let’s walk through the history, design, strategy, and the critical threshold they are crossing right now humanoid deployments.

In 2016, Wang Xingxing, a former employee at DJI, developed a low-cost quadruped robot called XDog for his master's thesis. He iterated upon the same quadruped in his new company named “Unitree.” For Unitree, their core component of choice was the actuator, the integrated joint that moves the robot’s limbs. Like BYD and their cells, DJI and their flight controller, Unitree chose the expensive actuator (50%-70% of the humanoid BoM) to improve and scale out from.

Unitree started with the academic robotics community as merely a quadruped company. Just as DJI had hobbyists paying out the nose for half-finished drones, Unitree saw university labs looking for a legged platform that didn’t cost $70-100K+. The Laikago shipped in 2018 at $45,000. The A1 followed in 2020 at $15,000; the Go1 in 2021 started at $2,700 for the Air trim and ran up to $8,500 for the Edu; the Go2 today starts between $1,600 and $2,800 depending on trim and region.

A 94-96% price decline in entry-level quadrupeds over six years pushed Unitree from academia into consumers and now even industry deployments -- with the broader AI wave lifting the hardware’s capabilities. More importantly, it gave Unitree years of real volume on the same systems for a humanoid: actuators, controls, suppliers, and production process. When Unitree released the H1 in 2024 at roughly $90K, the humanoid was less a brand-new product, but rather the direct result of their quadruped scaling curve. We’ve heard from people close to Unitree that the H1 was essentially a quadruped standing on two legs - note the bent knees and awkward walk. The H1 showed how far quadruped-era IP could be pushed into humanoids, but the following G1 changed Unitree’s world.

The $30-50K G1 - A New Possibility In 2024

In mid-2024, affordable, off-the-shelf humanoids were few and far between until Unitree came along. Agility’s Digit was just beginning to deploy a handful of robots into factories. Apptronik’s Apollo, unveiled August 2023, was pre-commercial. Figure’s initial commercial agreement with BMW, signed January 2024, was shipping in single-digit volumes. Tesla wasn’t (and as of V3, still isn’t) shipping Optimus externally at all. On the Chinese side, UBTech’s Walker, Fourier, and the early signs of AGIBot existed, but not as cheap nor at volume. No one could just “buy” a humanoid.

The G1 enabled an incredible academia sized market. Ask any researcher and they will tell you how dramatic a step-change in accessibility it was using a $30-50K, ready-to-purchase bot. This share of the research community has since bled into top-tier AI research companies via hirings, like Nvidia, Apple, and Meta, all purchasing hundreds of G1 units. Unitree has become the leading platform for humanoid AI research.

The Ecosystem Advantage

Unitree inherits both the supplier base of DJI and BYD’s past. China assembled 31.3 million vehicles in 2024, 40.9% of them new-energy (BEV or PHEV), and the aforementioned 3,000 drone component suppliers had already scaled many of the BLDC motors, drives, encoders, batteries, and manufacturing processes that general robotics can reuse. However, Unitree’s gravity is exemplified by the rise of new humanoids+quadrupeds supply chains. Every province now has several manufacturers of rightly sized/spec’d gearboxes, high-torque BLDC motors, and more. Within China, there are now ~200 humanoid companies all reaping the benefits of and contributing to this ecosystem.

All of this stemmed from Unitree’s decision to perfect the actuator. However, the first generations of their actuator didn’t work very well.

In 2024, Their Humanoids Weren’t Good

For brevity, we’ll use QDD in this piece to mean the combination of a brushless DC motor and a low-ratio planetary gearbox, typically in the single digits and up to 20:1, which can still provide adequate backdrivability, but understand there are nomenclature debates.

Let’s be clear: DJI and BYD unlocked markets when the product worked, and the H1 and original G1 were not very capable upon shipping. Whenever users pushed them toward real work, the motors often overheated. The G1 could only hold a 2kg payload, like a 2-liter bottle of soda, with arms fully outstretched for a few seconds before mandatory cooldown. The same 2-3kg with arms bent or contracted for maybe 2-3 minutes, like the diagram below.

After that, the robot typically needed about 30 minutes to return to functionality, and likely a full hour before resuming a real work task. Five minutes of work followed by the rest of the hour cooling down is not a productive robot.

The issue primarily came from Unitree’s core actuator choice: the QDD, or quasi-direct-drive, which are simpler and cheaper than typical robotics actuators. Historically, companies favored high-precision, high-power actuators that could both move the robot and support its weight. Industrial arms often use HarmonicDrives. Boston Dynamics’ early humanoids and quadrupeds used bulky hydraulic actuators. Even today, many humanoid companies default to high-gear-ratio actuators, like strainwaves from HarmonicDrive.

Those architectures work, but they are expensive, hard to manufacture, and often difficult to maintain. In 2018, the MIT Mini Cheetah popularized the QDD (quasi-direct-drive): a cheaper, simpler alternative. The open question was whether QDDs could scale and prove reliable enough for real-world robotics. Unitree believed this to be a yes.

Subscribe now

Why The Issues Around QDD?

QDDs flip the historically common robot-joint setup. Instead of a small motor with a big gearbox, they use a beefier motor with a much smaller gearbox. If the robot wants to lift 5kg, there’s two options.

• Big gearbox, small motor. The gearbox works like low gears on a bike, trading speed for force and multiplying the motor’s twisting force (torque) by 30x, 100x, or even 200x in some cases. This is the “gear ratio,” like 30:1, 100:1, 200:1, etc (not a direct 1:1 mapping in most cases). This setup is how industrial arms swing whole car bodies around with modest motors: the gearbox does most of the heavy lifting.

• Small gearbox, big motor. QDDs go this route, with gear ratios typically under 20:1 using a basic, off-the-shelf planetary gearbox. Since the gearbox barely multiplies anything, the motor has to be way stronger. Lifting the car chassis from above would require a huge motor (our quadrupeds piece explores the QDD further).

While there’s bonuses to Unitree’s QDD, like easily adapting to opposing forces (like collisions), or invoking a rapid, dynamic range, it does come with tradeoffs. Because the motor carries more of the torque burden directly, rather than relying on the gearbox to amplify it, early critics argued Unitree’s motors would draw very high current, run hot, and prove too unreliable for practical work.

Two Years Later, The QDDs Are Defying Expectations

The early critique was fair, QDDs gave Unitree a cheaper, simpler actuator, but pushed too much thermal burden onto the motor, hence the aforementioned overheating. But while most stuck with the strainwave (HarmonicDrive) route, Unitree took the chance and iterated.

Over the last few years, Unitree appears to have improved the actuator in several ways, now showing promising signs of scalability, with many other (Chinese) humanoids switching to the QDD wave and, consequently, building up the ecosystem. We will aim to cover here of the improvements Unitree has displayed, but to clarify: we have not had access to cycle test numbers, this is simply our best approximation of evaluating their hardware improvements.

Let’s begin with the usual P=I^2R, or in this case, Heat roughly scales with I^2R. So you may do two things: lower the current (I) the motor needs to draw, or lower the resistance (R) of the windings the current flows through. Most focus on Current because it’s squared, but both contribute.

One major lever to reduce wasted current is to make the motor’s torque smoother through each rotation. In plain terms: pedaling a bike with a slightly wobbly wheel takes more energy than a true one. Each rotation, you fight a small surge of resistance, and you push harder on average to hold the same speed.

A motor with a rough magnetic pull has the same problem: the rotor jerks slightly with every revolution, and the extra current you draw to overcome that jerkiness turns directly into heat. Those hiccups come from effects like cogging torque, where the rotor magnets interact with the stator teeth, and from non-ideal magnetic-field shapes that create torque ripple. Less ripple means less vibration, less wasted current, and more usable torque before overheating.

To resolve this, we can reshape or curve the magnets and slots so the pull stays smooth between rotations. Additionally, we can also skew the magnets so the stator teeth take turns engaging the field rather than all snagging at once.

Another useful solution is to pack more copper wire into the motor. A thicker, more densely-packed wire carries the same current with less resistance, known by Unitree as their “Low Copper Consumption Coil.” Halodi, now known as 1X, famously tweaked their copper fill as well by using thick, square copper wire.

Cooling is still important for a functional robot, but Unitree’s architecture is fairly conservative on this front. We’ve found passive cooling across most of the body, with active air cooling only at the main control board and hip joint, and a vapor chamber heat spreader at the knee. Unitree has iterated here too, adding active cooling around the pelvis in an October 2025 update that improved thermal headroom for subsequent G1 batches.

We suspect Unitree not focusing much on its cooling can be attributed to wanting to reduce costs and manufacturing complexity while focusing on the core problem we mentioned earlier: lowering the amount of current its motors need.

So Why QDDs In The First Place? A Quick Detour On Speed+Cost

Unitree made a bet on the QDD, taking an unproven architecture (in deployments) on the most expensive component in the robot. While difficult to work with, they are still higher efficiency (95%-98% vs 85%-90% for strainwaves), and up to 80% cheaper. Importantly, low-ratio planetary gearboxes are also common industrial components, machined with standard gear hobbing (think grinding) on widely available equipment, enabling many suppliers to exist.

Meanwhile, competitors choosing strainwave gearboxes for example, like from HarmonicDrive or LeaderDrive, face a more complicated ~13-step process. Multi-hour heat treatment of the metal grains to allow “flexing,” (shown below) precision hobbing into micron-level tolerances, etc, all lead to a process that took HarmonicDrive decades to perfect, and LeaderDrive is still considered by many to be lagging HarmonicDrive’s reliability after 20+ years.

Instead of verticalizing an entire decades-long learning curve, Unitree chose the QDD. Now, a new QDD redesign can become a sample actuator within weeks for Unitree. For context, a custom motor and gearbox subsystem may take a Western humanoid company 3+ months due to so many supply chain handoffs. Weeks of spec iteration, 6-8 weeks for motor+gearbox samples, then validation and reorders. The result is both cheaper production, as shown in our BoM, and faster iteration, as seen in the active pelvis-cooling rollout that went largely unnoticed.

From Burnout To Lightweight Tasks

Now, Unitree has iterated and improved their G1’s and actuators enough that small, but legitimate, tasks are within arm’s reach. Arms bent, the G1 sustains upwards of 10-15 minutes of operations carrying 5 kg, a roughly 2x increase in payload and a 5x increase in duration over our original numbers! With arms fully outstretched, 5kg (roughly a bowling ball) can be held for ~1 minute before hitting thermal limits. Even for humans this is considered a workout. But how close are we to Unitree being a “viable” humanoid?

Heading Towards Useful Work

Unitree is obviously very cheap, and we know the strategy they are taking, and how their hardware is improving, but does it matter? Many might point to the previous section declaring that 15 minutes carrying 5kg doesn’t matter: perhaps “dexterity is lacking,” “it doesn’t have hands,” “that’s not very long,” etc. However, we estimate that Unitree may have shipped roughly up to 250 humanoids into productive industry pilots or deployments in 2025, aside from their research/hobbyist sales. We’ve even found one company with 30 G1s deployed today, and multiple companies with 5-6 G1s deployed. Granted, these deployments are likely software limited (e.g. AI model capabilities), leading to differing economics based on what solutions are used, like 100% teleoperation (which is what we assume in our calculations).

Unitrees do not need to run perfectly, nor for extended periods of time, nor do we expect them to. Rather, it is a question of what’s sufficient for useful work. The G1’s arms are still underpowered, they don’t have enough “degrees of freedom” for perfectly human-like movements, and they still overheat on overly strenuous jobs. But this only puts a ceiling on the types of tasks the G1 can do, not a floor on whether it can do anything at all.

Looking past performative backflips, Unitrees can already perform “useful work,” non-exhaustively defined here as either.

A task performed in a business to produce some economic output, like sorting boxes, or a task performed to relieve a physical burden of a human, like folding clothes.

So what are these Unitrees actually doing? Essentially, carrying boxes/items from A to B. Currently, it tends to be lightweight materials handling, like in e-commerce tote (bin) handling with <3-5 kg payloads, or moving even empty boxes/totes.

None of these are 24-hour, fully-autonomous production lines, and most are still teleoperated. Nonetheless, let’s demonstrate that moving boxes around is becoming economically viable.

Subscribe now

Unitrees Are Crossing The Deployment Viability Threshold

"Thanks to Adamo for helping us understand teleoperated deployments further!"

We’ve discussed humanoid economics in depth in our Levels of Autonomy paper, but here we perform a full calculation for Unitree. Taking Agility Robotics’ (fantastic) task as a baseline, and plugging in Unitree inputs, we find Unitrees are currently passing below the $30 per hour labor cost of a human.

No humanoid is at mass-scale production/deployments yet, all are still iterating on the technology, and these figures may change from deployment to deployment (grippers/hands, payload, throughput, etc). Instead, we will show our best estimate of what they’re capable of today and what that looks like on a specific task, but want to note: these are early-stage numbers, and if Unitree’s hardware continues its improvement trajectory, and Autonomy improves, the economics likely only improve from here.

A Lovely Task: Tote Handoff

In this particular job, Agility serves as a “bridge” between automation systems, for example, carrying totes (bins) off the AMRs to place onto conveyor belts. It’s a standard, but particular, logistics workload, where a human typically waits on automation systems to line up for the transfer, but leaving dead time in between. It’s why Agility’s 66 totes per hour (from a conference demo, likely higher in deployments) is perfectly fine.

Additionally, in Agility’s GXO deployment, the totes are 2-4kg (good for our aforementioned Unitrees). With light payloads, low-throughput, forgiving retries upon failure, and little dexterous manipulation, it’s a perfect task for the current Level of Autonomy.

Calculating Unitree’s Economic Viability

Agility currently operates using a 2:1 utilization model, two units of operating time for every one unit of charging, giving Digit a two-thirds utilization rate relative to a human.

Operators deploying Unitrees on similar 2-4 kg tote transfer work reported to us a throughput matching Digit on this task. However, Unitrees aren’t the most robust robots. A Unitree G1 typically runs a similar task for 10-15 minutes, while needing 5-10 to cool down, but still leaving a 50%-67% utilization rate. In our assumptions, we remain very conservative, assuming full teleoperation, 15% service contract (typically 5-10% in industrial scenes), a two-year useful life, zero residual value, and only two shifts. Even still, the robot proves viable today.

To get the caveats out of the way, we are not proposing Unitree as the full package. Many layers still need to be added. Agility, for example, has a great operating system to coordinate with the Warehouse Management System, a deeper functional safety approach, their own layer of autonomy, and much more. However for Unitree, even full teleoperation seems to be viable in the right business settings now.

Subscribe now

Where This Goes

To our knowledge, this is the first stage of Unitree’s humanoids exhibiting useful work in deployments. It’s not that this task is exceptional, or a $100T TAM, but it shows Unitree may be crossing a threshold, and their trajectory is quite remarkable. Recall that DJI shipped a half-perfect drone to niche hobbyists and 32x’d their revenue, quickly catapulting themselves into drone dominance. In the beginning, the G1 would overheat from holding a box for 2-3 minutes too. The performance improvements thus far were funded by hobbyists/researchers. If Unitree unlocks even a slice of the warehouse TAM, progress can accelerate at breakneck speed.

With signs of robotic AI models gaining new capabilities, BoMs falling, and the quality of hardware improving thus far, Unitree could become the cheapest, competent humanoid platform in the market. Let’s talk about how they got to their world-leading $8,976 BoM.

China’s Manufacturing Competence

Throughout the piece so far, we’ve hinted at Unitree’s manufacturing competence and the ecosystem surrounding them. For robotics, and many other industries, working with the Chinese ecosystem is necessary to compete on a global scale when: Suppliers are mere hours away by train, samples arrive the same/next day, vertical iteration cycles can run in weeks instead of quarters, and components can run 20-40% cheaper than Western equivalents. It should be noted that strainwave gearboxes from Leaderdrive, for instance, sometimes cost a third of HarmonicDrive’s -- granted HarmonicDrive currently remains the reliability leader.

Most American robotics startups are already working with Chinese supply chains, like Sunday Robotics, Dyna, and XDOF, who all run their hardware teams out of China. Even Tesla Optimus sources from the Chinese supply chain, and will likely continue to do so.

Unitree’s Verticalization Is Remarkable - Even In China

The Chinese ecosystem is amazing, but we’ve harped on how great verticalization is, so let’s expand on this. Unitree self-develops BLDC motors, planetary gearboxes, LiDARs, and depth cameras, each typically (or even previously for Unitree) outsourced by other Chinese humanoid OEMs. Instead, Unitree’s self-produced motors can run as low as 30-40% of equivalent Western motors, and they now make some of the cheapest humanoid gearboxes in the world.

These same benefits are very apparent in the IPO filing. In Unitree’s First Round Inquiry Response with the Shanghai Stock Exchange (SSE), they explicitly state that scaling production gave them upstream bargaining power, which created a lasting cost advantage.

This translated to margins on their quadruped robots improving from 42.36% to 55.49% while costs dropped nearly in half. However, SemiAnalysis subscribers knew these quadruped margins already back in September.

This verticalization is a spectacle in Western markets, but even within China, where razor thin hardware margins require verticalization for survival. BYD and DJI from earlier showed their path to dominance via verticalization. UBTECH and AGIBot (two of the main Chinese humanoid competitors) are actively moving to bring more of the hardware under control, like gearboxes, motors, etc -- components Unitree already self-develops.

Both UBTECH and AGIBot still lean on ODM/OEM partners for manufacturing and, in some cases, final assembly, like AGIBot outsourcing European production to Minth Group in Serbia. Even then, AGIBot is licensing full tech transfer at $4M, scaling through partnerships instead of owning the manufacturing learning curve. Meanwhile, Unitree states in their S-1 they plan to bring further development inhouse, including “tooth-profile design, simulation optimization, material validation, and high-precision machining.”

However, neither Unitree nor other humanoid companies are at high-volume production. This implies that even as they scale production, Unitree may likely maintain a structural cost advantage from a first-mover standpoint. A future piece will detail the Chinese industrial ecosystem in all its glory, but for now, assume most humanoids will source from China, and even in China, Unitree is exceptional.

Conclusion

While Western manufacturers were/are still prototyping humanoids, Unitree has profitably shipped tens of thousands of quadrupeds, built up an entire humanoid market, entered into useful humanoid work, but everyone should consider: where does this stop for Unitree? BYD began with just battery cells, DJI with just controllers, and are now titans of industry.

Watching how Unitree has accelerated success through multiple robot form factors, and increasingly solidified a manufacturing advantage, they may continue to expand at this same pace and unlock markets previously unthinkable.

For now, let’s discuss robotic hands and which of Unitree’s suppliers may benefit, all now beyond the paywall.

Read more

“Five years from now, my prediction is we will launch and be operating every year more AI in space than the cumulative total on Earth... I would expect to be at least, sort of five years from now, a few hundred gigawatts per year of AI in space and rising.”
- Elon Musk on Dwarkesh Podcast, February 2026

Furthering space-based compute was also one of the stated motivations behind the merger of xAI into SpaceX (as a ‘reorganization of entities under common control’), and is a key part of SpaceX’s plans to go public, as stated in their S-1 filing on 20 May 2026.

“Our goal over time is to launch 100 gigawatts of compute to space each year. If operated continuously, the generation resources used to support 100 gigawatts of compute could generate approximately one-fifth of the annual power production in the United States, which was 4.4 thousand terawatt hours in 2025… We expect space‑based compute to massively increase AI compute scale, while also improving token economics.”
- SpaceX, S-1 Filing, May 2026

As expected, many part-time prognosticators in the Substack-verse have emerged from the woodwork to weigh in on the concept. Some articles bring up insightful points, but there are more than a few that are built upon ideas that fly in the face of science.

A few casual arguments made in favor of space datacenters include the following:

1. Space can provide free solar energy 24 hours a day

2. Cooling is “free”. Some erroneously point to space being cold as a key positive

3. Communications latency in space is low as you’re just sending light through a vacuum

4. There is no need for permitting in space… so far…

Many of these points sound like they hold merit on the surface, but a deeper analysis of each apparent advantage reveals a far more complex story.

While we think that it is possible that space datacenters could scale one day, deploying orbital compute using today’s technology currently costs several times more than deploying terrestrial compute. Achieving Space-Earth cost parity will require significant engineering work, material science breakthroughs and cost scaling progresses and will still take years to achieve. There are also important reliability and servicing obstacles to overcome - for instance - how GPU servers will recover from faults that require human intervention, effectively shielding accelerators from radiation, among many others.

When we deploy compute in space, it won’t be because of the four superficial reasons we have cherry-picked above. Rather, Space-based datacenters make sense in the world where AI demand well exceeds all of the four layers of terrestrial datacenter supply that we will introduce below. For Space datacenters to step up to this call - it is a necessary condition that major space datacenter cost items like radiators, solar arrays and launch costs decline considerably, and that a number of key operational obstacles are overcome.

Users of our AI Space Datacenter TCO Model can see a first-principles, system-level framework for evaluating orbital compute economics, engineering constraints, and supply-demand dynamics across both terrestrial and space-based infrastructure.

The four layers of incremental power supply for terrestrial datacenters include:

1. Grid-connected supply,

2. Converted bitcoin miners and powered land,

3. Behind the meter generation, and finally,

4. Industrial capacity and manpower to build further power infrastructure.

A necessary condition for AI related IT equipment demand to reach levels exceeding terrestrial datacenter supply is for there to be enough chip fabrication capacity to fulfill this demand in the first place, before we even discuss datacenters! We wrote about this in great detail in our recent article on the Great AI Silicon Shortage, where we concluded that the industry has moved from a power-constrained to an accelerator-constrained regime. Available datacenter capacity and power now exceed AI compute demand, but TSMC’s N3 wafer capacity and HBM supply cannot keep pace with the pace of accelerator deployments. This means that today, and for the next few years, chip manufacturing will be the global constraint before we even worry about supply for these four layers.

The chip constraint forms a separate fifth layer of supply - Semiconductor Production, and it is a “universal” constraint on all chip deployment, whether deployed on Earth or in Space. Users of our AI Space Datacenter TCO Model can see how this constraint applies well into the future, and under what scenarios regarding chip manufacturing capacity addition that Semiconductor Production may not be the constraint.

Elon Musk is clearly well aware of this constraint, and it is the impetus behind his Terafab Initiative. The AI Space Datacenter TCO Model also includes knobs and sliders for users to tune to test out various Terafab scenarios.

Framing the Space Datacenter Debate

Our various industry models such as the Accelerator Model, the Foundry Industry Model and WFE Models illustrate the aforementioned chip tightness. Meanwhile our AI Datacenter Model forecasts accelerating incremental datacenter additions in 2027 and 2028. Thus, datacenter capacity addition will run ahead of chip constraints in the next few years until fab capacity additions accelerate to catch up. Our suite of industry models will only forecast such wafer fab and datacenter capacity additions once such plans are confirmed.

However, the world in which AI demand is so overwhelming as to exceed the already formidable datacenter capacity additions is a world with no time for half measures. As such, our AI Space Datacenter TCO Model base case departs from our industry models to reflect this world, assuming accelerating incremental datacenter capacity additions and a meaningful step up in the pace of chip fab capacity addition. It is a world where all the stops are pulled out and many obstacles from gas turbine availability to EUV tool production constraints are overcome because clear long-term AI end use ROI justifies enough capital investment to overcome them.

The below chart illustrates what this world could look like - with incremental datacenter capacity additions eventually in the hundreds of GW annually, though adding chip capacity will still be more difficult than adding datacenter capacity:

In such a base case, our model shows that the cost difference between space and terrestrial datacenters starts at more than 4x in 2026 before narrowing to parity in ~2040, with levelized costs of compute in space declining below terrestrial thereafter. By the early 2030s, space datacenters could be only ~30% more expensive than Earth-based datacenters, opening the door to the first scaled space datacenters as soon as the turn of the decade!

Space-Earth datacenter cost parity opens the door, but in our base case, there is still ample terrestrial capacity - so going into space is a matter of preference and optimization rather than necessity. But if regulatory and capacity bottlenecks starve terrestrial datacenter capacity - space becomes a necessity. This scenario is the basis for our model’s Elon Musk Scenario.

In the Elon Musk scenario, terrestrial datacenter incremental capacity addition peaks out in 2028 and remains low for decades while chip production expansion marches ahead. In this scenario, Space becomes the only alternative for scaled AI datacenter deployments.

In the Elon Musk scenario, the space datacenter TAM could easily reach high hundreds of GW of incremental capacity per year.

Our Total Cost of Ownership Framework is the foundation that allows calculation of levelized cost of compute and it powers the AI Space Datacenter TCO Model. In the rest of this introduction, we will briefly explain the TCO framework and key conclusions from our AI Space Datacenter analysis.

Analyzing Space vs Earth Datacenters using our Total Cost of Ownership (TCO) Framework

In a manner similar to our standard AI Cloud TCO model, we split out various cost categories for space and terrestrial deployments, namely IT cluster capital cost, datacenter capital cost (including launch costs), and operating cost.

Headline TCO Findings using Present Costs and Technology

A 30.5kW B300 cluster (16 GPUs across two servers) deployed in 2026 has a total program capital cost (IT cluster capital cost plus datacenter capital cost) of $4.1M for a space deployment and $1.4M for terrestrial deployments. We use B300s and contemporary mainstream GPU as references for TCO analysis for the next few years, but it is much more likely that smaller, efficient and specialized chips akin to Tesla’s FSD chips will actually be deployed.

Transformed into a levelized monthly ownership cost incorporating respective WACCs and useful lives and adding monthly operating costs, we see a total monthly cost of ownership of $100,925/month for space deployments vs $27,724/month for terrestrial deployments.

Space datacenters are more costly because of a larger upfront capital cost of deployment, with the largest driver being launch costs at $1.6M out of the total $3.1M datacenter capital cost. The cost difference is even starker when considering monthly levelized datacenter costs - because space datacenters are expected to have a useful life of only 5 years vs the 15 years for Earth-based datacenters, monthly levelized datacenter capital costs are a whopping 18x higher than for terrestrial datacenters!

GPU rental pricing is typically quoted on a $/hr/GPU basis - and so we also present the above costs on a per hour basis. Using today’s technology, total cost of ownership on a GPU-hr basis for a B300 GPU is estimated at $8.64/hr/GPU for a space-based deployment, compared to $2.37/hr/GPU for a terrestrial deployment.

In addition to total cost of ownership (TCO) in $/hr/GPU, we also look at Levelized Cost of Compute (LCOC). The difference between TCO and LCOC is that LCOC reflects the net cost of compute needed to meet a certain SLA, given expected cluster reliability. LCOC will be higher than TCO because operators will need to account for radiation availability (i.e. compute availability that is temporarily affected by solar radiation), as well as additional GPUs required (i.e. provision for redundancy given GPU failures that cannot be replaced or repaired).

For terrestrial datacenters, the radiation availability and SLA requirement result in a gross up of about 5% on top of TCO of $2.37/hr/GPU to an LCOC of $2.49/hr/GPU. For space, this means a much larger 26% gross up on top of the $8.64/hr/GPU TCO to reach an LCOC of $10.91/hr/GPU.

All of the above TCO calculations including a further more detailed space cost breakdown are available for all years from 2026 to 2050 in our SemiAnalysis AI Space Datacenter TCO Model.

When Will Space and Terrestrial Costs Reach Parity?

Terrestrial datacenters are clearly more cost effective today, but will that always be the case? When will the effect of technological innovations driving cost efficiencies in space datacenter components as well as the ~80% drop in launch costs from ~$1,400-$1,800/kg for Falcon 9 today to only ~$250/kg for Starship in the future envisioned by SpaceX put costs for space AI datacenters at parity with Earth datacenters?

To answer this question, the AI Space Datacenter TCO Model presents a Levelized Cost of Compute (LCOC) analysis, comparing projections for the cost of compute for space-based and Earth-based datacenters.

In our base case scenario, the cost difference between space and terrestrial datacenters starts at over 4x in 2026, before narrowing to parity in ~2040, with levelized costs of compute in space declining below terrestrial thereafter.

The model and this report will show that successfully scaling technology and launch costs is a necessary condition for deploying space datacenters. Once Earth-Space cost differentials narrow meaningfully, then it is the potential shortfall of terrestrial capacity that will drive actual demand rather than further cost differentials.

Another obstacle to overcome stems from chip reliability and servicing. On Earth, 3-6% of GPUs in a cluster annually suffer failures that require human intervention. To ungate space datacenters, we will need to solve this problem either through robotics, greater reliability, over provisioning or a combination of all of the above.

In what scenario would the cost differential be narrower or could we even see space datacenters come out as decisively more cost effective? The AI Space Datacenter TCO Model allows users to customize many of the underlying assumptions.

In our base case, we make the following assumptions: (a) critical technology and engineering challenges (namely radiation impact and GPU reliability) are sufficiently solved or mitigated by ~2040, (b) large cost categories (launch, radiators, and solar) also achieve sufficient cost-down scaling, and (c) a generally bullish outlook on overall AI demand and chip production ramp.

The second scenario, the “Elon Musk case”, is where, on top of the base case assumptions, we assume incremental terrestrial datacenter capacity becomes even more difficult to ramp and costly (this premise is supported by rising ground DC input costs already being seen today), which further incentivizes space-based datacenters (i.e., more cost-effective to use orbital compute). This scenario also assumes a successful ramp of an additional ~1,000k wafer starts per month (WSPM) by 2040 added by Musk’s Terafab - in itself no mean feat, though by then we already expect a considerable acceleration in fab capacity expansion. Again - both the base case and the Elon Musk case are upside cases and depart from our industry models which focus instead on confirmed capacity additions.

The base scenario sees Space-Earth cost parity, as measured by Levelized Cost of Compute (LCOC) in $ per PFLOP-hour, by ~2040, while the Elon Musk Case sees near-parity earlier - by the early 2030s.

Compared to our base case, the Elon Musk case also sees greater and earlier space datacenter demand given less terrestrial datacenter supply to fulfill overall demand (subject to AI silicon constraints).

There is a lot of ground to cover to support the above conclusion, and in the rest of this report, we will deep dive into the underlying details of this framework and the build up of all the major assumptions underlying this analysis.

This deep dive has four main parts:

Part One is a warm-up round that will debunk a few misleading arguments made regarding space datacenters. This is a great way to introduce readers to important and foundational concepts.

Part Two will focus on discussing the four layers of incremental power supply here on earth after briefly addressing a few of the casual arguments for space datacenters.

Part Three introduces the AI Space Datacenter Total Cost of Ownership (TCO) Model and explains the SemiAnalysis TCO framework that is used in the model to discuss and compare costs for terrestrial and space datacenters.

Part Four explains in detail the build up of a space datacenter with a system by system cost breakdown as well as a discussion of the science behind space datacenter design and implementation.

Taken together, this deep dive will give readers a framework for evaluating future scenarios that may make space datacenters a viable decision and evaluating the arguments for or against space datacenters.

Launching our AI Space Datacenter TCO Model

Today, we are also launching our AI Space Datacenter TCO Model into General Availability. The model provides a first-principles, system-level framework for evaluating orbital compute economics, engineering constraints, and supply-demand dynamics across both terrestrial and space-based infrastructure.

It spans from launch vehicle physics and thermal rejection limits to AI demand curves and GPU-level cost of ownership, enabling users to stress-test when and how compute may transition off Earth. Our model spans 2026 - 2050, with dynamic scenario modeling driven by user-controlled assumptions.

The model will answer the question of if and when space datacenters will become economical and will show the scenarios with respect to end demand and costs on Earth that make Space a viable deployment option.

Please reach out to sales@semianalysis.com to find out more!

Part One: Debunking the Four Casual Arguments for Space Datacenters

Deploying datacenters in space will be hard, but for different reasons than most think. Let’s first debunk the overly simplistic arguments behind these four assertions regarding orbital compute.

Argument #1: You Get 24 Hour Free Solar Energy in Space

Most orbits do not actually achieve 24-hour exposure to the sun. The ISS and majority of the Starlink constellation are in Low Earth Orbit (LEO - within 400-500km of earth) and complete ~15 orbits per day, meaning objects in LEO are receiving sunlight for ~60% of the time. This means that out of 1,361 W/m² potential solar irradiance, a space datacenter in LEO might only capture ~800 W/m² in an average 24 hours. The datacenter will also require battery energy storage sufficient to supply 100% of the IT power when the space datacenter is in eclipse, adding hardware cost and complexity.

Instead, a Sun-Synchronous Orbit (SSO) is ideal for Space datacenters. SSO is a retrograde orbit (in the opposite direction of earth’s rotation) at a high inclination of >90 degrees that tracks the Earth’s terminator and faces the sun most of the day, save for an eclipse of up to 35 minutes per day. The battery energy system required to power the datacenter during eclipse is of far lower capacity than for LEO, but it still entails integrating some power electronics as well as some engineering complexity.

Argument #2: Cooling is Free

This is perhaps the most misunderstood claim - cooling is decisively not “free”. In fact, it’s quite the opposite. Space is cold, but it is called “Space” for a reason - unlike on Earth, where the atmosphere can conduct heat away from datacenter cooling towers using convection, there is nearly nothing in space to conduct away the heat via convection, and the primary way to remove heat from a datacenter in space is through radiating the heat away. Radiation can remove heat from an object even in the vacuum of space as internal thermal energy leads to the oscillation of charged particles generating photons that remove the heat energy from the object.

Cooling is the largest structural constraint for orbital compute. The International Space Station’s radiator system can only remove 70kW of heat (a quantity about half of what is required to cool a 140kW GB300 NVL72 rack!), requiring a total area of 325 m² and a total cost of $340-$500M – more on this later.

Admittedly this system was based on 30 year-old technology with plenty of cost bloat baked in, and costs have improved considerably since then. However, it illustrates the fact that heat removal is one of the core engineering problems to solve when it comes to space datacenters.

Argument #3: You Get The Lowest Latency in Space

Low communications latency is often cited as a key benefit enjoyed by deploying compute in space. Nothing is faster than light in a vacuum. However, the truth is more complicated. A LEO compute satellite completes about 15 orbits per day and is only over a given ground station for 5-7 minutes per pass. If the satellite is over the ground station nearest to you, then the connection will be strong, but this will only happen for 5-7 minutes per day.

Outside that window, the traffic must go to another satellite in the constellation or go through multiple inter-satellite links to reach a gateway that is closer to the end user. If there is a satellite passing over the Indian Ocean that is serving a US Customer, those hops through multiple Inter Satellite Links (ISLs) can accumulate 30-80ms of one-way delay. This problem worsens when you switch to optical ground links instead of RF as there are a limited number of ground stations at any given time that do not suffer from some degree of atmospheric interference. This necessitates the deployment of many ground stations spread throughout the world. Communicating from these dispersed ground stations to the end user is yet another source of added latency.

Argument #4: No Need for Permitting in Space

Permitting is more than just a headache when building a datacenter on Earth. In the US, projects face transmission cost inflation and study-related uncertainty, on top of the 5-7 year waits to connect to the grid. As we have outlined in the latest major expansion of our Energy Model, there has been substantial growth in onsite gas and behind-the-meter (BTM) projects as a workaround to waiting in the interconnection queue, but air permitting remains a significant hurdle. Wait times for turbines are also long, with the main OEMs, such as GE Vernova and Siemens Energy, having limited capacity to serve projects planning to come online before the end of the decade.

When it comes to space, one wrinkle is that SSO is a constrained subset of LEO, rather than a separate orbital regime. LEO spans 400-2,000 km across many inclinations, with carrying-capacity estimates ranging from ~100,000 to over a 1M satellites depending on separation and collision-tolerance assumptions. SSO, by contrast, requires a specific altitude-inclination relationship (roughly 97–99° inclination at 500-1,000 km) so that the orbital plane precesses at the rate needed to maintain a fixed local solar time.

Most operational SSO traffic concentrates in a 600–800 km sweet spot. Dawn-dusk SSO, the specific subset that rides the terminator and is relevant to orbital compute, is even narrower. It represents a single local-time slot within an already constrained orbit class, and is materially smaller in usable capacity than LEO.

Other than dawn-dusk SSO, there are other “orbits” that are exposed to the sun 24/7 - for example the Sun-Earth Lagrange Point L1. But here latency is a clear deal-breaker - it takes light ~10 seconds to travel the 3 million km round trip between Earth and L1.

Part Two: Terrestrial Datacenter Constraints and the Four Layers of Incremental Power Supply on Earth

The Four-Layer Framework: How Constrained is the Terrestrial System?

In a recent appearance on the Dwarkesh Podcast, Elon Musk promoted the idea of orbital compute, arguing that Space would shortly be the most compelling place to deploy AI. Musk’s argument is not just that space-bound chips may matter eventually, but that terrestrial power, turbines, and permitting will hit a wall fast enough that space could become the cheapest place to run AI within roughly three years. There are warnings from the turbine manufacturers, and queues to connect to US grids that could last years, so you can see why he thinks this.

Musk and SpaceX clearly believe in this and have put their money where their mouth is, with corporate commitments rewarding Musk with up to 302M Class B SpaceX shares (between ~$30B and ~$60B USD assuming a $100-$200 IPO price range) for delivering 100 TW per year of non-Earth based datacenters – though we will size the analytical realism of that milestone later in this report. On top of that, the recent launch of the Terafab initiative acknowledges one other additional constraint: you can’t build a datacenter anywhere if you don’t have the chips to fill it with.

To stress-test Musk’s power argument on its own terms, it’s worth asking: even if chip supply were unconstrained, would terrestrial power suffer constraints so severe as to force AI compute into orbit?

Borrowing the Peak Oil Framework

The “Peak Oil Theory” framework is helpful in answering this question. In the 1970s, this theory that global oil production was nearing a hard geological ceiling, and that oil would soon become impossible to produce and use. Instead, new supply sources became economical as conventional supply tightened and oil prices increased, boosting the incentive to drill harder. Supply moved up the cost curve and became more infrastructure-intensive, and in more recent decades, the technology improved to access more oil supply, stabilizing prices.

That framework can be applied to datacenter power, where the sources of power supply are varied and the barriers to entry are a lot lower than the much more consolidated chip manufacturing space, which has plenty of near-monopoly producers across the supply chain.

Let’s borrow from the Peak Oil Theory as we walk through the terrestrial power stack layer by layer. As we move through the latter half of this decade, power access is set to get scarcer and trickier to execute on even when available - the end result is that power becomes more expensive. Cost escalates as we tap into more difficult to access sources of power.

All of these layers will have to become exhausted before space becomes an economically viable alternative, or even a preferred option. The fifth layer is a “universal” constraint on all chip deployment, whether deployed on Earth or in Space.

While datacenter capacity was the bottleneck in the past few years, the overriding constraint today has now moved up the stack into semiconductor manufacturing — specifically advanced-node logic capacity at TSMC, HBM production at SK Hynix, Samsung and Micron, and DRAM output across the industry.

Moving giga- or even terawatts of chip capacity into space is a non-starter if we cannot even manufacture the chips to put up there.

As chip manufacturing constraints begin to limit the pace of AI accelerator production, we will now counterintuitively have sufficient datacenter supply in 2027 to cater to chip demand. Our SemiAnalysis AI Datacenter Model models confirmed facility and land bank pipelines, and in the AI Space Datacenter Model, we take a more optimistic capacity view by including potential capacity sources that have yet to be enumerated. Adding layers one through four show that total tracked global datacenter capacity (excluding China) could rise from 89 GW in 2026 to up to 338 GW in 2030 - nearly quadrupling overall capacity over four years. However, this capacity is delivered by tapping layers two to four to allow for more datacenter capacity, and accordingly we see converted capacity, behind-the-meter (BTM) generation, and industrial production expansion kicking in.

Current projected builds and allocated capacity implies tens of gigawatts of headroom in the next few years vs planned accelerator deployment. Unfortunately, Accelerator demand will be bottlenecked by chip production capacity for the next few years, and this is a problem that Space Datacenters cannot solve.

The below table from the SemiAnalysis AI Space Datacenter TCO Model illustrates how silicon capacity holds back AI chip deployment even when more datacenter capacity can be stood up.

Notwithstanding the above, let’s step through each layer of supply and discuss the constraints involved for each layer in detail.

Layer One: Grid-Connected Supply

Grid-connected power is still the cheapest on paper, with infrastructure costs in the $12–15M/MW range. But in most US markets, the real cost is waiting in queue for power interconnection from the grid. North Virginia’s PJM interconnection timelines now run to roughly seven years in practice and that timeline is not workable for hyperscalers that can barely keep up with end demand.

Of course there is an element of overbooking interconnect capacity, but even discounting for speculative filings, the approved and under-construction pipeline is large enough that physical transmission and substation constraints in the major build markets constrain the pace of power addition for the next few years. More on this can be found in our article on the Electric Reliability Council of Texas, i.e. ERCOT’s new batch study process.

Across US ISO territories, gross positive grid reliability headroom (defined as the buffer of effective supply above peak demand plus required reserve margins, measured on SemiAnalysis's penetration-adjusted ELCC methodology) stood at roughly 18.3 GW in 2025, down from 70.2 GW in 2021. In practical terms, grid reliability headroom is a metric that is linked to how much capacity can be connected to the grid at all.

That buffer narrows to just 15.9 GW in 2026 before net headroom turns negative in 2027, reaching an aggregate deficit of approximately 40 GW by 2030. Negative headroom means the grid is oversubscribed on a planning basis - more load is projected than accredited supply can reliably serve under each ISO's reserve margin requirements.

From a global energy perspective, datacenter electricity consumption reached nearly 340 TWh in 2024 - roughly 1.1% of global power output. AI-specific demand accounts for around 0.3% of global generation today, crosses 1.7% around 2027 in our base case, and reaches just under 5% by 2030. Even in an accelerated scenario it stays around 7% by 2030, with that ceiling representing roughly 380 GW of continuous power demand.

Despite the aforementioned tightness, help is on the way.

US planned power generation capacity additions are stepping up sharply in the coming years. Raw nameplate overstates what is actually usable, so we use Effective Load Carrying Capability (ELCC) to measure how reliably each source can meet peak demand. This adjusts for intermittent solar and wind power sources which contribute far less to the grid’s firm capacity than their headline numbers suggest.

This is a picture of progress. The US grid is adding capacity, solar is coming in faster than any prior generation technology, and international buildout continues to absorb demand across EMEA and APAC.

The ~106 GW of global datacenter capacity by 2027 generation additions and grid-connected supply can keep pace with accelerator demand. Beyond that, the grid alone cannot carry the load and we are pushed into the next layer of capacity addition.

Layer Two: Converted Capacity and Powered Land

When looking beyond the grid - the first place to look is converting existing facilities with power into AI Datacenters. Cryptominer conversions are the clearest example of this second supply layer. Core Scientific, IREN, Cipher Mining, Applied Digital, and TeraWulf together point to roughly 2 GW of tracked contracted conversions by the end of 2026 and roughly 5 GW by the end of 2027.

These are sites with existing grid connections, permitted substations, and in some cases usable cooling infrastructure. Although the quality of the existing technology on-site can vary, leading these sites to be similar or even lower in cost to grid-connected supply at around $10–15M/MW. Firms like Fermi Energy and Cloverleaf are bringing large, grid-connected sites to market by taking interconnection risk themselves rather than leaving it to hyperscalers. Oracle has committed at least $3.65B to support 1.4 GW of capacity at the Related/Oracle/DTE Electric campus in Michigan. That would have sounded extreme not long ago, but looks rational now that 1 GW of AI capacity can support on the order of $12–13B of annual revenue.

In aggregate, converted sites and powered land can add 8-10 GW of near-term supply, with Cryptominer conversions supplying 8GW cumulatively by 2028. This near-term supply can act as a relief valve for a few years before the repurposable inventory is mostly absorbed, and the industry turns to the next layer: off-grid power supply.

Layer Three: Behind-the-Meter (BTM) Generation

BTM generation was once considered a last resort, but when major AI cloud contracts imply annual revenue in the range of roughly $12–13M per MW of contracted critical IT load, getting 200 MW online six months early carries an NPV of roughly $400M-$500M. So any additional capex from bringing your own generation (BYOG) and skipping the queue, can result in quick reward. The all-in BTM costs can still fall in roughly the $110–170/MWh range depending on technology, not dramatically different to grid power that can already clear around $150/MWh in major US markets.

BTM annual additions in critical IT power terms — predominantly US-based — are set to be the primary source of power for half of new AI datacenter power capacity additions by 2028 — up from fewer than 7% of capacity added in 2025. Cumulative confirmed BTM critical IT capacity is set to reach 26 GW by the end of 2030, but this number will likely be much higher still from unannounced projects, with OEMs stating the majority of their orderbooks and enquiries come from datacenter projects. Small modular reactors for BTM operations could come into play, with perhaps 1–3 GW of supply post-2030.

The system-wide DC-addressable ceiling across all BTM generation categories runs into the tens of gigawatts per year by 2027 at a cost of $15-20M/MW — spread across six or seven distinct supply chains that don’t all tighten at once.

The BTM market is growing incredibly quickly and existing OEMs and new entrants alike are flooding into the sector. We will soon be launching an expansion to the SemiAnalysis Energy Model, tracking more than 30 OEMs, forecasting quarter by quarter manufacturing capacity, installations, and availability.

Layer Four: The Production Constraint in Industrials

The headroom for more compute on Earth is there from a power and shell perspective once we pull the levers of converted capacity and BTM generation, but the next layer, Layer Four: Industrial Production, consists of supply created by mustering capital for building additional manufacturing to enable more provision of all the prior layers.

Large power transformers already have some of the longest lead times in the electrical stack, this is because building transformers depends on a small number of grain-oriented electrical steel (GOES) producers globally. Transformers are generally required in both grid-fed and BTM scenarios alike. Copper is another restriction, given how broadly it sits across transformers, turbines, cables, busbars, and cooling equipment. Copper is difficult to mine, and has seen a nearly 20% price jump over the past year. That said, the increase in prices further downstream to the transformer manufacturers, are mostly demand-signal driven, and not reflective of actual supply. And the transition to HVDC and optics in networking are increasingly being considered as antidotes to this issue.

Labor for construction and operations is getting more costly, but modularization and digitalization of datacenters has already been implemented in buildout, and can reduce on-site labor needs by more than 50%. Still, a substantial number of skilled man-hours remains, and this would compound substantially once we head into the multiple hundreds of GWs of compute territory.

Tapping into this layer would push costs per MW beyond the $20M/MW range - how far beyond will depend on how many tens or even hundreds of gigawatts of capacity but how costs escalate once we are in this fourth layer will determine whether space datacenters make economic sense.

There are a wide variety of outcomes cost-wise. Users of our new AI Space Datacenter TCO Model can adjust assumptions around base Layer Four costs and the price elasticity of supply to analyze various scenarios.

Layer Five: The Semiconductor Ceiling

In the podcast with Dwarkesh, Musk does not name the hardware that would be best suited to his stellar ambitions. But does this even matter? As we have established, ramping up production for any chip is also the biggest constraint to mass cluster buildout on Earth. Given trends in Semiconductor production tightness - we will hit a silicon capacity constraint well before the other layers.

AI-related demand is modeled to consume just under 60% of TSMC’s N3 output in 2026 and approximately 86% in 2027, nearly squeezing out remaining smartphone and CPU demand. Additional fab area must first be built before chips can be projected into orbit.

Memory faces the same problem from another angle: incremental DRAM capacity is increasingly absorbed by HBM, which consumes roughly three times the wafer capacity of commodity DRAM on a bit per wafer basis basis. Our recent report on silicon and memory shortages goes deeper into this. On the DRAM side, AI-related demand is projected to consume roughly 70% of total DRAM wafer capacity by 2027, up from 12% in 2023 — a near six-fold increase in four years.

The structural reason this ceiling is harder to move than the power stack is cleanroom physics. Adding advanced fab capacity requires building cleanrooms first, then installing tools, then qualifying processes — a sequence that is hard to meaningfully accelerate in the near term regardless of capital availability. The point where that changes looks more like 2032–2034 than 2027–2029, as we will look into further.

In our AI Space Datacenter Model base case - logic and memory capacity additions move in lockstep, though memory tends to be the binding constraint for much of our forecast horizon.

Our base case assumes that there are considerable resources mustered to add semiconductor manufacturing capacity - this is clearly not a conservative assumption and there are plenty of bottlenecks that could derail this base case. Yet - even with these loosened assumptions, the silicon constraint is binding in the long-term even though we forecast it supporting hundreds of GW of AI capacity additions in our base case.

In the Elon Musk Scenario - we keep the same robust chip manufacturing capacity expansions, and with much lower terrestrial datacenter capacity, the AI industry must shift deployments to space.

Getting even close to fulfilling 800 GW of AI demand will require the entire global EUV fleet dedicated to AI with nothing left for phones, PCs, or anything else. Some semiconductor relief could materialize in the 2032–2034 window, as TSMC’s Arizona and Japan capacity comes fully online and memory fabs respond to sustained HBM demand with dedicated capacity additions.

Musk’s Terafab Initiative

During the March 2026 launch, Elon Musk framed Terafab as a 1 terawatt per year compute factory. Tesla, SpaceX, and xAI would build it together in Austin on a $20-25B budget, starting at 100K wafer starts per month and climbing toward 1M wafer starts per month (WSPM), roughly 70% of TSMC’s entire global output today.

The plant sits on 100 million square feet of floor space, which Musk compared to 10x Giga Texas or 15 Pentagons, across thousands of acres, and draws more than 10 gigawatts. Scope covers logic, memory, mask shop, advanced packaging and testing. Compute allocation splits 80% space and 20% terrestrial, roughly 800 GW for orbital datacenters and 100-200 GW for terrestrial inference - this aligns with SpaceX’s recent S-1 disclosures to have one chip variant optimized for terrestrial edge and inference (e.g. Tesla’s Optimus robots, vehicles), and another chip variant for orbital compute. First wafers are claimed to be out as soon as next year in 2027, with mass production in 2028.

We are not one to bet against Musk. He built reusable rockets, scaled EV production to nearly 2M cars a year, and designed custom inference chips that compete with the best in the industry. Even a fraction of Terafab is a meaningful success. The numbers still matter.

Start with capacity. Our Foundry Model puts global 300mm foundry capacity at 4M+ WSPM in 2025. Terafab at the 100K entry ramps in as 2.5% of the entire world of foundry wafer starts. Terafab at 1M full scale is 24% of global foundry capacity, or 68% of TSMC alone. Nobody has added that much in a decade outside of TSMC itself, and TSMC took three decades to get there.

Our Accelerator and HBM Model puts 1GW of deployed compute at 354K wafer starts across logic, memory, and packaging, with memory over 60% of the total. Wafer value per GW runs near $3B. If “1 terawatt” means 1TW of simultaneously deployed compute, that is 354M wafer starts a year, or 21x TSMC’s entire global output. If it means cumulative installed base over 15 to 20 years, the math works but only barely. Our best guess is that “terawatt” plays the same branding role that “giga” played for Gigafactory, originally pitched as producing more batteries than the rest of the world combined.