Du portable au cluster : passer un agent IA en production avec vLLM sur OpenShift

Un agent qui tourne sur un portable est un rêve pour une personne et une seule : Qwen3 raisonne, Ollama sert, aucune donnée ne quitte la machine et la facture est nulle. Mais le rêve s'arrête dès que le capot se ferme pour rentrer à la maison, ou qu'une deuxième personne veut toucher au même esprit ; un montage une machine, un utilisateur s'effondre face à la réalité multi-utilisateur. Le présentateur construit toute sa question sur cette faille : comment transformer ce montage silencieux en un service qu'une foule peut utiliser, sans tomber dans le piège de la machine unique ?

Le montage de départ est sobre : un agent à trois outils qui porte une calculatrice, un chercheur web et une connexion GitHub MCP, avec un raisonnement fourni par le modèle ouvert Qwen3 et un service assuré par Ollama sur le portable. Comme aucune donnée ne sort du boîtier, ni souci de confidentialité ni ligne de coût ; la liberté d'essai est totale. L'hôte décrit ce confort comme un duo une personne, une machine, puis pose nettement la question de production : comment le même agent peut-il vivre sans dépendre d'un portable au capot fermé ?

L'idée la plus forte arrive dès la première minute : rien ne change à l'intérieur de l'agent — seuls changent l'endroit où le modèle est servi et celui où l'agent s'exécute. Deux gestes : Ollama cède d'abord la place à un serveur d'inférence réglé pour le trafic simultané, puis tout le montage part en conteneur vers un cluster OpenShift. La même forme marche avec des points d'accès extérieurs comme Claude ou GPT ; l'agent se moque de l'origine du raisonnement du moment qu'il dispose d'une abstraction de point d'accès . La documentation Unsloth décrit des serveurs comme Ollama et vLLM reliés par le même motif d'interface compatible OpenAI, et c'est pourquoi l'écart entre portable et cluster tient en trois lignes d'un fichier .env.

Premier geste : la couche modèle

Le premier geste vise la couche modèle. Le montage Ollama du portable est remplacé par un service vLLM via OpenShift AI ; vLLM est un projet ouvert né à Berkeley qui, selon la présentation du blog RedHat, fut conçu pour l'efficacité de la mémoire des accélérateurs et la vitesse, rassemblant plus de 40 000 étoiles sur GitHub. Comme l'explique l'article de fond de TheNewStack, le serveur porte efficacement les appels empilés sur un même modèle grâce au regroupement continu et à l'attention paginée, avec des familles prises en charge de Llama et Mistral jusqu'à Granite et DeepSeek. Dans le flux AI Hub, le modèle est tiré d'une adresse URI HuggingFace, les ressources d'accélération et un moteur d'exécution sont choisis, et le déploiement produit un lien interne pour l'accès dans le cluster, un lien externe pour l'accès du dehors, plus une clé API qui authentifie les requêtes. La différence .env tient en trois lignes : le service vLLM du cluster au lieu d'Ollama en local, la clé fraîche et l'identité de modèle qu'attend vLLM.

L'esprit de la machine est Qwen3. Selon l'annonce officielle publiée sur GitHub, le vaisseau amiral 235B-A22B rivalise avec des modèles de premier rang comme DeepSeek-R1 et Gemini-2.5-Pro sur le code et les mathématiques, tandis qu'un petit montage d'experts mélangés comme 30B-A3B et des versions denses de 0,6B à 32B sont partagés en poids ouverts sous licence Apache 2.0. Une longue fenêtre de contexte et un mode de pensée hybride rendent la famille adaptée aux charges d'agent qui appellent des outils ; le petit montage gratuit du portable dans la démonstration est le visage quotidien de cette ouverture de licence.

Second geste : conteneur et cluster

Le second geste vise l'agent lui-même. Une commande de connexion est d'abord saisie depuis la console OpenShift pour entrer dans le cluster ; puis l'image est construite avec Podman, expédiée via Quay et mise en service — Docker fait le même travail. Des commandes make dans le dépôt réduisent les étapes de construction, d'envoi et de déploiement à quelques frappes. Une minute plus tard, le point d'accès du modèle et l'agent tournent comme des pods côte à côte dans le même cluster ; le pod est planifié, l'image est tirée, et l'agent qui vivait sur un portable il y a une minute vit désormais comme un pod sur OpenShift. Pas une ligne de code n'a changé — seule l'adresse du domicile a changé.

Lors de l'essai en direct, l'agent est d'abord sondé avec une recherche web et une question de calcul, puis invité à lire un ticket sur GitHub et à en ouvrir un nouveau, le même outil MCP portant lectures et écritures depuis l'intérieur du cluster. Les journaux de dialogue se suivent dans le terrain de jeu RedHat OpenShift AI plutôt que dans un terminal local ; du modèle à l'agent jusqu'au terrain de jeu, tout tourne dans le cluster, et le montage passe au suivi en journaux intra-cluster .

Déployé ne veut pas dire prêt pour la production

La finale trace une frontière honnête : le pod peut lire tout fichier de son propre conteneur et joindre à peu près tout au dehors ; visibilité des comportements, limites de ressources, usage sûr multi-équipes, permissions confiées à l'agent et cadrage des comportements sont absents. Selon l'angle zéro confiance de l'article CNCF, le trafic réseau sans bornes et les points d'accès ouverts dans les charges IA sur clusters sont l'édition coûteuse de problèmes classiques — une clé volée n'est pas une petite fuite mais une facture qui enfle. La conception ouverte Agent Sandbox relayée par InfoQ bâtit l'isolement avec un rideau gVisor, tandis que la piste des bacs à sable éphémères présentée par Google à KubeCon vise la même brèche. Le dépôt et le manifeste attendent dans les liens ; le verrouillage reste le sujet de la prochaine vidéo.