Qwen3.8-27B als Agent auf dem Mac Studio M1 Ultra

Qwen3.8-27B passt mit 4 Bit in die 64 GiB des Mac Studio und lässt daneben Platz für einen langen Verlauf. Auf dem Mac gibt es dafür sechs Server mit OpenAI-kompatibler Schnittstelle: mlx-lm als Referenz von Apple, die Ableger Rapid-MLX, oMLX, MTPLX und mlx-dspark, und llama.cpp mit Metal. Jede Engine lief mit den Gewichten, für die sie gebaut ist, und mit ihrem Cache so, wie man ihn im Alltag einschaltet.

Gemessen sind vier Dinge. Erstens eine Sitzung: ein Agentenverlauf von 52.000 Token, der Turn um Turn wächst, unterbrochen von einer Nebenfrage, einer zweiten Sitzung und einem Neustart des Servers. Zweitens acht einzelne Agentenschritte von 2.300 bis 98.000 Token, jeder kalt, für das reine Einlese- und Ausgabetempo. Drittens Folgefragen an ein Dokument von 32.000 bis 128.000 Token mit geprüften Antworten. Viertens, ob die Spekulation, mit der vier der Engines werben, die Ausgabe verändert.

Die Agentenverläufe sind aus der Aufzeichnung eines echten Coding-Agenten (mini-swe-agent) geschnitten; derselbe Satz lief schon auf dem HP ZBook Ultra G1a. Alle Zeiten sind auf der Uhr des Messskripts genommen, nicht aus den Angaben der Server. Vor jedem Start prüfte ein Skript, dass kein anderer Server, kein Download und kein Build lief. Werkzeugaufrufe beherrschen alle sechs: jede Engine löste die fünf Werkzeugaufgaben in drei Runden ohne formalen Fehler.

Der Grund liegt im Modell. Seine DeltaNet-Schichten tragen einen Zustand, der den ganzen Verlauf zusammenfasst und sich nicht auf eine frühere Stelle zurückschneiden lässt. Eine Engine kann einen gespeicherten Verlauf deshalb nur wiederverwenden, wenn der neue Prompt ihn genau fortsetzt, oder wenn sie unterwegs Schnappschüsse des Zustands abgelegt hat. Agentenschritte setzen den Verlauf fort; das gelingt allen.

Eine Nebenfrage oder eine zweite Sitzung schiebt einen anderen Verlauf dazwischen. mlx-lm hält nur einen Eintrag dieser Größe und liest danach 4,7 min neu ein. Über einen Neustart retten den Verlauf nur die Engines, die ihn auf die SSD schreiben: Rapid-MLX (1,2 s), oMLX (6,6 s) und MTPLX (5,9 s). llama.cpp hält den Verlauf im Arbeitsspeicher, mlx-dspark legt zwar einen Plattencache an, findet ihn nach dem Neustart aber nicht wieder.

Das Einlesen bestimmt die Wartezeit eines Agenten, sobald der Cache den Verlauf verliert. Die Ausgabe bestimmt die Zeit danach: Ein Schritt mit 1.000 Token Denken und Werkzeugaufruf dauert bei 37,3 Token je Sekunde rund 27 Sekunden, bei 20,2 rund 50. Während der Schritte zog der Chip 95 bis 102 Watt bei 71 bis 74 °C; der GPU-Takt blieb bei allen Engines auf 1.296 MHz.

Bei 32k lösen alle sechs Engines alle 24 Aufgaben aus drei Fassungen des Dokuments. Bei 128k bleibt llama.cpp fehlerfrei, oMLX löst 22 von 24 und schreibt dann nur noch 10,5 Token je Sekunde. MTPLX liest 128k in 19 Minuten ein und scheitert danach an Speicherfehlern: 3 von 24. mlx-dspark lief bis 64k; bei 128k leerte sein Speicherwächter den Cache, und eine Folgefrage brauchte 16 Minuten.

Mit Volltext nachgeprüft weicht MTPLX im Prosa-Prompt ab Zeichen 712 des Denkens ab, in der Agentenaufgabe A03 ab Zeichen 856; dort schreibt es danach eine andere Antwort und ruft die Shell mit anderen Befehlen auf. Das Ergebnis ist nicht falsch, aber nicht das des Modells ohne Entwurf. mlx-dspark schreibt mit Spekulation dieselben Token und hängt nur an der Grenze von 512 oder 1.024 Token noch angenommene Entwurfstoken an. Rapid-MLX, oMLX, llama.cpp und mlx-lm geben in allen Läufen byteweise dieselbe Ausgabe.

oMLX schaltet die Spekulation nur in den Modelleinstellungen, nicht beim Start; dort lief sie in beiden Armen. llama.cpp und mlx-lm haben für dieses Modell keine.

Für OpenCode mit Verläufen bis 52k, so weit gemessen: Rapid-MLX. Es hält den Verlauf über Nebenfragen, eine zweite Sitzung dazwischen und Neustarts, antwortet dabei in höchstens 1,3 Sekunden, gibt mit und ohne Spekulation dieselben Token aus und schreibt bei 13k 31,5 Token je Sekunde. Das Zeitlimit des Clients muss trotzdem den ersten Turn aushalten: Ein neuer Verlauf von 52k braucht auch hier 3,6 min.

Für Fragen an Dokumente über 64k: llama.cpp. Es ist beim Schreiben das langsamste, aber das einzige, das bei 128k fehlerfrei und sofort antwortet. Einen Neustart übersteht sein Cache nicht.

MTPLX schreibt am schnellsten und hält den Verlauf ebenfalls, ändert mit Spekulation aber die Ausgabe, schickt Werkzeugaufrufe in wenigen großen Stücken und stößt ab 52k an seinen Speicherwächter. oMLX hält den Verlauf und reicht bis 98k, bricht einen an der Token-Grenze abgeschnittenen Werkzeugaufruf aber mit einem Fehler ab. mlx-lm ist als Referenz gemessen; für einen Agenten verliert es den Verlauf zu leicht.