1.500 Tokens pro Sekunde: Qwen 3.8 auf Cerebras und die Frage nach dem Agenten-Tempo

Cerebras listet Qwen 3.8 27B im eigenen Modellkatalog mit rund 1.500 Tokens pro Sekunde Ausgabegeschwindigkeit. Die Hacker-News-Diskussion vom 03.09.2026 stand bei 493 Punkten, als ich sie am 05.09.2026 über die API abgefragt habe. Beides ist bemerkenswert. Die interessantere Frage beginnt aber danach: Was macht dieses Tempo mit einem Agenten, der nicht im Rechenzentrum läuft, sondern auf einem gebrauchten Google Pixel 6a?

Meine Antwort aus dem laufenden Betrieb lautet: Die Rate kauft schnelle Denkschritte, aber keinen Betrieb. Ein Agent braucht zuerst einen Host, der Cron-Ticks, Speicherdruck und Neustarts überlebt, bevor irgendeine Tokenrate etwas wert ist. Genau darum geht es in diesem Beitrag. Ich trenne dabei sauber, was im Cerebras-Katalog steht, was ich selbst gemessen habe und was eine begründete Hypothese bleibt.

Ich ordne meinen Agentenbetrieb in drei Ebenen, und diese Unterscheidung trägt den ganzen Beitrag. Das ist ein Arbeitsmodell, keine gemessene Zerlegung. Die erste Ebene ist das Modell-Denken: Planung, Urteil, Entwurfstext. Hier hilft die 1.500-Token-Rate unmittelbar, weil ein Plan in Sekunden steht, wo er früher Minuten gebraucht hat. Die zweite Ebene ist die Mechanik: Skripte holen Transkripte, prüfen 58 YouTube-Feeds und schreiben Heartbeats. Diese Arbeit läuft ohne Modell-Requests und damit ohne jede Abhängigkeit von Tokens pro Sekunde.

Die dritte Ebene ist der Betrieb: Watchdogs, Cron-Ticks und der Wiederanlauf, wenn Android dem Prozess den Speicher entzieht. Hier entscheidet Ausdauer, nicht Geschwindigkeit. Die drei Ebenen addieren sich nicht, sie dominieren nacheinander. Solange die Betriebsebene wackelt, ist die Denkebene Geschmackssache. Und solange die Mechanik auf Requests gebaut ist, frisst sie das Kontingent, das das Denken brauchen würde.

Warum Android Hintergrundprozesse überhaupt killt und wie mein Stack diese Kills übersteht, habe ich im Android-Beitrag im Detail dokumentiert, vom OOM-Sturm am 28. August bis zum semantischen Watchdog. Hier ist nur die Folge wichtig: Die Betriebsebene kennt keine Tokens pro Sekunde. Sie kennt Ticks, Logs und Wiederanläufe. Wer nur die Denkebene kauft, hat am Ende die schnellste Schwachstelle des Systems.

Die Mechanik-Ebene ist der Grund, warum mein Kontingent überhaupt reicht. Das komplette Transkript eines 54-minütigen Videos zu beschaffen und in einen Blog-Entwurf zu überführen, belastet das Modell-Kontingent praktisch nicht, weil ein Skript das Transkript holt und nur die Urteile Requests kosten. Wie dieser Stack im Ganzen aussieht, nämlich Termux, PRoot, kein Root, Cloud-Modelle, steht im Stack-Beitrag.

Gemessen habe ich drei Dinge, alle im normalen Betrieb, keiner davon im Labor. Erstens die Kontingentseite: Die komplette Verarbeitung eines 54-minütigen Videos kostete am 04.09.2026 laut Dashboard-Vergleich 0,5 Prozent des Fünf-Stunden-Fensters. Das ist eine Einzelmessung aus einem einzigen Workflow-Typ, und sie sagt etwas über Kontingentbelastung, nicht über Energie oder allgemeine Kosten.

Zweitens die Stabilität: Laut stability-snapshots.log und der stündlichen Heartbeat-Kette lief das System vom 28. August, 19:40 Uhr bis zum 1. September, 12:18 Uhr, 88 Stunden am Stück, ohne beobachteten OOM-Kill seit der Härtung am 28. August. Die Messung tickt stündlich, zwischen den Checks sieht sie nichts, und null beobachtete Kills sind keine Garantie für die Zukunft. Drittens die Projekte: Der Network Obfuscation Layer und der Preiskompass bestanden am 30.08.2026 zusammen 36 von 36 Tests.

Was all diese Zahlen nicht enthalten, ist eine Zeitmessung der Ebenen. Ich habe keine Stoppuhr laufen lassen, die Planung, Mechanik und Betrieb separat stoppt. Deshalb ist die These, der Engpass liege beim Betrieb und nicht beim Modell, für meinen Betrieb eine begründete Hypothese: gestützt auf die Beobachtung, dass der Agent auf Testläufe und Cron-Ticks wartet, nicht auf Modellantworten, und dass die Mechanik ohne Requests arbeitet. Widerlegt wäre sie, wenn eine echte Messung zeigte, dass Netz und Modell den größten Teil meiner Turn-Zeiten stellen. Genau diese Messung fehlt. Sie ist der nächste verbindliche Prüfschritt, und dieser Beitrag behauptet sie nicht.

Gleichwohl ist die Beobachtung konkreter, als das Wort Hypothese klingt. Beim Bau der beiden verifizierten Projekte saß die Wartezeit im Bauen und Prüfen, also in Testläufen, Nachlesen und Verifikation. Das Modell war zu keinem Zeitpunkt das Hindernis, das ich gespürt hätte. Und die 0,5-Prozent-Messung zeigt die umgekehrte Richtung der Sorge: Nicht das Denken ist teuer, sondern alles, was darum herum oft läuft. Beides zusammen macht die Hypothese plausibel, aber es ersetzt keine gestoppte Messreihe.

Der 1.500-Token-Wert ist keine Einmaligkeit, sondern die aktuelle Stufe einer Leiter, die Cerebras seit über einem Jahr hochgeht. Im Juli 2025 brachte das Unternehmen Qwen3-235B als schnellstes Frontier-Modell auf 1.500 Tokens pro Sekunde und bezifferte den Praxisgewinn: Antwortzeiten fallen laut Pressemitteilung von ein bis zwei Minuten auf rund 0,6 Sekunden. Qwen3-32B läuft laut Cerebras-Blog mit 2.400 Tokens pro Sekunde, der erste Antwort-Token kommt nach eigenen Angaben nach 1,2 Sekunden, gemessen von Artificial Analysis. Zum Vergleich steht im selben Blog: GPU-basierte Inferenz liegt bei Modellen dieser Klasse um etwa 150 Tokens pro Sekunde.

Für die saubere Bewertung lohnt es sich, fünf Größen auseinanderzuhalten, die oft in eine Zahl gequetscht werden: Ausgabe-Tokenrate, Zeit bis zum ersten Token, Gesamtdauer eines Auftrags, Ausgabequalität und Preis. Der Katalog nennt für Qwen 3.8 27B die Rate von rund 1.500 Tokens pro Sekunde und ein Kontextfenster von 64k im freien sowie 128k im bezahlten Tarif, abgerufen am 05.09.2026. Eine Angabe zur ersten Token-Latenz findet sich für dieses Modell dort nicht, die 1,2 Sekunden oben gehören zu Qwen3-32B. Zur Qualität sagt der Katalog nichts, und die Preise stehen separat hinter Rate-Limits und Pricing-Seite. Ich habe sie für diesen Beitrag nicht ausgewertet und mache deshalb keine Aussage zu Kosten.

Die eigentliche Nachricht der Leiter ist deshalb eine Verschiebung der Debatte. Vor einem Jahr ging es darum, ob so ein Tempo überhaupt möglich ist. Heute steht ein 27B-Modell mit dieser Rate im regulären Katalog, und die Frage lautet nicht mehr wie, sondern wofür. Genau auf dieser zweiten Frage arbeitet der Rest des Beitrags.

Der Thread lohnt sich als Stimmungsbild, und ich lese ihn genau als das: als Meinungs-Lage, nicht als technische Evidenz. Ein Teil der Kommentare feiert das Tempo und rechnet vor, wie sich Coding-Workflows anfühlen, wenn die Antwort in Bruchteilen einer Sekunde kommt. Ein anderer Teil rechnet die Preise durch und berichtet, Prompt-Caching werde zwar unterstützt, koste aber denselben Satz wie frische Tokens, und das Abo-Modell sei vergriffen. Wieder andere fragen nach dem Kontextfenster und finden die 128k, mit dem Vorbehalt, das reiche für agentische Arbeit knapp. Und ein Kommentar nennt die Ankündigung beim Namen: Pure Marketing.

Ich lese das nicht als Verachtung, sondern als Verschiebung des Marktangebots. Tempo ist der angebotene Vorteil, aber was ein Agenten-Betreiber zusätzlich kaufen muss, ist Verlässlichkeit: ein Host, der Ticks liefert, wenn gerade kein Modell-Request offen ist. Cerebras verkauft die schnellste Denkebene. Wer nur diese Ebene hat, merkt spätestens beim ersten Android-Kill, dass eine fehlende Betriebsebene keinen Token pro Sekunde wert ist.

Die Rate zählt, weil sie die Rechnung ändert. Schnellere Modellausgaben könnten den Engpass zur Betriebsebene verschieben. Für meinen Workflow ist das eine Hypothese: Die Zeitmessung der einzelnen Schritte fehlt, deshalb ist das die Arbeitshypothese dieses Beitrags, nicht seine gemessene Schlussfolgerung. Ein Agent, der in 30 Sekunden plant, wartet trotzdem auf den nächsten Cron-Tick, weil der Host den Takt vorgibt. In meinem Setup steht der stündliche Heartbeat, ein externer Tick kommt alle 60 Sekunden, und die Watchdogs bringen das System nach einem Android-Kill wieder in Betrieb. Für die Dauer dieses Wiederanlaufs habe ich aus den Snapshots grob zwei Minuten gelesen, ohne die Messstrecke sauber gestoppt zu haben. Die präzise Zahl fehlt, der Android-Beitrag zeigt den Mechanismus im Detail.

Mein Fazit fällt bewusst ohne Sieger aus. Die 1.500 Tokens pro Sekunde für Qwen 3.8 27B sind real, belegt und für die Denkebene ein echtes Upgrade. Für den Agentenbetrieb auf schwacher Hardware entscheidet sich der Nutzen aber an Stellen, die im Katalog nicht auftauchen: Taktgeber, Speicherdruck, Gedächtnis, Testläufe. Wer darüber nachdenkt, sollte die Betriebsebene parallel zur Denkebene bauen, also Watchdogs, Ticks und Gedächtnis, und sich nicht auf Tempo als Ersatz verkaufen lassen. Als nächsten Prüfschritt habe ich mir eine gestoppte Turn-Zeitreihe vorgenommen, Netz, Modell und Orchestrierung getrennt. Sobald sie läuft, ersetzt sie die Hypothese dieses Beitrags durch Zahlen.

Über den Autor: Ich bin Marcel, Grafikdesigner und Betreiber der d4sn3st-Seiten. Ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a, ohne Root, mit Cloud-Modellen und Terminal-Orchestrierung. Diesem Beitrag liegen eigene Messungen aus stability-snapshots.log und dem Ollama-Dashboard im Fenster 28.08. bis 05.09.2026 zugrunde sowie die Testberichte der beiden verifizierten Projekte vom 30.08.2026. Externe Angaben stammen aus dem Cerebras-Modellkatalog und der Hacker-News-Diskussion, beide abgerufen am 05.09.2026. Zuletzt fachlich geprüft: 05.09.2026.