Revolut mit GLM-5.3: Self-Hosting-Kosten und API-Alternative

Für die meisten Teams ist ein Pilot mit einer nutzungsabhängig abgerechneten API der richtige Einstieg in Revoluts GLM-5.3-Ansatz. Halte für Aufgaben, die deine Qualitätsprüfungen nicht bestehen, einen Weg zu einem Spitzenmodell offen. Dediziertes Hosting solltest du erst erwägen, wenn dein Datenverkehr, deine Latenzanforderungen und deine Betriebskosten dafür sprechen.

Die folgenden Zahlen trennen Revoluts gemeldete Ergebnisse von Empfehlungen für dein Team. Dokumentation und API-Preise wurden am 2026-11-09 geprüft.

Was hat Revolut tatsächlich bereitgestellt?

Revolut machte offene GLM-Modelle zum Standard für etwa 2,000 Entwickler und behielt Spitzenmodelle für Ausnahmefälle bei. Die Präsentation bei AI Engineer samt Transkript beschreibt den Wechsel von GLM-5.1 zu GLM-5.3. Die spätere Bereitstellung nutzte 56 Nvidia-B200-GPUs.

Die Folie mit Betriebskennzahlen nennt auch Together. Daraus folgt nicht, dass Revolut 56 Karten gekauft und in eigenen Räumen installiert hat. Die Folie nennt einen Partner, aber weder den Hardware-Eigentümer noch die vollständige Betriebsvereinbarung.

Modell-Endpunkt und Coding-Client sind getrennte Entscheidungen. Mache einen Modellwechsel nicht davon abhängig, alle Clients auszutauschen. In der beschriebenen Architektur übernimmt GLM textbasierte Aufgaben. Ein Router leitet Anfragen zur Bildauswertung an ein bildfähiges Modell weiter.

Auch die Produktivitätszahlen brauchen eine klare Einordnung. Abitbol meldete eine Verbesserung von ungefähr 60% bei der Programmierzeit und 70% bei der Durchlaufzeit, der sogenannten Lead Time. Die Folie zur Einführung weist dagegen 60% Verbesserung bei der Lead Time aus.

Behandle diese Angaben als gemeldete interne Trends, nicht als kontrollierten Vergleich zwischen GLM und Claude. Sie belegen nicht, dass der Modellwechsel allein die Verbesserung verursacht hat.

Was misst die Kostensenkung um 90%?

Die Schlagzeile vergleicht Revoluts gemeldete Inferenzrechnungen. Sie vergleicht weder die gesamten Personalkosten noch alle Kosten für den Besitz der Infrastruktur. Der offizielle Vortragsbericht beschreibt eine Rechnung von etwa einem Zehntel der früheren Ausgaben bei Anbietern von Spitzenmodellen. Ein Zehntel des bisherigen Rechnungsbetrags entspricht einer Senkung um 90%.

Davon getrennt ordnet The Register den Wert von $0.30 pro Million Eingabe-/Ausgabetokens Revoluts GLM-5.1-Phase zu. Vermische diesen historischen Tokenpreis nicht mit der gemeldeten Rechnungssenkung. Er ist weder ein öffentlicher GLM-5.3-API-Tarif noch ein Nutzungskontingent eines Claude-Code- oder Codex-Abos.

Die Folie mit Betriebskennzahlen bezeichnet gecachte Tokens ebenfalls als kostenlos. Der Vortragsbericht enthält jedoch keine vergleichbaren Datenmengen und Abrechnungszeiträume. Auch die Aufschlüsselung der Betriebskosten fehlt, die für eine vollständige Kostenrechnung nötig wäre. Stelle $0.30 deshalb nicht als Gesamtbetriebskosten inklusive aller Abschreibungen dar.

Frage vor dem Vergleich eines Hosting-Angebots, welche Kosten im Zähler des Tokenpreises stecken. Prüfe GPU-Miete oder Abschreibung, zusätzliche Server, Netzwerk, Speicher, Strom, Support und die Arbeit der Entwickler. Kläre, welche Posten bereits enthalten sind, damit du sie nicht doppelt zählst.

Definiere anschließend den Nenner. Neue Eingaben, Cache-Lesezugriffe und erzeugte Ausgaben sind unterschiedliche Abrechnungskategorien. Einen Durchschnitt mit kostenlosen Cache-Lesezugriffen kannst du nicht direkt mit dem Preis für ungecachte Eingaben vergleichen.

Warum 256K Kontext und weniger als drei Sekunden bis zum ersten Token?

Nutze 256K als Kontextbudget, das du für deine Aufgaben testest, nicht als Modellgrenze von GLM-5.3. Die aktuelle Z.ai-Dokumentation nennt reine Texteingaben und ein Kontextfenster von 1M Tokens.

Abitbols Aussage „Langer Kontext ist Abzocke“ beschreibt seine Abwägung beim Modellbetrieb. Längere Anfragen brauchen mehr Speicher für den Kontext und mehr Verarbeitung der Eingabe. Bei einer festen GPU-Flotte bleiben dadurch weniger Ressourcen für gleichzeitige Sitzungen.

Seine praktischen Ziele waren weniger als drei Sekunden bis zum ersten Token und ungefähr 200 erzeugte Tokens pro Sekunde. Das beschreibt die von Revolut gewünschte Nutzungserfahrung. Es garantiert nicht, dass jede neue Anfrage mit 256K Tokens ihre Eingabeverarbeitung innerhalb von drei Sekunden abschließt.

Miss im Pilotprojekt kalte Anfragen getrennt von Anfragen, die gecachten Kontext wiederverwenden. Erfasse den Median und das 95. Perzentil der Latenz bei normaler und maximaler Parallelität. Miss auch die Zeit bis zum Abschluss der Aufgabe. Die Generierungsgeschwindigkeit enthält weder Testlaufzeiten noch Wartezeiten auf Werkzeuge.

Beginne mit relevanten Dateien und abgerufenen Informationen, statt das gesamte verfügbare Kontextfenster zu füllen. Reserviere Platz für die Ausgabe. Erhöhe das Kontextbudget nur, wenn die Ergebnisse akzeptierter Aufgaben die zusätzlichen Kosten oder Wartezeiten rechtfertigen.

Welche Teile brauchen GPU-Kapazität und Betriebsarbeit?

Um Revoluts Bereitstellungsleistung nachzubilden, musst du das System auf die konkrete Last abstimmen. Dieselben Modellgewichte zu laden, reicht nicht aus. Die Leistungsfolie zeigt eine Verkürzung der Zeit bis zum ersten Token von 14.26 auf 1.68 Sekunden. Dabei blieben dieselben 56 B200-GPUs im Einsatz.

Das entspricht etwa 88% weniger Wartezeit auf den ersten Token. Es belegt nicht, dass jede Programmieraufgabe 88% schneller abgeschlossen wurde.

Der Vortrag behandelt FP4-Quantisierung und die Trennung von Prefill und Decode. Prefill verarbeitet die Eingabe. Decode erzeugt die Ausgabetokens. Solche Entscheidungen im Inferenzsystem erfordern Kapazitätstests und eine für Verschlechterungen verantwortliche Betriebsperson.

Die Flotte mit 56 Karten ist auch keine Mindestanforderung, um GLM-5.3 zu laden. Das aktuelle vLLM-Rezept dokumentiert einen FP8-Betrieb auf einem einzelnen Knoten mit acht H200- oder H20-GPUs. Diese kleinere Konfiguration verspricht weder Revoluts Parallelität noch dessen Latenz oder Kostenstruktur.

Lass für einen Pilot mit dediziertem Hosting repräsentative Agentensitzungen auf der vorgeschlagenen Hardware erneut abspielen. Halte Modell-Checkpoint, Rechengenauigkeit, Kontextbudget und maximale Parallelität fest. Fordere bestandene Aufgabenprüfungen und akzeptable Latenz, bevor du die Kapazität erweiterst.

Was kann ein Team ohne 56 GPUs übernehmen?

Übernimm zuerst die Standardmodell-Strategie und die Bewertungsmethode, nicht die Infrastruktur. Der folgende Pilot ist ein Vorschlag. Er rekonstruiert nicht Revoluts private Konfiguration.

Wähle 20 repräsentative Aufgaben aus deinen Repositories, etwa Fehlerbehebungen, Tests, Refactorings und Dokumentationsänderungen. Starte GLM-5.3 und dein bisheriges Modell jeweils vom selben Ausgangs-Commit. Halte Coding-Client, Werkzeugberechtigungen, Akzeptanztests und Review-Kriterien konstant.

Gib jedem Lauf eine eigene Arbeitskopie. Eine erfolgreiche Aufgabe muss die nötigen Dateien lesen, eine prüfbare Änderung erzeugen und die vereinbarten Kontrollen bestehen. Eine plausibel klingende Chatantwort genügt nicht.

Lege klare Routing-Regeln fest:

• Schicke gewöhnliche textbasierte Programmieraufgaben an GLM-5.3.
• Schicke Aufgaben mit Bildauswertung an ein freigegebenes bildfähiges Modell.
• Wechsle nach einem fehlgeschlagenen Korrekturversuch oder auf ausdrücklichen Wunsch des Reviewers zum Spitzenmodell und protokolliere den Grund.

Diese Regeln sind ein Ausgangspunkt für die Bewertung, keine allgemein optimale Zahl von Wiederholungen. Halte beide Wege innerhalb der freigegebenen Regeln für Datenverarbeitung und Werkzeugberechtigungen.

Für Routing auf Clientseite hilft die Konfigurationsanleitung für Claude Code Router. Das ist eine mögliche Umsetzung, keine Aussage darüber, dass Revolut dieses Paket verwendet hat.

Erfasse Eingabe-, Cache- und Ausgabetokens, fehlgeschlagene Versuche, Kosten des Wechsels zum Spitzenmodell, Laufzeit und menschliche Review-Zeit. Vergleiche die Gesamtausgaben pro akzeptierter Aufgabe. Der Leitfaden zu Kosten pro Coding-Agent-Aufgabe erklärt, warum ein niedrigerer Tokenpreis allein die Wahl nicht entscheidet.

Mache GLM-5.3 nur für Aufgabenkategorien zum Standard, die deine Qualitätsschwelle erreichen. Behalte den bisherigen Weg bei, wenn zusätzliche Versuche oder Reviews die Ersparnis aufzehren.

Was kostet GLM-5.3 über eine API?

Die Standard-API von Z.ai liefert eine messbare Vergleichsbasis, ohne dass du GPU-Kapazität buchen musst. Zum Stand 2026-11-09 nennt die veröffentlichte Preisliste folgende USD-Tarife für GLM-5.3:

Tokenkategorie	Preis pro 1 Million Tokens
Ungecachte Eingabe	$1.40
Gecachte Eingabe	$0.26
Ausgabe	$4.40

Die Speicherung gecachter Eingaben wird als zeitlich begrenzt kostenlos ausgewiesen. Behandle diese vorübergehende Bedingung nicht als dauerhafte Zusage.

Betrachte eine beispielhafte Last mit 100 Millionen Eingabetokens und 10 Millionen Ausgabetokens. Ohne Cache ergibt sich folgende Modell-Tokengebühr:

100 × $1.40 + 10 × $4.40 = $184.00

Werden 90 Millionen dieser Eingabetokens als Cache-Treffer abgerechnet, lautet die Schätzung:

10 × $1.40 + 90 × $0.26 + 10 × $4.40 = $81.40

Das sind Rechenbeispiele, keine gemessenen Rechnungen. Sie setzen voraus, dass keine kostenpflichtigen Werkzeuge genutzt werden, und enthalten nur die Modell-Tokengebühren. Der Cache-Anteil von 90% ist eine Beispielannahme, keine Zusage für deine Last.

Nutze das tatsächliche Antwortfeld usage.prompt_tokens_details.cached_tokens, um gecachte Eingaben zu unterscheiden. Z.ai beschreibt es im Leitfaden zum Kontext-Caching.

Der am 2026-11-09 geprüfte BetterToken-Katalog führt ebenfalls glm-5.3. Die GLM-Integration für OpenCode verwendet die OpenAI-kompatible Basis-URL https://www.bettertoken.ai/v1. Vergleiche die aktuellen Preise anhand deiner gemessenen Tokenverteilung. Dieser API-Zugang bildet weder Revoluts Infrastrukturkosten nach noch enthält er ein Coding-Tool-Abonnement.

Erstelle für den Z.ai-Zugangstest einen Standard API Key anhand der HTTP-API-Anleitung. Nutze für dieses Beispiel ein Standard-API-Konto mit Guthaben.

Führe die Befehle in Bash aus; curl muss installiert sein. Der erste Befehl wartet ohne angezeigte Eingabeaufforderung auf deinen Schlüssel. Füge ihn ein und drücke Enter. Der Schlüssel erscheint nicht auf dem Bildschirm.

read -rs ZAI_API_KEY && export ZAI_API_KEY

curl --silent --show-error \
  --write-out '\nHTTP %{http_code}\n' \
  "https://api.z.ai/api/paas/v4/chat/completions" \
  -H "Authorization: Bearer $ZAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Return exactly READY."}
    ]
  }'

Die Chat-Completion-Referenz dokumentiert diesen Endpunkt und das Antwortformat. Prüfe auf HTTP 200, einen nicht leeren Inhalt in choices[0].message.content und das Objekt usage. Die erwartete Antwort lautet READY. Das prüft den Zugriff, nicht die Codequalität oder die Werkzeugausführung.

Prüfe bei HTTP 429 vor einem weiteren Versuch den Fehlercode im JSON. Z.ai unterscheidet 1113, unzureichendes Guthaben oder fehlendes Ressourcenpaket, von 1302, einem Limit für die Anfragehäufigkeit. Lade im ersten Fall das richtige API-Konto auf. Senke im zweiten Fall die Anfragehäufigkeit. Diese Bedeutungen gelten für die Fehlerreferenz von Z.ai.

Gilt Yingjun Wus Gewinnschwelle bei 35% auch für dein Team?

Nein. Wu untersucht den Verkauf von Inferenz mit DeepSeek V4.1 Flash, nicht die Bereitstellung von GLM-5.3 für ein internes Entwicklerteam.

In seiner am 2. November 2026 aktualisierten Analyse deckt H200 selbst bei voller Auslastung die Miete nicht. Der B300-Fall erreicht die Gewinnschwelle ungefähr bei 35%. Der H200-Fall erzielt etwa $1.60 pro GPU-hour bei $3.99 Miete. Aus diesen gerundeten Werten ergibt sich ein rechnerischer Fehlbetrag von $2.39 pro Stunde, noch vor weiteren Kosten.

Seine Rechnung schließt Bandbreite, Personal und Reservekapazität aus. Behandle die Werte als Annahmen seines Szenarios, nicht als aktuelle Mietangebote oder hier reproduzierte Messungen.

Nützlich ist die Methode. Ersetze für internes Hosting den Umsatz aus Tokenverkäufen durch API-Ausgaben, die dein Betrieb tatsächlich vermeiden würde. Rechne mit deinem Modell, Cache-Anteil, erreichbaren Durchsatz, deinen Qualitätsprüfungen und deinen Latenzanforderungen neu.

Welche Betriebsform solltest du wählen?

Wähle eine nutzungsabhängig abgerechnete API, wenn die Nachfrage unsicher ist oder deinem Team Inferenzbetriebsexperten fehlen. Überdenke die Wahl, sobald wiederholte Messungen zeigen, dass vermiedene API-Ausgaben ein vollständiges Hosting-Angebot decken.

Teste dedizierte Kapazität bei einem Hosting-Anbieter, wenn die Nachfrage stabil ist, du aber keine Hardware besitzen und betreiben möchtest. Der Vertrag sollte Zuständigkeiten für Updates, Kapazitätsgrenzen, Ausfälle, Datenstandort und Support festlegen. Bleibe bei der nutzungsabhängigen Abrechnung, wenn die nötige Buchung deine realistische Nutzung übersteigt.

Betreibe deine eigene Inferenzinfrastruktur, wenn Kontrollanforderungen das rechtfertigen und ein Team sie warten kann. Ändere die Entscheidung, falls Spitzenlast-Latenz, Qualitätsverschlechterungen oder Personalkosten den erwarteten Vorteil beseitigen.

Fordere vor dem Vertragsabschluss einen Vergleich pro akzeptierter Aufgabe, einen Spitzenlasttest, ein vollständiges Monatsbudget und einen benannten Betriebsverantwortlichen. Berücksichtige ungenutzte Kapazität und Ausnahmen, die an Spitzenmodelle gehen. Nutze das TCO-Modell für Self-Hosting in Entwicklerteams für das Gesamtbudget, statt Revoluts historischen GLM-5.1-Wert als eigene Prognose zu übernehmen.