Einheit 6.5: KI-Inferenz: Managed Model Hub

Einführung

FinCorp benötigt einen internen Assistenten, der Mitarbeiterfragen auf Basis der eigenen Richtlinien- und Produktdokumentation beantwortet. Die architektonische Entscheidung betrifft nicht das intelligenteste Modell, sondern den Ort, an dem die Inferenz ausgeführt wird, und wer die operative Verantwortung trägt. Für ein deutsches Finanzdienstleistungsunternehmen unter DSGVO- und BSI-Pflichten sollte die Standardoption diejenige sein, die Daten im Inland hält, keine zusätzliche Infrastruktur zum Betrieb erfordert und nur für den tatsächlich verbrauchten Anteil abrechnet. Diese Option ist der verwaltete AI Model Hub. Diese Einheit legt dar, warum verwaltete Inferenz der Standard für Unternehmen ist, wann ein dedizierter GPU-Server sich stattdessen lohnt und wie FinCorp Retrieval-Augmented Generation aus Plattform-Bausteinen aufbaut. Sie schließt mit einem funktionierenden Inferenzaufruf, damit die API-Struktur konkret wird.

1. Managed Inference als Standard für Unternehmen

AI Model Hub ist ein Inferenzdienst: Er stellt vortrainierte Modelle hinter einer API bereit, sodass KI-Funktionen implementiert werden können, ohne die zugrunde liegende Hardware bereitzustellen oder zu warten. Für einen Architekten liegt der Reiz darin, dass eine gesamte operative Ebene, GPU-Treiber, Modellladungen, Kapazitätsreserven, Patches, aus dem Design entfernt wird. Vier Eigenschaften machen ihn zur Standardwahl für regulierte Workloads.

OpenAI-kompatible API. Der Hub stellt zwei API-Oberflächen bereit: eine native IONOS CLOUD API und eine OpenAI-kompatible API, die die Anfrage- und Antwortstruktur von OpenAI spiegelt. Die OpenAI-kompatible Basis-URL ist https://openai.inference.de-txl.ionos.com/v1, und sie bietet die bekannten Routen: Modellliste, 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 Portabilität. Jeder Client, jede Bibliothek oder jedes Framework, das bereits gegen die OpenAI API geschrieben wurde, kann durch Änderung der Basis-URL und des Tokens auf den Hub gerichtet werden, so dass die Wahl von FinCorp den Anwendungscode nicht an einen bestimmten Anbieter bindet.

Preise pro Token. Die Abrechnung erfolgt pro Million Tokens, aufgeteilt in Eingabe und Ausgabe, und variiert je nach Modell. Die folgenden Werte sind die dokumentierten Sätze für zwei repräsentative Textmodelle:

Wie die Tabelle zeigt, ist der Kostentreiber das Token-Volumen, nicht eine bereitgestellte Instanz. Es gibt keine GPU, die zwischen Anfragen untätig ist, und keine Verpflichtung, die Größe im Voraus festzulegen. Für einen internen Assistenten mit schwankender Last, die dem Arbeitstag folgt, ist die Bezahlung pro Token strukturell günstiger als die Reservierung von Beschleunigerhardware, die nur wenige Stunden von vierundzwanzig beschäftigt ist.

Zustandslos. Der Dienst verwirft Prompts und Ausgaben am Ende jeder Sitzung. Interaktionen werden nicht protokolliert, nicht aufgezeichnet und nicht für das Modelltraining wiederverwendet, und Kundendaten werden unter keinen Umständen für das Training verwendet. Zustandslosigkeit ist eine Compliance-Eigenschaft, nicht nur eine Effizienzeigenschaft: Es gibt keinen Speicher für gespeicherte Inhalte, über den der Datenschutzbeauftragte von FinCorp nachdenken muss, und keinen Datenlebenszyklus auf der Inferenzseite, der zu verwalten ist.

Verarbeitung im Inland. Alle Verarbeitung und Inferenz erfolgen ausschließlich in Deutschland, im Rechenzentrum Berlin. Die Dienste von AI Model Hub, einschließlich der Inferenzendpunkte, sind in ISO 27001-zertifizierten deutschen Rechenzentren gehostet. Für FinCorp schließt dies die Souveränitätsfrage, die die Plattformwahl überhaupt erst antrieb: Der Modellaufruf verlässt nie die deutsche Gerichtsbarkeit. Diese Aussage genau einordnen. Die ISO 27001-Zertifizierung bezieht sich auf die deutschen Rechenzentren, die den Hosten; es ist keine plattformweite Aussage, und die tiefere Analyse der Souveränitätsgrenzen und der Rolle des EU-AI-Act gehört zu Einheit 6.6.

Zwei operative Grenzen gehören ins Design. Der Uptime-SLA pro Dienst beträgt 99,9%, und sein Geltungsbereich umfasst nur die API-Endpunkte von AI Model Hub, nicht die Verfügbarkeit pro Modell oder die Inferenzqualität. Die allgemeine API hat ein Basis-Ratenlimit von 5 Anfragen pro Sekunde mit einer Burst-Obergrenze von 10; bei Überschreitung wird HTTP 429 Too Many Requests zurückgegeben. Ein Produktionsclient muss daher Backoff und Retry implementieren, anstatt unbegrenzten Durchsatz vorauszusetzen, und eine Workload mit hoher Ausbreitung benötigt eine Schicht zur Steuerung der Anfragen vor dem Hub.

2. Wann selbst gehosteter GPU-Serving gerechtfertigt ist

Das verwaltete Hub bietet einen festen Katalog von plattformseitig gehosteten Modellen. Wenn ein Kunde sein eigenes vortrainiertes Modell bereitstellen, auf proprietären Daten feinabstimmen oder ein Modell ausführen muss, das der Katalog nicht anbietet, stellt IONOS CLOUD stattdessen dedizierte, GPU-fähige Compute Engine-Server bereit. Diese bieten Root-Zugriff auf Enterprise-klasse GPU-Hardware auf einer nutzungsabhängigen Abrechnungsbasis, sodass die Arbeitslast auf Infrastruktur läuft, die der Kunde kontrolliert.

Der Kompromiss besteht in der Übernahme aller Verantwortlichkeiten, die der verwaltete Service zuvor verborgen hatte. Die ehrliche Einordnung für einen Architekten lautet wie folgt: In dem Moment, in dem man selbst hostet, wird das Inferenz-SLA zum eigenen, nicht mehr zum des Hubs. Ein einzelner GPU-Server ist dedizierte Hardware mit Single-Tenant-Charakter und ohne Live-Migration, sodass ein Host-Fehler oder ein Wartungsvorfall den Serving-Betrieb unterbricht, sofern man nicht selbst Redundanz aufgebaut hat. Die Erreichung der Verfügbarkeit, die der verwaltete Endpunkt bietet, bedeutet, mindestens zwei Serving-Knoten hinter einem Layer-4-Load Balancer zu betreiben, zusätzlich eigene Mechanismen für Modell-Loading, Health-Checks, Autoscaling und Patching vorzusehen. Die Standard-Quota pro Vertrag beträgt jedoch nur eine H200-S-Instanz (größere Templates oder zusätzliche Instanzen erfordern eine Erhöhung der Ressourcenlimits über ein Support-Ticket vor der Bereitstellung), und die Platzierung in Verfügbarkeitszonen ist auf Auto festgelegt, sodass man die beiden Knoten nicht explizit in separate Zonen zwingen kann. Vorhersehbare Kosten sind der Vorteil, den die Dokumentation hervorhebt: ein fester Satz für anhaltenden, dauerhaft aktiven Serving-Betrieb statt einer variablen Abrechnung pro Token. Selbst gehostete Lösungen sind daher nur für Arbeitslasten mit stabilem Zustand und hoher Auslastung oder für Modelle, die das Hub nicht bereitstellt, vorteilhaft.

Halten Sie zwei Dimensionierungsfragen getrennt. Inferenz-Dimensionierung wird durch Parallelität, Latenzziele und den Arbeitsspeicherbedarf des Kontextfensters gesteuert, und bei stabiler hoher Last kann ein dedizierter GPU günstiger sein als die Abrechnung pro Token. Dimensionierung für Training und Feinabstimmung ist ein anderes und aufwändigeres Regime: Es erfordert anhaltende Multi-GPU-Rechenleistung für proprietäre Datensätze, und der Plattformpfad dafür ist der GPU-Server, nicht das Inferenz-Hub. Dimensionieren Sie eine Inferenz-Bereitstellung nicht so, als wäre sie ein Trainingscluster, und gehen Sie nicht davon aus, dass ein für Inferenz dimensionierter GPU ein großes Modell in angemessener Zeit feinabstimmen kann. Der Assistent von FinCorp ist reine Inferenz mit moderater, burstiger Last, was genau das Profil ist, das das verwaltete Hub am besten bedient. Daher bleibt FinCorp beim Hub und richtet keine GPU-Server ein.

3. Vom Kunden selbst erstellte Retrieval-Augmented Generation

Der Assistent von FinCorp muss auf Basis der eigenen Dokumente von FinCorp antworten, nicht auf Basis des allgemeinen Trainings des Modells. Das dafür verwendete Muster ist Retrieval-Augmented Generation (RAG): Die Sprachfähigkeit des Modells wird mit relevanten Textabschnitten kombiniert, die zur Abfragezeit aus einer Wissensdatenbank abgerufen werden. Das Hub stellt die Komponenten auf der Modellseite bereit; der Architekt setzt die Komponenten auf der Speicherseite aus Plattform-Bausteinen zusammen.

Erstellen Sie RAG als kundeneigene Infrastruktur mit drei Plattformkomponenten:

• Embeddings aus dem Hub. Wandeln Sie jedes Dokumentenfragment mit POST /v1/embeddings in einen dichten Vektor um, wobei ein Embedding-Modell des Hubs wie BAAI/bge-m3 verwendet wird (dokumentiert mit 0,02 EUR pro Million Tokens). Derselbe Endpunkt embeddet die Abfrage des Nutzers zur Abrufzeit, sodass Abfrage und Korpus im selben Vektorraum liegen.
• Vektoren in Managed PostgreSQL. Speichern Sie die Embeddings in einer verwalteten PostgreSQL-Instanz mit der pgvector-Erweiterung. So erhalten Sie eine relationale Datenbank, deren Betrieb, Sicherung und Platzierung auf der privaten Datenschicht Ihnen bereits vertraut ist, mit Vektorähnlichkeitssuche als gleichwertige Abfrage. Sie lässt sich sauber mit allem kombinieren, was Modul 5 über die relationale Schicht festgelegt hat.
• Korpus in Object Storage. Bewahren Sie die Quelldokumente in Object Storage als System of record auf und nutzen Sie dessen Lifecycle- und Object-Lock-Funktionen für die Aufbewahrung. Der Vektorspeicher enthält Embeddings und Referenzen; der maßgebliche Text verbleibt im S3-kompatiblen Bucket.

Zur Abfragezeit verläuft der Ablauf wie folgt: die Frage embedden, eine Ähnlichkeitssuche in PostgreSQL durchführen, um die nächsten Fragmente abzurufen, und diese Fragmente dann als Kontext an POST /v1/chat/completions übergeben. In dieser Schleife ist kein verwalteter Vektorspeicher erforderlich, und Sie behalten die volle Kontrolle darüber, wo Vektoren und Korpus abgelegt werden.

Dies ist eine bewusste architektonische Entscheidung. AI Model Hub bot historisch eine Funktion für verwaltete Dokumentensammlungen, einen integrierten Vektorspeicher mit Chunking und einem nativen semantischen Abfrage-Endpunkt, mit einem Standard-chromadb-Backend und einem optionalen pgvector-Backend. Diese Funktion für verwaltete Vektorspeicher wird eingestellt und darf nicht als zukünftige Option in die Architektur einbezogen werden. Bauen Sie RAG stattdessen auf den oben genannten dauerhaften Bausteinen auf: Hub-Embeddings, Ihr eigenes pgvector auf Managed PostgreSQL und Ihr Korpus in Object Storage. Das Ergebnis ist in der Funktionsfähigkeit identisch, basiert vollständig auf Diensten, die FinCorp bereits betreibt, und birgt kein Risiko durch Funktionsauslauf.

Implementierungsanleitung für DCD

Der Aufbau in dieser Einheit ist bewusst schlank gehalten, da AI Model Hub über seine API genutzt wird und nicht als Data Center Designer-Infrastruktur bereitgestellt wird. Das Ziel besteht darin, ein Modell zu testen und einen funktionierenden, OpenAI-kompatiblen Aufruf zu erstellen, damit die API-Struktur konkret ist und das Anwendungsteam von FinCorp diese in den Assistenten integrieren kann. Die einzige Voraussetzung ist der Zugriff auf das Token-Management des Vertrags.

Aufbauziel: Ein Modell testen und einen funktionierenden, OpenAI-kompatiblen Aufruf erstellen.

Schritte:

1. API-Token generieren. Öffnen Sie im DCD das Access Management (Token-Management) und erstellen Sie ein neues API-Token für den AI Model Hub. Der Hub authentifiziert sich mit einem Bearer-Token, und das Token ist ein JSON Web Token (JWT) mit Ablaufdatum. Kopieren Sie das Token sofort, da es nur einmal angezeigt wird.
2. Das Token in der erwarteten Umgebungsvariable halten. Die Anleitungen des Hubs gehen davon aus, dass das Token in der Umgebungsvariable IONOS_API_TOKEN gehalten wird. Setzen Sie es in Ihrer Shell, anstatt das Token wörtlich in Skripte oder die Quellcodeverwaltung einzufügen.
3. Verfügbare Modelle auflisten. Bestätigen Sie die Konnektivität und ermitteln Sie Modell-Identifikatoren, indem Sie die OpenAI-kompatible Modelle-Route an der Basis-URL https://openai.inference.de-txl.ionos.com/v1 aufrufen. Eine erfolgreiche Antwort bestätigt, dass Token, Endpunkt und Region korrekt sind, bevor Sie einen Prompt senden.
4. Einen Chat-Vervollständigungsaufruf senden. Rufen Sie POST /v1/chat/completions an der Basis-URL auf, mit einem model-Identifikator aus Schritt 3 und einem messages-Array. Dies ist der zentrale Inferenzaufruf, den der Assistent von FinCorp ausführen wird.
5. Den funktionierenden Aufruf in die Anwendung übernehmen. Sobald der Aufruf zurückkehrt, übergeben Sie ihn dem Anwendungsteam als die kanonische Client-Konfiguration: Basis-URL, Modell-Identifikator und die Bearer-Token-Konvention. Jede OpenAI-kompatible Bibliothek funktioniert nun, indem nur die Basis-URL und das Token gesetzt werden.

Ein minimaler Chat-Vervollständigungsaufruf veranschaulicht die OpenAI-kompatible Struktur. Der architektonische Punkt ist der Anfragevertrag, nicht das Skript: Ändert man nur die Basis-URL und das Token, wird jeder OpenAI-Client auf den inländischen Hub umgerichtet.

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:

• Einfügen eines abgelaufenen oder falsch typisierten Tokens. Das Bearer-Token ist ein JWT mit einem exp-Claim. Authentifizierungsfehler sind in der Regel auf ein abgelaufenes Token zurückzuführen; regenerieren Sie es und setzen Sie IONOS_API_TOKEN neu, anstatt von einem fehlerhaften Request auszugehen.
• Einbetten des Tokens in Skripte oder Repositories. Das Token wird nur einmal angezeigt und gewährt Zugriff auf kostenpflichtige Inferenz. Verwahren Sie es in IONOS_API_TOKEN, halten Sie es aus der Quellcodeverwaltung heraus und rotieren Sie es nach dem üblichen Zeitplan.
• Einrichten des Clients auf die falsche Basis-URL. Die OpenAI-kompatible Basis-URL ist https://openai.inference.de-txl.ionos.com/v1. Ein Client, der für den generischen OpenAI-Host konfiguriert ist, schlägt fehl; bei der Migration eines OpenAI-Clients sollten nur die Basis-URL und das Token geändert werden.
• Annahme einer unbegrenzten Durchsatzkapazität. Die Basis-Ratenbeschränkung beträgt 5 Anfragen pro Sekunde, Burst 10, und der Dienst gibt HTTP 429 zurück, wenn diese überschritten wird. Implementieren Sie Backoff und Retry im Client und regulieren Sie Workloads mit hoher Fan-out; behandeln Sie den Endpunkt nicht als elastisch.
• Design auf Basis des verwalteten Dokumenten-Sammlungen-Vektor-Speichers. Dieser wird zurückgezogen. Bauen Sie RAG stattdessen auf Hub-Embeddings plus Ihrem eigenen pgvector auf Managed PostgreSQL plus Object Storage auf.
• Lesen der 99,9 % SLA als Garantie für Qualität oder pro Modell. Sie deckt nur die API-Endpunkte ab, nicht die Verfügbarkeit eines bestimmten Modells oder die Qualität der Inferenz.

Zusammenfassung

Für ein reguliertes Unternehmen ist das verwaltete Inferencing auf AI Model Hub der Standard: eine OpenAI-kompatible API, eine Preiskalkulation pro Token ohne GPU, die bei Leerlauf Kosten verursacht, ein zustandsloser Dienst, der nichts speichert, sowie eine Verarbeitung, die auf Rechenzentren in Deutschland beschränkt ist. Das selbst gehostete GPU-Serving auf dedizierter Hardware ist nur dann gerechtfertigt, wenn ein Modell benötigt wird, das der Hub nicht bereitstellt, wenn Fine-Tuning durchgeführt wird oder wenn eine konstant hohe Auslastung eine Berechnung mit Festpreis günstiger macht. In diesem Fall werden das Inferencing-SLA und die Redundanz zu Ihrer Verantwortung. Der Assistent von FinCorp entspricht dem verwalteten Profil, nutzt den Hub daher direkt und baut Retrieval-augmented Generation auf Basis von Hub-Embeddings, pgvector auf Managed PostgreSQL und einem Korpus in Object Storage auf, wobei der in Abstellung befindliche verwaltete Vektorstore vollständig umgangen wird.

Wichtige Punkte:

• Die OpenAI-kompatible Basis-URL ist https://openai.inference.de-txl.ionos.com/v1; das Umstellen eines OpenAI-Clients erfordert nur die Basis-URL und ein Bearer-Token.
• Die Preisgestaltung erfolgt pro Million Tokens und variiert je nach Modell; es gibt keine provisionierte Instanz, daher ist das Token-Volumen der Kostentreiber.
• Der Hub ist zustandslos und verarbeitet ausschließlich in Deutschland; Daten werden niemals für das Training verwendet. Das SLA von 99,9 % deckt nur die API-Endpunkte ab.
• Selbst gehostetes Serving auf GPU-Servern nur für nicht unterstützte Modelle, Fine-Tuning oder konstant hohe Auslastung, mit der Akzeptanz, dass Sie dann das SLA und die Redundanz selbst verantworten.
• RAG als kundeneigenes System aufbauen: Hub-Embeddings, Vektoren in pgvector auf Managed PostgreSQL, Korpus in Object Storage. Den in Abstellung befindlichen verwalteten Vektorstore nicht übernehmen.

Wichtige Begriffe:

• OpenAI-kompatible API: eine API-Oberfläche, die die Struktur von Anfragen und Antworten von OpenAI spiegelt, sodass bestehende OpenAI-Clients durch Änderung nur der Basis-URL und des Tokens funktionieren.
• Preiskalkulation pro Token: Abrechnung, gemessen an der Anzahl der Eingabe- und Ausgabe-Tokens pro Million, anstatt pro provisionierter Instanz.
• Retrieval-augmented generation (RAG): die Kombination eines Sprachmodells mit Passagen, die zur Abfragezeit aus einer Wissensbasis abgerufen werden, damit Antworten auf den eigenen Dokumenten des Kunden basieren.
• pgvector: eine PostgreSQL-Erweiterung, die Embedding-Vektoren speichert und Ähnlichkeitssuche unterstützt, wodurch ein von Kunden selbst erstellter Vektorstore auf Managed PostgreSQL ermöglicht wird.

Weitere Lektüre

• Einheit 6.6: KI-Souveränität und das EU AI Act (die Souveränitätsgrenze und die Rollen des EU AI Act hinter dem verwalteten Inferencing)
• Einheit 5.3: Relationale Datenbanken (Managed PostgreSQL) und Einheit 5.2: Object Storage (die RAG-Speicherschicht)
• IONOS CLOUD Architecture Center