Fassaden hinein. Ein Modell hindurch.

Sechs Dinge, die erstklassig sind statt abgeleitet

In einem HTTP-geprägten Gateway werden diese aus einem Pfad, einem Header oder dem Verhalten eines Provider-SDK erschlossen. Hier sind es Felder eines Domänenobjekts — deshalb können Policy, Routing, Caching und Abrechnung einheitlich darüber urteilen.

Diese eine Entscheidung ist der Grund, warum Chat, Embeddings, Vision, Audio, asynchrone Video-Jobs und Realtime-Sitzungen einen gemeinsamen Pfad für Policy, Routing und Abrechnung nutzen statt sechs verschiedene.

Den Dialekt sprechen, die Wiedergabetreue behalten

Clients senden Anfragen im OpenAI-, Anthropic- oder Gemini-Format oder direkt im nativen Inference-Request-Format. Native Adapter erhalten anbieterspezifisches Verhalten — Tool-Calling, Vision, strukturierte Ausgaben —, statt alles über ein Format zu vereinheitlichen und dabei Funktionalität an den Rändern zu verlieren.

Neun Stufen in fester Reihenfolge

Jede Anfrage durchläuft dieselben Stufen. Identität, Modellzugriff und Budget werden aufgelöst, bevor irgendetwas aufgerufen wird; die Eingabe-Policy läuft vor dem Cache, sodass auch eine gecachte Antwort geprüft ist; das Routing wählt das Deployment; Ausgabe- und Werkzeug-Policy laufen auf der Antwort; Kosten, Bewertungen und Nachweise fallen auf dem Rückweg an.

1. 01
   Authentifizieren

   Virtueller Key, Agenten-Token oder ein Unternehmens-IdP-Token auf /v1 (Enterprise). Löst Org, Team, Nutzer, Anwendung und Agentenlauf auf.

   ✗ 401
2. 02
   Modellzugriff

   Modellfreigaben, eingeengt durch die Whitelist des Keys, entscheiden, welche Aliase diese Identität aufrufen darf.

   ✗ 403
3. 03
   Budget

   Ratenlimits und Budgets werden auf Key, Org, Team, Nutzer, Anwendung und Modell reserviert. Alle müssen bestehen.

   ✗ 429 — keine Anbieterkosten
4. 04
   Policy (vor dem Aufruf)

   Geordnete Guardrail-Kette auf der Eingabe: PII, Injection, Moderation oder Ihr eigener Webhook. Der Cache sieht den maskierten Prompt.

   ✗ BLOCKIEREN · ◑ MASKIEREN · ◐ SCHWÄRZEN
5. 05
   Cache

   Exakt → kanonisch → Near-Dup → semantisch, jede Stufe gegen Falschtreffer abgesichert. Ein Treffer überspringt den Anbieter und die Ausgabestufen.

   ✓ TREFFER → zurück, kein Anbieteraufruf
6. 06
   Routing

   Fähigkeitsfilter, Residenz, Sitzungsaffinität, dann wählt die Routing-Strategie das Deployment. Ein Failover verlässt nie die erlaubten Rechtsräume.

7. 07
   Aufrufen

   Anbieterdialekt, echtes SSE-Streaming, Failover innerhalb des Alias, dann geordnete Fallbacks; jeder Versuch schreibt einen Egress-Eintrag in den Ledger. Policy während des Streams läuft auf einem gleitenden Fenster.

8. 08
   Policy (nach dem Aufruf)

   Ausgabe-Guardrails laufen auf der vollständigen Antwort. Werkzeugaufrufe, die das Modell zurückgibt, beurteilt die Werkzeug-Policy: zugelassen, mit Hinweis entfernt oder abgelehnt.

   ✗ 403 · entfernt
9. 09
   Abrechnen

   Budgets werden abgerechnet, der Ledger hält das Ergebnis fest, und Tokens, Kosten, Bewertungen und die Routing-Entscheidung landen als Anfrage-Logs, OTEL-Traces und Prometheus-Metriken.

Ein Proxy leitet eine Anfrage weiter. Dies entscheidet, was die Anfrage sein darf — und genau darin besteht der Unterschied zwischen Gateway und Control Plane.

Vier Lebenszyklen, ein Policy-Pfad

Weil der Lebenszyklus ein Feld der Anfrage ist und kein Implementierungsdetail eines Endpunkts, gilt für alle vier dieselbe Governance.

Das ist der Teil, den ein HTTP-geprägtes Gateway ohne Neuentwicklung nicht nachrüsten kann. Der Lebenszyklus muss im Domänenmodell liegen, bevor Policy einheitlich darauf wirken kann.

Vier Ebenen, bewusst getrennt

Kubernetes-nativ, nicht Kubernetes-kompatibel

Alles in einem Container ist Kubernetes-kompatibel. Nativ heißt, dass die Plattform das Ding modelliert, das Sie betreiben: Wäg liefert einen eigenen Operator und eigene Custom Resources, sodass das Gateway ein Objekt ist, das der Cluster versteht, statt eines Deployments, das jemand zusammengesteckt hat. Eine WaegInstance verantwortet die Deployments, das Networking, das Autoscaling und das Monitoring des Gateways und meldet eine Fehlkonfiguration als Condition mit Begründung; Anbieter, Modelle, Organisationen, Budgets, Guardrails und Keys können ebenfalls Custom Resources sein. Weil Budgets und Ratenlimits über Redis geteilt und nicht pro Replica gehalten werden, gibt Skalierung nie ein Budget doppelt aus — und der Operator markiert eine Instanz mit mehreren API-Replicas ohne Redis als nicht bereit. Vorausgesetzt sind Kubernetes 1.28 oder neuer oder OpenShift 4; wer lieber templatet als betreibt, nutzt das Helm-Chart.

Rust in der Data Plane

Gebaut auf tokio, hyper und axum mit Zero-Copy-Streaming, ausgeliefert als eine distroless Binary ohne Root. Kein Interpreter, kein Paketmanager, keine Node-Laufzeit im Gateway — die Admin-Konsole wird von derselben Binary ausgeliefert. Im heißen Pfad gibt es keinen ML-Router, Routing kostet also deterministische Analyse statt Modellinferenz.

Was Wäg nicht ist

Klar benannt, damit Sie es auf der richtigen Achse bewerten und niemand ein Briefing mit falschen Erwartungen bucht.

• Kein Inference-Server. Es führt keine Modelle aus. Es routet zu denen, die Sie ohnehin nutzen, einschließlich selbst gehosteter vLLM- oder Ollama-Endpunkte, und Wäg Edge steuert Modelle, die auf den Rechnern und in den mobilen Apps Ihrer Mitglieder laufen.
• Kein Modell-Hosting. Keine Gewichte, keine GPUs, keine Fine-Tuning-Pipeline.
• Keine Vektordatenbank. Es leitet Embedding-Aufrufe weiter und cached semantisch; es speichert Ihren Korpus nicht.
• Kein Observability-Backend. Es liefert OTEL und Prometheus an das, was Sie ohnehin betreiben.
• Kein Ersatz für ein API-Gateway. Kong und Envoy steuern HTTP. Wäg steuert Tokens, Modelle und Aktionen von Agenten. Das sind ergänzende Schichten, und die meisten Landschaften betreiben beide.

Die Control Plane ansehen · Zu den Benchmarks