Qwen3.8-Flash-Next auf einem MacBook mit 64 GB: Dateien, Quants und llama.cpp-Flags

Die Dateien von Qwen3.8-Flash-Next kommen zusammen auf 88 Gigabyte, und das Modell läuft gut auf einem Verbund aus drei RTX 3090. Nach Tagen regelmäßiger Nutzung ist der Eindruck stabil: Es denkt weniger als Qwen3.8-27B, bewältigt aber fast jede Aufgabe. Weniger Geschwafel, weniger Schleifen, mehr echte Antworten. Für ein Modell mit 6 Milliarden aktiven Parametern ist diese Mischung aus Kürze und Kompetenz ungewöhnlich.

Gaming-GPUs im Rack sind das eine, doch die Architekturänderung hinter diesem Modell wirft eine andere Frage auf: Läuft es auf einem MacBook? Gemeint ist ein einzelner Laptop mit 64 GB Unified Memory – ein Gerät, das man ins Flugzeug mitnimmt und dem man normalerweise kein Modell mit 180 Milliarden Parametern zutraut.

Zwei Testtage auf einem M4 Max und einem M1 Max, beide mit 64 GB, lieferten die Antwort: ja. Rechnen Sie mit 25 bis 30 Tokens pro Sekunde beim Decoding und rund 400 Tokens pro Sekunde beim Prefill – ganz ohne CPU-Offload.

„Ohne Offload“ ist der entscheidende Punkt. Ein Server mit drei 3090 muss Experten durch den System-RAM schleusen, der Laptop lädt das Modell einfach und legt los. Der M1 Max ist ein sechs Jahre alter Chip aus der ersten Apple-Silicon-Generation und schafft trotzdem etwa zwei Drittel der Geschwindigkeit des M4 Max. Das ist absolut brauchbar.

Im Folgenden geht es um die Einrichtung.

Welche Datei: nicht die bekannte

Hier lauert eine Falle. Die beliebteste Quantisierung dieses Modells ist das GGUF von Unsloth. Für einen Linux-Server ist es die richtige Datei, für einen Mac die falsche – das README von Unsloth räumt das selbst ein und verlangt unter macOS 75 bis 96 GB Speicher.

Ursache ist eine Eigenheit, wie Apples Grafiktreiber mit Speicher umgeht. Es lohnt sich, sie zu verstehen, denn sie erklärt alles Weitere.

llama.cpp lädt Modelle per Memory-Mapping der Datei. Das Betriebssystem liefert einen Zeiger, Seiten werden bei Bedarf gelesen. Unter Linux ist das vollständig lazy: Seiten, die man anfasst, werden geladen, die übrigen können auf der Platte bleiben oder verdrängt werden, wenn der Platz anderweitig gebraucht wird.

Metal, Apples Grafik-API, macht es komplizierter. Übergibt llama.cpp einen gemappten Shard an Metal, wird der gesamte Shard „wired“. Er wird also im RAM festgenagelt, ist garantiert vorhanden und kann nicht verdrängt werden. In den Shards von Unsloth liegen Modellgewichte und N-Gramm-Tabelle gemischt in denselben Dateien. Fordert Metal also einen einzigen Gewichtstensor an, pinnt es gleich Gigabytes an Tabelle mit. Auf einem Mac mit 64 GB folgt sofort ein Out-of-Memory-Fehler, noch bevor ein einziges Token entstanden ist.

Zur Erinnerung, was diese N-Gramm-Tabelle ist: ein 29 GB großer „zweiter Aktenschrank“, der überhaupt nicht rechnet, sondern nur nachgeschlagen wird – etwa 2,7 Kilobyte pro erzeugtem Token. Bei 30 Tokens pro Sekunde sind das rund 3 MB/s an Lesezugriffen, eine Last, die ein USB-Stick von 2012 bewältigen würde. Die Tabelle war nie für schnellen Speicher gedacht. Sie muss nur erreichbar sein.

Das Layout von Unsloth zwingt sie versehentlich in den schnellen Speicher. Unter Linux lässt sich die Platzierung pro Tensor überschreiben, Metal bietet diese Kontrolle nicht. Die Lösung muss daher strukturell sein: Die Tabelle kommt in einen Shard ohne GPU-Tensoren, damit nichts ihr Pinnen erzwingt.

Genau das machen die AtomicChat-M64-Builds. Jedes ihrer Quants ist so neu gepackt, dass Shard 2 nur die N-Gramm-Tabelle enthält. Die Tabelle wird seitenweise über den OS-Cache von der SSD gestreamt, wie es die Architektur vorsieht, und nur die echten Rechengewichte werden wired.

Das erklärt auch das Label „M64“. Es bezeichnet eine Layout-Familie, die von Macs mit 64 GB inspiriert ist – ein Repack mit getrennten Shards – und verspricht keine Größe. Alle drei Builds tragen das Suffix, auch das 110-GB-Build für Rechner mit 128 GB. Ob ein Build auf Ihren Rechner passt, entscheidet die Zahl der Bits pro Gewicht, nicht das Suffix.

Auch die Qualität spricht für sie. Der Ersteller ging von den BF16-Originalen aus, nutzte seine eigene veröffentlichte Importance-Matrix und maß dann jedes Build an den echten Ausgaben des Referenzmodells. Die rohen KLD-Logs und Referenz-Logits sind öffentlich – mehr Transparenz, als die meisten Anbieter bieten.

Welches Quant: 3.84 oder 4.27?

Auf einem Mac mit 64 GB kommen zwei Builds in Frage. Beide liefen jeweils ganze Tage als Hauptmodell. Gemessen auf dem M4 Max mit 64 GB:

| Build                     | Decode  | Prefill | Max context | Resident RAM |
|---------------------------|---------|---------|-------------|--------------|
| AD-3.84bpw-IQ4_XS-M64     | 28-32/s | ~400/s  | 220,000     | 45.8 GB      |
| AD-4.27bpw-Q4_K_M-M64     | ~25/s   | ~350/s  | 144,000     | 54.5 GB      |

Der Kompromiss ist ungewöhnlich klar. Das 4.27 liefert deutlich bessere Qualität, seine Abweichung vom Modell in voller Präzision ist weniger als halb so groß wie die des 3.84. Dafür kostet es Geschwindigkeit und 8,7 GB wertvollen residenten Speicher, weshalb sein Kontext bei 144K statt 220K endet.

Für den Alltag ist das 3.84 die bessere Wahl, aus einem Grund: Kontext. Ein Fenster von 220.000 Tokens bei 30 Tokens pro Sekunde ist ein angenehmerer Begleiter als 144.000 Tokens bei 25. Ganze Codebasen, komplette Notizsammlungen und vollständige Projekthistorien zu laden – da spürt man die Fenstergröße den ganzen Tag, während der Qualitätsunterschied nur in Grenzfällen auftaucht, die einmal pro Woche vorkommen.

Entscheiden Sie nach Workload. Wenn Sie ständig lange Dokumente einspeisen, nehmen Sie das 3.84. Wenn Sie präzises Reasoning auf kürzeren Eingaben betreiben und der Qualitätsunterschied stört, nehmen Sie das 4.27. Es passt in 64 GB, aber der Mac wird damit zur reinen Ein-Modell-Maschine.

Die Namen lügen. Gut, aber sie lügen.

Dieser Teil sorgte auf Reddit für Aufregung, deshalb hier die klare Fassung: Weder „IQ4_XS“ noch „Q4_K_M“ in diesen Dateinamen beschreibt, was drinsteckt.

Die AtomicChat-Builds sind gemischte Rezepte. Verschiedene Teile des Modells bekommen unterschiedliche Quantisierungstypen, und der Dateiname nennt nur den Standardtyp, der den durchschnittlichen Bits pro Gewicht am nächsten kommt – die Model Card sagt das offen. Das steckt tatsächlich in jedem Build.

AD-3.84bpw-IQ4_XS-M64

| AD-3.84bpw-IQ4_XS-M64  | Real type     | Share | Why                     |
|------------------------|---------------|-------|-------------------------|
| n-gram table           | ~6-bit        | 46%   | memorized hints, cheap  |
| MoE expert body        | IQ1_M (1.75b) | ~40%  | 512 experts, 2% active  |
| dense layers, heads    | Q6_K/Q8_0     | ~14%  | the parts that think    |

AD-4.27bpw-Q4_K_M-M64

| AD-4.27bpw-Q4_K_M-M64  | Real type      | Share | bpw contribution |
|------------------------|----------------|-------|------------------|
| n-gram table           | Q5_1           | 41%   | 1.74             |
| ffn_gate/up experts    | IQ2_S (IQ3_S*) | 29%   | 1.24             |
| ffn_down experts       | IQ4_NL         | 24%   | 1.03             |
| everything else        | Q8_0           | 5%    | 0.23             |

Zusätzlich bekommen die Schichten 0 bis 3 und 40 bis 47 das präzisere IQ3_S. Die Statistik der Importance-Matrix zeigte, dass sich die Aktivierungsenergie in den letzten Schichten ballt, und eine gleichmäßige Bitverteilung würde Bits an die Schichten 4 bis 39 verschwenden.

Ist das Schummeln? Die Reddit-Kommentatoren sagten ja. Die Zahlen sprechen dagegen, denn sie zeigen ein kalibriertes Rezept, das genau tut, wofür es gebaut wurde. Verglichen mit dem vollen BF16-Modell wählt das 4.27-Build in 89,5 % der Fälle dasselbe Top-Token, und seine Perplexität liegt nur 2,6 % höher (Verhältnis 1,026). Bits wurden nicht weggeworfen, sondern umverteilt. Einen Experten, den ein Token in etwa 2 % der Fälle berührt, kann man stark komprimieren, während die dichten Schichten, durch die jedes Token läuft, groß bleiben. Die Architektur selbst setzt auf dieselbe Wette – hier wird sie eine Ebene tiefer angewandt, auf die Quantisierung.

Der Befehl

Zuerst llama.cpp aktualisieren und neu bauen. Die Unterstützung für die Architektur qwen4exp ist am 27. August in Mainline gelandet, und es tut sich viel:

cd ~/github_repos/llama.cpp
git pull
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j

Danach die Speichergrenze für die GPU anheben. macOS begrenzt sie auf einem 64-GB-Rechner auf etwa 48 GB, und die Einstellung wird bei jedem Neustart zurückgesetzt:

sudo sysctl iogpu.wired_limit_mb=57344

Dann den Server starten:

llama-server \
  -m /Users/andrewzhu/ai_models/Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64/Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64-00001-of-00028.gguf \
  --alias Qwen3.8-Flash-Next \
  --jinja \
  -ngl 99 \
  -c 168000 \
  -fit off \
  --host 0.0.0.0 --port 8083 \
  --metrics \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --reasoning-format none \
  --parallel 1

Vier Details in diesem Befehl sind wichtiger, als sie aussehen.

-fit off ist Pflicht. Der automatische Speicher-Fitter von llama.cpp schätzt diese Architektur falsch ein und kann nicht allozieren. Ohne das Flag stirbt der Server beim Start auf einem Rechner mit reichlich Speicher, und der Fehler sieht genau aus wie „zu wenig RAM“ – was Leute auf eine frustrierende Suche schickt. Auf den Linux-Rigs war das Flag nicht nötig, auf dem Mac schon.

Es gibt kein -ot-Override. Ein Linux-Server muss die N-Gramm-Tabelle an die CPU binden, per Regex -ot '^per_layer_token_embd\.weight$=CPU'. Der Mac kann das weglassen. Mit dem Split-Shard-Layout landet die Tabelle von selbst beim Host, weil nichts in ihrem Shard Metal zum Pinnen veranlasst. Das Shard-Design löst bereits das Problem, das der Regex gelöst hat.

Auch ein --load-mode-Flag fehlt, es bleibt also beim Standard-mmap. Auf einem Linux-Rechner mit 128 GB könnte man mmap abschalten und alles einmal einlesen. Auf dem Mac ist mmap genau die gewünschte Funktion. Damit kann das OS die 39-GB-Tabelle von der SSD ein- und auslagern, während die Tokens sie verbrauchen. Schaltet man es ab, würde das System versuchen, alle 85 GB resident zu machen – und der Laptop hat nur 64.

Schließlich fehlt -ncmoe. Ein Setup mit einer einzelnen 3090 braucht rund 43 GB Experten, die im System-RAM geparkt sind. Auf dem Mac passt der gesamte speicherresidente Teil, 45,8 GB, unter das Wired-Limit von 56 GB, also muss nichts ausgelagert werden. Unified Memory fasst einfach alles. Es ist die erste Maschine, auf der die Antwort auf „Was kommt wohin?“ lautet: „Alles, was zählt, dorthin, wo es zählt, und zwar gleichzeitig.“

Der alte Laptop schafft es auch

Dasselbe Setup funktioniert auch auf einem M1 Max mit 64 GB. Das war Apple Silicons erster ernsthafter Vorstoß, vor sechs Jahren erschienen, als 64 GB im Laptop noch Datenblatt-Angeberei waren und keine Voraussetzung für Inferenz.

Er erreicht etwa zwei Drittel der Geschwindigkeit des M4 Max – mit demselben Modell, derselben Datei und denselben Flags. Eine praktikable Aufteilung: die tägliche Arbeit auf den M1 Max verlagern und dem M4 Max eine einzige Aufgabe geben – dieses Modell, immer geladen, das am Nachbartisch mit 30 Tokens pro Sekunde antwortet.

Zwei Einschränkungen gibt es, und die sollte man nicht schönreden.

Die Maschine ist belegt. Solange das Modell geladen ist, bleibt der Speicherdruck hoch, also Browser-Tabs und Chat-Apps schließen, denn dieser Mac macht jetzt nur noch eins. Genau deshalb lohnen sich zwei.

Die SSD arbeitet. Die Tabelle wird ständig gestreamt. Die Bandbreite ist gering, verursacht über Monate aber echten Verschleiß, und bei langen Sessions drehen die Lüfter auf. Die Modelldateien auf ein externes USB4-NVMe-Gehäuse zu legen, ist eine freundliche Geste gegenüber dem internen Laufwerk.

Treten Sie aber einen Schritt zurück. Ein Laptop, gekauft zum Programmieren und Videoschnitt, betreibt jetzt ein Modell, das sich mit Frontier-KI messen kann. Das Modell hat 180 Milliarden Parameter und lebt auf Hardware, deren Kühlung nie für Tensor-Lasten ausgelegt wurde. Kein Rechenzentrum, kein Cluster, keine API-Rechnung. Die Architektur kam zur Hardware, nicht umgekehrt.

Das ist die eigentliche Geschichte von Qwen3.8-Flash-Next. Große Modelle sind nicht kleiner geworden. Kluge Modelle sind willkommen geworden.