Startseite / Artikel / Warum ein 17-GB-Modell, das heruntergeladen wird, nicht bedeutet, dass 17 GB Speicher zum Betrieb benötigt werden

LLM Local AI Mixture of Experts Inference Machine Learning

Warum ein 17-GB-Modell, das heruntergeladen wird, nicht bedeutet, dass 17 GB Speicher zum Betrieb benötigt werden

Erfahren Sie, wie aktive Parameter, Gesamtparameter, das Wachstum des KV-Caches sowie die Rechenaufwand die tatsächlichen Speicher- und Rechenkosten für den lokalen Betrieb eines Sprachmodells bestimmen.

2722 Wörter

Ein neues offenes Modell wird angekündigt, die Schlagzeilen behaupten, es konkurriere mit weitaus größeren Systemen, und eine Zahl zieht alle Blicke auf sich: Die Downloadgröße beträgt nur 17 GB. Das scheint ernsthafte Programmierhilfen für einen gewöhnlichen Arbeitsrechner erreichbar zu machen – bis man eine echte Codebasis oder ein langes Gespräch lädt und der Prozess an Speicherplatz scheitert. Die Dateigröße, die Anzahl der aktiven Parameter sowie der tatsächliche Speicherbedarf eines laufenden Modells sind drei verschiedene Größen. Dieser Artikel erklärt, wie sie miteinander zusammenhängen, damit Sie vor der Planung von Hardware abschätzen können, wie viel es tatsächlich kostet, ein Modell zu betreiben – anhand von Schlagzeilen allein.

Die Anzahl der Parameter ist ein schwächerer Indikator als früher

Beim Vergleich von Sprachmodellen schauen die meisten Menschen zuerst auf die Anzahl der Parameter. Das ist ein vernünftiger Instinkt: Parameter sind die gelernten Gewichte des Netzwerks, und es scheint logisch, dass mehr Parameter ein größeres, intelligenteres und teureres Modell bedeuten.

Moderne Architekturen haben diese Beziehung deutlich lockerer gemacht. Ein früher Wendepunkt war die Forschung von DeepMind zu Chinchilla bezüglich rechenoptimierter Trainingsmethoden. Dabei zeigte sich, dass ein 70-Milliarden-Parameter-Modell, das mit weitaus mehr Daten trainiert wurde, größere Modelle wie das 280-Milliarden-Parameter-Gopher übertreffen konnte, selbst wenn beide eine vergleichbare Menge an Rechenleistung für das Training nutzten.

Die Schlussfolgerung war nicht, dass kleine Modelle gewinnen. Es handelte sich um eine differenziertere und nützlichere Erkenntnis: Die Art und Weise, wie ein Modell seine Parameter nutzt, kann genauso wichtig sein wie ihre Anzahl. Diese Idee wurde zum Kern einer weiteren Architektur, die heute bei Diskussionen über effiziente Modelle eine zentrale Rolle spielt – der Mixture of Experts.

Aktive Parameter gegen Gesamtparameter

Ein Mixture of Experts (MoE)-Modell enthält viele Experten-Subnetzwerke. Anstatt jeden Token durch das gesamte Netzwerk zu leiten, wählt ein kleiner Router für jeden Token einige Experten aus, und nur diese Experten erledigen die Arbeit.

Eine nützliche Analogie ist ein Unternehmen mit 100 Mitarbeitern. Jeder einzelne Kundenauftrag könnte nur fünf von ihnen erfordern, sodass man sagen kann, dass fünf Personen für diesen Auftrag „aktiv“ sind. Das Unternehmen muss jedoch weiterhin alle 100 beschäftigen, unterbringen und bezahlen, denn der nächste Auftrag könnte wieder andere fünf erfordern.

MoE-Modelle verhalten sich genauso:

Die Anzahl der aktiven Parameter gibt ungefähr an, wie viele Parameter an der Erstellung eines Tokens beteiligt sind.
Die Gesamtzahl der Parameter gibt an, wie umfangreich das Modell insgesamt ist.

Der Unterschied zwischen den beiden kann enorm sein. DeepSeek-V3 ist ein bekanntes Beispiel: Insgesamt verfügt es über etwa 671 Milliarden Parameter, wobei pro Token rund 37 Milliarden aktiviert werden. Die Erzeugung eines Tokens ist daher weitaus günstiger als bei einem dichten Modell mit 671 Milliarden Parametern. Das bedeutet jedoch nicht, dass DeepSeek-V3 in allen praktischen Aspekten wie ein Modell mit 37 Milliarden Parametern funktioniert – und genau da gehen viele Vergleiche falsch.

Rechenkosten und Speicherkosten sind getrennte Posten

Aktive Parameter liefern eine gute Orientierung für die Rechenleistung: Sie zeigen an, wie viele Multiplikations- und Akkumulationsoperationen jedes Token erfordert, und somit, wie schnell Tokens auf bestimmter Hardware erzeugt werden können.

Das Speicherbedarf ist ein separater Faktor. Der Inferenzmotor kann die Experten, die für den aktuellen Token nicht ausgewählt wurden, nicht entfernen, da der Router für den nächsten Token einen beliebigen von ihnen auswählen kann. Alle müssen weiterhin erreichbar bleiben, in der Regel in einer GPU oder im integrierten Speicher, da das Herunterladen von Gewichten vom Festplattenspeicher pro Token viel zu langsam wäre.

Daher kann ein Modell zwar günstig berechnet werden, dennoch viel Speicher benötigen. Eine prägnante Formel beschreibt dies:

Die aktiven Parameter zeigen an, wie viel Rechenleistung jeder Token benötigt. Die Gesamtgröße des Modells gibt an, wie viel Speicher verfügbar sein muss.

Die beiden Größen stehen in Zusammenhang, beantworten aber unterschiedliche Fragen und können nicht miteinander vertauscht werden.

Was eine 17 GB große Download-Datei tatsächlich enthält

Deshalb ist die Bezeichnung „ein 17 GB großes KI-Modell“ irreführend. Eine quantisierte Gewichtsdatei kann tatsächlich diese Größe haben. Durch Quantisierung werden die Gewichte in weniger Bits gespeichert – beispielsweise 4 statt 16 Bit – wodurch die Dateigröße um ein Vielfaches reduziert wird, bei nur geringem Qualitätsverlust.

Doch die Datei auf Ihrer SSD ist nur ein Bestandteil dessen, was der laufende Prozess benötigt. Darüber hinaus sind folgende Ressourcen erforderlich:

die Gewichte, sobald sie in den Speicher geladen wurden,
der eigene Overhead des Inferenzprozesses,
temporäre Puffer, die während der Berechnung verwendet werden,
der Kontext, der im KV-Cache gespeichert wird,
sowie alles, was das Betriebssystem und andere Software bereits nutzen.

Eine 17 GB große Datei bedeutet daher nicht, dass ein Rechner mit 17 GB freiem Speicher das Modell problemlos ausführen kann – oder überhaupt noch, sobald der Kontext wächst.

Community-Messungen zu Qwen3.8-27B machen diesen Punkt konkret. Eine quantisierte Version mit etwa 17 GB benötigt erheblich mehr Speicher, sobald ein langer Kontext geladen wird. Bei der nativen Kontextlänge des Modells von 262.144 Token wird allein der KV-Cache sehr groß. Um zu verstehen, warum das so ist, muss man sich ansehen, wie ein Modell ein Gespräch speichert.

Das Gespräch selbst verbraucht Speicher

Ein Transformer liest Ihre Anfrage nicht einmal und wirft sie anschließend weg. Beim Erzeugen jedes neuen Tokens bezieht er sich auf alle früheren Token im Kontext. Die Neuberechnung der internen Repräsentation des gesamten Kontexts für jedes neue Token wäre äußerst langsam, weshalb Inferenz-Engine stattdessen die Zwischenergebnisse speichern.

Der Store ist der KV-Cache, abgekürzt für Key/Value-Cache. Für jeden Token im Kontext speichert jede Aufmerksamkeitsschicht einen Schlüsselvektor und einen Wertvektor. Der Cache wächst daher annähernd linear mit der Länge des Kontexts: Ein Modell, das für ein kurzes Gespräch problemlos ausreicht, kann erheblich schwerer werden, wenn man ihm Zehntausende oder Hunderttausende von Tokens zur Verarbeitung gibt – beispielsweise einen ganzen Repository.

Laut der Modellbeschreibung von Qwen3.8-27B auf Hugging Face unterstützt das Modell einen nativen Kontext von 262.144 Tokens. Es verwendet ein hybrides Design, bei dem nur einige Schichten herkömmliche Aufmerksamkeitsmechanismen nutzen, was es überhaupt ermöglicht, ein so langes Fenster praktisch zu verwenden.

Eine Gemeinschaftsanalyse der Architektur schätzt für die Schichten, die weiterhin einen traditionellen Cache verwenden, etwa 64 KB an FP16-KV-Cache-Daten pro Token. Multipliziert man das mit 262.144 Tokens, erhält man rund 16,8 GB an KV-Cache – noch bevor andere Aspekte berücksichtigt werden. Ein grober Speicherbedarf für eine Sitzung mit vollständigem Kontext sieht dann so aus:

Modellgewichte: etwa 17 GB
KV-Cache bei vollständigem Kontext: etwa 17 GB
Ausführungskosten und Puffer: zusätzlicher Bedarf

Das Modell ist niemals auf ein Programm von 17 GB geschrumpft. Sie haben 17 GB an quantisierten Gewichten heruntergeladen, wobei die tatsächliche Rechenlast etwa doppelt so hoch oder sogar noch höher sein kann. So wird auch klar, warum die Kontextlänge der Hebel ist, den man ansetzen muss, wenn der Speicher knapp ist: Die Halbierung des Kontexts verringert in etwa auch die Größe des Caches, und viele Laufzeiten können den KV-Cache selbst quantisieren, um ihn weiter zu verkleinern – mit einem gewissen Verlust an Genauigkeit. Solche Angaben aus der Community sind Schätzungen; überprüfen Sie sie im Vergleich zum vom eigenen Laufzeitumfeld gemeldeten Speicherverbrauch.

Wie hybride Aufmerksamkeit lange Kontexte beherrschbar hält

Dort wird die Architektur interessant. In einem herkömmlichen Transformer behält jede Aufmerksamkeitsschicht ihre eigenen KV-Einträge, wodurch der Cache sowohl mit der Anzahl der Schichten als auch mit der Anzahl der Token wächst.

Laut veröffentlichten Analysen zu seiner Architektur verfolgt Qwen3.8-27B einen hybriden Ansatz. Von seinen 64 Schichten verwenden nur eine relativ geringe Anzahl die vollständige Aufmerksamkeit, während die meisten lineare Aufmerksamkeit nutzen. Die Schichten mit linearer Aufmerksamkeit fassen die Vergangenheit in einen Zustand festen Formats zusammen, anstatt Schlüssel und Werte für jeden Token zu speichern, wodurch sie nicht zum wachsenden Cache beitragen. Nur die Schichten mit vollständiger Aufmerksamkeit verursachen Kosten pro Token, weshalb der oben angegebene Wert pro Token so niedrig ist.

Eine solche Technik macht sehr lange Kontextfenster überhaupt erst praktikabel. Ohne sie würde der für ein Viertel Million Tokens benötigte Speicher schnell unpraktisch werden – außer auf Rechenzentrumshardware.

Wenn also ein Modell ein riesiges Kontextfenster bewirbt, stellen Sie eine Nachfrage: Was tut die Architektur, um diesen Kontext bezahlbar zu machen? Allein die Länge des Kontexts sagt dazu nichts aus.

Ein Sieg in einem Benchmark ist kein Gesamtsieg

Überschriften haben noch eine weitere Angewohnheit: Ein Modell „schlägt Claude“ oder „schlägt GPT“ in einem bestimmten Benchmark, und es wird geschlussfolgert, dass es insgesamt besser ist. Benchmarks messen spezifische Aufgaben unter bestimmten Bedingungen, und eine einzige Bewertung sagt wenig über alles andere aus.

Qwen3.8-27B veranschaulicht dies gut. Seine veröffentlichten Ergebnisse zeigen starke Werte im Bereich Programmierung:

Terminal-Bench 2.1, der agierendes Arbeiten in einer Terminalumgebung prüft: 73,0
SWE-bench Pro, der das Beheben tatsächlicher Probleme in Repositorien testet: 61,7
GPQA Diamond, eine Sammlung wissenschaftlicher Fragen auf Graduiertenniveau: 89,2

In der Vergleichstabelle derselben Modellkarte, wo die Werte von Opus 4.6 Max angegeben sind, ist das Bild gemischt. Auf Terminal-Bench 2.1 liegt Qwen hinter den 78,2 Punkten von Opus 4.6 Max. Auf SWE-bench Pro liegt sein Wert von 61,7 über den 53,4 Punkten von Opus. Auf GPQA Diamond liegt sein Wert von 89,2 unter den 91,3 Punkten.

Welches Modell ist besser? Das hängt von der Aufgabe ab. Agentenbasierte Terminalarbeiten, Fehlerbehebung auf Repository-Ebene sowie wissenschaftliche Fragen auf Graduierten-Niveau erfordern unterschiedliche Fähigkeiten, genauso wie langfristige Agentenaufgaben. Jeder Benchmark gibt nur Aufschluss über eine bestimmte Fähigkeit und nicht über eine universelle Rangliste der Intelligenz.

Auch die Methodik spielt eine wichtige Rolle. Das Bewertungstool, die Strategie zur Anregung des Modells, die verfügbaren Werkzeuge, die Benotungsmethode sowie die Konfiguration des Modells können alle die Ergebnisse beeinflussen, und Anbieter führen ihre Konkurrenten nicht immer unter identischen Bedingungen durch. Eine Aussage wie „Modell X ist besser als Modell Y“ lässt den wichtigen Teil aus. Die genaue Formulierung lautet eher so:

Unter diesen Bedingungen erzielte Modell X in dieser Bewertung eine höhere Punktzahl als Modell Y.

Das ist weniger spektakulär, aber weitaus nützlicher.

Das Nachdenken ist ein verborgener Kostenvielfacher

Auch wenn Parameter und Speicher bereits verstanden sind, kann eine weitere Variable stillschweigend den Betriebskosten eines Modells zugrunde liegen: wie lange es vor der Antwort nachdenkt.

Modellierungen, die auf logischem Denken basieren, bieten zunehmend eine Einstellung dafür an. Qwen3.8 unterstützt einen Parameter reasoning_effort mit Ebenen wie low, medium und xhigh, wobei xhigh als Standardwert gilt. In der Dokumentation werden diese Ebenen ausdrücklich als Steuerungselemente für Tiefe und Kosten des logischen Denkens beschrieben.

Der Kompromiss ist einfach zu verstehen: Mehr logisches Denken kann bei schwierigen Problemen helfen, doch jeder Schritt dieses Denkprozesses erzeugt Token – was zu mehr Rechenleistung, höherer Latenz sowie bei langen Denkketten auch zu einem größeren KV-Cache führt. Zwei Personen, die dasselbe Modell verwenden, können daher allein aufgrund dieser einen Einstellung völlig unterschiedliche Kosten erleben.

Dies ist besonders relevant für Koding-Agenten, die Aufgaben von sehr unterschiedlicher Schwierigkeit bearbeiten. Vergleichen Sie einen Antrag zur Umbenennung einer Variablen mit einem Antrag, ein unbekanntes Repository zu durchforsten, einen architektonischen Fehler zu finden, sechs Dateien zu ändern, die Tests auszuführen, die Fehler zu diagnostizieren und einen Patch zu erstellen. Der erste erfordert bei weitem nicht so viel Rechenkapazität wie der zweite. Das Ausführen maximaler Rechenleistung für jeden Antrag ist wie das Einbeziehen eines erfahrenen Ingenieurs in eine Besprechung über die Beschriftung einer Schaltfläche: Es funktioniert zwar, ist aber eine schlechte Nutzung der Ressourcen.

Es gibt eine Einschränkung, die bereits in Qwens eigener Dokumentation erwähnt wird. Die Verringerung der Rechenleistung kann zwar die Geschwindigkeit pro Schritt erhöhen, führt aber bei mehrstufigen Aufgaben zu mehr Wiederholungen oder Fehlern, wodurch die Ersparnisse wieder aufgehoben werden können. Der praktische Ansatz besteht darin, die Gesamtkosten einer Aufgabe zu messen und nicht nur die Latenz pro Schritt, sowie einfache und schwierige Aufgaben bei vorhandener Möglichkeit in unterschiedliche Einstellungen zu leiten. Es gibt keine einzige Einstellung, die für alles geeignet ist.

Warum effiziente aktive Rechenleistung weiterhin von großer Bedeutung ist

Trotz all dieser Einschränkungen könnte man leicht zu dem Schluss kommen, dass die Geschichte von leistungsstarken kleinen lokalen Modellen nur Marketing ist. Das ist nicht der Fall. Der Fortschritt ist real: Modelle mit einem bescheidenen Budget an aktiver Rechenleistung können heute ernsthafte Arbeiten im Bereich der Softwareentwicklung bewältigen, die noch vor ein paar Jahren nur sehr schwer lokal ausgeführt werden konnten.

Die einzige Korrektur, die notwendig ist, besteht darin, dass effiziente Berechnungen nicht automatisch eine geringe Speichernutzung bedeuten.

Der Unterschied ist bei der Skala von Rechenzentren umso wichtiger. Ein Anbieter, der Tausende von Nutzern bedient, lädt die Gewichte einmal hoch und teilt sie allen Anfragen mit. Der KV-Cache hingegen gehört jeder einzelnen Konversation. Wenn die Speicheranforderungen pro aktiver Konversation reduziert werden, passen mehr gleichzeitige Nutzer auf denselben Hardware-Setup, was die Kosten für den Betrieb des Modells direkt senkt.

So betrachtet werden architektonische Details, die wie obskure Forschungstricks erscheinen – wie hybride Aufmerksamkeitsmechanismen oder Kompression des KV-Caches – zu wichtigen wirtschaftlichen Faktoren. Ein Modell muss nicht überall klein sein; es muss dort effizient sein, wo die Infrastruktur am meisten unter Druck steht.

Wann ein 17-GB-Modell tatsächlich ein großer Vorteil ist

Auch gibt es eine sehr positive Seite. Viele reale Aufgaben erfordern einen kurzen Kontext:

eine einzige Datei,
ein fokussiertes Programmierproblem,
ein kleines Projekt,
eine gewöhnliche Chat-Unterhaltung.

In solchen Fällen kann ein gut quantisiertes Modell dieser Klasse tatsächlich beeindruckend sein. Man benötigt keinen großen Cloud-Server, um es auszuprobieren. Man kann ein leistungsstarkes Modell auf Consumer-Hardware ausführen, die Daten auf dem eigenen Gerät speichern und so Gebühren pro Token für jedes Experiment vermeiden. Ein praktisches Beispiel für diesen Workflow finden Sie unter der Erstellung eines lokalen Angry Birds-Klons mit Qwen3.8-27B und Pi.

Dadurch wird die Zahl der Menschen erweitert, die mit ernsthafter KI experimentieren können – was vermutlich wichtiger ist als die Tatsache, dass ein Benchmark-Ergebnis drei Punkte höher ist als ein anderes.

Vier Fragen, die man statt „Wie viele Parameter?“ stellen sollte

Nächstes Mal, wenn eine Schlagzeile auf eine geringe Anzahl an Parametern oder eine kleine Download-Größe hinweist, gehen Sie diese vier Fragen durch.

Wie viele Parameter sind aktiv?

Dies gibt Aufschluss über die Rechenleistung pro Token und somit ungefähr darüber, wie schnell das Modell auf Ihrer Hardware generieren kann.

Wie viele Parameter gibt es insgesamt?

Dies zeigt die Gesamtauswirkung auf die Ressourcen an und ist der Hauptfaktor dafür, wie viel Speicher die Gewichte benötigen.

Wie groß wird der KV-Cache?

Dies hängt von der Architektur sowie von der Länge des Kontexts ab, den Sie tatsächlich verwenden möchten, und wird bei langen Kontexten zum dominierenden Faktor.

Wie lange überlegt das Modell, bevor es antwortet?

Dies beeinflusst die Latenz, den Tokenverbrauch und die Kosten und kann je nach Aufgabe angepasst werden.

Zusammen verraten Ihnen diese vier Antworten weitaus mehr als die Größe einer Download-Datei jemals könnte.

Modelle sind effizienter geworden, nicht unbedingt kleiner

Der allgemeine Trend zeigt echte Effizienzsteigerungen in der gesamten Architektur: bessere Trainingsstrategien und Skalierung der Daten, verbesserte Routenfindung durch Experten, bessere Quantisierungsverfahren, effizientere Aufmerksamkeitsarchitekturen sowie ein Verarbeitungsmechanismus, der zur Ausführung konfiguriert werden kann.

Nichts davon macht effiziente Berechnungen gleichbedeutend mit geringem Speicherverbrauch:

Ein MoE-Modell kann pro Token nur einen Bruchteil seiner Parameter aktivieren, enthält aber dennoch ein sehr großes Netzwerk.
Ein quantisiertes Modell benötigt nur wenig Speicherplatz auf der Festplatte, verbraucht aber zur Ausführung deutlich mehr Arbeitsspeicher.
Ein langes Kontextfenster kann dazu führen, dass allein das Gespräch Gigabyte an Speicher verbraucht.
Eine höhere Rechenleistungseinstellung kann denselben Anfrageauftrag erheblich rechenintensiver machen.

Daher ist die bessere Frage nicht, wie viele Parameter ein Modell hat. Es geht eher darum:

Wie viel Speicher und Rechenleistung benötigt diese spezifische Aufgabe, von der Laden des Modells bis zur Erzeugung des endgültigen Tokens?

Haupterkenntnisse

Die Download-Größe eines Modells umfasst nur seine Gewichte; der KV-Cache, die Laufzeitkosten und Puffer kommen zusätzlich hinzu und können bei langen Kontexten die tatsächlichen Anforderungen verdoppeln.
Aktive Parameter beschreiben die Rechenleistung pro Token, während die Gesamtzahl der Parameter bestimmt, wie viel Speicher verfügbar bleiben muss.
Die Größe des KV-Caches skaliert mit der Länge des Kontexts und hängt stark von der Architektur ab, weshalb hybride Aufmerksamkeitsdesigns für lange Kontextfenster wichtig sind.
Benchmark-Ergebnisse sind task-spezifisch und methodenabhängig; man sollte sie als „besser in dieser Bewertung“ und nicht als „allgemein besser“ verstehen.

Der Aufwand für das Reasoning ist ein echter Kostentreiber, doch man sollte die Gesamtkosten der Aufgabe messen, da geringerer Aufwand zu erneuten Versuchen führen kann, die die Ersparnisse wieder aufheben.

Wenn eine Schlagzeile ein winziges Modell verspricht, das ein großes Modell übertrifft, sollte man vor dem Glauben daran oder dem Ablehnen des Versprechens den Benchmark, die Einrichtung, die aktiven und gesamten Parameter, die Quantisierung, die Kontextlänge sowie das Reasoning-Budget überprüfen.