Forschungsbericht · überarbeitet am 09. November 2026
Das Arbeitsinventar vor der Bauteilauswahl
Ausgangspunkt ist das archivierte Qwen-Inventar für Batch 1 mit 8.192 Eingabetokens und 256 Ausgabetokens. Die gespeicherten Gewichte umfassen 53.791.996.928 Byte, die erfassten Zustände 708.509.696 Byte. Mit zusätzlich angenommenen 4 GiB Scratch ergibt sich vor einer Kapazitätsreserve ein Bedarf von etwa 54,758 GiB. Diese Größen beschreiben gespeicherte Daten und nicht den kumulierten Zugriffsumfang.
Für 255 weitere Decode-Schritte zählt dieselbe Abbildung rund 13,069 TB Gewichtslesen. Ein Speicher kann das Modell also vollständig aufnehmen und trotzdem zu langsam liefern. Der Versuch ersetzt pauschale Auslastungsfaktoren durch native Kanalmodelle. Eine grundlegende zusätzliche Frage bleibt, ob Rechenwerk und lokale Verbindungen die gelieferten Daten anschließend tatsächlich verarbeiten können.
Ein ausgeführter DRAM-Simulator als Messinstrument
Ramulator 2 wird als nativer C++-Simulator mit integriertem Ayna-Energiemodell ausgeführt. Ein erster Satz umfasst 23 Speicherprofil- und Kontrollfälle, ein zweiter 28 Fälle mit unterschiedlichen Reihenfolgen, Queues und Trace-Längen. Die Quellstände, Abhängigkeiten und Rohdaten sind festgelegt und archiviert. Alle ausgegebenen Reads werden bis zur tatsächlichen Rückmeldung verfolgt.
Die Läufe bestehen 56 upstream Prüfungen. Eine separate Prüfung gegen eine zusätzlich installierte Original-Ayna-Binärdatei ist mangels dieser Datei übersprungen. Deshalb wird kein vollständiger unabhängiger Vergleich zweier Energieimplementierungen behauptet. 216 innere Artefakte und beide Ergebnisarchiv-Hashes sind geprüft. Die Hostlaufzeiten von 48,14 beziehungsweise 78,69 Sekunden beschreiben die Ausführung des Analysewerkzeugs, nicht die spätere Antwortzeit eines Chips.
Bankparallelität verändert die tatsächlich bediente Rate
Der Profilvergleich verwendet je einen Kanal, 65.536 abgeschlossene Reads, offene Zeilen, All-Bank-Refresh und denselben FRFCFS-RowHit-Scheduler. Innerhalb eines Profils bleibt die Adressmenge gleich. Geändert wird, ob Zugriffe bankweise gebündelt oder über die verfügbaren Bänke verteilt werden.
| Simulatorprofil | Bankweise | Verteilt, Queue 128 |
|---|---|---|
| DDR5-6400 | 11,271 GB/s | 23,493 GB/s |
| LPDDR5-6400 | 5,487 GB/s | 11,804 GB/s |
| GDDR7-28000 PAM3 | 10,369 GB/s | 24,414 GB/s |
| HBM3-6400 | 8,851 GB/s | 45,867 GB/s |
| HBM4-8000 | 8,506 GB/s | 44,275 GB/s |
Die verteilte Reihenfolge nutzt vorhandene Bankparallelität besser. Das ist kein neu erfundener Mechanismus und kein Vergleichssieg gegen einen optimierten GPU-Controller. Die HBM4-Zahl gilt für dieses konkrete Profil samt Controller. Sie ist keine allgemeine Leistungsangabe aller am Markt verfügbaren HBM4-Bausteine.
Kleine Optimierungen müssen längere Kontrollen bestehen
Die zweite Serie variiert 2, 4, 8, 16, 32, 64 und 128 aufeinanderfolgende Zugriffe je Bank sowie 128 oder 512 Request-Plätze. Der Kandidat burst-8 mit Queue 128 verbessert den kurzen Test gegenüber der bereits verteilten Referenz um 1,21 %. Bei viermal längerer Trace bleiben nur 0,143 % mehr Durchsatz. burst-32 ist in diesem langen Vergleich langsamer.
Für weitere Ressourcenrechnungen wird vorsichtig die kleinere burst-8-Bandbreite beider Trace-Längen verwendet, 44,357 GB/s pro Kanal. Eine Hochrechnung auf 32 gleichzeitig unabhängige Kanäle wäre eine zusätzliche Annahme. Sie ist in diesem Einzelkanalversuch noch nicht bestätigt. Auch Queue 512 benötigt zusätzliche Controllerhardware, deren Fläche und Energie nicht dadurch nachgewiesen werden, dass der Simulator mehr Plätze zulässt.
Speicherenergie und Gesamtenergie sauber verbinden
Ayna modelliert Speicherbausteinenergie einschließlich I/O und Refresh. Für HBM4 sind Teile der Stromparameter extrapoliert. Reale Qwen-Gewichtstoggles oder ein physischer HBM4-Chip wurden nicht gemessen. Im burst-8-Kurztest ergeben gesetzte Aktivitätsannahmen von 0, 0,5 und 1 etwa 3,403, 4,899 und 6,394 pJ je gelesenem Bit. Im längeren 0,5-Test sind es 4,915 pJ/Bit.
Diese Unterschiede sind eine Sensitivität auf Eingangsannahmen und keine statistischen Fehlerbalken. Die Grundlast während des Lesens ist enthalten. Zusätzliche Warteenergie wird separat aus einem Leerlauftest abgeleitet. Rechenwerke, Zustandsschreiben, Controlleranteile außerhalb der Modellgrenze, Spannungswandler und Kühlung sind damit noch nicht bilanziert. Die kleine Reihenfolgeänderung begründet auch energetisch keinen großen Architekturabstand.
Warum der gekoppelte Folgetest die frühe Prognose korrigiert
Eine ursprüngliche Teilrechnung kombinierte fünf angenommene HBM4-Stapel mit GPU-Prefill als Zeitanker und kam auf 4,536 Sekunden. Der Aktivierungsverkehr wurde dabei nur beim Decode vollständig angesetzt. Die spätere gekoppelte Prüfung zeigte für die konkrete nicht zusammengefasste Abbildung bereits mindestens 28,671 Sekunden Prefill-Aktivierungszeit bei 6,4 GB/s. Die frühere Zahl und ihre rund 609 J Speicherteilenergie sind daher keine aktuelle Chipprognose.
Der bleibende Ertrag dieser Untersuchung ist die überprüfbare Kanalcharakterisierung und eine begründete Auswahl weiterer Tests. Mehr Kapazität, mehr nominelle Bandbreite und eine günstigere Reihenfolge reichen einzeln nicht aus. Deshalb folgt als nächstes der bereits ausgeführte gemeinsame Ablauf mit mehreren Controllern, endlichen Antwortpuffern und Rechenabhängigkeiten. Erst er zeigt, welcher Anteil der Speicherleistung unter einer konkreten Operatorlast tatsächlich genutzt wird.
Konsequenz für den nächsten Entwurf
Kapazität, gleichzeitig nutzbare Bandbreite und lokale Ports gemeinsam prüfen.