Monat: Oktober 2026

Deep dive into Azure Maia 300 architecture

From its inception, Azure Maia has been built around a single architectural philosophy: optimize the entire system for LLM inference so that every watt and every dollar delivers more intelligence. Now in its third generation, Maia 300 is the fullest expression of that philosophy. Maia 300 is built as a complete system, with software, silicon, physical rack infrastructure, networking, and datacenters co-designed to operate as a single platform to meet the demands of cloud-scale agentic inference.

Learn more about Maia 300 here

That system-level approach is increasingly necessary as agentic workloads, including multi-step execution, long-context decoding, and tool use, change the computational profile and arithmetic intensity of inference. Meeting these demands requires sustaining locality, supplying compute with enough memory capacity and bandwidth, minimizing data movement, scaling communication efficiently, and fitting the most capability within a datacenter’s fixed power and cooling envelope.

At Microsoft, we see this transformation firsthand through the products and platforms our customers use every day, from Microsoft Copilot and GitHub Copilot to Microsoft Foundry. Operating these workloads at scale gives us a unique view into how AI is being adopted across industries and the infrastructure needed to support the next generation of AI applications and agents. Maia 300 is designed to maximize useful tokens per watt and useful tokens per dollar, bringing more capacity, capability, and performance to these products and Microsoft’s broader AI portfolio for our customers.

Energy-efficient inference through software-defined dataflow

Maia 200 introduced a new class of accelerator architecture called Software Defined Locally Accessed Dataflow Architecture, or SDLA. It begins with the observation that efficient data management, including storing, moving and converting data, is one of the central challenges in modern AI systems. The Maia programmable dataflow architecture separates control path programming from data path execution and allows software to explicitly coordinate data placement, movement, conversion and synchronization across specialized local memories, DMA engines, compute engines, and the network.

Maia 300 system-on-chip architecture

Maia 300 evolves this architecture for long-context, reasoning-intensive, and decode-heavy inference. First, memory moves from the uniform memory access (UMA) organization of the SoC to a locality-aware non-uniform (NUMA) organization across chiplets, so software can place data near the compute that uses it. Second, new narrow-precision formats with hardware-accelerated data type conversion reduce the bytes moved for each token. Third, the rack doubles to 96 accelerators and the scale-up domain grows to a superpod of 12,288 accelerators, enabling more accelerators to work effectively as a single system.

Rather than scaling performance through increased power and silicon area alone, Maia 300 improves performance per watt through a set of architectural innovations that optimize data movement, locality, precision, and memory efficiency across the system:

Multi-chiplet architecture boosts performance by placing compute on TSMC N2P, where the advanced process delivers the greatest performance-per-watt benefit, while separating memory-controller and I/O functions onto dies optimized for bandwidth, connectivity, and cost. This increases the silicon area dedicated to compute performance and allows each function to use the technology best suited to its role, while SDLA manages locality and data movement across the package. This strategy increases the system’s compute FLOPs by 36%, adds 2.5 times HBM bandwidth, and provides 14% more scale-up bandwidth.

Optimized low precision inference, introducing enhanced MXFP4 and sub-3-bit storage formats. Narrower representations reduce memory footprint and data movement, allowing the system to support larger models, longer contexts, and more concurrent sessions within the same power envelope.

Optimized inference kernel through ISA enhancement: The vector engine adds optimizations for key inference kernels, including softmax, low precision data casting, and other operations.

Efficient on-die data movement, Maia 300 changes memory from a uniform organization to a non-uniform (NUMA) one across chiplets. Each compute region has nearby memory, and SDLA’s explicit control over DMA engines, local SRAM, HBM and the network-on-chip places data next to the compute that uses it. Data travels shorter distances, which reduces the energy spent moving it.

Memory hierarchy optimized for bandwidth per watt, combining software-managed on-die SRAM with eight HBM4 stacks providing 288 GB of capacity and 18 TB/s of bandwidth per accelerator. Compared with Maia 200, this delivers 2.5 times the memory bandwidth, 33% more capacity, and approximately 2 times the HBM bandwidth per watt, keeping more model and KV state close to compute.

Maia 300 brings 2.5 times the memory bandwidth, 33% more capacity, and approximately 2 times the HBM bandwidth per watt compared with Maia 200

One scale-up fabric: From pod to superpod

Maia 300 makes the network a native extension of its software-defined dataflow architecture. Maia’s AI network controller implements custom AI transport based on Ethernet. A two-tier network builds a high-performance superpod with up to 12,288 accelerators. Maia presents one communication model to software—the same semantics to move data directly to any accelerator within a superpod.

Half-switched in-rack topologyEach accelerator divides its scale-up connectivity between direct links and switched paths. Direct links connect two accelerators in a tray, while the switched fabric connects all 96 accelerators in the rack to form a pod. All in-rack connectivity uses electrical links to reduce power and cost.

Optical second tier across racksSecond-tier switches connect up to 128 racks together to form a superpod. Optics provide the reach required to extend scale-up network across the pods.

One fabric from the accelerators in a pod to the superpod

One fabric rather than separate scale-up and scale-out domainsIntegrated network controllers and specialized AI transport use the same communication semantics inside the pod and across the superpod. Maia accelerators can directly initiate communication to any accelerator in the superpod, without involving the host or a discrete scale-out NIC.

Low-hop communication pathsThere are three latency domains: A direct connected accelerator pair is the lowest latency domain, then accelerators within a pod are one switch hop away, and any accelerator across pods is three switch hops away. Software can keep latency-sensitive tensor-parallel traffic local within the lowest latency domains.

Bandwidth allocated to the workloadThe bandwidth split between in-rack and cross-rack bandwidth per accelerator is not fixed at the system design time. It becomes a parameter that is set based on job packing. An accelerator can drive up to 750 GB/s to any peer within the superpod, when only a subset of accelerators are going cross-rack. Refer to the spare tray example below.

Flexible job placementTensor parallelism can remain within the 96-accelerator rack, while wider expert and pipeline parallelism span racks. Jobs can use capacity across rack boundaries, reducing stranded accelerators when workload sizes do not align with the physical rack configuration.

A 64-accelerator job can run as four 16-accelerator shards, one in each of four racks

Disaggregated inference within the scale-up domainPrefill and decode workers can be sized and placed independently. After prefill computation completes, KV state moves directly to the selected decode workers over the same scale-up fabric rather than leaving the domain through a separate host-mediated scale-out path.

Resilience across racksWhen accelerators become unavailable, schedulers can use hot-spare capacity in another rack within the superpod transparently to software kernels. The workload remains on the scale-up fabric, trading additional path latency for improved availability and resource utilization.

A spare tray in one rack can offset a failed tray in another rack

Rack-scale architecture for deployment efficiency

At datacenter scale, efficiency is determined by how much useful infrastructure can be deployed and operated within a fixed power and cooling envelope. Building on the foundational energy efficiency of the Maia SoC architecture, the Maia 300 rack co-designs server layout and density, network topology and switching, power and cooling design, and advanced telemetry to deliver up to 2.5x more performance per watt compared to Maia 200.

96 accelerators within 167 kWMaia 300 integrates 96 accelerators across 24 four-accelerator trays within a 167-kW rack, doubling the accelerator density of Maia 200. Each tray incorporates four accelerators with its host processor, memory, storage, and cooling. Eliminating separate host trays frees rack space and allows power and thermal resources to be managed as one system, increasing the inference capacity deployed within each rack.

Consolidated switch architectureSix high-radix switch ASICs are integrated into three liquid-cooled switch trays, providing the rack-local connectivity required by all 96 accelerators while minimizing the space and power consumed by switching.

Rack-level power deliveryDual power feeds, high-capacity power shelves, and a 50 V busbar architecture distribute power efficiently across accelerator and switch trays while providing operational redundancy. The integrated rack automatic transfer switch maintains high availability even when a single power feed is offline for servicing.

Flexible cooling architectureLiquid cooling removes more than 80% of the rack’s thermal load from accelerators, voltage regulators, and switch ASICs, while air cooling supports memory, storage, and other ancillary components. Maia 300 can connect directly to facility water where it is available or use a heat-exchanger unit to reject heat in air-cooled datacenter environments. This provides greater flexibility in where and how the system can be deployed at scale.

Datacenter-integrated telemetryWe have incorporated deployment learnings to strengthen reliability, availability, and serviceability (RAS), observability, debuggability, fault handling, and redundancy, improving robustness as we deploy additional volume. Rack and row level power telemetry connect with datacenter operations, enabling operating points to be managed against available power and cooling capacity. This data informs algorithms that dynamically allocate power and optimize workload placement and deployment density, improving utilization and tokens delivered per watt.

What Maia 300 delivers

Maia 300 is the next step in a multigenerational program to deploy efficient AI systems at scale. The design is optimized end to end across software, silicon, physical rack infrastructure, networking, and datacenters to deliver a leap in performance and efficiency for cloud-scale agentic inference.

Relative to Maia 200, Maia 300 delivers up to 7 times greater rack-scale token throughput in its full 96-accelerator configuration and more than 2.5 times the performance per watt. It brings more memory bandwidth per watt and twice the accelerators per rack, while building on SDLA, our software-defined dataflow architecture and a two-tier scale-up network to support a single programming model spanning kernel to data center scale. Together, these advances enable us to deliver more useful intelligence, more efficiently, to more people and organizations.

Maia 300 delivers up to 7 times greater rack-scale token throughput and more than 2.5 times the performance per watt compared with Maia 200

The opportunity ahead is not simply to build more compute. It is to make advanced AI capabilities more accessible, affordable, and useful. Maia 300 is an important step toward that goal.

Next month at Microsoft Ignite 2026 in San Francisco and online, we’re looking forward to sharing more information on our AI strategy, technology adoption trends, and success in Frontier Transformation.

Read about the latest Azure Maia 300’s news here.

Learn more about Azure Maia 300 here.

Learn more about Azure’s silicon to systems approach here.
The post Deep dive into Azure Maia 300 architecture appeared first on Microsoft Azure Blog.
Quelle: Azure

Advancing hardware security with open-source Integrated HSM technology

At this year’s OCP Global Summit, Microsoft announced Project Tessera, the evolution of the Azure Integrated Hardware Security Module (HSM), into a fully open-source initiative developed in collaboration with Marvell®, Oracle, and Open Compute Project (OCP). Project Tessera advances our broader commitment to open, industrywide standards for platform security.

The motivation behind Project Tessera is straightforward: the entire industry benefits when we collaborate and advance hardware security together.

Project Tessera carries forward the workload directly attached to the HSM architecture introduced by Azure Integrated HSM, making the architecture, specifications, protocols, drivers, software, firmware, and reproducible build environments open source for the broader community. Over time, the initiative will advance toward a fully open-source silicon implementation, while making hardware broadly available, enabling organizations across the ecosystem to adopt, integrate, and contribute to the platform.

Explore the Tessera Integrated HSM GitHub

This approach builds on the model Microsoft established with other industry collaborators on Caliptra, a fully open-source silicon root-of-trust that has since been broadly adopted across the hardware ecosystem. Through Project Tessera, industry leaders including Microsoft, Marvell®, Oracle, and the Open Compute Project will apply that same model of transparency and collaboration to advance hardware key protection with the industry.

The cybersecurity landscape is rapidly changing, and protecting keys and credentials has never been more important. We are now facing two generational transformations that are fundamentally reshaping how we view the cybersecurity landscape:

AI is increasing the speed and scale of cyberattacksAI-orchestrated attacks are increasing the scale, speed, and sophistication of attacks, giving adversaries new ways to operate and compressing the time between vulnerability discovery and exploitation. These capabilities amplify risks such as credential theft, key exfiltration, and signing abuse.Keys and credentials are high-value control assets. When compromised, they can enable attackers to impersonate trusted entities, bypass security controls, authorize malicious operations, expose sensitive data, and undermine software security defenses. Protecting these assets requires infrastructure with layered, hardened protections capable of withstanding sustained attacks across multiple concurrent attack vectors.

Quantum computing is changing the cryptographic risk horizonQuantum computing promises transformative advances, but it also presents a risk to many of today’s cryptographic algorithms. A sufficiently powerful quantum computer could break widely used public-key cryptography, undermining digital signatures, authentication, and identity verification.Post-quantum cryptography was once viewed as an important but distant technology shift. Advances in quantum computing have changed that perspective as organizations recognize the urgency, scale, and complexity of the transition. HSM-backed signing infrastructure will be among the first critical systems to migrate, requiring HSMs that support post-quantum cryptography and are interoperable with classical HSMs to support migration.

These emerging threats motivated the development of Azure Integrated HSM, which was designed to meet rigorous security standards for hardware-based key protection, while also accelerating Microsoft’s transition to post-quantum cryptography through scale deployments of quantum resilient integrated HSMs.

Azure Integrated HSM introduced a workload-attached HSM that performs cryptographic operations closer to the workload while keys remain continuously protected within the HSM security boundary. This architecture strengthens key protection, improves cryptographic performance, offers crypto-agility, and provides a simpler operational model.

Tessera is an evolution of Azure’s first integrated HSM model, incorporating insights gained from deploying Azure Integrated HSM at scale, and advances the technology through collaboration in the Open Compute Project, with the goal of broadly addressing the challenges of key and credential management in the era of AI and quantum computing.

Eliminating key management anti-patterns

In central HSM deployment models, HSM infrastructure is separate from compute resources, requiring cryptographic operations to traverse the network. The resulting latency and operational dependencies can lead enterprises to adopt workarounds that improve performance or availability but unintentionally weaken key protections. Some of these common key-management anti-patterns include:

HSM keys may act as certificate authorities and endorse externally generated keys. These keys can then serve as trusted delegates without receiving the same hardware protection.

HSM generated keys may be created as extractable and exported from the HSM in wrapped form. When used outside of the HSM the keys may not receive assurance levels equivalent to a FIPS 140-3 Level 3 HSM and become more susceptible to exfiltration or misuse.

Other anti-patterns include caching keys outside of HSMs for resilience, using software-held keys to reduce network latency to remote HSMs, sharing keys and security domains to simplify governance, and relying on proprietary protocols for interoperability. These practices intend to prioritize operational flexibility but can make key protection, policy enforcement, and auditable provenance less consistent across environments, undermining the security value HSMs are designed to provide.

The goal of Project Tessera is to advance the integrated HSM model to address these challenges in the industry, without compromising on security. The project will deliver Tessera Integrated HSM, a fully open-source integrated HSM designed to consistently enforce FIPS 140-3 Level 3 key protection throughout the key’s lifecycle.

By combining strong hardware-rooted protection with an open-source implementation and open protocols, Tessera Integrated HSM creates a path toward greater transparency, interoperability, and innovation across the HSM ecosystem. The native support for quantum-resilient cryptography will help ease the industry’s transition to post-quantum cryptography.

Figure 1: Tessera Integrated HSM

Demonstrating an open, interoperable HSM ecosystem

Today at the Open Compute Project Global Summit, Microsoft and Marvell® demonstrated the Tessera Integrated HSM transfer protocols establishing HSM partition cloning and resiliency rings across a Tessera Integrated HSM and a Marvell® LiquidSecurity® 2 HSM. The demonstration showed how two heterogeneous HSMs can operate in a resilient and unified security domain. Non-extractable keys within the security domain always remain protected within the HSMs and are available only to the authorized HSM partitions participating in the security domain and remain under the sole control of the partition owner.

The Tessera Integrated HSM protocols use post-quantum cryptography to protect communication between HSMs. This enables authorized workloads with a Tessera Integrated HSM to use both classical cryptography and post-quantum cryptographic services while their keys remain secured within the HSM boundary and can only be authorized for use by the key owner.

Figure 2: Partition cloning example

The Project Tessera specifications, protocols, software libraries, drivers, firmware, and hardware are available through the Tessera Integrated HSM GitHub. Going forward, this repository will add more open-source silicon, new hardware designs, and enhancements developed with the community.

Expanding Project Tessera through confidential computing

The early collaborators working on Project Tessera within the OCP community are exploring how the Tessera Integrated HSM key protection architecture can extend beyond systems with dedicated integrated HSM hardware. As part of this work, the project is making a minimal, unikernel-based Tessera firmware stack open source, designed to run within hardware-isolated confidential computing environments.

This implementation uses the same firmware stack as the hardware integrated HSM, extending a common security architecture across HSMs and confidential computing environments. In this model, cryptographic keys are protected within a confidential computing container, which provides cryptographic services to securely bound workloads, including worker containers and virtual machines. The initial implementation leverages AMD SEV-SNP and integrates with open-source virtualization technologies such as OpenVMM, with the Open Compute community working to extend support to other confidential computing architectures.

The complementary deployment models in Project Tessera extend strong key protection across systems with different hardware capabilities and assurance requirements. For platforms without dedicated integrated HSM hardware, confidential computing provides broadly deployable, hardware-isolated key protection with a minimal trusted computing base.

Project Tessera provides the highest level of hardware assurance, protecting keys within a dedicated, tamper-resistant security boundary designed to meet demanding certification requirements, including FIPS 140-3 Level 3 and Common Criteria.

Figure 3: Protection profiles for assurance levels

The deployment models share the same Project Tessera firmware and programming model, giving organizations a consistent foundation for cryptographic security across their infrastructure while providing a natural path to integrated HSM and higher levels of assurance in newer systems.

Together, these models make strong key protection accessible across a broad range of systems with different security assurance needs, all built on a common, open architecture. As the Open Compute Project community continues to advance Tessera Integrated HSM, we see an exciting opportunity for broader industry collaboration to strengthen key protection, expand secure key management, and accelerate innovation across the ecosystem.

Explore the Tessera Integrated HSM GitHub

For more information, visit the Microsoft booth at the Open Compute Project Global Summit for live demonstrations, explore Tessera Integrated HSM implementation on GitHub, and read the Microsoft Infrastructure Community blog for additional hardware security announcements: OCP2026 Hardware Security Updates.

Check out Microsoft’s presence at OCP Summit this year: aka.ms/OCP2026

Learn more about Azure Infrastructure: aka.ms/silicontosystems

The post Advancing hardware security with open-source Integrated HSM technology appeared first on Microsoft Azure Blog.
Quelle: Azure