AI Gateway Pattern auf Azure: Zentraler LLM-Zugriff, Rate Limiting und Kostenkontrolle

Wenn ein Team mit Azure OpenAI experimentiert, ist Governance einfach. Wenn zehn Teams gleichzeitig produktive KI-Features bauen, folgt Chaos: unvorhersehbare Kosten, keine Nutzungsvisibilität, inkonsistente Content-Safety-Policies und keine Möglichkeit nachzuverfolgen, welche Anwendung welche Tokens generiert hat.

Das AI Gateway Pattern löst dies durch Zentralisierung des LLM-Zugriffs über einen verwalteten Proxy — typischerweise Azure API Management.

Warum Sie ein AI Gateway brauchen

Problem 1: Kostentransparenz — Ohne Gateway erscheinen Azure OpenAI-Kosten als einzelne Zeile. Sie können nicht beantworten, welches Team wie viele Tokens verbraucht hat.

Problem 2: Rate Limiting — Ohne Gateway kann ein Batch-Job eines Teams die gesamte Quote erschöpfen und andere Teams blockieren.

Problem 3: Compliance — Verschiedene Workloads erfordern möglicherweise verschiedene Content-Safety-Einstellungen und Logging-Policies.

Architektur

Anfrage-Fluss durch das AI Gateway

APIM Policy: Token-basiertes Rate Limiting

<policies>
    <inbound>
        <validate-jwt header-name="Authorization" 
                      failed-validation-httpcode="401">
            <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
        </validate-jwt>
        
        <azure-openai-token-limit 
            counter-key="@(context.Subscription.Id)"
            tokens-per-minute="100000"
            estimate-prompt-tokens="true" />
        
        <azure-openai-emit-token-metric namespace="AIGateway">
            <dimension name="Team" value="@(context.Subscription.Name)" />
            <dimension name="Application" value="@(context.Request.Headers.GetValueOrDefault("X-App-Name", "unknown"))" />
            <dimension name="Model" value="@(context.Request.MatchedParameters["deployment-id"])" />
        </azure-openai-emit-token-metric>
        
        <set-backend-service backend-id="openai-load-balancer" />
    </inbound>
</policies>

Load Balancing über Azure OpenAI Instanzen

<backend id="openai-load-balancer">
    <load-balancer>
        <backend-pool>
            <backend id="openai-eastus" priority="1" weight="50" />
            <backend id="openai-westeurope" priority="1" weight="50" />
            <backend id="openai-swedencentral" priority="2" weight="100" />
        </backend-pool>
    </load-balancer>
</backend>

Circuit Breaker für Resilienz

Wenn 50% der Anfragen an ein Backend fehlschlagen (429 Rate Limit oder 5xx), öffnet der Circuit Breaker für 30 Sekunden und leitet Traffic an andere Backends weiter.

Semantic Caching

Für wiederholte Abfragen (FAQ-Stil) reduziert Semantic Cache den Token-Verbrauch:

<inbound>
    <azure-openai-semantic-cache-lookup 
        score-threshold="0.95"
        embeddings-backend-id="embedding-backend" />
</inbound>
<outbound>
    <azure-openai-semantic-cache-store duration="3600" />
</outbound>

Implementierungsempfehlungen

1. Starten Sie mit APIM — Bauen Sie kein Custom Gateway. APIMsKI-spezifische Policies decken 90% der Anforderungen ab
2. Eine Subscription pro Team — Saubere Kostenzuordnung von Tag eins
3. Mehrere Azure OpenAI Instanzen deployen — In verschiedenen Regionen für Resilienz
4. Circuit Breaker aktivieren — Schutz gegen Kaskadenfehler bei Throttling
5. Alles loggen, Zugriff einschränken — Vollständiges Prompt-Logging für Compliance, striktes RBAC auf Log-Zugriff
6. Budget-Alerts setzen — Azure Monitor Alerts wenn Token-Verbrauch Schwellenwerte überschreitet

Müssen Sie ein AI Gateway für Ihr Unternehmen implementieren? Kontaktieren Sie uns — wir helfen Organisationen, LLM-Zugriff mit Kostenkontrolle, Compliance und Resilienz zu zentralisieren.