Forschungsbericht · überarbeitet am 09. November 2026
Der Operatorvertrag als überprüfbare Schnittstelle
Der Versuch exportiert ein echtes torch.nn.Linear mit torch.export. Zugelassen ist genau ein aten.linear.default-Operator ohne Bias. Gewichte und Eingaben müssen zusammenhängende endliche BF16-Tensoren sein. Formen, Datentypen und Layouts außerhalb dieses Vertrags werden abgewiesen. Ein stiller CPU-Ersatzpfad ist nicht vorgesehen. Im bestandenen Lauf wird ein Fallbackzähler von null protokolliert.
Dieser enge Vertrag macht die Übersetzung überprüfbar. Eine beliebige PyTorch-Funktion kann viele Operationen und unterschiedliche Rundungen enthalten. Hier lässt sich dagegen für jeden angenommenen Auftrag bestimmen, welche Speicherwörter und FMA-Schritte die Hardware ausführen muss. Die Unterstützung eines Operators wird damit als konkrete Eigenschaft der Software beschrieben und nicht mit der Unterstützung eines vollständigen Sprachmodells gleichgesetzt.
Von Tensoren zu fortlaufenden FP32-Summen
Die Laufzeitsoftware übersetzt den Graphen in den versionierten HAL-Vertrag tile-linear-v1. Sie protokolliert Tensorformen, Byte-Strides, Speicherladungen, geordnete K-Blöcke und synchronisierte Ergebniszugriffe. BF16-Operanden werden in 64-Bit-SRAM-Wörter gepackt. Die Reduktionsdimension K wird in Abschnitte von höchstens 64 zerlegt. Ein Auftrag beginnt mit einer frischen FP32-Summe und setzt diese über alle folgenden Blöcke fort.
Die Ausführung nutzt die vorhandene Vier-Lane-Kachel mit HardFloat-Rechenwerken und festgelegten IHP-SRAM-Modellen. Eine Beobachterschicht erfasst die tatsächlich angenommenen Ergebnislesezugriffe. Sie verändert weder Kachel noch Testbench. Entscheidend ist, dass nicht nur erwartete Softwarewerte ausgegeben werden, sondern die von der RTL-Ausführung zurückgelieferten Wörter und Statusflags.
Zwei Lastfälle prüfen unterschiedliche Fehlerquellen
Der kurze Fall besteht aus zwei Aufträgen mit M = 2, N = 3 und K = 131. Die Aufträge verwenden unterschiedliche Gewichtszeilen und laufen ohne Reset zwischen den Aufträgen. Die ungerade Reduktionslänge erzeugt einen Restblock. So werden Gewichtswechsel, Initialisierung, Speicherzuordnung und die Fortsetzung nach vollständigen Blöcken gemeinsam geprüft.
Der zweite Fall verwendet M = 1, N = 3 und K = 5.120. Drei vollständige Zeilen eines archivierten Qwen-Gate-Gewichtsausschnitts laufen durch 80 Blöcke. Die Aktivierungen werden mit einem festen Seed in CPU-PyTorch erzeugt. Der kurze Lauf enthält 1.572 FMAs, 330 Operanden-Schreibzugriffe und zwölf Ergebnislesezugriffe. Der lange Lauf enthält 15.360 FMAs, 5.120 Operanden-Schreibzugriffe und drei Ergebnislesezugriffe.
Numerische Gleichheit auf mehreren Ebenen
Eine unabhängige Ganzzahlimplementierung der Floating-Point-FMA liefert die Referenz für FP32-Ausgabewörter und Ausnahmeflags. Alle 15 geprüften Ausgaben stimmen in allen drei Ablaufvarianten bitgenau überein. Zusätzlich wird der FP32-Fehler gegenüber einem PyTorch-FP64-Skalarprodukt erfasst. Nach BF16-Rundung stimmen die Ausgaben auch mit der nativen PyTorch-Projektion überein.
Diese Prüfungen beantworten unterschiedliche Fragen. Die Ganzzahlreferenz bestätigt die deklarierte FMA-Reihenfolge. Der PyTorch-Vergleich verbindet den engen Hardwarevertrag mit der ursprünglichen Softwareoperation. Die Übereinstimmung dieser 15 Ausgaben ist kein allgemeiner Qualitätsnachweis für Qwen, für andere Reduktionsreihenfolgen oder für jeden denkbaren Eingabetensor.
Überlappung spart Zufuhrzeit, nicht Rechenarbeit
| Lastfall | Seriell | Feste Überlappung | Bankbewusst |
|---|---|---|---|
| Zwei Aufträge, K = 131 | 1.054 Takte | 868 Takte | 868 Takte |
| Ein Auftrag, K = 5.120 | 12.003 Takte | 7.181 Takte | 6.947 Takte |
Gezählt wird vom ersten gepackten Operanden-Schreibzugriff bis zum letzten Ergebnislesen, mit einem 64-Bit-Schreibplatz pro Takt. Arbeit und SRAM-Transaktionszahl bleiben innerhalb jedes Lastfalls gleich. Überlappung verschiebt Transfers in Rechenphasen. Die bankbewusste Auswahl verbessert den langen Lauf um 3,26 % gegenüber der bereits überlappenden Referenz. Der größere Abstand zur seriellen Variante ist deshalb nicht die maßgebliche Aussage über den zusätzlichen Optimierungsschritt.
Die Rechenphase benötigt unverändert 6.880 Takte. Gegenüber 7.181 Takten fester Überlappung könnte selbst eine vollständig verdeckte übrige Zufuhr höchstens 4,19 % einsparen. Für 10 % müssten zusätzlich mindestens 418 Kerntakte entfallen. Diese Schranke erklärt, warum allein ein weiterer Zufuhrplan den gewählten Leistungsabstand nicht erreichen kann.
Ein funktionierender Softwarepfad mit definierter Messgrenze
Für den langen Lauf ergibt dieselbe gezählte SRAM-Arbeit in allen Varianten einen modellierten internen Taktbogenanteil von 1,304 µJ bei 1,20 V und 25 °C. Dieser Wert umfasst weder Rechenlogik noch vollständige SRAM-Aktivität, Leitungen, Taktbaum, Leckstrom oder Host. Aus gleichen Teilenergien folgt daher keine gleiche Gesamtenergie.
Der nachgewiesene Fortschritt ist die geschlossene Funktionskette vom exportierten Operator bis zu überprüften RTL-Ausgaben. Die protokollierte Laufzeit des Simulators auf dem Host ist von den Kachelport-Takten getrennt. Physische Taktgrenzen, externe Speicheranbindung und weitere Modelloperatoren benötigen eigene Nachweise. Der vorhandene Vertrag und seine Ablehnungstests bilden eine belastbare Grundlage, um solche Erweiterungen kontrolliert hinzuzufügen.
Konsequenz für den nächsten Entwurf
Den durchgängigen Softwarepfad für die unterstützten Linear-Operatoren in der Forschungsplattform weiterverwenden.