6 Par Giorgio Regni, directeur technique, Scality. 8 octobre 2026. La plupart des organisations ont découvert l’IA via une API cloud, et pour des projets pilotes, c’était le bon choix. La production, c’est une autre histoire. Dès que les agents entrent dans le travail quotidien, les volumes de tokens se multiplient, chaque requête transporte du code et des documents propriétaires, et le modèle derrière un workflow validé peut changer selon le calendrier de quelqu’un d’autre. Dans l’enquête IDC de juin 2026 menée auprès de 1 015 décideurs infrastructure, 85 % d’entre eux estiment que leurs charges de travail IA exigent une infrastructure hybride, entre sur site et cloud public, avec un intérêt croissant pour les systèmes clés en main, motivé par les enjeux de souveraineté des données. La question pratique devient alors : quelles charges de travail rapatrier en premier sur site ? La réponse porte généralement sur les usages à fort volume, actifs en permanence et qui touchent des données sensibles, avec les agents de développement en tête de liste. Ce sont aussi les charges les plus difficiles à opérer soi-même. Que faut-il pour exécuter l’inférence IA sur sa propre infrastructure, à l’échelle de toute l’organisation ? Chaque session d’agent transporte un contexte que le modèle doit lire avant de pouvoir répondre : le dépôt de code, le prompt système, les définitions d’outils, la conversation jusqu’ici. Le modèle n’en garde rien d’une requête à l’autre. Chaque fois qu’un développeur revient, un GPU recalcule ce contexte de zéro ou le relit depuis l’endroit où il a été stocké. À grande échelle, ce choix détermine le coût de l’inférence, et c’est pour cela qu’un spécialiste du stockage livre aujourd’hui une pile d’inférence : la partie la plus difficile du service d’un modèle s’est révélée être la mémoire. Scality AI Inference Factory, lancée le 8 octobre 2026, est une pile à code ouvert construite sur Scality ADI (AI Data Infrastructure) pour exécuter des modèles open-weight sur votre propre infrastructure. Elle est disponible sous forme de licence logicielle ou de service entièrement managé. Vos agents de développement relisent la même base de code toute la journée Chaque reprise de session est un choix entre recalculer le contexte et le relire. Imaginez dix mille développeurs qui ouvrent leurs agents de code un lundi matin. Chaque session charge le même dépôt, le même prompt système et les mêmes définitions d’outils. À l’heure du déjeuner, chaque agent a relu ce contexte des dizaines de fois, et le développeur qui s’absente pour une réunion s’attend à ce que sa session reprenne là où elle s’était arrêtée. Les mesures publiées montrent l’ampleur du phénomène. Dans une étude des charges de travail agentiques publiée cette année, 84,6 à 99,5 % des tokens d’entrée étaient réutilisés depuis le cache d’un tour à l’autre. La même étude constate que le taux de succès du cache chute d’environ 98 % à 16-26 % lorsque trop d’agents simultanés saturent le cache. Le modèle oublie tout entre deux requêtes. Il faut donc autre chose pour conserver ce contexte, et chaque fois qu’il manque, un GPU doit recalculer un travail déjà fait. Tokens en cache : dix fois moins chers, et ce n’est pas un hasard La plupart des grands fournisseurs facturent un token d’entrée en cache environ dix fois moins cher qu’un token hors cache, ce qui montre bien que recalculer le contexte est un coût à éviter. Les tarifs publiés par Anthropic, par exemple, facturent un accès au cache à 0,1 fois le prix d’entrée, et moins encore sur ses modèles les plus récents. Le cache épargne au fournisseur le recalcul. La remise vous rétrocède une partie de cette économie, et le fournisseur conserve sa marge. Quand la plupart des tokens de vos développeurs sont répétés, vous payez le même contexte, tour après tour. Les fournisseurs ont construit ce cache parce que recalculer le contexte coûte cher. Sur vos propres serveurs, ce cache repose sur du matériel déjà déployé et ne vous coûte rien de plus. Ce cache est volumineux, et nous l’avons mesuré dans notre propre laboratoire client. Une seule session GLM-5.2 avec un contexte de 438 764 tokens a produit 189 Go de cache KV, soit environ 430 Ko par token. Avec le modèle réparti sur les huit GPU de notre serveur, cette seule session ne tenait pas en HBM et a dû être déportée vers un stockage externe. Dix mille sessions de ce type nécessiteraient environ 1,9 Po. Le cache ne tient ni dans la mémoire GPU ni dans la DRAM d’un serveur. Dans les architectures GPU à mémoire désagrégée, chaque GPU doit pouvoir accéder à n’importe quel token en cache. À cette échelle, la mémoire devient un problème de stockage, et le stockage, Scality l’opère en production continue depuis 2009. L’idée reçue veut que le stockage soit trop lent pour se trouver sur le chemin de service, où chaque milliseconde avant le premier token compte. Nous avons passé l’année écoulée à vérifier si c’est encore vrai. Nous avons relié des GPU au stockage objet et tout mesuré Avec le cache servi depuis Scality ADI, nous avons mesuré un délai avant le premier token (TTFT) de 166 ms sur un contexte de 14 000 tokens, à seulement 83 ms de la mémoire GPU, et contrairement à la mémoire GPU, la capacité augmente à mesure que l’on ajoute du stockage. Nous avons connecté des GPU directement à Scality ADI en RDMA, sans passer par le CPU sur le chemin des données, et mesuré les résultats. Le laboratoire était volontairement modeste : un serveur à huit GPU, cinq serveurs de stockage vieux de quelques générations et quatre liens RDMA à 100 Gbit/s. Le réseau était le facteur limitant en laboratoire, et le produit fonctionnait sur une fabric à 400 Gbit/s. vLLM découpe le cache KV en blocs de taille fixe et attribue un nom à chacun, ce qui permet à Scality ADI de stocker chaque bloc comme un objet. Même avec S3 sur RDMA, chaque lecture d’objet passe encore par le plan de contrôle S3, conçu pour l’internet public : signature des requêtes, contrôles de politique, recherches de métadonnées, sommes de contrôle et encapsulation XML, à chaque requête. Le Scality AI Connector le remplace par notre propre plan de contrôle allégé, avec une authentification en une seule passe et sans encapsulation XML ni multipart : le chemin de contrôle s’exécute en quelques microsecondes et le modèle objet reste inchangé. Pour une lecture, le GPU réserve de l’espace dans sa mémoire et indique à Scality ADI quel objet y placer. Le GPU ne pilote jamais lui-même le transfert ; c’est Scality ADI qui s’en charge. Le disque NVMe TLC place l’objet dans la RAM du serveur de stockage via PCIe, et la carte réseau l’envoie directement dans la mémoire GPU en RDMA. Les données contournent le CPU, le noyau et la pile logicielle : c’est ainsi que le connecteur atteint 97 % du débit nominal du réseau entre les GPU et le stockage. Recalculer le contexte de 14 000 tokens a pris 2,3 secondes, soit 14 fois plus que le relire. Sur un modèle plus gros, l’écart se creuse. Pour GLM-5.2 avec un contexte de 438 764 tokens, le recalcul a pris 529 secondes et la relecture 7,3 secondes, soit 72 fois plus rapide. Lors d’un second test, avec 8 instances vLLM (une par GPU), Scality ADI a conservé 8 To de cache KV, soit plus de 80 fois la mémoire d’un GPU et environ dix fois celle du serveur entier. Le premier token est resté entre 355 et 373 ms à toutes les tailles, de 69 Go à 8 To. La latence entre tokens n’a pas changé : la récupération se termine avant le premier token, et chaque token suivant est produit depuis la mémoire GPU. Comme le cache réside dans Scality ADI plutôt que dans un seul serveur, chaque GPU peut y accéder, et c’est ce qui rend possible le service désagrégé : exécuter les deux phases de l’inférence sur des pools de GPU distincts. Le prefill calcule le cache KV d’un nouveau prompt, et le decode génère la réponse, un token à la fois. Quand les deux tournent sur les mêmes GPU, chaque nouveau prefill interrompt les decodes en cours. Une fois séparés, chaque pool se consacre à une seule tâche à plein temps et évolue indépendamment, les deux travaillant à partir du même cache KV partagé. Les travaux de recherche sur lesquels cela repose sont publics. DistServe (OSDI 2024) a mesuré jusqu’à 7,4 fois plus de requêtes par GPU pour les mêmes objectifs de latence, en transférant le cache directement entre GPU. Dans notre architecture, le prefill écrit plutôt le cache KV dans Scality ADI, et le decode le relit : n’importe quel GPU de decode peut ainsi reprendre n’importe quel contexte, et ce niveau de stockage n’impose pratiquement aucune limite à la taille du cache. Le même chemin sert à charger les modèles. Les 54,86 Go de poids du modèle Gemma-3 27B se sont chargés dans un GPU en 1,9 seconde depuis Scality ADI, près de dix fois plus vite que depuis les disques locaux du serveur GPU, car la lecture se fait simultanément sur de nombreux disques du niveau de stockage. Selon la charge, un GPU peut changer de modèle jusqu’à mille fois par jour. Chaque couche au-dessus du stockage a dû être corrigée Nous avons soumis chaque correctif en amont. Le moteur de service, les chargeurs de poids, les outils de transfert de données et la fabric avaient tous été écrits pour un stockage lent et de faible capacité. Aucun ne s’attendait à un niveau distant répondant à la vitesse du matériel. Plusieurs ont cédé d’une manière qui n’apparaît que lorsqu’on mesure le côté stockage de l’inférence. Le cas le plus flagrant était le connecteur de déchargement KV de vLLM, qui récupérait environ cinq fois plus de blocs de cache que nécessaire à chaque restauration. Quiconque utilisait ce connecteur pour décharger vers un stockage objet payait cette taxe. Nous avons corrigé le connecteur, sans toucher au cœur de vLLM, et intégré le correctif en amont, si bien que tous les stockages objet situés derrière ce chemin en profitent. Nous avons également étendu ModelExpress, le chargeur de modèles open source, pour qu’il récupère les poids directement depuis le stockage objet. Il n’existe aucun fork Scality dans la pile. Nous packageons la pile, maintenons chaque couche à jour au fil de l’évolution des modèles et des moteurs de service, et pouvons l’exploiter pour vous. Vous maîtrisez le modèle, les données et les coûts Vous conservez votre environnement, choisissez parmi des modèles open-weight validés et décidez du moment où quoi que ce soit change. Vos développeurs gardent les outils qu’ils utilisent déjà et modifient un seul paramètre : le point de terminaison d’inférence passe de l’API cloud au vôtre. Claude Code, Codex, OpenCode et les autres outils de vos développeurs continuent de fonctionner comme avant. Le modèle que vous choisissez reste celui que vous exécutez. Version, quantification et retrait évoluent quand vous le décidez (et non quand un fournisseur réorganise son parc), si bien qu’un résultat validé en mars se reproduit en septembre. Si vous vendez de l’IA intégrée à votre propre produit, cette reproductibilité fait partie de votre promesse client. Le contexte, lui aussi, reste chez vous. Une API externe ne reçoit jamais une simple question : elle reçoit la base de code, les documents récupérés et la sortie de chaque outil appelé par l’agent. Sur votre propre infrastructure, rien de tout cela ne quitte votre périmètre. Tout reste sous votre juridiction, et personne en dehors de votre entreprise ne peut le couper. L’ensemble de la pile peut être exploité de manière sécurisée. Le coût fonctionne aussi différemment. Une facture d’API au compteur augmente avec chaque token, donc plus vite encore lorsque l’adoption fonctionne. Sur vos propres serveurs, le budget est fixe, et plus vos équipes l’utilisent, moins chaque token coûte cher. Ce que vous déployez Scality AI Inference Factory réunit toute la pile de service derrière un point de terminaison unique. Elle comprend vLLM, Dynamo, le Scality AI Connector, Scality ADI, et bien plus. Les familles de modèles open-weight validées incluent Mistral, Gemma, gpt-oss, Qwen, Kimi, GLM et DeepSeek. La pile se déploie sur des serveurs standard Dell, HPE, Lenovo et Supermicro. Vous recevez le code source, pouvez auditer la manière dont l’état d’inférence est stocké et déplacé, et pouvez soumettre des modifications à la revue de nos ingénieurs. Le niveau de stockage sous-jacent gère déjà plus de 12 Eo en production dans plus de 70 pays. Échangez avec un architecte IA Scality sur votre charge de travail. Apportez votre trafic et un dépôt de code, et nous le dimensionnerons avec vous. Cessez de payer pour reconstruire un contexte que vous avez déjà. Découvrez l’inférence IA sur site avec Scality et permettez à vos équipes d’exploiter l’IA selon leurs propres conditions.
