Ein Relais oder Proxy für die GLM API wird oft als Änderung einer einzigen Zeile base_url betrachtet. Im Betrieb zeigt sich, dass vier Fragen die Erfahrung bestimmen: Durch wessen Infrastruktur läuft die Anfrage, wem gehört der Key, wie werden Kosten berechnet, und wer behebt Störungen? Sind diese vier Punkte unklar, taugt selbst ein niedriger Preis nicht für Produktionsverkehr.

Dieser Beitrag vergleicht Direktanbindung, eigenen Proxy und verwaltetes Gateway und behandelt Abrechnungstransparenz, Drosselung, Key-Risiko, Störungsumschaltung und Migrationsprüfung. Verfügbare Modelle und Preise richten sich nach den Modellpreisen.

Hinweis: Zhipu, GLM und BigModel sind Marken der jeweiligen Inhaber. Dieser Beitrag dient der technischen Erläuterung; es besteht keine Zugehörigkeit oder Vertretungsbeziehung zu Zhipu. Der Relais-Markt ändert sich schnell; der Beitrag ist keine Empfehlung für einzelne Anbieter.

1. Zuerst fünf Begriffe trennen

  • Offizielle Direktanbindung: Die Anwendung ruft die Schnittstelle der offenen Zhipu-Plattform direkt auf; Key, Rechnung und Drosselung gehören zum eigenen Konto.
  • Netzwerk-Proxy: stellt nur Erreichbarkeit her, ändert die API-Semantik nicht, der Key bleibt beim Nutzer.
  • Eigener Proxy oder eigenes Gateway: selbst betriebene Weiterleitung, Authentifizierung, Drosselung und Logs; Upstream bleibt das offizielle Konto oder ein konformer Anbieter.
  • Kommerzielles Relais: ein Dritter leitet weiter und rechnet ab, möglicherweise mit Kontingenten, Paketen oder gemeinsamem Key; die Grenzen bestimmt der Betreiber.
  • Einheitliches AI-Gateway: OpenAI-kompatibler Zugang, bündelt mehrere Modelle, einheitliche Keys, Abrechnung und Konsole; verwaltet oder selbst betrieben möglich.

Die Begriffe werden oft vermischt, sodass Netzwerkprobleme als Modellprobleme erscheinen. Vor Vertragsabschluss reicht eine Frage: In wessen Identität erreicht die Anfrage den Upstream?

2. Vier Varianten in einer Tabelle

Dimension Direkt offiziell Eigener Proxy Verwaltetes Gateway
Abrechnungstransparenz offizielle Rechnung, klare Grundlage Upstream-Rechnung plus eigene Kosten Preisregeln und Nutzungsdetails prüfen
Netzwerkstabilität von lokalem Ausgang abhängig hängt von Server und Leitung ab hängt von Gateway-Leitung und Upstream ab
Drosselungsgrundlage Konto- oder Projektebene eigene Kontrolle, aber Upstream-Limits Tarifregeln prüfen, gemeinsamer Pool?
Key und Daten selbst gehalten, Daten direkt zum Upstream selbst kontrollierbar, eigenes Audit möglich eigener Key und Datenschutz bestätigen
Betriebsaufwand niedrig Server, Zertifikate, Bereitschaft an Dienstleister übertragen, von dessen Verfügbarkeit abhängig

Keine Variante passt für alle: Wer nur GLM nutzt und bei Netzwerk und Zahlung keine Probleme hat, bindet direkt an; wer festen Ausgang und Audit braucht, baut selbst; wer mehrere Modelle, aber kein Betriebsteam hat, prüft ein verwaltetes Gateway.

3. Abrechnung: Grundlagen jenseits des Faktors

Häufige Angebote lauten „offizieller Preis mal Faktor“ oder „Token-Paket“. Der Faktor ist nur der Einstieg; die Rechnung bestimmen diese acht Punkte:

  1. Werden Eingabe und Ausgabe getrennt berechnet, und ist der Faktor gleich?
  2. Erhalten Cache-Treffer einen Rabatt, auf welcher Preisversion basiert er?
  3. Zählen Denk-Token von Reasoning-Modellen zur Ausgabe?
  4. Werden Fehler, Wiederholungen und Streaming-Abbrüche berechnet?
  5. Liefert Streaming die vollständige usage?
  6. Mindestaufladung, Gültigkeitsdauer und Rückerstattungsbedingungen?
  7. Sind Rechnungen möglich, wie werden Währung und Wechselkurs festgelegt?
  8. Lässt sich die Rechnung nach Projekt, Key und Modell aufteilen?

Erst wenn diese acht Punkte in der Vergleichstabelle stehen und dieselben Anfragen wiedergegeben werden, lässt sich der echte Preis berechnen. Die Preise auf dieser Website stehen unter Modellpreise und ändern sich mit Modell und Aktion.

4. Stabilität: Kennzahlen, Probe und Störungsumschaltung

Stabilität zeigt sich nicht in Werbung, sondern in sechs Kennzahlen: Erfolgsrate, P50/P95-Latenz, Zeit bis zum ersten Token, Timeout-Rate, 429-Anteil und Ausgabegeschwindigkeit. Mit Prompts realistischer Länge testen, Streaming, langen Kontext und Parallelität abdecken und mindestens einen Spitzenzyklus beobachten.

Störungsumschaltung ist nicht einfach „zwei Adressen konfigurieren“. Nur bei Verbindungsfehlern, 5xx und eindeutigen Drosselungscodes umschalten; bei 401, 403 oder 400 – Konfigurationsfehlern – scheitert auch der Ersatzweg meist. Bei Anfragen mit Nebenwirkungen zuerst prüfen, ob sie ausgeführt wurden, um doppelte Abbuchungen zu vermeiden.

import os
from openai import OpenAI

ENDPOINTS = [
    {
        "name": "primary",
        "base_url": os.environ["GLM_BASE_URL"],
        "api_key": os.environ["GLM_API_KEY"],
    },
    {
        "name": "backup",
        "base_url": os.environ["BACKUP_BASE_URL"],
        "api_key": os.environ["BACKUP_API_KEY"],
    },
]

def ask(prompt: str) -> str:
    last_error = None
    for endpoint in ENDPOINTS:
        client = OpenAI(
            base_url=endpoint["base_url"],
            api_key=endpoint["api_key"],
            timeout=60,
            max_retries=0,
        )
        try:
            resp = client.chat.completions.create(
                model=os.environ["GLM_MODEL"],
                messages=[{"role": "user", "content": prompt}],
                max_tokens=512,
            )
            return resp.choices[0].message.content
        except Exception as exc:
            last_error = exc
            print(f"{endpoint['name']} fehlgeschlagen: {type(exc).__name__}")
    raise RuntimeError("Haupt- und Ersatzzugang fehlgeschlagen") from last_error

Modellfähigkeiten, Kontextlänge und Parameterunterstützung von Haupt- und Ersatzweg sind nicht zwingend gleich. Vor dem Umschalten mit einem festen Testsatz vergleichen; den Ersatzweg nicht als vollständig gleichwertig behandeln.

5. Drosselung und Parallelität: die unsichtbaren Kosten eines gemeinsamen Pools

Die offizielle Direktanbindung drosselt meist auf Konto- oder Projektebene, nach Parallelität, Anfragen pro Minute oder Tokenrate, abhängig von Tarif und Modell; maßgeblich sind Konsole und Dokumentation.

Nutzt ein kommerzielles Relais einen gemeinsamen Pool, überlagern sich Ihre Spitzen mit denen anderer: tagsüber normal, im Abendpeak gehäuft 429; im Fehlerkörper können Hinweise auf offene Beträge oder Tarifgrenzen erscheinen. Bei 429 zuerst den Geschäftscode lesen, nicht reflexartig wiederholen.

Ein weiterer häufig übersehener Punkt ist der Wiederholungssturm. Wenn drei Dienste je viermal wiederholen, kann der Upstream ein Vielfaches der ursprünglichen Anfragen erhalten. Richtig sind begrenzte Parallelität im Client, Warteschlangen zur Glättung, exponentielles Backoff mit Jitter und ein Gesamtbudget für Wiederholungen im Gateway.

6. Key-Zugehörigkeit und Datengrenzen

Die häufigste Falle beim Relais ist der Key. Gemeinsame oder weiterverkaufte Keys und Kontingente unklarer Herkunft bringen vier Probleme: Bei einer Upstream-Sperre fällt der Betrieb mit aus; mehrere Kunden konkurrieren um dasselbe Limit; Anfrageinhalte laufen über Dritte, Logs und Aufbewahrung sind intransparent; die Bedingungen erlauben den Weiterverkauf möglicherweise nicht, im Streit fehlt die Grundlage.

Beim Anbieter mindestens prüfen: Firmenbetreiber, Leistungsbedingungen, Datenschutzerklärung, Rechnungsfähigkeit, Störungskontakt und Exit-Mechanismus. In stark regulierten Bereichen wie Finanzen und Gesundheit zuerst Direktanbindung, Private Deployment oder Anbieter mit unterzeichenbarem Datenverarbeitungsvertrag prüfen.

Eine weitere Grundregel: Den offiziellen Key nicht beim Relais aufladen oder verwalten lassen. Sobald der Key das Konto verlässt, sind Nutzung und Rechte nicht mehr kontrollierbar.

7. Migrationsschritte: immer nur eine Variable ändern

  1. Baseline erfassen: Erfolgsrate, P50/P95, Timeout-Rate, 429-Anteil, Tokenverbrauch pro 1.000 Anfragen und Rechnung.
  2. Abhängigkeiten erfassen: Modellnamen, thinking-Parameter, Tools, JSON-Ausgabe, Streaming und Bildeingaben.
  3. Neue Test- und Produktions-Keys anlegen, jeweils mit Obergrenze und Alarm.
  4. Nur base_url und api_key ändern und die minimale Anfrage in der Vorabumgebung testen.
  5. Mit echten Prompts wiedergeben und Ausgabequalität, Dauer und usage vergleichen.
  6. Fehlerzuordnung prüfen: Werden 401, 403, 429, 5xx und Timeouts korrekt erkannt?
  7. 5 bis 10 Prozent des Traffics grau schalten, 3 bis 7 Tage beobachten, den alten Zugang als Rückfall behalten.
  8. Nach der vollständigen Umstellung eine Woche weiter abgleichen, bis Rechnung, Nutzung und Logs übereinstimmen.

Ändern Sie nicht gleichzeitig Modell, Prompt und Gateway, sonst ist die Ursache nicht zuzuordnen.

8. Prüfliste: Ist ein Zugang verlässlich?

Prüfpunkt Vorgehen Warnsignal
Latenz denselben Prompt mehrfach senden, P50/P95 vergleichen starke Schwankung oder dauerhaft langsamer als direkt
Fehlerrate 429, 5xx und Timeouts zählen gehäufte Ausfälle zu Spitzenzeiten
Nutzung usage mit Backend-Rechnung vergleichen weicht ab, Streaming ohne usage
Modellidentität fester Testsatz für Fähigkeitsgrenzen und Stil deutliche Verschlechterung, kürzerer Kontext
Key-Isolation eigener Key, Rotation möglich? Angaben zur Key-Herkunft verweigert
Vertrag und Support Betreiber, Bedingungen, Rechnung, Reaktionszeit nur private Kontaktdaten, keine Bedingungen

Warnsignale: dauerhaft deutlich unter offiziellem Preis, Versprechen völliger Ausfallfreiheit, verweigerte Nutzungsdetails, Aufforderung zur Herausgabe des offiziellen Keys, unklarer Datenstandort. Bei einem dieser Punkte zuerst mit kleinem Traffic testen und nicht die Produktion auf einmal migrieren.

9. Wann Self-Hosting besser passt

Feste Ausgangs-IP, einheitliches Audit, Routing über mehrere Upstreams oder zwingend eigener Key sprechen für Self-Hosting. Üblich ist ein Reverse-Proxy mit Key-Verwaltung, Drosselung, Logs und Alarmen; Upstream bleibt das offizielle Konto oder ein konformer Anbieter.

Die Kosten vollständig rechnen: Server, Bandbreite, Zertifikate, Updates, Sicherheitspatches und Bereitschaft. Bei geringem Volumen und ohne Betriebsteam ist Self-Hosting oft teurer und umgeht die Upstream-Limits nicht.

10. Auswahl nach Rahmenbedingungen

  1. Zuerst Netzwerk und Zahlung: Ist der offizielle Zugang stabil und aufladbar, direkt anbinden.
  2. Dann Kontrolle: Werden fester Ausgang, Audit und private Keys benötigt, Self-Hosting prüfen.
  3. Dann Modellbereich: Mehrere Modelle über einen Zugang, verwaltetes Gateway prüfen.
  4. Zuletzt Service: Betreiber, Bedingungen, Rechnung, Support und Datenpolitik.

Für einen einheitlichen Zugang können Sie beim ZSQH AI Gateway einen Test-Key anlegen und zuerst testen, dann migrieren; verfügbare Modelle und Abrechnung stehen unter Modellpreise. „Günstig“ sollte nicht das einzige Kriterium sein.

11. Häufige Fragen (FAQ)

1. Worin unterscheiden sich Relais und Proxy?

Ein Proxy ist meist eine Weiterleitung auf Netzwerkebene und löst nur die Erreichbarkeit; ein Relais umfasst zusätzlich Konto, Abrechnung oder Key-Verteilung. Vor Vertragsabschluss Grenzen und Key-Zugehörigkeit klären.

2. Kann ein Relaispreis unter dem offiziellen Preis seriös sein?

Er kann aus Großeinkauf, Leitungssubventionen oder Kontingentweiterverkauf stammen, aber auch mit gemeinsamem Key und Instabilität einhergehen. Zuerst Abrechnungsgrundlage, Nutzungsdetails und Bedingungen prüfen, dann mit kleinem Traffic testen.

3. Wie erkennt man, ob ein Relais das Modell austauscht?

Das model-Feld allein reicht nicht, es kann umgeschrieben werden. Mit einem festen Testsatz Fähigkeitsgrenzen, Kontextlänge, Ausgabestil und usage-Struktur vergleichen und die Direktanbindung als Referenz behalten.

4. Wie viel Code muss für die Migration zum Gateway geändert werden?

Bei den meisten OpenAI-SDK-Projekten nur base_url und api_key; Modellnamen werden anhand der Preisseite angepasst. Bei thinking, Tools oder speziellen Antwortfeldern sind Kompatibilitätstests nötig.

5. Wann sollte man einen eigenen Proxy betreiben?

Bei festem Ausgangs-IP, einheitlichem Audit, Multi-Upstream-Routing oder wenn Compliance den eigenen Key verlangt. Bei geringem Volumen und ohne Betriebsteam ist Self-Hosting meist teurer.

Weiterlesen