Microsoft expects Maia 300 to give 40% more tokens per megawatt than GPU systems it does not name, from 2027

A 40 per cent claim that is an expectation, against GPU systems the post does not name, for a chip due in 2027

Microsoft's post of 12 October 2026, by its executive vice president for Cloud + AI, says: "we expect Maia 300 to deliver 40% more tokens per megawatt compared to leading GPU-based systems." That is 1.4 times (derived), or the same tokens from 71.4 per cent of the power, which is 28.6 per cent less (derived: 1 divided by 1.4). Three parts of the sentence carry the weight, and none is a measurement. "Expect" is a forecast. "Leading GPU-based systems" is not a product, a rack or a date. And the chip it describes "will begin production deployments in 2027", which is between 81 and 445 days after the post (derived), with no quarter given.

Set that beside what the post says about silicon that already exists. Maia 200, the second generation, "is now serving Microsoft production workloads, including Microsoft Copilot", with GitHub Copilot and Microsoft Foundry "to follow by end of year", which is 80 days away (derived). It is "deploying across the United States, Europe and Australia". So for anyone who uses Microsoft's AI services, this is not a 2027 story. On Microsoft's own account one generation of its chip serves Copilot today, Foundry is meant to follow by 31 December, and the United Kingdom is not named.

This briefing reads the post, the Azure Maia 300 deep dive that the post calls a "technical paper", the specification image it links, the Maia 300 media page, the earlier Maia 200 announcement and paper, and Microsoft's AMD post of 20 July, plus the memory, process and number-format standards, the vendors' own rack pages, the MLPerf record and the UK pages that bear on a customer. None of it shows that Maia 300 will miss 40 per cent. It shows what kind of evidence the claim is. Here is what the record does not establish.

• That 40 per cent holds for any workload you run. The model, batch size, latency target, context length and number format behind the comparison are not stated.
• Which GPU. The post names no vendor, part or rack. Microsoft's own pages show NVIDIA systems in its MLPerf submission and AMD's Helios platform coming to Azure, so the baseline could be either.
• That anyone outside Microsoft has measured it. Maia 300 is not deployed, and the only Azure submission to the latest MLPerf Inference round lists NVIDIA systems, not Maia.
• What a customer will pay. The post gives no price and no commitment to pass savings on.
• Where a UK request would run, or what isolates it there. The post lists the United States, Europe and Australia, does not name the United Kingdom or define "Europe", and no security design for Maia 300 is described on any page read.

The claims as arithmetic: five GPU comparisons, five baselines

Microsoft has made at least five efficiency claims in 2026 against GPUs or other hardware in its fleet, each in a different unit and against a differently worded baseline. The first four are about Maia 200, which exists. The fifth is a forecast for Maia 300, which does not yet deploy. The wording is Microsoft's, from the Maia 200 announcement of 26 January, the Azure blog post and paper of 25 August, and the 12 October post.

Microsoft's efficiency claims against GPUs in 2026: the wording of the claim and of the baseline, and where it was made. Quoted from the pages named.

Claim	Baseline as worded	Where, and what it describes
"30% better performance per dollar"	"the latest generation hardware in our fleet today" (January); "the latest-generation GPUs in Microsoft's fleet" (August)	Maia 200 announcement, 26 Jan 2026, and Azure blog, 25 Aug 2026. Per dollar, not per watt.
"30% cost (TCO) and 15% energy" saved	"any other AI accelerator in Microsoft's fleet". The paper says "internal data suggests".	Maia 200 paper on arXiv, 25 Aug 2026. No GPU is named and no workload given.
"over 40% higher token generation under the same rack power budget"	"other leading accelerators in the Azure fleet"	Azure blog, 25 Aug 2026. One named model, MAI-Thinking-1, on Maia 200.
"up to 1.7x more tokens per watt"	"leading GPU infrastructure"	Post, 12 Oct 2026. Maia 200, for "built-in AI capabilities" in Teams, Copilot and Cowork.
"we expect ... 40% more tokens per megawatt"	"leading GPU-based systems"	Post, 12 Oct 2026. Maia 300, not yet deployed. A forecast.

Every ratio converts into something you can compare, and the comparison is awkward for the headline. The table below does the sums.

Derived figures and the arithmetic behind them. Inputs are Microsoft's, from the pages named above; every result is ours (derived).

Microsoft's figure	Arithmetic	Result (derived)
Maia 300: 40% more tokens per megawatt (expected)	1 + 0.40; then 1 / 1.4	1.4 times; the same tokens at 71.4 per cent of the power, 28.6 per cent less
Maia 200: up to 1.7x tokens per watt	1 / 1.7	The same tokens at 58.8 per cent of the power, 41.2 per cent less
Maia 200 paper: 15% energy saved	1 / 0.85	1.18 times the work per unit of energy
Maia 200: over 40% more tokens at equal rack power	1 + 0.40	1.4 times or more, on one named model
Maia 300: up to 7x rack-scale throughput over Maia 200	7 / 2 (96 against 48 accelerators a rack)	3.5 times per accelerator
Maia 300: more than 2.5x performance per watt over Maia 200	7 / 2.5	A rack drawing 2.8 times the power, if both figures describe one workload and hold exactly (inference). That would put a Maia 200 rack near 59.6 kW.
Chain the claims: Maia 200 over GPU, then Maia 300 over Maia 200	1.7 x 2.5 = 4.25; then 4.25 / 1.4	4.25 times, against the 1.4 forecast: a factor of 3.04 apart

Read the last row. If one workload, one metric and one GPU stood behind the 1.7 times, the 2.5 times and the 1.4 times, Maia 300 would beat that GPU by about 4.25 times, not 1.4. So they cannot share a baseline, and the post does not say how they differ. Possible reasons, all inference: the 1.4 times is against a newer GPU generation expected in 2027; the 1.7 times is a best case ("up to") on built-in features; the units differ; or the workloads do. The same point shows in the second Maia 200 row: the 40 per cent now expected of the 2027 chip is numerically the same as the "over 40%" Microsoft attached in August to the chip already in production, at equal rack power, on one model. Neither number tells you the generational step against GPUs.

What a baseline statement looks like, for contrast. NVIDIA's Vera Rubin NVL72 page says the system delivers "up to 10x more tokens per megawatt" than its GB200 NVL72, and its footnote names the model (Kimi-K2 Thinking), the input and output lengths (32K and 8K) and the baseline rack, and calls the figure subject to change. That is also a vendor's own claim and we did not verify it. It names the three things a reader needs. It also shows how much the baseline matters: ten times between two generations of one vendor's racks, on that vendor's workload, is 7.1 times the width of Microsoft's 1.4 (derived). Which "leading" system is the baseline can move the answer by more than the gap being claimed.

Stated and not stated, claim by claim

The table sets what Microsoft's post, deep dive, media page and specification image state against what they do not. Press coverage by CNBC and Unite.AI is secondary and is marked where used.

What the Maia 300 post, deep dive, media page and specification image state, and what they do not, read on 12 October 2026.

The claim	Stated	Not stated
40% more tokens per megawatt	"we expect", against "leading GPU-based systems", "by improving efficiency across the system".	Which GPU, model, batch size, latency target, context length or number format; measured or modelled; whether the megawatt is rack, IT or facility power; any independent result.
Up to 7x Maia 200 throughput	"in a full 96-accelerator configuration". The deep dive adds "more than 2.5 times the performance per watt" over Maia 200.	The workload, the method, and any comparison with a GPU. It is Microsoft against its own earlier chip.
Up to 1.7x tokens per watt	Maia 200, for "built-in AI capabilities" in Teams, Copilot and Cowork, against "leading GPU infrastructure".	Which GPU, which feature, whether answers were equivalent, how it was measured.
Maia 200 is in production	"now serving Microsoft production workloads, including Microsoft Copilot"; GitHub Copilot and Foundry "to follow by end of year".	How much traffic, how many accelerators or racks, which products run in which regions, what a customer can see.
Where it is deployed	"deploying across the United States, Europe and Australia". In January the announcement named two US regions: US Central near Des Moines and US West 3 near Phoenix.	The United Kingdom, or what "Europe" covers. Which Azure regions. Whether any customer request is served from them yet.
Maia 300 timing	"production deployments in 2027".	A quarter, a volume or a region. CNBC (secondary) reports a Microsoft general manager declined to give a timeline.
Multi-gigawatt	"multi-gigawatt deployments starting in 2027", Maia "the primary inference system for Microsoft products and services".	How many gigawatts, by when, at which sites, of which generation. "Primary" is not "only".
Security	One sentence: infrastructure must deliver intelligence "securely and efficiently at scale".	Any isolation, attestation, memory protection or confidential-computing design for Maia 300. The deep dive body has no security wording.
Price	A design aim of "useful tokens per dollar" in the deep dive.	A price, a unit, or any commitment to pass savings to customers. "Useful" is not defined.
The "technical paper"	The post says "read our technical paper".	A paper. The link goes to a 7-minute Azure blog post, tagged "Thought leadership", with no GPU comparison in it.

One row deserves a second look. The deep dive, the document the post points to for detail, never mentions a GPU, a megawatt or the 40 per cent. We searched its body for the words GPU, NVIDIA, megawatt and 40% and found none. The 40 per cent figure appears in the post and in press coverage of the post, and nowhere in the technical material a reader would turn to in order to check it.

The rack numbers agree with each other, and that is all they show

The specification image holds figures the text lacks: 13.8 POPS at FP4, 6.9 POPS at FP8, 3.2 TB/s of bidirectional scale-up bandwidth, a pod of 96 accelerators a rack and about 12,000 accelerators in one scale-up domain. Together with the post they let us test whether Microsoft's chip, stack and rack numbers agree. They do.

Rack figures against per-accelerator figures, from the post, the specification image and the deep dive. The check column is our arithmetic (derived).

Item	Stated	Check (derived)
HBM capacity	288 GB an accelerator; 27.6 TB a rack	96 x 288 GB = 27,648 GB = 27.6 TB. Agrees.
HBM bandwidth	18.0 TB/s an accelerator; 1.7 PB/s a rack	96 x 18.0 = 1,728 TB/s = 1.728 PB/s, which rounds to 1.7. Dividing the rounded 1.7 back gives 17.7 TB/s.
Per HBM4 stack	Eight stacks	288 / 8 = 36 GB and 18.0 / 8 = 2.25 TB/s a stack. 36 GB is a 12-high stack of 24 Gb dies, a size Micron lists.
Pin speed	Not stated	2.25 TB/s over a 2,048-bit interface is about 8.8 Gb/s a pin. JEDEC's April 2025 release says "up to 8Gb/s"; Micron lists more than 11 Gb/s; Samsung up to 13 Gb/s.
Rack power	167 kW; 950 W TDP; 96 accelerators	167 / 96 = 1.74 kW each. 96 x 950 W = 91.2 kW, 54.6 per cent of the rack. The other 75.8 kW is not itemised.
Layout	24 trays of four accelerators	24 x 4 = 96. Agrees.
Scale-up	3.2 TB/s bidirectional; up to 12,288 accelerators over 128 racks	1.6 TB/s each way, 17.8 per cent of the HBM bandwidth. 12,288 / 96 = 128 racks, about 21.4 MW of racks (superpod only, switches and facility not counted).

On the memory standard: JEDEC's HBM4 standard page describes a 64-bit channel interface, and its April 2025 release, as reproduced by a trade publication (secondary), gives up to 8 Gb/s across 2,048 pins for up to 2 TB/s a stack, in 4, 8, 12 or 16-high stacks of 24 or 32 Gb dies. Micron and Samsung list faster parts. Eight Micron-class stacks would give more than 22 TB/s (derived: 8 x 2.8), so Maia 300's 18.0 TB/s is about 80 per cent of that. The post names no memory supplier and does not say why the stacks run at the speed they do. A lower speed may trade bandwidth for power (inference). It is not a flaw, and it is not stated.

On the process: TSMC's own page says N2 entered volume production in the fourth quarter of 2025 and that N2P, an extension with "further performance and power benefits", has volume production "scheduled for the second half of 2026". That is consistent with Maia 300 deployments in 2027, and it is TSMC's schedule, not Microsoft's delivery.

The unit in the claim is tokens per megawatt, and a megawatt is bought at the facility. The deep dive says liquid cooling removes more than 80 per cent of the rack's thermal load and that Maia 300 can connect to facility water or use a heat-exchanger unit in air-cooled halls, but it gives no facility overhead. So the 167 kW is a floor under any per-megawatt figure, and whether Microsoft's 40 per cent uses rack power or facility power is not stated.

Peak is not achieved bandwidth. The Maia 200 paper reports, for memory-bound matrix multiplications, up to 51.4 per cent of peak HBM bandwidth, and above 50 per cent for operands bigger than 113.5 MiB. Maia 300 states no achieved figure. A per-watt claim built on 18.0 TB/s is a claim about the ceiling, and a token rate depends on how much of it a real workload reaches.

What the step from Maia 200 is: memory, not compute

Microsoft's own pages for the two generations let us compare them directly. The Maia 200 figures are from its announcement and paper; the Maia 300 figures are from the post, the deep dive and the specification image.

Maia 200 against Maia 300 from Microsoft's own pages. Ratios and per-watt figures are ours (derived); the last column says whether Microsoft states the ratio.

Item	Maia 200, then Maia 300	Ratio (derived) and Microsoft's wording
HBM capacity	216 GB HBM3e, then 288 GB HBM4	1.33 times. Microsoft: "33% more capacity".
HBM bandwidth	7 TB/s, then 18.0 TB/s	2.57 times. Microsoft: "2.5 times".
TDP	750 W, then 950 W	1.27 times. Not stated as a ratio.
Peak FP4	10,145 Tflop/s (paper), then 13.8 POPS (image)	1.36 times. Microsoft: compute "36%" more. Dense or sparse basis not stated.
Peak FP4 per watt of TDP	13.5, then 14.5 trillion operations a watt	1.07 times. Not stated by Microsoft.
HBM bandwidth per watt	9.3, then 18.9 GB/s a watt	2.03 times. Microsoft: "approximately 2 times".
FP4 operations per byte of HBM bandwidth	1,449, then 767	About half. Not stated by Microsoft.
Scale-up bandwidth	2.8 TB/s, then 3.2 TB/s bidirectional	1.14 times. Microsoft: "14% more".
Accelerators a rack; scale-up domain	48 and 6,144, then 96 and 12,288	Twice and twice.
On-die SRAM	272 MB, then not stated	The specification image has no SRAM row.

Microsoft's ratios reproduce, which is a point in its favour. What the table adds is the shape of the step. Peak compute per watt of TDP rose by about 7 per cent (derived, and the dense or sparse basis of the two figures is not confirmed), while memory bandwidth per watt about doubled. The balance moved from roughly 1,450 FP4 operations for each byte the HBM can deliver to roughly 770. That is a chip built for work that waits on memory, which is how the post describes long-context decoding and agentic tasks. It says little for work that waits on compute, such as reading a long prompt, and the post gives no figure for that phase. This is inference from Microsoft's numbers, not a Microsoft statement. It does mean a 40 per cent token gain, if it arrives, will depend on the mix of work a service does.

The 7 times figure is mostly density. Twice the accelerators in a rack gives 2 times, and the rest is 3.5 times a chip (derived). At 2.5 times the memory bandwidth, a decode-bound token rate would rise by about that much on bandwidth alone (inference), so 3.5 times needs more from number formats, kernels or the network. Microsoft does not break the 7 times out.

The baseline cannot be rebuilt from the vendors' own pages

The post names no GPU, so this is not Microsoft's baseline. It is what the main rack-scale vendors print on their own pages, set beside Microsoft's figures for scale. One entry is Microsoft's own: Azure's MLPerf submission of 16 September lists the GB300 at 1,400 W per GPU.

Rack-scale systems as the vendors state them on their own pages, and Microsoft's own MLPerf file for the GB300. Per-GPU figures marked derived are ours.

System	HBM and bandwidth per accelerator	Accelerator power as stated
Maia 300 rack: 96 accelerators, 27.6 TB, 1.7 PB/s (Microsoft)	288 GB HBM4; 18.0 TB/s	950 W TDP; 167 kW a rack
GB300 NVL72: 72 GPUs (NVIDIA page; Azure MLPerf file)	288 GB HBM3e; 8 TB/s (576 TB/s over 72, derived)	1,400 W TGP in Azure's MLPerf v6.1 file. NVIDIA's page states none, and no rack power.
Vera Rubin NVL72: 72 GPUs, 20.7 TB (NVIDIA page)	288 GB HBM4; 19.2 TB/s	Not stated on the page, and no rack power.
Helios: 72 MI455X, 31 TB (AMD pages)	Up to 432 GB HBM4; 23.3 TB/s. The Helios page also prints 19.6 TB/s.	Not stated on the pages, and no rack power.

Take the post's phrase "industry-leading HBM bandwidth per watt". On Microsoft's own listed power it holds against the GB300: 18.9 GB/s a watt for Maia 300 against 5.7 for the GB300 (derived: 18,000 / 950 and 8,000 / 1,400), or 3.3 times, with the caveat that TDP and TGP are not the same measure. Against the Rubin and the MI455X it cannot be checked, because their pages state no power. It would hold if the Rubin drew more than about 1,013 W or the MI455X more than about 1,230 W (derived: bandwidth divided by 18.9 GB/s a watt). Either way it is memory bandwidth per watt of a chip, not tokens per watt of a service.

On compute, the GB300 NVL72 page lists 1,080 PFLOPS of dense FP4 for 72 GPUs, which is 15 PFLOPS a GPU (derived); Maia 300's 13.8 POPS is 92 per cent of that, with Maia's dense or sparse basis not stated. No page lists a rack power for any of these systems, so a tokens-per-megawatt figure cannot be built from vendor pages alone. Microsoft's AMD post of 20 July adds that it is bringing AMD's Helios platform to Azure for inference as "ND MI455X v7" machines and calls customer choice "a core design principle", so "leading GPU-based systems" in Microsoft's fleet may mean NVIDIA, AMD or both. The post does not say.

Multi-gigawatt: a power plan, and what it converts to

"Multi-gigawatt" is a statement about electricity, so it converts. The table assumes every watt is rack power at Microsoft's 167 kW for 96 accelerators, which is an upper bound: cooling and facility overheads would lower every count. It is not a deployment figure, and Microsoft gives none.

Gigawatts of Maia 300 racks as racks and accelerators, at 167 kW and 96 accelerators a rack. An upper bound that ignores facility overheads (derived).

Power	Racks of 167 kW	Accelerators at 96 a rack, at most
1 GW	5,988	574,850
2 GW, the least "multi-gigawatt" can mean	11,976	1,149,701
3 GW	17,964	1,724,551
One superpod (12,288 accelerators)	128	12,288, about 21.4 MW of racks

So "multi-gigawatt" means at least about 1.1 million accelerators by this bound, and Microsoft states no chip count. A report relayed by a secondary outlet, Runtime Wire, says Microsoft was discussing manufacturing capacity for more than 300,000 Maia 300 chips in 2027, citing earlier reporting; we could read only its opening paragraph. If that were right and all were Maia 300 racks, it is 3,125 racks and about 522 MW (derived). The post says the family scales "starting in 2027", which is a start, not an end.

"Primary inference system" is likewise a direction. CNBC, a secondary source, reports that a Microsoft general manager said Microsoft keeps "optionality" over silicon, that NVIDIA remains a large part of the picture, and that a sell-side analyst note estimated Maia at about 10 per cent of Microsoft's AI chip spending by the first quarter of 2027. That estimate is an analyst's, not Microsoft's. CNBC also drops the word "expect" from the 40 per cent, writing that the new version can run "with 40% more tokens per megawatt". The post says Microsoft expects it.

The dates in this story, counted from the post on 12 October 2026 (derived), with the source of each.

Event	Date	Days from the post
Maia 200 announced (Microsoft)	26 Jan 2026	259 before
Maia 200 paper posted to arXiv	25 Aug 2026	48 before
Azure's MLPerf Inference v6.1 submission published (NVIDIA systems only)	16 Sep 2026	26 before
Microsoft Ignite, San Francisco and online	17 to 20 Nov 2026	36 to 39 after
Foundry on Maia 200 "by end of year"; UK in-country Copilot processing "by the end of 2026"	31 Dec 2026	80 after
Maia 300 "production deployments in 2027"	1 Jan to 31 Dec 2027	81 to 445 after

Friendly names that sound like facts about your service

Each label below sounds like a property of the service you buy. Each is a fact about Microsoft's design, supply plan or strategy.

Labels in the Maia 300 post and deep dive, what each is, and what it is not.

Label	What it is	What it is not
"inference-first architecture"	A design intent: memory-heavy, decode-heavy work.	A measured result, or a statement about how your requests are served.
"primary inference system"	A direction for Microsoft's own products from 2027.	A share, a date, or a promise that your service runs on it. CNBC reports Microsoft keeps optionality.
"industry-leading HBM bandwidth per watt"	A chip-level ratio, checkable against the GB300 on Microsoft's own power figure.	Tokens per watt. Not checkable against the Rubin or MI455X from vendor pages.
"multi-gigawatt"	A power plan across the whole Maia family from 2027.	A chip count, a date, or any figure about your region.
"Frontier Transformation"	Microsoft's name for its strategy. The pages give it no technical content.	A service level, a control or a commitment.
"enhanced MXFP4"	A number format the post says cuts memory and bandwidth.	A defined standard. The OCP specification defines no "enhanced" variant.
"useful tokens"	The unit Microsoft says it maximises per watt and per dollar.	Defined anywhere on the pages read.

The post says "Model and silicon choice are inherent in our vision". Whose choice? Microsoft's Learn pages on deployment types, data privacy and regions describe choosing a model, a deployment type and a region. None of the three mentions Maia, an accelerator or any silicon. CNBC reports that Maia accelerators cannot be rented by the hour, unlike Google's and Amazon's, and a Microsoft general manager said the company wants to "deploy the right silicon for the right models". The silicon choice, as far as the record goes, is Microsoft's.

On the number format: the OCP Microscaling specification v1.0, written under an alliance that the OCP announcement says AMD, Arm, Intel, Meta, Microsoft, NVIDIA and Qualcomm formed, defines MXFP4 as 4-bit E2M1 elements in blocks of 32 sharing one 8-bit scale. That is 4.25 bits an element (derived: 4 + 8/32). The specification defines no "enhanced" variant and the deep dive does not say what is enhanced, nor what its "sub-3-bit storage formats" are. Narrower formats move fewer bytes, which is the point. The pages give no comparison of outputs between Maia serving and GPU serving, so whether a service answers the same on each is not stated.

Nothing independent yet, and a test only Microsoft can run

We looked for a result for Maia that Microsoft did not produce. As of about 15:10 BST on 12 October 2026 we found none.

• MLPerf Inference. The v6.1 results, published on 16 September 2026, list Microsoft Azure among 30 submitting organisations. Azure's submission folder holds three system descriptions, all NVIDIA: two GB200 NVL72 and one GB300 NVL72. No Maia system is submitted.
• The Maia 200 paper. The arXiv paper gives peak figures and one end-to-end result, a 7-billion-parameter open model on a single chip at 2,434 tokens a second. It publishes no GPU comparison and says of its matrix tests that "we outperform comparable GPUs and CPUs but consciously refrain from a direct comparison". The 30 per cent cost and 15 per cent energy savings are labelled "internal data suggests".
• Maia 300. No paper exists in what we read. The "technical paper" is a blog post.
• Press. CNBC and Unite.AI repeat the post. Microsoft's own quote sheet of analyst comments is compiled by Microsoft for use "as third-party perspective". One quoted analyst says custom silicon can become an important margin driver, which is a comment about Microsoft's economics, not yours.
• Access. CNBC reports Maia cannot be rented by the hour. An outside party cannot run its own test unless Microsoft opens one.

None of this is a criticism of the chip. Custom accelerators are a real way to cut the cost of inference, the figures above hang together, and Microsoft's habit of publishing a paper for Maia 200 is better than silence. The gap is that the headline claim for the new chip rests on a comparison nobody else can repeat. Microsoft could close it by submitting Maia to MLPerf or naming its comparison.

Who has what interest

Microsoft wrote the post, designed the chip, chose the comparisons, and sells Azure, Microsoft 365 Copilot, GitHub Copilot and Foundry, so it gains when its own silicon lowers its cost of serving them. It is also an OpenAI shareholder: its own post of 28 October 2025 put its stake at roughly 27 per cent on an as-converted diluted basis (as of that post; not re-checked), and the Maia post says Maia 200 runs OpenAI models. NVIDIA and AMD sell the leading GPU systems and have their own comparisons. TSMC makes the compute chiplets. The memory supplier is not named. If Maia lowers Microsoft's cost per token, as the post says it is meant to, whether that lowers yours is a pricing decision the post does not make.

Security: one sentence in the post, nothing in the architecture pages

The post says AI infrastructure must deliver intelligence "securely and efficiently at scale". We searched each Microsoft page for the security design behind that. This is what each says.

What each Microsoft page says about security for Maia, read 12 October 2026, and what it does not say.

Page	What it says	What it does not say
Post, 12 Oct 2026	One sentence, quoted above. No Maia 300 security feature.	Isolation between customers, attestation, memory protection, confidential computing.
Deep dive, 12 Oct 2026	No security wording in the body (searched for secur, confiden, isolat, attest, encrypt). It does cover telemetry, reliability and redundancy.	Everything in the first row.
Maia 300 media page	Lists videos, images and a quote sheet.	Any security statement.
Maia 200 announcement, 26 Jan 2026	"Native integration with the Azure control plane delivers security, telemetry, diagnostics and management capabilities at both the chip and rack levels."	What those security capabilities are.
Maia 200 paper, 25 Aug 2026	"a fully secure boot system", integrated into Azure's management.	Tenant isolation, attestation, memory scrubbing.

The mechanism matters because of what the deep dive says Maia 300 does. Any accelerator "can directly initiate communication to any accelerator in the superpod, without involving the host". Prefill and decode can run on different accelerators, and the working memory of a conversation, the key and value state, "moves directly to the selected decode workers" over the same fabric. A 64-accelerator job can run as four shards in four racks, and a spare tray in one rack can stand in for a failed tray in another. These are efficiency features, and they mean state derived from your prompts moves between accelerators and racks over an Ethernet-based fabric that serves many customers. The pages say nothing about whether that state is encrypted in transit, bound to one tenant, or scrubbed when memory is reused.

"Not stated" is not "absent". It is the gap a customer should ask Microsoft to close in writing before Maia carries regulated data. For what a missing scrub step looks like when hardware is reused, the site's earlier brief on Cloudflare container disks returned to a shared pool without being cleared is the example. It is not a claim about Maia.

UK: what to put on paper if you use Copilot, Foundry or Azure OpenAI

Where it runs. The post lists the United States, Europe and Australia for Maia 200. Microsoft's own page on in-country Copilot processing said in November 2025 that UK customers would have the option "by the end of 2025". Its editor's note of 3 April 2026 now says local inferencing for Microsoft 365 Copilot is expected in the United Kingdom "by the end of 2026", twelve months later (derived). For Foundry, the deployment types page, updated 12 August 2026, says Global types "May be processed in any Azure region", Data Zone types stay within the US, EU or Asia Pacific, and geography-based types "arrive last, have no guaranteed availability date". There is no UK data zone on that page, and the region support page lists UK South. None of these pages mentions Maia or any silicon. So a UK customer cannot tell from Microsoft's documentation which silicon serves a deployment type, or whether a UK deployment will run on Maia.

Model and hardware change control. A service moving from GPU to Maia silicon is a change inside the supplier's supply chain, under the supplier's control. Microsoft's Maia 200 deep dive says workloads are scheduled with the same tooling as Azure's GPU fleets, which "ensures portability across hardware types". The NCSC's guidelines for secure AI system development (27 November 2023) are aimed at providers whose systems use external APIs, which describes a customer building on Foundry. They say to assess and monitor AI supply chains across the life cycle and to be "ready to failover to alternate solutions" (secure development), and that "changes to data, models or prompts can lead to changes in system behaviour", so major updates should be treated "like new versions" and users supported to evaluate model changes (secure operation). The ICO's accountability guidance adds that a processor may decide "the IT systems and methods you use to process personal data" where the contract allows. So the contract decides. If it does not constrain the supplier's technical choices, silicon is plausibly the supplier's call (inference). Ask for notice of a change, and for the contract term that constrains it.

Behaviour parity. A change of silicon can come with a change of number format, and the pages give no evidence that outputs match. One model name can already cover two versions, and the site's brief on Microsoft's Decision-1 launch shows how a headline ratio changes when the baseline does. Pin your own evaluation set and re-run it at each change, as the NCSC's monitoring guideline implies.

Data location and transfers. The ICO's international transfers page covers restricted transfers, adequacy regulations including the UK Extension for the US, and the transfer risk assessment, now called the data protection test in legislation. Which of these applies depends on where processing happens, and the post does not say where Maia traffic is processed. Microsoft's data privacy page (page dated 18 May 2026) says prompts and completions are not used to train the base models and that Global deployments may be processed in any geography where the model is deployed. We read no retention period for abuse-monitoring samples on it and state none. The ICO's AI guidance says it is under review because of the Data (Use and Access) Act, and its DPIA section says a DPIA should set out processors involved. Record silicon and region as items in the DPIA. A health body using Dragon Copilot, which the post lists among services Maia will support, should read these questions with its data protection officer, because clinical records are among the most sensitive data a service handles.

Supplier concentration and the Critical Third Parties regime. HM Treasury designated four providers from 13 July 2026 under the Critical Third Parties (Designation) Regulations 2026, Microsoft Ireland Operations Limited among them. The release says oversight "applies only to the systemic services provided to the financial sector" and that "Financial firms remain responsible for managing risks arising from their third-party suppliers." The Bank of England's page says designated providers must keep the regulators and the firms that rely on them informed, particularly during major incidents. The pages read do not list which Microsoft services are systemic, do not mention Maia, and say nothing about a change of silicon. A financial firm should ask Microsoft whether the AI services it uses are within scope and how a silicon change would be notified. The NCSC's supply chain guidance says to know your suppliers and what they have asked their sub-contractors to do, and its control principles say it is "not possible to transfer complete responsibility or accountability" to a cloud provider. Making one in-house chip Microsoft's primary inference system concentrates Microsoft's own supply, and a customer cannot diversify inside a Microsoft service. It can diversify only by contract and by keeping a fallback.

Cost control. Tokens per watt is not tokens per pound. The post gives no price, and what a customer is billed per token, per hour or per reserved unit is not stated for any Maia-served deployment. The deployment types page says Global Standard "has the lowest price" and the broadest region coverage, which puts cost and data residency in tension. Record the cost of a completed task, not of a token, and compare each deployment type on it.

What to do, in order

The question the post cannot answer

If your Copilot or Foundry requests moved to a Microsoft chip that nobody outside Microsoft has benchmarked, in a region your contract does not name, who would tell you before it happened, and how would you know the answers had not changed?

Key facts