Mehr Rechenleistung pro Watt gilt als Antwort auf die Kostenfrage der künstlichen Intelligenz. Die Architektur von Azure Maia 300 setzt den größten Hebel woanders an: nicht im Rechnen selbst, sondern im Weglassen von Wegen. Wer die Azure Maia 300 System-on-Chip Architektur durchgeht, stößt auf eine Verschiebung, die sich durch alle Ebenen zieht, vom einzelnen Die über das Rack bis zur Halle. Daten zu bewegen kostet Energie. Wer diese Bewegung reduziert, gewinnt oft mehr als jemand, der nur schneller rechnet. Das ist der Ansatz im dritten Anlauf von Microsofts eigenem KI-Beschleuniger.
Am einfachsten versteht man das über eine Analogie aus der Logistik. Ein Lagerhaus wird nicht dadurch besser, dass man schneller kommissioniert, sondern dadurch, dass man die Wege zwischen Regal und Verpackung verkürzt. Wer jeden Artikel quer durch die Halle fährt, bezahlt am Ende für den Transport und nicht für die Ware. In einem KI-System ist es dasselbe: Jedes Byte, das über einen langen Draht oder durch den falschen Speicher wandert, kostet Strom, ohne einen nützlichen Token zu erzeugen. Die Maia-300-Architektur lässt sich als Versuch lesen, die Wege im Lager so kurz wie möglich zu halten.
Software Defined Locally Accessed Dataflow Architecture: ein Fahrplan statt geratener Caches
Mit Maia 200 hat Microsoft eine Architekturklasse eingeführt, die den sperrigen Namen Software Defined Locally Accessed Dataflow Architecture trägt, kurz SDLA. Der Ausgangspunkt ist eine unscheinbare Beobachtung: Das Speichern, Bewegen und Umwandeln von Daten gehört zu den zentralen Problemen moderner KI-Systeme. SDLA trennt deshalb den Kontrollpfad von der Ausführung des Datenpfads. Software legt explizit fest, wo Daten liegen, wann sie sich bewegen, in welches Zahlenformat sie überführt werden und wann synchronisiert wird, und zwar über lokale Speicher, DMA-Einheiten, Rechenkerne und das Netzwerk hinweg.
Der Unterschied zu klassischen Beschleunigern liegt in der Zuständigkeit. Dort rät die Hardware über Caches, welche Daten wohl als Nächstes gebraucht werden, und der Compiler hofft, dass die Vermutung stimmt. Bei SDLA entscheidet der Compiler, und die Hardware führt aus. Für die LLM-Inferenz ist das relevant, weil dort nicht ein einmaliger Durchlauf dominiert, sondern eine lange Kette von Decode-Schritten, in denen dieselben Gewichte immer wieder auf neue Zwischenstände treffen. Ein Fahrplan, der diese Wiederholungen kennt, ist billiger als eine Hardware, die sie jedes Mal neu errät.
Chiplets, NUMA und schmale Zahlenformate im System-on-Chip
Maia 300 ist kein monolithischer Chip mehr. Die Rechenregionen sitzen auf Dies im TSMC-N2P-Verfahren, wo der Fertigungsprozess den größten Performance-pro-Watt-Vorteil verspricht, während Speichercontroller und I/O auf separaten Dies untergebracht sind, die auf Bandbreite, Anbindung und Kosten optimiert wurden. Die teure Fläche steckt damit dort, wo tatsächlich gerechnet wird, und jede Funktion bekommt die Technologie, die zu ihrer Rolle passt. Microsoft beziffert den Effekt mit 36 Prozent mehr Rechen-FLOPs, der 2,5-fachen HBM-Bandbreite und 14 Prozent mehr Scale-up-Bandbreite gegenüber dem Vorgänger.
Wichtiger als die Zahlen ist, was mit dem Speicher passiert. Maia 200 war im System-on-Chip uniform organisiert, jeder Rechenkern sah den Speicher mit denselben Zugriffszeiten. Maia 300 wechselt auf eine nicht-uniforme Organisation über die Chiplets, bei der jede Rechenregion ihren nahen Speicher hat. Software kann Daten dorthin legen, wo sie gebraucht werden, statt sie quer über den Chip zu ziehen. Das ist der Lagergedanke in Silizium gegossen: kurze Wege statt schnellerer Stapler.
Dazu kommt die zweite Sparmaßnahme, das Format. Maia 300 führt verbesserte MXFP4-Formate und Speicherformate unter drei Bit ein, jeweils mit hardwarebeschleunigter Typkonvertierung. Je schmaler die Darstellung, desto weniger Bytes müssen für jeden Token durch den Chip wandern, und desto mehr Modell, Kontext und gleichzeitige Sitzungen passen in dasselbe Energiebudget. Die Vektoreinheit wurde außerdem auf typische Inferenzkerne zugeschnitten, etwa Softmax und das Herunterbrechen in niedrige Genauigkeiten. Energieeffiziente KI entsteht hier also nicht durch einen einzelnen Trick, sondern durch viele kleine Einsparungen an derselben Stelle.
Speicherhierarchie: 288 Gigabyte und 18 Terabyte pro Sekunde
Die Speicherschicht entscheidet, ob ein Beschleuniger im Betrieb schnell ist oder nur auf dem Datenblatt. Maia 300 kombiniert softwareverwalteten SRAM auf dem Die mit acht HBM4-Stapeln, die pro Beschleuniger 288 Gigabyte Kapazität und 18 Terabyte pro Sekunde liefern. Im Vergleich zu Maia 200 sind das die 2,5-fache Bandbreite und 33 Prozent mehr Kapazität, bei ungefähr doppelter HBM-Bandbreite pro Watt. Der KV-Cache eines langen Dialogs bleibt damit näher an der Recheneinheit, die ihn tatsächlich braucht.
Für agentische Workloads ist das kein Detail. Wenn ein Modell mehrere Schritte plant, Werkzeuge aufruft und dabei einen langen Kontext mit sich führt, wächst der Speicherbedarf pro Anfrage deutlich. Wer dann Bandbreite spart, spart an der falschen Stelle. Die Rechnung von Microsoft lautet entsprechend: nutzbare Token pro Watt und nutzbare Token pro Dollar, nicht FLOPs im Leerlauf. Ein Beschleuniger, der Rechenleistung bereitstellt, aber auf Daten wartet, erzeugt keine Token und damit auch keinen Wert.
Ein Fabric vom Pod zum Superpod
Netzwerke gelten in der KI-Hardware traditionell als Zubehör: oben drauf, wenn die Rechenknoten erst einmal stehen. Maia 300 behandelt sie als Verlängerung der Datenflussarchitektur. Ein eigener Netzwerkcontroller übernimmt einen maßgeschneiderten Transport auf Ethernet-Basis, und eine zweistufige Topologie verbindet bis zu 12.288 Beschleuniger zu einem Superpod. Entscheidend ist, dass Software nur ein Kommunikationsmodell sieht, mit denselben Semantiken innerhalb des Pods und über Racks hinweg.
Innerhalb eines Racks ist die Topologie halbvermittelt. Direkte Verbindungen koppeln jeweils zwei Beschleuniger in einem Tray, das vermittelte Fabric erschließt alle 96 Beschleuniger des Racks. Alle Verbindungen im Rack laufen elektrisch, was Strom und Kosten senkt. Die zweite Stufe über Racks hinweg nutzt Optik, weil nur Licht die nötige Reichweite für einen Superpod aus bis zu 128 Racks bringt. Drei Latenzdomänen entstehen so: das direkt verbundene Paar, ein Switch-Hop innerhalb des Pods, drei Hops über Pod-Grenzen.
Auch die Bandbreitenzuteilung ist ungewöhnlich. Wie viel pro Beschleuniger in das Rack und wie viel über Racks geht, ist nicht fest verdrahtet, sondern folgt der Jobplatzierung. Ein Beschleuniger kann bis zu 750 Gigabyte pro Sekunde zu einem beliebigen Partner im Superpod treiben, solange nur ein Teil der Beschleuniger rackübergreifend kommuniziert. Ein 64-Beschleuniger-Job läuft entsprechend als vier Shards zu je 16 Beschleunigern in vier Racks, während Tensor-Parallelität im niedrigsten Latenzbereich bleibt. Fällt ein Tray aus, kann ein Hot Spare aus einem anderen Rack einspringen, ohne dass der Kernel davon erfährt.
Auch die Trennung von Prefill und Decode wird räumlich: Beide Rollen lassen sich unabhängig dimensionieren, und der KV-Zustand wandert nach dem Prefill direkt über dasselbe Fabric zum ausgewählten Decode-Worker, statt über den Host und eine separate Scale-out-Karte zu laufen. Ein einziges Fabric statt zweier getrennter Welten bedeutet weniger Kopien, weniger Hops und weniger Verwaltungsaufwand.
96 Beschleuniger in 167 Kilowatt: Rack-Architektur als Effizienzfrage
Auf Rackebene wird sichtbar, wo die Rechnung tatsächlich geschrieben wird. Maia 300 packt 96 Beschleuniger in 24 Tray-Einheiten zu je vier Beschleunigern, dazu Host-Prozessor, Speicher, Storage und Kühlung, alles in einem Rack mit 167 Kilowatt. Damit verdoppelt sich die Beschleunigerdichte gegenüber Maia 200. Weil separate Host-Trays entfallen, lassen sich Strom und Kühlung als ein System bewirtschaften statt als Sammlung von Einzelteilen.
Sechs hochradige Switch-ASICs sitzen in drei flüssiggekühlten Switch-Trays und versorgen alle 96 Beschleuniger. Die Stromverteilung läuft über zwei Einspeisungen, leistungsfähige Power Shelves und eine 50-Volt-Busbar, ergänzt um ein integriertes Transfer-Switch, das den Betrieb auch bei Wartung einer Einspeisung aufrechterhält. Flüssigkühlung nimmt mehr als 80 Prozent der Wärmelast von Beschleunigern, Spannungsreglern und Switches ab, während Luft die Speicher- und Storage-Komponenten kühlt. Wo kein Facility-Wasser verfügbar ist, übernimmt ein Wärmetauscher die Abfuhr.
Dazu kommt Telemetrie bis auf Rack- und Reihenebene, die mit dem Rechenzentrumsbetrieb gekoppelt ist. Betreiber können Arbeitspunkte gegen die real verfügbare Strom- und Kühlleistung fahren und Placement-Algorithmen mit Messwerten füttern. Das klingt nach Betriebsdetail, ist aber Teil der Architektur: Azure KI-Hardware wird erst dann effizient, wenn die Auslastung über die gesamte Halle gesteuert wird und nicht nur pro Karte.
Was die Zahlen bedeuten und was offen bleibt
Microsoft nennt für Maia 300 das bis zu Siebenfache an Token-Durchsatz auf Rackebene gegenüber Maia 200, in der vollen Konfiguration mit 96 Beschleunigern, dazu mehr als das 2,5-Fache an Leistung pro Watt. Die Größen sind nachvollziehbar begründet: mehr Beschleuniger pro Rack, mehr Bandbreite pro Watt, kürzere Datenwege, ein durchgängiges Fabric. Es handelt sich aber um Herstellerangaben aus einem Technikbeitrag, nicht um unabhängig nachgemessene Werte. Wer Azure Maia 300 einschätzen will, sollte diese Zahlen als Designziele lesen und nicht als Messergebnisse.
Interessanter als die Spitzenwerte ist die Richtung, die die Architektur vorgibt. Ein KI-Beschleuniger für agentische Inference muss heute weniger ein Rechenmonster sein als ein gut organisierter Logistiker: Speicher nah an der Recheneinheit, schmale Formate, ein Netzwerk ohne Umwege und ein Rack, das in das Strombudget einer Halle passt. Wer diese vier Punkte zusammendenkt, bekommt energieeffiziente LLM-Inferenz für Cloud-Scale, die sich nicht über höhere Leistungsaufnahme finanziert, sondern über geringeren Verschleiß an Datenwegen. Die Azure Maia 300 Architektur erklärt sich daraus, wie konsequent sie diese Wege verkürzt.
Für dich als Betreiber oder Entwickler heißt das konkret: Die interessanten Fragen verschieben sich. Nicht mehr die Zahl der TFLOPS entscheidet, sondern wie gut ein Modell auf die Speicher- und Netzwerktopologie passt, wie viel Kontext pro Sitzung realistisch bleibt und wie transparent Werkzeuge wie Microsoft Foundry Latenz und Kosten abbilden. Das ist eine unbequeme Verschiebung, weil sie nicht mit einer einzelnen Kennzahl zu erledigen ist. Wer Token pro Watt ernst nimmt, stellt aber andere Fragen als jemand, der nur nach Rechenleistung schaut.
Quelle: azure.microsoft.com
