Wo Modelle in eine Architektur gehören

Das Modell ist eine Abhängigkeit, nicht die Architektur

Abschnitt 12.1 beschrieb ein Modell als probabilistische Funktion, die über eine API erreicht wird. In einer Architektur ist es ein Container unter vielen und meist ein kleiner Teil des Codes. Ein Kundensupport-Assistent hat ein Chat-Frontend, einen Gesprächsspeicher, Integrationen mit Bestell- und Erstattungsservices, einen Suchindex, Identitätsverwaltung, Logging, eine Übergabe an menschliche Agenten und eine Deployment-Pipeline; der Modellaufruf ist eine Zeile in der Mitte. Die Architekturfragen sind daher vertraute Fragen an eine neue Art von Abhängigkeit: Wo läuft sie, wie wird sie aufgerufen, was sitzt zwischen ihr und den Aufrufern, was geschieht, wenn sie langsam, falsch oder nicht verfügbar ist, und wer ist für ihre Ausgabe verantwortlich?

Diese Fragen richtig zu beantworten ist wichtiger, als das beste Modell des Monats zu wählen. Modelle werden alle paar Monate ersetzt; das Gateway, der Fallback-Entwurf, das Evaluierungsset und der menschliche Prüfprozess bleiben über Jahre. Die Entscheidungen in diesem Abschnitt sind die bedeutsamen, schwer umkehrbaren im Sinne von Kapitel 1, daher verdienen sie Entscheidungsdokumente; die Wahl einer bestimmten Modellversion sollte leicht zu ändern sein.

Drei Orte, an denen ein Modell laufen kann

Gehostete Modell-APIs. Der Anbieter betreibt das Modell, und Sie zahlen pro Token. Dazu gehören die eigenen APIs der Frontier-Anbieter (unter anderem OpenAI, Anthropic und Google) und Cloud-Plattformen, die Modelle mehrerer Hersteller innerhalb Ihres bestehenden Cloud-Kontos weiterverkaufen. Das ist der schnellste Einstieg und bietet Zugang zu den leistungsfähigsten Modellen, ohne Beschleuniger kaufen oder betreiben zu müssen. Die Kosten sind Preise pro Token, die mit der Nutzung wachsen, Rate Limits, die jemand anderes festlegt, eine Abhängigkeit von der Verfügbarkeit des Anbieters, Modelle, die nach dem Zeitplan des Anbieters abgekündigt werden, und Daten, die Ihren Verantwortungsbereich verlassen. Verträge, Bedingungen zur Auftragsverarbeitung, Optionen ohne oder mit begrenzter Aufbewahrung und regionale Verarbeitung mildern den letzten Punkt, beseitigen ihn aber nicht.

Selbst gehostete Open-Weight-Modelle. Bei einem Open-Weight-Modell werden die trainierten Gewichte veröffentlicht, sodass Sie es mit einem Inferenzserver wie vLLM auf eigenen oder gemieteten Beschleunigern betreiben können. Beispiele sind Modelle von Meta (Llama), Mistral, Alibaba (Qwen), DeepSeek, Google (Gemma) und OpenAI (gpt-oss). Sie kontrollieren den Datenpfad, die genaue Version und das Fine-Tuning, und bei hohem, gleichmäßigem Volumen können die Kosten pro Token deutlich unter die API-Preise fallen. Im Gegenzug übernehmen Sie die Kapazitätsplanung für knappe, teure Hardware, die Auslastung (ungenutzte Beschleuniger kosten genauso viel wie ausgelastete), Upgrades, Sicherheitspatches und Rufbereitschaft. Lizenzen sind wichtig: Manche Open-Weight-Modelle nutzen permissive Lizenzen wie Apache 2.0, andere eigene Lizenzen mit Bedingungen zu Nutzung oder Umfang, und die meisten veröffentlichen ihre Trainingsdaten nicht. Die Open Source AI Definition der Open Source Initiative (Version 1.0, Oktober 2024) legt die Messlatte höher als offene Gewichte allein. Ein Mittelweg, den der Chatbot dieses Kurses selbst nutzt, ist, Open-Weight-Modelle über einen externen Inferenzanbieter aufzurufen: Preise pro Token, keine Hardware und die Freiheit, dasselbe Modell anderswohin mitzunehmen.

Geräteinterne Modelle. Kleine Modelle, oft mit einigen Milliarden Parametern oder weniger und auf geringere Genauigkeit quantisiert, laufen auf Smartphones, Laptops oder im Browser. Sie bieten Datenschutz (die Daten verlassen das Gerät nie), Offline-Betrieb, keine Kosten pro Aufruf und sehr geringe Latenz, zum Preis einer viel geringeren Leistungsfähigkeit, einer großen Streuung der Geräteleistung, größerer App-Downloads und der Schwierigkeit, Modelle zu aktualisieren, die bereits an Millionen von Geräten ausgeliefert sind. Viele Produkte kombinieren sie: Ein kleines geräteinternes Modell erledigt schnelle, private Aufgaben und eskaliert schwierigere an die Cloud.

Online-Inferenz und Batch-Scoring

Die zweite Frage ist, ob ein Nutzer wartet. Online-Inferenz ruft das Modell im Anfragepfad auf, daher gelten Latenzziele: Nutzer bemerken die Zeit bis zu den ersten sichtbaren Wörtern, weshalb Chat-Antworten gestreamt werden, und sie brechen eine Anfrage ab, die viele Sekunden dauert. Online-Aufrufe brauchen Timeouts, Nebenläufigkeitsgrenzen und Kapazität für die Abendspitze, genau wie jede synchrone Abhängigkeit in Kapitel 6.

Batch-Scoring verarbeitet viele Elemente, ohne dass jemand wartet: zwei Millionen Gerichte über Nacht mit Allergenen taggen, die Support-Gespräche vom Vortag zusammenfassen, eine Dokumentensammlung neu einbetten. Batch-Arbeit kann das günstigste ausreichende Modell nutzen, laufen, wenn Kapazität frei ist, und in Ruhe wiederholen. Mehrere Anbieter bieten asynchrone Batch-Schnittstellen an, die eine Datei mit Anfragen annehmen und die Ergebnisse innerhalb von Stunden mit erheblichem Rabatt liefern. Dazwischen liegt die asynchrone Inferenz: Eine Anfrage wird in eine Queue gestellt, der Nutzer erfährt, dass das Ergebnis folgt (eine Erstattungsentscheidung per E-Mail, eine Dokumentzusammenfassung in wenigen Minuten), und Worker arbeiten die Queue in kontrolliertem Tempo ab und nutzen dabei die Queues und Backpressure aus Kapitel 9, um Spitzen und die Rate Limits der Anbieter abzufangen. Arbeit aus dem Online-Pfad zu verlagern ist eine der wirksamsten Entscheidungen für Kosten und Zuverlässigkeit, die es gibt.

Ein AI-Gateway zwischen Anwendungen und Modellen

Sobald mehr als ein Team oder eine Funktion Modelle aufruft, macht sich ein eigenes AI-Gateway bezahlt. Es spielt die Rolle, die ein API-Gateway für Microservices spielt, spezialisiert auf Modellverkehr. Anwendungen rufen einen internen Endpoint mit einem Anfrageformat und ihrer eigenen Identität auf; das Gateway hält die Anbieterschlüssel, übersetzt in die API jedes Anbieters, wendet Routing und Fallbacks an, setzt Quoten und Ausgabenbudgets pro Team durch, wendet Rate Limits an, zeichnet jeden Aufruf auf (Modell, Version, Tokenzahlen, Latenz, Kosten, Ergebnis) für Tracing und Kostenzuordnung, kann Antworten cachen und bietet einen Ort, an dem sich Eingabe- und Ausgabe-Guardrails zentral anbinden lassen.

Die Vorteile sind architektonisch: Die Wahl des Anbieters wird zu einer Konfigurationsentscheidung statt einer Codeänderung in jedem Service, Schlüssel sind nicht mehr über Anwendungen verstreut, die Ausgaben sind pro Funktion sichtbar, und ein Ausfall beim Anbieter wird an einer Stelle behandelt. Die Kosten sind die jedes gemeinsamen Vermittlers. Es ist eine neue kritische Abhängigkeit, die hochverfügbar sein muss, es fügt etwas Latenz hinzu, und seine Logs werden zu einem konzentrierten Speicher von Prompts, die personenbezogene Daten enthalten können, sodass Regeln zu Schwärzung und Aufbewahrung (siehe Privacy by Design) für es gelten. Es gibt Open-Source- und verwaltete Gateway-Produkte, und Cloud-Plattformen enthalten Gateway-Funktionen; ein schlankes eigenes Gateway zu bauen ist für ein kleines System vernünftig, aber Quoten, Streaming, Wiederholungen und Abrechnung sind mehr Arbeit, als es scheint.

Routing und Kaskaden

Nicht jede Anfrage braucht das leistungsfähigste Modell. Routing entscheidet vorab, welches Modell eine Anfrage bearbeiten soll, anhand von Regeln (die Funktion, die Kundenstufe, die Sprache) oder eines kleinen, schnellen Klassifikators. Im Support-Assistenten kann Wo ist meine Bestellung? an ein kleines, günstiges Modell gehen, das ein Tool aufruft, während eine Beschwerde über drei verschiedene Probleme an ein größeres Modell geht. Eine Modellkaskade versucht dagegen zuerst ein günstigeres Modell und eskaliert nur, wenn eine Prüfung ergibt, dass seine Antwort nicht gut genug ist. FrugalGPT von Chen, Zaharia und Zou (2023) zeigte, dass gut abgestimmte Kaskaden die Qualität des stärksten Modells zu einem Bruchteil der Kosten annähernd erreichen können.

Eine Kaskade ist nur so gut wie ihre Eskalationsprüfung. Verlässliche Prüfungen sind deterministisch: Die Ausgabe besteht die Schemavalidierung nicht, eine zitierte Quelle existiert nicht, ein Pflichtfeld fehlt, eine Geschäftsregel lehnt den Vorschlag ab. Ein Prüfmodell, das die Antwort bewertet, ist schwächer, aber oft nützlich. Die eigene Konfidenzangabe eines Modells ist das unzuverlässigste Signal und sollte nicht allein verwendet werden. Kaskaden haben auch Kosten: Eskalierte Anfragen bezahlen zwei Aufrufe und warten auf beide, es gibt nun zwei Modelle, die evaluiert und im Gleichschritt gehalten werden müssen, und die Qualitätsobergrenze setzt die Prüfung, nicht das starke Modell. Messen Sie die Eskalationsrate; wenn die meisten Anfragen eskalieren, routen Sie stattdessen.

Fallback-Kaskaden über Modelle und Anbieter hinweg

Modell-APIs versagen auf alle Arten, auf die entfernte Abhängigkeiten versagen, und auf ein paar eigene: Rate-Limit-Antworten (HTTP 429), wenn ein Kontingent erschöpft ist, Überlastungsfehler zu Stoßzeiten, langsame Antworten, die einen Timeout überschreiten, regionale Ausfälle und Modelle, die zu einem Abkündigungsdatum zurückgezogen werden. Die Muster aus Kapitel 9 gelten unmittelbar, angeordnet als Fallback-Kaskade: eine geordnete Liste von Stufen, von denen jede versucht wird, wenn die darüber fehlschlägt. Eine typische Kaskade besteht aus dem primären Modell; demselben Modell in einer anderen Region oder bei einem anderen Host; einem anderen Modell ähnlicher Leistungsfähigkeit von einem zweiten Anbieter; einem kleineren, schnelleren Modell; und schließlich einer Antwort ohne KI, etwa einer hilfreichen vorformulierten Nachricht, den Suchergebnissen des Hilfe-Centers oder einer Übergabe an einen Menschen.

Entwurfsregeln für eine Kaskade: Geben Sie jeder Stufe einen eigenen Timeout und der ganzen Kaskade eine Gesamtfrist, damit der Nutzer nie auf vier langsame Fehlschläge hintereinander wartet; beachten Sie Retry-After und versetzen Sie ein durch Rate Limits gebremstes Modell in eine Abkühlphase (ein einfacher Circuit Breaker), statt es mit Anfragen zu überhäufen; wiederholen Sie keine Fehler, die erneut auftreten werden, etwa eine zu große oder von einem Inhaltsfilter abgelehnte Anfrage; validieren Sie die Ausgabe auf jeder Stufe, weil eine niedrigere Stufe Antworten in leicht anderer Form liefern kann; evaluieren Sie jede Stufe mit demselben Evaluierungsset, da Prompts oft pro Modell angepasst werden müssen; und zeichnen Sie auf, welche Stufe geantwortet hat, damit Qualitäts-Dashboards eine verschlechterte Antwort von einer normalen unterscheiden können.

Die KI-Funktionen dieses Kurses sind ein kleines, reales Beispiel. Die Antworten von ArchitectBot und die Bewertung schriftlicher Testantworten werden über eine Kaskade mehrerer Open-Weight-Modelle erzeugt, die ein einziger Inferenzanbieter bereitstellt und die in fester Präferenzreihenfolge versucht werden. Ein Modell, das eine Rate-Limit-Antwort liefert, wird für die vom Anbieter verlangte Dauer (innerhalb festgelegter Grenzen) pausiert, eine Anfrage, die fehlschlägt, in einen Timeout läuft oder eine unbrauchbare Antwort liefert, geht an die nächste Stufe, diese Stufen teilen sich ein gemeinsames Zeitbudget, und ein zweiter Anbieter dient als letzte Stufe. Der Entwurf tauscht auf den unteren Stufen etwas Antwortqualität gegen Verfügbarkeit: Eine etwas schwächere Antwort ist besser als keine.

Human in the Loop

Human in the Loop beschreibt mehrere verschiedene Entwürfe, und es hilft zu benennen, welcher gemeint ist. Freigabe vor der Wirkung: Das Modell entwirft, ein Mensch gibt frei (eine Erstattung über einer Grenze, eine Antwort an eine Aufsichtsbehörde, eine Änderung an der Produktion). Prüfung nach der Wirkung: Ausgaben werden sofort wirksam, und Menschen prüfen eine Stichprobe oder die markierten Fälle. Eskalation: Das Modell erledigt, was es kann, und übergibt den Rest mit dem Gespräch und den Belegen an einen Menschen. Feedback: Menschen labeln oder korrigieren Ausgaben, um Evaluierungssets aufzubauen und Prompts zu verbessern.

Jeder Entwurf hat architektonische Folgen. Eine Freigabe erzeugt eine Queue, die für das Spitzenvolumen dimensioniert werden muss, wie die Prüf-Queue für Betrugsfälle in Abschnitt 12.1, und fügt Latenz hinzu, die in Minuten oder Stunden gemessen wird. Wer Hunderte guter Vorschläge freigibt, fängt an, ohne Lesen freizugeben (Automation Bias), daher sollte die Oberfläche die Belege und die genaue Aktion zeigen, Ungewöhnliches hervorheben und verfolgen, wie oft die Prüfenden den Vorschlag ändern; eine Änderungsquote nahe null ist eine Warnung, kein Erfolg. Übergaben brauchen den vollständigen Kontext, damit sich der Kunde nicht wiederholen muss. Die menschliche Aufsicht, die Regulierung für manche Einsatzzwecke verlangt, ist noch anspruchsvoller: Die Person muss die Grenzen des Systems verstehen und es übersteuern können.

Bauen oder kaufen, und wie man ein Modell wählt

Die Frage „Bauen oder kaufen“ hat mehr als zwei Antworten. Sie können eine fertige KI-Funktion in einem Produkt kaufen, das Sie bereits nutzen (den Assistenten eines Helpdesk-Herstellers); auf gehosteten APIs aufbauen; ein Modell per Fine-Tuning für Ihre Aufgabe anpassen; offene Gewichte selbst hosten; oder, selten, ein eigenes Modell trainieren. Nutzen Sie die strategische Linse des Domain-Driven Design: Kaufen Sie für generische Fähigkeiten wie die Transkription von Meetings, und bauen Sie dort, wo KI Ihre Core Domain berührt und Ihre eigenen Daten Ihnen einen Vorteil verschaffen. Was immer Sie bauen, halten Sie anbieterspezifischen Code hinter einem Port mit je einem Adapter pro Anbieter, und vermeiden Sie Abhängigkeiten von Funktionen, die nur ein Anbieter bietet, sofern ihr Wert den Lock-in nicht rechtfertigt.

Wählen Sie Modelle mit Ihrem eigenen Evaluierungsset, nicht anhand öffentlicher Leaderboards. Leaderboards messen allgemeine Aufgaben, die Ihren vielleicht nicht ähneln, und auf manche wurde gezielt hin optimiert. Legen Sie die Kriterien und ihre Gewichte vor dem Testen fest, wie bei jeder gewichteten Entscheidung, setzen Sie dann zwei oder drei Kandidaten auf die engere Wahl und messen Sie sie an einigen Hundert echten Beispielen. Rechnen Sie damit, dass die Antwort eine Kombination ist, etwa ein kleines Modell für das Routing und ein größeres für schwierige Fälle, statt eines einzigen Siegers.