Azure Maia 300: what Microsoft silicon means for Foundry

On 12 October 2026 Scott Guthrie announced Azure Maia 300, Microsoft's third in-house inference accelerator, and said Microsoft will "scale our Azure Maia family to multi-gigawatt deployments starting in 2027, making Maia the primary inference system for Microsoft products and services." The chip numbers are large: 288 GB of HBM4 per accelerator, 18 TB/s of memory bandwidth, 96 accelerators in a 167-kilowatt rack, and a claim of 40% more tokens per megawatt than leading GPU-based systems. The sentence that matters for anyone paying an Azure OpenAI or Foundry invoice is quieter and sits in the middle of the post: the current chip, Maia 200, already serves Microsoft Copilot, and "GitHub Copilot and Microsoft Foundry to follow by end of year." The models you call through Foundry are moving onto Microsoft silicon within the next eleven weeks, and Microsoft has published no price, no region list and no opt-in for it. This piece sorts out what was announced, what changes for a Foundry deployment in the EU data zone, and what you can verify yourself.

What was announced, next to what already runs

Maia 200 was announced on 26 January 2026 as a TSMC 3 nm part with 216 GB of HBM3e at 7 TB/s, a 750 W thermal envelope, and a claim of 30% better performance per dollar than the newest hardware then in Microsoft's fleet. It went live first in the US Central region near Des Moines, with US West 3 near Phoenix named as next. Yesterday's post says it is now "deploying across the United States, Europe and Australia" and delivering up to 1.7x more tokens per watt for Teams, Copilot and Cowork workloads compared with GPU infrastructure. Maia 300 is the successor, built as a multi-chiplet part on TSMC's N2P process, and it does not reach production until 2027.

Three things are absent from both announcements. There is no pricing of any kind. There is no VM SKU or deployment type that lets a customer pick Maia, and the Foundry deployment-types documentation, updated in August, still only lets you choose where data is processed and how you pay. And there is no named European region. "Europe" is as precise as it gets, which for a Swedish buyer who has standardised on Sweden Central is not precise at all.

You do not choose the silicon, and that is the point

In an interview published the same day, Guthrie said customers using Microsoft's APIs will end up "using Maia chips under the covers." That is the operating model. Foundry's serverless deployment types abstract the hardware completely: Global Standard routes to any Azure region, Data Zone Standard keeps processing inside the EU or US zone, Regional Provisioned pins it to a geography. None of them expose an accelerator family, and nothing in yesterday's announcement suggests that will change. If Microsoft moves GPT-6 Sol traffic from Nvidia racks to Maia 200 racks in a region you use, you will not be notified, and your bill will not say so.

This is how every hyperscaler already runs managed inference, and in most respects it is good for you. You are buying tokens with a latency and quality expectation, not rack hours. The responsibility that comes with it is yours: the only way to know whether a silent backend change affected your workload is to have a baseline to compare against. Teams that already run a nightly evaluation set against their production deployment, recording p50 and p95 latency, output length and a task-specific quality score, will notice a migration. Teams that do not will find out from a user.

One detail from the technical material deserves attention here. Maia 300's throughput figures are quoted at low precision, and coverage of the technical paper notes support for enhanced MXFP4 formats. Microsoft has not said which precision any given Foundry model is served at today, on any hardware, and it does not promise bit-identical output across backends. A model served at a different quantisation can produce different tokens for the same prompt at the same temperature. For a chatbot that is invisible. For a classification pipeline whose thresholds were tuned in a spreadsheet in March, it is a regression you will attribute to the wrong cause unless the evaluation set exists.

The 40% is Microsoft's cost, not your price

Tokens per megawatt is a datacentre operator's metric. It tells you how much inference Microsoft can sell from a fixed power envelope, which is the constraint that actually limits AI capacity in 2026. It says nothing direct about the per-million-token prices on the Azure pricing page. Those prices are set by competition between model providers, and Guthrie was explicit about that in the same interview: "There's a real price war going on where model costs are coming down." The $2 input and $10 output per million tokens that GPT-6.1 Sol, Claude Sonnet 5.5 and Gemini 4 Argon converged on this autumn arrived before a single Foundry request ran on Maia. Microsoft-Decision-1 at $0.042 per million did too.

What cheaper inference does change is Microsoft's room to keep matching those cuts without eroding margin, and its willingness to sell capacity that is currently rationed. The deployment-types documentation is candid about the rationing: geography-based deployment types "arrive last, have no guaranteed availability date, and depend on capacity that frees up as older models retire." If Maia racks arrive in European regions in volume, the first visible effect for an EU customer is more likely to be a Data Zone or Regional deployment type appearing for a model that was Global-only, rather than a lower unit price. That is worth more to a regulated Swedish organisation than a few öre per thousand tokens, and it is the thing to ask your Microsoft account team about by name.

A sober way to put money on it: do not budget for a Maia-driven price cut in 2027. Budget on today's list prices, keep the 50% batch discount and the flex and priority processing tiers in the model, and treat any cut as upside. The lever you control is which model answers which request. Routing a classification step from a $2 model to a $0.042 one saves more than any silicon transition will.

Which models actually move

Both Maia announcements name the same three groups: OpenAI models, Microsoft's own MAI models, and "leading open-source model families." Anthropic is not mentioned in either post. The November 2025 partnership under which Anthropic committed to $30 billion of Azure compute named "NVIDIA Grace Blackwell and Vera Rubin systems" for its initial one gigawatt, and Guthrie said yesterday that Microsoft remains "big partners of NVIDIA and AMD." On the public record, then, Claude models in Foundry stay on Nvidia hardware, and OpenAI and open-weight models are the ones that follow Copilot onto Maia 200 by year end.

For a team that has standardised on one model family, this splits into two cases. If you run GPT-6 or an open-weight model such as a Llama or gpt-oss deployment through Foundry serverless, assume your traffic is in scope for a backend change before 31 December and set up the baseline now. If you run Claude through Foundry, nothing public says your backend changes this year, but the same baseline costs nothing extra and protects you against Nvidia-to-Nvidia generation changes too.

Capacity in the EU data zone, and what silicon does not fix

Sweden Central is the region most Swedish Azure customers put their AI workloads in, and it is one of the regions inside the EU data zone. On 29 September 2026, between 10:03 and 15:58 UTC, Azure OpenAI Service, Foundry Agent Service, Foundry Models and Cognitive Services in Sweden Central returned intermittent failures, raised latency and HTTP 5xx errors. Microsoft's preliminary root cause, under tracking ID 7QL5-Z50, was a backend metadata service whose database and cache calls timed out after an internal process increased request volume, causing unhealthy instances to restart in a loop. Not one GPU was involved.

That incident is the useful corrective to reading yesterday's announcement as a reliability story. More accelerators per megawatt raise the ceiling on how many tokens a region can serve. They do nothing for a control plane that falls over under its own metadata traffic, and they do nothing for a Data Zone Standard deployment whose primary region is interrupted, which the documentation notes affects all traffic initially routed there. The resilience work is the same as it was in September: a second deployment in another EU data zone region such as Germany West Central or France Central, a client that retries against it, and a decision recorded somewhere about whether Global Standard is acceptable for the workload when the EU zone is degraded. Data Zone processing stays within the EU Data Boundary regardless of which chip answers, so the silicon transition does not reopen your residency assessment. It also does not close the availability gap.

The Swedish and EU angle

Residency documentation does not need a Maia addendum. The EU Data Boundary commitment is about where prompts and responses are processed and stored, not what processes them. A Data Zone deployment that was compliant on Nvidia hardware is compliant on Maia hardware in the same zone. If your GDPR Article 30 record or your DPIA names the Foundry deployment type and region, it remains accurate. If it names the hardware, it was over-specified and should be fixed anyway.

Energy is the Swedish argument for asking where the racks land. Microsoft chose tokens per megawatt as the headline metric because power, not chips, caps datacentre growth. Sweden's regions sit on a grid with low-carbon electricity and cool air, which is why they exist. A 167 kW rack that delivers seven times the throughput of its predecessor is the kind of hardware an operator wants in a cheap-power region. Microsoft has said nothing about which European region gets Maia first. A Swedish customer with a provisioned-throughput commitment has a legitimate reason to ask, because PTU capacity for a new model is exactly what the documentation says is gated by freed-up hardware.

Procurement language should say "deployment type," never "GPU." Public-sector tenders in Sweden still occasionally specify accelerator vendors in requirements documents written by people who last looked at the market in 2024. A Foundry serverless deployment cannot satisfy a clause that names Nvidia, and after yesterday it would be a mistake to try. Specify the deployment type, the data zone, the SLA tier and the evaluation thresholds the service must meet. Those are the things Microsoft commits to and the things you can test.

What to do this quarter

• 1. Inventory deployments by type and model. List every Foundry and Azure OpenAI deployment with its SKU name (GlobalStandard, DataZoneStandard, ProvisionedManaged and so on), region and model. The OpenAI and open-weight entries are the ones in scope for a year-end backend change.
• 2. Record a baseline before December. Run a fixed evaluation set of a few hundred representative prompts against each production deployment and store latency percentiles, token counts and task scores. Rerun it weekly. A backend migration shows up as a step change in that series.
• 3. Pin model versions and read the retirement calendar. A silicon migration is most likely to coincide with a model version bump. Pinned versions give you a controlled moment to re-baseline instead of two changes landing together.
• 4. Enforce deployment types with Azure Policy. If EU data zone processing is a requirement, deny the Global SKUs at the subscription or management-group scope so that a developer cannot fix a capacity shortage by quietly switching to GlobalStandard.
• 5. Ask Microsoft two specific questions. Which European regions will host Maia 200 capacity in 2026, and will that capacity be used to open Data Zone or Regional deployment types for models currently Global-only. Write down the answers; they will be useful in the next PTU negotiation.

The policy for item 4 is short. It denies any Foundry deployment whose SKU is Global Standard; duplicate the rule for GlobalProvisionedManaged and GlobalBatch if those are also out of bounds.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        { "field": "type", "equals": "Microsoft.CognitiveServices/accounts/deployments" },
        { "field": "Microsoft.CognitiveServices/accounts/deployments/sku.name", "equals": "GlobalStandard" }
      ]
    },
    "then": { "effect": "deny" }
  }
}

Conclusion

Maia 300 is a 2027 story for Microsoft's balance sheet and a 2026 story for your evaluation pipeline. The chip you will actually meet first is Maia 200, which reaches Foundry by the end of this year for OpenAI and open-weight models, in European regions Microsoft has not named, at prices that are not changing because of it. Build the baseline, lock the deployment types, and ask where the racks are. Everything else in the announcement is Microsoft's problem to deliver.