Ein Modell, jede Karte: wie ein 27B auf 8 GB läuft

Ein Freund stellte die Frage, die entscheidet, ob das alles funktioniert: „Ich habe eine 3060 mit 12 GB. Bin ich raus?"

Vor sechs Wochen war die ehrliche Antwort ja. Unser Katalog hatte zwei winzige Modelle, und eine Modell-ID und eine Quantisierung waren dasselbe — entweder passte der eine Build, den wir auslieferten, oder Sie bedienten gar nichts. Heute bedient seine Karte Qwen3.8 27B, und das hier musste sich dafür ändern.

Ein Modell ist keine Datei

Die Lösung war eine Unterscheidung, die wir vom ersten Tag an hätten treffen sollen. Ein Modell ist, was ein Kunde anfragt: qwen3.8-27b. Ein Build ist ein konkretes Artefakt — eine Quantisierung, eine Engine, eine exakte Datei aus einer exakten Upstream-Revision, mit veröffentlichtem SHA-256.

Ein Modell, mehrere Builds. Die Anfrage des Kunden ändert sich nie; der Host wählt den Build, den seine Karte tatsächlich ausführen kann:

Karte	Build	Auf der Platte
24 GB	Q5_K_M — Referenz	18,4 GB
20 GB	Q4_K_M — Referenz	15,3 GB
16 GB	Q3_K_XL — ausgewogen	12,2 GB
12 GB	Q2_K_XL — kompakt	9,2 GB
9 GB	IQ2_XXS — kompakt	6,8 GB

Wir benennen den Kompromiss, statt ihn zu verstecken. Ein 27B mit 2 Bit ist ein echtes Modell mit echten Qualitätskosten — oft immer noch besser als ein 4B mit 4 Bit, aber nicht immer, und nicht für Code. Das „kompakt" zu nennen und zu sagen warum, ist nützlicher, als es stillschweigend zu servieren.

Das Flag-Paar, das unseren Kontext verdoppelte

Beim Dimensionieren dieser Builds haben wir etwas Peinliches gelernt. Unser erster Versuch lud Qwen3.8 Q4_K_M auf eine RX 7900 XTX mit 24 GB, mit 16K Kontext und vier Batching-Slots. Die Karte hatte 345 MiB frei und verbrachte den Lauf mit Thrashing.

Die Lösung kam aus einer Konfiguration, die genau dieses Modell täglich auf genau dieser Karte bediente: --flash-attn on mit --cache-type-k q4_1 --cache-type-v q4_1. Ein quantisierter KV-Cache ist ungefähr ein Viertel so groß wie der Standard. Gleiche Karte, gleiches Modell, danach:

before:  16K context  →    345 MiB free   (thrashing)
after:   32K context  →  6,812 MiB free

Doppelter Kontext und sechs Gigabyte Luft, aus einem Flag-Paar. Es ist jetzt die Baseline, mit der jeder GGUF-Build startet.

Die Schätzung ist nicht das Versprechen

Jeder Build trägt eine VRAM-Schätzung: Gewichte, plus KV-Cache für seinen Kontext und seine Slots, plus Reserve. Diese Schätzung entscheidet, was sich herunterzuladen lohnt — sie existiert, damit niemand 15 GB zieht, um dann festzustellen, dass es nicht passt.

Sie ist nicht das, was Kunden angezeigt wird. Ein Build wird auf einer Maschine erst beanspruchbar, nachdem diese Maschine ihn geladen und gebenchmarkt hat. Schätzungen steuern Downloads; Messungen entscheiden das Routing. Wenn Ihr Dashboard sagt, Ihre Karte schafft 37 Token pro Sekunde, dann kam diese Zahl von Ihrer Karte, nicht aus einer Tabelle.

Was Ihre Karte bedienen kann

Ihre Karte	Modelle
6–8 GB	Gemma 4 E4B, die kleinen Qwen2.5-Modelle
10 GB	+ Gemma 4 12B
12 GB	+ Qwen3.8 27B (Q2_K_XL)
16 GB	+ gpt-oss 20B, Qwen3.8 mit Q3_K_XL
24 GB	alles, inkl. Gemma 4 26B-A4B und Qwen3.8 mit Q4/Q5

Der Katalog hat die vollständige Liste mit Preisen. Oder installieren Sie den Agenten und fragen Sie Ihre eigene Maschine:

$ mahout models
this machine: 24 GiB VRAM detected

* qwen3.8-27b  (Qwen3.8 27B Instruct)
      > UD-Q5_K_M      18.4 GiB  needs ~23 GiB   32K ctx  reference   <- this machine

Also: 12 GB ist nicht raus. Es reicht, seit dieser Woche, um das Flaggschiff zu bedienen.

Zum Katalog · Welches Modell passt auf meine GPU? · mahout installieren