Was ist ein API-Proxy: Prinzip, Risiken & Checkliste

Der Weg eines Requests durch den Proxy

Klärung der Begriffe: Ein „Proxy-API“ ist ein Gateway zwischen deiner App und dem Backend. Dein Code sendet weiterhin im OpenAI-Format, nur zeigt base_url auf das Gateway und du nutzt dessen Key.

Das Gateway erledigt drei Aufgaben.

• Request-Weiterleitung: Validierung, Ergänzung von Defaults und Weiterleitung an das Backend. Die Antwort (inkl. SSE-Streaming) wird an dich zurückgegeben.
• Key-Mapping: Dein Key ist nur im Gateway gültig. Er identifiziert dich, dein Guthaben und deine Modelle. Die Credentials zum Backend bleiben intern.
• Abrechnung & Ratenlimits: Abzug des Guthabens basierend auf Input/Output-Token. Zählung der Requests pro Minute pro Key. Überschreitung führt zu 429.

Wenn du diese drei Punkte zusammen betrachtest, wird klar, warum sich die Proxy-Erfahrung stark unterscheidet: Die Implementierung der Weiterleitungsschicht bestimmt Latenzschwankungen und die Stabilität des Streamings, die Schlüsselschicht bestimmt das Schadensausmaß bei einem Leak, und die Abrechnungsschicht bestimmt, ob die Rechnungen transparent und nachvollziehbar sind.

Unterschied zu direktem Single-Modell-Zugriff

Bei einer direkten Verbindung sendest du Anfragen an die offizielle Domain des Modellanbieters. Normalerweise entspricht ein Konto einem Satz von Modellen, einem Abrechnungsmodell und einer Dokumentation. Vermittelte Dienste haben zwei gängige Formen, die sich darin unterscheiden, „wie viele Dienste dahintergeschaltet sind“.

Dimension	Direkter Single-Dienst	Aggregierter Proxy	Single-Modell-Proxy
Modellanzahl	Einige der eigenen Modelle des Anbieters	Dutzende bis Hunderte	Eines
Schnittstellenformat	Anbieterspezifisch	Einheitlich OpenAI-kompatibel	OpenAI-kompatibel
Fehlersuche	Geringste, kurze Kette	Höchste, viele Mapping-Regeln	Gering, nur ein Modell
Anwendungsfälle	Stabiler Betrieb eines Anbieters	Häufiger Modellwechsel zum Vergleich	Festes Modell, Vorhersagbarkeit

Bei nur einem Modell nutzt du die Aggregation nicht, sondern riskierst Unsicherheit beim Mapping. Bei häufigem Wechsel spart Aggregation Arbeit. Es gibt kein absolutes Gut oder Böse.

Diese Seite bietet nur ein Modell mit der ID uncensored und einer OpenAI-kompatiblen Chat-Vervollständigungs-API. Für Diskussionen zu Kompromissen und Kosten sieh dir Kosten und Kompromisse bei unbegrenzten KI-APIs an.

Drei häufige Risiken

Key-Sicherheit

Der Proxy-Key ist wie eine Prepaid-Karte: Wer ihn hat, gibt dein Guthaben aus. Risiken: Key im Frontend, in Repos oder Chats. Lösung: Nur Server-Umgebungsvariablen, Frontend leitet über Backend weiter. Bei Leak sofort zurücksetzen und sofortiges Inaktivieren prüfen.

Modell-Ersatz

Das meistdiskutierte Problem bei Aggregatdiensten: Du fragst A an, erhältst aber billigeres B. Das lässt sich schwer an Dokumenten erkennen, sondern nur durch Verhaltenstests. Nutze Fragen mit Standardantworten und fixiere temperature, um die Stabilität zu prüfen. Prüfe auch /v1/models auf Übereinstimmung mit der Abrechnungsseite.

Intransparente Limits

Manche Dienste drosseln im Peak oder verwerfen Requests, was zu Timeouts führt. Gute Dienste geben Ratenlimits pro Key an und senden bei Überschreitung eine normierte 429. Prüf: Limit pro Key oder Account? Fehlercode bei Limit? Fehlercode bei leerem Guthaben?

Checkliste zur Auswahl eines Proxy-Dienstes

Diese Liste kannst du direkt in deine Bewertungsdokumentation kopieren und Punkt für Punkt abhaken.

1. Wird ein öffentliches GET /v1/models bereitgestellt, dessen Modellliste mit der Preisliste übereinstimmt?
2. Sind Fehlerantworten strukturiertes JSON mit code und message, und sind 401, 402, 429 und 503 klar voneinander unterschieden?
3. Ist das pro Schlüssel erlaubte Anfragevolumen pro Minute in der Dokumentation festgehalten und nicht nur mündlich mitgeteilt?
4. Gibt es klare Zahlen für die Kontextlänge, die maximale Token-Anzahl pro Antwort und die Größe des Anfragekörpers?
5. Wird der Betrag exakt nach der Token-Anzahl im usage-Feld abgezogen, und lässt sich der Kontostand jederzeit einsehen?
6. Verfällt das Prepaid-Guthaben? Ist die Gültigkeitsdauer des kostenlosen Testguthabens klar angegeben?
7. Kannst du den Schlüssel selbst zurücksetzen, und wird der alte Schlüssel sofort ungültig?
8. Wird das Streaming unterstützt, und enthält die letzte Antwort die usage-Statistik, damit du die Abrechnung selbst prüfen kannst?
9. Gibt es eine klare Aussage dazu, ob Prompts zum Training verwendet werden?
10. Werden nicht unterstützte Fähigkeiten (z. B. Vektoren, Bilder, Audio) ehrlich gekennzeichnet und nicht vage beschrieben?

Perfekt ist unrealistisch, aber wenn du bei den ersten fünf Punkten zwei Fragen nicht beantworten kannst, solltest du zunächst mit einem kleinen Betrag testen, statt sofort ein großes Guthaben aufzuladen.

Die 10-Minuten-Verifizierung nach Erhalt des Schlüssels

Egal welchen Anbieter du wählst, vor dem Live-Gang lohnt sich eine 10-minütige Basisverifizierung. Schritt 1: Liste die Modelle auf und prüfe, ob die zurückgegebenen IDs deinen Erwartungen entsprechen:

复制curl -s https://api.llmzhongzhuan.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

Schritt 2: Sende eine kleine Anfrage und beobachte, ob das usage-Feld in der Antwort vorhanden ist und die Werte plausibel sind. Das folgende Beispiel lässt das Modell das Datum wiederholen, um zu prüfen, ob es Informationen erfindet, die es nicht wissen kann. Dies ist eine grobe Verhaltensprüfung, keine strenge Evaluation:

复制curl -s https://api.llmzhongzhuan.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "用一句话介绍你自己，然后复述今天的日期是几号。"}],
    "max_tokens": 200
  }' 

Nimm diese beiden Schritte in deine Deployment-Skripte auf und führe sie bei jedem Schlüssel- oder Anbieterwechsel aus. Wenn die Antwort kein usage-Feld enthält oder die usage-Werte deutlich von der Eingabelänge abweichen, deutet das auf mangelnde Abrechnungstransparenz hin. Kläre das vor einer größeren Aufladung. Für Anleitungen zur Integration in verschiedene Frameworks sieh dir den Framework-Konfigurationsleitfaden an.

Parameter dieses Dienstes zum Abgleich mit der Checkliste

Hier sind die tatsächlichen Parameter dieses Dienstes aufgeführt, damit du die obige Checkliste direkt abgleichen kannst, ohne ständig in der Dokumentation hin- und herwechseln zu müssen.

• API-Endpunkt: https://api.llmzhongzhuan.com/v1, unterstützt POST /v1/chat/completions und GET /v1/models, Authentifizierung über Bearer-Schlüssel.
• Nur ein Modell mit der id uncensored; nur Text, keine Vektoren, Bilder, Audio, Video oder Fine-Tuning.
• Das Kontextfenster umfasst 100.000 Token (Input plus Output), max_tokens beträgt standardmäßig 2048, maximal 32.000; der Anfragekörper darf 8 MB nicht überschreiten.
• Jeder Schlüssel erlaubt 300 Anfragen pro Minute; bei Überschreitung wird 429 zurückgegeben; 503 upstream_busy bedeutet, dass du es später erneut versuchen solltest; wenn das Guthaben aufgebraucht ist oder das Testguthaben abgelaufen ist, wird 402 no_credit zurückgegeben.
• Der Preis beträgt 0,25 USD pro Million Input-Token und 1,00 USD pro Million Output-Token. Prepaid-Aufladung, kein Abonnement, das Guthaben verfällt nie.
• Prompts werden nicht zum Training verwendet.

Die genauen Werte findest du auf der Preisliste und in der Dokumentation. Neue Konten erhalten 0,50 USD Testguthaben mit einer Gültigkeitsdauer von 7 Tagen. Für die Registrierung sind keine Zahlungsinformationen erforderlich; du kannst damit zunächst den oben beschriebenen Verifizierungsprozess durchlaufen.