L'infrastructure IA dépasse désormais l'ère où elle ne servait qu'une seule requête de modèle à la fois. Un agent intelligent de niveau prod...
L'infrastructure IA dépasse l'époque où elle ne traitait qu'une seule requête modèle à la fois.
Un agent de production ne se contente pas de recevoir une requête et de renvoyer une réponse. Il peut décomposer une tâche en plusieurs étapes, appeler des outils externes, maintenir un contexte, coordonner des sous-agents, examiner les résultats intermédiaires et rester actif pendant de longues périodes. Lorsqu'une entreprise déploie des milliers de ces agents simultanément, les besoins en infrastructure diffèrent radicalement de ceux de l'inférence d'un chatbot classique.
Lors du sommet 2026 Open Compute Technology à Pékin, Inspur a proposé deux directions d'infrastructure pour cette nouvelle charge de travail :
La première direction met l'accent sur l'échelle : maintenir en ligne un grand nombre d'agents à longue durée de vie. La seconde direction se concentre sur la qualité : permettre à plusieurs modèles aux atouts différents de collaborer, plutôt que de forcer un seul modèle à traiter chaque partie d'une tâche difficile.
L'inférence traditionnelle des grands modèles suit généralement un schéma simple :
En revanche, le chemin d'exécution d'une application agent est beaucoup plus long.
Une seule tâche métier peut impliquer :
Par conséquent, l'infrastructure doit non seulement prendre en charge l'inférence du modèle, mais aussi un grand nombre de processus logiciels persistants.
Dans un environnement d'entreprise, le nombre d'agents actifs peut passer de dizaines à des milliers, voire des dizaines de milliers. Certains agents peuvent fonctionner en continu, tandis que d'autres sont créés dynamiquement pour des tâches courtes et détruits une fois terminées.
Cela modifie l'équilibre entre les ressources CPU et GPU.
Le GPU reste indispensable pour :
Le CPU gère une grande partie du travail périphérique :
Le modèle peut être responsable de la génération de raisonnement ou de texte, mais le CPU exécute généralement l'environnement d'exploitation des agents.
Par conséquent, l'infrastructure des agents passe d'une conception centrée sur le GPU à un système où le CPU, le GPU, le réseau, le stockage, le refroidissement et les logiciels d'orchestration collaborent.
Dans les serveurs d'entreprise classiques, la densité CPU a toujours été limitée par la consommation électrique, le refroidissement, l'espace, le câblage, les ventilateurs et les besoins de maintenance.
Le déploiement d'agents modifie le modèle économique.
Si des milliers d'agents ont besoin de ressources CPU pour l'orchestration, l'appel d'outils et l'isolation de l'environnement d'exécution, les racks à faible densité CPU occuperont davantage de surface de salle informatique, de connexions réseau et d'infrastructure associée.
Parallèlement, les centres de données IA évoluent vers des puissances de rack plus élevées.
Selon des sources, Inspur prévoit que la puissance des racks IA en Chine approchera les 300 kilowatts, tandis que certaines conceptions mondiales s'orientent déjà vers des systèmes de rack à l'échelle du mégawatt. Le refroidissement par air traditionnel, généralement limité à quelques dizaines de kilowatts par rack, devient de plus en plus difficile à cette densité.
Par conséquent, le refroidissement liquide n'est plus un problème exclusif au GPU.
Les racks CPU qui soutiennent les charges de travail des agents doivent également s'adapter à l'architecture de puissance et de refroidissement de la prochaine génération de centres de données IA.
Inspur a lancé ce qu'elle présente comme le premier serveur rack refroidi par liquide natif CPU au monde.
Ce système est basé sur l'architecture OCM 2.0 refroidie par liquide et prend en charge les processeurs x86 et Arm.
Ses principaux paramètres sont les suivants :
| Caractéristique | Paramètre rapporté par le fabricant |
|---|---|
| Nombre maximal de CPU par rack | 384 |
| Nombre d'agents concurrents supportés | Plus de 40 000 |
| Architecture des processeurs | x86 et Arm |
| Plage de refroidissement | CPU, mémoire, SSD, carte réseau, module optique et autres composants générant de la chaleur |
| Densité de calcul | 4 CPU intégrés dans un espace 0,5U |
| Méthode de maintenance | Maintenance complète du cycle de vie du refroidissement liquide |
| Scénarios cibles | Centres de données IA haute densité et à l'échelle du gigawatt |
Ce système ne considère pas le refroidissement liquide comme un ajout après la conception du serveur.
Au contraire, la disposition du calcul et l'architecture de refroidissement sont développées en collaboration.
Les serveurs traditionnels à plaque froide
peuvent refroidir directement le processeur, mais la mémoire, le réseau, le stockage, les composants d'alimentation et d'autres dispositifs doivent encore compter sur les ventilateurs pour le refroidissement.
À mesure que la densité augmente, cette approche devient moins efficace.
L'architecture de refroidissement liquide natif d'Inspur intègre les principaux composants générant de la chaleur dans un système de refroidissement unifié :
Cela réduit la dépendance au flux d'air interne, permettant une disposition plus compacte des composants.
Ci-dessous se trouvent trois icônes bleues intitulées « Architecture de refroidissement liquide », « Connexion de refroidissement liquide » et « Maintenance de refroidissement liquide ». Cette image est étroitement liée au contexte et présente visuellement l’état d’exposition des serveurs à architecture de refroidissement liquide d’Inspur, en écho à la conception d’architecture de refroidissement liquide décrite dans le document.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)
Ce rapport décrit une unité de calcul compacte intégrant plusieurs groupes de processeurs et composants périphériques dans un boîtier fin et léger.
L’objectif de conception est de récupérer l’espace occupé par les éléments suivants :
La disposition plate des composants permet à une seule grande plaque froide de couvrir davantage de zones du système.
Le rack adopte une conception interne sans câble ou avec un nombre réduit de câbles, permettant une maintenance sans interruption. Inspur indique que cela améliore l’efficacité du déploiement et de la maintenance des racks complets.
OCM est l’abréviation de Open Compute Module.
L’architecture modulaire vise à découpler le module processeur de la conception globale du système. Cette conception permet de prendre en charge plus facilement des processeurs de différentes générations ou architectures sans avoir à reconcevoir le rack complet pour chaque processeur.
Pour les entreprises et les opérateurs de centres de données, cette solution peut offrir les avantages suivants :
Les résultats réels dépendent de la compatibilité de l’écosystème, de l’interopérabilité et de la disponibilité des composants associés.
Exécuter des dizaines de milliers d’agents pour résoudre des problèmes de capacité n’améliore pas automatiquement la qualité des réponses.
Les grands modèles de langage ont chacun leurs spécialités.
Certains modèles peuvent être plus performants dans :
Même les modèles de très grande taille ont des lacunes.
Lorsqu’ils traitent des tâches complexes, un seul modèle peut omettre des questions clés que d’autres modèles pourraient identifier. Un modèle unique peut également fournir une réponse avec assurance, sans révéler d’incertitude ni envisager d’autres interprétations.
C’est pourquoi le deuxième axe d’infrastructure d’Inspur se concentre sur la collaboration multi-modèles.
L’API de fusion multi-modèles EPAI distribue en parallèle des tâches complexes à plusieurs modèles candidats.
Chaque modèle génère indépendamment une réponse. Un modèle d’examen et de fusion compare ensuite les réponses candidates pour identifier :
Non pris en charge :
La plateforme génère ensuite une réponse synthétique.
Il ne s’agit pas d’un simple vote majoritaire ni d’une concaténation directe de toutes les réponses. Le flux de travail attendu est le suivant :
Selon le rapport d’Inspur, ce système a atteint 53,9 % dans l’évaluation DRACO, surpassant chaque modèle individuel du pool de candidats utilisé dans ce test.
Ce résultat doit être considéré comme une référence rapportée par la plateforme, et non comme une affirmation que la fusion de modèles dépasse toujours le meilleur modèle unique. Les performances dépendront des modèles candidats, du modèle d’évaluation, de la logique de routage, du type de tâche, des invites et de la méthode de notation.
Si chaque requête exécutait plusieurs modèles, cela augmenterait inutilement les coûts et la latence.
C’est pourquoi EPAI distingue les tâches courtes et prévisibles des tâches complexes.
Un modèle léger peut suffire pour :
Plusieurs modèles peuvent être utiles pour :
Ce principe de routage est essentiel pour les systèmes de production.
La collaboration multi-modèles est la plus précieuse lorsque l’amélioration potentielle de la qualité compense les coûts supplémentaires en tokens, le temps GPU et la latence de réponse.
L’API EPAI est conçue pour cacher l’orchestration multi-modèles derrière une interface unifiée.
Les développeurs envoient une requête à la plateforme. EPAI gère :
La même interface peut être intégrée dans des applications agents et des frameworks de développement, sans que chaque équipe ait besoin de construire un système personnalisé de routage et d’évaluation de modèles.
Cette architecture convient aux entreprises utilisant un mélange de :
Le principal défi opérationnel est que plusieurs grands modèles peuvent devoir être disponibles simultanément. Cela impose des exigences plus élevées en matière de mémoire accélératrice, de bande passante d’interconnexion, d’ordonnancement et de communication à faible latence.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
Le super nœud MetaBrain SD200 est la plateforme matérielle qui soutient le flux de travail de fusion multi-modèles.
Ce système adopte une architecture de communication à mémoire sémantique à faible latence multi-hôtes. Selon Inspur, il peut interconnecter 64 accélérateurs GPU nationaux au sein d’un même système.
Sa conception comprend :
Capacités
Ce super nœud pourrait, selon les dires, prendre en charge un modèle unique de jusqu’à quatre trillions de paramètres, ou plusieurs modèles de l’ordre du trillion utilisés simultanément par des applications agents.
Inspur rapporte que le SD200 a réduit le temps de génération d’un token unique pour le modèle Kimi K2.6 de l’ordre du trillion à 4,77 millisecondes.
La société indique également que le temps de génération du premier token a été réduit de 35 % par rapport à l’implémentation précédente.
Ces données concernent des environnements d’optimisation et de test spécifiques et ne doivent pas être interprétées comme une latence garantie pour chaque modèle, déploiement, longueur d’invite, niveau de concurrence ou charge de travail de production.
Ces améliorations sont attribuées à plusieurs technologies.
Les modèles autorégressifs génèrent généralement un token, valident le nouvel état, puis génèrent le suivant.
La prédiction multi-token tente de générer plusieurs tokens candidats en une seule étape et de les valider ensemble.
Lorsque la précision de la prédiction est élevée, cela peut réduire le nombre de tours de décodage séquentiel.
L’optimisation a utilisé des poids INT4 et le calcul d’activation INT8 dans une partie de la charge des modèles experts mixtes.
Par rapport au calcul BF16, cela peut réduire :
La quantification peut affecter la qualité du modèle, donc les équipes de production doivent évaluer la précision en fonction de leurs propres charges, et non uniquement des résultats de vitesse.
La compilation JIT génère des noyaux d’accélérateur spécialisés à l’exécution en fonction de la forme, de la disposition et du type de données des tenseurs.
Par rapport aux implémentations statiques génériques, les noyaux spécialisés peuvent réduire les branches inutiles et améliorer l’accès mémoire.
Le préremplissage de l’invite et le décodage des tokens ont des caractéristiques de performance différentes.
Séparer les deux phases permet d’allouer les ressources de manière différenciée et de transférer de manière asynchrone le cache KV, réduisant ainsi la contention entre le calcul et la communication.
Inspur indique que le SD200 a terminé l’optimisation des performances pour plusieurs modèles open source majeurs, notamment :
La compatibilité ne signifie pas nécessairement que chaque modèle atteint la même latence ou le même débit.
L'architecture du modèle, le nombre de paramètres, la conception du MoE, la longueur du contexte, la quantification, le traitement par lots et les logiciels de service influencent tous les performances.
Le supernœud à 64 accélérateurs est adapté aux grands projets d'infrastructure d'IA, mais il est trop vaste et trop coûteux pour de nombreuses entreprises.
Inspur a également lancé le MetaBrain SD200 Édition Entreprise.
L'édition Entreprise réduit le domaine de calcul à extension verticale de 64 à 16 accélérateurs, visant le déploiement local de modèles à des milliards de paramètres.
Les caractéristiques annoncées incluent :
Cette édition Entreprise cible principalement les charges de travail suivantes :
Elle offre un point d'entrée plus réduit aux organisations qui ont besoin d'un contrôle local du modèle mais ne peuvent justifier un supernœud à 64 accélérateurs.
Les produits présentés à l'OCTS 2026 illustrent une architecture à trois niveaux.
| Niveau | Responsabilités principales |
|---|---|
| Plateforme logicielle | Accès aux modèles, routage des tâches, orchestration, permissions, évaluation et fusion des résultats |
| Infrastructure CPU | Processus agents, appels d'outils, exécution en bac à sable, gestion du contexte et interaction avec les systèmes métier |
| Supernœud GPU | Inférence de grands modèles, génération de tokens à haut débit et exécution multi-modèles |
Le système ne fonctionne correctement que lorsque les trois niveaux travaillent en synergie.
Un cluster GPU rapide ne peut compenser un ordonnancement d'agents faible. Un rack CPU haute densité ne peut améliorer la qualité de l'inférence sans accès à des modèles puissants. Une API de fusion complexe ne peut offrir une latence utile si les modèles sous-jacents ne peuvent être chargés ou connectés efficacement.
C'est le principal changement dans la concurrence pour l'infrastructure des agents.
Le marché précoce se concentrait sur la capacité d'un serveur à prendre en charge un seul grand modèle. L'ère des agents déplace l'attention vers les performances au niveau système :
Les chiffres impressionnants fournis par les fournisseurs sont utiles, mais insuffisants pour choisir une plateforme d'infrastructure d'agents.
Une évaluation en environnement de production doit mesurer la charge de travail complète.
Ne pas seulement compter les utilisateurs actifs, mais aussi :
Un agent de
recherche léger a des caractéristiques de demande de ressources très différentes d'un agent de codage doté d'un environnement de développement dédié.
La métrique « nombre d'agents par rack » doit être mappée aux besoins réels en mémoire, CPU, stockage et réseau de l'application cible.
Mesurer :
Un faible temps de génération de token dans un benchmark ne garantit pas une faible latence pour un flux de travail de bout en bout.
La fusion multi-modèles peut améliorer la qualité, mais peut entraîner une multiplication des coûts d'inférence.
Les équipes doivent comparer :
Les racks refroidis par liquide natif nécessitent une infrastructure d'installation correspondante.
Vérifier :
Les normes de modules ouverts peuvent améliorer la flexibilité, mais la portabilité réelle dépend de la compatibilité logicielle.
Vérifier :
Les agents à longue durée de vie nécessitent un contrôle strict sur :
La densité de l'infrastructure ne doit pas se faire au détriment de l'isolation opérationnelle.
Il s'agit d'un serveur rack complet CPU conçu autour d'un système de refroidissement, et non d'un refroidissement liquide ajouté à une conception traditionnelle à air. Inspur affirme qu'il peut accueillir jusqu'à 384 CPU et prendre en charge plus de 40 000 agents concurrents.
Ce chiffre est la valeur maximale rapportée par le fournisseur de l'architecture de référence d'Inspur. La capacité réelle dépend des ressources CPU, mémoire, stockage, réseau et d'isolation du bac à sable requises par chaque agent.
Les modèles de langage peuvent fonctionner sur GPU, mais les agents ont également besoin de CPU pour l'ordonnancement, l'exécution d'outils, la gestion d'état, l'accès aux systèmes métier, les vérifications de sécurité et l'isolation des environnements d'exécution. Les flux de travail de longue durée et multi-agents augmentent encore ce besoin en CPU.
L'OCM est une architecture de module de calcul ouvert conçue pour séparer le module de calcul de la conception plus large du rack. Le système OCM 2.0 refroidi par liquide d'Inspur prend en charge plusieurs architectures CPU et un refroidissement liquide de tous les composants.
Le MetaBrain SD200 est un supernœud d'IA d'Inspur conçu pour l'inférence de grands modèles et les charges de travail multi-modèles. Il utilise une architecture étendue à 64 accélérateurs, prenant en charge l'adressage unifié et une interconnexion haute vitesse.
Il s'agit d'une API qui envoie une tâche à plusieurs modèles candidats, collecte leurs réponses indépendantes, et
utilise un modèle de révision et de fusion pour identifier le consensus, les divergences, les omissions et les perspectives uniques avant de générer une réponse finale.
Non. Les modèles multiples peuvent améliorer les performances sur les tâches complexes, mais augmentent la consommation de tokens, les coûts de calcul et la latence. Les tâches simples sont mieux routées vers un seul modèle léger.
Le SD200 complet utilise un domaine étendu de 64 accélérateurs pour les charges de travail à très grande échelle. Le SD200 Édition Entreprise réduit le domaine à 16 accélérateurs, destiné aux entreprises qui ont besoin de déployer localement des modèles à des milliards de paramètres avec un seuil d'infrastructure plus bas.
DeepSeek : Un fournisseur de modèles d'IA dont le modèle open source a été inclus dans la liste de compatibilité SD200.
Les annonces d'Inspur à l'OCTS 2026 répondent à deux problèmes majeurs soulevés par les agents d'entreprise.
Le baie CPU native à refroidissement liquide se concentre sur l'extensibilité, offrant un environnement intensif pour la planification des agents, les outils, les bacs à sable, la gestion du contexte et l'exécution de longs processus. Le flux de travail de fusion multi-modèles SD200 et EPA se concentre sur l'intelligence, permettant à plusieurs grands modèles de collaborer sur des tâches complexes, les résultats étant intégrés par le modèle de révision.
La leçon plus large est la suivante : l'infrastructure des agents ne peut être réduite à un seul accélérateur plus rapide. Un système de production nécessite la coordination du CPU, du GPU, de la mémoire, de l'interconnexion, du refroidissement, de l'orchestration, des autorisations et de l'évaluation.
Le critère central de l'infrastructure des agents passe de l'efficacité d'exécution d'un seul modèle à la capacité de l'ensemble du système à planifier efficacement des milliers d'agents et à produire en continu des résultats fiables.
Partez d’une phrase et obtenez un site complet en quelques minutes.
