Einheit 6.5: KI-Schlussfolgerung: Gemanagtes Modell-Hub

Einführung

FinCorp möchte einen internen Assistenten, der die Fragen des Personals aus den eigenen Richtlinien- und Produktunterlagen beantwortet. Die architektonische Entscheidung besteht nicht darin, welches Modell am cleversten ist, sondern wo die Inferenz ausgeführt wird und wer die operativen Aufgaben übernimmt. Für ein deutsches Finanzdienstleistungsunternehmen unter GDPR und BSI-Vorschriften sollte die Standardoption die sein, die die Daten im Inland hält, keine zusätzliche Infrastruktur zur Ausführung erfordert und nur für den tatsächlich verbrauchten Bedarf abrechnet. Diese Option ist der gemanagte AI Model Hub. Diese Einheit begründet, warum gemanagte Inferenz die Unternehmensstandard ist, wann ein dedizierter GPU-Server seine Aufgaben erfüllt und wie FinCorp eine retrieval-augmentierte Generation aus Plattformprimitiven aufbaut. Sie endet damit, einen funktionierenden Inferenzaufruf zu demonstrieren, damit die API-Form konkreter wird.

1. Managed Inference als Unternehmensstandard

AI Model Hub ist ein Inference-Service: Er dient vorab trainierten Modellen hinter einem API, sodass Sie AI-Funktionen implementieren können, ohne die zugrunde liegende Hardware bereitstellen oder warten zu müssen. Für einen Architekten liegt der Reiz darin, dass er eine gesamte Betriebsfläche, GPU-Treiber, Modellladung, Kapazitätsreserve, Patching, aus dem Design entfernt. Vier Eigenschaften machen es zur Standardwahl für ein reguliertes Workload.

OpenAI-kompatibler API. Der Hub bietet zwei API-Oberflächen: eine native IONOS-API-Oberfläche und eine OpenAI-kompatible API-Oberfläche, die die OpenAI-Anforderungs- und Antwortstruktur spiegelt. Die OpenAI-kompatible Basis-URL ist https://openai.inference.de-txl.ionos.com/v1, und sie dient den vertrauten Routen: Modellauflistung, POST /v1/chat/completions für Text, POST /v1/embeddings für Vektoren und POST /v1/images/generations für Bilder. Die architektonische Konsequenz ist die Portabilität. Jeder Client, jede Bibliothek oder jedes Framework, das bereits gegen die OpenAI-API-Oberfläche geschrieben wurde, kann auf den Hub verweisen, indem die Basis-URL und das Token geändert werden, sodass die Wahl von FinCorp ihre Anwendungscode nicht an einen Anbieter bindet.

Preis pro Token. Die Abrechnung erfolgt pro Million Token, aufgeteilt zwischen Eingabe und Ausgabe, und variiert je nach Modell. Die folgenden Zahlen sind die dokumentierten Tarife für zwei repräsentative Textmodelle:

Wie die Tabelle zeigt, ist der Kostenschalter der Token-Volume und nicht eine bereitgestellte Instanz. Es gibt keine GPU, die zwischen den Anfragen untätig ist, und es gibt keine Verpflichtung, vorher eine Größe zu reservieren. Für einen internen Assistenten, dessen Last dem Arbeitstag folgt, ist die Zahlung pro Token strukturell günstiger als die Reservierung von Beschleuniger-Hardware, die nur ein paar Stunden von vierundzwanzig Stunden ausgelastet ist.

Zustandslos. Der Service verwirft Prompts und Ausgaben am Ende jeder Sitzung. Interaktionen werden nicht protokolliert, nicht aufgezeichnet und nicht für die Modelltraining wiederverwendet, und Kundendaten werden unter keinen Umständen für die Training verwendet. Zustandslosigkeit ist eine Compliance-Eigenschaft, nicht nur eine Effizienz-Eigenschaft: Es gibt keinen gespeicherten-Inhalts-Speicher für den Daten-Schutz-Beauftragten von FinCorp, um darüber nachzudenken, und es gibt keinen Inferenz-seitigen Daten-Lebenszyklus zu regeln.

Verarbeitet im Inland. Alle Verarbeitung und Inferenz erfolgen ausschließlich in Deutschland, im Rechenzentrum Berlin. AI Model Hub-Dienste, einschließlich der Inferenz-Endpunkte, werden in ISO 27001-zertifizierten deutschen Rechenzentren gehostet. Für FinCorp schließt dies die Souveränitätsfrage, die die Plattformwahl von Anfang an getrieben hat: Der Modellaufruf verlässt nie die deutsche Gerichtsbarkeit. Begrenzen Sie diesen Anspruch genau. Die ISO 27001-Zertifizierung ist an die deutschen Rechenzentren geknüpft, die den Hub hosten; es ist keine plattformweite Aussage, und die tiefere Souveränitäts-Grenze und EU-AI-Act-Rolle-Analyse gehört zu Einheit 6.6.

Zwei operationale Grenzen gehören in das Design. Die pro-Service-Verfügbarkeits-SLA beträgt 99,9%, und ihr Umfang sind die AI Model Hub-API-Endpunkte nur, nicht die pro-Modell-Verfügbarkeit oder Inferenz-Qualität. Der allgemeine API hat eine Basis-Rate-Grenze von 5 Anfragen pro Sekunde mit einer Burst-Decke von 10; das Überschreiten davon gibt HTTP 429 Too Many Requests zurück. Ein Produktions-Client muss daher Backoff und Wiederholung implementieren, anstatt unbegrenzten Durchsatz anzunehmen, und ein High-Fan-Out-Workload benötigt eine Anfragen-Pacing-Schicht vor dem Hub.

2. Wenn selbstgehosteter GPU-Server eingesetzt werden kann

Der gemanagte Hub dient einem festen Katalog von plattformbasierten Modellen. Wenn ein Kunde sein eigenes vorge trainiertes Modell bereitstellen, auf proprietären Daten feinjustieren oder ein Modell ausführen muss, das der Katalog nicht bietet, bietet IONOS stattdessen dedizierte GPU-aktivierte Compute Engine-Server an. Diese bieten Root-Zugriff auf unternehmensklassige GPU-Hardware auf einer Pay-as-you-go-Basis, sodass die Workload-Ausführung auf einer Infrastruktur erfolgt, die der Kunde kontrolliert.

Der Kompromiss besteht in der Übernahme aller Aspekte, die der gemanagte Service zuvor verborgen hat. Die ehrliche Darstellung für einen Architekten lautet: Sobald man selbst hostet, wird die Inferenz-SLA zu Ihrer, nicht zu der des Hubs. Ein einzelner GPU-Server ist ein Single-Tenant-Dedicated-Hardware ohne Live-Migration, sodass ein Host-Fehler oder ein Wartungsereignis die Ausführung unterbricht, es sei denn, Sie haben selbst Redundanz aufgebaut. Um die Art von Verfügbarkeit zu erreichen, die der gemanagte Endpunkt bietet, bedeutet dies, mindestens zwei Ausführungsknoten hinter einem Layer-4-Load Balancer auszuführen, sowie Ihre eigene Modell-Ladefunktion, Gesundheitsprüfung, Autoskalierung und Patching, aber die Standard-Vertragsquote beträgt nur eine H200-S-Instanz (größere Vorlagen oder zusätzliche Instanzen erfordern eine Unterstützungsticket-Ressourcenbegrenzungserhöhung vor der Bereitstellung) und die Verfügbarkeitszonenplatzierung ist auf Auto festgelegt, sodass Sie die beiden Knoten nicht explizit in separate Zonen zwängen können. Die vorhersehbare Kostenstruktur ist der Vorteil, den die Dokumentation hervorhebt, ein fester Tarif für nachhaltige, immer aktive Ausführung anstelle von variabler Token-Rechnung, sodass Selbst-Hosting in der Regel nur für gleichmäßige, hoch ausgelastete Workloads oder für Modelle, die der Hub nicht bereitstellt, gewinnt.

Halten Sie zwei Größenfragen getrennt. Inferenz-Größen werden durch Konkurrenz, Latenzziele und Kontextfenster-Arbeitsspeicher bestimmt, und für eine gleichmäßige hohe Last kann ein dedizierter GPU-Server günstiger sein als die Token-Rechnung. Training- und Feinabstimmungs-Größen sind ein anderes und schwereres Regime: Es benötigt nachhaltige Multi-GPU-Berechnungen gegen proprietäre Datensätze, und der Plattformweg dafür ist der GPU-Server, nicht der Inferenz-Hub. Größen Sie eine Inferenz-Bereitstellung nicht so, als ob es sich um eine Trainings-Cluster handelte, und nehmen Sie nicht an, dass ein inferenzgroßer GPU-Server ein großes Modell in vernünftiger Zeit feinjustieren kann. FinCorps Assistent ist reine Inferenz mit bescheidener, stoßweiser Last, was genau das Profil ist, das der gemanagte Hub am besten bedient, sodass FinCorp auf dem Hub bleibt und keine GPU-Server aufstellt.

3. Kunden-gebauter Retrieval-augmentierter Generation

FinCorps Assistent muss aus FinCorps eigenen Dokumenten antworten, nicht aus dem allgemeinen Training des Modells. Das Muster dafür ist die retrieval-augmentierte Generation (RAG): Kombinieren Sie die Sprachfähigkeit des Modells mit relevanten Passagen, die aus einer Wissensbasis zur Abfragezeit abgerufen werden. Der Hub stellt die modellseitigen Komponenten bereit; der Architekt komponiert die speicherseitigen Komponenten aus Plattformprimitiven.

Bauen Sie RAG als kunden-eigene Infrastruktur mit drei Plattformkomponenten auf:

• Einbettungen vom Hub. Konvertieren Sie jedes Dokumentenstück in einen dichten Vektor mit POST /v1/embeddings, unter Verwendung eines Hub-Einbettungsmodells wie BAAI/bge-m3 (dokumentiert bei 0,02 EUR pro Million Token). Der gleiche Endpunkt einbettet die Abfrage des Benutzers zur Abrufzeit, sodass Abfrage und Korpus im gleichen Vektorraum leben.
• Vektoren in Managed PostgreSQL. Speichern Sie die Einbettungen in einer Managed PostgreSQL-Instanz mit der pgvector-Erweiterung. Dies gibt Ihnen eine relationale Datenbank, die Sie bereits kennen, wie Sie sie bedienen, sichern und auf der privaten Datenebene platzieren, mit Vektor-Ähnlichkeitssuche als erste-Klasse-Abfrage. Es komponiert sauber mit allem, was Modul 5 über die relationale Ebene festgestellt hat.
• Korpus in Object Storage. Bewahren Sie die Quelldokumente in Object Storage als System der Aufzeichnung auf, unter Verwendung seiner Lebenszyklus- und Objektsperren-Funktionen für die Aufbewahrung. Der Vektor-Speicher enthält Einbettungen und Referenzen; der autoritative Text bleibt im S3-kompatiblen Bucket.

Zur Abfragezeit ist der Ablauf: Einbetten der Frage, Ausführen einer Ähnlichkeitssuche in PostgreSQL, um die nächstliegenden Stücke abzurufen, und dann Übergeben dieser Stücke als Kontext an POST /v1/chat/completions. Nichts in dieser Schleife erfordert einen gemanagten Vektor-Speicher, und Sie behalten die volle Kontrolle darüber, wo die Vektoren und das Korpus leben.

Dies ist eine bewusste architektonische Entscheidung. AI Model Hub bot historisch eine gemanagte Dokumentensammlungs-Funktion, einen eingebauten Vektor-Speicher mit Stückelung und einem nativen semantischen Abfrage-Endpunkt, mit einem Standard-chromadb-Backend und einem optionalen pgvector-Backend. Diese gemanagte Vektor-Speicher-Funktion wird eingestellt und darf nicht als Option für die Zukunft entworfen werden. Bauen Sie RAG stattdessen auf den dauerhaften Primitiven auf: Hub-Einbettungen, Ihre eigene pgvector auf Managed PostgreSQL und Ihr Korpus in Object Storage. Das Ergebnis ist identisch in der Fähigkeit, sitzt vollständig auf Diensten, die FinCorp bereits betreibt, und birgt kein Risiko der Veraltung.

DCD Implementierungs-Walkthrough

Der Aufbau dieser Einheit ist absichtlich leicht gehalten, da AI Model Hub über sein API konsumiert wird, anstatt als Data Center Designer-Infrastruktur bereitgestellt zu werden. Das Ziel ist es, ein Modell zu testen und einen funktionierenden OpenAI-kompatiblen Aufruf durchzuführen, sodass die API-Form konkrete und das Anwendungsteam von FinCorp sie in den Assistenten einbinden kann. Die einzige Voraussetzung ist der Zugriff auf das Token-Management des Vertrags.

Build-Ziel: Ein Modell testen und einen funktionierenden OpenAI-kompatiblen Aufruf durchführen.

Schritte:

1. Generieren Sie ein API-Token. Im DCD öffnen Sie den Zugriff auf das Token-Management (Access Management) und erstellen ein neues API-Token für das AI Model Hub. Der Hub authentifiziert sich mit einem Bearer-Token, und das Token ist ein JSON-Web-Token (JWT) mit einem Ablaufdatum. Kopieren Sie das Token sofort, da es nur einmal angezeigt wird.
2. Halten Sie das Token in der erwarteten Umgebungsvariable. Die Anleitungen des Hubs gehen davon aus, dass das Token in der IONOS_API_TOKEN-Umgebungsvariable gehalten wird. Setzen Sie es in Ihrer Shell, anstatt den buchstäblichen Token in Skripte oder Quellcode zu kopieren.
3. Listen Sie die verfügbaren Modelle auf. Bestätigen Sie die Konnektivität und entdecken Sie Modell-Identifikatoren, indem Sie die OpenAI-kompatible Modelle-Route unter der Basis-URL https://openai.inference.de-txl.ionos.com/v1 aufrufen. Eine erfolgreiche Antwort beweist, dass das Token, der Endpunkt und die Region korrekt sind, bevor Sie einen Prompt senden.
4. Senden Sie eine Chat-Vervollständigung. Rufen Sie POST /v1/chat/completions gegen die Basis-URL mit einem model-Identifikator aus Schritt 3 und einem messages-Array auf. Dies ist der Kern-Inferenz-Aufruf, den der Assistent von FinCorp durchführen wird.
5. Heben Sie den funktionierenden Aufruf in die Anwendung. Sobald der Aufruf zurückgegeben wird, übergeben Sie ihn dem Anwendungsteam als kanonische Client-Konfiguration: Basis-URL, Modell-Identifikator und die Bearer-Token-Konvention. Jede OpenAI-kompatible Bibliothek funktioniert jetzt, indem nur die Basis-URL und das Token gesetzt werden.

Ein minimaler Chat-Vervollständigungs-Aufruf veranschaulicht die OpenAI-kompatible Form. Der architektonische Punkt ist der Anforderungsvertrag, nicht das Skript: Durch Ändern nur der Basis-URL und des Tokens kann jeder OpenAI-Client auf den inländischen Hub umgeleitet werden.

curl https://openai.inference.de-txl.ionos.com/v1/chat/completions \
  -H "Authorization: Bearer $IONOS_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.3-70B-Instruct",
    "messages": [{"role": "user", "content": "Summarise our refund policy."}]
  }'

Häufige Fehler:

• Einsetzen eines abgelaufenen oder falschen Token-Typs. Das Bearer-Token ist ein JWT mit einem exp-Anspruch. Authentifizierungsfehler sind in der Regel ein abgelaufenes Token, regenerieren Sie es und setzen Sie IONOS_API_TOKEN neu, nicht eine fehlerhafte Anfrage.
• Hartcodieren des Tokens in Skripten oder Repositories. Das Token wird einmal angezeigt und gewährt Zugriff auf bezahlte Inferenz. Bewahren Sie es in IONOS_API_TOKEN auf, halten Sie es aus dem Quellcode heraus und rotieren Sie es nach dem üblichen Zeitplan.
• Zeigen des Clients auf die falsche Basis-URL. Die OpenAI-kompatible Basis ist https://openai.inference.de-txl.ionos.com/v1. Ein Client, der für den generischen OpenAI-Host konfiguriert ist, wird fehlschlagen; nur die Basis-URL und das Token sollten geändert werden, wenn ein OpenAI-Client migriert wird.
• Annahme unbegrenzter Durchsatzleistung. Die Basis-Rate-Limit-Begrenzung beträgt 5 Anfragen pro Sekunde, Burst 10, und der Dienst gibt HTTP 429 zurück, wenn die Begrenzung überschritten wird. Bauen Sie Backoff und Wiederholung in den Client ein und pacen Sie Workloads mit hoher Ausstrahlung; behandeln Sie den Endpunkt nicht als elastisch.
• Entwerfen auf dem Managed-Document-Collections-Vektor-Speicher. Er wird pensioniert. Bauen Sie RAG auf Hub-Embeddings plus Ihre eigenen pgvector auf Managed PostgreSQL plus Object Storage anstelle dessen.
• Lesen der 99,9%-SLA als Qualitäts- oder pro-Modell-Garantie. Sie gilt nur für die API-Endpunkte, nicht für die Verfügbarkeit eines bestimmten Modells oder die Qualität der Inferenz.

Zusammenfassung

Für ein reguliertes Unternehmen ist das verwaltete Raten auf AI Model Hub Standard: ein OpenAI-kompatibler API, Token-Preisgestaltung ohne inaktive GPU, die finanziert werden müssen, ein zustandsloser Dienst, der nichts speichert, und die Verarbeitung ist auf deutsche Rechenzentren beschränkt. Selbst gehostete GPU-Server auf dedizierter Hardware sind nur dann gerechtfertigt, wenn Sie ein Modell benötigen, das der Hub nicht bereitstellt, Sie feinjustieren oder eine ständig hohe Auslastung einen festen Rechenpreis billiger macht, und es macht die Raten-SLA und Redundanz zu Ihrer Verantwortung. FinCorps Assistant passt zum verwalteten Profil, daher nutzt es den Hub direkt und baut eine retrieval-augmentierte Generation aus Hub-Embeddings, pgvector auf Managed PostgreSQL und einem Korpus in Object Storage, indem es den veraltenden verwalteten Vektor-Speicher vollständig umgeht.

Wichtige Punkte:

• Die OpenAI-kompatible Basis-URL ist https://openai.inference.de-txl.ionos.com/v1; das Umleiten eines OpenAI-Clients benötigt nur die Basis-URL und ein Bearer-Token.
• Die Preisgestaltung erfolgt pro Million Token und variiert je nach Modell; es gibt keine bereitgestellte Instanz, daher ist der Token-Volume der Kostenschalter.
• Der Hub ist zustandslos und verarbeitet ausschließlich in Deutschland; Daten werden nie für die Schulung verwendet. Die 99,9%-SLA umfasst nur die API-Endpunkte.
• Selbst gehostete GPU-Server nur für nicht unterstützte Modelle, Feinjustierung oder ständig hohe Auslastung, wobei Sie dann die SLA und Redundanz besitzen.
• Bauen Sie RAG als kunden-eigenes: Hub-Embeddings, Vektoren in pgvector auf Managed PostgreSQL, Korpus in Object Storage. Verwenden Sie nicht den veraltenden verwalteten Vektor-Speicher.

Wichtige Begriffe:

• OpenAI-kompatibler API: eine API-Oberfläche, die die OpenAI-Anfrage- und Antwortstruktur spiegelt, sodass bestehende OpenAI-Clients durch Änderung nur der Basis-URL und des Tokens funktionieren.
• Token-Preisgestaltung: Abrechnung, die pro Million Eingabe- und Ausgabetoken gemessen wird, anstatt pro bereitgestellter Instanz.
• Retrieval-augmentierte Generation (RAG): Kombination eines Sprachmodells mit Passagen, die bei der Abfrage aus einer Wissensbasis abgerufen werden, sodass Antworten auf die eigenen Dokumente des Kunden basieren.
• pgvector: eine PostgreSQL-Erweiterung, die Embedding-Vektoren speichert und Ähnlichkeitssuche unterstützt, wodurch ein kunden-eigener Vektor-Speicher auf Managed PostgreSQL ermöglicht wird.

Weitere Lektüre

• Einheit 6.6: KI-Souveränität und das EU-KI-Gesetz (die Souveränitätsgrenze und EU-KI-Gesetz-Rollen hinter gemanagter Inferenz)
• Einheit 5.3: Relationale Datenbanken (Managed PostgreSQL) und Einheit 5.2: Object Storage (die RAG-Speicherebene)
• IONOS Cloud Architekturzentrum