Eine große Unternehmens-IT-Organisation hat fünf generative KI-Anwendungen in Produktion, elf Modell-Deployments verteilt über drei Azure-Subscriptions, eine Monatsrechnung von rund 38.000 Euro und keine verlässliche Möglichkeit zu sagen, welche der fünf das Geld ausgegeben hat. Nichts ist kaputt. Jede App funktioniert, jedes Team hat geliefert, jedes Security-Review wurde seinerzeit bestanden. Was nicht existiert, ist ein einziger Ort, an dem ein Token gezählt, ein Aufrufer identifiziert oder ein Modell außer Betrieb genommen wird, und genau diese Lücke schließt diese zehnteilige Serie: ein zentral verwaltetes GenAI-Gateway auf Azure, durch das jede Anwendung geht und an dem keine vorbeikommt.

Das Unternehmen, und was es tatsächlich bezahlt

Nennen wir es beim Namen: eine etablierte Unternehmens-IT-Organisation, rund 400 Entwickler in etwa 40 Produktteams, die meisten Workloads auf Azure, eine Plattform-Gruppe, die bereits die Landing Zones und die CI-Templates besitzt. Generative KI kam so, wie sie üblicherweise kommt: von den Rändern nach innen. Ein Kundenservice-Assistent ging zuerst live, weil ein Product Owner Budget hatte. Dann ein Summarizer für den IT-Betrieb, ein interner Code-Assistent, eine Retail-Wissenssuche über die Produktdokumentation und ein Marketing-Copy-Tool. Fünf Teams, fünf Entscheidungen, fünf direkte Integrationen gegen Azure OpenAI.

Jede dieser Entscheidungen war für sich genommen richtig. Zusammen ergeben sie ein spezifisches und inzwischen vertrautes Bild:

  • Elf Modell-Deployments über drei Subscriptions. Zwei davon sind Duplikate desselben Modells in derselben Region, angelegt, weil ein Team keine Quota an die Ressource gebunden bekam, die es bereits hatte.
  • Rund 38.000 Euro pro Monat an Modellkosten, die das Cost Management auf Subscription-Ebene ausweist. Es kann der Finanzabteilung also die Summe nennen, aber keinem Product Owner seine eigene Zahl.
  • Vier der fünf Apps halten einen Key in den Application Settings. Eine hielt ihn in einem Repository, bis ein Secret-Scanner ihn fand. Keine App lässt sich einzeln sperren, ohne dass ein Entwickler die Konfiguration genau dieser App anfasst.
  • Eine 60-Tage-Ankündigung zur Modellabschaltung kam per E-Mail, und die Plattform-Gruppe verbrachte zwei Tage damit, Repositories zu greppen, um herauszufinden, welche Anwendungen brechen würden, weil nirgendwo festgehalten war, welche App welche Modellversion aufruft.

Dann der Vorfall, der die Entscheidung tatsächlich erzwang. Ein Batch-Job im Marketing-Copy-Tool verbrauchte rund vierzig Minuten lang den Großteil der tokens-per-minute-Quota auf einem geteilten Deployment. Der Kundenservice-Assistent, der dasselbe Deployment nutzte, begann, echten Kunden HTTP 429 zurückzugeben. Keines der beiden Teams hat etwas falsch gemacht. Es gab im Pfad keinen Mechanismus, in dem sich "ein Aufrufer darf die Quota nicht erschöpfen, von der ein anderer abhängt" hätte ausdrücken lassen, weil es überhaupt keinen gemeinsamen Pfad gab.

Das ist das ehrliche Argument für ein Gateway. Nicht "zentrale Kontrolle ist gute Architektur". Sondern: Quota, Kostenzuordnung, Credential-Rotation und Modell-Lifecycle sind allesamt Eigenschaften des Aufrufs, und wenn keine Komponente jeden Aufruf sieht, lässt sich keine davon irgendwo durchsetzen, außer per Konvention.

Was das Pro-App-Muster wirklich kostet

Direkte Integration ist am ersten Tag tatsächlich billiger. Ein SDK-Client, ein Key, ein Endpoint, kein Platform-Team im kritischen Pfad. Die Kosten kommen später und landen woanders als bei dem Team, das sich dafür entschieden hat, und genau deshalb wird dieses Muster immer wieder gewählt.

Die sich aufsummierenden Kosten sind drei, und alle drei sind dieselben Kosten in verschiedenen Verkleidungen. Änderungskosten: Eine Modellabschaltung, eine Preisänderung, eine Regionsmigration oder ein Anbieterausfall muss einmal pro Anwendung behandelt werden, von fünf Teams mit fünf Backlogs und fünf verschiedenen Graden von Interesse. Zuordnungskosten: Ausgaben sind pro Ressource sichtbar und pro Verbraucher unsichtbar, also kann niemand ein Budget bekommen, was heißt, dass niemand ein Limit bekommen kann. Governance-Kosten: Jede neue Kontrolle, Prompt-Logging, PII-Schwärzung, eine Transparenzanforderung aus dem EU AI Act, muss fünfmal implementiert und fünfmal verifiziert werden, und der Review-Aufwand skaliert mit der Zahl der Anwendungen statt mit der Zahl der Kontrollen.

Ein Gateway beseitigt diese Kosten nicht. Es verschiebt sie an einen Ort, an dem ein Platform-Team sie einmal bezahlen kann. Das ist das ganze Argument, und jeder reichhaltigeren Version davon sollte man misstrauen.

Build versus Buy auf Azure

Das Team hat drei Varianten geprüft, und die Antwort ist nicht die, die sich ein Entwickler wünscht.

Azure API Management als AI-Gateway. API Management liefert einen Satz von Fähigkeiten, die explizit auf Language-Model-Traffic zielen, und die Liste ist länger, als die meisten vor dem Lesen annehmen. Die llm-token-limit-Policy erzwingt tokens-per-minute oder eine Token-Quota pro Stunde, Tag, Woche, Monat oder Jahr gegen einen beliebigen Counter-Key, darunter ein Subscription-Key, eine Aufrufer-IP oder ein beliebiger Policy-Ausdruck, und sie kann Prompt-Tokens auf dem Gateway vorab berechnen, sodass ein Request über dem Limit das Backend gar nicht erst erreicht. Die Policies llm-semantic-cache-store und llm-semantic-cache-lookup cachen Completions per Vektorähnlichkeit gegen Azure Managed Redis oder einen anderen RediSearch-kompatiblen Cache. Die llm-emit-token-metric-Policy schreibt Token-Zahlen mit Custom Dimensions nach Application Insights, das Rohmaterial für die Zuordnung pro Verbraucher. Backends unterstützen Round-Robin-, gewichtetes, prioritätsbasiertes und Session-aware Load Balancing sowie einen circuit breaker, dessen Trip-Dauer den Retry-After-Header des Backends respektiert, sodass ein Pay-as-you-go-Endpoint den Überlauf eines gesättigten Provisioned-Throughput-Unit-Deployments abfangen kann, ohne dass jemand Retry-Code schreibt.

Die Anbieterabdeckung ist hier wichtig und leicht falsch einzuschätzen. API Management vermittelt Language-Model-APIs, die den Schemas von OpenAI Chat Completions und Responses, der Anthropic Messages API (in den v2-Tiers) und der Google Vertex AI API entsprechen, gegen Modelle in Microsoft Foundry oder bei Nicht-Microsoft-Anbietern einschließlich Amazon Bedrock. Eine unified model API, zum Zeitpunkt des Schreibens in Preview, stellt mehrere Backends hinter einem einzigen OpenAI-kompatiblen Endpoint bereit und übersetzt die Formate, sodass ein Governance-Policy-Set über alle Anbieter hinweg gilt. Anthropic Claude, Mistral und Llama sind über diese Schicht erreichbar, statt jeweils eine eigene Integration zu verlangen.

Ein Open-Source-Proxy auf AKS. LiteLLM und ähnliche Projekte liefern Anbieterübersetzung und Routing in einem Container unter voller eigener Kontrolle, mit einem schnelleren Weg zu einem gewünschten Feature und ohne Abhängigkeit von einer Preview. Man erbt dafür eine On-Call-Rotation für eine Komponente, die jetzt vor jedem AI-Request des Unternehmens sitzt, plus die Identity-, Netzwerk- und Audit-Arbeit, die API Management bereits zertifiziert hat.

Ein maßgeschneiderter FastAPI-Service. Maximale Kontrolle, und die einzige Option, bei der jeder Fehler der eigene ist. Vertretbar für eine Komponente mit wirklich ungewöhnlichen Anforderungen, was ein Token zählender Reverse Proxy nicht ist.

Die Entscheidung, der diese Serie folgt: API Management ist die Data Plane, und was API Management nicht kann, wird als kleine Python-Control-Plane auf AKS gebaut. Diese Aufteilung lohnt es sich zu verinnerlichen, denn genau hier gehen die meisten Gateway-Projekte schief. Teams versuchen entweder, alles als Policy-XML auszudrücken, was ein unwartbares Artefakt produziert, das niemand testen kann, oder sie leiten den Traffic durch ihren eigenen Service und implementieren Rate Limiting schlecht nach. Das Gateway trägt den Request. Die Control Plane trägt den Zustand: welche Modelle existieren, wer sie aufrufen darf, was ein Aufruf kostet und was passiert, wenn ein Modell abgeschaltet wird.

Was man trotzdem selbst baut

Fünf Dinge, und jedes davon ist ein späterer Teil dieser Serie.

  • Ein Modellkatalog mit Lifecycle. Welche logischen Modellnamen existieren, welche physischen Deployments dahinterstehen, welche deprecated sind und wann sie verschwinden. Anwendungen müssen chat-default aufrufen, nie einen Deployment-Namen, sonst wird aus der 60-Tage-Abschaltungsmail wieder ein 60-Tage-Migrationsprojekt.
  • Tenant-Identität und Onboarding. Ein Team bekommt ein Client-Credential, eine Quota, eine Modell-Allowlist und eine Kostenstelle, provisioniert als Code statt als Ticket.
  • Kostenzuordnung und Chargeback. Token-Metriken mit einer Tenant-Dimension sind nur der Input. Daraus eine monatliche Zahl pro Team zu machen, die die Finanzabteilung akzeptiert, ist eine Datenpipeline mit eigenen Tests.
  • Evaluations-Gates in der Pipeline. Eine neue Modellversion zu promoten ist ein Deployment. Ein Deployment, das Modellverhalten ändert, ohne dass ein Eval-Ergebnis dranhängt, ist ein Ausfall, der darauf wartet, dass ein Kunde ihn findet.
  • Asynchrone und langlaufende Arbeit. Die Batch-Zusammenfassung von Support-Tickets gehört nicht auf denselben synchronen Pfad wie ein Kunde, der auf sein erstes Token wartet. Diese Trennung ist eine Queue, kein Timeout-Setting.

Zielarchitektur

Die Plattform ist bewusst langweilig und bewusst additiv. Fällt die Control Plane aus, bedient die Data Plane den Traffic mit der letzten bekannten Konfiguration weiter, denn ein Gateway, das bei einem Control-Plane-Ausfall geschlossen ausfällt, ist ein unternehmensweiter Ausfall.

graph TD
  subgraph consumers["Consumer apps"]
    A1["customer-service assistant"]
    A2["IT-ops summarizer"]
    A3["code assistant"]
    A4["retail knowledge search"]
    A5["marketing copy tool"]
  end

  subgraph gw["Data plane: API Management"]
    POL["policies:
llm-token-limit, semantic cache,
emit-token-metric, JWT validate"]
    LB["backend pool:
priority + weighted, circuit breaker"]
  end

  subgraph cp["Control plane: Python on AKS"]
    CAT["model catalog"]
    TEN["tenant registry"]
    COST["cost attribution job"]
  end

  subgraph models["Model layer"]
    FDRY["Microsoft Foundry:
GPT deployments, PTU + PAYG"]
    ANTH["Anthropic Claude"]
    OSS["Mistral, Llama"]
  end

  ID["Microsoft Entra ID"]
  RED["Azure Managed Redis
semantic cache"]
  SRCH["Azure AI Search
retrieval"]
  MON["Azure Monitor +
Application Insights"]

  A1 --> POL
  A2 --> POL
  A3 --> POL
  A4 --> POL
  A5 --> POL

  ID -. "OAuth2 client credentials" .-> POL
  POL --> LB
  POL <--> RED
  LB --> FDRY
  LB --> ANTH
  LB --> OSS
  POL -- token metrics, prompt logs --> MON
  CAT -. "backend + policy config" .-> gw
  TEN -. "subscriptions, quotas" .-> gw
  MON --> COST
  A4 -. "grounding data" .-> SRCH

Zwei Eigenschaften dieses Diagramms sind tragend. Erstens: Jeder Pfeil in die Modellschicht beginnt innerhalb von API Management, was bedeutet, dass die Netzwerkregeln auf den Foundry-Ressourcen alles andere verweigern. Das Gateway ist keine Empfehlung, es ist die einzige Route mit einem Pfad. Zweitens: Die Control Plane schreibt Konfiguration ins Gateway und liest Telemetrie aus Azure Monitor, sitzt aber nie im Request-Pfad. Sie kann mittags neu deployt werden.

Der Stack, an einem Ort

Was die zehn Teile berühren, damit die Form der Serie von hier aus sichtbar ist. Infrastructure as Code in Terraform, mit dem Vergleich zu Bicep und ARM, der in Teil 2 ehrlich geführt statt weggewunken wird. Docker-Images und AKS für die Control Plane. Azure DevOps für Pipelines, Versionierung und Release-Management. Python überall dort, wo die Logik lebt. Microsoft Entra ID mit OAuth2 client credentials und API-Keys dort, wo ein Legacy-Aufrufer es nicht besser kann. Azure AI Search und eine dedizierte Vektordatenbank für Retrieval, verglichen statt verkündet. Azure Managed Redis für Semantic Caching. Azure Monitor und Application Insights für Telemetrie, daneben LLM-spezifische Observability in LangSmith und Openlayer, und Dataiku dort, wo ein Data-Science-Team bereits zu Hause ist. LangChain für Orchestrierung in dem einen Teil, in dem sich ein Framework seinen Platz verdient, und in den Teilen, in denen nicht. Streaming über Server-Sent Events, WebSockets dort, wo eine Session wirklich bidirektional ist, und eine Message Queue für alles, was keine sofortige Antwort braucht.

Die zehn Teile, der Reihe nach: das Plädoyer für ein Gateway; Terraform gegen Bicep und ARM; die Anbieterabstraktion und Streaming; asynchrone und ereignisgesteuerte Arbeit; Identität, Quota und Chargeback; Semantic Caching; Retrieval mit Azure AI Search gegen eine echte Vektordatenbank; Orchestrierung auf dem Gateway; CI/CD und Modell-Lifecycle in Azure DevOps; und Observability mit AI-Governance.

Wie Erfolg aussieht

Der letzte Teil kommt auf diese Punkte zurück. Es sind die vier Zahlen aus der Aufwandsbilanz oben, messbar gemacht:

  • Jeder Product Owner sieht die eigenen Token-Ausgaben für den laufenden Monat, innerhalb eines Tages nach ihrem Entstehen, ohne das Platform-Team zu fragen.
  • Keine Anwendung hält ein langlebiges Modell-Credential. Den Zugriff eines Teams zu widerrufen ist eine Konfigurationsänderung im Tenant-Register, kein Eingriff in die App Settings dieses Teams.
  • Eine Ankündigung zur Modellabschaltung erzeugt eine Query, keine Untersuchung: Der Katalog weiß bereits, welche Tenants in den letzten 30 Tagen auf dieses Deployment aufgelöst wurden.
  • Ein Tenant kann die Quota eines anderen Tenants nicht erschöpfen, verifiziert durch das Nachstellen des 429-Vorfalls von oben als Lasttest gegen das Gateway.
  • Die mediane zusätzliche Latenz durch das Gateway bleibt für ungecachte Aufrufe unter 60 Millisekunden am 95. Perzentil, und Semantic-Cache-Treffer kehren in einem Bruchteil eines Modellaufrufs zurück.

Fehlerbilder, auf die man von Tag eins an achten muss

Drei, und sie verdienen es, benannt zu werden, bevor irgendein Terraform geschrieben ist. Das Gateway wird zum Single Point of Failure, sobald es die einzige Route ist, was ja der Zweck ist. Sein Verfügbarkeitsziel muss deshalb höher liegen als das der anspruchsvollsten Anwendung dahinter, und sein Deployment muss vom ersten Apply an zonenredundant sein, nicht erst nach dem ersten Vorfall. Policy-Wildwuchs kommt leise: Policy-XML ist Code, es wird bei jedem Request ausgeführt, und es ist schnell an einem Ort geschrieben, an dem es niemand reviewt. Es gehört in die Versionskontrolle zum Rest der Plattform, per Pipeline angewendet, nie im Portal editiert. Und der Bypass-Pfad macht alles andere zunichte, denn ein einziges Team, das einen direkten Key zu einem Foundry-Endpoint behält, macht jede Zuordnungszahl und jede Quota-Garantie zur Näherung. Das ist eine Netzwerkregel und ein Alert, kein Policy-Dokument.

Weiterlesen

Für die Infrastruktur- und Plattform-Seite, so etwas in diesem Maßstab zu betreiben, gibt es die Field Notes auf ercan.cloud, und der Hub liegt auf ercanermis.com.

Referenzen