Research bei LuNa

Vielleicht · Bald

Ein Modell wachsen lassen — ohne es zu trainieren

Eine Frage lässt uns nicht los: Kann man neues Wissen in ein Modell packen, ohne es neu zu trainieren — ohne dass es vergisst, was es schon konnte, und so, dass es wirklich größer und fähiger wird?

Mehr verraten wir vorerst nicht. Es ist früh, und wir wissen selbst nur halb, ob es klappt. Aber wenn ja, verändert es, wie ein Modell nach dem Bauen dazulernt — und das wäre eine eigene Seite wert.

Status: explorativ. Keine Versprechen, keine Termine. Sobald es etwas Echtes zu zeigen gibt, steht es zuerst hier.

Unser eigener HIP-Kernel

Unser Training läuft nicht auf Standard-Code. Ein Kernstück läuft auf vier selbst geschriebenen HIP-Kernels — keine fertige Kernel-Bibliothek per pip, keine vorgebaute Extension — zugeschnitten auf genau die Karte, die wir tatsächlich haben: eine AMD Radeon RX 9060 XT (RDNA 4, gfx1200, 16 GB) unter ROCm.

Vier Kernel, vier Aufgaben. Jede Zahl unten ist auf dieser Karte gemessen, nicht geschätzt:

Kernel	Aufgabe	Gemessen
Feld-Generierung	baut Gewichtsmatrizen live auf	9,2×–13,1× schneller als reines PyTorch
Fused Backward	fasst den Backward-Pass in einen Kernel-Start	2,1× 11.900 → 25.500 tok/s
Fused Cross-Entropy	baut die volle Logit-Matrix nie im Speicher auf	+6,8 % Tempo, −56 % VRAM
INT4-GEMV	4-Bit-Inferenz-Decoding (Q4_K/Q6_K)	2,5× Decode-Tempo, 3,0× weniger VRAM

Die VRAM-Ersparnis durch den Fused-Cross-Entropy-Kernel (7,67 GB → 3,41 GB) ist es, die deutlich größere Batches erlaubt — und da zeigt sich der eigentliche Effekt: bei Batch 64 liegt der Durchsatz bei 46.600 Token/s. Auf der Inferenz-Seite entscheidet der INT4-Kernel darüber, ob ein 7B-Modell überhaupt auf diese Karte passt — bf16 braucht 15,23 GB und ist damit schon nahe an der 16-GB-Grenze, bevor überhaupt ein KV-Cache dazukommt; der INT4-Pfad braucht 4,77 GB.

Korrektheit zuerst

Ein schneller Kernel, der falsch rechnet, ist schlimmer als keiner. Jeder dieser Kernel wird gegen PyTorchs eigene Referenz geprüft: Gradienten per gradcheck in fp64, der Cross-Entropy-Loss bit-genau bis 9,5e-7, und die INT4-Ausgabe an einem echten 3B-Modell mit Kosinus-Ähnlichkeit 1,000000 gegen das bf16-Original verifiziert.

Wir sind auch bei den Grenzen ehrlich: Der INT4-Kernel erreicht aktuell etwa 200–280 GB/s der ~640 GB/s Speicherbandbreite, die die Karte maximal hergibt — da ist noch Luft nach oben, und die steht auf unserer Liste, nicht unter dem Teppich.

7/10

Unsere eigene, ehrliche Einschätzung. Die Techniken (Kernel-Fusion, gekachelter Online-Softmax, warp-basiertes GEMV) sind etabliert, nicht hier erfunden — die Leistung liegt darin, sie korrekt anzuwenden, mit echten gemessenen Gewinnen und strenger Korrektheitsprüfung, komplett von Hand, auf einer einzelnen Consumer-GPU, für die kaum ML-Tooling optimiert ist. Was höher verhindert: nur auf einer GPU-Form verifiziert, nicht peer-reviewed, und außerhalb unserer eigenen Trainingsläufe noch nicht im echten Praxistest.

Quellcode bleibt vorerst geschlossen. Wir machen den Kernel-Code aktuell nicht Open Source — unser Fokus liegt weiterhin auf den Modellen selbst, nicht darauf, Infrastruktur als eigenes Produkt zu veröffentlichen.

Bald mehr

Wir stecken gerade spürbar mehr Arbeit in unsere Modelle. Ein Teil davon wird als LuNa 0.7 sichtbar; ein anderer Teil entsteht hier, auf dieser Seite. Schau wieder vorbei.