GLM-5 Inferenzgeschwindigkeit auf WaveSpeed: Latenz & Durchsatz

Ich wollte schnell antworten, während ich eine Onboarding-E-Mail entwarf. GLM-5 wirkte intelligent, aber der erste Token ließ so lange auf sich warten, dass ich mich dabei ertappte, wie ich den Cursor anstarrte. Keine Katastrophe, nur eine kleine Pause, die immer wieder auftrat. Das ist für mich normalerweise das Signal, nachzuschauen, was wirklich los ist.

Ich bin Dora. Ich habe eine einfache Testreihe durchgeführt, um herauszufinden, wie viel GLM-5-Inferenzgeschwindigkeit ich herausholen kann, ohne meinen Workflow in ein Wissenschaftsprojekt zu verwandeln. Nichts Ausgefallenes, nur genug, um den Unterschied bei echter Arbeit zu spüren – nicht im Labor.

Testmethodik (Hardware, Einstellungen, Promptlängen)

Ich habe drei Zugangswege ausprobiert:

• ​WaveSpeed​: eine schlanke Beschleunigungsschicht, die ich teste und die Request-Shaping und Caching auf der Client/Gateway-Seite übernimmt.
• ​Direkte Z.ai-API: der direkte Weg zu GLM-5 über den Anbieter.
• ​OpenRouter​: ein Vermittler, der Anfragen mit einigen Extras an den Modellanbieter weiterleitet.

Hardware und Kontext

• Lokaler Client: MacBook Pro (M2 Max, 64 GB RAM). Netzwerk über stabiles Glasfaser (≈500 Mbps Download, ≈30 ms zu gängigen US-Endpunkten).
• Serverseite: kein eigener Server, nur Client-Aufrufe – außer bei WaveSpeed, das ein kleines lokales Gateway betreibt, um Caching und Batch-Shaping zu verwalten.

Einstellungen, die ich konstant gehalten habe (sofern nicht anders angegeben)

• Modell: GLM-5 (chat/completions), temperature 0.2, top_p 0.9, max_tokens 512.
• Streaming aktiviert, weil ich so tatsächlich arbeite.
• Retries deaktiviert, außer bei Netzwerkfehlern.

Verwendete Prompts

• Kurz: 60–80 Token (eine knappe Anweisung mit 2–3 Einschränkungen).
• Mittel: ~350 Token (E-Mail-Entwurf mit Markenhinweisen und Beispielen).
• Lang: ~1.500 Token (ein kleines Briefing mit Produktkontext, Tonalitätshinweisen und Do/Don’t-Listen).

Ich führte 25 Iterationen pro Bedingung durch und erfasste:

• Time to First Token (TTFT): von der Anfrage bis zum ersten gestreamten Token.
• Durchsatz (Token/s): gestreamte Ausgaberate, sobald Token eintreffen.
• Einen Schalter für den „Thinking-Modus” (Reasoning-Traces des Anbieters).

Wichtige Kennzahlen

Time to First Token (TTFT)

Kurze Prompts lagen bei guten Routen zwischen 250–400 ms. Mittlere Prompts trieben den TTFT auf 450–700 ms. Lange Prompts überschritten eine Sekunde, sofern kein Caching einsprang. Der Anstieg war nicht linear: Warteschlangen- und Validierungsoverhead schienen genauso ins Gewicht zu fallen wie die Promptlänge.

Meine Einschätzung: Unter 400 ms fühlt sich alles flüssig an – alles über einer Sekunde reißt mich aus dem Arbeitsfluss. Wenn ich Live-Text bearbeite, ist das erste Token wichtiger als der abschließende Durchsatz.

Token pro Sekunde (Durchsatz)

Sobald das Streaming begann, sah ich 35–70 Tok/s bei Nicht-Thinking-Läufen. Das ist angenehm schnell für Texte, im Grenzbereich für Code-Diffs. Der Durchsatz sank bei längeren Ausgaben – vermutlich wegen serverseitigem Shaping und Safety-Passes, nicht wegen der reinen Modellgeschwindigkeit.

Thinking-Modus vs. Nicht-Thinking-Modus

Mit aktiviertem „Thinking” stieg der TTFT um 30–80 %, und der Durchsatz halbierte sich in manchen Fällen. Der Text war bei anspruchsvollen Prompts kohärenter, aber für alltägliches Entwerfen brauchte ich das nicht. Das sparte mir anfangs keine Zeit, aber nach einigen Läufen bemerkte ich, dass es den mentalen Aufwand bei komplexen Bearbeitungen reduzierte. Bei einfachen Aufgaben lasse ich es deaktiviert.

Wie WaveSpeed-Beschleunigung auf GLM-5 angewendet wird

WaveSpeed hat die Modellgewichte nicht verändert. Es hat auf meiner Seite der Verbindung zwei einfache, nützliche Dinge getan: redundante Arbeit reduziert und Anfragen so geformt, dass der Anbieter schneller reagieren konnte. Bei GLM-5 äußerte sich das in besserem TTFT bei wiederholten Prompts und kleinen Gewinnen bei mittleren Prompts.

ParaAttention und Caching-Techniken

• ParaAttention (meine Notizen): Anstatt unzusammenhängende Anfragen zu bündeln, parallelisiert WaveSpeed attention-freundliche Abschnitte innerhalb eines einzelnen langen Prompts, wenn es wiederholtes Scaffolding erkennt. In der Praxis wurde das Vorspiel (System + gemeinsame Beispiele) wiederverwendet und nur das Delta übertragen. Ich kann die Interna nicht überprüfen, aber der Effekt sah aus wie eine partielle KV-Wiederverwendung auf Gateway-Ebene.
• Caching: Es memoisierte Embeddings für das Prompt-Vorspiel und kurze System-Templates. Wenn ich an derselben Aufgabe mit kleineren Änderungen iterierte, sank der TTFT um ~120–180 ms. Bei kalten Prompts war der Vorteil kleiner (~40 ms), aber noch spürbar.

Grenzen, die ich erreicht habe

• Der erste Kaltlauf ist nach wie vor durch den Upstream gebunden. Keine Wunder.
• Wenn ich mehr als ~20 % des Prompts änderte, half der Cache nicht.
• Der Thinking-Modus neutralisierte die Gewinne weitgehend: der Reasoning-Trace verhielt sich wie ein separater Stream.

Vergleich: WaveSpeed vs. direkte Z.ai-API vs. OpenRouter

Hier sind die kleinen Unterschiede entscheidend.

• Direkte Z.ai-API: Konsistent. Geringste Varianz beim TTFT. Wenn ich vorhersehbare Starts für Demos brauchte, war das meine Wahl. Bei langen Prompts war die TTFT-Einbuße real, aber gleichmäßig.
• OpenRouter: Im Durchschnitt etwas höherer TTFT, etwas mehr Varianz, aber einfaches Setup und Routing-Flexibilität. Gut, wenn ich mehrere Modelle jongliere. Die Dokumentation ist solide – siehe die OpenRouter-Anleitungen.

• WaveSpeed-Schicht: Bester TTFT bei warmen Prompts und mittleren Eingaben, wahrscheinlich durch Caching und Request-Shaping. Bei wirklich kalten, langen Prompts lag er gleichauf mit dem direkten Zugang.

Keiner dieser Wege veränderte das grundlegende GLM-5-Verhalten. Sie veränderten, wie schnell ich das Gefühl hatte, dass das Modell „aufwacht”, und wie reibungslos sich die Iteration anfühlte.

Wenn Sie eine Entscheidung treffen müssen:

• Stabile Leistung und weniger bewegliche Teile benötigt? Gehen Sie direkt über den Anbieter. Referenz: die ZhipuAI-API-Dokumentation.
• Multi-Modell-Routing oder gemeinsame Schlüssel für verschiedene Tools benötigt? OpenRouter ist in Ordnung – akzeptieren Sie ein paar Millisekunden mehr.
• Den ganzen Tag an ähnlichen Prompts iterieren? Eine leichte Beschleunigungsschicht zahlt sich eher durch mentale Ruhe aus als durch rohe Geschwindigkeit.

Optimierungstipps für Produktions-Workloads

Was in der Praxis wirklich geholfen hat:

• Vorspiel aufwärmen: Halten Sie System-Prompts und gemeinsame Beispiele stabil. Cachen Sie diese, auch clientseitig. Meine TTFT-Einsparungen: ~100–200 ms bei Wiederholungen.
• Den Schwanz kürzen: Begrenzen Sie max_tokens auf das tatsächlich Benötigte. Das Reduzieren einer 1.000-Token-Obergrenze auf 400 verkürzte die Gesamtzeit meiner Entwürfe um 10–20 %.
• Strukturierte Retries bevorzugen: Falls Retries nötig sind, Streams fortsetzen, nicht neu starten. Blinde Retries killten den TTFT.
• Variabilität kontrollieren: temperature ≤0,3 für die Produktion. Geringere Entropie reduzierte Server-Passes und machte den Durchsatz stabiler.
• Thinking-Modus verzögern: Nur bei Prompts aktivieren, die historisch gesehen fehlschlagen. Ich markiere „schwierige Prompts” und setze das Flag pro Route.
• Langen Kontext vorgelagert aufteilen: Referenzen einmal zusammenfassen, die Zusammenfassung speichern und wiederverwenden. Der zweite und dritte Lauf fühlt sich deutlich leichter an.
• Tokenisierung beachten: Verschiedene SDKs tokenisieren leicht unterschiedlich. Den Client festlegen und erneut messen: Ich habe allein dadurch scheinbare Regressionen beobachtet.
• p95 messen, nicht nur p50: Spitzenartige Ausreißer verursachen die sichtbaren Verzögerungen, an die sich Nutzer erinnern.

Rohe Benchmark-Daten (Tabelle)

Hier ist der Schnappschuss aus meinen Läufen (25 Iterationen pro Zeile). Alle Zahlen sind Näherungswerte, repräsentieren aber gut, was ich an der Tastatur gespürt habe.

Hinweise

• „Warmes Vorspiel” bedeutet, dass System und gemeinsame Beispiele vom Gateway gecacht wurden.
• Der Durchsatz wird nach dem ersten Token gemessen. Gesamtzeit = TTFT + tokens_out / Durchsatz.
• Das Netzwerk war stabil: Als ich im Hotel-WLAN testete, sah alles um 10–20 % schlechter aus.

Eine letzte Beobachtung: 150 ms vom TTFT abzuschneiden war für mich bedeutsamer als 5 Tok/s mehr, weil es das kleine Warten reduzierte, das Kontextwechsel auslöst. Das ist keine universelle Regel, nur die Art, wie mein Gehirn mit Streams umgeht.