Untersucht wird die Gate-Projektion der ersten MLP-Schicht des archivierten Qwen-Checkpoints. Ihre Matrix besitzt 17.408 Ausgabezeilen und 5.120 Eingabespalten. Die 89.128.960 BF16-Werte belegen unkomprimiert 178.257.920 Byte. Tensorherkunft und Inhalt sind über eine festgelegte Checkpointrevision und eine SHA256-Prüfsumme identifiziert. Damit vergleichen die Implementierungen dieselben Modellgewichte und nicht unterschiedlich günstige Zufallsmatrizen.
Die Aufgabe lautet Y = X · Wᵀ für Batchgrößen 1 und 8. Vergleichsgröße ist jeweils eine vollständige Batchprojektion. Acht Eingabevektoren sind deshalb nicht mit der Laufzeit eines einzelnen Vektors zu verwechseln. Der Versuch erzeugt keine Sprachmodellantworten. Er isoliert einen häufigen linearen Baustein, dessen Optimierung sich anschließend als stärkere Softwarebasis verwenden lässt.
" }, { "heading": "cuBLAS und eigener Triton-Kern unter gleichen Bedingungen", "html": "Die Ausführung verwendet eine NVIDIA RTX PRO 6000 Blackwell Server Edition mit PyTorch 2.8.0, CUDA 12.8 und Triton 3.4. Der eigene unkomprimierte Triton-Kern wird mit der in diesem Versuch verwendeten cuBLAS-Ausführung verglichen. Die Kernelkonfigurationen wurden zunächst auf getrennten synthetischen Gewichten eingestellt und danach für den echten Tensor festgehalten. Dadurch wird nicht nachträglich die günstigste Konfiguration für jede Messrunde ausgewählt.
Alle Methoden verwenden CUDA-Graph-Blöcke und dieselbe BF16-Darstellung. TF32 und reduzierte BF16-Reduktionspräzision sind in der archivierten Umgebung deaktiviert. Die Ausgaben werden mit einer FP32-Referenz aus unveränderten BF16-Eingaben abgeglichen. Unterschiedliche Summationsreihenfolgen sind innerhalb der vorher festgelegten Genauigkeitsgrenzen zulässig. Es handelt sich daher nicht um den streng bitidentischen FMA-Vertrag der späteren RTL-Versuche.
" }, { "heading": "Cachezustand und Wiederholungen getrennt betrachten", "html": "Jede Variante läuft sowohl mit wiederverwendeter Matrix als auch mit fünf rotierenden physischen Matrixkopien. Im Rotationsfall überschreitet der Arbeitsbestand bei beiden untersuchten Darstellungen das Vierfache des gemeldeten 128-MiB-L2-Caches. Das reduziert die Abhängigkeit von einer einzigen dauerhaft warmen Matrix. Tatsächliche Cache-Misses wurden jedoch nicht mit Hardwarezählern profiliert, weshalb die Rotation nicht als garantierter cachefreier Betrieb bezeichnet wird.
Drei getrennte Eingabeseeds liefern drei Messrunden je Bedingung. Berichtet wird der Median dieser Runden. Die gespeicherten p05/p95-Bereiche beschreiben die zeitlichen Blockstichproben innerhalb der Ausführung. Sie sind keine Konfidenzintervalle für alle Geräte, Systemzustände oder Anwendungslasten. Eine weitere erfolgreiche Cloud-Ausführung prüft die Wiederholbarkeit des zentralen Befunds.
" }, { "heading": "Gemessene Operatorzeiten und Energie", "html": "| Erste Ausführung | cuBLAS | Triton |
|---|---|---|
| Batch 1, Rotation | 121,16 µs | 117,61 µs |
| Batch 8, Wiederverwendung | 133,15 µs | 119,86 µs |
| Batch 8, Rotation | 134,10 µs | 120,07 µs |
| GPU-Boardenergie, Batch 8, Rotation | 47,24 mJ | 41,40 mJ |
Im Batch-8-Rotationsfall entsprechen die ungerundeten Werte 10,47 % kürzerer Operatorzeit und 12,36 % weniger GPU-Boardenergie. Die Zeitbereiche der drei Runden bleiben getrennt, der Gewinn überschreitet jeweils die festgelegte 5-%-Schwelle. Bei Batch 1 ist der Zeitgewinn kleiner und erreicht diese Schwelle nicht.
Die zweite erfolgreiche Ausführung liefert für denselben Batch-8-Fall 134,05 gegenüber 120,08 µs sowie 47,61 gegenüber 39,89 mJ. Der Zeitbefund wiederholt sich mit 10,42 %. Die unterschiedliche Energieersparnis von 16,20 % zeigt zugleich, weshalb einzelne Energiefenster nicht als unveränderliche Eigenschaft eines Kernels behandelt werden dürfen.
" }, { "heading": "Was der Energiezähler tatsächlich umfasst", "html": "Die Energie stammt aus mindestens zwei Sekunden langen NVML-Zählerfenstern. Wiederholte Projektionen werden gemeinsam gemessen und auf die ausgeführte Arbeit bezogen. Enthalten ist die GPU-Boardaufnahme einschließlich der im Fenster anfallenden Grundaufnahme. Die Werte sind keine reine Energie der Multiplikationen und keine Messung des gesamten Servers.
CPU, Hauptspeicher, Spannungsversorgung außerhalb des Boards und Kühlung sind nicht Teil dieser Grenze. Die Energie eines simulierten Kachelblocks kann daher nicht unmittelbar neben diese Millijoulewerte gestellt und als Effizienzvergleich gelesen werden. Für einen solchen Vergleich wären vollständige Arbeitsumfänge und übereinstimmende Energiegrenzen nötig.
" }, { "heading": "Welche Referenz der Befund verbessert", "html": "Der unkomprimierte Kern ist für diese Projektion die stärkere der getesteten Implementierungen und wird als weitere Operatorreferenz gesichert. Das ist ein konkret gemessener Softwaregewinn auf vorhandener Hardware. cuBLAS bezeichnet eine Bibliothek für lineare Algebra und keine universelle Obergrenze aller GPU-Implementierungen.
Eine vollständige Modellreferenz müsste zusätzlich Fusionen, Laufzeitsoftware, Aufmerksamkeit, Speicherverwaltung und Ausgabeprozess einbeziehen. Auch weitere Geräte und optimierte Modellserver fehlen in diesem Versuch. Der wissenschaftliche Nutzen liegt deshalb in einer klar abgegrenzten positiven Kontrolle: Ein Kandidat, der diese bereits schnellere Implementierung nicht erreicht, kann nicht allein durch einen Vergleich mit der langsameren Bibliothekskonfiguration überzeugen.
" } ] }, { "id": "verlustlose-gewichte", "topic": "Speicher", "level": "GPU-Messung", "status": "Nicht weiterverfolgt", "title": "Wann beschleunigen verlustlos komprimierte Gewichte eine Projektion?", "result": "23,50 % weniger Speicher", "paragraphs": [ "Eine verlustlose Blockdarstellung nutzt Exponentbereiche der BF16-Gewichte. Vorzeichen und Mantisse bleiben erhalten; ungeeignete Blöcke weichen auf das ursprüngliche Format aus. Header und Offsets werden mitgezählt.", "Die vollständige getestete Matrix benötigt 136.369.536 statt 178.257.920 Byte. Alle 89.128.960 Werte wurden bitgenau wiederhergestellt. Das ist eine Speicherersparnis ohne veränderte gespeicherte Werte.", "Der erste kombinierte GPU-Dekodier- und Rechenkern benötigt jedoch 325,94 bis 718,86 Mikrosekunden, gegenüber rund 118 bis 120 Mikrosekunden für den passenden unkomprimierten Kern. Auch die Boardenergie fällt höher aus. Der Dekodieraufwand kann die Byteersparnis überkompensieren." ], "boundary": "Die Ablehnung betrifft die geprüften Implementierungen. Ein spezieller Hardwaredekoder wäre eine neue, separat zu prüfende Hypothese.", "decision": "Die verlustlose Darstellung dokumentieren. Den getesteten GPU-Dekodierpfad wegen seines höheren Zeit- und Energiebedarfs aussortieren.", "source": "AR-002 Originalbericht", "source_sha256": "09cc47709167b33a7ff47181f071be19081cbcf7b12913c0b1b75ad0730464fc", "abstract": "Verlustlose Kompression kann den Gewichtsspeicher verkleinern, ohne gespeicherte Werte zu verändern. Ob daraus kürzere Rechenzeit entsteht, hängt vom Dekoder ab. Wir vergleichen die vollständige Darstellung einer realen Qwen-Matrix mit zwei tatsächlich ausgeführten GPU-Dekodierpfaden.", "sections": [ { "heading": "Speicher sparen, ohne die Gewichte zu quantisieren", "html": "Die untersuchte Matrix ist die Gate-Projektion der ersten MLP-Schicht aus dem gepinnten Qwen-Checkpoint. Sie enthält 17.408 mal 5.120 BF16-Werte. Das sind 89.128.960 Werte und unkomprimiert 178.257.920 Byte. Der Versuch verwendet diese vollständige reale Matrix, keine künstlich besonders gut komprimierbaren Koeffizienten.
Die Hypothese ist einfach: Wenn weniger Gewichtsbytes aus dem Speicher gelesen werden müssen, könnte eine bandbreitenbegrenzte Projektion schneller und energieärmer werden. Anders als bei verlustbehafteter Quantisierung soll jeder BF16-Wert bitgenau rekonstruierbar bleiben. Dafür müssen jedoch Nutzdaten, Metadaten und Dekodierarbeit vollständig in die Vergleichsgrenze aufgenommen werden. Eine kleinere Datei allein beantwortet die Geschwindigkeitsfrage nicht.
" }, { "heading": "Das Blockformat nutzt gemeinsame Exponentenbereiche", "html": "Je 256 Werte bilden einen Block. Wenn dessen Exponentenspanne höchstens 15 beträgt, genügt für jeden Exponenten ein 4-Bit-Abstand zum gemeinsamen Bezug. Vorzeichen und Mantisse bleiben unverändert. Ein ungeeigneter Block fällt auf die ursprüngliche 16-Bit-Darstellung zurück. Damit erhält die Darstellung einen klar definierten Ausreißerpfad und muss problematische Werte nicht nachträglich verändern.
Die vollständige GPU-Darstellung zählt zwei Byte Blockheader und vier Byte Offset je Block mit. Von 348.160 Blöcken lassen sich 343.573 komprimieren. Die gemischten Nutzdaten belegen 134.280.576 Byte, Header und Offsets weitere 2.088.960 Byte. Insgesamt entstehen 136.369.536 Byte oder durchschnittlich 12,2402 Bit pro Gewicht. Wenige feste globale Containerfelder sind in dieser GPU-Darstellung nicht enthalten.
" }, { "heading": "Was die Bitprüfung beweist", "html": "Alle 89.128.960 BF16-Bitmuster werden nach dem Packen exakt wiederhergestellt. Damit sind die gespeicherten Werte unverändert und der Gewichtsspeicher sinkt um 23,50 %. Diese Aussage benötigt keine angenommene Toleranz für einen Quantisierungsfehler. Die Vollständigkeit der Prüfung ist wichtig, weil eine Stichprobe seltene Rückfallblöcke oder fehlerhafte Offsets übersehen könnte.
Die anschließenden Matrixrechnungen werden gegen FP32 mit denselben BF16-Eingangswerten geprüft. Zugelassene Unterschiede durch die Summationsreihenfolge sind im Versuchsvertrag getrennt festgelegt. Der Test belegt keine ganze Sprachmodellantwort. Er trennt die verlustlose Speicherung von der numerischen und zeitlichen Ausführung des Operators.
" }, { "heading": "Ein GPU-Vergleich mit passenden Kontrollen", "html": "Die Messung läuft auf einer RTX PRO 6000 Blackwell Server Edition mit PyTorch 2.8.0 und Triton 3.4. Untersucht werden Batch 1 und Batch 8, jeweils mit drei Eingabeseeds. Die Konfigurationen wurden zuvor auf getrennten synthetischen Gewichten eingestellt und danach auf der echten Matrix festgehalten. CUDA-Graph-Blöcke reduzieren den Einfluss wiederholter Hoststarts.
Neben Wiederverwendung wird eine Rotation über fünf physische Gewichtskopien gemessen. Beide Speicherformate überschreiten dabei gemeinsam viermal die gemeldete L2-Kapazität. Das erschwert einen Vergleich ausschließlich aus dem Cache, ersetzt aber keine Messung der tatsächlichen Cache-Misses. Kontrollen sind cuBLAS und ein eigener unkomprimierter Kern auf derselben Matrix. Energie stammt aus mindestens zwei Sekunden langen NVML-Zählerfenstern einschließlich GPU-Grundaufnahme.
" }, { "heading": "Zwei Dekoder sparen Bytes, verfehlen aber das Leistungsziel", "html": "Der erste kombinierte Dekodier- und Rechenkern benötigt je nach geprüftem Fall 325,94 bis 718,86 µs. Der passende unkomprimierte Kern liegt bei etwa 117,61 bis 120,07 µs. Auch die gemessene GPU-Boardenergie steigt. Eine zweite Implementierung lädt Metadaten blockweise und dekodiert Wertepaare gemeinsam. Ihre vollständige Bitprüfung besteht ebenfalls.
Im separat ausgeführten Batch-8-Rotationsfall benötigt der verbesserte Dekoder 456,85 µs und 147,95 mJ Boardenergie. Der unkomprimierte Kern benötigt 120,08 µs und 39,89 mJ, cuBLAS 134,05 µs und 47,61 mJ. Die zweite Umsetzung verbessert den ersten komprimierten Pfad, bleibt jedoch ungefähr 3,8-mal langsamer als der passende unkomprimierte Kern. Host, Netz und Kühlung sind nicht Teil dieser Energiegrenze.
" }, { "heading": "Was von der Hypothese übrig bleibt", "html": "Die Speicherersparnis ist nachgewiesen. Der Geschwindigkeits- und Energiegewinn der getesteten GPU-Dekodierung ist widerlegt. In einem ideal ausschließlich durch Gewichtsbytes begrenzten Fall entspräche die Reduktion rechnerisch nur etwa dem Faktor 1,31. Dekoderarbeit und andere Kosten verringern diesen Spielraum. Eine kleinere Darstellung trägt deshalb allein kein mehrfaches Systembeschleunigungsversprechen.
Ein spezieller Hardwaredekoder am Speicherausgang wäre eine neue Hypothese. Er müsste Metadatenzugriffe, Rückfallblöcke, Portbreite, Register, Timing und Energie gegen Raw-BF16 ausweisen. Bekannte verlustlose Kompressionsansätze gehören dabei zu den Referenzen. Die geprüfte GPU-Richtung wird vorerst beendet, während Format, Bitprüfung und negative Laufzeitergebnisse als reproduzierbarer Befund erhalten bleiben.
" } ] }, { "id": "quanten-adapter", "topic": "Quanten", "level": "Training im Simulator", "status": "Nicht weiterverfolgt", "title": "Kann ein lernbarer Quantenadapter eine klassische LoRA-Anpassung übertreffen?", "result": "LoRA 3,409933 · Quantum 3,451734 NLL", "paragraphs": [ "SmolLM2-135M blieb als Backbone eingefroren. Trainiert wurden kleine Bausteine vor dem Ausgabekopf: LoRA, MLP, trigonometrischer Block und ein idealer Vier-Qubit-Erwartungswertblock. Drei Seeds, zwei Lernraten und dasselbe Updatebudget ergaben 24 Trainingsversuche.", "Der Quantenblock verbessert den unveränderten Backbone, verliert aber in allen drei Seeds gegen LoRA. Die mittlere negative Log-Likelihood beträgt 3,451734 gegenüber 3,409933; kleiner ist besser. Die geometrische Perplexität ist etwa 4,27 % höher.", "Funktion und Gradienten wurden gegen einen äquivalenten klassischen Operator geprüft. Der Rückstand existiert bereits bei idealer Simulation. Endliche Messwiederholungen wurden nach dem Training ausgewertet; ein reales QPU-Training fand nicht statt." ], "boundary": "Eine Einbauposition, ein kleines Modell, begrenzte Daten und Trainingsbudgets. Kein Urteil über alle Quantenarchitekturen.", "decision": "Diese konkrete Adapterfamilie nicht auf eine kostenpflichtige QPU portieren.", "source": "AR-003 Originalbericht", "source_sha256": "e6fede622462d986655411b36ec76ff07c0439ad604fea7e3fc2a67328c71a0d", "abstract": "Ein kleiner Quantenbaustein wird vor dem Ausgabekopf eines eingefrorenen Sprachmodells trainiert. Der Versuch prüft seine Modellqualität gegen LoRA, MLP und eine trigonometrische Kontrolle unter demselben Updatebudget. Die Schaltung läuft in einem klassischen GPU-Simulator.", "sections": [ { "heading": "Ein eng begrenzter Eingriff in ein Sprachmodell", "html": "Der Versuch verwendet SmolLM2-135M als eingefrorenen Backbone. Trainiert wird ausschließlich ein kleiner Baustein vor dem Ausgabekopf. Damit lässt sich untersuchen, ob die gewählte Quantenfunktion nützliche zusätzliche Struktur lernt, ohne gleichzeitig das gesamte Sprachmodell zu verändern. Die Frage betrifft diese Einbauposition und diese Adapterfamilie.
Verglichen werden LoRA mit Rang 4, ein MLP mit Breite 4, ein trigonometrischer Block und ein idealer Vier-Qubit-Erwartungswertblock. LoRA besitzt 4.608 trainierbare Parameter, die drei anderen Varianten jeweils 4.616. Die Parameterzahlen liegen nahe beieinander. Daraus folgt noch keine Gleichheit der späteren Hardwarekosten, weil die Verfahren ihre Ausgaben sehr unterschiedlich berechnen.
" }, { "heading": "Datenaufteilung und Training vor der Auswertung festlegen", "html": "Gepinnte Modell- und WikiText-Revisionen liefern 16.384 Trainings-, 4.096 Validierungs- und 4.096 Testtokens bei einer Kontextlänge von 128. Vier Familien, drei Zufallsstarts und zwei Lernraten ergeben 24 Trainingsversuche. Jeder Versuch erhält 64 Updates mit 256 Tokenbeispielen. Insgesamt werden 1.536 Optimizerschritte ausgeführt.
Die Qualitätsgröße ist die mittlere negative Log-Likelihood, kurz NLL, in Nats pro Token. Kleinere Werte sind besser. Zusätzlich wird die geometrische Perplexität ausgewiesen. Das vorab festgelegte Auswahlziel verlangt mindestens 0,01 Nats Verbesserung gegenüber der klassischen Kontrolle und einen Vorteil in allen drei Seeds. Die klassische GPU simuliert dabei eine ideale Schaltung. Kein physischer Quantenprozessor ist am Training beteiligt.
" }, { "heading": "Qualität unter demselben Budget vergleichen", "html": "Das unveränderte Modell erreicht eine Test-NLL von 3,526229. LoRA erzielt 3,409933, das MLP 3,429072, der trigonometrische Block 3,439383 und der ideale Quantenblock 3,451734. Alle vier trainierten Familien verbessern damit den unveränderten Backbone. Innerhalb dieses Versuchs liegt LoRA jedoch vorn.
Der Quantenbaustein verliert in allen drei Seeds gegen LoRA. Die mittlere Differenz beträgt 0,0418006 Nats pro Token zu seinen Ungunsten. Das entspricht ungefähr 4,27 % höherer geometrischer Perplexität. Sein Wert liegt bei 31,5551 gegenüber 30,2632 für LoRA. Der Vergleich wird somit nicht durch die bloße Verbesserung zum eingefrorenen Ausgangsmodell entschieden, sondern durch die stärkere klassische Alternative.
" }, { "heading": "Funktion und Gradienten unabhängig kontrollieren", "html": "Ein negatives Lernergebnis wäre wenig aussagekräftig, wenn der Quantenblock falsch eingebunden wäre. Deshalb werden zunächst native Modelllogits und der separate Hiddenstate-/Head-Pfad verglichen. Im Probeinput stimmen sie exakt überein. Die Quantenfunktion wird außerdem gegen einen äquivalenten klassischen 16-mal-16-Operator einschließlich Gradienten geprüft. Die größte Abweichung beträgt höchstens 5,33 × 10⁻¹⁵.
Nach dem idealen Training werden gemeinsame Z-Basis-Messungen mit 128 beziehungsweise 1.024 Shots simuliert. Die mittleren NLL-Werte liegen bei 3,451899 und 3,451706. Die entscheidende Lücke zu LoRA ist bereits ohne Messrauschen vorhanden. Diese Nachprüfung ist kein verrauschtes QPU-Training. Die Parameter wurden mit exakten Simulatorgradienten gelernt, endliche Messwiederholungen erst anschließend ausgewertet.
" }, { "heading": "Die Quantenfunktion bleibt in einen klassischen Pfad eingebettet", "html": "Pro vorbereitetem Beispiel verwendet der Block vier logische Qubits, zwölf abstrakte RY-Rotationen, acht CZ-Gatter und vier gemeinsam gemessene Z-Erwartungswerte. LayerNorm sowie Down- und Up-Projektion bleiben klassisch. Die beiden Projektionen umfassen zusammen 4.608 klassische MACs pro Token. Backbone und Sprachmodellausgabekopf bleiben ebenfalls Teil der Rechnung.
Ein einfacher Parameter-Shift-Pfad für acht trainierbare und vier Eingabewinkel würde 24 verschobene Einstellungen plus einen Vorwärtslauf benötigen. Das entspricht 25 mal der gewählten Shotzahl pro Beispiel. Diese Konstruktion ist keine allgemeine Quantenuntergrenze. Native Gatter, Fehlerkorrektur, Steuerung und Versorgung sind nicht gemessen. Vier Qubits lassen sich hier zudem mit nur 16 klassischen Amplituden simulieren, weshalb ein Qualitätsgewinn allein noch keinen Hardwarevorteil begründen würde.
" }, { "heading": "Welche Schlussfolgerung das Experiment trägt", "html": "Der konkret geprüfte Adapter wird nicht auf eine kostenpflichtige QPU übertragen. Unter dem festgelegten Budget erreicht er das Qualitätsziel nicht. Alle ausgewählten Versuche enden zugleich am höchsten getesteten Lernraten- und Schrittbudget. Vollständige Konvergenz oder optimale Hyperparameter sind damit nicht nachgewiesen. WikiText könnte außerdem im Vortraining des Backbones enthalten gewesen sein.
Diese Grenzen betreffen die Reichweite des Befunds, nicht seine Richtung im geprüften Vergleich. Eine andere Einbauposition, ein anderer Auslesevertrag oder eine quantennative Modellfamilie benötigt eine neue kontrollierte Hypothese. Der vorliegende Versuch liefert eine überprüfbare Entscheidung für diese Familie und dokumentiert sowohl ihre Lernfähigkeit als auch den Rückstand zur passenden klassischen Referenz.
" } ] }, { "id": "quanten-schueler", "topic": "Quanten", "level": "Training im Simulator", "status": "Nicht weiterverfolgt", "title": "Lässt sich eine Qwen-Projektion in einen kompakten Quantenschüler übertragen?", "result": "27,59 % relativer Testfehler", "paragraphs": [ "Ein Schüler approximiert eine reale 4 × 16-Teilmatrix mit künstlichen Eingaben. Zwei Schaltungstiefen, drei Seeds und zwei Lernraten untersuchen, ob die Darstellung zur Aufgabe passt. Das Ziel war ein relativer numerischer Testfehler von höchstens 5 %.", "Die tiefere getestete Ausführung erreicht im Mittel 27,59 % und verfehlt dieses Gate. Der kleine Projektionsschüler lässt sich zugleich in eine klassische 4 × 16-Matrix übersetzen. Ein geringer Schaltungsparameterumfang ist hier keine Begründung für einen Quantenrechenvorteil.", "Die richtige Forschungsfrage bleibt, ob eine andere Aufgabe, Ein-/Ausgabedarstellung oder Modellfamilie quantengeeignet ist. Eine ganze Sprachmodellarchitektur wurde weder transformiert noch auf einem Quantenchip ausgeführt." ], "boundary": "Winzige lineare Teilfunktion, kein Sprachqualitätstest und keine gemessene Quantenhardwarezeit.", "decision": "Diesen Schüler nicht zur Hardwareauslegung hochskalieren.", "source": "AR-004 Originalbericht", "source_sha256": "a273769c4a4db6544b153e9f75d0ad353d02a58bba0f029901a4636d5c589fbb", "abstract": "Eine Transformation allein macht ein Sprachmodell noch nicht quantengeeignet. Wir trainieren deshalb zunächst einen kleinen Schüler auf einer realen Qwen-Teilmatrix. Der Versuch prüft Darstellungsfehler, klassische Vergleichsmodelle und die Kosten, die eine spätere Quantenimplementierung zusätzlich berücksichtigen müsste.", "sections": [ { "heading": "Eine kleine lineare Funktion als erster Filter", "html": "Aus der Gate-Projektion der ersten Qwen-Schicht wird eine unveränderte Teilmatrix mit vier Ausgängen und 16 Eingängen verwendet. Die Herkunft der BF16-Gewichte ist über einen gespeicherten Hash geprüft. Die Zielwerte werden mit den daraus rekonstruierten Gewichten in FP64 berechnet. Es handelt sich um eine echte Gewichtsstichprobe, aber um künstliche Eingaben und keine ausgeführten Sprachmodellantworten.
Die Aufgabe ist bewusst klein. Vor einem großen Quantenschüler muss zunächst geklärt werden, ob die vorgeschlagene Schaltungsfamilie überhaupt eine bekannte lineare Funktion hinreichend genau darstellen kann. Das vorab gesetzte Ziel beträgt höchstens 5 % relative numerische Testabweichung in allen drei Zufallsstarts. Ein Bestehen wäre erst der Einstieg in eine Ressourcenprüfung, nicht bereits ein Beschleunigungsnachweis.
" }, { "heading": "Wie der Schüler die Eingabe verarbeitet", "html": "Der Schüler nutzt fünf Qubits. Ein 16-dimensionaler Eingabevektor wird normiert und mit Nullen auf einen 32-dimensionalen Zustandsvektor ergänzt. Darauf wirkt eine trainierbare Schaltung aus RY-Rotationen und CX-Verbindungen. Die ersten vier Ausgangsamplituden werden mit der Eingabenorm und vier trainierbaren Ausgangsskalierungen multipliziert. Verglichen werden vier und acht Schaltungslagen.
Diese Amplituden sind im Simulator direkt zugänglich. Eine reale Quantenhardware müsste ihre gewünschte klassische Ausgabe durch ein passendes Messverfahren gewinnen. Dieser Ausleseaufwand wird durch den Lernversuch nicht kostenlos gelöst. Weil die Normierung am Ausgang wieder aufgehoben wird und die Schaltung linear auf den Zustandsvektor wirkt, bleibt die gesamte geprüfte Abbildung eine klassische lineare Funktion der ursprünglichen Eingabe.
" }, { "heading": "Training und Auswahl vom Test trennen", "html": "Reproduzierbar erzeugte gaußverteilte Eingaben werden in 256 Trainings-, 128 Validierungs- und 256 Testvektoren aufgeteilt. Beide Schaltungstiefen werden mit drei Seeds und zwei Lernraten trainiert. Jeder Lauf erhält höchstens 160 Updates. Alle 20 Updates wird die Validierungsleistung geprüft. Checkpoint und Lernrate werden ausschließlich anhand dieser Validierung gewählt.
Der Testwert ist die Quadratwurzel aus der gesamten quadrierten Vorhersageabweichung geteilt durch die gesamte quadrierte Zielgröße. Er beschreibt einen relativen Vektorfehler. Er ist keine Perplexität und kein Maß für Sprachverständnis. Der feste Aufbau vermeidet, nachträglich nur günstige Eingaben oder Trainingsstarts zu berichten. Zugleich bleibt die Aussage auf die kleine Matrix und die untersuchte synthetische Eingabeverteilung beschränkt.
" }, { "heading": "Mehr Tiefe verbessert die Näherung, erreicht aber das Ziel nicht", "html": "Die Ausführung mit vier Lagen erreicht im Mittel 58,92 % relativen Testfehler. Mit acht Lagen sinkt er auf 27,59 %. Die drei Werte des tieferen Schülers liegen bei etwa 21,02 %, 36,54 % und 25,20 %. Die Verbesserung durch die größere Schaltung ist damit sichtbar. Keiner dieser drei Testwerte erfüllt jedoch das festgelegte 5-%-Ziel.
Eine klassische Rang-2-SVD erreicht etwa 54,80 % Fehler bei 40 gespeicherten Koeffizienten. Der tiefere Quantenschüler besitzt 44 trainierbare Parameter und approximiert die Matrix unter diesem Budget besser. Das ist kein exakt gleicher Parametervergleich. Vor allem bleibt eine starke Kontrolle bestehen: Die ursprüngliche dichte 4-mal-16-Matrix benötigt 64 Koeffizienten und 64 MACs, ohne den zusätzlichen Approximationsfehler des Schülers.
" }, { "heading": "Die klassische Kompilierung ist eine notwendige Kontrolle", "html": "Nach dem Training wird der Schüler auf sämtliche 16 Basisvektoren angewendet. Daraus entsteht eine gewöhnliche klassische Matrix, die seine gesamte lineare Funktion beschreibt. Auf den Testeingaben wird geprüft, dass diese kompilierte Matrix denselben Ausgang wie die Schaltung liefert. Damit ist die geringe Zahl trainierbarer Winkel allein kein Argument dafür, die Funktion später auf einem Quantenprozessor auszuführen.
Die gemeinsame Lernserie prüft zudem Gradientenpfad und Schaltungsfunktion unabhängig. Gespeicherte Checkpoints reproduzieren ihre Testscores. Ein separater Qiskit-Prozess kontrolliert ausgewählte trainierte Schaltungen. Diese Prüfungen sichern die Simulation ab. Sie messen weder physische Zustandspräparation noch klassische Amplitudenrekonstruktion, Fehlerkorrektur oder Energieverbrauch einer realen QPU.
" }, { "heading": "Welche Transformation einen neuen Versuch rechtfertigen würde", "html": "Der geprüfte Projektionsschüler wird nicht zu einer Hardwareauslegung hochskaliert. Er verfehlt das numerische Ziel, und seine kleine lineare Funktion besitzt eine unmittelbare klassische Realisierung. Längeres Training könnte die Näherung verändern. Es würde die Frage nach dem passenden Ein- und Ausgabevertrag aber nicht automatisch lösen.
Eine neue Hypothese müsste erklären, welche nichttriviale Struktur ein größerer Schüler ausnutzt, wie die Eingangsdaten vorbereitet werden und welche Ausgabe tatsächlich benötigt wird. Wird statt eines vollständigen Zahlenvektors nur ein Symbol oder eine Entscheidung gebraucht, verändert sich die Auslesefrage grundlegend. Genau diese Art von Aufgabenwechsel ist separat prüfbar. Eine vollständige Transformation von Qwen oder unveränderte Sprachmodellfähigkeit ist durch den vorliegenden Teilmatrixversuch nicht nachgewiesen.
" } ] }, { "id": "quanten-generator", "topic": "Quanten", "level": "Training im Simulator", "status": "Funktion bestätigt", "title": "Kann ein Quantenmodell das nächste Symbol direkt erzeugen?", "result": "1,29718 statt 1,24125 Test-NLL", "paragraphs": [ "Der quantennative Generator lernt eine Messverteilung: Eine Messung kann direkt das nächste Symbol liefern. Der vollständige klassische Zahlenvektor muss für diesen Vertrag nicht ausgelesen werden. Varianten mit vier, sechs und acht Qubits wurden auf einem synthetischen Prozess mit vier Symbolen untersucht.", "Zusätzliche Hilfsqubits beseitigen eine konkrete Beschränkung der kleinen unitären Darstellung. Der Acht-Qubit-Generator erreicht eine Test-NLL von 1,29718. Eine exakte klassische Tabelle mit 64 Wahrscheinlichkeiten erreicht aber 1,24125.", "Die Funktion ist real im Simulator ausgeführt. Der geänderte Auslesevertrag ist interessant; Qualität und Gesamtaufwand schlagen in dieser Aufgabe die starke klassische Kontrolle nicht. Die Symbolsequenzen sind keine natürliche Sprache." ], "boundary": "Keine QPU, kein natürliches Sprachmodell, keine Energie- oder Laufzeitmessung auf Quantenhardware.", "decision": "Den funktionierenden Auslesevertrag dokumentieren; diese Ausführung nicht als Gewinner skalieren.", "source": "AR-005 Originalbericht", "source_sha256": "a273769c4a4db6544b153e9f75d0ad353d02a58bba0f029901a4636d5c589fbb", "abstract": "Ein quantennativer Generator muss nicht bei jedem Schritt einen vollständigen klassischen Ergebnisvektor auslesen. Wir trainieren eine Messverteilung, aus der direkt das nächste Symbol entsteht. Eine kleine kontrollierte Sequenzaufgabe zeigt, was dieser Ausgabevertrag leistet und welche klassischen Kontrollen er schlagen müsste.", "sections": [ { "heading": "Die Ausgabe ist ein Symbol statt eines Zahlenvektors", "html": "Bei einer klassischen Projektion werden viele numerische Ergebnisse für die weitere Rechnung benötigt. Eine Quantenabbildung muss diese Werte gegebenenfalls mit vielen Messungen rekonstruieren. Für einen generativen Schritt ist ein anderer Vertrag möglich: Die Messung liefert unmittelbar das nächste Symbol aus einer gelernten Wahrscheinlichkeitsverteilung.
Unser Versuch prüft genau diesen Wechsel. Der Kontext wird als Basiszustand vorbereitet, eine trainierbare Schaltung verändert die Zustandsamplituden und die Messung der Ausgaberegister liefert eines von vier Symbolen. Ein vollständiger klassischer Wahrscheinlichkeitsvektor ist zur einzelnen Symbolziehung nicht erforderlich. Die neue Kontextpräparation pro Symbol bleibt notwendig. Diese Funktion wird im Simulator ausgeführt, nicht auf einer QPU.
" }, { "heading": "Ein stochastischer Prozess mit vollständig bekannten Grenzen", "html": "Die Sequenzaufgabe besitzt vier Symbole. Das nächste Symbol hängt von den beiden vorherigen ab. Damit gibt es 16 mögliche Kontexte und vier Ausgangswahrscheinlichkeiten je Kontext. Der erzeugende Prozess ist eine vorgegebene klassische Wahrscheinlichkeitsregel und wurde nicht aus einem Quantenmodell abgeleitet. Der Versuchsaufbau bevorzugt somit keine Schaltungsfamilie durch ein quantenerzeugtes Ziel.
Trainings-, Validierungs- und Testdaten werden separat erzeugt. Sie enthalten 128, 64 und 128 Sequenzen mit jeweils zwölf vorherzusagenden Folgesymbolen. Untersucht werden drei Schaltungen mit vier, sechs und acht Qubits sowie jeweils drei Lagen. Drei Seeds, zwei Lernraten und höchstens 160 Updates je Lauf bilden das gemeinsame Trainingsbudget. Die Auswahl erfolgt anhand der Validierungsdaten.
" }, { "heading": "Ein Strukturhindernis wird sichtbar", "html": "Der Vier-Qubit-Generator verwendet alle 16 Basiszustände als Kontexteingaben. Für eine unitäre Transformation auf dieser vollständigen Basis ist der Mittelwert der vier Ausgabewahrscheinlichkeiten über gleich gewichtete Kontexte jeweils 1/4. Das ist eine strukturelle Eigenschaft des gewählten Modells, keine Frage einer noch nicht ausreichend langen Optimierung.
Der Zielprozess verlangt stattdessen ungefähr 0,1866, 0,2240, 0,2684 und 0,3211 als entsprechende Mittelwerte. Die kleine Schaltung kann diese Bedingung daher nicht beliebig treffen. Zusätzliche Hilfsqubits in den Varianten mit sechs und acht Qubits heben diese konkrete Vollbasis-Beschränkung auf. Der Versuch untersucht so eine begründete Architekturänderung statt lediglich weitere Trainingsschritte desselben eingeschränkten Modells.
" }, { "heading": "Qualität gegen Tabelle, MLP und Transformer messen", "html": "Die mittlere Test-NLL beträgt 1,33789 für vier Qubits, 1,30142 für sechs und 1,29718 für acht. Kleinere Werte sind besser. Zusätzliche Hilfsqubits verbessern die untersuchte Modellfamilie. Ein klassisches MLP erreicht jedoch 1,24301, ein kleiner Transformer 1,24210 und eine klassische Übergangstabelle 1,24125.
Die Tabelle speichert 64 Wahrscheinlichkeiten und wird aus den Trainingshäufigkeiten mit einer auf Validierung gewählten Glättung bestimmt. Sie ist keine Kenntnis der versteckten Testantworten. Weil sämtliche 16 Kontexte klein und explizit darstellbar sind, ist sie eine passende starke Kontrolle. Auch die Wahrscheinlichkeiten eines fertig trainierten Quantengenerators lassen sich für diese Aufgabe vollständig klassisch tabellieren. Keiner der Quantenkandidaten erfüllt das vorab festgelegte Qualitätsgate gegen die stärkste klassische Alternative.
" }, { "heading": "Direkte Symbolerzeugung tatsächlich ausführen", "html": "Drei ausgewählte Modelle erzeugen in einem separaten Qiskit-Prozess jeweils 32 aufeinanderfolgende Symbole. Nach jeder Ziehung wird der Kontext aktualisiert und neu präpariert. Insgesamt sind das 96 zusätzliche Zustandspräparationen für die autoregressiven Folgen. Die Prüfung ergänzt 150 Zustandsläufe an 15 ausgewählten trainierten Schaltungen aus der gemeinsamen Versuchsserie.
Die unabhängig berechneten Zustände stimmen bis auf Abweichungen unter 4 × 10⁻¹⁶ überein. Damit ist der geänderte Auslesevertrag funktional nachvollzogen. Eine einzelne simulierte Ziehung ist trotzdem keine gemessene physische Tokenlatenz. Die verwendeten exakten CPU-Gradienten, die Zustandspräparation und das Born-Sampling enthalten keine vollständige Gerätefehler-, Steuerungs- oder Versorgungsbilanz.
" }, { "heading": "Der Fortschritt liegt im Vertrag, nicht in einem gemessenen Vorsprung", "html": "Der Versuch zeigt einen funktionierenden Generator, dessen Ausgabemessung unmittelbar ein Symbol liefert. Er zeigt außerdem, weshalb ein kleiner unitärer Ansatz eingeschränkt ist und wie Hilfsqubits diese konkrete Einschränkung verändern. Das sind überprüfbare Erkenntnisse über die Modellstruktur. Auf der gewählten Aufgabe entsteht daraus noch kein Qualitäts- oder Aufwandsvorteil gegenüber den klassischen Kontrollen.
Eine neue Aufgabe müsste eine Struktur besitzen, die sich nicht bereits mit einer winzigen Tabelle vollständig abbilden lässt. Gleichzeitig müssten Kontextzugriff, Training und benötigte Ausgabe weiterhin realistisch bleiben. Die vier Symbole sind keine natürliche Sprache und der Zweischrittkontext kein Langkontext-Sprachmodell. Mehr Qubits allein beantwortet deshalb weder die Skalierungsfrage noch die Frage nach einer besseren Hardware für vollständige Sprachmodelle.
" } ] }, { "id": "quanten-lehrer", "topic": "Quanten", "level": "Training im Simulator", "status": "Nicht weiterverfolgt", "title": "Kann ein Quantenlehrer ein klassisches Modell besser trainieren?", "result": "1,30601 direkt · 1,30736 mit Lehrer", "paragraphs": [ "Ein klassischer Schüler wurde direkt sowie mit idealen Quanten-Softlabels, endlichen Messwiederholungen und einem klassischen Lehrer trainiert. Drei Seeds sollten zeigen, ob ein Quantenlehrer nützliche Struktur vermittelt, ohne später bei jeder Anfrage benötigt zu werden.", "Die mittlere Test-NLL beträgt 1,30601 beim direkten Training und 1,30736 mit idealem Quantenlehrer. Ein stabiler Gewinn fehlt. Die gesamte Versuchsserie mit Schülern, Generatoren und Lehrern umfasste 66 Lernläufe; ausgewählte Checkpoints und zusätzliche Qiskit-Ausführungen wurden nachgeprüft." ], "boundary": "Kleine kontrollierte Aufgabe und exakte Simulatorgradienten. Hardwarekosten des Quantentrainings wurden nicht gemessen.", "decision": "Diesen Lehrer nicht in den Produktpfad übernehmen. Eine andere Trainingshilfe benötigt eine neue Hypothese.", "source": "AR-006 Originalbericht", "source_sha256": "a273769c4a4db6544b153e9f75d0ad353d02a58bba0f029901a4636d5c589fbb", "abstract": "Quantenhardware müsste nicht bei jeder späteren Anfrage beteiligt sein. Ein denkbarer Einsatz besteht darin, während des Trainings zusätzliche Lernsignale zu liefern. Wir vergleichen dafür denselben kleinen klassischen Schüler mit direkten Zielwerten, idealen Quanten-Softlabels, endlichen Messwiederholungen und einem klassischen Lehrer.", "sections": [ { "heading": "Quantenaufwand auf die Trainingsphase begrenzen", "html": "Ein Lehrer kann neben dem beobachteten richtigen Symbol auch Wahrscheinlichkeiten für alternative Ausgaben bereitstellen. Solche Softlabels enthalten zusätzliche Struktur und werden bei der Distillation an ein kleineres Modell weitergegeben. Die Forschungsfrage ist, ob eine Quantenfunktion besonders nützliche Softlabels erzeugt. Das eingesetzte Endmodell könnte danach vollständig klassisch arbeiten.
Der Ansatz verschiebt die Kostenfrage. Die QPU wäre nicht bei jedem späteren Token nötig, ihr Trainings- und Exportaufwand bliebe aber Teil der Entwicklungskosten. Ein sinnvoller Vorteil müsste deshalb bessere Schülerqualität oder geringeren gesamten Lernaufwand zeigen. Dass ein Quantenlehrer überhaupt trainierbar ist, reicht für diese Entscheidung noch nicht.
" }, { "heading": "Derselbe Schüler in vier Lernbedingungen", "html": "Die Aufgabe verwendet denselben kontrollierten Prozess mit vier Symbolen und zwei Kontextsymbolen wie der quantennative Generatorversuch. Der Schüler ist ein kleines klassisches MLP mit zwei verborgenen Einheiten. Seine Ein- und Ausgabe sowie seine Modellkapazität bleiben in allen Bedingungen gleich. Die Unterschiede liegen allein in den Trainingssignalen.
Verglichen werden direktes Training auf den beobachteten Zielwerten, zusätzliche Softlabels eines idealen Quantenlehrers, Softlabels desselben Ansatzes mit 2.048 simulierten Messungen je Kontext und Softlabels eines klassischen Lehrers. Beim Lehrertraining gewichtet die Verlustfunktion harte Zielwerte und Lehrerwahrscheinlichkeiten jeweils mit 50 %. Der direkte Arm verwendet ausschließlich die harten Zielwerte. Die Lehrerterme werden gleichmäßig über die 16 bekannten Kontexte gemittelt.
" }, { "heading": "Lehrerauswahl und Schülerauswahl nicht am Test optimieren", "html": "Je Seed wird der Quantenlehrer anhand der Validierung aus den trainierten Quantenfamilien ausgewählt. Für die klassische Kontrolle stehen die trainierten klassischen Familien und die Übergangstabelle zur Verfügung. Auch hier entscheidet die Validierung. Die späteren Testantworten dienen weder zur Lehrerauswahl noch zur Bestimmung der Schülerparameter.
Alle Schülerbedingungen verwenden drei Seeds, zwei Lernraten und maximal 160 Updates mit regelmäßigen Validierungsprüfungen. Die gemeinsame Serie aus Projektionsschülern, Generatoren und Trainingshelfern umfasst insgesamt 66 Lernläufe und 33 ausgewählte Checkpoints. Diese Gesamtsumme gehört nicht allein zum Lehrerexperiment. Für eine Kostenbewertung werden Lehrersuche und anschließendes Schülertraining getrennt erfasst, damit ein aufwendig ausgewählter Lehrer nicht kostenlos erscheint.
" }, { "heading": "Die Testwerte zeigen keinen stabilen Qualitätsgewinn", "html": "Direktes Training erreicht eine mittlere Test-NLL von 1,30601. Mit idealem Quantenlehrer beträgt sie 1,30736, mit endlichen Quanten-Softlabels 1,30815 und mit klassischem Lehrer 1,31098. Kleinere Werte sind besser. Der ideale Quantenlehrer liegt damit in dieser kleinen Serie vor dem getesteten klassischen Lehrer, aber nicht vor dem direkten Training.
Die Einzelergebnisse erklären, weshalb der Mittelwert allein nicht genügt. Mit idealem Quantenlehrer verbessert sich der Schüler in zwei Seeds gegenüber dem direkten Arm, verschlechtert sich im dritten jedoch stärker. Das vorab festgelegte Gate verlangt eine mittlere Verbesserung von mindestens 0,01 Nats gegenüber direktem Training und klassischem Lehrer sowie einen Vorteil in jedem Seed. Diese Bedingung wird nicht erfüllt. Aus drei Seeds wird keine allgemeine statistische Überlegenheit abgeleitet.
" }, { "heading": "Endliche Messungen sind noch kein realer Quantenbetrieb", "html": "Für die endliche Lehrerfassung werden je Kontext 2.048 Symbole aus der idealen Verteilung gezogen. Bei 16 Kontexten entspricht das 32.768 simulierten Shot-Ausführungen pro Lehrerexport. Die Häufigkeiten dieser Ziehungen bilden die Softlabels. Die Simulation enthält die Stichprobenstreuung des Born-Samplings, aber keine kalibrierten Gerätefehler, keinen realen Messaufbau und keine Fehlerkorrektur.
Die Quantenlehrer selbst wurden mit exakten CPU-Simulatorgradienten optimiert. Eine physische Umsetzung etwa mit Parameter-Shift würde zusätzliche Schaltungsausführungen benötigen. Hinzu kämen Zustandspräparation, Steuerung und Versorgung. Die gespeicherten CPU-Trainingszeiten sind daher keine Vorhersage der Laufzeit einer QPU. Ebenso lässt sich aus der fehlenden QPU im späteren Schülerbetrieb noch keine gesamte Energieersparnis ableiten.
" }, { "heading": "Wann ein Trainingshelfer einen neuen Anlauf verdient", "html": "Der konkrete Lehrer wird nicht in den vorgesehenen Produktpfad übernommen. Unter dem geprüften Budget fehlt ein stabiler Vorteil gegenüber dem einfacheren direkten Training. Die Entscheidung verwirft diese Kombination aus Aufgabe, Lehrerfamilie, Schülerkapazität und Verlustgewichtung. Sie widerlegt nicht jede denkbare Quantenhilfe beim Lernen.
Ein neuer Versuch müsste eine überprüfbare Ursache für nützlichere Lernsignale benennen. Anschließend wären starke klassische Lehrer, dieselbe Schülerkapazität, zurückgehaltene Daten und sämtliche Such- und Trainingskosten einzubeziehen. Für diese kleine Aufgabe können sämtliche Lehrerwahrscheinlichkeiten klassisch tabelliert werden. Eine überzeugende Hardwarebegründung müsste daher über die bloße Erzeugung dieser 64 Wahrscheinlichkeiten hinausgehen und einen Vorteil zeigen, der nach vollständiger Kostenrechnung erhalten bleibt.
" } ] }, { "id": "spaet-runden", "topic": "Hardware", "level": "RTL + Synthese", "status": "Nicht weiterverfolgt", "title": "Kann eine späte Rundung die FP32-Akkumulation ersetzen?", "result": "10.241 statt 5.121 Kerntakte", "paragraphs": [ "Zwei erste RTL-Prototypen mit 72 und 128 Bit sammeln Produkte breit und runden erst am Ende. Sie zählen Scan, benötigte Bitbreite, Wiederholung und Abschluss mit. Die Referenz verwendet fortlaufende FP32-FMA.", "Bei K = 5.120 benötigt der Zweipass-Ansatz 10.241 statt 5.121 Kerntakte. Die unplatzierten Standardzellflächen betragen 73.071 beziehungsweise 96.034 µm² gegenüber 38.581 µm² für die Referenz. Ein verkürzter Rechenschritt allein entfernt den zusätzlichen Durchlauf nicht.", "Eine andere Rundungsreihenfolge ist außerdem ein anderer Numerikvertrag. Selbst wenn BF16-Ausgaben in vielen Stichproben gleich bleiben, zeigen gezielte Auslöschungsfälle Unterschiede. Mathematisch genauer bedeutet nicht automatisch modellidentisch." ], "boundary": "Synthese, kein fertiges Layout dieser breiten Kerne und keine dynamische Gesamtenergiebilanz.", "decision": "Die beiden Zweipass-Prototypen nicht ins Layout übernehmen.", "source": "AR-007 Originalbericht", "source_sha256": "a273769c4a4db6544b153e9f75d0ad353d02a58bba0f029901a4636d5c589fbb", "abstract": "Wer Produkte zunächst exakt summiert, kann wiederholte Rundung aus der inneren Rechenschleife entfernen. Wir prüfen die Idee zuerst numerisch und anschließend mit vollständigen RTL-Prototypen. Die Kosten für Exponentprüfung, breite Register und einen zweiten Eingabedurchlauf gehören zum Vergleich.", "sections": [ { "heading": "Zwei unterschiedliche Rechenverträge", "html": "Die bestehende Referenz multipliziert BF16-Operanden und führt die Summe mit aufeinanderfolgenden FP32-FMA-Schritten fort. Jeder Schritt rundet sein Ergebnis auf FP32. Der Kandidat richtet die Produkte als ganze Zahlen an einem gemeinsamen Exponenten aus, sammelt sie breit und rundet erst am Ende einmal auf FP32. Damit ändert sich die Rundungsreihenfolge.
Die Forschungsfrage lautet, ob der reduzierte Rundungsaufwand einen günstigeren vollständigen Rechenpfad ermöglicht. Eine mathematisch genauere Summe ist dabei nicht automatisch identisch mit der sequentiellen Referenz. Für einen Einsatz im Modell wären sowohl die physische Effizienz als auch die numerische Verträglichkeit zu prüfen. Bekannte Exact-dot- und Kulisch-Verfahren bilden den fachlichen Hintergrund, keine hier beanspruchte neue Erfindung.
" }, { "heading": "Der numerische Vorfilter bestimmt die nötige Breite", "html": "Der erste Versuch umfasst 192 Skalarprodukte mit K = 5.120. Sechs vollständige Zeilen der archivierten Qwen-Gewichtsstichprobe werden mit 32 synthetischen Eingabevektoren kombiniert. Eine unabhängige Rechnung mit rationalen Zahlen kontrolliert die exakten Summen. Die konservative Breitenprüfung berücksichtigt Exponentabstand, Signifikanden und Summandenanzahl ohne Gutschrift für eine mögliche Auslöschung.
Bei normalverteilten Eingaben werden 56 bis 65 Bit benötigt, bei einzelnen Ausreißern 65 bis 71 Bit und bei weit gespreizten Exponenten 109 bis 117 Bit. Der pauschale 64-Bit-Kandidat lässt deshalb nur 93 von 192 Fällen zu. Eine Ablehnung bedeutet, dass die gewählte Schranke keine sichere Breite garantiert. Sie beweist nicht für jeden Einzelfall einen tatsächlich eingetretenen Überlauf.
" }, { "heading": "Numerische Genauigkeit und Modellidentität auseinanderhalten", "html": "181 der 192 FP32-Ergebnisse unterscheiden sich von der sequentiellen FMA-Rechnung. Nach dem abschließenden Cast auf BF16 stimmen die Ergebnisse in allen 192 Stichproben überein. Daraus folgt jedoch keine allgemeine Gleichheit. Der gezielte Auslöschungsfall 2²⁴ + 1 − 2²⁴ ergibt bei exakter Summation 1, bei sequentieller FP32-Rundung 0. Auch nach einem BF16-Cast bleibt dieser Unterschied bestehen.
Die Stichprobe zeigt damit zwei Dinge. Viele kleine FP32-Abweichungen verschwinden beim gröberen Ausgabeformat, andere können erhalten bleiben. Eine spätere Modellprüfung müsste reale Aktivierungen, seltene Exponentenlagen und vollständige Ausgaben einbeziehen. Aus der Reduktion von 5.120 Rundungen auf eine lässt sich insbesondere kein entsprechend großer Geschwindigkeitsfaktor ableiten.
" }, { "heading": "Was die vollständigen RTL-Kerne enthalten", "html": "Die beiden Prototypen verwenden 72 beziehungsweise 128 Bit. Ihr erster Durchlauf scannt die Exponenten und prüft die erforderliche Breite. Im zweiten Durchlauf werden dieselben Eingaben erneut gelesen, multipliziert, ausgerichtet und addiert. Hinzu kommen Überlaufkontrolle sowie normale und subnormale Abschlussrundung nach Round-to-nearest-even. NaN und Unendlich gehören nicht zum endlichen Kandidatenvertrag.
Bei K = 5.120 zählt die Simulation 10.241 Kerntakte gegenüber 5.121 für die sequentielle Referenz. Bei gleichem Takt verdoppelt sich die Kernlaufzeit damit nahezu. Eine physische Taktverbesserung müsste diesen Aufwand erst kompensieren. Ablehnungen sind explizit gekennzeichnet, ein produktiver Ausweichpfad ist noch nicht implementiert. Dessen Zeit, Speicherzugriffe und Steuerung dürften bei einer Systembewertung nicht fehlen.
" }, { "heading": "Synthese und Funktion liefern einen klaren Auswahlgrund", "html": "Unter derselben Yosys-/ABC-Abbildung in die IHP-Bibliothek ergeben sich summierte Standardzellflächen von 38.581,40 µm² für die Referenz, 73.071,33 µm² für 72 Bit und 96.034,38 µm² für 128 Bit. Das entspricht etwa dem 1,89- beziehungsweise 2,49-Fachen der Referenz. Es sind unplatzierte Zellensummen, keine fertigen Chipflächen. Ein erreichbarer physischer Takt und die dynamische Gesamtenergie wurden nicht bestimmt.
Je Kern wurden 28 RTL-Aufgaben einschließlich sechs langer Skalarprodukte geprüft. Die Referenz liefert 28 Ergebnisse. Die 72-Bit-Variante liefert 24 Ergebnisse und vier korrekte Ablehnungen, die 128-Bit-Variante 26 Ergebnisse und zwei korrekte Ablehnungen. Nach Synthese bestehen jeweils 22 kurze Netzlistenfälle. Die begrenzte lange Netzlistenprüfung läuft ins Zeitlimit und wird nicht als bestanden gewertet.
" }, { "heading": "Welche Änderung einen neuen Versuch rechtfertigen würde", "html": "Die beiden geprüften Zweipass-Prototypen werden nicht zur Layoutvertiefung priorisiert. Mehr Zellfläche und nahezu doppelte Taktenzahl liefern in ihrer aktuellen Form keinen günstigen Ausgangspunkt. Das betrifft diese Implementierungen. Breite Integer-Buchführung und der vorgeschaltete Scan lassen Optimierungsmöglichkeiten erkennen, deren Wirkung aber erst ein neuer Vergleich zeigen könnte.
Ein aussichtsreicher neuer Kandidat müsste beispielsweise wiederverwendbare Exponentenmetadaten, schmalere Kontrollfelder oder einen vollständigen effizienteren Fused-dot-Pfad konkret umsetzen. Er wäre gegen eine starke arithmetische Referenz zu prüfen, nicht nur gegen den ersten Prototyp. Unverzichtbar bleiben ein sicherer Zahlenvertrag, ein bezifferter Ausweichpfad und eine Qualitätsprüfung im Modell. Erst dann wäre weniger Rundung ein belastbares Architekturargument.
" } ] }, { "id": "pytorch-bis-rtl", "topic": "Software", "level": "Durchgängiger Funktionstest", "status": "Funktion bestätigt", "title": "Wie gelangt eine PyTorch-Projektion bis zu überprüfbaren RTL-Ergebnissen?", "result": "15 FP32-Ausgaben und Flags bitgenau", "paragraphs": [ "Ein exportierter Linear-Operator wird in einen HAL-Auftrag übersetzt. Die Laufzeitsoftware packt BF16-Wörter, zerlegt K in Blöcke bis 64 und führt die FP32-Summe über die Blockgrenzen fort. Ein realer Qwen-Gewichtsausschnitt und reproduzierbare PyTorch-Aktivierungen liefern die Eingaben.", "Alle 15 geprüften FP32-Ausgaben und Flags stimmen mit der unabhängigen Referenz überein. Auch die BF16-Ausgaben entsprechen der nativen PyTorch-Projektion. Bei K = 5.120 sinken die Porttakte von 7.181 bei fester auf 6.947 bei bankbewusster Überlappung: 3,26 %.", "Der zunächst unterstützte Vertrag umfasst einen ungebiassten Linear-Operator mit zusammenhängenden, endlichen BF16-Operanden. Ein späterer kleiner Zweikachelgraph erweitert die Verbindung; eine vollständige Qwen-Inferenz auf dieser Hardware ist damit nicht vorhanden." ], "boundary": "Die Schnittstelle funktioniert innerhalb des erklärten Operatorvertrags. Takte am Kachelport sind keine gemessene GPU- oder Serverlatenz.", "decision": "Den durchgängigen Softwarepfad für die unterstützten Linear-Operatoren in der Forschungsplattform weiterverwenden.", "source": "AR-008 Originalbericht", "source_sha256": "9f5fdf251f2754ce8a8732cba3325c47acac55803d34f1eac0f62dd60fd22e8d", "abstract": "Ein Hardwareentwurf wird erst nutzbar, wenn Software seine Operationen und Zustände zuverlässig ansteuern kann. Dieser Versuch verfolgt einen exportierten Linear-Operator durch Übersetzung, Speicherbelegung, Kachelausführung und Ergebnisrückgabe.", "sections": [ { "heading": "Der Operatorvertrag als überprüfbare Schnittstelle", "html": "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.
" }, { "heading": "Von Tensoren zu fortlaufenden FP32-Summen", "html": "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.
" }, { "heading": "Zwei Lastfälle prüfen unterschiedliche Fehlerquellen", "html": "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.
" }, { "heading": "Numerische Gleichheit auf mehreren Ebenen", "html": "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.
" }, { "heading": "Überlappung spart Zufuhrzeit, nicht Rechenarbeit", "html": "| 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.
" }, { "heading": "Ein funktionierender Softwarepfad mit definierter Messgrenze", "html": "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.
" } ] }, { "id": "direkte-weitergabe", "topic": "Hardware", "level": "RTL + Layoutnäherung", "status": "Tempo verbessert", "title": "Wann lohnt sich die direkte Weitergabe zwischen zwei Rechenkacheln?", "result": "55 → 50 Takte bei K16", "paragraphs": [ "Der zusammenhängende Pfad verbindet PyTorch, HAL/Runtime, zwei RTL-Kacheln und die Software-Rückgabe. Ergebnisse gelangen aus dem Rechenregister an die nächste Kachel. Gegen eine bereits überlappend lesende SRAM-Referenz entfallen vier Schreib- und vier Lesevorgänge.", "Der warme K16-Lauf braucht 50 statt 55 Takte. Bei K64 sind es 122 statt 127: Der relative Gewinn sinkt von 9,09 auf 3,94 %. Dieselben fünf eingesparten Takte tragen bei größerer Arbeit immer weniger zur gesamten Anfrage bei.", "Ein kurzer OpenROAD-Vorvergleich mit gespeicherten Platzierungs-/Grobverdrahtungsdaten bestätigt eine positive Timing-Tendenz. Ein früher langer Lauf verlor finale Exportdaten und erfüllte die Antennenabnahme nicht vollständig. Diese fehlenden Belege werden nicht als nachträglicher Layoutnachweis ausgegeben." ], "boundary": "Dieser verbundene Graph ist kleiner als das ganze Modell. Grobverdrahtung und ein künstlicher RC-Belastungstest ersetzen keinen fertigen physikalischen Nachweis.", "decision": "Direkte Weitergabe als geprüften Baustein im verbundenen Software- und RTL-Pfad beibehalten.", "source": "AR-009 Originalbericht", "source_sha256": "04ccaa0a2f99f8b97b825f6ab32f7b8ffd6bc267cf3ab8c7e2c5ed629f96e2de", "abstract": "Ein Ergebnis muss nicht erst zurück in den Ausgangsspeicher, wenn der nächste Rechenschritt bereits feststeht. Wir vergleichen einen direkten Registerpfad mit einer überlappend lesenden SRAM-Brücke bei gleicher Numerik, Gewichtsresidenz und Softwareanbindung.", "sections": [ { "heading": "Ein kleiner Graph mit vollständig erklärter Funktion", "html": "Der Vertrag tile-graph-v1 unterstützt zwei Linear-Operationen mit expliziter FP32-Rechnung, einem ReLU zwischen den Operationen und anschließender BF16-Rundung. Batchgröße ist 1, die Eingabetiefe liegt zwischen 1 und 64. Zwischenbreite und Ausgabebreite betragen jeweils vier. Die Gewichte stammen aus realen Qwen-Ausschnitten. Die Zusammensetzung ist jedoch ein synthetischer Graph und bildet keine zwei benachbarten Qwen-Schichten nach.
Der gesamte Pfad umfasst PyTorch-Export, HAL-Übersetzung, residente Gewichtsbeladung, Aktivierungsschreiben, Start des Hardwaregraphen und tatsächliches Ergebnislesen. Nicht unterstützte Graphen scheitern ausdrücklich. Ein erfolgreicher Softwareaufruf kann daher nicht durch eine unbemerkte Ausführung auf der CPU zustande kommen.
" }, { "heading": "Was die Direktverbindung verändert", "html": "Die Referenz liest Ergebnisse bereits über eine gepipelinte C-SRAM-Brücke. Sie ist damit stärker als ein künstlich vollständig serieller Speicherpfad. Der Kandidat führt die registrierten FP32-Ergebnisse direkt über eine Ready/Valid-Schnittstelle zum ReLU- und BF16-Packer. Bei Rückstau bleiben Ergebnisindex, Wert und Flags stabil, bis der Empfänger die Übertragung annimmt.
Pro Anfrage entfallen vier 64-Bit-C-Schreibzugriffe und vier entsprechende Lesezugriffe. Das sind 64 Transaktionsbytes. Vier direkte Übertragungsschritte und die Packerregister bleiben erforderlich. Auch die zweite Kachel erhält weiterhin ein gepacktes A-SRAM-Wort, das sie später liest. Die Änderung beseitigt folglich einen konkreten Speicherumweg, nicht jede Zwischenablage oder jede Datenbewegung des Graphen.
" }, { "heading": "Gewichtsresidenz und unabhängige Funktionskontrolle", "html": "Beide Datenwege besitzen dieselbe Arithmetik, je zwei Kacheln mit acht Speicherbänken sowie dieselbe Ausgabegrenze. Für jede Eingabetiefe werden zwei unterschiedliche Gewichtssätze jeweils für drei Anfragen ohne Kachelreset verwendet. Die 30 Anfragen benötigen gemeinsam 352 kalte 64-Bit-Gewichtsschreibzugriffe statt 1.056 bei ständigem Neuladen. Diese Wiederverwendung gilt für beide Varianten und wird nicht als Vorteil der Direktverbindung angerechnet.
Vier Konfigurationen mit zwei Datenwegen und jeweils mit beziehungsweise ohne Rückstau ergeben 120 Graphausführungen und 480 Prüfungen finaler Werte und Flags. Gerichtete Gegenfälle umfassen Rundungsgleichstände, Auslöschung, subnormale Werte, vorzeichenbehaftete Null und negative Werte. Sieben nicht unterstützte Eingaben werden abgewiesen. Eine unabhängige Ganzzahl-FMA prüft die Ausgaben. Native PyTorch-Ausführungen bestätigen die BF16-Zwischenwerte und die vereinbarte finale FP32-Toleranz.
" }, { "heading": "Fünf Takte bleiben fünf Takte", "html": "| Eingabetiefe | SRAM-Brücke | Direkt | Weniger Takte |
|---|---|---|---|
| K = 1 | 34 | 29 | 14,71 % |
| K = 16 | 55 | 50 | 9,09 % |
| K = 64 | 127 | 122 | 3,94 % |
Die warme Anfrage beginnt mit dem ersten Aktivierungsschreiben und endet mit dem letzten Ergebnislesen. Modellbeladung ist separat erfasst. Der absolute Vorteil beträgt in diesen Fällen fünf Takte. Je mehr Rechenarbeit die Anfrage enthält, desto kleiner wird ihr relativer Anteil. Die Rückstaufälle dienen dem korrekten Protokollverhalten. Wegen unterschiedlicher absoluter Phasen der eingebrachten Pausen werden ihre Zeiten nicht als zusätzliche Geschwindigkeitsrangfolge verwendet.
Eine Übertragung auf das ganze Modell hängt vom tatsächlichen Zeitanteil dieses Pfades ab. Belegte er beispielsweise ein Viertel einer Anfrage, ergäben 9,09 % lokale Zeitersparnis nur etwa 2,27 % weniger Gesamtzeit. Dieser Anteil ist eine Sensitivitätsannahme und keine gemessene Qwen-Aufteilung.
" }, { "heading": "Was die physische Näherung ergänzt", "html": "Ein ausgeführter OpenROAD-Vorvergleich verwendet gespeicherte Platzierungsdaten und Grobverdrahtungsführungen. Daraus werden Leitungsparasitiken geschätzt und Setup sowie Hold geprüft. Bei einer angenommenen Periode von 25 ns beträgt die Setupreserve 1,376 ns für die Referenz und 2,743 ns für die direkte Variante. Beide bestehen diesen Näherungsvergleich. Die Standardzellfläche ist 0,272 % kleiner, die geschätzte Leitungslänge 2,824 % kürzer.
Ein zusätzlicher Test verdoppelt Leitungswiderstände und Kapazitäten. Er ist ein künstlicher Belastungsfall und kein kalibriertes Prozessintervall. Die vollständigen Schlussdaten eines früheren Detailrouting-Laufs gingen beim Export verloren, zudem blieben Antennenverletzungen. Dieser Lauf liefert deshalb keinen abgeschlossenen physischen Nachweis. Die erhaltenen Grobverdrahtungsdaten erlauben eine konkrete Vorauswahl, aber keine nachträgliche Freigabe des fehlenden Endlayouts.
" }, { "heading": "Energieentscheidung und weitere Verwendung", "html": "Für die acht vermiedenen SRAM-Transaktionen lassen sich 810,9844 pJ interner Taktbogenenergie aus der Speicherbibliothek ableiten. Zusätzliche Steuerung, Direktverbindung, Taktlast und restliche Zellen fehlen in diesem Teilbetrag. Er ist keine Nettoenergieersparnis. Bei K = 64 dürfte die mittlere Leistung am gemeinsamen Takt höchstens etwa 4,10 % steigen, damit die kürzere Zeit überhaupt einen lokalen Energiegewinn ergibt.
Die Direktweitergabe bleibt als geprüfter Funktionsbaustein im Software- und RTL-Pfad erhalten. Der Versuch benennt zugleich den begrenzten Hebel: Eine kleine konstante Übergabekostenersparnis ersetzt keine Lösung für äußere Gewichtsbandbreite, größere Teilgraphen oder vollständige Systemenergie. Für weitere Vergleiche ist sie eine konkrete Ausgangsvariante mit reproduzierbaren Zugriffen, Protokollregeln und Taktzahlen.
" } ] }, { "id": "speicherwerkzeuge", "topic": "Speicher", "level": "Native DRAM-Simulation", "status": "Geprüft", "title": "Welche nutzbare Bandbreite liefert ein konkretes Speicherprofil?", "result": "51 native Speicherfälle", "paragraphs": [ "Ramulator 2 mit der integrierten Ayna-Energieberechnung liefert konkrete Controller- und DRAM-Zeiten. Profile, Queues und Reihenfolgen wurden in 51 nativen Fällen geprüft. Speicherenergie aus diesem Modell bleibt von gemessener Boardenergie getrennt.", "Eine zusätzliche Reihenfolgeoptimierung verbessert den Durchsatz im längeren Kontrolllauf nur um 0,143 % gegenüber der bereits verteilten Referenz. Mehr Queue- oder Scheduler-Varianten sind deshalb keine überzeugende Abkürzung zum großen Architekturvorsprung.", "Ein früheres 4,536-Sekunden-Teilzeitszenario übernahm GPU-Prefill als Anker und zählte Aktivierungsverkehr nicht vollständig. Der gekoppelte Folgetest zeigt diese Grenze. Diese alte Zahl ist ausdrücklich keine aktuelle Chipprognose." ], "boundary": "Speicherprofile und teilweise extrapolierte Energieparameter sind Modellannahmen. Die große angenommene Rechengeometrie ist nicht physisch belegt.", "decision": "Kapazität, gleichzeitig nutzbare Bandbreite und lokale Ports gemeinsam prüfen.", "source": "AR-010 Originalbericht", "source_sha256": "99203b2726cd457f02a16cdc22469047f62c3d3dcf7515af4b94559846c4bcd7", "abstract": "Kapazität, nominelle Transferrate und tatsächlich bediente Zugriffe sind unterschiedliche Eigenschaften. Native DRAM-Simulationen prüfen, wie Adressverteilung, Warteschlangen und Zugriffsreihenfolge den Speicherbeitrag eines modellnahen Systems bestimmen.", "sections": [ { "heading": "Das Arbeitsinventar vor der Bauteilauswahl", "html": "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.
" }, { "heading": "Ein ausgeführter DRAM-Simulator als Messinstrument", "html": "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.
" }, { "heading": "Bankparallelität verändert die tatsächlich bediente Rate", "html": "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.
" }, { "heading": "Kleine Optimierungen müssen längere Kontrollen bestehen", "html": "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.
" }, { "heading": "Speicherenergie und Gesamtenergie sauber verbinden", "html": "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.
" }, { "heading": "Warum der gekoppelte Folgetest die frühe Prognose korrigiert", "html": "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.
" } ] }, { "id": "gekoppelte-kanaele", "topic": "Speicher", "level": "Gekoppelte Ereignissimulation", "status": "Nicht weiterverfolgt", "title": "Wie viel Speicherbandbreite erreicht ein endliches Rechenarray?", "result": "5,421 versus 2,385 TB/s", "paragraphs": [ "160 simulierte Kanäle versorgen ein endliches Verhaltensarray. Ein Gewichtsrequest braucht vorher einen reservierten Antwortplatz. Rückstau, native DRAM-Antworten, FP32-Abhängigkeiten und Links beeinflussen sich im selben Lauf; ein Einzelkanalergebnis wird nicht einfach vervielfacht.", "Bei vollständiger Q-Projektion kommen 5,421 TB/s konsumierter Gewichtsverkehr an, bei MLP-down 2,385 TB/s. Größere Puffer helfen je nach Operator unterschiedlich. Nominalbandbreite ist keine überall verfügbare Nutzbandbreite.", "Der ungefuste zentrale Pfad produziert bereits im Prefill rund 183,493 GB Aktivierungsverkehr. Bei 6,4 GB/s braucht allein dieser Verkehr mindestens 28,671 Sekunden. Selbst eine optimistische Projektionsuntergrenze mit 256 GB/s verfehlt die geforderte Reserve für das Systemziel." ], "boundary": "Die 163.840 MAC-Einheiten bei angenommenen 1 GHz sind ein Verhaltensmodell, keine fertig realisierte Chipfläche. Keine vollständige Modellnumerik in diesem Simulator.", "decision": "Diese konkrete zentrale Abbildung nicht als großen Chip weiter auslegen.", "source": "AR-011 Originalbericht", "source_sha256": "c13c02102f83be59437478e68703dfccec0ae37242a88ddb94ff113d4bdecdb8", "abstract": "Die Summe nomineller Kanalbandbreiten sagt wenig über den tatsächlich verarbeiteten Gewichtsverkehr aus. Ein gekoppelter Simulator verbindet native DRAM-Antworten mit endlichen Puffern, Rechenabhängigkeiten und gemeinsam genutzten Datenwegen.", "sections": [ { "heading": "Vom unabhängigen Kanal zum rückgekoppelten Ablauf", "html": "Das C++-Frontend ConnectedArray ist mit einem festgelegten Ramulator-2-Quellstand kompiliert. DRAM-Timings, Controller, Scheduler und integrierte Ayna-Energieimplementierung bleiben unverändert. Ein Gewichtsrequest darf nur gestellt werden, wenn vorher ein Antwortplatz reserviert wurde. Dieser Platz wird erst nach Verarbeitung freigegeben. Speicherantworten, Rechenfortschritt und Rückstau beeinflussen sich somit während desselben Laufs.
Der große Fall enthält 160 simulierte Kanäle. Jeder besitzt einen eigenen Controller und Gewichtsdienst. Eine gemessene Einzelkanalzahl wird nicht einfach mit 160 multipliziert. Alle 23 vorher festgelegten Fälle liegen vollständig vor. Zwei wiederholte Kontrollen reproduzieren native Zeiten, Bandbreiten und Speicherenergie. Fehlgeschlagene Exportversuche bleiben von erfolgreich gesicherten einzelnen Ergebnissen getrennt dokumentiert.
" }, { "heading": "Welche Hardware der Simulator voraussetzt", "html": "Verwendet wird das Profil HBM4_32Gb_8Hi mit HBM4_8000Mbps, nominal 64 GB/s je Kanal. 160 Kanäle entsprechen fünf modellierten Stapeln mit zusammen 160 GiB Kapazität und 10,24 TB/s nomineller Bandbreite. Der Controller nutzt FRFCFSRowHit, offene Zeilen, All-Bank-Refresh und 128 Read-Queue-Einträge. Davon getrennt werden 8, 128 oder 512 reservierbare Antwortplätze zu je 32 Byte getestet.
Die Rechengeometrie umfasst je Kanal zwei Engines, 16 Ausgabelanes und 32 Tokenlanes. Das ergibt 163.840 angenommene MAC-Einheiten bei hypothetischen 1 GHz und vier Takten FP32-Rückkopplung. Die vorhandene kleine RTL-Kachel beweist weder diese Größe noch diese Frequenz. Untersucht werden vollständige Q-Formen mit N = 12.288 und K = 5.120 sowie MLP-down mit N = 5.120 und K = 17.408. K256-Schnitte sind gesondert ausgewiesen.
" }, { "heading": "Decode zeigt unterschiedliche Grenzen derselben Kanäle", "html": "| M = 1 | Konsumierte Gewichte | Kernelzeit |
|---|---|---|
| Q, 160 Kanäle, 8 Plätze | 2,132 TB/s | 59,803 µs |
| Q, 160 Kanäle, 128 Plätze | 5,421 TB/s | 23,989 µs |
| Q, 160 Kanäle, 512 Plätze | 5,822 TB/s | 22,390 µs |
| MLP-down, 160 Kanäle, 128 Plätze | 2,385 TB/s | 75,076 µs |
Mehr Antwortplätze verkürzen Q um 6,67 % und erhöhen seinen Durchsatz um 7,14 %. Der Payloadpuffer wächst dabei von 0,625 auf 2,5 MiB. MLP-down nutzt trotz derselben Kanäle deutlich weniger Bandbreite. Seine lange geordnete Summation liegt nahe der Abhängigkeitszeit von rund 69,6 µs. Mehr ankommende Gewichte können diese Kette nicht beliebig verkürzen.
Für M = 1 bleiben außerdem 31 der 32 Tokenpositionen ungenutzt. Die feste Arrayform passt damit anders zu Decode als zu Prefill. Eine umschaltbare Geometrie wäre ein neuer Entwurf und wird hier nicht kostenlos vorausgesetzt.
" }, { "heading": "Prefill braucht Wiederverwendung und genügend Eingabefenster", "html": "Im K256-Prefill-Schnitt mit M = 256 benötigen 128 Antwortplätze und vier Eingabeabschnitte 54,329 µs bei angenommenen 256 GB/s Aktivierungslink. 512 Plätze reduzieren diese Zeit nur auf 54,319 µs. 32 Eingabeabschnitte sind nicht schneller als vier. Ein einzelner Abschnitt verlängert die Zeit auf 58,402 µs. Zusätzliche Puffer helfen folglich nur, solange sie einen tatsächlichen Engpass beseitigen.
Der vollständige Q-Prefill mit K = 5.120 und M = 256 liefert während der nativen Rechnung 156,645 TMAC/s und benötigt einschließlich analytisch ergänzter Ausgabe 151,981 µs. Sein konsumierter Gewichtsverkehr beträgt 1,224 TB/s. Die niedrigere Bandbreite gegenüber Decode ist hier erwartbar, weil ein Gewicht für 256 Tokens verwendet wird. Das Ergebnis bezeichnet einen Operatorblock, nicht den gesamten Prefill mit 8.192 Tokens.
" }, { "heading": "Eine Untergrenze kann einen Aufbau früh ausschließen", "html": "Die ergänzende Bilanz verwendet alle 16 gruppierten Projektionsformen des archivierten Inventars, 8.192 Prefill-Tokens, einen letzten lm_head-Schritt und 255 weitere Decode-Schritte. In der untersuchten Abbildung lädt jede nicht zusammengefasste Operation ihren Input und schreibt FP32-Ausgaben über denselben zentralen Pfad. Allein im Prefill entstehen 183.493.414.912 Byte Aktivierungsverkehr.
Bei 6,4 GB/s benötigen diese Transfers mindestens 28,671 Sekunden. Selbst der optimistische Fall mit 256 GB/s und M256-Blöcken ergibt für sämtliche Projektionen 5,368 Sekunden. Für das historische 5,429-Sekunden-Ziel mit 10 % Reserve dürften sie höchstens 4,886 Sekunden benötigen. Andere Modelloperatoren sind in dieser günstigen Untergrenze noch nicht enthalten. Damit wird diese konkrete zentrale Abbildung ausgeschieden, ohne einen großen Layoutlauf zu benötigen.
" }, { "heading": "Kapazität, lokale Ports und Energie bleiben eigene Größen", "html": "Die größte Projektion benötigt mindestens 20,4375 MiB gezählten Payloadspeicher. Dazu kommen Tags, Controller, ECC und weitere Zustände. Bei voller angenommener Auslastung entstehen logisch bis zu 1,31072 PB/s verteilte FP32-Akkumulatorzugriffe. Dies ist lokaler Verkehr, keine zusätzliche HBM-Forderung. Register, Banking und Weiterleitung müssen seine physischen Ports und seinen Fanout erst realisieren.
Ayna liefert beispielsweise 5,157 mJ Speicherenergie für Q-Decode mit 128 Plätzen. Rechenlogik, lokale Speicher, Host-PHY, Versorgung und die Warteenergie des analytischen Ausgabeabschnitts fehlen. Gesamtenergie und vollständige Modelllaufzeit bleiben deshalb unbestimmt. Der Simulator erzeugt auch keine vollständigen BF16-Qwen-Ausgaben. Sein Ergebnis ist eine belastbare Ressourcen- und Engpassprüfung, aus der der anschließende verbundene MLP-Versuch mit lokalen Zwischenwerten hervorgeht.
" } ] }, { "id": "lokaler-mlp", "topic": "Software", "level": "Numerik + Portmodell", "status": "Funktion bestätigt", "title": "Wann beschleunigen lokale Zwischenwerte einen vollständigen MLP-Teilgraphen?", "result": "17 Variantenpaare geprüft", "paragraphs": [ "Gate und up werden über SiLU und ein BF16-Produkt mit down verbunden. Die Numerik hält BF16-Eingaben, fortgesetzte FP32-FMA und eine gemeinsam definierte SiLU-Tabelle fest. Lokale Puffer und Summenzusammenführungen bleiben Teil der Bilanz.", "13 native Zahlenwertfälle und 17 begrenzte Variantenpaare sind geprüft. Bei schmaler Verbindung kann lokale Weitergabe im Prefill bis ungefähr 30 % Modellzeit sparen. Bei stärkerer zentraler Referenz und im Decode verschwindet der Vorteil weitgehend; bei schnellem Netz kann die direkte Steuerung langsamer werden.", "Selbst ein hypothetisch kostenloser MLP-Teil reicht im alten seriellen 6,4-GB/s-Pfad nicht für das 5,429-Sekunden-Ziel. Die übrigen Operatoren und Aktivierungstransfers bleiben bestehen." ], "boundary": "Das Zeitmodell besitzt angenommene Ports und Frequenzen. Es ist keine neue vollständige Qwen-Ausführung und kein RTL-Layout des großen MLP.", "decision": "Den verbundenen Teilgraphen und die Vergleichsfälle für lokale Datenversorgung weiterverwenden.", "source": "AR-012 Originalbericht", "source_sha256": "a3b1edbb74b02fd0607dded2b623aa856dc17c43149d58a9d4bff15a9e5398d4", "abstract": "Gate, up, Aktivierungsfunktion und down bilden einen verbundenen Rechenabschnitt. Wir prüfen zwei Wege für seine Zwischenwerte bei gleicher Numerik, endlichen Puffern und gezählten Ports. Entscheidend ist, ob die direkte Verbindung auch gegen eine bereits überlappende zentrale Referenz gewinnt.", "sections": [ { "heading": "Drei Projektionen mit einem gemeinsamen Zahlenvertrag", "html": "Der untersuchte Teilgraph besitzt D = 5.120 Eingaben, H = 17.408 Zwischenwerte und O = 5.120 Ausgaben. Gate und up berechnen zwei Projektionen derselben Eingabe. Anschließend entsteht der Zwischenvektor aus SiLU(gate) × up. Down projiziert ihn zurück in die Ausgabedimension. Diese Topologie entspricht dem archivierten Modellinventar.
Beide Datenwege verwenden BF16-Eingaben und -Gewichte sowie fortlaufende FP32-FMA in aufsteigender K-Reihenfolge. Gate und up werden auf BF16 gerundet. SiLU verwendet eine festgelegte gemeinsame Tabelle, danach folgt ein BF16-Produkt. Down akkumuliert wieder in FP32 und rundet abschließend auf BF16. Die Tabelle definiert den Vergleichsvertrag, aber keine universelle Bitgleichheit zu jedem GPU-Backend. Ihre 87 zusätzlich mit hoher Dezimalpräzision geprüften Werte ersetzen keinen erschöpfenden Nachweis aller transzendenten Rundungsgrenzen.
" }, { "heading": "Funktion prüfen, bevor Datenwege bewertet werden", "html": "Dreizehn deterministische Fälle prüfen verschiedene Formen, Tokenzahlen, ungleiche Modulaufteilungen und Restpakete. Ein Fall verwendet sechs echte archivierte Gate-Gewichtszeilen mit K = 5.120. Eingaben sowie up und down bleiben dort synthetisch. Eine unabhängige Python-Integer-FMA erzeugt Erwartungswerte. C++ std::fma berechnet sowohl den zentral abgelegten Zwischenvektor als auch den Streamingpfad. Alle 3.621 geprüften FP32- und BF16-Werte stimmen überein.
Der Vertrag verteilt Ausgabezeilen der Down-Projektion. Jedes Modul behält die vollständige geordnete Summe seiner Ausgaben. Eine alternative Verteilung über K würde lokale Teilsummen erzeugen. Sie liefert bereits 38 andere FP32-Ausgaben in den Testfällen. Ein gerichteter Fall mit den Produkten 2²⁴, 1 und −2²⁴ zeigt außerdem ein anderes BF16-Ergebnis. Deshalb wird eine solche Umordnung hier nicht als kostenlose Parallelisierung zugelassen.
" }, { "heading": "Die zentrale Referenz darf bereits überlappen", "html": "Beide Varianten besitzen dieselben 160 Module, Gewichtsquellen und lokalen SiLU-Produkt-Stufen. Die Referenz schreibt Zwischenpakete in einen begrenzten zentralen Ring und verteilt sie von dort an down. Sie darf Schreiben, Lesen und Rechnen überlappen. Der Kandidat überträgt direkt per Multicast. Reservierte Quell- und Empfangsplätze bleiben bis zur tatsächlichen Übergabe belegt.
Der zentrale Ring fasst acht Pakete, je Quelle und Empfänger sind zwei Plätze vorgesehen. Ein Paket enthält 16 Features über den Tokenblock. Bei M = 256 vermeidet die direkte Variante 17.825.792 Byte zentrale SRAM-Zugriffe und 8.912.896 Byte zusätzliche Netzeinspeisung je MLP. Empfangskopien und Multicast-Baumkanten bleiben erforderlich. Die äußere Gewichtsmenge ist in beiden Fällen 534.773.760 Byte. Entfallene zentrale Zugriffe sind somit nur ein Teil der gesamten Datenbewegung.
" }, { "heading": "Die Rangfolge hängt von Verbindung und Ports ab", "html": "SimPy 4.1.2 bildet konkurrierende Dienste, endliche Puffer und Rückstau ab. Der Gate/up-Anteil verwendet eine optimistische Ressourcenhülle, die Down-Gewichtszufuhr einen idealen begrenzten Dienst. Es wurde in dieser Runde kein neuer Ramulator-Lauf ausgeführt. DRAM-Kommandokonflikte und Refreshverluste werden deshalb nicht vollständig neu bestimmt. Alle 17 vorher festgelegten Variantenpaare sind ausgeführt und archiviert.
| Tokens / Link | Zentral | Direkt | Direkter Effekt |
|---|---|---|---|
| M1 / 6,4 GB/s | 112,376 µs | 112,369 µs | 0,006 % kürzer |
| M32 / 6,4 GB/s | 542,091 µs | 385,369 µs | 28,91 % kürzer |
| M256 / 6,4 GB/s | 4.198,619 µs | 2.945,059 µs | 29,86 % kürzer |
| M256 / 64 GB/s | 790,821 µs | 790,547 µs | 0,035 % kürzer |
| M256 / 256 GB/s | 586,275 µs | 655,475 µs | 11,80 % länger |
Der zentrale Ring kann Arbeitsphasen entkoppeln und Pakete früher bereitstellen. Zwei nachträgliche Portkontrollen zeigen, dass breitere lokale Ports die Zeitumkehr verändern. Sie sind ausdrücklich explorative Ursachenprüfungen und keine zusätzlichen vorab festgelegten Vergleichsfälle.
" }, { "heading": "Lokale Zustände sind der nächste physische Engpass", "html": "Die direkte M256-Variante benötigt 69,9375 MiB Payloadspeicher, die zentrale Referenz 70 MiB. Der Kapazitätsgewinn beträgt lediglich 64 KiB, weil der zentrale Ring bereits klein ist. Enthalten sind unter anderem 34 MiB Gate/up-Summen, 5 MiB Down-Summen und insgesamt 20 MiB replizierte SiLU-Tabellen. Controller, ECC und Banking kommen hinzu.
Die schnelle Arrayannahme verlangt 8.192 Byte Akkumulatorzugriffe je Modul und angenommenem 1-GHz-Zyklus. Eine naive Umsetzung mit je einem vorhandenen 8-KiB-IHP-Makro pro 64-Bit-1RW-Port würde allein rund 43.245 mm² Makrofläche benötigen. Das ist keine allgemeine Untergrenze für Register oder andere Prozesse. Es zeigt, dass eine kleine gespeicherte Datenmenge noch keine realisierbare Portzahl garantiert. Bei nur 512 Byte Akkumulatorzugriff steigt derselbe direkte M256-Modellfall auf etwa 6.882 µs statt rund 791 µs.
" }, { "heading": "Was der verbundene Teilgraph für das Systemziel leistet", "html": "Die lokale Weitergabe ist funktional bestätigt und kann bei schmaler Verbindung erhebliche Modellzeit sparen. Sie liefert aber keinen allgemeinen Sieger. In einer ergänzenden seriellen BF16-Abbildung bewegen die übrigen Prefill-Projektionen ohne MLP noch 48.662.821.888 Byte. Bei 6,4 GB/s benötigen allein diese Transfers mindestens 7,604 Sekunden. Selbst ein kostenloser MLP könnte diesen konkreten Aufbau nicht unter das historische 5,429-Sekunden-Ziel bringen.
Gesamtenergie bleibt nicht bestimmt. Die entfallenden zentralen Zugriffe stehen weiteren Kopien, Ports, Tabellen und Steuerung gegenüber. Der Versuch begründet deshalb die nächste engere Frage nach lokalen FP32-Registern und Gewichtsblock-Wiederverwendung. Er hält den funktionierenden Teilgraphen fest, ohne aus einer bedingten Teilzeit eine vollständige Qwen-Laufzeit oder einen Siliziumvorteil abzuleiten.
" } ] }, { "id": "register-bloecke", "topic": "Speicher", "level": "Native Numerik + Mengenbilanz", "status": "Verkehr reduziert", "title": "Wie lassen sich lokale Summen und wiederverwendete Gewichte verbinden?", "result": "98,44 % weniger Kontext-SRAM-Verkehr", "paragraphs": [ "Ein K64-Gewichtsblock wird über 128 Tokenkontexte wiederverwendet. FP32-Summen bleiben innerhalb des Blocks in Registern; nur an Blockgrenzen wechseln sie in den Kontextspeicher. Dadurch steigt die äußere Gewichtslesemenge im verglichenen Plan nicht.", "Für den M256-Fall sinkt der Akkumulator-SRAM-Verkehr von 547,649 auf 8,556 GB. Dafür werden 2,5 MiB Register und 15 MiB Kontext-SRAM benötigt. 208 native Ausführungen vergleichen insgesamt 1.391.780 Zahlenwerte und 2.288 Verkehrsgrößen ohne Abweichung.", "Diese große Ersparnis bezieht sich auf die vorherige SRAM-Abbildung vieler Kontexte. Die kleine RTL-Kachel hielt eine einzelne Summe schon zuvor in Registern. Deshalb sind die 98,44 % kein zusätzlicher Gewinn gegenüber dieser Kachel oder einer GPU. Bei breiten Ports und Einzel-Decode entsteht im getesteten Modell kein Zeitvorteil." ], "boundary": "Verkehrsreduktion ist keine Energiereduktion. Registerfläche, Auswahl, Taktlast und reale Ports müssen erst physisch bilanziert werden.", "decision": "Die nachgerechnete Verkehrsreduktion und ihre Portbedingungen als Grundlage der anschließenden physischen Kontextvergleiche sichern.", "source": "AR-013 Originalbericht", "source_sha256": "c2a0678e443894d70a3bd106da7bf9f1ae3bcfeca21806f7591c4a42fde9ca69", "abstract": "Viele Tokenkontexte entlasten die äußere Gewichtsversorgung, erhöhen aber den Bedarf an lokalen Akkumulatorzugriffen. Ein blockweiser Ablauf untersucht, wie FP32-Summen in Registern bleiben können, ohne dieselben Gewichte häufiger aus dem äußeren Speicher zu lesen.", "sections": [ { "heading": "Zwei Datenströme müssen gleichzeitig günstig bleiben", "html": "Eine dichte MLP-Rechnung muss Gewichte und laufende Summen bereitstellen. Ein Gewicht kann für viele Tokens wiederverwendet werden. Werden sämtliche Tokenkontexte jedoch im SRAM gehalten, benötigt die modellierte Akkumulation sehr viele lokale Lese- und Schreibzugriffe. Vollständig in Registern bearbeitete kleine Tokenkacheln vermeiden diese Zugriffe, müssen dafür womöglich Gewichte erneut laden.
Untersucht wird deshalb ein K64/T128-Plan. Ein Gewichtsblock aus 64 Summenschritten bleibt im Cache, während 128 Tokenkontexte nacheinander rechnen. Innerhalb des Blocks bleiben die FP32-Summen in Registern. Erst an Blockgrenzen werden sie exakt gespeichert oder wiederhergestellt. Diese Anordnung bewahrt die Gewichtsreihenfolge und vermeidet zusätzliche äußere Gewichtsladungen im gewählten Vergleich.
" }, { "heading": "Ein definierter MLP und mehrere ausführbare Pläne", "html": "Die Form lautet D = 5.120, H = 17.408 und O = 5.120. Gate und up werden über SiLU und ein BF16-Produkt mit down verbunden. Eingaben und Gewichte sind BF16, die fortlaufende FMA-Summe ist FP32. Die Reduktionsreihenfolge über K bleibt aufsteigend. FP32-Speicherung an Blockgrenzen führt keine zusätzliche Rundung ein.
Eine Python-Integer-FMA bildet die unabhängige Referenz. Ein ohne Fast-Math kompiliertes C++-Modell verwendet std::fma. Sechzehn Zahlenwertfälle werden mit dreizehn Plänen ausgeführt. Insgesamt stimmen 1.391.780 geprüfte Werte und 2.288 Verkehrsgrößen in 208 Ausführungen ohne Abweichung überein. Darunter sind ungerade Formen, Restblöcke und 65, 129 beziehungsweise 257 Tokens. Ein Fall verwendet sechs archivierte echte Gate-Zeilen, die übrigen Gewichte sind überwiegend synthetisch.
Diese Zählung umfasst wiederholte Werte in verschiedenen Plänen. Sie bezeichnet keine entsprechende Zahl unabhängiger Modelllasten. Ausnahmeflags und vollständige Qwen-Antwortqualität werden in diesem Versuch nicht geprüft.
" }, { "heading": "Die Mengenbilanz des Gewichtsblocks", "html": "| M256-Plan | Äußere Gewichte | Akkumulator-SRAM | Akkumulatorregister |
|---|---|---|---|
| SRAM-Referenz | 0,535 GB | 547,649 GB | keine zusätzlichen Kontextregister |
| Dauerhaft T32 | 4,278 GB | 0 | 1,875 MiB |
| Dauerhaft T128 | 1,070 GB | 0 | 7,5 MiB |
| K64/T128 | 0,535 GB | 8,556 GB | 2,5 MiB |
Der ausgewählte Plan reduziert den logischen Akkumulator-SRAM-Verkehr um 98,44 %. Die äußeren Gewichtsbytes bleiben exakt 534.773.760 je MLP. Die großen GB-Zahlen sind über den Auftrag kumulierte Zugriffe und keine benötigte Speicherkapazität. Die kleine bestehende RTL-Kachel hält eine einzelne Summe bereits in Registern. Die 98,44 % beziehen sich auf die vorherige SRAM-Abbildung vieler Kontexte und nicht auf einen zusätzlichen Vorteil gegenüber dieser Kachel oder einer GPU.
" }, { "heading": "Unter welchen Portbedingungen entsteht ein Zeitgewinn?", "html": "Das Zeitmodell verwendet 160 Module mit je zwei Engines, 16 Ausgabe- und 32 Tokenlanes. Zusammen sind das 163.840 angenommene MAC-Einheiten. Die Frequenz von 1 GHz ist eine Annahme. Gewichte, Eingaben, Rechnen und Kontextwechsel werden in expliziten Phasen bilanziert. Es gibt weder kostenloses Vorladen noch unbegrenzte Puffer. Gate, up und down teilen dieselben Rechenwerke.
Bei M = 256, einem 64-GB/s-Link und 512 Byte Akkumulator-SRAM-Zugriff pro Modul und Zyklus sinkt die modellierte Zeit von 8,164 auf 2,325 ms. Dieser bedingte Vorteil von 71,53 % ist eine Aussage über die knappe SRAM-Abbildung. Bei 8.192 Byte pro Zyklus benötigt die Referenz 2,201 ms und der Kontextplan 2,225 ms. Er ist dann 1,11 % langsamer. Für M = 1 benötigt er rund 0,50 % mehr Zeit. Die Portbreite entscheidet also wesentlich über die Rangfolge.
" }, { "heading": "Kapazität und dynamische Energie verschwinden nicht", "html": "K64/T128 benötigt zusätzlich zu 2,5 MiB Akkumulatorregistern insgesamt 15 MiB FP32-Kontext-SRAM. Gewichtscache, replizierte Eingabepuffer, lokale Zwischenwerte, globale Ein- und Ausgaben, Antwort-FIFOs und SiLU-Tabellen bleiben erhalten. Eine gemeinsame obere Referenz für FMA-Pipelineregister führt zu 51,25 MiB gezähltem Payload und Bitzustand. Tags, ECC, Taktverteilung und konkrete Bankinglogik sind darin noch nicht physisch ausgelegt.
Der Plan führt weiterhin etwa 547,608 GB laufende Registerzugriffe aus. Der Speicherort ändert sich, die Summenaktualisierung nicht. Bei gleicher äußerer Gewichtsmenge muss ein Registerbyte einschließlich der erfassten Transfers weniger als ungefähr 96,93 % der Energie eines SRAM-Bytes benötigen, damit der dynamische Tausch günstiger wird. Zusätzliche Leck- und Taktenergie fehlt in dieser Bedingung. Eine Koeffizientensensitivität mit 27 Kombinationen ergibt günstige und ungünstige Fälle, keine Erfolgswahrscheinlichkeit.
" }, { "heading": "Von einer Verkehrsersparnis zur physischen Prüfung", "html": "Die C++-Ausführungen und unabhängigen Zähler zeigen, dass die geplante Gewichts- und Kontextbewegung funktional konsistent ist. Die Laufzeiten des C++-Programms selbst sind keine Chipzeiten. Auch die angenommene große Rechengeometrie, ihre Ports und ihre Frequenz sind nicht durch diesen Versuch realisiert.
Der Befund begründet einen engen Folgeschritt: vier lokale Kontexte je Lane im bestehenden RTL mit tatsächlicher Auswahl, Taktlast und Speicheranschlüssen vergleichen. Genau diese Frage untersuchen die separaten Berichte zu vier Kontexten und zur aktiven Summe. Ihre Layout- und Aktivitätswerte ergänzen die hier gemessenen Mengen. Dadurch bleibt die große Verkehrsersparnis überprüfbar, ohne sie vorzeitig in einen unbelegten Gesamtenergiegewinn umzudeuten.
" } ] }, { "id": "vier-kontexte", "topic": "Hardware", "level": "Vollständiges kleines Layout", "status": "Geprüft", "title": "Rechtfertigen vier Registerkontexte ihre zusätzliche Auswahlhardware?", "result": "9,77 % höhere Kachelenergie", "paragraphs": [ "Vier identische HardFloat-Lanes und dieselbe 8-KiB-SRAM wurden in IHP SG13G2 fertig platziert und verdrahtet. Die Referenz hält bereits einen Kontext je Lane in Registern; der Kandidat vier. Vergleichsbedingungen sind TT 1,20 V, 25 °C, derselbe Floorplan und 50 ns Takt.", "Im Hauptfall sinken die Takte von 572 auf 520. Die minimale extrahierte Taktperiode steigt jedoch von 17,33 auf 20,15 ns. Mit den jeweiligen Timinggrenzen gerechnet braucht der Kandidat 5,70 % mehr Zeit. Seine aktive Zellfläche ist 8,88 % größer.", "Die Energieauswertung mit bedingten Zell- und Leitungsverzögerungen liefert am gemeinsamen Takt 276,169 gegenüber 303,155 nJ: 9,77 % mehr Energie trotz weniger Takte. Im Einzelkontext steigt die Energie um 12,42 %. Die Auswahl zwischen den Summen liegt im kritischen FMA-Pfad.", "Sechs RTL-Fälle mit 88.704 FMAs je Variante, zwei gemappte Aktivitätsfälle je Variante, neun Simulator-Kontrollen sowie ein Offline-Audit der Rohbelege bestanden. Bei häufigeren Kontextwechseln gibt es günstigere Zeitfälle; sie ersetzen den festgelegten Hauptfall und seine Energiebilanz nicht." ], "boundary": "Vollständiger kleiner Rechen-/Kontextblock, nicht das gesamte Modell. Energie ist aus Bibliotheken, extrahierten Leitungen und Aktivität berechnet, nicht am Silizium gemessen.", "decision": "Diese direkte Auswahlvariante nicht vergrößern. Der abgeschlossene Folgetest „Aktiver Kontext“ verbessert das Timing, verfehlt aber ebenfalls das kombinierte Energieziel.", "source": "AR-014 Originalbericht", "source_sha256": "92471f07a921ee23545bd2c5f34f581d4ebb985d4974d2e6f2bade3abbe7a197", "abstract": "Register können Kontexttransfers zum SRAM vermeiden. Sie benötigen aber Auswahlpfade, Taktlast und Verdrahtung. Zwei vollständige kleine Layouts prüfen, ob die eingesparten Transaktionen bei identischer Rechenarbeit tatsächlich kürzere Zeit und geringere Energie ergeben.", "sections": [ { "heading": "Die Hypothese betrifft den Kontextwechsel", "html": "Die Referenz besitzt vier HardFloat-Lanes für BF16-Produkte mit fortlaufender FP32-FMA. Jede Lane hält ihre aktive Summe bereits in einem Register. Nur bei einem Wechsel wird ein anderer Kontext aus dem SRAM geladen oder dorthin zurückgeschrieben. Der Kandidat hält vier Summenkontexte je Lane direkt in Registern und wählt den angeforderten Kontext vor der Rechnung aus.
Die Akkumulatorregister wachsen dadurch von 128 auf 512 Bit. Die 80 Ausnahmeflag-Bits bleiben gleich. Eingabekommandos, Operanden, Hostanschlüsse und die 8-KiB-SRAM mit 64-Bit-1RW-Anschluss sind identisch. Der Versuch prüft somit den Preis einer zusätzlichen lokalen Kontextauswahl. Er vergleicht nicht Registerakkumulation mit einem künstlichen SRAM-Zugriff nach jeder FMA.
" }, { "heading": "Numerik, Arbeitsmenge und primäre Entscheidung", "html": "Der Hauptfall umfasst K = 128, vier Kontexte und Blöcke mit 64 Summenschritten. Beide Varianten führen 2.048 Lane-FMAs aus. Ein Gegenfall verwendet nur einen Kontext. Weitere Tests enthalten kürzere Blöcke, K = 131 mit Rückstau, vier reale Gate-Gewichtszeilen mit K = 5.120 sowie gerichtete Sonderwerte. Die Reihenfolge über K bleibt erhalten. Eine Split-K-Umordnung oder reduzierte Präzision wird nicht verwendet.
Sechs RTL-Fälle mit 88.704 FMAs je Variante bestehen eine unabhängige Integer-Floating-Point-Referenz einschließlich Ausgabebits, Ausnahmeflags und Zugriffszähler. Zwei Fälle werden zusätzlich auf den gemappten Netzlisten geprüft. Die Leistungsentscheidung bleibt am vorher festgelegten Hauptfall orientiert. Ein besonders günstiger Fall mit häufigen Kontextwechseln ersetzt ihn nicht nachträglich.
" }, { "heading": "Vom RTL zu vergleichbaren Layouts", "html": "Beide Schaltungen werden in IHP SG13G2 mit identischem 1.600 × 1.200 µm großen Floorplan und derselben Flussversion platziert und verdrahtet. Die Randbedingungen sind TT, 1,20 V, 25 °C und 50 ns Zieltakt. Detaillierte Verdrahtung meldet keine DRC- oder Antennenverletzungen. Extrahierte Setup- und Hold-Prüfungen bestehen. Funktionale Parasitiken und Versorgung sind erfasst, unverbundene Taktbaum-Dummy-Ausgänge einzeln dokumentiert.
Die Die-Fläche von 1,92 mm² ist für beide gleich und bewusst großzügig gewählt. Sie ist nicht mit der aktiven Zellfläche gleichzusetzen. Der Vergleich verwendet einen gemeinsamen Flächenoptimierungsmodus. Er beweist daher weder eine minimale Fertigungsfläche noch die Unvermeidlichkeit des Befunds für jede denkbare Vier-Kontext-Implementierung.
" }, { "heading": "Weniger Takte können trotzdem länger dauern", "html": "| Größe im Hauptfall | Ein Kontext | Vier Kontexte |
|---|---|---|
| Arbeitstakte | 572 | 520 |
| Aktive Instanzfläche | 490.120 µm² | 533.624 µm² |
| Standardzellfläche | 226.174 µm² | 269.678 µm² |
| STA-Minimalperiode | 17,33 ns | 20,15 ns |
| Takte × eigene STA-Grenze | 9,913 µs | 10,478 µs |
Vier Kontexte vermeiden im Hauptfall je 16 SRAM-Lese- und Schreiboperationen. Am gemeinsamen Takt sinkt die Zeit um 9,09 %. Die aktive Instanzfläche steigt um 8,88 %, die Standardzellfläche um 19,23 %. Vor allem verlängert sich der kritische Pfad. Er startet beim Kandidaten am Kontextauswahlsignal und endet im Summenregister. Auswahl, Fanout und FMA liegen auf derselben zeitbestimmenden Strecke.
Mit den jeweiligen gerundeten STA-Minimalperioden gerechnet wird der Kandidat dadurch 5,70 % langsamer. Diese Grenzrechnung ist keine dynamische Ausführung bei maximaler Frequenz. Im Block16-Fall spart die Variante dagegen 27,37 % Takte und 15,56 % rechnerische STA-Grenzzeit. Der Nutzen hängt somit vom Verhältnis zwischen Kontextwechseln und Rechenarbeit ab.
" }, { "heading": "Verzögerungsabhängige Aktivität statt Zugriffszähler allein", "html": "Die Energieauswertung verwendet gemappte Netzlisten mit bedingten Zell- und extrahierten Leitungsverzögerungen. CVC führt die Aktivitätsfälle aus, OpenSTA liefert die Leistungsmodelle. Neun positive und absichtlich fehlschlagende Kontrollen prüfen die Simulatorpfade. Dokumentierte Kompatibilitätsadapter erhalten die numerischen Propagationsverzögerungen. Statische Timingprüfungen verwenden die Originaldaten, dynamische Setup- und Hold-Notifier sind nicht vollständig qualifiziert.
Bei 50 ns benötigt die Referenz im Hauptfall 276,169 nJ und der Kandidat 303,155 nJ. Das sind 9,77 % mehr modellierte Energie trotz weniger Takte. Im Einzelkontext steigt sie von 65,711 auf 73,875 nJ, entsprechend 12,42 %. Gezählt werden Standardzellen, Registerauswahl, Taktverteilung, SRAM, Leckstrom und extrahierte Leitungen. Frühere Werte ohne Verzögerungen bleiben getrennte Zwischenstände und werden nicht mit diesen Ergebnissen vermischt.
" }, { "heading": "Die Ursache wird zur nächsten überprüfbaren Hypothese", "html": "Die direkte Vierfachauswahl besteht die kombinierte Zeit- und Energiehürde für den Hauptfall nicht. Der Befund ist konstruktiv: SRAM-Transaktionen verschwinden, während reale Auswahlhardware und Schaltaktivität hinzukommen. Der nächste Vergleich hält deshalb die aktive Summe fest am FMA und wählt weitere Kontexte nur beim Blockwechsel. Dessen Ergebnisse sind im separaten Bericht zum aktiven Kontext beschrieben.
Der vorliegende Versuch betrifft den kleinen Rechen- und Kontextblock. Externe Gewichte, Operandenquellen, übrige Modelloperationen, Spannungswandler und Kühlung fehlen in der Energiegrenze. Die Modelle ersetzen keinen industriellen Mehr-Ecken-Signoff oder eine Messung am gefertigten Chip. Sie reichen jedoch aus, diese konkrete Implementierung unter den angegebenen Bedingungen fachlich begründet nicht als bevorzugtes großes Array weiterzuentwickeln.
" } ] }, { "id": "ki-synthese", "topic": "KI-Entwurf", "level": "Replay realer Synthesemessungen", "status": "Geprüft", "title": "Findet KI gute Syntheserezepte mit weniger Werkzeugaufrufen?", "result": "8 Aufrufe: feste Regel und Entscheidungsbaum", "paragraphs": [ "Elf trainierte Verfahren und vier feste Regeln wählten aus sechs Syntheserezepten. In jeder Falte wurde eine vollständige Schaltung zurückgehalten; die übrigen 30 Messwerte dienten als Trainingsbasis. Ziel war eine funktional geprüfte Netzliste innerhalb von 1 % der besten Rasterfläche.", "Standardrezept zuerst, diversifizierte Übertragung und ein einzelner Entscheidungsbaum erreichen sechs von sechs Aufgaben mit insgesamt acht Aufrufen. Für den Baum kommt das Training hinzu. LightGBM und XGBoost treffen fünf von sechs. Der Vergleich spielt 36 zuvor ausgeführte Yosys-Synthesen nach; es sind keine neuen 36 Layouts.", "Für diese kleine Aufgabenmenge kann selbst ein perfekter Erstvorschlag nur zwei der acht Aufrufe sparen. Die größte Chance liegt deshalb nicht unbedingt in einem komplexeren Lernmodell. TabPFN, SAC und Transformer wurden in dieser Runde nicht ausgeführt und werden nicht als getestet dargestellt." ], "boundary": "Explorative Auswertung weniger Schaltungen. Die Rangfolge ist keine allgemeine Aussage über Lernverfahren oder den gesamten Chipdesignprozess.", "decision": "Starke feste Regeln beibehalten. KI nur an Aufgaben messen, an denen Fehler, Suchkosten und Gesamtaufwand tatsächlich reduziert werden können.", "source": "AR-015 Originalbericht", "source_sha256": "7ef87c0834bac3fb30d94311fd9dfd91594d20dffd1b77c295353c4a61f1390e", "abstract": "Die Wahl eines Syntheserezepts verändert die Fläche einer digitalen Schaltung. Wir untersuchen, ob trainierte Modelle erfolgversprechende Rezepte besser priorisieren als einfache Regeln. Grundlage sind 36 tatsächlich ausgeführte und funktional geprüfte Yosys-Synthesen.", "sections": [ { "heading": "Eine überprüfbare Aufgabe für lernende Verfahren", "html": "Ein KI-Verfahren kann im Chipentwurf Vorschläge priorisieren, bevor teure Werkzeuge sie ausführen. Dazu muss es nicht nur gute Entwürfe finden. Es muss einschließlich Datengewinnung, Training und Fehlversuchen weniger Aufwand verursachen als ein sinnvoll gewähltes einfaches Verfahren. Unser Versuch grenzt diese Frage auf die Auswahl aus sechs Syntheserezepten ein.
Der Archivdatensatz enthält sechs unterschiedliche RTL-Schaltungen mit jeweils sechs ausgeführten Rezepten. Ein Flächenwert wird nur zugelassen, wenn die abgebildete Netzliste den zugehörigen Funktionstest bestanden hat. Das Ziel ist eine gültige Zellfläche höchstens 1 % oberhalb des besten gültigen Rezepts im jeweiligen Raster. Dieses Rasterminimum ist eine Referenz innerhalb des Versuchs und kein bewiesenes globales Schaltungsoptimum.
" }, { "heading": "Ganze Schaltungen werden vom Training getrennt", "html": "Die Auswertung umfasst sechs Falten. In jeder Falte bleiben sämtliche sechs Messwerte einer Schaltung beim Training außen vor. Die anderen fünf Schaltungen liefern gemeinsam 30 Messwerte. Dadurch kann ein Modell nicht einfach andere Rezepte derselben Testschaltung im Training sehen. Zwischen den Falten überlappen die Trainingsdaten. Die sechs Falten sind deshalb keine sechs unabhängigen großen Studien.
Als Eingaben dienen vier logarithmierte generische Zellzähler, die Rezeptkennung und deren Wechselwirkung. Das Lernziel ist der Flächenquotient zum kleinsten gültigen Rezept der jeweiligen Trainingsschaltung. Parameter und Zufallsstart sind vor dem Vergleich festgelegt. Die Testschaltung wird erst anhand der vorgeschlagenen Rangfolge ausgewertet. Der gesamte Vergleich bleibt explorativ, weil das zugrunde liegende Archiv bereits bekannt war.
" }, { "heading": "Elf Modelle und vier einfache Kontrollen", "html": "Ausgeführt wurden Entscheidungsbaum, Extra Trees, Random Forest, Gradient Boosting, Histogram Gradient Boosting, LightGBM, XGBoost, K-Nearest Neighbors, Ridge, RBF-SVR und ein kleines neuronales Netz. Vier feste Strategien bilden die Kontrolle. Sie beginnen mit dem Standardrezept oder übertragen mittlere Werte, die nächste ähnliche Trainingsaufgabe beziehungsweise verschiedenartige Voroptimierungen.
Eine Aufgabe zählt nach einem, zwei oder drei Aufrufen als gelöst, sobald das beste bis dahin ausgewählte Rezept das 1-%-Ziel erreicht. Trainierte Verfahren erhalten denselben Datenstand. Neben den Aufrufen werden Fitzeit und Rangbildungszeit erfasst. Die Werkzeugzeit wird aus den tatsächlich gemessenen Laufzeiten der ausgewählten Archivrezepte rekonstruiert. Diese Auswertung startet keine neuen Synthesen und keine Layoutläufe.
" }, { "heading": "Was der Vergleich tatsächlich ergibt", "html": "Standardrezept zuerst, diversifizierte Übertragung und der einzelne Entscheidungsbaum lösen jeweils fünf von sechs Aufgaben mit dem ersten Aufruf. Nach spätestens drei Aufrufen je Aufgabe erreichen sie alle sechs Ziele. Über die Aufgaben summiert benötigen diese drei Strategien jeweils acht Aufrufe. Für dieselben ausgewählten Fälle entstehen 92,44 Sekunden rekonstruierte Archiv-Werkzeugzeit. Beim Baum kommen Trainingsdaten und Fitzeit hinzu.
LightGBM und XGBoost erreichen das Ziel innerhalb des Limits auf jeweils fünf Schaltungen. Beim Addierer verfehlen sie es. Auch Random Forest, Extra Trees und beide weiteren Boostingverfahren lösen nicht alle sechs Fälle. Ridge, RBF-SVR und das kleine neuronale Netz erreichen vier von sechs. Diese Rangfolge beschreibt den konkreten Rezeptkatalog, nicht die allgemeine Leistungsfähigkeit der Modellfamilien.
" }, { "heading": "Der mögliche Gewinn ist durch die Aufgabe begrenzt", "html": "Eine fehlerfreie Erstwahl könnte in diesem Versuch die acht Aufrufe der starken festen Referenz nur auf sechs reduzieren. Das wären zwei eingesparte Aufrufe. Eine Halbierung auf vier wäre schon deshalb unmöglich, weil jede der sechs Schaltungen mindestens einmal ausgeführt werden muss. Ein komplexeres Lernmodell kann diese Grenze des Versuchsaufbaus nicht umgehen.
Eine unabhängige Wiederholung reproduzierte alle 90 Rangfolgen sowie die Flächen- und Aufrufmetriken exakt. Die Rangbildung benötigte 3,28 beziehungsweise 5,04 Sekunden. Diese Zeiten bestätigen die technische Reproduzierbarkeit des Replays. Sie sind kein Nachweis einer verkürzten vollständigen Chipentwicklung. Datengewinnung, andere Werkzeugentscheidungen und spätere physische Prüfungen bleiben zusätzliche Kosten.
" }, { "heading": "Welche KI-Aufgabe sich daraus ableiten lässt", "html": "Für den untersuchten Katalog bleibt die feste Referenz eine starke Wahl. Der Entscheidungsbaum erreicht dieselbe Auswahlqualität, liefert aber keinen belegten Gesamtaufwandsvorteil. TabPFN, SAC und Transformer wurden in diesem Synthesevergleich nicht ausgeführt. Ein sequenzieller Lernagent benötigt eine echte mehrstufige Werkzeugumgebung. Größere Netzmodelle benötigen wesentlich mehr unterschiedliche Schaltungen und eine belastbare Trennung der Aufgabenfamilien.
Der nächste sinnvolle Test müsste vorab neue Schaltungen und Abnahmekriterien festlegen, einen größeren Entscheidungsraum öffnen und sämtliche Modell- und Werkzeugkosten mitzählen. Die zentrale Frage wäre dann, ob KI gleich gute funktionale und physische Ergebnisse mit geringerem Gesamtaufwand erreicht. Eine lange Liste getesteter Modelle allein beantwortet diese Frage nicht. Der vorliegende Vergleich zeigt konkret, wo eine einfache Regel bereits schwer zu schlagen ist.
" } ] }, { "id": "llm-reparatur", "topic": "KI-Entwurf", "level": "Ausgeführte RTL-Reparatur", "status": "Funktion bestätigt", "title": "Wann hilft Werkzeugfeedback einem LLM bei der RTL-Reparatur?", "result": "4/4 mit und ohne Diagnose", "paragraphs": [ "Vier eingefrorene synthetische Fehler wurden mit denselben Verträgen und Abnahmetests untersucht. Ein Vorschlag pro Fall; die Feedback-Bedingung erhielt zusätzlich die erste Werkzeugdiagnose. Codex und zwei über Vertex getestete Gemini-Varianten wurden getrennt ausgewertet.", "Auf vollständigen Paaren erreichen die Modelle bereits ohne zusätzliche Diagnose vier von vier korrekten Reparaturen. Ein Feedbackvorteil ist damit in diesen Aufgaben nicht sichtbar. Ein Timeout und Antworten außerhalb des festgelegten Formats zählen im Hauptvergleich nicht als angenommene Lösungen.", "Ein früherer separater Versuch mit drei Fehlern zeigte drei erfolgreiche Codex-Reparaturen gegenüber einer erfolgreichen festen Regel. Das ist ein positiver Befund zur Reparaturfähigkeit, aber keine allgemeine Modellrangfolge. Werkzeuge müssen helfen, die Funktion zu prüfen; überzeugender Quelltext allein ist kein Nachweis." ], "boundary": "Kleine ausgewählte Fehlermenge, teilweise gemeinsame Testpräfixe. Kein belegter Gesamtzeitvorteil für die komplette Entwicklung eines Chips.", "decision": "Schwierigere zurückgehaltene Aufgaben und vollständige Modell-, Werkzeug- und Eingriffskosten wären der nächste KI-Nachweis.", "source": "AR-016 Originalbericht", "source_sha256": "9f5fdf251f2754ce8a8732cba3325c47acac55803d34f1eac0f62dd60fd22e8d", "abstract": "Ein Sprachmodell kann fehlerhaften Schaltungscode korrigieren. Ob eine zusätzliche Simulatordiagnose dabei einen messbaren Unterschied macht, prüfen wir in einem gepaarten Vergleich mit unveränderten Aufgaben, begrenzten Änderungen und festen Abnahmetests.", "sections": [ { "heading": "Reparaturfähigkeit und Feedbackwirkung sind zwei Fragen", "html": "Im Entwurfsprozess kann KI auf zwei Arten nützlich sein. Sie kann eine passende Änderung im Quelltext vorschlagen und sie kann aus Rückmeldungen der Werkzeuge zusätzliche Informationen gewinnen. Ein erfolgreicher Vorschlag mit beigefügter Fehlermeldung beweist zunächst nur die Reparaturfähigkeit. Um den Beitrag der Fehlermeldung zu bestimmen, braucht es denselben Versuch ohne diese zusätzliche Information.
Unser Vergleich verwendet vier eingefrorene synthetische RTL-Fehler. Die Module und Aufgabenfamilien sind im Projekt bereits bekannt. Es handelt sich um einen kontrollierten Reparaturschritt, nicht um eine autonome vollständige Chipentwicklung. Die zu prüfende Hypothese lautet, dass zusätzliche Icarus-Diagnosen bei gleichem Vorschlagsbudget häufiger zu korrekt abgenommenen Änderungen führen.
" }, { "heading": "Ein Vorschlag unter einem festen Änderungsvertrag", "html": "Beide Bedingungen enthalten denselben fehlerhaften Quelltext und denselben Port- und Verhaltensvertrag. Die Feedback-Bedingung erhält zusätzlich den ersten Icarus-Fehler und höchstens sieben zusammenhängende Zeilen der Entwicklungssequenz. Pro Fall ist eine Textänderung erlaubt. Die zu ersetzende und die neue Zeichenfolge dürfen jeweils höchstens 256 UTF-8-Bytes umfassen. Der übrige Quelltext bleibt unverändert.
Vor der Modellanfrage wird geprüft, dass die unbeschädigte Referenz alle drei Testsequenzen besteht und der neue Fehler die Entwicklungssequenz verletzt. Eine vorgeschlagene Änderung wird nur angenommen, wenn sie korrekt angewendet werden kann und anschließend sämtliche Tests besteht. Die zwei reservierten Testsequenzen werden nicht als Vorschlagskontext bereitgestellt. Sie teilen allerdings Teile gerichteter Präfixe mit der Entwicklungssequenz.
" }, { "heading": "Modelle und Bedingungen getrennt ausführen", "html": "Codex bearbeitete die beiden Bedingungen in getrennten Agentenkontexten. Zusätzlich wurden zwei Gemini-Varianten über Vertex ausgeführt. Innerhalb einer Modellversion bleiben Decoding-Einstellungen und Ausgabelimits gleich. Die Antworten einer Bedingung werden der anderen nicht gezeigt. Diese prozedurale Trennung vermeidet eine direkte Weitergabe der Lösung zwischen den Armen, ist aber keine unabhängige Zugriffskontrolle aller Modellwerkzeuge.
Der Vergleich zwischen Modellanbietern kann durch Unterschiede der Modelle und Aufrufsysteme beeinflusst sein. Die kausale Frage zum Feedback wird deshalb vor allem innerhalb derselben Modellversion betrachtet. Eine feste Reparaturregel läuft als zusätzliche Kontrolle mit. Die Bewertung erfasst Quellhashes, Antwortformat und funktionale Tests, statt einen plausibel aussehenden Änderungsvorschlag bereits als Erfolg zu verbuchen.
" }, { "heading": "Die vollständigen Paare erreichen schon ohne Diagnose das Maximum", "html": "Im ersten vollständigen Durchlauf reparieren Codex, Gemini 4 Argon und Gemini 3.8 Flash jeweils alle vier Fälle mit und ohne Diagnose. Die feste Regel löst in diesem Vier-Fall-Versuch keinen Fall. Für die vollständigen Modellpaare ist damit kein Zusatznutzen des Feedbacks sichtbar. Die Aufgaben lassen sich bereits aus Quelltext und Vertrag vollständig lösen. Das Ergebnis belegt erfolgreiche Reparaturen, liefert aber keine Rangfolge zwischen diesen drei Modellen.
Die Wiederholungen zeigen zusätzlich Unterschiede im Ablauf. Ein Argon-Aufruf ohne Diagnose überschreitet das Zeitlimit und liefert keine Vorschläge. Zwei Flash-Antworten enthalten gültiges JSON, jedoch eine Liste statt der vorgeschriebenen Zuordnung. Nach der vorab festgelegten Hauptwertung werden diese Antworten nicht angenommen. Die getrennte nachträgliche Zuordnung über unveränderte Quellhashes ergibt zwar korrekte Reparaturen, ändert aber die Hauptwertung nicht.
" }, { "heading": "Was der frühere Pilot ergänzt", "html": "Ein separater Pilot mit drei anderen Fehlern untersuchte Belegungsgrenzen, die Übernahme akzeptierter Nutzdaten und die Priorität gleichzeitiger Speicheranforderungen. Codex reparierte drei von drei Fällen, die feste Regel einen. Codex-Vorschläge benötigten zwölf Werkzeugaufrufe, die Regel acht. Fehlgeschlagene Änderungen wurden früh abgebrochen, weshalb weniger Aufrufe dort keinen höheren Wirkungsgrad bedeuten.
Die Werkzeugunterprozesse dauerten im Pilot 2,26 Sekunden für Codex-Vorschläge und 1,74 Sekunden für die Regel. Modellrechenzeit und Tokenzahl standen nicht vollständig zur Verfügung. Dieser Pilot hatte keinen Codex-Arm ohne Feedback. Er zeigt deshalb eine praktisch nutzbare Reparaturfähigkeit auf den drei Fällen, isoliert aber weder die Wirkung des Feedbacks noch eine Einsparung der gesamten Entwicklungszeit.
" }, { "heading": "Ein anspruchsvollerer Abnahmetest muss anders aussehen", "html": "Vier ausgewählte kleine Fehler erzeugen schnell einen Deckeneffekt. Für einen aussagekräftigeren Feedbacktest werden zurückgehaltene Aufgaben benötigt, deren Ursache sich aus dem Quelltext allein schwer erkennen lässt. Dazu gehören zeitliche Wechselwirkungen, längere Transaktionsfolgen und Fälle, bei denen mehrere zunächst plausible Änderungen an einer unabhängigen Prüfung scheitern. Diese Erweiterungen sind Anforderungen an einen nächsten Versuch und keine bereits erreichten Ergebnisse.
Für eine Produktivitätsaussage müssten korrekt abgenommene Entwürfe, Modellzeit, Werkzeugzeit, Fehlversuche und menschliche Eingriffe gemeinsam erfasst werden. Funktionale Simulation ersetzt außerdem keine Synthese- oder Layoutqualifikation. Der vorliegende Nachweis rechtfertigt, LLM-Vorschläge als überprüfbare Reparaturschritte in die Software einzubinden. Einen nachgewiesenen Vorteil durch zusätzliche Diagnosen liefert diese konkrete Fehlermenge noch nicht.
" } ] }, { "id": "grosse-systeme", "topic": "Architektur", "level": "Bedingte Ressourcenanalyse", "status": "Untersucht", "title": "Wann lohnt sich mehr Fläche für KI-Rechenhardware?", "result": "Fläche, Energie und Bandbreite getrennt", "paragraphs": [ "Das Forschungsziel verlangt keinen winzigen Einzelchip. Mehrere Dies, große Träger und modulare Speicher-Rechenanordnungen bleiben im Suchraum. Eine große Siliziumsumme ist jedoch nicht dasselbe wie eine fertige Platine oder ein geeigneter Fertigungsprozess.", "Mehr Fläche kann die Wärmedichte senken, spart aber nicht automatisch Energie. Linklängen, aktive Speicherbänke, Taktverteilung, Versorgung und ruhende Module müssen mitzählen. Bandbreite in gerade unbenutzten Modellschichten darf nicht als nutzbare Bandbreite der aktuellen Schicht verbucht werden.", "Gewichte, Zustände und Programme müssen innerhalb erklärter Kapazitäts- und Operationsgrenzen austauschbar sein. Ein Modellwechsel soll keinen neuen Maskensatz verlangen. Dichte Speicherlagen, analoge/photonische Teilfunktionen und alternative Träger bleiben eigenständige Ideen; sie sind durch die bisherigen Digitaltests nicht bewiesen." ], "boundary": "Keine konkrete neue Fertigungstechnologie, kein Tape-out und keine Kostenfreigabe für ein Muster. Offene IHP-Prozessdaten sind kein Ersatz für moderne industrielle Signoff-Daten.", "decision": "Große Systeme weder wegen ihrer Fläche pauschal verwerfen noch ohne vollständige Ressourcenrechnung bevorzugen.", "source": "AR-017 Originalbericht", "source_sha256": "9f347a7a8c0b5f7ad2772900cd9a1a39b10ba21bbe46e196d09ce2b65a0f8dfc", "abstract": "Ein großes Rechensystem kann mehr Gewichte lokal halten und Datenwege anders organisieren. Entscheidend ist, ob der zusätzliche Speicher während einer konkreten Modellanfrage tatsächlich nutzbar ist. Unsere Ressourcenanalyse trennt dafür Siliziumfläche, aktive Bandbreite, Rechenzeit und Energie.", "sections": [ { "heading": "Die Forschungsfrage beginnt beim Datenweg", "html": "Der Ausgangspunkt ist eine Architektur mit aktualisierbaren Gewichten nahe an gemeinsam genutzten Rechenwerken. Eine mögliche Umsetzung verteilt das Modell auf mehrere Dies, Speicher-Rechenmodule oder größere Träger. Die Hypothese lautet, dass weniger wiederholte Datenbewegung die zusätzlichen Verbindungen und den höheren Grundaufwand aufwiegen kann. Die bloße Größe eines Systems entscheidet diese Frage nicht.
Untersucht wurde ein bedingter Ressourcenraum. Es handelt sich weder um einen gefertigten Großchip noch um ein verbindliches Fertigungskonzept. Die Vergleichsaufgabe bleibt die Ausführung derselben Modelloperationen mit einem definierten Zahlenformat. Ein Modellwechsel soll durch neue Gewichte und Programme möglich sein, ohne einen neuen Maskensatz zu erfordern.
" }, { "heading": "Was die Flächenzahlen tatsächlich beschreiben", "html": "Eine frühe Abschätzung ergab rund 11.300 mm² summierte Siliziumfläche für Gewichte in einem bestimmten Speicherdichtekontext. Das entspricht 113 cm² oder rechnerisch einem Quadrat mit etwa 10,6 cm Kantenlänge. Diese Umrechnung beschreibt noch keine reale Platine. Anschlussflächen, Abstände, Versorgung, Rechenlogik und Gehäuse sind darin nicht automatisch enthalten.
Spätere Varianten auf Basis offener IHP-Prozessdaten lagen bei etwa 2,1 bis 3,2 m² summierter Speicher- und Rechenzellfläche. Diese Zahlen sind keine alternative Schätzung desselben Entwurfs. Prozess, Rechenwerke und Umfang unterscheiden sich. Die Suche erlaubte sogar bis zu 10 m². Große Systeme wurden somit nicht pauschal wegen ihrer Fläche ausgeschlossen. Die konkreten Ausführungen scheiterten an zusätzlichen technischen Bedingungen.
" }, { "heading": "Installierte Bandbreite ist noch keine aktive Bandbreite", "html": "Bei einer einzelnen autoregressiven Anfrage durchläuft ein Modell seine Schichten nacheinander. Werden die Gewichte jeder Schicht auf ein eigenes Modul verteilt, kann während der Verarbeitung dieser Schicht nur ein Teil der installierten Speicherkanäle arbeiten. Die Bandbreite der gerade ruhenden Schichten darf nicht zum augenblicklichen Datenangebot addiert werden. Eine vollständige Bilanz muss daher für jede Phase festhalten, welche Kanäle liefern, welche Rechenwerke konsumieren und welche Zwischenergebnisse warten.
Mehrere unabhängige Anfragen können eine solche Schichtpipeline besser auslasten. Damit verändert sich jedoch die Zielgröße. Höherer Gesamtdurchsatz bedeutet nicht automatisch eine kürzere Antwortzeit für eine Einzelanfrage. Prefill, Decode, Batchgröße und Warteschlangen müssen getrennt betrachtet werden, bevor daraus eine Systemrangfolge entsteht.
" }, { "heading": "Warum die ersten großen Ausführungen ausscheiden", "html": "Die erste vollständige BF16-mal-BF16-plus-FP32-Probe wurde in dieselbe IHP-Bibliothek abgebildet. Der unplatzierte Pfad benötigte unter den geprüften Bedingungen 38,980 ns, entsprechend einer bedingten Rate von 25,65 MHz. Das trug die zuvor angesetzten 100 bis 500 MHz nicht. Diese Probe war ein einfacher kombinatorischer Rechenpfad mit Randregistern. Sie belegt keine allgemeine Frequenzgrenze des Prozesses und berücksichtigt noch keine optimierte interne Pipeline.
Zusätzlich begrenzte die zentrale Zusammenführung der Ergebnisse den Durchsatz. Mehr installierte Rechenwerke beseitigten diesen gemeinsamen Anschluss nicht. Die logische Konsequenz war, die konkreten zentralen Abbildungen auszusortieren und lokale Akkumulation sowie direkte Weitergabe als getrennte Hypothesen zu prüfen. Ein größeres Flächenbudget allein hätte die Ursache nicht behoben.
" }, { "heading": "Thermik, Energie und Fertigung getrennt rechnen", "html": "Eine größere Fläche kann die abgegebene Leistung auf mehr Oberfläche verteilen. Daraus folgt zunächst eine geringere Wärmedichte, keine niedrigere elektrische Gesamtleistung. Zusätzliche Leitungen, Taktverteilung, Speicherbänke und ruhende Module können den Verbrauch erhöhen. Umgekehrt können kürzere lokale Verbindungen Energie sparen. Welche Wirkung überwiegt, erfordert charakterisierte Zugriffsenergien und einen zeitlich aufgelösten Betriebsplan.
Auch die Fertigungsfrage bleibt eigenständig. Mehrere kleine Dies, dichte Speicherlagen oder ein anderer Träger können die Aufteilung verändern. Ein Träger aus Folie liefert aber noch keine geeignete schnelle Logik. Offene Prozessdaten ermöglichen überprüfbare Demonstratoren. Sie ersetzen weder eine moderne industrielle Prozesscharakterisierung noch Packagingangebote, Ausbeutedaten oder die Freigaben für eine konkrete Fertigung.
" }, { "heading": "Ein sinnvoller Vergleich für den nächsten Architekturstand", "html": "Eine größere Architektur muss Kapazität, gleichzeitig verfügbare Speicherports, Rechenrate und Verbindungen gemeinsam dimensionieren. Der Vergleich benötigt denselben vollständigen Arbeitsumfang und dieselbe Qualitätsanforderung. Speicherverkehr ist in Bytes, Rechenarbeit in Operationen und Energie in Joule zu erfassen. Ein hoher Anteil gezählter Prefill-Operationen darf dabei nicht als identischer Anteil an der gemessenen Laufzeit ausgegeben werden.
Der bisherige Befund rechtfertigt einen offenen Suchraum, aber keine Bevorzugung großer Systeme. Erfolgversprechend wäre eine konkrete Abbildung, die einen dominanten Datenweg reduziert und nach Einrechnung ihrer zusätzlichen Kosten schneller oder energieärmer bleibt. Lokale Kachelergebnisse liefern dafür Bausteine. Erst die vollständige Zuordnung der Modellphasen zeigt, ob diese Bausteine einen Systemvorteil tragen.
" } ] }, { "id": "aktiver-kontext", "topic": "Hardware", "level": "Layout + verzögerte Aktivität", "status": "Tempo verbessert", "title": "Kann eine feste aktive Summe den Kontextwechsel beschleunigen?", "result": "572 → 531 Takte bei identischer Rechenarbeit", "paragraphs": [ "Vier unveränderte Rechenlanes lesen ihre aktive FP32-Summe unmittelbar aus einem Register. Drei weitere Kontexte bleiben in Wechselplätzen; ein Blockwechsel tauscht die aktive Summe in einem zusätzlichen Takt. Insgesamt bleiben es 512 Summenbits. Neun Fälle mit 91.788 FMAs, Zwischenausgaben und Rückstau bestehen die bitgenaue Referenzprüfung.", "Der vollständig verdrahtete Hauptfall benötigt 531 statt 572 Takte gegenüber der Ein-Kontext-Referenz: 26,55 statt 28,60 Mikrosekunden am gemeinsamen 50-ns-Takt. Die extrahierte Minimalperiode sinkt von 17,33 auf 16,68 ns. Multipliziert man die Taktzahlen mit den jeweiligen STA-Grenzen, ergeben sich 8,857 statt 9,913 Mikrosekunden, entsprechend 10,65 % weniger Zeit. An diesen Grenzfrequenzen wurde nicht nachgespielt.", "Die modellierte Kachelenergie bei 50 ns steigt jedoch von 276,169 auf 281,608 nJ, also um 1,97 %. Die aktive Instanzfläche steigt um 6,80 %. Der Einzelkontext benötigt 3,20 % mehr Energie. Die vorab festgelegte kombinierte Hürde von mindestens 10 % Zeit- und Energiegewinn ist damit verfehlt.", "Gegenüber dem vorherigen Vier-Kontext-Entwurf verbessert der Umbau die Zeit an den STA-Grenzen um 15,47 % und die modellierte Energie um 7,11 %. Das ist eine lokale Verbesserung eines eigenen Zwischenstands. Die Ein-Kontext-Referenz bleibt im Hauptfall sparsamer.", "Eine passive Antennenzelle lieferte einen winzigen negativen Modellleistungswert. Die ursprüngliche strenge Prüfung stoppte deshalb. Originalberichte bleiben erhalten; eine nachträglich ergänzte, eng begrenzte Intervallrechnung umfasst den Beitrag explizit. Ihr Einfluss bleibt unter 0,000002 nJ im Hauptfall und ändert das Ergebnis nicht. Das ist keine Abschätzung der gesamten physikalischen Modellunsicherheit. Der kurze Folgejob ergänzte nur das fehlende zweite Leistungsfenster aus derselben Wellenform." ], "boundary": "Kleiner vollständiger Rechen-/Kontextblock bei IHP SG13G2 TT 1,20 V / 25 °C. Keine Energieauswertung des vollständigen Modells, keine Siliziummessung. 50-ns-Energie und STA-Grenzzeit sind getrennte Auswertungen.", "decision": "Den schnelleren Kontextbaustein und den vollständig dokumentierten Layoutvergleich in die Forschungsbasis übernehmen. Das Ergebnis zeigt einen konkreten Architekturgewinn mit einem bezifferten Energie- und Flächenaufwand.", "source": "AR-018 Originalbericht", "source_sha256": "b32b3c2f7250477869c34603882200b403b7403c285695dd3e8b4f8b1e8966b7", "abstract": "Vier Summenkontexte müssen nicht bei jedem Rechenschritt vor dem FMA ausgewählt werden. Wir halten die aktive FP32-Summe direkt am Rechenwerk und tauschen weitere Kontexte nur an Blockgrenzen. Der Vergleich umfasst Funktion, vollständige Verdrahtung, Timing und verzögerungsabhängige Aktivität.", "sections": [ { "heading": "Die Auswahl aus dem kritischen Rechenweg nehmen", "html": "Die Ausgangsreferenz hält bereits eine aktive Summe pro Lane in einem Register. Weitere Kontexte werden bei Bedarf über SRAM ausgetauscht. Ein erster Vier-Kontext-Entwurf speicherte dagegen vier Summen direkt in Registern und wählte die benötigte Summe vor jeder FMA aus. Diese Auswahl verlängerte den kritischen Pfad. Der neue Kandidat untersucht deshalb eine andere Organisation derselben vier Kontexte.
Vier unveränderte HardFloat-Lanes lesen ihre aktive FP32-Summe unmittelbar aus einem festen Register. Drei weitere Plätze halten die inaktiven Summen. Ein geändertes Kontextkennzeichen löst einen Tausch mit dem aktiven Register aus und kostet einen zusätzlichen Takt ohne Rechnung. Insgesamt bleiben 128 aktive und 384 inaktive Summenbits. Die Auswahl verschwindet nicht vollständig, liegt aber nicht mehr vor dem Summeneingang jeder FMA.
" }, { "heading": "Ein eingefrorener Hauptfall und passende Gegenfälle", "html": "Der vorab festgelegte Hauptfall verwendet vier Kontexte, K = 128 und Blöcke mit 64 Summenschritten. Die Referenz und der Kandidat bearbeiten dieselben 2.048 Lane-FMAs. Ein einzelner Kontext prüft, ob zusätzliche Register und Steuerung auch dann kosten, wenn kaum Kontextwechsel eingespart werden können. Weitere gepaarte Fälle verändern Blocklänge, K, Rückstau und Sonderwerte. Ein K = 5.120-Fall enthält vier reale Qwen-Gate-Gewichtszeilen.
Zu den sechs unveränderten Vergleichsfällen kommen drei zusätzliche Funktionstests mit unregelmäßigen Kontextfolgen, Zwischenausgaben und Rückstau. Zusammen bestehen 91.788 Lane-FMAs den Vergleich mit einer unabhängigen Ganzzahlreferenz. Ausgabebits und kumulierte Ausnahmeflags stimmen überein. Die drei neuen Fälle wurden nicht nachträglich auf der Referenz ausgeführt und liefern deshalb keine zusätzlichen gepaarten Leistungswerte.
" }, { "heading": "Gleicher physischer Rahmen, neue Datenführung", "html": "Alle drei Entwürfe verwenden dieselbe 8-KiB-SRAM mit 64-Bit-1RW-Anschluss, vier Rechenlanes und einen 1.600 × 1.200 µm großen Floorplan. Der Prozess ist IHP SG13G2 am TT-Punkt bei 1,20 V und 25 °C. Der gemeinsame Zieltakt beträgt 50 ns. Die zwei früheren Referenzen bleiben eingefroren. Sie werden nicht erneut geroutet, um einen günstigeren Vergleich zu erzeugen.
Der neue Datenweg besteht detaillierte Verdrahtungsprüfungen ohne gemeldete DRC- oder Antennenverletzungen sowie extrahierte Setup- und Hold-Prüfungen. Unverbundene Taktbaum-Dummy-Ausgänge werden einzeln geprüft und von funktionalen Signalen unterschieden. Externe Operandenquellen liegen außerhalb des Blocks. Hostzugänge sind vorhanden, Hostverkehr ist jedoch nicht Teil der ausgewerteten Aktivitätslast.
" }, { "heading": "Taktzahl und Timing gemeinsam auswerten", "html": "| Hauptfall | Ein Kontext | Vier direkt ausgewählt | Aktive Summe |
|---|---|---|---|
| Takte | 572 | 520 | 531 |
| Zeit bei 50 ns | 28,600 µs | 26,000 µs | 26,550 µs |
| STA-Minimalperiode | 17,33 ns | 20,15 ns | 16,68 ns |
| Takte × eigene STA-Grenze | 9,913 µs | 10,478 µs | 8,857 µs |
Gegenüber einem Kontext spart die aktive Summe 41 von 572 Takten. Das entspricht 7,17 % kürzerer Zeit am gleichen Takt. Die zusätzliche Tauschphase erklärt, weshalb sie elf Takte mehr benötigt als die direkte Vierfachauswahl. Gleichzeitig sinkt ihre extrahierte Minimalperiode auf 16,68 ns.
Die Multiplikation von Taktzahl und jeweiliger STA-Grenze ergibt 10,65 % kürzere rechnerische Zeit gegenüber einem Kontext und 15,47 % gegenüber der vorherigen Vierfachauswahl. An diesen Grenzfrequenzen wurde nicht nachgespielt. Die am gemeinsamen 50-ns-Takt ausgeführte Aktivitätsrechnung bleibt davon getrennt.
" }, { "heading": "Die Energiebilanz enthält den Preis der Register", "html": "Die modellierte Kachelenergie steigt im Hauptfall von 276,169 auf 281,608 nJ, entsprechend 1,97 %. Die aktive Instanzfläche einschließlich SRAM wächst von 490.120 auf 523.472 µm², also um 6,80 %. Gegenüber dem vorherigen Vier-Kontext-Entwurf sinkt die Energie um 7,11 %. Im Einzelkontext-Gegenfall steigt sie gegenüber der ursprünglichen Referenz um 3,20 %.
Gezählt werden Rechen- und Kontextblock, Taktbaum, SRAM sowie extrahierte Leitungen. Zwei identische Aktivitätsfälle wurden mit bedingten Zell- und Leitungsverzögerungen bitgenau nachgespielt. Neun positive und absichtlich scheiternde Kontrollen qualifizieren den Simulatorpfad. Ein Offlineaudit prüft unter anderem Quellhashes, Transaktionen, Netzbindung, Wellenform und unabhängig aufsummierte Zellleistungen. Es handelt sich um eine modellierte Energie fertiger Arbeit, nicht um eine Siliziummessung.
" }, { "heading": "Numerische Auffälligkeit und belastbare Entwurfsentscheidung", "html": "Eine passive Antennenzelle lieferte einen winzigen negativen Modellleistungswert. Die ursprüngliche strenge Prüfung stoppte daran. Die Rohdaten blieben erhalten. Eine nachträglich ergänzte Intervallrechnung behandelt ausschließlich identifizierte passive Beiträge unter eng begrenzten Schwellen. Ihr Hauptfallintervall beträgt 281,608413656 bis 281,608415476 nJ. Diese minimale Spannweite verändert den Befund nicht und ist keine Abschätzung der gesamten Modell- oder Prozessunsicherheit.
Die vorab festgelegte gemeinsame Hürde verlangte mindestens 10 % weniger STA-Grenzzeit und 10 % weniger modellierte Energie. Der Zeitteil wird erreicht, der Energieteil nicht. Erhalten bleibt ein nachweislich schnellerer eigener Kontextbaustein mit beziffertem Flächen- und Energieaufwand. Vollmodellenergie, externe Gewichtsversorgung, Board und Kühlung wurden nicht bilanziert. Der Bericht begründet damit eine konkrete lokale Architekturentscheidung und benennt genau, welche weitergehenden Aussagen der Vergleich noch nicht trägt.
" } ] }, { "id": "gemeinsame-teilprodukte", "topic": "Hardware", "level": "Geroutete Netzliste + interne STA", "status": "Zielkonflikt vermessen", "title": "Wie viel spart gemeinsame Teilproduktbildung nach der Verdrahtung?", "result": "32 Lanes: 7,61 % weniger Zellfläche, 37,30 % längere interne Mindestperiode", "decision": "Globale Teilproduktverteilung nicht als Geschwindigkeitsgewinner weiterführen. Lokale Auswahl und Addition sowie räumlich begrenzte Wiederverwendung getrennt untersuchen. Die geringere Zellfläche bleibt ein dokumentierter Nutzen mit konkreten Verbindungskosten.", "source": "AR-019 Originalbericht", "source_sha256": "7ec4c7a0d9d7e7966b4ecc1ae0280f9e9bb92d39d78d48fb74d31414bebbe01e", "published_label": "10. November 2026", "scientific_figure": "product-tradeoff", "boundary": "Registrierter vorzeichenloser Produktgenerator. Typische STA-Ecke mit begrenzter CTS-Ausnahme, verbleibende Fanout-Verletzungen. Keine Gesamtenergie oder Siliziummessung.", "abstract": "Wenn mehrere Rechenlanes denselben Eingabewert verwenden, können sie Teilprodukte gemeinsam erzeugen. Wir prüfen an vier vollständig verdrahteten Produktgeneratoren, ob weniger Rechenlogik auch nach Platzierung, Pufferung und Leitungsextraktion vorteilhaft bleibt.", "sections": [ { "heading": "Die Frage hinter dem gemeinsamen Produktgenerator", "html": "In einer Matrixoperation wird derselbe Aktivierungswert häufig mit mehreren Gewichten multipliziert. Eine einzelne Lane kann das Produkt selbst berechnen. Alternativ lassen sich ausgewählte Vielfache des gemeinsamen Werts einmal erzeugen und an mehrere Lanes verteilen. Das spart möglicherweise Logik, verlangt aber zusätzliche Auswahl- und Verbindungsstrukturen. Genau dieser Zielkonflikt lässt sich durch einen Operationszähler allein nicht entscheiden.
Unsere Hypothese lautet: Die eingesparte Teilproduktlogik könnte die Fläche verringern, ohne die erreichbare Taktrate wesentlich zu verschlechtern. Der Versuch hält Funktion, Registergrenzen und physischen Rahmen konstant. Er bewertet die tatsächlich entstandene Schaltung nach der Detailverdrahtung. Die relevanten Größen sind Standardzellfläche, Leitungen, elektrische Last und interne Timinggrenze.
" }, { "heading": "Gleiche Rechnung, zwei Implementierungen", "html": "Für jede Lane gilt exakt Produkt = x × (128 + fraction). Der gemeinsame Eingang x ist acht Bit breit und nimmt Werte von 0 bis 255 an. Die sieben Gewichtsbruchbits bilden Werte von 0 bis 127 ab. Das vollständige Ergebnis benötigt 16 Bit. Es wird weder vorzeitig gerundet noch abgeschnitten.
Die Referenz erzeugt das Produkt separat für jede Lane. Der Kandidat berechnet gemeinsam nutzbare Vielfache von x. Jede Lane wählt anhand ihrer Gewichtsbits Teilprodukte und setzt daraus ihr eigenes Ergebnis zusammen. Die Gewichte bleiben veränderbare Eingänge. Beide Entwürfe haben registrierte Ein- und Ausgänge. Nach dem Füllen der Pipeline liefern sie je Lane ein Ergebnis pro Takt.
Untersucht werden jeweils 16 und 32 Lanes. Der Vergleich betrifft ausschließlich diesen vorzeichenlosen Signifikanden-Produktpfad. Exponentenbehandlung, NaN und Unendlich, Rundung und FP32-Akkumulation gehören nicht zu den vier Layouts. Ein vollständiger Gleitkomma-FMA ist daher eine eigene Nachweisaufgabe.
" }, { "heading": "Der physische Versuch ist innerhalb jedes Paars gleich", "html": "Alle vier Entwürfe wurden mit dem offenen IHP-SG13G2-Prozess und derselben typischen Bibliothek bei 1,20 V und 25 °C verarbeitet. Die Taktperiode beträgt 50 ns, das Ein- und Ausgangsbudget jeweils 10 ns, die Taktunsicherheit 0,1 ns. Ausgangslast, Synthese- und Layoutbedingungen sind innerhalb der Paare identisch. Die feste Die-Größe beträgt 800 × 800 µm bei einem Kern von 760 × 760 µm.
Ein vollständiger Platzierungs- und Verdrahtungslauf je Variante bildet die Datenbasis. Danach wurden die parasitären Leitungswiderstände und -kapazitäten extrahiert. Das ist eine physische Entwurfsanalyse am Computer, keine Messung an einem gefertigten Chip. Mehrere Platzierungsseeds und weitere Prozess-, Spannungs- oder Temperaturecken wurden in diesem Versuch nicht untersucht.
Da die äußere Die-Fläche fest vorgegeben ist, bedeutet eine um 7,61 % kleinere Standardzellfläche nicht einen um 7,61 % kleineren fertigen Chip. Sie bezeichnet die Summe der in der Auswertung erfassten Standardzellflächen.
" }, { "heading": "Die fertigen Netzlisten rechnen die erwarteten Produkte", "html": "Die logische Prüfung verwendet die finalen verdrahteten Verilog-Netzlisten, nicht einen stillen Rückfall auf die ursprüngliche RTL-Beschreibung. Jede der vier Varianten wird mit denselben 34.816 gepackten Eingabevektoren getestet. Die ersten 32.768 Vektoren enthalten alle 256 Eingabewerte und 128 Gewichtsbruchwerte. Weitere 2.048 Vektoren prüfen deterministisch erzeugte Kombinationen.
Ein unabhängiger Ganzzahlvergleich prüft insgesamt 3.342.336 einzelne Lane-Ausgaben. Die Testbench berücksichtigt die Registerstufen, lässt anfangs undefinierte Ausgaben unbewertet und leert die Pipeline nach dem letzten Eingabewert. Alle vier Netze bestehen. Eine gezielte Kontrolle mit invertiertem Ausgabebit wird zurückgewiesen.
Dieser Netzlistentest arbeitet ohne Verzögerungen. Seine Laufzeit auf dem Host ist keine Chipzeit. Die funktionale Gleichheit und die nachfolgende statische Timinganalyse sind zwei getrennte Nachweise.
" }, { "heading": "Weniger Zellfläche, mehr Verbindungsaufwand", "html": "| Größe | 16 Referenz | 16 gemeinsam | 32 Referenz | 32 gemeinsam |
|---|---|---|---|---|
| Standardzellfläche | 108.739 µm² | 103.023 µm² | 211.797 µm² | 195.683 µm² |
| Verdrahtete Gesamtlänge | 364.106 µm | 578.152 µm | 774.056 µm | 1.172.929 µm |
| Interne Mindestperiode | 5,795 ns | 8,528 ns | 6,732 ns | 9,243 ns |
| STA-Maximalfrequenz | 172,56 MHz | 117,26 MHz | 148,55 MHz | 108,19 MHz |
| Pufferzellen | 1.259 | 1.419 | 2.500 | 2.859 |
| Höchster Signal-Fanout | 8 | 12 | 13 | 14 |
Bei 32 Lanes sinkt die Standardzellfläche von 211.797 auf 195.683 µm². Das entspricht 7,61 % weniger Zellfläche. Gleichzeitig wächst die verdrahtete Länge von 774.056 auf 1.172.929 µm, also um 51,53 %. Bei 16 Lanes treten dieselben Richtungen auf: 5,26 % weniger Zellfläche und 58,79 % mehr Drahtlänge.
Auch die Pufferzahl steigt. Die zusätzlichen Puffer liegen im Signalnetz. Bei 32 Lanes werden dort 2.742 statt 2.383 Puffer gezählt. Die Anzahl der Taktpuffer bleibt innerhalb des Paars unverändert. Der zusätzliche Aufwand lässt sich deshalb nicht einfach einem größeren Taktbaum zuschreiben.
Diese Beobachtung ist mit längeren Wegen für gemeinsam erzeugte Werte vereinbar. Sie beweist noch nicht, dass ein bestimmter Teilproduktbus allein die Verschlechterung verursacht. Dafür müssten gleiche Schaltungen mit gezielt veränderter räumlicher Verteilung verglichen werden.
" }, { "heading": "Warum wir die inneren Registerpfade separat auswerten", "html": "Der ursprüngliche Timingbericht wurde durch das feste 10-ns-Ausgangsbudget geprägt. Seine begrenzenden Pfade führen vom Ausgangsregister zum Ausgangsport. Werte von ungefähr 10,8 ns beschreiben unter diesen Bedingungen deshalb nicht die innere Rechengrenze. Eine Rangfolge der Rechenarchitektur daraus wäre irreführend.
Ein gesonderter Readback hat dieselben finalen Layoutdaten und extrahierten Parasitiken erneut eingelesen. Es erfolgte keine neue Synthese, Platzierung oder Optimierung. Alle 16 finalen Dateiidentitäten der vier Entwürfe wurden abgeglichen. Zusätzlich zur internen Mindestperiode wurden die zehn schlechtesten Setup- und Holdpfade jedes Designs explizit zwischen Registern ausgewertet.
Für die vorliegenden gleichflankigen Ein-Takt-Pfade ergibt sich die interne Mindestperiode aus 50 ns − schlechtester interner Setup-Slack. Bei 32 Lanes erhält die Referenz 6,731903 ns, der gemeinsame Generator 9,243183 ns. Der Kandidat verlangt damit eine um 37,30 % längere Periode. Bei 16 Lanes steigt sie von 5,794968 auf 8,528076 ns, entsprechend 47,16 %.
Bei dem tatsächlich festgelegten 50-ns-Takt bleiben Durchsatz und Pipeline-Latenz gleich. Die interne STA bewertet die unterschiedliche Timingreserve. Ihre rechnerischen Maximalfrequenzen sind keine über alle Betriebsbedingungen freigegebenen Siliziumtaktraten. Die genaue Dezimaldarstellung dient der Nachrechnung und beschreibt nicht die Genauigkeit des physikalischen Modells.
" }, { "heading": "Eine begrenzte Timingausnahme und verbleibende Regeln", "html": "Die strengen ursprünglichen Timingquittungen wurden nicht nachträglich auf Erfolg umgeschrieben. Sie melden je Design drei Treiber ohne Leitungsannotation. Eine separate Prüfung identifiziert genau diese Pins als unverbundene Ausgänge von Taktbaum-Dummylasten. Die Eingänge der Zellen bleiben mit positiver Library-Kapazität im extrahierten Taktbaum verbunden. Auch ihre Erreichbarkeit im Widerstandsgraph wird geprüft.
Nur diese offenen Ausgänge werden in der anschließenden begrenzten Qualifikation ausgenommen. Angeschlossene Ausgänge, fehlende Eingangsverbindungen oder getrennte Widerstandsverbindungen müssen in gezielten Negativkontrollen scheitern. Resetpins, die das Werkzeug bei der Registerabfrage mitführt, wurden ebenfalls kontrolliert. Sie liegen inaktiv an High. Die berichteten Setup- und Holdpfade enden tatsächlich am Dateneingang der Register.
| Regel | 16 Referenz | 16 gemeinsam | 32 Referenz | 32 gemeinsam |
|---|---|---|---|---|
| Signal-Fanout, Ziel höchstens 8 | 0 | 1 | 2 | 6 |
| Gemeldete Slew-Verletzungen | 0 | 0 | 0 | 0 |
| Gemeldete Kapazitätsverletzungen | 0 | 0 | 0 | 0 |
| Detailroute-DRC / Antennen | 0 / 0 | 0 / 0 | 0 / 0 | 0 / 0 |
Das 50-ns-Setup-/Hold-Ziel ist unter dieser engen Ausnahme erfüllt. Die Tabelle zeigt jedoch verbleibende Fanout-Zielverletzungen. Diese werden durch die Ausnahme nicht aufgehoben. Ein Timingvergleich an einer typischen Ecke ist keine vollständig abgeschlossene elektrische Freigabe, keine unabhängige Foundry-DRC-/LVS-Prüfung und keine Produktionsfreigabe.
" }, { "heading": "Was die Kapazitätsdiagnose über Energie sagen kann", "html": "| Netzklasse | 16 Referenz | 16 gemeinsam | 32 Referenz | 32 gemeinsam |
|---|---|---|---|---|
| Signalnetze | 52,5858 pF | 96,3620 pF | 118,7418 pF | 202,8779 pF |
| Taktbaum | 1,2022 pF | 1,0831 pF | 2,2157 pF | 2,1779 pF |
Die Signalnetzsumme steigt bei 32 Lanes von 118,7418 auf 202,8779 pF. Das sind 70,86 % mehr in derselben Auswertedefinition. Zusammen mit Drahtlänge und Pufferzahl ist dies ein konkreter Hinweis auf zusätzliche elektrische Last.
Die Zahl ist die Summe der gemeldeten D_NET-Gesamtkapazitäten. Die Extraktion enthält dabei keine Zell-Pinkapazitäten. Kopplung kann zu mehreren Netzsummen beitragen. Es handelt sich daher weder um eine eindeutig einmal gezählte physische Gesamtkapazität noch um die tatsächlich geschaltete Kapazität.
Für Energie fehlen Aktivitätsverteilung, Zellleistungsmodelle im betrachteten Arbeitsfall und eine gemeinsame vollständige Bilanzgrenze. Aus der kleineren Fläche folgt kein Energiegewinn. Aus der höheren Kapazität allein folgt umgekehrt noch keine vollständige negative Energiebilanz. Dieser Versuch liefert keine Energiezahl.
" }, { "heading": "Die nächste Hypothese richtet sich nach den gemessenen Pfaden", "html": "Die globale Teilproduktverteilung gewinnt hier die Zellflächenrangfolge und verliert die Rangfolge bei interner Mindestperiode, Drahtlänge und Pufferzahl. Damit ist die geprüfte Ausführung für ein vorrangiges Geschwindigkeitsziel kein Gewinner. Der Befund gibt eine konkrete Auswahlentscheidung und nicht bloß einen offenen Wunsch vor.
Als nächste Änderung kommen kleinere benachbarte Sharing-Gruppen in Betracht. Sie könnten Verteilungswege verkürzen, benötigen aber erneut zusätzliche Tabellenlogik. Daneben müssen die lane-lokale Auswahl und Addition untersucht werden. Lange kapazitive Netze können auch nach der gemeinsamen Verteilung entstehen. Eine bloße Verringerung des ersten Broadcast-Fanouts wäre deshalb noch keine vollständige Lösung.
Ein sauberer Folgeversuch hält die gesamte Lanezahl und die Arithmetik fest und ändert jeweils nur die Gruppierung oder die lokale Implementierung. Ein vollständiges 16-Lane-Array ist keine kontrollierte Ablation eines 32-Lane-Arrays mit zwei Sharing-Gruppen. Neue Kandidaten werden erst nach denselben Funktionstests und physischen Prüfungen eingeordnet.
" }, { "heading": "Daten, Rechenweg und Nachvollziehbarkeit", "html": "Die Daten- und RTL-Veröffentlichung enthält unveränderte JSON-Auswertungen, ausgewählte Schaltungsquellen, Prüfsummen und einen ausführbaren Offlineprüfer. Die Produktvergleichsdaten und KI-Vergleichsdaten sind auch einzeln verfügbar. Der Prüfer kontrolliert die Rechnung und die Bindung an die mitgelieferten Quellen. Er startet keinen neuen physischen Entwurf.
Die veröffentlichten Quellen unterscheiden die ursprüngliche strenge Timingbewertung von der anschließend begründet qualifizierten Auswertung. Hashes verbinden den Readback mit den identischen Ausgangslayouts. Die nativen Layoutarchive und eine erneute Foundry-Prüfung sind nicht Teil des Downloads. Die Ergebnisse gelten für diesen Baustein unter den genannten Bedingungen. Sie ersetzen keinen Vollmodell- oder Marktvergleich.
" } ] }, { "id": "ki-gegen-vertragsgenerator", "topic": "KI-Entwurf", "level": "Ausgeführter Modell- und RTL-Vergleich", "status": "Klassische Referenz schneller", "title": "Wann hilft ein LLM bei klar spezifizierten RTL-Bausteinen?", "result": "Alle Verfahren 6/6 korrekt. Online-Median 8,29 s für den Vertragsgenerator.", "decision": "Bekannte Modulklassen durch den geprüften Vertragsgenerator abdecken. KI anschließend an zurückgehaltenen neuen Aufgabenfamilien messen und Erstellung, Werkzeugläufe und Eingriffe vollständig erfassen. Ein Vorteil im gesamten Chipentwurf ist durch diesen Versuch nicht belegt.", "source": "AR-020 Originalbericht", "source_sha256": "4daa5464bf1f65addddcb6b2c2534532d6221cd7f6e4302043e187ae783ebbaf", "published_label": "10. November 2026", "scientific_figure": "ai-online-time", "boundary": "Sechs konstruierte Fälle aus drei bekannten Familien, zwei Wiederholungen. Onlinezeit ab eingerichtetem Experiment. Kein Vergleich mit Codex, keine PPA- oder Gesamtkostenrangfolge.", "abstract": "Ein Sprachmodell kann fehlerhaftes RTL reparieren. Ob es einen Entwurfsprozess verbessert, entscheidet aber der Vergleich mit einer starken Alternative. Wir messen zwei tatsächlich aufgerufene Modelle gegen einen deterministischen Vertragsgenerator und zählen Entwicklungsdiagnose, Werkzeugläufe sowie Fehlversuche mit.", "sections": [ { "heading": "Die Alternative zur KI muss dieselbe Aufgabe gut lösen", "html": "Ein einfacher Zufallsvorschlag oder eine schwache Reparaturregel würde die Frage zu leicht machen. Für bekannte, klar beschreibbare Modulklassen gibt es eine stärkere klassische Alternative: Ein Generator kann aus Schnittstelle und Verhaltensvertrag unmittelbar eine korrekte Schaltung erzeugen. Er benötigt für jede neue Parameterkombination keine Modellanfrage.
Wir vergleichen deshalb einen solchen deterministischen Vertragsgenerator mit Gemini 3.8 Flash und Gemini 4 Argon. Beide Modelle wurden über Vertex AI tatsächlich aufgerufen. Die Modellkennungen stammen aus den archivierten Antworten. Es handelt sich nicht um einen Vergleich mit dem Codex-Assistenten, der am Projekt arbeitet.
Die Forschungsfrage ist eng: Bringt ein LLM bei bereits bekannten kleinen Modulklassen mehr korrekt gelöste Aufgaben oder weniger Onlineaufwand als der vorhandene Generator? Der Versuch bewertet keine neue Gesamtarchitektur und keine allgemeine Fähigkeit, Produktionschips zu entwickeln.
" }, { "heading": "Sechs neue Instanzen aus drei bekannten Familien", "html": "Jede Instanz beginnt mit einem synthetisch eingefügten Fehler. Der Vertrag, die Parameter und der fehlerhafte Quelltext werden vor der Modellanfrage festgelegt. Modelle und Generator dürfen vollständige Ersatzmodule liefern. Eine künstliche Beschränkung auf die Reparatur genau einer Zeile gibt es nicht.
| Familie | Zwei Instanzen | Verbindliche Funktion |
|---|---|---|
| Exakte Produkte | 4 beziehungsweise 7 Lanes | 8-Bit-Eingang × (128 + 7-Bit-Bruchwert), vollständiges 16-Bit-Ergebnis |
| Lokale Summenkontexte | 2 × 24 Bit beziehungsweise 4 × 32 Bit | Modulare Ganzzahlsummen mit Enable, Clear, Reset und festgelegtem Überlauf |
| Weitergabepuffer | 13 beziehungsweise 29 Bit | Ein Speicherplatz, Ready/Valid, Rückstau und gleichzeitige Annahme/Ausgabe ohne Blase |
Die Summenkontexte sind ausdrücklich Ganzzahlschaltungen. Ihr Bestehen ist kein Nachweis einer FP32-FMA. Die Familien sind dem Experimentautor bekannt und wurden von ihm konstruiert. Neue Parameter und Fehler machen daraus keine verdeckten realen Kundenprojekte. Auch eine Überschneidung der allgemeinen Aufgabenideen mit Modelltrainingsdaten lässt sich nicht ausschließen.
" }, { "heading": "Entwicklungsdiagnose als kontrollierte Zusatzinformation", "html": "Für jedes Modell gibt es zwei Bedingungen. Die erste enthält Vertrag und fehlerhafte Quelle. Die zweite enthält zusätzlich die erste Fehlermeldung einer Entwicklungsprüfung und bis zu sieben zugehörige Eingabezeilen. Außer diesem Diagnoseblock bleiben die Eingabepakete gleich. Die zusätzlichen verdeckten Prüfsequenzen werden nicht an die Modelle übertragen.
Jede Bedingung läuft zweimal in getrennten, zustandslosen Anfragen. Die Reihenfolge der Bedingungen wird in der zweiten Wiederholung umgekehrt. Temperatur und Thinking-Einstellung werden konstant gehalten. Jede Antwort enthält einen Kandidaten für jede der sechs Aufgaben. Es gibt weder eine nachträgliche Auswahl des besten Vorschlags noch eine manuelle RTL-Reparatur nach dem Einfrieren.
Der Diagnosearm erhält Entwicklungsfeedback bereits im Prompt. Dies ist keine mehrstufige autonome Agentenschleife. Der Vergleich misst deshalb den Nutzen dieser konkreten Zusatzinformation und nicht jede mögliche Form werkzeuggestützter KI.
" }, { "heading": "Gleicher Compiler, gleiche Testfolgen, unabhängige Erwartungswerte", "html": "Ein separat programmierter Python-Oracle berechnet die erwarteten Ausgaben. Der Generator verwendet diese Ausgaben nicht zur Schaltungserzeugung. Alle Vorschläge durchlaufen dieselben Quellverbotsprüfungen, denselben Icarus-Compiler und dieselben unveränderten Testdateien. Pro Kandidat sind höchstens eine Kompilierung und drei Simulationen vorgesehen. Beim ersten fachlichen Fehler würde die Bewertung dieses Kandidaten abbrechen.
Für die Produktaufgaben enthält die Entwicklungsfolge alle 32.768 Eingang/Bruchwert-Paare. Zwei weitere getrennte Zufallsfolgen enthalten jeweils 8.192 Zeilen. Die Kontext- und Pufferfälle verwenden jeweils drei Folgen mit 4.096 Zeilen. Zusätzliche Kontrollen bestätigen, dass der Referenzgenerator alle Fälle besteht und jeder der sechs ursprünglichen Fehler erkannt wird.
Ein vollständiger Arm verarbeitet 147.456 Trace-Zeilen. Über zehn Arme sind das 1.474.560 Vergleiche und 240 Compiler-/Simulatoraufrufe. Eine Zeile kann mehrere Lanes oder Kontextzustände enthalten. Sie ist keine unabhängige Forschungsaufgabe. Der Umfang bleibt sechs Fälle aus drei Familien.
" }, { "heading": "Alle Verfahren bestehen, der Generator benötigt weniger Onlinezeit", "html": "| Verfahren | Wiederholung 1 | Wiederholung 2 | Median |
|---|---|---|---|
| Vertragsgenerator | 8,62 s | 7,97 s | 8,29 s |
| Gemini 3.8 Flash · ohne Diagnose | 12,16 s | 12,08 s | 12,12 s |
| Gemini 3.8 Flash · mit Diagnose | 12,02 s | 12,94 s | 12,48 s |
| Gemini 4 Argon · ohne Diagnose | 45,76 s | 41,11 s | 43,44 s |
| Gemini 4 Argon · mit Diagnose | 142,64 s | 47,48 s | 95,06 s |
Alle fünf Verfahren lösen in jeder Wiederholung sämtliche sechs Aufgaben. Die beobachtete Erfolgsquote beträgt überall 6/6. Zusätzliche Entwicklungsdiagnose erhöht sie hier nicht, weil schon die Bedingung ohne Diagnose alle Aufgaben besteht. Der Versuch hat bei diesem Funktionsmaß einen Deckeneffekt.
Gemessen wird die Summe aus Vorschlagserzeugung und den anschließend tatsächlich ausgeführten Compiler- und Simulatorläufen eines vollständigen Arms. Die Tabelle zeigt beide Beobachtungen und ihren Median. Bei zwei Werten ist dieser Median deren arithmetische Mitte. Er ist kein Konfidenzintervall und keine stabile Schätzung über eine breite Aufgabenverteilung.
Der Vertragsgenerator erreicht einen Median von 8,29 s. Flash benötigt rund 12 s, Argon in diesen Aufrufen rund 43 s ohne und 95 s mit Diagnose. Die Aussage ist eine Online-Rangfolge bei gleich bestandener Funktion. Unterschiedliche akzeptierte RTL-Quellen können trotzdem unterschiedliche Fläche, Timing und Energie besitzen. Solche PPA-Größen wurden hier nicht bewertet.
" }, { "heading": "Der Timeout gehört zum Ergebnis und nicht in den Papierkorb", "html": "Ein erster Argon-Aufruf mit Diagnose erreichte die anfänglich konfigurierte Transportgrenze von 75 Sekunden. Der Versuch ist erhalten und seine verstrichene Zeit wird dem Arm zugerechnet. Vor der fachlichen Auswertung wurde für alle Arme einheitlich höchstens eine identische Wiederholung bei Transporttimeout zugelassen. Die neue Transportgrenze beträgt 600 Sekunden. Der identische Retry gelang.
So ergibt sich für den betroffenen Arm einschließlich Werkzeugen eine Dauer von 142,64 s. Die zweite Wiederholung derselben Bedingung benötigt 47,48 s. Aus diesem Unterschied kann nicht gefolgert werden, dass Diagnose Argon grundsätzlich verlangsamt. Stichprobe, Netzwerklatenz und Transportstörung reichen nicht aus, um einen solchen Kausaleffekt zu bestimmen.
Insgesamt wurden neun Generierungsversuche für acht vollständige Modellantworten protokolliert. Es gab keine inhaltliche Nachbesserung anhand der zurückgehaltenen Tests. Neben 240 bewerteten Werkzeugaufrufen fallen 36 gemeinsame Kontrollaufrufe und vier Tokenzählaufrufe an.
" }, { "heading": "Was Zeit und Kosten umfassen und was nicht", "html": "Die Onlinezeit beginnt erst im eingerichteten Experiment. Die Erstellung des Vertragsgenerators, der Aufgaben, des Oracles und der Prüfumgebung war Entwicklungsarbeit. Sie wurde nicht als aktive Personen- oder Codex-Arbeitszeit separat gemessen und ist nicht kostenlos. Auch proprietäres Modelltraining, Codex-Abonnement beziehungsweise Tokenzuordnung und lokale elektrische Energie fehlen in der Kostenbilanz.
Die belegbare Kalenderzeit zwischen Beginn der eingefrorenen Kontrollen und Abschluss der Bewertung beträgt 580,40 s. Sie enthält Warten, Koordination, Transportkorrektur und Auswertung. Sie ist keine aktive Arbeitszeit. Der lokale Windows-Host war nicht exklusiv reserviert. Die gemessenen Werkzeugzeiten sind deshalb keine präzisen plattformunabhängigen Benchmarks.
Bekannte Modellkosten betragen nach der archivierten konservativen Listenrechnung 0,40963065 USD. Für den Timeout ohne Verbrauchsantwort werden zusätzlich höchstens 0,20944440 USD reserviert. Die Summe von höchstens 0,61907505 USD ist eine Kostenmodellgrenze, keine eingesehene Rechnung und kein vollständiger Projektpreis. Ein API-Kostenwert von null für den Generator bedeutet ausschließlich, dass er keine Modell-API aufruft.
Vier operative Eingriffe sind dokumentiert: vorhandene Anmeldung außerhalb der Sandbox verwenden, Transportgrenze ändern, einheitlichen Timeout-Retry festlegen und eine Importnamenskollision im Fortsetzungsprogramm beheben. Eine zusätzliche Nachverarbeitungskorrektur behandelt LF-/CRLF-Zeilenenden bei Quellhashes. Keine dieser Maßnahmen veränderte einen fachlich bewerteten RTL-Vorschlag.
" }, { "heading": "Welche Rolle die KI daraus in unserer Software erhält", "html": "Für diese bekannten Modulklassen ist der vorhandene Generator die sinnvollere Standardausführung. Er liefert denselben getesteten Funktionsumfang bei geringerer beobachteter Onlinezeit. Das Ergebnis ist weder eine allgemeine Widerlegung von KI im Chipdesign noch ein positiver Nachweis umfassender Designproduktivität.
Der nächste aussagekräftige Vergleich muss Aufgaben enthalten, für die der vorhandene Generator noch keine Lösungsschablone besitzt. Dafür braucht es vorab zurückgehaltene Familien, realistische Änderungsaufträge und eine vollständige Erfassung der Entwicklungskosten beider Wege. Wenn das Ziel bessere physische Entwürfe ist, müssen beide Verfahren anschließend dieselben Kriterien für Fläche, Timing und Energie erreichen.
KI-Vorschläge, Generatoren und klassische Suchverfahren sollten nach der Aufgabe ausgewählt werden. TPE oder Bayes-Optimierung können numerische Entwurfsparameter durchsuchen. Für die hier untersuchte reine Reparatur eines vollständig spezifizierten RTL-Verhaltens wären sie keine automatisch stärkere Vergleichsgruppe. Die unabhängige Funktionsprüfung bleibt bei allen Verfahren verbindlich.
" }, { "heading": "Die ausgeführten Vorschläge sind öffentlich nachspielbar", "html": "Die Daten- und RTL-Veröffentlichung enthält unveränderte JSON-Auswertungen, ausgewählte Schaltungsquellen, Prüfsummen und einen ausführbaren Offlineprüfer. Die Produktvergleichsdaten und KI-Vergleichsdaten sind auch einzeln verfügbar. Der Prüfer kontrolliert die Rechnung und die Bindung an die mitgelieferten Quellen. Er startet keinen neuen physischen Entwurf.
Das Paket enthält alle 60 tatsächlich kompilierten Kandidaten sowie Verträge, Testbenches und die eingefrorenen Testvektoren. Mit einer vorhandenen Icarus-Verilog-Installation kann ein einzelner vollständiger Arm lokal erneut simuliert werden. Der Paketprüfer benötigt nur Python. Ein lokaler Replay erzeugt keine neue Modellantwort und rekonstruiert nicht die damalige Netzwerklatenz.
Mit der Veröffentlichung sind die ursprünglich zurückgehaltenen Testfolgen öffentlich. Sie dürfen in späteren Experimenten nicht erneut als unbekannte Testfälle ausgegeben werden. Die Originalhashes, die vollständig mitgezählten Fehlversuche und die klar benannten Bilanzlücken machen die Reichweite des Befunds prüfbar.
" } ] }, { "id": "vollstaendige-fma-vier-lanes", "topic": "Hardware", "level": "Vollständige FMA + extrahierte STA", "status": "Timingvorteil im Layout", "title": "Verbessert eine gemeinsame Produkttabelle das Timing einer vollständigen FMA-Kachel?", "result": "Vier Lanes: rund 9,8 % kürzere interne Mindestperiode, 0,84 % mehr Zellfläche.", "decision": "Die vollständige Vier-Lane-Kachel bleibt ein Kandidat für kurze lokale Rechenwege. Als nächster kontrollierter Versuch folgt eine vorab festgelegte Suche über Kernform und Platzierungsdichte. Ein unabhängiger Acht-Bit-Produktpfad soll anschließend den kausalen Beitrag des Teilens abgrenzen. Weitere Betriebsecken, Layoutseeds und Aktivitätsdaten müssen die Stabilität und energetischen Kosten des Timinggewinns klären.", "source": "AR-021 abgeschlossene Abnahme", "source_sha256": "8f57192d026acc5c96b224916428abef788b25d1056fa7240c7e7c6a17bc7660", "published_label": "10. November 2026", "boundary": "Vier Lanes, vier lokale Kontexte, kein Host-SRAM. Ein Layoutlauf je Variante und eine typische STA-Ecke. Kein Nachweis isolierter Sharing-Kausalität, Gesamtenergie oder Marktüberlegenheit.", "scientific_figure": "fma4-timing", "abstract": "Eine vollständige Vier-Lane-FMA mit lokalen FP32-Summen erreicht im verdrahteten Vergleich rund 9,8 % kürzere interne Mindestperiode. Ein gezielter Funktionstest der finalen Netzlisten ohne Verzögerungen besteht. Die separate statische Timinganalyse gilt für eine typische Prozess-, Spannungs- und Temperaturecke.", "sections": [ { "heading": "Zusammenfassung", "html": "Wir vergleichen zwei Implementierungen einer Kachel mit vier Rechenlanes und vier lokalen FP32-Summenkontexten je Lane. Beide berechnen dieselbe fusionierte Operation aus zwei BF16-Operanden und einer FP32-Summe. Die Kontrollimplementierung verwendet die vollständige HardFloat-Funktion. Der Kandidat ersetzt darin die exakte ganzzahlige Produktbildung durch eine gemeinsam genutzte Tabelle von Teilprodukten. Exponentenausrichtung, Behandlung besonderer Zahlenwerte, Addition und abschließende Rundung bleiben enthalten.
Im abgeschlossenen Layout beträgt die aus der extrahierten statischen Zeitanalyse abgeleitete interne Mindestperiode 18,70 ns bei der Kontrolle und 16,87 ns beim Kandidaten. Das entspricht einer Verkürzung um rund 9,8 Prozent. Bezieht man die festen Ein- und Ausgangsbudgets ein, sinkt die entsprechende Periode von 27,77 auf 27,20 ns, um rund 2,1 Prozent. Dem stehen 0,84 Prozent mehr Standardzellfläche und 7,01 Prozent mehr geroutete Leitungslänge gegenüber. Die Diefläche bleibt gleich.
Diese Werte beschreiben zwei konkrete vollständige Implementierungen bei einem typischen Prozessfenster. Beim vorgegebenen 50-ns-Takt arbeiten beide mit derselben Taktfrequenz. Eine kürzere Modellantwort oder niedrigere Energie pro Ergebnis wurde damit nicht gemessen. Beide finalen Standardzellnetzlisten bestehen denselben gezielten Funktionstest ohne Verzögerungen. Die statische Timinganalyse wird separat bewertet und ist auf eine typische Prozess-, Spannungs- und Temperaturecke begrenzt.
" }, { "heading": "Welche Rechenarbeit wird geteilt?", "html": "Eine BF16-Aktivierung wird an alle vier Lanes übertragen. Jede Lane erhält ein eigenes BF16-Gewicht und führt ihre eigene FP32-Summe. Das passt zu einer Matrix-Vektor-Operation, bei der ein Eingabewert mehrere Ausgabekanäle beeinflusst. Der Versuch verändert weder die Gewichte noch die geforderte Ausgabegenauigkeit.
Für die Produktbildung bezeichnen a und b die vorzeichenlosen, normalisierten achtstelligen Signifikanden. Zerlegt man b in zwei Vier-Bit-Ziffern, gilt exakt:
a × b = (a × b_hi) × 16 + (a × b_lo).
Der Kandidat bildet die sechzehn Vielfachen a × d für d = 0 … 15 gemeinsam. Jede Lane wählt anhand ihres Gewichts zwei Einträge aus und setzt daraus ihr exaktes Produkt zusammen. Die Normalisierung einschließlich Subnormalzahlen erfolgt in der bestehenden Gleitkommalogik. Der Code nutzt die sechzehn bekannten nachlaufenden Nullbits der nach FP32 eingebetteten BF16-Signifikanden. Er ersetzt ausschließlich den entsprechenden Produktteil innerhalb der fusionierten Operation.
Das ist keine Quantisierung. Es gibt keinen zusätzlichen Rundungsschritt zwischen Multiplikation und Addition. Das Ergebnis wird weiterhin einmal auf FP32 mit Round-to-Nearest, Ties-to-Even gerundet. NaN, Unendlich, vorzeichenbehaftete Nullen, Subnormalzahlen und Ausnahmeflags bleiben Teil des Vertrags.
Die gemeinsame Berechnung kann Rechenlogik reduzieren oder anders strukturieren. Sie erzeugt gleichzeitig zusätzliche Verteilung und Auswahl. Ob daraus ein physischer Vorteil entsteht, hängt von Verdrahtung, Puffern, Lasten und dem kritischen Pfad ab. Genau diese Wechselwirkung motiviert den Layoutvergleich.
" }, { "heading": "Lokale Summen und die Vergleichsgrenze", "html": "In beiden Varianten liegt die aktive FP32-Summe direkt an der Arithmetik. Drei weitere Summenkontexte werden in lokalen Registern gehalten. Beim Kontextwechsel tauscht der Controller die aktive Summe mit dem ausgewählten inaktiven Kontext. Bei aufeinanderfolgenden Operationen desselben Kontextes entfällt dieser Austausch. Die Ausgabe verwendet in beiden Varianten denselben Handshake und dieselbe Behandlung von Rückstau.
Der physische Top enthält kein Host-SRAM. Gewichtsversorgung, Modellzustände außerhalb der lokalen Register, Interconnect zwischen mehreren Kacheln und ein vollständiger Modellgraph sind nicht Bestandteil des gemessenen Ausschnitts. Der Vergleich untersucht daher die Integration von vollständiger FMA und lokalen Summen, nicht die Bandbreite eines Gesamtspeichersystems.
Die Kontrolle shared_fma4_baseline und der Kandidat shared_fma4_shared verwenden denselben lokalen Controller. Die Arithmetik- und Controllerquellen sind gegenüber dem vorangehenden funktionalen Entwurf unverändert. Der neue Top legt vier Lanes fest. Eine ebenfalls geroutete dritte Implementierung mit unabhängigen, speziell verkürzten Acht-Bit-Produkten fehlt. Aus dem Paarvergleich lässt sich deshalb nicht isolieren, welcher Anteil einer Änderung ausschließlich durch die gemeinsame Tabelle und welcher durch die andere Produktstruktur entsteht.
| Bedingung | Für beide Varianten |
|---|---|
| Prozessdaten | IHP SG13G2, typische Standardzellbibliothek |
| Spannung und Temperatur | 1,20 V und 25 °C |
| Taktsoll | 50 ns, entsprechend 20 MHz |
| Ein- und Ausgangsbudget | jeweils 10 ns |
| Ausgangslast und Taktunsicherheit | 0,01 pF und 0,1 ns |
| Diefläche | 1.000 × 1.000 µm, entsprechend 1 mm² |
| Kernfläche | 960 × 960 µm |
| Platzierungsdichte | 0,35 |
| Rechenressourcen des Entwurfswerkzeugs | acht Threads je Lauf |
| Werkzeugumgebung | festgeschriebener ORFS-Container und gehashte Werkzeuge, Skripte und Bibliothek |
Der Flow umfasst Synthese, Platzierung, Taktbaum, detaillierte Verdrahtung und RC-Extraktion. Die tatsächlich ausgeführten ABC-Mappingbedingungen wurden paarweise verglichen. In beiden Fällen scheiterte die vorgesehene SCL-Konvertierung, anschließend wurde derselbe direkte Liberty-Weg genutzt. Treiber, Last, Bibliotheksdatei und Ausschlussliste sind übereinstimmend dokumentiert. Die ursprüngliche Datei abc.constr wurde nicht separat archiviert. Die tatsächlich geladene Treiber- und Lastangabe stammt aus der ABC-Ausgabe und den festgeschriebenen Eingangsdaten. Ein Vergleich unterschiedlicher Synthesestrategien wird daraus nicht abgeleitet.
Die Worker quittieren 1.375,70 Sekunden für die Kontrolle und 1.404,39 Sekunden für den Kandidaten. Das sind Laufzeiten des Entwurfswerkzeugs von etwa 23 Minuten, keine Ausführungszeiten der Kachel. Die Sammlung enthält 129 beziehungsweise 130 hashgeprüfte Ergebnisdateien. Die im Versuch reservierten vier Euro sind eine Planungsobergrenze und keine vorliegende Schlussrechnung.
" }, { "heading": "Ergebnisse nach Verdrahtung", "html": "Prozentwerte beziehen sich jeweils auf die Kontrolle. Die Periodenangaben sind aus den archivierten Berichten auf zwei Dezimalstellen übernommen. Daraus berechnete Prozentwerte besitzen keine höhere physische Genauigkeit.
| Größe | Kontrolle | Gemeinsame Tabelle | Änderung |
|---|---|---|---|
| Interne Mindestperiode, Register zu Register | 18,70 ns | 16,87 ns | −9,79 % |
| Mindestperiode einschließlich Portbudgets | 27,77 ns | 27,20 ns | −2,05 % |
| Standardzellfläche | 286.929 µm² | 289.346 µm² | +0,84 % |
| Diefläche | 1.000.000 µm² | 1.000.000 µm² | 0 % |
| Geroutete Leitungslänge | 1.202.331 µm | 1.286.641 µm | +7,01 % |
| Größter berichteter Signalfanout nach Reparatur | 8 | 8 | gleich |
| Summe der SPEF-Netzkapazitäten | 194,3377 pF | 214,7419 pF | +10,50 % |
| Setup-Slack bei 50 ns | 22,2294 ns | 22,8040 ns | positiv bei beiden |
| Hold-Slack | 0,1685 ns | 0,1673 ns | positiv bei beiden |
Die minimale interne Periode beschreibt den Register-zu-Register-Pfad im verwendeten Timingmodell. Ihre reziproke Änderung entspräche rechnerisch 10,85 Prozent mehr interner Frequenzreserve. Das ist keine bereits gefahrene höhere Betriebsfrequenz. Die Ein- und Ausgänge haben eigene Zeitbudgets und begrenzen die Schnittstelle anders. Für die tatsächlich untersuchte Konfiguration bleiben 50 ns und damit die Zahl der Takte pro identischer Auftragsfolge unverändert.
Standardzellfläche bezeichnet die Summe belegter Zellen. Sie ist nicht mit Diefläche oder Herstellungskosten gleichzusetzen. Ebenso ist die Summe der in SPEF berichteten Netzkapazitäten keine aktivitätsgewichtete Schaltkapazität. Ohne Umschalthäufigkeiten, Glitches, interne Zellleistung, Leckleistung und konsistente Messgrenze lässt sich daraus kein Energieverbrauch ableiten. Die zusätzliche Leitungslänge und Kapazität sind konkrete Gründe, einen Energievorteil gesondert zu prüfen.
" }, { "heading": "Warum die Timingqualifikation einen eigenen Audit benötigt", "html": "Die unveränderte strenge Auswertung der ursprünglichen Berichte setzt timing_usable=false. Ursache sind fünf beziehungsweise sechs als nicht annotiert gemeldete Ausgänge zusätzlich eingefügter Taktlastzellen. Diese Ausgangspins sind in der finalen Netzliste tatsächlich unverbunden. Ihre Eingangspins hängen dagegen am realen Taktbaum und müssen mit ihren Lasten erhalten bleiben.
annotation-audit-qualified.json prüft diese Zuordnung für jeden gemeldeten Pin anhand von finaler Netzliste, Liberty-Pinrichtung, Verbindungsliste und extrahiertem RC-Netz. Die Eingangslasten sind im Taktbaum enthalten und über das Widerstandsnetz erreichbar. Drei gezielte Gegenproben je Variante werden abgewiesen: ein doch verbundener Ausgang, ein fehlender Takteingang und eine unterbrochene RC-Verbindung.
Die zusätzliche Qualifikation erlaubt deshalb einen begrenzten Vergleich unter dieser explizit geprüften Ausnahme. Sie ändert weder SDC noch die ursprünglichen Berichte und erklärt nicht pauschal alle fehlenden Annotationen für unbedenklich. Die ursprüngliche Vergleichsdatei bleibt mit ihrer strengen negativen Qualifikation erhalten. Der Audit ist ein zusätzlicher Nachweis, kein nachträgliches Überschreiben des Ergebnisses.
Detailliertes Routing meldet bei beiden Varianten null DRC- und Antennenverletzungen. Die ausgewerteten elektrischen Zähler für Fanout, Flankensteilheit, Kapazität sowie Setup und Hold stehen ebenfalls auf null. Die Versorgungskonnektivität für VDD und VSS besteht. Diese Prüfungen ersetzen weder belastete IR-Drop- und Elektromigrationsanalysen noch einen vollständigen Fertigungs-Signoff.
" }, { "heading": "Die finalen Netzlisten bestehen die gezielte Funktionsprüfung", "html": "Vor dem Layout wurden die exakt verwendeten Vier-Lane-Tops gegen eine unabhängige ganzzahlige FMA-Referenz geprüft. Nach der Verdrahtung besteht dieselbe Sollspur auf beiden finalen Standardzellnetzlisten. Je Variante werden 163 Befehle, 272 einzelne Lane-FMAs, 77 Ausgabeereignisse und 19 Resets geprüft. Ein Ausgabeereignis vergleicht alle vier FP32-Werte und die zugehörigen Ausnahmeflags.
Die Spur enthält fusionierte Überlaufkompensation, Subnormalgrenzen, NaN und Unendlich, dynamische Gewichte, vier dauerhafte Kontexte und Ausgabe-Rückstau. Jede Rechenanforderung wird durch eine anschließende Ausgabe beobachtbar. Der Vergleich greift ausschließlich auf die äußeren Ports zu. Eine absichtlich um ein Bit verfälschte Sollausgabe führt bei beiden Netzlisten zum erwarteten Abbruch. Damit wird auch kontrolliert, dass der Sollvergleich tatsächlich anschlägt.
Die Abnahme verknüpft Netzlisten-, Testbench-, Zellmodell- und Spurhashes mit den beiden gerouteten Layoutarchiven. Es gibt keinen Rückfall auf das ursprüngliche RTL. Die IHP-Zellmodelle und Icarus Verilog 12.0 sind mit ihren Dateihashes dokumentiert. Die vollständigen Netzlisten und Zellmodelle sind im kleinen öffentlichen Nachweispaket nicht enthalten.
Die Simulation arbeitet ohne annotierte Laufzeitverzögerungen. Die 100-ns-Testbench-Periode ist eine Ablaufhilfe des Simulators, keine gemessene Schaltungsperiode und kein Ersatz für den getrennten 50-ns-STA-Vertrag. Die 272 Lane-FMAs sind gezielte Fälle, keine erschöpfende Prüfung aller Zahlenkombinationen. Die Abnahme ist weder ein formaler Äquivalenzbeweis noch eine SDF-Simulation.
Frühere fehlgeschlagene Infrastrukturversuche wurden erhalten. Der erfolgreiche Linux-Lauf ersetzt deren Status nicht rückwirkend. Eine unvollständige Ausführung zählt weiterhin nicht als Nachweis.
" }, { "heading": "Einordnung und nächster Erkenntnisgewinn", "html": "Der Versuch beantwortet eine eng umrissene Integrationsfrage: Der Kandidat erreicht innerhalb einer vollständigen FMA mit lokalen Summen ein kürzeres internes Timingmodell bei weitgehend gleicher Zellfläche, während Verbindungsaufwand zunimmt. Die Grenze eines isolierten Produktgeneratorvergleichs wird dadurch in Richtung einer vollständigen Rechenkachel verschoben. Ein günstigeres isoliertes Produkt lässt sich nicht automatisch auf diese Integration übertragen, weshalb der vollständige Vergleich erforderlich ist.
Vier Lanes sind weder ein Ersatz für einen abgeschlossenen 32-Lane-Vergleich noch ein Beleg für Skalierbarkeit. Ein einzelner Platzierungs- und Routinglauf je Variante liefert keine Streuungsverteilung. Prozess-, Spannungs- und Temperaturvariationen, mehrfache Layoutseeds, Aktivität und größere Lanezahlen sind nicht geprüft. Eine Verallgemeinerung auf gesamte Modelle, Training oder marktführende Beschleuniger wäre deshalb nicht durch diesen Datensatz gedeckt.
Nach der bestandenen gezielten Funktionsabnahme ist ein sinnvoller Folgeversuch die vorab spezifizierte Suche über Kernform und Platzierungsdichte. Sie kann zeigen, ob die Verteilung des gemeinsamen Signals und die örtliche Anordnung der Summen das Timing weiter verbessern oder ob der Verbindungsaufwand den Ansatz begrenzt. Der unabhängige Acht-Bit-Produktpfad bleibt eine wichtige spätere Ablation, um die Ursache des Effekts genauer zu trennen. Für einen Energienachweis braucht es eine identische Lastspur, Schaltaktivitäten und ein vollständigeres Leistungsmodell.
" }, { "heading": "Daten und Nachrechnung", "html": "Das gesonderte Datenpaket zu AR-021 enthält unveränderte Abschlussmetriken und Timingberichte beider Layouts, den begrenzten CTS-Audit, originale Positiv- und Negativlogs sowie die geprüfte Sollspur und Testbench. Die Vergleichsdaten und kuratierte Abnahmequittung sind auch einzeln verfügbar.
Nach dem Entpacken prüft python verify_fma4.py --require-final die Dateiintegrität, die Bindung an die mitgelieferten Ausgangsdaten, Prozentrechnungen und die dokumentierten Abnahmekriterien. Mit --self-test werden zusätzlich veränderte Perioden, Netzlistenidentitäten, Negativkontrollen und unvollständige Abnahmestände absichtlich zurückgewiesen.
Die Originale der kuratierten Zusammenfassung und Abnahme sind anhand ihrer SHA-256-Identitäten benannt. Betriebskennungen wurden weggelassen. Die vollständigen nativen Layoutarchive, finalen Verilog-Netzlisten und Zellmodelle gehören nicht zum Download. Der Offlineprüfer startet deshalb weder eine neue Verdrahtung noch einen erneuten Netzlistenlauf. Er prüft die veröffentlichten Daten und Belege. Eine Prüfsumme allein ist kein unabhängiger Nachweis für den Inhalt eines nicht mitgelieferten Artefakts.
Grundlagen der verwendeten Werkzeuge: Berkeley HardFloat, OpenROAD und IHP Open PDK. Sie sind Werkzeuggrundlagen dieses Versuchs, keine Projektpartner.
" } ] } ], "tile": { "date": "2026-11-07", "kind": "post_route_estimate", "scope": "Small four-lane compute/context block. Not silicon or full-model energy.", "common_period_ns": 50, "baseline_commit": "a8b5ddc5fc8c4cccf8ded9b9d66b4f9b11800719", "cases": [ { "id": 0, "cycles": [ 572, 520, 531 ], "sta_period_ns": [ 17.33, 20.15, 16.68 ], "area_um2": [ 490120.0, 533624.0, 523472.0 ], "energy_nJ": [ 276.16938318118326, 303.1545136034399, 281.6084154760674 ], "swap_energy_interval_nJ": { "min": 281.60841365568626, "max": 281.6084154760674 } }, { "id": 1, "cycles": [ 131, 130, 130 ], "sta_period_ns": [ 17.33, 20.15, 16.68 ], "area_um2": [ 490120.0, 533624.0, 523472.0 ], "energy_nJ": [ 65.7112117913297, 73.87547419677271, 67.8149570240163 ], "swap_energy_interval_nJ": { "min": 67.81495659854839, "max": 67.8149570240163 } }, { "id": 2, "cycles": [ 716, 520, 555 ], "sta_period_ns": [ 17.33, 20.15, 16.68 ], "area_um2": [ 490120.0, 533624.0, 523472.0 ] }, { "id": 3, "cycles": [ 697, 621, 636 ], "sta_period_ns": [ 17.33, 20.15, 16.68 ], "area_um2": [ 490120.0, 533624.0, 523472.0 ] }, { "id": 4, "cycles": [ 22412, 20488, 20811 ], "sta_period_ns": [ 17.33, 20.15, 16.68 ], "area_um2": [ 490120.0, 533624.0, 523472.0 ] }, { "id": 5, "cycles": [ 170, 46, 69 ], "sta_period_ns": [ 17.33, 20.15, 16.68 ], "area_um2": [ 490120.0, 533624.0, 523472.0 ] } ], "labels": [ "Ein aktiver Kontext", "Vier direkt ausgewählte Kontexte", "Aktive Summe und Wechselplätze" ], "swap_source_sha256": "24df67143b8bc34be90955041abeeb5446497be33ebb0fd8e28f265465d58944", "case_labels": [ "K128 · 4 Kontexte · Block64", "K128 · 1 Kontext · Block64", "K128 · 4 Kontexte · Block16", "K131 · Stalls · Block64", "K5120 · echte Gate-Gewichte", "K5 · Sonderwerte · Block1" ] }, "swap": { "status": "complete_combined_gate_failed", "label": "Aktive Summe + drei Wechselkontexte", "note": "Der aktive Kontextbaustein verkürzt im Hauptfall die Laufzeit bei gleichem Takt um 7,17 %. Die modellierte Kachelenergie steigt um 1,97 %, die aktive Instanzfläche um 6,80 %. Vergleichsbasis ist die eigene Ein-Kontext-Kachel." }, "sources": [ { "title": "OpenROAD", "url": "https://github.com/The-OpenROAD-Project/OpenROAD" }, { "title": "IHP Open PDK", "url": "https://github.com/IHP-GmbH/IHP-Open-PDK" }, { "title": "Berkeley HardFloat", "url": "https://www.jhauser.us/arithmetic/HardFloat.html" }, { "title": "Ramulator 2", "url": "https://github.com/CMU-SAFARI/ramulator2" } ], "publication": { "brand": "Feldra Labs", "report_count": 21, "scope": "Curated research summaries and downloadable arithmetic; original laboratory archives retained privately." } }