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

Introduction

FinCorp souhaite un assistant interne capable de répondre aux questions du personnel à partir de sa propre documentation sur les politiques et les produits. La décision architecturale ne porte pas sur le modèle le plus performant, mais sur l'endroit où l'inférence est exécutée et sur qui porte la charge opérationnelle. Pour une entreprise allemande du secteur financier soumise au RGPD et aux obligations du BSI, l'option par défaut devrait être celle qui maintient les données dans le pays, n'ajoute aucune infrastructure à exploiter et ne facture que ce qui est consommé. Cette option est le AI Model Hub managé. Cette unité établit pourquoi l'inférence managée est la norme en entreprise, à quel moment un serveur GPU dédié se justifie, et comment FinCorp construit la génération augmentée par récupération à partir des primitives de la plateforme. Elle se termine en présentant un appel d'inférence fonctionnel afin que la forme de l'API soit concrète.

1. Inférence gérée par défaut en entreprise

AI Model Hub est un service d'inférence : il met à disposition des modèles pré-entraînés derrière une API, vous permettant d'implémenter des fonctionnalités d'IA sans provisionner ni maintenir le matériel sous-jacent. Pour un architecte, l'intérêt réside dans l'élimination d'une surface opérationnelle entière, à savoir les pilotes GPU, le chargement des modèles, la marge de capacité et l'application des correctifs, 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 : une API IONOS CLOUD native et une API compatible OpenAI qui reproduit la structure des requêtes et des réponses d'OpenAI. L'URL de base compatible OpenAI est https://openai.inference.de-txl.ionos.com/v1, et elle sert les routes familières : liste des 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 cadre déjà écrit pour l'API OpenAI peut être dirigé vers le hub en modifiant l'URL de base et le jeton, de sorte que le choix de FinCorp ne lie pas son code applicatif à un seul fournisseur.

Tarification par jeton. La facturation est effectuée par million de jetons, divisée entre l'entrée et la sortie, et varie selon le 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 volume de jetons, et non une instance provisionnée. Il n'y a aucun GPU qui reste inactif entre les requêtes et aucune obligation de dimensionnement préalable. Pour un assistant interne à charge variable dont l'activité suit la journée de travail, le paiement par jeton est structurellement moins coûteux que la réservation de matériel accélérateur 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 journalisées, ni enregistrées, ni réutilisées pour l'entraînement des modèles, et les données clients ne sont utilisées pour l'entraînement en aucune circonstance. L'absence d'état est une propriété de conformité, et non seulement d'efficacité : il n'y a pas de magasin de contenu conservé sur lequel le délégué à la protection des données de FinCorp doit raisonner, et aucun cycle de vie des données côté inférence à gouverner.

Traitement dans le pays. Tout le traitement et l'inférence se produisent exclusivement en Allemagne, dans le centre de données de Berlin. Les services AI Model Hub, y compris les points d'entrée d'inférence, sont hébergés dans des centres de données allemands certifiés ISO 27001. Pour FinCorp, cela résout la question de la souveraineté qui a motivé le choix de la plateforme en premier lieu : l'appel au modèle ne quitte jamais la juridiction allemande. Définissez précisément le périmètre de cette affirmation. La certification ISO 27001 est attachée aux centres de données allemands hébergeant le hub ; ce n'est pas une déclaration à l'échelle de la plateforme, et l'analyse plus approfondie des frontières de souveraineté et du rôle de la loi européenne sur l'IA relève de l'Unité 6.6.

Deux limites opérationnelles doivent être prises en compte dans la conception. Le SLA de disponibilité par service est de 99,9 %, et son périmètre est limité aux points d'entrée de l'API AI Model Hub, et non à la disponibilité par modèle ou à la qualité de l'inférence. L'API générale comporte une limite de débit de base de 5 requêtes par seconde avec un plafond de pointe de 10 ; la dépasser renvoie HTTP 429 Too Many Requests. Un client de production doit donc implémenter un recul et une nouvelle tentative plutôt que de supposer un débit illimité, et une charge de travail à forte dispersion nécessite une couche de régulation des requêtes devant le hub.

2. Quand le déploiement auto-hébergé de serveurs GPU est justifié

Le hub géré propose un catalogue fixe de modèles hébergés par la plateforme. Lorsqu'un client doit déployer son propre modèle pré-entraîné, effectuer un ajustement fin sur des données propriétaires, ou exécuter un modèle absent du catalogue, IONOS CLOUD met à disposition des serveurs Compute Engine dédiés équipés de GPU. Ces serveurs offrent un accès root à du matériel GPU de classe entreprise sur une base de paiement à l'usage, de sorte que la charge de travail s'exécute sur une infrastructure contrôlée par le client.

Le compromis consiste à assumer la responsabilité de tout ce que le service géré masquait. La formulation honnête pour un architecte est la suivante : dès que vous auto-hébergez, le SLA d'inférence devient le vôtre, et non celui du hub. Un serveur GPU unique est un matériel dédié à un seul locataire sans migration en direct, de sorte qu'une défaillance de l'hôte ou un événement de maintenance interrompt le service, à moins que vous n'ayez vous-même mis en place une redondance. Atteindre le niveau de disponibilité offert par le point d'accès géré implique d'exécuter au moins deux nœuds de service derrière un équilibreur de charge de couche 4, en plus de la gestion du chargement des modèles, des vérifications d'état, de la mise à l'échelle automatique et des correctifs. Cependant, le quota par contrat par défaut est limité à une seule instance H200-S (les modèles plus volumineux ou les instances supplémentaires nécessitent une augmentation de la limite de ressources via un ticket d'assistance avant le déploiement), et l'affectation aux zones de disponibilité est fixée sur Auto, ce qui vous empêche d'imposer explicitement la répartition des deux nœuds dans des zones distinctes. Le coût prévisible est l'avantage mis en avant par la documentation : un tarif fixe pour un service continu et permanent, plutôt qu'une facturation variable par jeton. L'auto-hébergement ne s'avère donc rentable que pour les charges de travail en régime établi et à forte utilisation, ou pour les modèles non pris en charge par le hub.

Gardez deux questions de dimensionnement distinctes. Le dimensionnement pour l'inférence est déterminé par la concurrence, les objectifs de latence et la mémoire de la fenêtre de contexte. Pour une charge élevée et stable, un GPU dédié peut être moins coûteux qu'une facturation par jeton. Le dimensionnement pour l'entraînement et l'ajustement fin relève d'un régime différent et plus exigeant : il nécessite une puissance de calcul multi-GPU soutenue sur des jeux de données propriétaires, et le chemin sur la plateforme pour cela est le serveur GPU, et non le hub d'inférence. Ne dimensionnez pas un déploiement d'inférence comme s'il s'agissait d'un cluster d'entraînement, et ne supposez pas qu'un GPU dimensionné pour l'inférence permettra d'ajuster finement un grand modèle en un temps raisonnable. L'assistant de FinCorp repose sur une inférence pure avec une charge modérée et intermittente, ce qui correspond exactement au profil que le hub géré sert le mieux. FinCorp reste donc sur le hub et ne met pas en place de serveurs GPU.

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

L'assistant de FinCorp doit répondre à partir des documents propres à FinCorp, et non à partir de l'entraînement général du modèle. Le schéma pour cela est la génération augmentée par récupération (RAG) : combiner la capacité linguistique du modèle avec des passages pertinents récupérés depuis une base de connaissances au moment de la requête. Le hub fournit les éléments côté modèle ; l'architecte compose les éléments côté stockage à partir des primitives de la plateforme.

Construisez le RAG comme une infrastructure détenue par le client avec trois composants de la plateforme :

• Embeddings depuis le hub. Convertissez chaque fragment de document en vecteur dense avec POST /v1/embeddings, en utilisant un modèle d'embedding du hub tel que BAAI/bge-m3 (documenté à 0,02 EUR par million de jetons). La même interface embarque la requête de l'utilisateur au moment de la récupération, de sorte que la requête et le corpus résident dans le même espace vectoriel.
• Vecteurs dans Managed PostgreSQL. Stockez les embeddings dans une instance Managed PostgreSQL avec l'extension pgvector. Cela vous offre une base de données relationnelle dont vous savez déjà opérer, sauvegarder et placer sur la couche de données privée, avec la recherche de similarité vectorielle en tant que requête de premier ordre. Elle se compose proprement avec tout ce que le Module 5 a établi concernant la couche relationnelle.
• Corpus dans Object Storage. Conservez les documents sources dans Object Storage en tant que système de référence, en utilisant ses fonctions de cycle de vie et de verrouillage d'objets pour la rétention. Le magasin de vecteurs contient les embeddings et les références ; le texte autorité reste dans le bucket compatible S3.

Au moment de la requête, le flux est le suivant : embarquer la question, exécuter une recherche de similarité dans PostgreSQL pour récupérer les fragments les plus proches, puis passer ces fragments comme contexte à POST /v1/chat/completions. Rien dans cette boucle n'exige un magasin de vecteurs géré, et vous conservez le contrôle total de l'emplacement des vecteurs et du corpus.

C'est un choix architectural délibéré. AI Model Hub offrait historiquement une fonctionnalité de collections de documents gérées, un magasin de vecteurs intégré avec segmentation et une interface de requête sémantique native, avec un backend chromadb par défaut et un backend pgvector optionnel. Cette fonctionnalité de magasin de vecteurs géré est en cours de retrait et ne doit pas être conçue comme une option pour l'avenir. Construisez plutôt le RAG sur les primitives durables ci-dessus : embeddings du hub, votre propre pgvector sur Managed PostgreSQL, et votre corpus dans Object Storage. Le résultat est identique en capacité, repose entièrement sur des services que FinCorp exploite déjà, et ne comporte aucun risque de dépréciation.

Déroulement de la mise en œuvre de DCD

La construction de cette unité est volontairement 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 d'obtenir un appel compatible OpenAI fonctionnel, afin que la forme de l'API soit concrète et que l'équipe applicative de FinCorp puisse l'intégrer à l'assistant. Le seul prérequis est l'accès à la gestion des jetons du contrat.

Objectif de construction : Tester un modèle et obtenir un appel compatible OpenAI 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 JSON Web Token (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 guides pratiques du hub supposent que le jeton est conservé dans la variable d'environnement IONOS_API_TOKEN. Définissez-la dans votre shell plutôt que de coller le jeton littéral dans des scripts ou du contrôle de code source.
3. Lister les modèles disponibles. Confirmez la connectivité et découvrez les identifiants de modèles en appelant la route des modèles compatible OpenAI à 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 n'importe quel prompt.
4. Envoyer une complétion de chat. Appelez POST /v1/chat/completions contre l'URL de base avec un identifiant model issu de l'étape 3 et un tableau messages. C'est l'appel d'inférence principal que l'assistant de FinCorp effectuera.
5. Intégrer l'appel fonctionnel dans l'application. Une fois que l'appel renvoie une réponse, transmettez-le à l'équipe applicative en tant que configuration client de référence : URL de base, identifiant du modèle et convention du jeton Bearer. Toute bibliothèque compatible OpenAI fonctionne désormais en définissant uniquement l'URL de base et le jeton.

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

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 de mauvais type. Le jeton Bearer est un JWT avec une revendication exp. Les échecs d'authentification sont généralement dus à un jeton expiré ; régénérez-le et réinitialisez IONOS_API_TOKEN, plutôt que de considérer qu'il s'agit d'une requête mal formée.
• Coder le jeton en dur dans des scripts ou des dépôts. Le jeton n'est affiché qu'une seule fois et accède à l'inférence payante. Conservez-le dans IONOS_API_TOKEN, excluez-le de la gestion de code source et faites-le tourner selon le calendrier habituel.
• Pointer le client vers l'URL de base incorrecte. L'URL de base compatible OpenAI est https://openai.inference.de-txl.ionos.com/v1. Un client configuré pour l'hôte OpenAI générique échouera ; seules l'URL de base et le jeton doivent changer lors de la migration d'un client OpenAI.
• Supposer un débit illimité. La limite de débit de base est de 5 requêtes par seconde, avec une rafale de 10, et le service renvoie HTTP 429 en cas de dépassement. Intégrez le recul et la réessai dans le client et régulez les charges de travail à forte diffusion ; ne considérez pas le point d'accès comme élastique.
• Concevoir sur le magasin vectoriel de collections de documents gérées. Il est en cours de retrait. Construisez le RAG sur les intégrations du hub, ainsi que sur votre propre pgvector sur Managed PostgreSQL et Object Storage à la place.
• Interpréter le SLA de 99,9 % comme une garantie de qualité ou par modèle. Il ne couvre que les points d'accès de l'API, et non la disponibilité d'un modèle spécifique ni la qualité de l'inférence.

Résumé

Pour une entreprise soumise à des réglementations, l'inférence managée sur AI Model Hub est la solution par défaut : une API compatible OpenAI, une tarification par jeton sans GPU inactif à financer, un service sans état qui ne conserve rien, et un traitement limité aux centres de données allemands. Le déploiement d'inférence sur GPU auto-hébergé sur du matériel dédié n'est justifié que lorsque vous avez besoin d'un modèle non pris en charge par le hub, que vous effectuez un ajustement fin, ou qu'une charge stable à forte utilisation rend le calcul à tarif fixe moins coûteux, et cela fait de l'engagement de service (SLA) et de la redondance pour l'inférence votre responsabilité. L'assistant de FinCorp correspond au profil managé, il consomme donc directement le hub et construit la génération augmentée par récupération à partir des embeddings du hub, pgvector sur Managed PostgreSQL, et un corpus dans Object Storage, évitant ainsi complètement le magasin de vecteurs managé en cours de dépréciation.

Points clés :

• L'URL de base compatible OpenAI est https://openai.inference.de-txl.ionos.com/v1 ; pour rediriger un client OpenAI, il suffit de modifier l'URL de base et le jeton Bearer.
• La tarification est par million de jetons et varie selon le modèle ; il n'y a pas d'instance provisionnée, donc le volume de jetons 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 l'entraînement. Le SLA de 99,9 % ne couvre que les points d'entrée API.
• Auto-hébergez sur des serveurs GPU uniquement pour les modèles non pris en charge, l'ajustement fin, ou une charge stable à forte utilisation, en acceptant que vous devenez alors responsable du SLA et de la redondance.
• Construisez la RAG comme étant de propriété client : embeddings du hub, vecteurs dans pgvector sur Managed PostgreSQL, corpus dans Object Storage. N'adoptez pas le magasin de vecteurs managé en cours de dépréciation.

Terminologie importante :

• API compatible OpenAI : une surface API qui reproduit la structure des requêtes et des réponses d'OpenAI, permettant aux clients OpenAI existants de fonctionner en modifiant uniquement l'URL de base et le jeton.
• Tarification 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 augmentée par récupération (RAG) : combinaison d'un modèle de langage avec des passages récupérés d'une base de connaissances au moment de la requête, afin que les réponses soient ancrées dans les documents propres au client.
• pgvector : une extension PostgreSQL qui stocke des vecteurs d'embeddings et prend en charge la recherche de similarité, permettant un magasin de vecteurs construit par le client sur Managed PostgreSQL.

Pour aller plus loin

• Unité 6.6 : Souveraineté de l'IA et Règlement européen sur l'IA (la frontière de souveraineté et les rôles du Règlement européen sur l'IA derrière l'inférence managée)
• Unité 5.3 : Bases de données relationnelles (Managed PostgreSQL) et Unité 5.2 : Object Storage (la couche de stockage RAG)
• IONOS CLOUD Architecture Center