Encoder, Experten und Speicher

Es gibt einen Moment, der in den Gesprächen der letzten Monate immer wiederkehrt, und er kommt stets an derselben Stelle. Der Anwendungsfall ist besprochen, alle sind sich einig, dass ein LLM nötig ist, und dann sagt jemand — meist nicht die technische Person, meist die, die unterschreibt — den Satz: «Ich habe gelesen, dass diese chinesischen Modelle so gut sind wie ChatGPT und dazu gratis. Nehmen wir eines davon ins Haus und haben Ruhe?»

Es ist eine gute Frage. Es ist auch eine Frage ohne einzeilige Antwort, und wie Sie die nächsten zwanzig Sekunden gestalten, entscheidet, ob Sie für den Rest des Projekts die Person sind, die mitdenkt, oder die, die einen Anbieter verteidigt.

Für eine gute Antwort reicht es nicht zu wissen, dass DeepSeek eine neue Version veröffentlicht hat. Sie müssen wissen, was sich geändert hat, denn diese Änderung — nicht die Versionsnummer — sagt Ihnen, ob das Modell im Rechenzentrum des Kunden laufen kann. Was folgt, ist das Minimum, um dieses Gespräch auf Augenhöhe zu führen: Encoder und Decoder, Mixture of Experts, Lookup-Speicher, und womit man es tatsächlich betreibt.

Was wirklich passiert ist, der Reihe nach

Ich fasse die Fakten zusammen, denn der Faden reisst schnell.

Am 14. August hat Zhipu GLM-5.3 veröffentlicht, vorgestellt als stärkstes offenes Modell fürs Coding. Interessant daran ist, dass es sich das Basismodell mit GLM-5.2 teilt: Der gesamte Zugewinn kommt allein aus dem Post-Training. Auf ihrem internen Coding-Benchmark nennen sie einen relativen Sprung von 50%, und auf den öffentlichen agentischen Benchmarks geht es von 4,6 auf 28,3 bei Terminal-Bench 3.0 und von 46,2 auf 66,9 bei DeepSWE v1.1. Die Gewichte kamen zwei Wochen nach der Ankündigung heraus, nach Abschluss der Sicherheitsprüfungen.

Qwen3.8-Flash-Next hat eine Idee in Produktion gebracht, die bis dahin vor allem ein Paper war: der Netzwerkarchitektur eine riesige Tabelle mit N-Gramm-Embeddings zur Seite zu stellen — 51 Milliarden Parameter, zwanzig Millionen Bi- und Trigramme — die nichts rechnet und nur gelesen wird. Das Backbone ist ein Mixture of Experts — MoE, das Kürzel, das Ihnen ab jetzt überall begegnet — mit 125 Milliarden Parametern und 6 Milliarden aktiven pro Token.

Am 10. September kam DeepSeek-V4.1-Flash, und dieses Modell interessiert mich am meisten, weil es alle drei Bausteine zusammenbringt, um die es hier geht. Angegebener Kontext von einer Million Token, und ein API-Preis, der ausserhalb der Spitzenzeiten bei 0,15 Dollar pro Million Token im Input und 0,60 im Output liegt, mit bereits zwischengespeichertem Input bei 0,003.

Die Architektur fasst DeepSeek allerdings in drei Zeilen, und von dort lohnt es sich zu starten: Engram-Speicher mit 196 Milliarden Parametern, ein MoE-Backbone mit 552 Milliarden, und eine neue Causal-Encoder-Decoder-Architektur mit nur 8 Milliarden aktiven Parametern für den Input und 16 für den Output.

Merken Sie sich diese Zeilen. Sie sind das Datenblatt jedes offenen Modells, das Ihnen in den nächsten Monaten vorgelegt wird, und alles Weitere dient dazu, sie zu lesen: drei Zeilen, drei Konzepte, und aus jedem folgt eine Frage, die das Angebot verschiebt. V4.1-Flash ist ausserdem der bequemste Fall zum Nachdenken, weil es die Techniken der beiden anderen vereint — das MoE, das alle haben, und den Lookup-Speicher, den Qwen auf echte Grösse gebracht hat — und die Trennung zwischen Encoder und Decoder hinzufügt.

Eine Sache zu den Zahlen noch vorweg, denn das ist das häufigste Missverständnis: Es sind drei Grössen an drei verschiedenen Orten, und sie addieren sich nicht so, wie es aussieht. Die 552 Milliarden sind das Backbone — Attention, Embeddings und Experten, Encoder und Decoder zusammen. Die 196 Milliarden des Engram-Speichers liegen ausserhalb dieser Rechnung, denn sie sind eine Tabelle und kein Netz. Und die 8 und die 16 sind keine dritte Gruppe: Sie sind der Anteil der 552, der tatsächlich aktiv wird, beim Lesen und beim Schreiben.

Die Richtung ist die im Diagramm: Die Leistung wächst, und die Parameter, die pro Token wirklich arbeiten müssen, sinken. Es gibt nichts geschenkt — dazu später mehr — aber es ist der Grund, warum die Frage des Kunden, vor zwei Jahren naiv, heute eine ernsthafte Antwort verdient.

Warum die Frage gerade jetzt kommt

Es gibt drei Treiber, und man hält sie besser auseinander, denn sie führen zu verschiedenen Entscheidungen.

Der erste ist regulatorisch und wird am häufigsten missverstanden. Die Pflichten für Modelle mit allgemeinem Verwendungszweck gelten seit dem 2. August 2025. Die Transparenzpflichten aus Artikel 50 — der Person zu sagen, dass sie mit einem KI-System spricht, generierte Inhalte zu kennzeichnen — gelten ab dem 2. August 2026, mit einer Verlängerung bis zum 2. Dezember 2026 für die Kennzeichnung bei Systemen, die schon auf dem Markt sind. Die Fristen für Hochrisikosysteme haben sich dagegen verschoben: Die Omnibus-Verordnung ist seit dem 27. Juli 2026 in Kraft und verschiebt eigenständige Systeme nach Anhang III auf den 2. Dezember 2027, in bereits regulierte Produkte eingebettete KI auf den August 2028.

Das gehört ins Gespräch, denn die Hälfte der Kunden glaubt an eine Frist, die sie nicht hat, und die andere Hälfte glaubt, gar keine zu haben, während Artikel 50 sie sehr wohl betrifft. In jedem Fall: Keine dieser Regeln sagt, dass das Modell im eigenen Haus stehen muss. Self-Hosting ist eine mögliche Antwort auf eine Anforderung an Datenhaltung oder Anbieterkontrolle, keine Pflicht für sich.

Der zweite Treiber sind die Kosten, und hier fehlt fast immer eine Überlegung. Self-Hosting macht aus variablen Kosten fixe. Es lohnt sich ab einer bestimmten Menge, und diese Schwelle ist gestiegen, nicht gesunken, weil der Preis pro Token in der Cloud weiter fällt. Wenn der Kunde zehntausend Aufrufe im Monat macht, amortisiert sich ein Server für 200'000 Franken nie, und ihm das zu sagen ist die Leistung, die Sie verkaufen.

Der dritte ist die Kontrolle: zu wissen, wo die Daten liegen, nicht von einer Abkündigung abhängig zu sein, eine Version einfrieren zu können. Das ist oft der eigentliche Grund, auch wenn er als einer der beiden anderen präsentiert wird. Und darauf ist Self-Hosting tatsächlich die Antwort.

Die Versionsnummer ist kein Argument

In einem Pre-Sales-Gespräch oder in einer fachlichen Diskussion nützt es Ihnen nichts zu wissen, dass die 4.1 draussen ist und besser läuft als die 4: Das weiss der Kunde auch, aus demselben Beitrag, den Sie gelesen haben. Sie müssen beantworten können, warum sie besser läuft, denn daraus folgt alles Übrige — wie viel Speicher nötig ist, was sich quantisieren lässt, was bricht.

Es sind die drei Zeilen von vorhin, rückwärts gelesen: wie ein Modell innen gebaut ist — die Zeile mit dem Causal Encoder-Decoder, die mit der 8 und der 16 — wie es gross sein kann, ohne wie ein grosses Modell zu kosten — die 552 Milliarden des MoE — und wie es sich Arbeit spart, die es schon millionenfach gemacht hat, also die 196 Milliarden des Engram-Speichers. Ich gehe sie der Reihe nach durch, vom Fundament aus: Wer das Fundament hat, springt zu den Zwischentiteln.

Erstes Konzept: was ein Transformer ist, und warum es ihn gibt

Bis 2017 lasen Sprachmodelle Text so, wie wir ihn lesen: ein Wort nach dem anderen, im Kopf behaltend, was vorher kam. Das funktionierte, hatte aber zwei Schwächen. Bei langen Sätzen ging der Anfang unterwegs verloren. Und vor allem liess es sich nicht parallelisieren: Wenn man für das sechste Wort erst das fünfte fertig haben muss, nutzt man eine GPU mit Tausenden Kernen zu einem Zehntel ihrer Möglichkeiten.

2017 veröffentlichte eine Gruppe bei Google ein Paper, dessen Titel bereits die These ist: Attention Is All You Need. Die Idee ist, das sequenzielle Lesen wegzuwerfen. Geben Sie dem Modell den ganzen Satz auf einmal, und lassen Sie es für jedes Wort berechnen, wie relevant jedes andere Wort dafür ist. Dieses «wie relevant» ist die Attention, und darauf läuft alles Weitere.

Ein Beispiel, damit es greifbar wird. Nehmen Sie den Satz: «Die Überweisung auf das ausländische Konto ging nicht durch, weil es gesperrt war». Bezieht sich dieses es auf die Überweisung oder auf das Konto? Wir lösen das, ohne es zu merken. Das Modell löst es über Gewichte: Während es «es» verarbeitet, fragt es, wie stark «Überweisung» zählt und wie stark «Konto», und bildet den gewichteten Mittelwert ihrer Repräsentationen. Diese Rechnung — die Self-Attention — wird für jedes Wort gegen alle anderen gemacht, und für alle Wörter gleichzeitig. Und genau das ist der Punkt: Es sind Matrixmultiplikationen, und nichts anderes machen GPUs den ganzen Tag.

Diese Architektur heisst Transformer. Sie ist der Grund, warum es LLMs gibt: nicht weil sie klüger wäre als das, was vorher da war, sondern weil sie skaliert. Man kann zehntausend Karten und Monate an Training hineinstecken, und sie wird weiter besser.

Der Punkt fürs Gespräch lautet: Alle Modelle, über die wir sprechen, sind Transformer. GPT, Claude, Llama, Qwen, GLM, DeepSeek. Alles Weitere sind Variationen über dieses Thema, keine Alternativen. Wenn ein Anbieter Ihnen eine Architektur als revolutionär präsentiert, ist die richtige Frage fast immer: «Welches Stück des Transformers haben Sie geändert?»

Die zwei Hälften: wer liest und wer schreibt

Wir sind bei der dritten Zeile, der mit dem Causal Encoder-Decoder: In V4.1-Flash sind das vierzig Layer, zwanzig pro Hälfte, und aus dieser Teilung kommen die 8 und die 16.

Im Paper von 2017 besteht der Transformer aus zwei Blöcken, und es sind zwei, weil dieses Modell übersetzen sollte.

Der Encoder bekommt den französischen Satz — der schon vollständig dasteht — und baut daraus eine interne Repräsentation, die Hidden States: eine Art «was dieser Satz bedeutet» in Zahlenform. Der Decoder nimmt diese Repräsentation und erzeugt den deutschen Satz, ein Wort nach dem anderen, und schaut dabei sowohl auf die übergebene Bedeutung als auch auf das, was er bereits geschrieben hat.

Der Unterschied liegt nicht in Grösse oder Können. Er liegt darin, was jeder anschauen darf, und hier lohnt sich Deutlichkeit, denn dieser Punkt kehrt später überall wieder.

Der Encoder arbeitet an einem Text, der bereits vollständig existiert. Während er das fünfte Wort verarbeitet, kann er also auch das neunte und das zwanzigste verwenden: Sie liegen auf dem Tisch. Das meint bidirektionale Attention — sie liest vorwärts und rückwärts. Denken Sie an eine Lektorin: erst das ganze Dokument lesen, dann entscheiden.

Der Decoder kann das nicht. Der Decoder schreibt gerade, und wenn er beim fünften Wort ist, existiert das neunte noch nicht: Er muss es erst erzeugen. Ihm wird durch die Konstruktion verwehrt, über die Position hinauszuschauen, an der er arbeitet, und diese Einschränkung heisst Causal Mask: kausal in dem Sinn, dass die Ursache vor der Wirkung kommt. Das ist kein Implementierungsdetail. Ohne diese Maske würde das Modell im Training schummeln: Man gibt ihm den ganzen Satz und verlangt das sechste Wort, und wenn es das Wort sehen kann, lernt es nicht, es vorherzusagen, sondern es abzuschreiben.

Warum ist Bidirektionalität wertvoll, wenn man sie haben kann? Weil die Bedeutung eines Wortes sehr oft von dem abhängt, was danach kommt. «Ich habe das Konto geschlossen»: das Bankkonto oder die Abrechnung? Das erkennen Sie nur an der Fortsetzung. Wer liest, kann bis zum Ende warten. Wer schreibt, nicht.

BERT, und warum es sich lohnt zu wissen, wer das ist

BERT — die Abkürzung steht für Bidirectional Encoder Representations from Transformers, und der Name sagt bereits alles — ist das Modell, mit dem Google im Paper von 2018 allein die Encoder-Hälfte genommen und berühmt gemacht hat. Man chattet nicht damit: Es generiert keinen Text, ist kein Assistent, hat keinen Systemprompt. Sie geben ihm Text, und es gibt Ihnen Zahlen zurück.

Hier lohnt sich Konkretheit, denn an dieser Stelle reisst meist der Faden. Geben Sie einem Encoder den Satz «die Überweisung wurde abgelehnt», dann kommt ein Vektor zurück: eine Reihe von Zahlen, 768 bei BERT-base, 1024 bei BERT-large, 384 bei den kleinen Modellen, die man heute für die Suche verwendet. Einzeln genommen bedeuten sie nichts und sind nicht lesbar. Sie haben aber eine Eigenschaft: Texte mit ähnlicher Bedeutung erzeugen nahe beieinander liegende Vektoren.

«Die Überweisung wurde abgelehnt» und «die Zahlung ist nicht durchgegangen» haben fast kein Wort gemeinsam, und ein LIKE '%...%' bringt sie nie zusammen. Ihre Vektoren dagegen liegen sehr nah beieinander, während der Vektor von «die Sitzung ist um drei» auf der anderen Seite des Raums landet. Das ist das Embedding: Text als Koordinaten, in einem Raum, in dem Nähe Bedeutungsähnlichkeit ist.

Und genau deshalb funktioniert ein RAG. Wenn Sie die Dokumente des Kunden indexieren, landet nicht der Text in der Vektordatenbank, sondern diese Vektoren. Dann kommt die Frage der Person, Sie wandeln sie gleich um und suchen die nächstgelegenen Vektoren. Sie finden die richtige Stelle auch dann, wenn die Person Wörter benutzt hat, die im Dokument nicht vorkommen. Diese Umwandlung macht ein Encoder.

Dann gibt es die zweite Art, dieselbe Ausgabe zu nutzen. Setzen Sie auf den Encoder einen Klassifikationskopf, bekommen Sie statt Koordinaten ein Etikett: Spam oder nicht, dieses Wort ist ein Personenname, dieses Ticket betrifft die Rechnungsstellung. Dasselbe Modell, dieselbe Rechnung, zwei Arten der Nutzung. Mit dem Kopf entscheidet das Modell und gibt Ihnen ein Wort; mit den rohen Vektoren entscheidet jemand anderes — die Vektorsuche, ein Reranker, ein Clustering — und das Modell liefert nur die Koordinaten.

Diese Vektoren sind übrigens dieselben Hidden States wie oben. In einem Decoder bleiben sie innen und dienen dazu, das nächste Wort zu erzeugen. In einem Encoder nehmen Sie sie mit: Sie sind das Endprodukt.

Eine Klarstellung, die Peinlichkeiten erspart: BERT, wie es kommt, ist nicht das Modell für ein RAG. Die Autoren von Sentence-BERT schreiben es im Abstract — die Konstruktion von BERT macht es für die Ähnlichkeitssuche ungeeignet — und haben diese Architektur 2019 eigens nachtrainiert, womit der Vergleich von zehntausend Sätzen von fünfundsechzig Stunden auf wenige Sekunden fiel. Die Embedding-Modelle, die Sie heute verwenden, stammen aus dieser Arbeit, nicht von BERT ab Stange.

Es lohnt sich aus zwei sehr konkreten Gründen zu wissen, wer das ist.

Erstens: Diese Familie ist keineswegs tot, Sie benutzen sie täglich, ohne sie beim Namen zu nennen. Jedes Mal, wenn Sie ein Embedding berechnen, jedes Mal, wenn Sie Ergebnisse neu sortieren, steckt fast immer ein Nachfahre von BERT darunter. Wenn der Kunde ein RAG in Produktion hat, steckt darin ein Encoder, auch wenn es im Raum niemand weiss.

Zweitens schlägt ein kleiner Encoder bei diesen Aufgaben ein riesiges generatives Modell, kostet ein Hundertstel und antwortet in Millisekunden. Regelmässig trifft man Unternehmen, die Support-Tickets mit einem Aufruf an ein generatives LLM klassifizieren. Das ist wahrscheinlich der einfachste Rat in einem Gespräch, und er ist so viel wert wie der ganze Rest.

Dann kam OpenAI und machte das Gegenteil: den Encoder weg, nur den Decoder behalten, ihm das halbe Internet vorlegen und ihn schlicht das nächste Wort erraten lassen. Von da an ist alles, was wir LLM nennen — GPT, Claude, Llama, die DeepSeeks bis zur V4 — Decoder-only.

Und hier kommt DeepSeek, mit einem Wort, das man nicht übersehen sollte

Der technische Bericht zu DeepSeek-V4.1-Flash beschreibt das Modell als Causal Encoder-Decoder: vierzig Layer, zwanzig Encoder und zwanzig Decoder. Und man liest herum — so habe ich es auch in einem derzeit weit verbreiteten Video gehört — das sei eine Rückkehr zum bidirektionalen Encoder im Stil von BERT.

Das stimmt nicht, und das Adjektiv steht mit Absicht da: Der Encoder ist kausal. Das gesamte Backbone behält die Causal Mask, niemand schaut nach vorn. Was DeepSeek aus der Architektur von 2017 aufgreift, ist nicht die Bidirektionalität, sondern die Rollenteilung: Eine Hälfte verdaut den Input, die andere erzeugt.

Und der eigentliche Gewinn steckt in einem Detail, das technisch aussieht und es nicht ist. In einem Decoder-only-Modell baut und behält jeder Layer seinen eigenen KV-Cache (Key-Value), das Arbeitsgedächtnis der Attention: jenes, das mit der Kontextlänge wächst und der Kostenposten ist, der agentische Projekte umbringt. Zwanzig Layer, zwanzig Caches. Hier rechnet der Decoder ihn nicht: Er projiziert ihn aus dem letzten Hidden State des Encoders. Eine Projektion statt zwanzig Caches.

Daraus folgen die zwei Zahlen, auf die es ankommt. Der Verbrauch fällt auf rund 890 Byte pro Token, ein Viertel der vorherigen Generation — und zum Massstab des Wegs: DeepSeek-V1 lag bei etwa 390'000 Byte pro Token. Und es entsteht die Asymmetrie, die in den Schlagzeilen seltsam klingt: 8 Milliarden aktive Parameter beim Lesen, 16 beim Schreiben, im Jargon 8B im Prefill und 16B im Decode. Sind die beiden Rollen erst getrennt, gibt es keinen Grund mehr, ihnen dasselbe Budget zu geben: einen langen Input verstehen und einen guten Output erzeugen sind zwei verschiedene Arbeiten.

Wenn wir schon dabei sind, eine Klarstellung, die ich ständig falsch höre und die Sie in einer Fachdiskussion ausweist: Die Kosten der Attention über den Kontext wachsen nicht exponentiell. Sie wachsen quadratisch in der Rechenlast und linear im Cache-Speicher. Das ist keine akademische Pedanterie: «Exponentiell» legt nahe, langer Kontext sei ein unlösbares Problem, «quadratisch mit linearem Cache» sagt Ihnen genau, wo anzusetzen ist. Und genau dort haben sie angesetzt.

Zweites Konzept: Mixture of Experts, dünn in der Rechnung, nicht im Speicher

Zweite Zeile: 552B-parameter MoE. Es ist das bekannteste der drei Konzepte und wird fast immer halb erzählt.

Ein dichtes Netz schickt jedes Token durch alle seine Parameter. Ein Mixture of Experts — kurz MoE, und so sehen Sie es in Datenblättern und Modellnamen — ersetzt den Feed-Forward-Block durch viele kleinere Blöcke, die Experten, und stellt einen Router davor, der für jedes Token wenige davon auswählt. In DeepSeek-V4.1-Flash sind es 384 Routed Experts plus ein Shared Expert pro MoE-Layer, und pro Token werden 6 davon plus der Shared aktiv.

Das Ergebnis ist die zweite Hälfte der dritten Zeile: Ein Modell mit 552 Milliarden Parametern kostet pro Token so viel wie ein Modell mit 8 oder 16 Milliarden. Das macht den oben genannten Listenpreis möglich.

Und jetzt der Teil, der im Gespräch den Unterschied macht, denn hier überzeugt sich der Kunde — oder Ihr technisches Gegenüber — von etwas Falschem: MoE ist dünn in der Rechnung, nicht im Speicher. Alle 384 Experten müssen im schnellen Speicher liegen. Der Router entscheidet erst zur Laufzeit anhand der Aktivierungen, welche gebraucht werden: Man kann es vorher nicht wissen, also kann man sie nicht anderswo halten und rechtzeitig holen.

Sechzehn Milliarden aktiv, aber beherbergen müssen Sie fünfhundertzweiundfünfzig.

Das ist der Grund, warum die VRAM-Rechnung fast nie so aufgeht, wie man es erwartet.

Drittes Konzept: N-Gramme und Engram, die zweite Achse der Sparsamkeit

Bleibt die erste Zeile, die mit den 196 Milliarden. Es ist das jüngste der drei Konzepte und das am wenigsten verbreitete, und es ist jenes, das die Hardwarefrage tatsächlich verändert.

Die Ausgangsbeobachtung ist einfach: In den Parametern eines Modells leben zwei sehr verschiedene Dinge. Auf der einen Seite die Fähigkeit zu schliessen, zu formulieren, Anweisungen zu folgen. Auf der anderen die wiederkehrenden Muster: kurze Tokenfolgen, die das Modell millionenfach gesehen hat und die es bei jeder Inferenz neu aufbaut, indem es sie durch die ersten Layer schickt. Das ist Rechenzeit, die aufgewendet wird, um etwas Statisches zurückzugewinnen, und im Paper formuliert DeepSeek es so: Der bedingte Speicher entlastet die ersten Layer von der Rekonstruktion statischer Muster.

Die Idee ist also, diese Muster aus dem Netz zu holen und in eine über N-Gramme indexierte Lookup-Tabelle zu legen. An jeder Position schaut man auf die kurze, gerade gesehene Tokenfolge, liest die passende Zeile, und dieser Vektor wird in den Residual Stream eingespeist. Null Matrixmultiplikationen: nur ein Lesezugriff.

Was in dieser Tabelle wirklich steht, wird in beide Richtungen falsch erzählt, und Genauigkeit lohnt sich. Es ist kein Faktenarchiv: Keine Zeile sagt, dass Rom die Hauptstadt Italiens ist, es gibt keine Subjekte und Prädikate, und schreiben können Sie auch nicht hinein. Es sind Vektoren, adressiert über Tokenfolgen, und zwar kurze — in V4.1-Flash sind die Ordnungen zwei, drei und vier Token, mit acht Hash-Köpfen pro Ordnung und rund sechzehn Millionen Zeilen pro Kopf.

Es ist aber auch kein inhaltsleeres syntaktisches Detail, und das Paper wird deutlich: Schaltet man den Speicher ab, brechen die Wissens-Benchmarks auf 29 bis 44% des ursprünglichen Werts ein, während das Textverständnis 81 bis 93% behält. Die Autoren nennen ihn den zentralen Ablageort des parametrischen Wissens im Modell. Der Mechanismus ist ein Lookup wiederkehrender Muster; die Wirkung ist, dass die Fakten dort wohnen.

Woher es kommt. Das Video, das dieser Tage kursiert, schreibt DeepSeek das erste Paper zum Thema zu. Das ist nicht korrekt, und dieses Detail lohnt sich in der Tasche. Der Vorfahr ist Scaling Embedding Layers in Language Models von Da Yu, Edith Cohen, Badih Ghazi und Kolleginnen und Kollegen — die Methode ist als SCONE bekannt, erschienen im Februar 2025 und an der NeurIPS vorgestellt. DeepSeek hat darauf mit Engram aufgebaut — Conditional Memory via Scalable Lookup — und Eigenes hinzugefügt: Multi-Head-Hashing, damit verschiedene Entitäten nicht kollidieren, und ein Gate, das die gelesene Zeile mit dem aktuellen Kontext vergleicht und sie unterdrückt, wenn beide sich widersprechen. Qwen kam danach, zitierte diese Arbeit und brachte die Tabelle auf ein Modell echter Grösse.

Warum das der Teil ist, der die Hardware betrifft. Hier liegt der eigentliche Grund, warum ich darüber schreibe, und der Unterschied zum MoE.

Der Index in die N-Gramm-Tabelle hängt nur von den IDs der bereits gesehenen Token ab. Nicht von den Aktivierungen, nicht vom Router, von nichts, was erst zur Laufzeit bekannt ist. Er steht also im Voraus fest: Während die GPU noch am aktuellen Token rechnet, können Sie die Zeile schon holen, die Sie danach brauchen. Asynchrones Prefetch, überlappend mit der Rechnung, ohne Stillstand. Und deshalb — und nur deshalb — können diese 196 Milliarden Parameter im Systemspeicher oder auf NVMe liegen statt im VRAM, während die 384 Experten das nicht können.

Zwei Klarstellungen lohnen sich noch, denn beide höre ich schlecht erzählt.

Erstens: Es ist kein RAG. Es gibt keine Ähnlichkeitssuche, kein Embedding der Frage, keinen Retriever. Es ist deterministische Adressierung in eine Tabelle, per Hash berechnet. Es RAG zu nennen verliert genau die Eigenschaft, die es nützlich macht: die Vorhersagbarkeit des Index.

Zweitens: Die Vorstellung, man könne Fakten aktualisieren, indem man in die Tabelle schreibt — Firmendokumente hineinladen und ein Modell erhalten, das sie kennt — ist reizvoll und wird oft wiederholt, ist heute aber eine Forschungsrichtung und keine verfügbare Funktion. Die Tabelle wird zusammen mit dem Rest des Modells trainiert und ist bei der Inferenz eingefroren. Wenn das jemand im Gespräch als Alternative zu Fine-Tuning oder RAG präsentiert, lohnt es sich, das geradezurücken.

Zu den Zahlen: DeepSeek berichtet, das Optimum liege darin, 20 bis 25% der Parameter dem bedingten Speicher zuzuweisen, und bei festem Rechenbudget wachse die Qualität log-linear mit der Grösse der Tabelle. Das ist das eigentlich Interessante: ein Skalierungshebel, der keine FLOPs kostet.

Läuft es also auf meiner Hardware?

Jetzt die konkrete Frage. Die Antwort, die ich vor einem Monat gegeben habe, war nein, und heute ist sie falsch: Es läuft, nur nicht mit der Engine, die Sie erwarten.

Auf dem Produktionsweg bleibt die Rechnung dieselbe. Der vollständige Checkpoint liegt bei rund 510 GB, und das vLLM-Rezept verlangt etwa 614 GB VRAM: ein Knoten mit acht H200 oder ein GB200-Tray.

Der andere Weg ist eine Engine, die für wenige Modelle geschrieben wurde. ds4, oder DwarfStar, ist die von Salvatore Sanfilippo: Backends für Metal, CUDA und ROCm, und V4.1-Flash unter den unterstützten Modellen. Das 2-Bit-GGUF wiegt 341 GiB, davon sind 189 die Engram-Tabellen, die auf der Platte bleiben und zeilenweise gelesen werden, wenn sie gebraucht werden, nie vollständig geladen. Im Speicher liegen müssen 152 GiB, auf einem Mac mit 128 GB arbeitet man also mit SSD-Streaming; zwei verbundene Maschinen mit 128 GB teilen sie sich, rund 81 GiB je Seite; auf einer mit 512 GB passen sie ganz hinein. Auf einem DGX Spark läuft es genauso, und die Mitte September veröffentlichten Zahlen nennen ein Prefill zwischen 93 und 96 Token pro Sekunde beim Streaming von der SSD.

Sehen Sie aber, was hier passiert ist, denn es ist das dritte Konzept, das zurückkehrt: Dieses Modell passt nur deshalb in eine Büromaschine, weil die 189 GiB Lookup-Speicher auf einer SSD liegen dürfen. Wären es 189 GiB Experten gewesen, hätte der Router sie alle im schnellen Speicher gewollt, und es gäbe überhaupt keinen Weg. Sparsamkeit im Zugriff ist kein Detail aus einem Paper: Sie ist der Grund, warum dieses Gespräch mit dem Kunden heute anders ausgeht als vor sechs Monaten.

Den Preis fürs Angebot muss man allerdings nennen: DwarfStar ist eine spezialisierte Engine, die auf den GGUFs läuft, die sie selbst erzeugt, kein allgemeines Runtime, auf dem man eine Plattform baut. Zum Ausprobieren und für den internen Gebrauch ist es der konkreteste Weg, den es gibt; für einen Dienst mit SLA sind Sie zurück auf dem Weg von oben.

Womit Sie es heute betreiben

Das ist der Teil, der in Diskussionen über offene Modelle immer fehlt, und er entscheidet, ob ein Projekt startet. Ein Modell mit öffentlichen Gewichten ist kein Modell, das Sie betreiben können: Sie brauchen ein Runtime, das seine Architektur umsetzt, und zwischen der Veröffentlichung der Gewichte und diesem Moment liegen Wochen oder Monate.

vLLM ist die einzige Antwort auf Produktionsniveau. Die Unterstützung kam ab Tag null und ist auf NVIDIA wie auf AMD verifiziert. Mit einem pip install kommen Sie aber nicht hin, denn kein Wheel bedient diese Architektur: Es geht über ein Docker-Image, und heute sind das die normalen Nightlies — jede Nightly ab dem 10. September. Das Rezept verlangt die erwähnten 614 GB, verteilt auf 259 GiB Experten und 183 GiB Engram-Tabellen. Derselbe Stack hat bereits einen Weg auf Silizium, das weder NVIDIA noch AMD ist, von Ascend bis Cambricon.

DwarfStar ist die andere Zeile, die das Modell heute lädt, und es ist die von oben: eine spezialisierte Engine, keine Plattform.

SGLang hat Preview-Container, keine Release: dev-dsv41 für NVIDIA und eine MI350X-Variante, die derzeit noch in einer offenen Pull Request steckt. Setups über mehrere vernetzte DGX Sparks gibt es, aber es sind Repositories Einzelner, kein offizieller Weg.

llama.cpp lädt es upstream nicht: Die Pull Request ist ein Entwurf und macht nur die Konvertierung — in den Worten des Autors lädt die konvertierte Datei nicht. Das Runtime existiert auf einem Branch seines Forks, und auch ik_llama.cpp hat eine offene PR für diese Architektur. Keine der beiden ist gemergt.

Ollama, LM Studio und MLX laden es lokal nicht: Ollama bietet es nur mit dem Tag cloud an, LM Studio aus der eigenen Cloud und ohne den lokalen Betrieb als validiert zu bezeichnen, und bei MLX ist die offizielle Pull Request offen, aber nicht gemergt, bei ein paar kursierenden Community-Portierungen. Hier lohnt es sich, eine verbreitete Überzeugung zu entschärfen, denn sie gilt über dieses Modell hinaus: Man sagt oft, Ollama sei ein Wrapper um llama.cpp, und das stimmt heute nicht mehr — es hat eine eigene Engine, und die Blockade ist, dass diese Engine die Architektur nicht umsetzt. Wenn Sie jemand fragt «können wir das auf Ollama nehmen?», lautet die eigentliche Frage immer gleich: Hat das Runtime, das Sie verwenden wollen, diese Architektur umgesetzt?

Und Achtung vor einer Falle, die einen Tag kostet: Auf Hugging Face finden Sie bereits ein halbes Dutzend Repositories DeepSeek-V4.1-Flash-GGUF, mit echten Gewichten darin, von Q2 bis Q8. Sie sehen nach Unterstützung aus und sind es nicht: Ein GGUF ist eine Datei, und solange das Runtime in Ihrer Produktion die Architektur nicht umsetzt, lädt diese Datei niemand. Verfügbare Gewichte und betreibbares Modell sind zwei verschiedene Daten, und dazwischen liegen Wochen.

Was wir verlieren

Und hier der Teil, der in begeisterten Präsentationen nie vorkommt.

Benchmarks sagen Verschiedenes, je nachdem, was sie messen. DeepSeek meldet 74,2 bei DeepSWE v1.1, vor Claude Opus 5 (74,0) und GPT-5.6 Sol (73,0). Auf demselben Material gibt Terminal-Bench 3.0 aber 30,0 gegen 43,3 bei Opus 5, und bei 4.0 wird der Abstand grösser: 31,2 gegen 51,8. Bei 2.1, der vorherigen Suite, liegt 4.1-Flash dagegen vor allen: 90,6 gegen 89,1. Das ist die Zahl, die man Ihnen zitieren wird, und sie stimmt — es wechselt die Suite, nicht das Modell. Der Unterschied liegt zwischen dem Lösen einer abgegrenzten Aufgabe und dem Durchhalten einer langen agentischen Sitzung, mit Werkzeugen, Fehlern und Erholung. Das Zweite ist das, was unsere Projekte tatsächlich tun.

Geschwätzigkeit kostet. Die unabhängigen Messungen von Artificial Analysis zählen 250 Millionen Output-Token gegenüber einem Median von 140 Millionen bei den Vergleichsmodellen: rund 80% mehr. Auf dem Papier sind die Kosten pro Token lächerlich und bleiben vorteilhaft; wenn Sie aber eine On-Premise-Infrastruktur dimensionieren, zahlen Sie diese Token in GPU-Sekunden, nicht in Dollar.

Harnesses funktionieren, aber nicht gratis. Claude Code lässt sich auf ein lokales Modell richten: Sie setzen ANTHROPIC_BASE_URL auf einen llama-server, der mit Template-Unterstützung gestartet wurde, und es funktioniert — samt Tool Calling und Prompt Caching, ohne Proxy. Im ausführlichsten Bericht, den ich gefunden habe, lässt sich der Kontext von einer Million Token aber nicht aufbauen, mit einer praktischen Grenze bei 256k, und ein Prefill von einigen Dutzend Token pro Sekunde bedeutet, dass die zwanzigtausend Token Systemprompt des Harness in der ersten Runde mehrere Minuten fressen. Es funktioniert. Ein Daily Driver ist es nicht.

Und es gibt ein Stück, das niemand mitnimmt. Wenn Sie Zugang zu einem geschlossenen Modell kaufen, kaufen Sie nicht nur die Gewichte: Sie kaufen den Dienst darum herum — die Verfügbarkeitszusage, das Tuning der Tool-Calling-Formate, den Moderationslayer, die Tatsache, dass jemand die Fehler schon gefunden hat. Wenn Sie das Modell ins Haus holen, wird diese ganze Arbeit Ihre. Sie gehört ins Angebot, denn das ist die Position, die üblicherweise fehlt.

Eine letzte Warnung, von der teuren Sorte: Am 10. September, dem Tag der Veröffentlichung, hat DeepSeek die Kennung deepseek-v4-flash auf die neue 4.1 umgelenkt, und am 14. dasselbe mit deepseek-v4-pro, das heute von der 4.1 zum Flash-Preis bedient wird. Wenn Sie eine Regressionssuite auf diesen Endpunkten haben, misst sie seit einigen Tagen ein anderes Modell. Es ist genau die Art von Vorfall, wegen der man die Gewichte ins eigene Haus holt.

Zurück zur Frage aus dem Gespräch

Stellen wir den Moment vom Anfang noch einmal auf die Bühne. Der Kunde hat gelesen, dass die chinesischen Modelle so gut wie ChatGPT und gratis sind, und fragt, ob man sie nicht ins Haus nehmen sollte.

Der Punkt dieses ganzen Textes ist nicht, dass Sie jetzt wissen, was MoE bedeutet. Er ist, dass diese Frage, die wie eine einzige aussieht, in Wahrheit vier enthält — und jede der vier folgt aus einem der Konzepte von oben. Sie neu zu formulieren ist das, was Sie in diesen Raum mitbringen und was der Kunde allein nicht kann.

«Wie viele aktive Parameter, und wie viele insgesamt?» Kommt vom MoE. Der Kunde nennt Ihnen die Zahl aus dem Beitrag; Sie brauchen die andere, denn die eine dimensioniert die Rechenlast und die andere den Speicher. Wenn der Anbieter — oder die begeisterte Kollegin — nur antwortet «wir aktivieren sechzehn Milliarden», haben Sie nichts Brauchbares über den Server erfahren, den Sie kaufen müssen.

«Wie viel Kontext nutzen wir wirklich, und für wie viele parallele Sitzungen?» Kommt vom KV-Cache. Es ist die Frage, die niemand stellt und die später die Budgets sprengt, denn dieser Cache wächst nicht mit der Zahl der Parameter: Er wächst mit dem Kontext multipliziert mit der Zahl der gleichzeitig verbundenen Personen. Ein Modell, das in einem Proof of Concept mit einer Person bequem passt, passt bei dreissig womöglich nicht mehr.

«Wie viel von diesem Modell darf auf langsamem Speicher liegen?» Kommt von den N-Grammen. Es ist die Frage, die ein Angebot über 200'000 Franken VRAM von einem über 40'000 für RAM und SSD trennt — und heute lautet die Antwort zum ersten Mal nicht «nichts».

«Und wofür genau setzen wir das ein?» Das ist keine Architekturfrage, und es ist die wichtigste der vier. Lautet die Antwort «Fragen zu unseren Dokumenten beantworten», sind wir in einem Bereich, in dem ein offenes Modell von vor sechs Monaten die Arbeit auf einer Maschine erledigt, die das Unternehmen kaufen kann. Lautet sie «ein Agent, der Tickets eröffnet, Code schreibt und sich selbst korrigiert», sind wir dort, wo die oben zitierten Benchmarks 74,2 auf der einen und 31,2 auf der anderen Seite sagen. Das sind zwei verschiedene Projekte mit zwei verschiedenen Budgets, und der Unterschied zeigt sich in keiner Rangliste.

Neun von zehn Malen lautet nach diesen vier Fragen die ehrliche Antwort: nicht das neueste Modell, nicht für alles, und nicht jetzt. Aber fast immer gibt es eine kleinere Version derselben Idee — ein Modell eine Generation zurück, für eine einzige Aufgabe, auf Hardware, die in ein Rack passt — die wirklich funktioniert und das Kontrollproblem löst, von dem der Kunde ausgegangen ist. Genau diese vorzuschlagen, statt schlicht «nein, lieber Cloud» oder «ja, kaufen wir einen Cluster» zu sagen, ist die Arbeit, die ich in meine Projekte mitbringe.

Und hier liegt der tiefere Grund, warum sich Zeit dafür lohnt. Die Versionen wechseln alle sechs Wochen: Jede Zahl in diesem Text wird im Januar alt sein, und das ist in Ordnung. Die Konzepte nicht. Die Attention ist von 2017, die Trennung von Rechnen und Speichern ist so alt wie die Informatik, und die Sparsamkeit — zuerst in der Rechnung mit dem MoE, jetzt auch im Zugriff mit den N-Grammen — wird 2028 immer noch die richtige Linse sein, um Modelle zu lesen. Den Releases hinterherzulaufen ist ein Rennen, das Sie verlieren. Die drei oder vier Ideen zu verstehen, die die Releases neu kombinieren, ist eine Investition, die sich bei jedem Gespräch auszahlt.

Denn am Ende kann der Unterschied zwischen Ihnen und dem Kunden nicht sein, dass Sie den Beitrag zuerst gelesen haben. Er muss sein, dass Sie eine Architektur in eine Budgetposition übersetzen können.

Die Fragen, die offen bleiben

Die vier Fragen von oben sind die, die ich zu handhaben weiss. Es gibt vier weitere, die ich heute nicht mit eigenen Zahlen beantworten kann.

Die erste: Was heisst «unterstützt Tool Calling» eigentlich? Jede Modellfamilie hat ihr eigenes Format, jedes Runtime übersetzt es auf seine Art, und die Stelle, an der die Übersetzung bricht, taucht in keinem Benchmark auf.

Die zweite: Ist ein agentischer Harness portabel? Claude Code startet auf einem lokalen Modell, aber wie weit kommt es, bevor langsames Prefill und Wiederholschleifen den Zyklus unbrauchbar machen? Und wie viel von dem, was wir dem Modell zuschreiben, ist in Wahrheit das Verdienst des Harness?

Die dritte: Was machen wir jenseits der Chat Completion damit? Vision, strukturierte Ausgabe, Embeddings, Reranking, Speculative Decoding: Das sind die Teile, die in der Produktion wirklich gebraucht werden, und die Unterstützung der lokalen Runtimes ist lückenhaft.

Die vierte, die unbequemste: Wann lohnt sich Self-Hosting wirklich? Nicht im Prinzip, sondern mit Zahlen: Mengenschwelle, Kosten des Servers, Kosten der Leute, die ihn betreiben, tatsächlicher Wert der Kontrolle. Es ist eine Rechnung, die in den meisten Fällen nicht aufgeht, und das zu sagen ist nützlicher, als einen Cluster zu verkaufen.

Zu diesen vier habe ich vorerst Meinungen. Ich messe sie, bevor ich darüber schreibe.