Messung · 18. Oktober 2026 · je Stand zweimal 8 Längen

Qwen3.8-Flash-Next mit sushi auf dem Mac Studio M1 Ultra

sushi 1.2.1 · sushi 1.2.4 · Fork cead269c auf Mac Studio M1 Ultra

Autoren

Dipl.-Ing. Sören GebbertInstitut für holistische Technologieforschung GmbH Claude Code Opus 5.5Anthropic

Maschine

Mac Studio M1 Ultra

SoC: Apple M1 Ultra, 20 CPU-Kerne, 64 GPU-Kerne
Speicher: 64 GiB Unified Memory, davon bis 58 GiB für die GPU (iogpu.wired_limit_mb)
System: macOS 26.2, Netzbetrieb
Gewichte: beamster/Qwen3.8-Flash-Next-Sushi-2.6bpw

Drei Stände von sushi

Zwei Releases und ein Fork

1.2.1: Release, SHA-256 787ceffca035
1.2.4: Release, SHA-256 4de05a815b52
Fork: 1.2.4 mit 11 Commits, Stand cead269c (Kapitel 05)
Start: für alle gleich: MTP an, KV-Cache 8 bit, Kontext 262.144

Protokoll

Acht Fragen an ein Wetterprotokoll

Längen: 8 Stufen von 32.000 bis 245.000 Token, ein Dokument je Stufe
Reihenfolge: Fork, 1.2.4, 1.2.1, 1.2.1, 1.2.4, Fork
Budget: 3.072 Token Ausgabe, davon höchstens 2.048 Denken
Gemessen: Einlesen, Folgefragen, Ausgabe und Fragen ohne Antwort

245k Kontext245.127 Token im Prompt

435Token/s

sushi 1.2.1Prompt-Verarbeitung bei der ersten Frage

9,4Minuten

Ganzen Text einlesen einmal, bei der ersten Frage

19,2Sekunden

Folgefrage einlesen der Text ist schon verarbeitet

49,9Token/s

Ausgabe beim Antworten auf Folgefragen

Speicherfehler

sushi 1.2.47 von 16 Fragen ohne Antwort, in beiden Messungen

–

Ganzen Text einlesen die erste Frage scheiterte

–

Folgefrage einlesen Messläufe mit Fehler zählen nicht

–

Ausgabe Messläufe mit Fehler zählen nicht

709Token/s

Fork cead269cPrompt-Verarbeitung bei der ersten Frage

5,8Minuten

Ganzen Text einlesen einmal, bei der ersten Frage

14,6Sekunden

Folgefrage einlesen der Text ist schon verarbeitet

49,5Token/s

Ausgabe beim Antworten auf Folgefragen

Mittel beider Messungen eines Stands. Bei der ersten Frage zu einem Text liest sushi ihn vollständig ein, bei jeder Folgefrage nur ein Stück davon. Die Längen dazwischen zeigt Kapitel 02.

01 · Aufbau

Dieselben Fragen an drei Stände

Auf dem Mac Studio M1 Ultra liefen drei Stände von sushi mit denselben Gewichten, derselben Startzeile und denselben Dokumenten wie im Bericht über Apple M1: das Release 1.2.1, das Release 1.2.4 und ein Fork von 1.2.4 mit Änderungen für den M1 Ultra (Kapitel 05). Je Länge von 32k bis 245k gab es ein Dokument und acht Fragen; jeder Messlauf bekam einen frisch gestarteten Server ohne Plattencache.

Jeder Stand lief zweimal, in der Folge Fork, 1.2.4, 1.2.1, 1.2.1, 1.2.4, Fork. Ändert sich die Maschine über die Stunden, trifft das im Mittel alle drei gleich. Die beiden Messungen eines Stands liegen beim Einlesen höchstens 1,7 % auseinander, und 1.2.1 liest bis 128k auf 0,5 % so schnell ein wie im Bericht über Apple M1.

Der GPU standen 58 GiB zur Verfügung, 2 GiB mehr als die Vorgabe von 56 GiB. Mit dieser Grenze beantwortete 1.2.1 im Bericht über Apple M1 auch bei 229k und 245k jede Frage.

02 · Tempo

Der Fork liest bei 245k 1,6‑mal so schnell ein wie 1.2.1

Der Fork liest bei 32k 5 % mehr Token je Sekunde ein als 1.2.1, bei 128k 23 % und bei 245k 63 %. 1.2.4 liest bis 192k langsamer ein als 1.2.1, bei 32k um 29 %.

1.2.1 wird mit wachsender Länge langsamer, der Fork bleibt über 650. 1.2.1 liest 622 Token je Sekunde bei 32k und 435 bei 245k, der Fork 654 und 709. 1.2.4 liest über alle Längen bis 192k 440 bis 547; bei 229k und 245k fehlt es, weil die erste Frage am Speicher scheiterte (Kapitel 03). Bei 245k dauert das erste Einlesen mit 1.2.1 9,4 Minuten, mit dem Fork 5,8.

Bei Folgefragen liegt 1.2.4 auf 1.2.1, der Fork darunter. sushi liest bei jeder Folgefrage ein Stück des Textes neu ein. Das dauert mit dem Fork 22 bis 26 % kürzer als mit 1.2.1; 1.2.4 weicht von 1.2.1 höchstens 3 % ab. Bei 229k und 245k braucht eine Folgefrage mit 1.2.1 19,7 und 19,2 Sekunden, mit dem Fork 14,7 und 14,6.

Beim Schreiben liegen die Stände nahe beieinander. 1.2.1 erzeugt 45,6 bis 52,5 Token je Sekunde, 1.2.4 47,4 bis 55,5, der Fork 49,5 bis 60,4. sushi schreibt mit Mehrtoken-Vorhersage (MTP); wie oft sie trifft, hängt am Text, und der unterscheidet sich zwischen den Ständen (Kapitel 04). Je Länge liegt der Fork zwischen 1,0- und 1,3-mal so schnell wie 1.2.1.

Die Zeiten misst das Messskript am Datenstrom: Einlesen bis zum ersten Token, Ausgabe danach. Ein Messlauf, in dem eine Frage am Speicher scheiterte, zählt fürs Tempo nicht.

03 · Speicher

Nur der Fork beantwortet bis 245k jede Frage

1.2.4 ließ bei 229k und 245k in beiden Messungen 21 von 32 Fragen ohne Antwort, 1.2.1 in der ersten Messung 4 bei 192k und 229k. Der Fork beantwortete alle 128 Fragen.

Der GPU-Speicher lief beim Einlesen über. sushi meldet dann OutOfMemory und beendet die Antwort ohne Text; die nächste Frage beginnt neu. Bei 1.2.4 traf das in beiden Messungen dieselben Längen, bei 1.2.1 nur die erste Messung.

Alle drei liefen mit derselben Grenze von 58 GiB für die GPU. Wie viel Speicher jeder Stand bei welcher Länge braucht, ist nicht gemessen; die Reihe zeigt nur, wo er nicht reichte.

04 · Antworten

Die drei Stände schreiben verschiedenen Text

Zwischen zwei Messungen desselben Stands sind 78 % der Antworten byteweise gleich, zwischen zwei Ständen 27 bis 37 %.

Bei 1.2.1 stimmen 47 von 60 Antworten beider Messungen überein, beim Fork 50 von 64; die erste Frage zu einem Text beantworten beide Messungen jedes Stands immer gleich. 1.2.1 und Fork geben dagegen nur 16 von 60 gleiche Antworten. Die Stände rechnen also nicht Bit für Bit dasselbe; der Fork ändert, wie Zwischenwerte gerundet werden (Kapitel 05).

Richtig waren beim Fork 36 und 37 von 64 Antworten, bei 1.2.1 32 und 33, bei 1.2.4 33 und 32. Mit einem Dokument je Länge belegt das keinen Unterschied im Verstehen; den misst der Bericht über Apple M1 mit drei Fassungen je Länge.

05 · Der Fork

Elf Commits auf sushi 1.2.4

Der Fork liegt öffentlich im Zweig m1-ultra von holistech/sushi; der Vergleich mit v1.2.4 zeigt alle Änderungen auf einmal. Gemessen ist hier der ganze Fork. Wie viel eine einzelne Änderung beiträgt, belegt diese Reihe nicht.

eef8792e Befehlspuffer: Die GPU sammelt bis zu 1.000 Rechenaufträge und 1.000 MB, bevor sie einen Puffer abschickt; auf M1 Max und M1 Ultra.
ef4dcb9c Attention beim Schreiben: ein breiteres Raster für die geteilte Attention, damit beide Chiphälften des Ultra Arbeit bekommen.
7b57ecf9 Messschalter für Kostenzerlegungen der Kernel; ohne gesetzte Variable wirkungslos.
cf2e9a36 Experten beim Einlesen: Die Matrixmultiplikation rechnet nur die Blöcke von acht Zeilen, die belegt sind.
9d20a479 Befehlspuffer je Phase: 250 MB beim Einlesen, 1.000 MB beim Schreiben; dafür ein kleiner Patch an MLX.
1b5efd2c Gewichte beim Einlesen: ab 1.024 Zeilen erst entpacken, dann multiplizieren.
aaa3762b Derselbe Weg in f16 statt bf16.
4b34d2e1 Sparse Attention beim Einlesen: bis 4.096 Schlüssel über eine Maske statt über eine Auswahl.
ef794693 Sparse Attention darüber: ein eigener Kernel, der die Schlüssel zeilenweise in Kacheln von acht liest.
dfdcb613 Einbettungen je Schicht (PLE): ein paralleler Durchgang durch die von der SSD eingeblendete Tabelle.
cead269c Attention beim Einlesen: Der Kernel legt die Schlüssel zeilenweise im schnellen Speicher der Threadgroup ab.

06 · Alle Zahlen

Die Ergebnisse je Länge

Mittel beider Messungen eines Stands ohne Messläufe mit Fehlfrage: Einlesen bei der ersten Frage in Token je Sekunde, Folgefrage in Sekunden, Ausgabe in Token je Sekunde. Die Spalten „ohne Antwort“ zählen die Fragen ohne Antwort über beide Messungen. Aus diesen Werten sind alle Grafiken dieses Berichts gerechnet.

Einlesen
Länge	Einlesen 1.2.1	Einlesen 1.2.4	Einlesen Fork	Folgefrage 1.2.1	Folgefrage 1.2.4	Folgefrage Fork
32k	622	440	654	12,6	12,6	9,5
64k	610	538	681	11,8	11,8	9,2
96k	605	534	719	11,4	11,5	8,5
128k	600	547	736	10,5	10,5	7,9
160k	587	545	752	9,8	9,9	7,5
192k	557	536	754	8,8	9,1	6,6
229k	458	–	720	19,7	–	14,7
245k	435	–	709	19,2	–	14,6

Ausgabe und Fragen ohne Antwort
Länge	Ausgabe 1.2.1	Ausgabe 1.2.4	Ausgabe Fork	ohne Antwort 1.2.1	ohne Antwort 1.2.4
32k	52,5	55,5	60,4	0	0
64k	45,6	51,2	58,9	0	0
96k	48,9	49,1	51,4	0	0
128k	45,6	47,4	50,5	0	0
160k	47,6	53,1	52,8	0	0
192k	50,2	53,9	56,0	2	0
229k	47,5	–	58,2	2	14
245k	49,9	–	49,5	0	7

07 · Grenzen

Was diese Messung nicht zeigt

Eine Maschine. Gemessen ist nur der Mac Studio M1 Ultra. Wie der Fork auf anderen Chips läuft, ist nicht gemessen.

Ein Dokument je Länge. Für das Tempo genügt das, wie die zwei Messungen je Stand zeigen. Für das Verstehen nicht: Unterschiede in der Zahl richtiger Antworten sind hier kein Befund.

Mehr GPU-Speicher als vorgegeben. Alle Messläufe hatten 58 GiB für die GPU. Mit der Vorgabe von 56 GiB ist nicht gemessen.

Gegen die Releases, nicht gegen den Entwicklungsstand. Der Fork baut auf 1.2.4 auf. Was sich in sushi seit 1.2.4 geändert hat, enthält er nicht.

Keine Ursachen. Warum 1.2.4 langsamer einliest als 1.2.1 und bei 229k und 245k nicht mit dem Speicher auskommt, ist nicht untersucht.

Eine Art Dokument, eine Sitzung. Wie sich die Stände mit Quelltext oder in einem Agenten schlagen, ist hier nicht gemessen.