Le KV cache sort du GPU : Scality met le stockage dans le chemin d'inférence

Ce qui s'est passé

Le 8 octobre 2026, l'entreprise d'infrastructure de données Scality a annoncé à San Francisco la disponibilité immédiate d'AI Inference Factory. C'est une pile logicielle open-code permettant aux entreprises, organismes publics et fournisseurs neo-cloud de déployer et d'exploiter l'inférence IA sur leur propre infrastructure ; selon le communiqué, une alternative supportée aux services d'IA cloud, sans assembler toute la pile à partir de zéro.

La pile comprend quatre parties : des modèles ouverts validés et maintenus dans la pile ; une couche de service d'inférence désagrégée, avec prefill et decode mis à l'échelle indépendamment ; un plan de contrôle avec authentification, comptage, routage vers les GPU détenant le contexte pertinent et ordonnancement par SLA ; et Scality ADI, une infrastructure autonome de gestion des données sous gouvernance de politiques, qui joue le rôle de couche de stockage partagé.

Proposée en licence logicielle ou en service entièrement géré, elle a été démontrée au Scality Day à Paris le 8 octobre. Scality dit valider, livrer et maintenir la pile intégrée pour suivre le rythme des modèles, des technologies de service et des exigences de sécurité.

[1]

Pourquoi maintenant

Le communiqué résume la motivation en trois factures. Premièrement : avec la tarification cloud au token, plus le workflow est utile, plus la facture est imprévisible, et impossible à plafonner. Deuxièmement : versions et quantifications peuvent changer à la discrétion du fournisseur, ébranlant les workflows construits dessus. Troisièmement : où sont traités prompts, documents et code propriétaire, sous quelle juridiction, et qui peut couper l'accès ; les trois questions de souveraineté pour les données sensibles et régulées. Le pari de Scality : la plupart finiront en hybride, avec les processus IA critiques on-premises.

Le communiqué cite l'analyste IDC Nataliya Yezhkova : là où l'infrastructure peut héberger et servir efficacement l'état des modèles, l'inférence locale est une option crédible pour un nombre croissant de charges d'entreprise et du secteur public. Note : c'est une citation d'appui dans le communiqué du fabricant, pas un rapport indépendant d'IDC.

[1]

La substance technique

Le morceau le plus solide est la conception de Scality ADI comme couche partagée de KV cache. En inférence, le KV cache croît avec la longueur du contexte et déborde vite la HBM du GPU ; l'approche conventionnelle le laisse sur le serveur GPU où il est né. L'approche Scality : ADI fournit un cache partagé multipetabyte que les GPU lisent avec une latence du même ordre que la mémoire GPU, restaurant le contexte depuis le stockage au lieu de le recalculer, avec une meilleure utilisation des GPU et un coût réduit.

Avec la désagrégation prefill/decode : un pool de GPU ne fait que le prefill et écrit le KV cache dans ADI ; un autre ne fait que le decode, le relisant pour générer les tokens. N'importe quel GPU de decode peut reprendre n'importe quel contexte, le prefill n'interrompt plus le decode, et les deux pools tournent à plein.

Les mots du CTO Giorgio Regni méritent d'être consignés : le KV cache sur ADI est assez rapide pour rester dans le chemin de service ; restaurer un contexte depuis ADI est du même ordre que la mémoire GPU et 14 fois plus rapide que le recalcul, avec des GPU occupés en permanence ; le stockage n'est plus une raison de garder le KV cache dans le serveur GPU. Le CEO Jérôme Lecat cadre le récit de souveraineté : les organisations ont besoin de plus de contrôle sur où tourne l'inférence, comment les modèles sont gérés et ce qu'il advient de leurs données.

[1]

Lire les chiffres

Scality a publié des chiffres de ses propres tests, sans vérification indépendante : Gemma-3 27B chargé en 1,9 seconde via RDMA en parallèle sur le cluster, environ 10 fois le NVMe local ; 166 ms de warm time-to-first-token en restaurant un contexte de 14K tokens depuis ADI, seulement 83 ms derrière HBM ; récupération du KV cache 14 fois plus rapide que le recalcul à 14K, 72 fois à 439K ; cache de plus de 80 fois la mémoire d'un GPU, avec 1 000 sessions concurrentes reprenables sans recalcul ; 97 % de la vitesse de ligne entre GPU et stockage ; contexte restauré avant le premier token, sans impact mesurable sur la génération.

Pour la désagrégation elle-même, le communiqué cite deux études publiques tierces : DistServe (OSDI 2024), jusqu'à 7,4 fois plus de requêtes sous les mêmes objectifs de latence ; Mooncake, 75 % de requêtes en plus sur le trafic de production de Kimi. Ce sont des chiffres de recherche publique, pas des tests Scality ; il faut les séparer des chiffres du fabricant.

Les conditions de point idéal sont explicites : 14K et 439K sont les longueurs choisies par le communiqué ; l'absence d'impact mesurable dépend d'une restauration achevée avant le premier token, sans distribution de latence de queue publiée. Jusqu'à reproduction tierce, la planification de capacité doit décoter les chiffres du fabricant et exiger des mesures sur votre propre distribution de contextes.

[1]

Souveraineté et ouverture

La liste de compatibilité est large : frameworks OpenCode, Hermes, Goose, LangGraph et Pydantic AI ; modèles ouverts validés dont Mistral, Gemma, gpt-oss, Qwen, Kimi, GLM et DeepSeek ; serveurs standard Dell, HPE, Lenovo et Supermicro. Tout est livré en open code : le client peut inspecter comment l'état d'inférence est stocké et déplacé, et proposer des contributions, mais Scality les revoit ; l'ouverture est réelle, et le gardien aussi.

Deux factures à régler. Premièrement : open code avec révision Scality n'est pas la même chose que l'open source purement communautaire ; c'est plus proche de l'open source commercial à tronc contrôlé par le fabricant. Il faut s'enquérir des critères de révision, des SLA de correctifs de sécurité et des limites de support après un fork. Deuxièmement : une fois le KV cache devenu un actif persistant, auditable et portable entre GPU, prompts et documents reposent dans le stockage partagé sous forme de cache ; politique de résidence, chiffrement, audit d'accès et sémantique de suppression doivent être reconstruits ; le communiqué promet gouvernance de politiques et cycles de vie approuvés par des humains pour ADI, mais reste vague sur les mécanismes, exactement le détail qu'un acheteur régulé doit verrouiller avant de signer.

[1]

Implications et actions

Trois implications pour les équipes envisageant l'inférence locale ou souveraine. Premièrement : les variables d'optimisation des coûts changent ; taux de succès du KV cache, latence de restauration et ratios prefill/decode pèsent désormais autant que le nombre de GPU achetés ; exigez du fabricant des mesures sur votre distribution de contextes, pas les chiffres de point idéal du communiqué.

Deuxièmement : le plan de contrôle décide de la pile ; authentification, comptage, routage et ordonnancement par SLA déterminent si l'inférence locale est un service exploitable ou un tas de GPU nus ; que Scality le mette parmi les quatre parties montre qu'il comprend la logique d'achat enterprise, et l'acheteur devrait réceptionner sur la même liste.

Troisièmement : trois choses ne peuvent pas encore être affirmées ; sans reproduction indépendante, décotez les chiffres dans votre planification ; zéro client publié, donc stabilité en production et chemins de mise à jour inconnus ; et la pile locale échange la facture au token contre des coûts fixes d'amortissement matériel, d'énergie et d'exploitation : plus prévisible n'est pas moins cher, et le TCO exige vos propres données de charge. Le récit de souveraineté doit atterrir au plan des données : les poids ouverts ne sont que la première étape ; la résidence et la juridiction du KV cache, des prompts et des logs d'audit sont le vrai test.

[1]