Unité 6.5 : Inférence IA : Hub de modèles géré

Introduction

FinCorp souhaite un assistant interne qui réponde aux questions du personnel à partir de sa propre documentation de politique et de produits. La décision architecturale ne consiste pas à déterminer quel modèle est le plus ingénieux ; elle consiste à déterminer où s'exécute l'inférence et qui supporte le poids opérationnel. Pour une entreprise financière allemande soumise aux obligations GDPR et BSI, l'option par défaut devrait être celle qui garde les données dans le pays, n'ajoute pas d'infrastructure à exploiter et facture uniquement ce qui est consommé. Cette option est l'inférence gérée AI Model Hub. Cette unité établit pourquoi l'inférence gérée est la valeur par défaut de l'entreprise, quand un serveur GPU dédié est justifié, et comment FinCorp crée une génération améliorée par récupération à partir de primitives de plateforme. Elle se termine par la mise en place d'un appel d'inférence fonctionnel afin que la forme API soit concrète.

1. Inférence gérée comme défaut d'entreprise

Le AI Model Hub est un service d'inférence : il sert des modèles pré-entraînés derrière un API, ce qui vous permet de mettre en œuvre des fonctionnalités d'intelligence artificielle sans avoir à provisionner ou à maintenir le matériel sous-jacent. Pour un architecte, l'attrait est qu'il supprime une surface opérationnelle entière, les pilotes GPU, le chargement de modèles, la marge de capacité, la correction de bogues, de la conception. Quatre propriétés en font le choix par défaut pour une charge de travail réglementée.

API compatible OpenAI. Le hub expose deux surfaces API : un API natif IONOS et un API compatible OpenAI qui reflète la structure de requête et de réponse OpenAI. L'URL de base compatible OpenAI est https://openai.inference.de-txl.ionos.com/v1, et il sert les routes familières : lister les modèles, POST /v1/chat/completions pour le texte, POST /v1/embeddings pour les vecteurs, et POST /v1/images/generations pour les images. La conséquence architecturale est la portabilité. Tout client, bibliothèque ou framework déjà écrit contre le API OpenAI peut être pointé vers le hub en changeant l'URL de base et le jeton, de sorte que le choix de FinCorp ne verrouille pas son code d'application à un fournisseur.

Tarification par jeton. La facturation est par million de jetons, répartie entre l'entrée et la sortie, et varie en fonction du modèle. Les chiffres suivants sont les tarifs documentés pour deux modèles de texte représentatifs :

Comme le montre le tableau, le levier de coût est le jeton Volume, et non une instance provisionnée. Il n'y a pas de GPU inactif entre les requêtes et pas d'engagement pour une taille à l'avance. Pour un assistant interne à charge irrégulière dont la charge suit la journée de travail, payer par jeton est structurellement moins cher que réserver du matériel d'accélérateur qui est occupé quelques heures sur vingt-quatre.

Sans état. Le service supprime les invites et les sorties à la fin de chaque session. Les interactions ne sont pas enregistrées, ne sont pas enregistrées, et ne sont pas réutilisées pour la formation de modèles, et les données client ne sont pas utilisées pour la formation dans aucune circonstance. La propriété sans état est une propriété de conformité, et non seulement une propriété d'efficacité : il n'y a pas de magasin de contenu conservé pour que l'agent de protection des données de FinCorp puisse raisonner à ce sujet, et il n'y a pas de cycle de vie des données d'inférence à gouverner.

Traitée dans le pays. Toutes les traitements et inférences se font exclusivement en Allemagne, dans le centre de données de Berlin. Les services AI Model Hub, y compris les points de terminaison d'inférence, sont hébergés dans des centres de données allemands certifiés ISO 27001. Pour FinCorp, cela clôture la question de souveraineté qui a motivé le choix de la plateforme dans un premier temps : l'appel de modèle ne quitte jamais la juridiction allemande. Délimitez cette affirmation avec précision. La certification ISO 27001 s'attache aux centres de données allemands qui hébergent le hub ; ce n'est pas une déclaration à l'échelle de la plateforme, et l'analyse plus approfondie de la frontière de souveraineté et du rôle de l'UE-AI-Act appartient à l'unité 6.6.

Deux limites opérationnelles appartiennent à la conception. Le SLA de disponibilité par service est de 99,9 %, et sa portée est les points de terminaison API du AI Model Hub uniquement, et non la disponibilité par modèle ou la qualité d'inférence. Le API général comporte un taux de base de 5 requêtes par seconde avec un plafond d'explosion de 10 ; le dépassement de ce plafond renvoie HTTP 429 Too Many Requests. Un client de production doit donc mettre en œuvre un mécanisme de rétrogradation et de réessai plutôt que de supposer un débit illimité, et une charge de travail à grande échelle nécessite une couche de rythmisation des requêtes devant le hub.

2. Lorsque l'hébergement auto-hébergé GPU est justifié

Le hub géré sert un catalogue fixe de modèles hébergés sur la plateforme. Lorsqu'un client a besoin de déployer son propre modèle pré-entraîné, d'effectuer un ajustement fin sur des données propriétaires ou d'exécuter un modèle que le catalogue ne propose pas, IONOS positionne des serveurs dédiés Compute Engine activés GPU à la place. Ces serveurs donnent accès à Root à du matériel GPU de classe entreprise sur une base de paiement à l'utilisation, de sorte que la charge de travail s'exécute sur une infrastructure que le client contrôle.

Le compromis est la propriété de tout ce que le service géré cachait. La formulation honnête pour un architecte est la suivante : dès l'instant où vous hébergez vous-même, le SLA d'inférence devient le vôtre, et non celui du hub. Un seul serveur GPU est un matériel dédié mono-locataire sans migration en direct, de sorte qu'une panne d'hôte ou un événement de maintenance interrompt le service à moins que vous n'ayez construit une redondance vous-même. Pour atteindre le type de disponibilité que fournit le point de terminaison géré, il faut exécuter au moins deux nœuds de service derrière un Load Balancer de couche 4, ainsi que votre propre chargement de modèle, vérification de l'état, mise à l'échelle automatique et correction, mais la quote-part par défaut du contrat est d'un seul instance H200-S (les modèles plus grands ou les instances supplémentaires nécessitent une augmentation de la limite de ressources via un ticket de support avant le déploiement) et le placement de la zone de disponibilité est fixé à Auto, de sorte que vous ne pouvez pas forcer explicitement les deux nœuds dans des zones séparées. Le coût prévisible est l'avantage que la documentation met en avant, un taux fixe pour un service toujours actif et continu, plutôt qu'une facturation variable par jeton, de sorte que l'hébergement auto-hébergé tend à gagner seulement pour les charges de travail à utilisation élevée et à l'état stable, ou pour les modèles que le hub ne sert pas.

Gardez deux questions de dimensionnement séparées. Le dimensionnement de l'inférence est dicté par la concurrence, les objectifs de latence et la mémoire de la fenêtre de contexte, et pour une charge élevée stable, un GPU dédié peut être moins cher que la facturation par jeton. Le dimensionnement de la formation et de l'ajustement fin est un régime différent et plus lourd : il nécessite un calcul multi-GPU soutenu sur des jeux de données propriétaires, et le chemin de la plateforme pour cela est le serveur GPU, et non le hub d'inférence. N'effectuez pas de dimensionnement d'un déploiement d'inférence comme si c'était un Cluster de formation, et ne supposez pas qu'un GPU de taille d'inférence mettra à jour un grand modèle en un temps raisonnable. L'assistant de FinCorp est une inférence pure avec une charge modeste et irrégulière, ce qui est exactement le profil que le hub géré sert le mieux, de sorte que FinCorp reste sur le hub et ne met pas en place de serveurs GPU.

3. Génération améliorée par récupération construite par le client

L'assistant de FinCorp doit répondre à partir des documents de FinCorp, et non à partir de la formation générale du modèle. Le modèle pour cela est la génération améliorée par récupération (RAG) : combiner la capacité linguistique du modèle avec des passages pertinents récupérés à partir d'une base de connaissances au moment de la requête. Le hub fournit les pièces du côté du modèle ; l'architecte compose les pièces du côté du stockage à partir de primitives de plateforme.

Construisez RAG en tant qu'infrastructure appartenant au client avec trois composants de plateforme :

• Embeddings à partir du hub. Convertissez chaque chunk de document en un vecteur dense avec POST /v1/embeddings, en utilisant un modèle d'incrustation de hub tel que BAAI/bge-m3 (documenté à 0,02 EUR par million de jetons). Le même point de terminaison incruste la requête de l'utilisateur au moment de la récupération, de sorte que la requête et le corpus vivent dans le même espace vectoriel.
• Vecteurs dans Managed PostgreSQL. Stockez les incrustations dans une instance de Managed PostgreSQL avec l'extension pgvector. Cela vous donne une base de données relationnelle que vous savez déjà exploiter, sauvegarder et placer sur le niveau de données privé, avec une recherche de similarité vectorielle en tant que requête de premier plan. Elle se compose proprement avec tout ce que le module 5 a établi sur le niveau relationnel.
• Corpus dans Object Storage. Conservez les documents sources dans Object Storage en tant que système d'enregistrement, en utilisant ses fonctionnalités de cycle de vie et de verrouillage d'objet pour la rétention. Le magasin de vecteurs contient des incrustations et des références ; le texte autoritaire reste dans le seau compatible S3.

Au moment de la requête, le flux est : incrustez la question, exécutez une recherche de similarité dans PostgreSQL pour récupérer les chunks les plus proches, puis passez ces chunks comme contexte à POST /v1/chat/completions. Rien dans cette boucle ne nécessite un magasin de vecteurs géré, et vous conservez le contrôle total de l'endroit où vivent les vecteurs et le corpus.

Il s'agit d'un choix architectural délibéré. AI Model Hub a historiquement offert une fonctionnalité de collections de documents gérées, un magasin de vecteurs intégré avec un chunking et un point de terminaison de requête sémantique natif, avec un backend chromadb par défaut et un backend pgvector facultatif. Cette fonctionnalité de magasin de vecteurs gérée est en cours de suppression et ne doit pas être conçue comme une option à suivre. Construisez RAG à la place sur les primitives durables ci-dessus : incrustations de hub, votre propre pgvector sur Managed PostgreSQL, et votre corpus dans Object Storage. Le résultat est identique en termes de capacités, est entièrement assis sur des services que FinCorp exploite déjà, et ne comporte aucun risque de dépréciation.

DCD Déploiement étape par étape

La construction de cette unité est délibérément légère car AI Model Hub est consommé via son API plutôt que provisionné en tant qu'infrastructure Data Center Designer. L'objectif est de tester un modèle et de mettre en place un appel OpenAI-compatible fonctionnel de sorte que la forme API soit concrète et que l'équipe d'application de FinCorp puisse la relier à l'assistant. Le seul prérequis est l'accès à la gestion des jetons du contrat.

Objectif de construction : Tester un modèle et mettre en place un appel OpenAI-compatible fonctionnel.

Étapes :

1. Générer un jeton API. Dans DCD, ouvrez la gestion des accès (gestion des jetons) et créez un nouveau jeton API pour AI Model Hub. Le hub s'authentifie avec un jeton Bearer, et le jeton est un jeton Web JSON (JWT) avec une date d'expiration. Copiez le jeton immédiatement, car il n'est affiché qu'une seule fois.
2. Conserver le jeton dans la variable d'environnement attendue. Les didacticiels du hub supposent que le jeton est conservé dans la variable d'environnement IONOS_API_TOKEN. Définissez-le dans votre shell plutôt que de coller le jeton littéral dans les scripts ou le contrôle de version.
3. Lister les modèles disponibles. Confirmez la connectivité et découvrez les identificateurs de modèle en appelant la route de modèles OpenAI-compatible à l'URL de base https://openai.inference.de-txl.ionos.com/v1. Une réponse réussie prouve que le jeton, le point de terminaison et la région sont corrects avant d'envoyer une invite.
4. Envoyer une completion de chat. Appelez POST /v1/chat/completions contre l'URL de base avec un identifiant model de l'étape 3 et un tableau messages. Il s'agit de l'appel d'inférence de base que l'assistant de FinCorp effectuera.
5. Intégrer l'appel fonctionnel dans l'application. Une fois que l'appel est retourné, transmettez-le à l'équipe d'application en tant que configuration de client canonique : URL de base, identifiant de modèle et convention de jeton Bearer. Toute bibliothèque OpenAI-compatible fonctionne désormais en définissant uniquement l'URL de base et le jeton.

Un appel de completion de chat minimal illustre la forme OpenAI-compatible. Le point architectural est le contrat de requête, et non le script : modifier uniquement l'URL de base et le jeton redirige tout client OpenAI vers le hub national.

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."}]
  }'

Erreurs courantes :

• Coller un jeton expiré ou d'un type incorrect. Le jeton Bearer est un JWT avec une réclamation exp. Les échecs d'authentification sont généralement dus à un jeton expiré, régénérez-le et réinitialisez IONOS_API_TOKEN, et non à une requête malformée.
• Intégrer le jeton dans des scripts ou des référentiels. Le jeton est affiché une seule fois et accorde un accès payant à l'inférence. Stockez-le dans IONOS_API_TOKEN, gardez-le hors du contrôle de source, et faites-le pivoter selon l'horaire habituel.
• Pointer le client vers la mauvaise URL de base. La base compatible OpenAI est https://openai.inference.de-txl.ionos.com/v1. Un client configuré pour l'hôte OpenAI générique échouera ; seule l'URL de base et le jeton devraient changer lors de la migration d'un client OpenAI.
• Supposer un débit illimité. La limite de taux de base est de 5 requêtes par seconde, avec un pic à 10, et le service renvoie HTTP 429 lorsqu'il est dépassé. Intégrez le recul et la répétition dans le client et rythmez les charges de travail à forte dispersion ; ne traitez pas le point de terminaison comme élastique.
• Concevoir sur le vecteur de stockage de collections de documents gérées. Il est en cours de retrait. Créez RAG sur les embeddings de hub plus vos propres pgvector sur Managed PostgreSQL plus Object Storage à la place.
• Lire la SLA de 99,9 % comme une garantie de qualité ou par modèle. Elle couvre uniquement les points de terminaison API, et non la disponibilité d'un modèle spécifique ou la qualité de l'inférence.

Résumé

Pour une entreprise réglementée, l'inférence gérée sur AI Model Hub est la valeur par défaut : un API compatible OpenAI, un prix par jeton avec aucun GPU inactif à financer, un service sans état qui ne conserve rien, et un traitement confiné aux centres de données allemands. L'hébergement auto-hébergé de GPU sur du matériel dédié n'est justifié que lorsque vous avez besoin d'un modèle que le hub ne sert pas, que vous effectuez un ajustement fin, ou que la charge d'utilisation élevée et constante rend le calcul à taux fixe moins cher, et cela rend l'inférence SLA et la redondance votre responsabilité. L'assistant de FinCorp correspond au profil géré, il consomme donc directement le hub et crée une génération améliorée par récupération à partir d'incrustations du hub, pgvector sur Managed PostgreSQL, et un corpus dans Object Storage, contournant complètement le magasin de vecteurs géré obsolète.

Points clés :

• L'URL de base compatible OpenAI est https://openai.inference.de-txl.ionos.com/v1 ; la redirection d'un client OpenAI nécessite uniquement l'URL de base et un jeton Bearer.
• Le prix est par million de jetons et varie en fonction du modèle ; il n'y a pas d'instance provisionnée, donc le jeton Volume est le levier de coût.
• Le hub est sans état et traite exclusivement en Allemagne ; les données ne sont jamais utilisées pour la formation. La SLA de 99,9 % couvre uniquement les points de terminaison API.
• Hébergez-vous sur les serveurs GPU uniquement pour les modèles non pris en charge, l'ajustement fin ou la charge d'utilisation élevée et constante, en acceptant que vous possédiez alors la SLA et la redondance.
• Créez RAG en tant que propriété du client : incrustations du hub, vecteurs dans pgvector sur Managed PostgreSQL, corpus dans Object Storage. N'adopez pas le magasin de vecteurs géré obsolète.

Terminologie importante :

• API compatible OpenAI : une surface API qui reflète la structure de requête et de réponse d'OpenAI, permettant aux clients OpenAI existants de fonctionner en ne changeant que l'URL de base et le jeton.
• Prix par jeton : facturation mesurée par million de jetons d'entrée et de sortie plutôt que par instance provisionnée.
• Génération améliorée par récupération (RAG) : combinaison d'un modèle de langage avec des passages récupérés à partir d'une base de connaissances au moment de la requête, de sorte que les réponses soient ancrées dans les documents du client.
• pgvector : une extension PostgreSQL qui stocke les vecteurs d'incrustation et prend en charge la recherche de similarité, permettant un magasin de vecteurs construit par le client sur Managed PostgreSQL.

Lecture supplémentaire

• Unité 6.6 : Souveraineté de l'IA et le règlement AI de l'UE (la limite de souveraineté et les rôles de l'UE-AI-Act derrière l'inférence gérée)
• Unité 5.3 : Bases de données relationnelles (Managed PostgreSQL) et Unité 5.2 : Object Storage (le niveau de stockage RAG)
• Centre d'architecture IONOS Cloud