Vertiefende Analyse · Etwa 4 Min. Lesezeit
Laplace 3B auf Trainium2: Fester Zustand ist kein perfektes Gedächtnis
Der i14/AWS-Bericht trennt Zustandsgröße, Optimiererkommunikation und reale Kompilierungskosten.
- Hier veröffentlicht
- Datum der Quelle
- Quelle geprüft
Ein AWS-Beitrag vom 20. Oktober beschreibt Training und Betrieb von i14s Laplace 3B auf Trainium2 mit nativem PyTorch. Ein fester rekurrenter Zustand ersetzt einen wachsenden KV-Cache. Entscheidend ist, welche Grenze sich dadurch verschiebt und welche Qualitäts- und Betriebsfragen offenbleiben.
Nachrichten anhören
Diesen Artikel vorlesen oder mit den Nachrichten fortfahren.
Vorlesen wird vorbereitet…
Gerätestimme
Browser oder Gerät verarbeiten die Sprache. AISubHub sendet den Text nicht an eine Audio-API. Stimmen und Wiedergabe bei gesperrtem Bildschirm hängen vom Gerät ab.
Beim Fortsetzen kann sich ein kurzer Satzteil wiederholen.
Auf einen Blick
- Berichtet werden 29.5 MB Zustand je Sequenz und insgesamt 11544 Ausgabetokens pro Sekunde bei 1280 Sequenzen auf einer trn2.48xlarge. Das sind weder Gesamtspeicher noch Nutzerrate.
- Der Trainingsplan umfasst 100 Milliarden Tokens, die Ergebnisse etwa 44 Milliarden. 24-fach weniger Kommunikation ist etwas anderes als 1.63-facher Trainingsdurchsatz.
Komprimierte Geschichte statt verlustfreier Erinnerung
Softmax-Inferenz speichert üblicherweise mit dem Kontext wachsende Schlüssel und Werte. Laplace 3B aktualisiert mit Gated Linear Attention eine rekurrente Matrix und komprimiert frühere Inhalte in 29.5 MB je Sequenz. Der Trainingsaufwand der Aufmerksamkeit skaliert linear statt quadratisch mit der Länge. Gewichte, Aktivierungen, Eingabeverarbeitung und andere Puffer verschwinden dadurch nicht. Auch der Informationsabruf verändert sich durch Kompression. Die Quelle verlangt ausdrücklich Tests für die jeweilige Arbeitslast: Eine lange Unterhaltung im Speicher unterzubringen beweist nicht, dass jedes alte Detail mit nötiger Genauigkeit abrufbar bleibt.
Chipanpassung und Kommunikation wirken verschieden
Das Team ersetzt einen GPU-spezifischen Triton-Kern durch PyTorch-Operatoren. Sechzehn Blöcke zu 128 Tokens passen zu den 128 Pufferpartitionen; der Bericht schreibt dieser Ausrichtung 14% Durchsatzgewinn zu. Bei Muon mussten verteilte Gradienten weiterhin Informationen über Partitionsgrenzen nutzen. Zwei All-to-all-Austausche verteilen vollständige Matrizen zur parallelen Verarbeitung und liefern Ergebnisse zurück. Der Verkehr je Rang fällt von 10.87 GB auf 0.45 GB, der Durchsatz steigt von 73378 auf 119934 Tokens pro Sekunde. 24-fach weniger Kommunikation bedeutet ausdrücklich keine 24-fache Trainingsbeschleunigung.
Der Plan ist nicht das abgeschlossene Ergebnis
Die Konfiguration nennt 3.028 Milliarden Parameter, 24 Schichten und einen FineWeb-Edu-Plan mit 100 Milliarden Tokens. Die gezeigten Trainingsresultate enden bei Schritt 84210, ungefähr 44 Milliarden Tokens, statt nach den geplanten 190735 Schritten. Etwa 120000 Tokens pro Sekunde und sinkender Loss gelten für diesen Laufabschnitt. Stabilität ist ein nützlicher Implementierungsbefund, aber kein Anwendungsbenchmark, kein Vergleich mit allen Transformern und kein Nachweis faktischer Erinnerung. Wir trennen daher den gelungenen Hardwareport von der weiterhin aufgabenspezifisch zu belegenden Modellqualität.
Gesamtdurchsatz braucht seine Konfiguration
Eine trn2.48xlarge nutzt im Test 64 logische NeuronCores mit je 20 Sequenzen pro Replikat, insgesamt 1280. Die 11544 Ausgabetokens pro Sekunde werden über diese Last geteilt. Der ungefähr 82-fach kleinere Zustand wird mit einem vergleichbaren KV-Cache bei 8192 Tokens verglichen, nicht mit der Gesamtrechnung. Eingaben von 2048 auf 8192 Tokens erhöhten die Kosten pro Ausgabetoken im Experiment um 0.5%. Eingabearbeit, Hardwarezuteilung, Qualität und Auslastung bleiben für ein echtes Budget relevant.
Realer Verkehr deckt versteckte Kompilierung auf
Eine neue Decode-Batchbreite erforderte zunächst etwa 11 Sekunden Kompilierung. Diese Schritte machten 1.1% der Schritte, aber 47.5% der Decode-Zeit aus. Auffüllen auf feste Breiten beseitigte diese Kosten; Gewinne bei versetzten Ankünften unterschieden sich von festen Batches. Zudem kann BF16-Neuverknüpfung kompilierte Ausgaben leicht von Eager-Ausgaben unterscheiden; für exakte Reproduzierbarkeit nennt die Quelle Eager. Ein Pilot sollte Ankunftsmuster, hohe Wartezeiten, numerische Toleranzen und Informationsabruf gemeinsam prüfen. Das sind unsere Prüfvorschläge, keine von AISubHub gemessenen Einsparungen oder bereitgestellten Dienste.
Warum es wichtig ist
Unsere Analyse: Fester Zustand kann lange Sitzungen planbarer machen. Dafür müssen Informationsabruf und reale Ankunftsmuster geprüft werden; Architektur und Laufzeit gehören zusammen.
Grenzen und Verfügbarkeit
Wir lasen Text und Bildunterschriften vollständig, führten aber keinen Code aus. Ergebnisse stammen von i14/AWS, nicht von uns. Ein Abopreis, kostenlose Hardware, universelle Überlegenheit oder Produktionsgarantie ist nicht belegt. TorchNeuron Native wurde als Beta verwendet.
Quellen und Belege
Datum der Quelle: · Quelle geprüft:
KI-gestützte redaktionelle Beiträge, anhand der genannten Primärquellen geprüft. Anbieterangaben werden zugeordnet; eine Aufnahme ist keine Empfehlung.