FAQ zu KI-Gateways

Nur wenn das Gateway pro Instanz lizenziert ist, statt Token aufzuschlagen. GateLLM wird pro 2-GB-Instanz lizenziert (Pro $400/Monat) — nie ein Aufschlag pro Token, kein Plattform- oder Zahlungszuschlag; Sie zahlen Anbieter zu Standardtarifen. Die echte Ersparnis kommt aus Composition: Ein Topmodell (Claude Opus) plant, während offene SOTA-Modelle (GLM / Qwen / DeepSeek) ausführen — zu ~1/7 der Kosten. SaaS-Aggregatoren erheben typischerweise ~5–8 % Plattform- + Zahlungsgebühren: ein erheblicher versteckter Kostenfaktor bei Volumen.

Ehrliche Messlatte: ein Anbieter, ein Team, keine Compliance-Vorgabe, überschaubare Monatsausgaben — direkte API-Aufrufe sind einfacher, und Sie brauchen kein Gateway. Ein Gateway beginnt sich zu rechnen, wenn Sie Multi-Anbieter-Failover, Kostenzuordnung pro Team, Compliance / Datenresidenz oder Echtzeittransparenz bei außer Kontrolle geratenen Ausgaben brauchen. Führen Sie keines ein, bevor Sie es wirklich brauchen.

Der direkte Weg zu einem Anbieter ist ein Single Point of Failure — ein Ausfall legt Ihre gesamte App lahm. GateLLM unterstützt anbieterübergreifendes Fallback: Wenn der primäre Anbieter 5xx zurückgibt oder in einen Timeout läuft, wechselt der Datenverkehr ohne Codeänderung zu einem Backup-Anbieter. Für wichtigere Aufrufe können Sie außerdem ein Multi-Modell-Code-Review in Ihrer Orchestrierungsebene betreiben (z. B. paralleles Review in GitHub Actions) — das Gateway liefert die Protokoll-Interoperabilität, damit mehrere Modelle dieselbe Anfrage prüfen.

Ein SaaS-Gateway fügt einen zusätzlichen Sprung aus Ihrem Netzwerk hinaus hinzu. GateLLM wird selbst gehostet in Ihrer VPC betrieben; der zusätzliche Sprung zur Anbieter-API ist lokale Interprozess-Kommunikation — submillisekunden Overhead mit vernachlässigbarem Einfluss auf die Streaming-Zeit bis zum ersten Token.

Ja. GateLLM Composition unterstützt modusbewusste Richtlinien: Administratoren sperren Plan-/Ausführungsstufen — Topmodelle für Planung, Open-SOTA für Ausführung — für ~97 % Leistungsfähigkeit zu ~14 % Kosten. Sie können auch nach Token-Anzahl oder Komplexität klassifizieren, um dynamisch zu routen und zu verhindern, dass der gesamte Datenverkehr auf dem teuersten Modell läuft.

Ein schlechter Proxy tut das: Er puffert den Stream, bricht tool_calls-JSON-Fragmente oder stolpert über anbieterübergreifende Formatunterschiede bei Tool-Aufrufen. GateLLM reicht Streams nativ ohne Pufferung durch und betreibt Capability-Normalisierung — vereinheitlicht Tool-Aufrufe, strukturierte Ausgaben, Prompt-Cache, Reasoning-Token und drei weitere anbieterübergreifende Kopplungspunkte hinter einer Schnittstelle, sodass anbieterübergreifendes Modell-Mixing nie an Formatdrift scheitert.

Ein Relay leitet Ihre Anfragen über seine eigenen Server weiter — Ihre Prompts, Schlüssel und Ausgaben sind ihm alle ausgesetzt, mit echten Risiken von Modellsubstitution, Verschlechterung oder dem Verschwinden des Betreibers (eine CISPA-Studie fand Identitätsprüfungsfehler in 45,83 % der Modell-Fingerprint-Tests, arxiv.org/abs/2603.01919). GateLLM ist BYOK und selbst gehostet: Schlüssel liegen nur im Speicher des Gateways, Anfragen gehen direkt an Anbieter-APIs, kein Dritter im Pfad — es gibt keinen Raum für Substitution, Verschlechterung oder Verschwinden.

Ja. GateLLM wird vollständig in Ihrem Netzwerk bereitgestellt — Daten verlassen es nie, was Datenexport-Compliance erfüllt. Es spricht nativ das DashScope-Protokoll, um inländische Modelle zu erreichen (Tongyi / Zhipu / DeepSeek / Doubao). Der Datenverkehr zu geschlossenen Modellen wird über Composition reduziert, was grenzüberschreitende Aufrufe verringert.

Monatsrechnungen kommen zu spät. GateLLM Token Ops ordnet Kosten pro Anfrage zu — nach Team / Agent / Modell / Client — mit Echtzeittransparenz der Abbaurate und Budgetobergrenzen pro Agent, die Aufrufe tatsächlich stoppen. Die absturzsichere Abrechnung (Vorabzug → Abrechnung → Rückerstattung) bleibt auch bei Prozessabstürzen korrekt; die Management-API exportiert Abstimmungsdaten in Ihr internes Abrechnungssystem.

Bei einem SaaS-Aggregator können Sie nur seinem Wort vertrauen — es gibt keine kryptografische Bestätigung, dass er nicht stillschweigend ein kleineres Modell einsetzt, um die Marge einzustecken (OpenRouter selbst führt keine Modellidentitätsprüfung durch). GateLLM ist BYOK und selbst gehostet: Sie nutzen Ihre eigenen Schlüssel, und Anfragen gehen von Ihrem Gateway direkt an den API-Endpunkt des Anbieters — die Modellidentität wird von der Anbieter-API selbst garantiert, ohne austauschbaren Sprung dazwischen.

Ja. Richten Sie die base_url Ihres OpenAI SDK auf GateLLM (mit /v1) — keine weiteren Codeänderungen — und rufen Sie jedes Modell über eine einheitliche Schnittstelle auf. Ein base_url-Wechsel schließt die Migration ab: keine Funktionsdrift, kein Proxy-Shim — Ihr OpenAI-Client steuert direkt einen anbieteräquivalenten einheitlichen Endpunkt.

Nein — ein Gateway bedient alle drei. Richten Sie die base_url des OpenAI SDK auf das Gateway (mit /v1); richten Sie das Anthropic SDK auf die Gateway-Wurzel (das SDK hängt /v1/messages selbst an, Schlüssel über den Header x-api-key); das Google Gemini SDK verbindet direkt (Schlüssel über den Header x-goog-api-key). Das Gateway übersetzt bidirektional über vier Eingangs- + vier Ausgangsprotokolle (OpenAI / Anthropic / Gemini / DashScope) — Client- und Upstream-Protokoll dürfen sich unterscheiden: Claude aus dem OpenAI SDK, GPT aus dem Anthropic SDK oder DeepSeek aus dem Gemini SDK ohne Codeänderungen aufrufen; Drittanbieter-Clients wie Cherry Studio nutzen den OpenAI-kompatiblen Eingang. Siehe die Protokoll-Interop-Matrix unter docs.gatellm.io reference/protocol-matrix.

Ja. Bedrock verbindet als Upstream (aws_converse / aws_invoke-Protokoll, Bedrock-API-Schlüssel + regionaler Runtime-Endpunkt, Inference-Profile unterstützt); Clients nutzen weiterhin die OpenAI-/Anthropic-/Gemini-SDKs, und das Gateway übersetzt das Protokoll. Auf Bedrock gehostete Claude-/GLM- und Direktanbieter-Modelle können im selben Routing / Load Balancer unter einer Governance-Ebene gemischt werden.

Ja. Das Gateway hat einen integrierten MCP-Proxy: Er bündelt mehrere externe MCP-Tool-Server (streamable HTTP / SSE) hinter einem /mcp-Endpunkt, sodass Claude Desktop oder jeder MCP-Client sie alle mit einem einzigen Gateway-Schlüssel aufruft. Tool-ACLs und Kontextbudgets je Key-Gruppe steuern den Zugriff, mit integrierter BM25-Suche, wenn die Tool-Liste lang wird. Tool-Zulassung, Ratenbegrenzung und Audit teilen dieselbe Governance-Ebene wie der Modell-Datenverkehr.

Ja. Das Gateway überbrückt WebSocket-Sitzungen unter /v1/realtime (OpenAI Realtime und DashScope Realtime). Langlebige Sprachsitzungen laufen parallel zum HTTP-Datenverkehr: gleiche Schlüsselauthentifizierung und -zulassung, pro Turn eingemessen (response.create → response.done) in dieselbe Statistik-/Abrechnungs-/Log-Pipeline wie HTTP — ein konsistentes Kosten-Ledger.

Fünf Ebenen: Key-Gruppen begrenzen, welche Modelle und Load Balancer jeder Mandant erreichen kann; Zugriffsschlüssel + Header-ACL-Regeln unterscheiden Clients nach Anfrage-Header; identitätsbezogene Modellzuordnung leitet denselben Modellnamen zu unterschiedlichen Upstreams je Mandant; RPM-/Parallelitäts-/TPM-Limits pro Schlüssel begrenzen die Nutzung; und die Kostenzuordnung pro Anfrage sorgt dafür, dass jeder Mandant nur seine eigenen Ausgaben sieht. Siehe die Anleitung zur Mandantentrennung unter docs.gatellm.io usecases/multi-tenant-isolation.

Ja. GateLLM fängt die Suche auf Gateway-Ebene ab: Konfigurieren Sie eine Suchmaschine (serper, inline in der Konsole testbar), dann steuern Dreifach-Umschalter pro Modell (Capability folgen / erzwingen an / erzwingen aus) die Injektion. Ergebnisse werden je Client-Protokoll in native Suchblöcke synthetisiert (Anthropic server_tool_use / OpenAI url_citation / Responses web_search_call) — auch offene Modelle erhalten Suchgrundlage. Suchfehler degradieren sanft, ohne Anfragen zu blockieren, und abgefangene Suche ist von der nutzungsbasierten Abrechnung ausgenommen. Siehe console/search unter docs.gatellm.io.

Ja. Ein Upstream kann mehrere API-Schlüssel mit gewichteter Verteilung halten: Ein deterministischer gewichteter Hash (FNV-1a) bindet jeden Aufrufer fest an denselben Schlüssel (Cache-Affinität), und wenn ein Schlüssel ausfällt, wiederholt das Gateway den Versuch mit dem nächsten unversuchten Schlüssel innerhalb dieses Upstreams. Schlüssel mit weight=0 sind Standby — sie werden erst genutzt, nachdem jeder Schlüssel mit weight>0 ausgefallen ist. Der Bindungsstatus ist Zeile für Zeile in der Konsole sichtbar. Siehe reference/upstreams-models-fields unter docs.gatellm.io.

Ja. Jeder OpenAI-kompatible Endpunkt funktioniert als Upstream: Legen Sie eine benutzerdefinierte Basis-URL fest, und vLLM-/Ollama-/TGI-Dienste werden neben Cloud-Anbietern governiert. Ausgehende Proxys (socks5 / http), benutzerdefinierte Anfrage-Header und DNS pro Upstream sind für private Netze und spezielle Topologien konfigurierbar.

Kein YAML erforderlich. GateLLM liefert eine visuelle Konsole: Upstreams / Modelle / Load Balancer / Zugriffskontrolle / MCP / Statistiken / Logs werden alle per GUI konfiguriert, mit sofortigem Wechsel zwischen Chinesisch und Englisch. Batch-Änderungen durchlaufen vorbereiten → Vorschau (vollständiger Namensraum-Konfliktsatz) → atomare Übernahme, wobei der gesamte Batch bei jedem Konflikt zurückgerollt wird. Konsolenkonten gibt es in den Rollen Administrator / Monitor (schreibgeschützt), und jeder Vorgang und Login wird auditiert.

LiteLLM ist ein ausgezeichneter Open-Source-LLM-Proxy. GateLLM und LiteLLM teilen eine Capability-Basis (Routing, Tool-Aufrufe, strukturierte Ausgaben, Caching, SSO über OIDC + SAML 2.0 + SCIM). GateLLMs Differenzierungsmerkmale sind das einzelne Rust-Binary, 15 Protokollformen (die 4 Chat-Protokollfamilien übersetzen von jedem zu jedem, der Rest gemäß Interop-Matrix), gatewayseitige automatische Cache-Injektion und eine YAML-freie Konsole; LiteLLM führt bei seinem Enterprise-Ökosystem (Secret Manager, Guardrail-Callbacks von Drittanbietern, Observability-Callbacks). Siehe /compare/litellm.

Ja. Vollständig selbst gehostet in Ihrer VPC; BYOK-Schlüssel nur im Speicher, nie auf der Festplatte; Enterprise-SSO (OIDC: Azure AD / Okta / generisch, plus SAML 2.0 und SCIM-2.0-Auto-Provisioning); Audit-Logs auf Anfrageebene, exportierbar; DSGVO-ready; ausgerichtet an SOC-2-Type-II-/ISO-27001-Kontrollen (Zertifizierung in Vorbereitung). Siehe /security.

Erstellen Sie in Konsole → Einstellungen → Abrechnung einen manuellen Preis-Snapshot für das Modell — er wird als gepinnt markiert (gelbes Abzeichen). Ein gepinnter Preis wird aktuell und überdeckt die automatische Basis darunter; Systemaktualisierungen überspringen dieses Modell und überschreiben Ihren manuellen Preis nie. Beim Löschen fällt es auf die nächste automatische Zeile zurück und heilt sich selbst.

Nein. Preis-Snapshots sind nach created_at geordnet, und jeder deckt nur sein eigenes [eigener Zeitpunkt, nächster Zeitpunkt)-Fenster ab — der früheste füllt die Historie auf, der letzte verlängert sich unbegrenzt nach vorn. Erstellen Sie einen neuen Snapshot mit zukünftigem Wirksamkeitszeitpunkt, um die Senkung vorzuplanen, sodass sie nur spätere Monate betrifft, oder tragen Sie einen historischen Preis nach, um vergangene Monate präzise zu berechnen.

Setzen Sie ein tägliches / monatliches Kostenkontingent (USD-Betrag) auf dem Zugriffsschlüssel — zwei unabhängige Zyklen, beurteilt nach UTC-Kalendertag und -monat, die 429 quota_exceeded zurückgeben und den Dienst stoppen, sobald einer erreicht ist (das Tagesfenster trägt Retry-After). Kontingente erben Schlüssel → Gruppe → global; ein Gruppenkontingent ist eine Obergrenze pro Schlüssel innerhalb der Gruppe (kein gemeinsames Ledger), und über Gruppen hinweg gewinnt das weiteste.