Microsoft Maia 300 sets a 2027 date for inference at rack scale

Microsoft plans to begin production deployments of Azure Maia 300 in 2027, while Maia 200 is already serving workloads including Copilot. For teams using Microsoft's AI services, the October 12 announcement changes the infrastructure roadmap; it does not establish a new Maia 300 service they can deploy today.

Microsoft's announcement and architecture explanation were published on October 12, 2026, the same date as the original report discovered through The Verge. The deployment date belongs to next year, not to the announcement.

Production has two different dates

Microsoft says Maia 200 is running production workloads and that GitHub Copilot and Microsoft Foundry are due to follow by the end of 2026. Maia 300 is the next generation, intended to become part of a larger Maia deployment programme starting in 2027.

That distinction matters when planning capacity. A change in the infrastructure behind a Microsoft product is different from a customer-facing offer with documented access, regional availability and pricing. The announcement does not establish those terms for an independently selectable Maia 300 service.

Read the rack comparison as a system claim

Microsoft expects 40% more tokens per megawatt than leading GPU-based systems and claims up to seven times Maia 200's rack-scale token throughput in a full 96-accelerator configuration. These are manufacturer claims, not independent measurements reported by TechKili. The sevenfold figure describes a rack comparison, not a sevenfold improvement for every chip or every user request.

The architecture article explains that Maia 300 doubles the number of accelerators per rack and changes memory placement, data movement and networking together. Its design places data near the compute that uses it, reducing unnecessary transfers. Those mechanisms help explain the direction of the design without proving the headline gains in a particular application.

For evaluation, throughput and response time answer different questions. A service may handle more concurrent requests without making every individual answer proportionally faster. Comparing systems also requires the same model, precision, context length and workload. The announcement is insufficient to calculate a customer's future bill or guarantee an application-level speedup.

What an Azure team can establish today

Keep the existing deployment decision tied to the service contract and workload measurements available today. Ask for model support, operating regions, access terms and latency under your own concurrency pattern before treating a hardware roadmap as usable capacity.

Networking remains part of that assessment. Our coverage of Upscale's mixed-accelerator network proposal explains why connecting accelerators and validating a complete workload are separate tasks. Maia 300 similarly merits evaluation as a full system. Its 2027 production schedule gives teams a planning horizon; the useful next evidence is how a documented service performs for their workload.