Inspur construit une infrastructure d'agents intelligents : 40 000 agents par rack et collaboration multi-modèles

Introduction

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 :

1. Un serveur rack refroidi par liquide natif CPU, conçu pour prendre en charge plus de 40 000 agents concurrents dans un seul rack.
2. La combinaison du MetaBrain SD200 supernode avec l'API EPAI multi-modèles, permettant à plusieurs grands modèles de générer, examiner et combiner des réponses pour des tâches complexes.

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.

Les défis d'infrastructure spécifiques posés par les charges de travail des agents

L'inférence traditionnelle des grands modèles suit généralement un schéma simple :

1. L'utilisateur envoie une requête.
2. Le modèle effectue l'inférence.
3. Le système renvoie une réponse.
4. La session se termine ou attend la prochaine requête.

En revanche, le chemin d'exécution d'une application agent est beaucoup plus long.

Une seule tâche métier peut impliquer :

• Planification
• Décomposition des tâches
• Recherche
• Appel d'outils
• Exécution de code
• Vérification des permissions
• Processus sandbox
• Inférence multi-tours
• Coordination des sous-agents
• Validation des résultats
• Agrégation des résultats
• Gestion d'état à longue durée de vie

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 génère des tokens

Le GPU reste indispensable pour :

• L'inférence des grands modèles
• Le pré-remplissage et le décodage
• La génération d'embeddings
• Le traitement multimodal
• La production de tokens à haut débit
• L'exécution parallèle de modèles

Le CPU exécute l'environnement des agents

Le CPU gère une grande partie du travail périphérique :

• Ordonnancement des processus agents
• Appel d'outils
• Gestion du contexte et de l'état
• Interaction avec les systèmes métier
• Exécution sandbox
• Opérations réseau et stockage
• Authentification et permissions
• Coordination des workflows
• Préparation des résultats

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.

Pourquoi la densité CPU devient de plus en plus importante

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.

Un rack peut prendre en charge plus de 40 000 agents

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.

De l'extension de la plaque froide CPU au refroidissement de tous les composants

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é :

• CPU
• Mémoire
• Carte réseau
• Module optique
• SSD
• Composants de communication

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)

Unité de calcul compacte

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 :

• Grands ventilateurs
• Conduits d’air
• Tuyaux de refroidissement
• Câbles internes
• Plateaux de serveurs traditionnels

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.

Pourquoi l’OCM est important

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 :

• Plus de choix matériels
• Mise à niveau plus facile de la plateforme
• Réduction des travaux de conception redondants
• Meilleure compatibilité avec les architectures x86 et Arm
• Prolongation de la durée de vie de l’infrastructure du rack

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.

La taille n’est pas l’intelligence

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 :

• Le raisonnement logique
• L’écriture de code
• L’analyse de longs textes
• La recherche technique
• L’écriture naturelle
• L’extraction structurée
• Les tâches multilingues

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.

Collaboration de plusieurs modèles sur une même tâche

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 :

• Les conclusions communes
• Les jugements contradictoires
• Les informations manquantes
• Les points de vue uniques

Non pris en charge :

• Domaines nécessitant une coordination

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 :

1. Génération des candidats
2. Examen croisé des modèles
3. Analyse des différences et omissions
4. Fusion en une sortie finale

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.

Les tâches simples utilisent toujours un seul modèle

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.

Tâches adaptées à un seul modèle

Un modèle léger peut suffire pour :

• Questions-réponses simples
• Conversion de format
• Extraction basique
• Tâches de classification
• Appels d’outils courts
• Conversion de contenu standard

Tâches mieux adaptées à la fusion multi-modèles

Plusieurs modèles peuvent être utiles pour :

• Recherche approfondie
• Comparaison technique
• Analyse d’architecture
• Planification complexe
• Raisonnement sur de longs textes
• Révision à enjeux élevés
• Tâches aux preuves floues
• Sorties nécessitant une validation indépendante

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.

Flux de travail de fusion multi-modèles EPAI

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 sélection des modèles candidats
• La distribution parallèle des tâches
• La collecte des réponses
• L’exécution du modèle d’évaluation
• L’analyse des différences
• La génération de la réponse finale

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 :

• Modèles open source
• Modèles propriétaires
• Modèles généralistes
• Modèles spécifiques à un domaine
• Modèles déployés localement
• Modèles API cloud

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.

MetaBrain SD200 fournit le moteur de tokens

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 :

• Architectures ouvertes OCM et OAM
• Interconnexion 3D Mesh
• Adressage d’accélérateur unifié
• Communication pair à pair à haute vitesse
• Mémoire partagée de grande capacité

Capacités

• Prise en charge de plusieurs modèles de l’ordre du trillion de paramètres
• Optimisation conjointe matériel-logiciel

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.

Temps de génération de token de 4,77 millisecondes dans les tests d’Inspur

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.

Prédiction multi-token

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.

Quantification W4A8

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 pression sur la bande passante mémoire
• L’utilisation de la mémoire de l’accélérateur
• Les besoins de calcul
• Le coût d’inférence par token

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.

Compilation juste-à-temps du noyau

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.

Séparation préremplissage-décodage

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.

Compatibilité des modèles

Inspur indique que le SD200 a terminé l’optimisation des performances pour plusieurs modèles open source majeurs, notamment :

• Kimi K2.6
• DeepSeek V4
• GLM 5.2
• MiniMax M3

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.

L'édition Entreprise abaisse le seuil de déploiement

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 :

• Domaine d'interconnexion unifié de 16 accélérateurs
• Communication à mémoire sémantique native
• Adressage unifié
• Mémoire d'accélérateur unifiée de l'ordre du téraoctet
• Amélioration de plus de 40 % du temps de génération du premier token pour l'inférence de modèles à des milliards de paramètres
• Prise en charge native des principaux modèles open source à des milliards de paramètres
• Coûts de migration et d'adaptation inférieurs à ceux d'un système SD200 complet

Cette édition Entreprise cible principalement les charges de travail suivantes :

• Compréhension de longs documents
• Raisonnement logique complexe
• Déploiement de modèles privés
• Collaboration multi-agents
• Recherche interne
• Applications métier sensibles

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.

La pile d'infrastructure devient plus intégrée

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 :

• Combien de processus agents peuvent rester en ligne ?
• À quelle vitesse peuvent-ils appeler les modèles et les outils ?
• Plusieurs modèles peuvent-ils être exécutés simultanément ?
• Comment la mémoire est-elle partagée ou isolée ?
• Comment les permissions sont-elles appliquées ?
• La plateforme peut-elle router différemment les tâches simples et complexes ?
• Le système reste-t-il stable sous une forte charge concurrente ?
• Quelle est son efficacité à générer des tokens utiles ?

Ce que les entreprises doivent évaluer avant le déploiement

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.

1. Concurrence des agents

Ne pas seulement compter les utilisateurs actifs, mais aussi :

• Sous-agents par tâche
• Processus d'outils
• Bacs à sable
• Tâches en arrière-plan
• Sessions persistantes
• Pics de charge
• Processus de reprise après panne

2. CPU et mémoire par agent

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.

3. Latence du modèle

Mesurer :

• Temps de génération du premier token
• Latence inter-tokens
• Temps de bout en bout de la tâche
• Latence de file d'attente
• Latence d'appel d'outils
• Latence en situation de concurrence

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.

4. Économie multi-modèles

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 :

• Précision du modèle unique
• Précision du modèle fusionné
• Nombre de tokens consommés
• Utilisation du GPU
• Temps de réponse
• Coût du modèle de révision
• Taux d'échec
• Réduction de la révision humaine

5. Compatibilité du refroidissement et des installations

Les racks refroidis par liquide natif nécessitent une infrastructure d'installation correspondante.

Vérifier :

• Unités de distribution de liquide de refroidissement
• Températures d'alimentation et de retour
• Exigences de pression et de débit
• Détection de fuites
• Procédures de maintenance
• Solutions de récupération de chaleur
• Capacité d'alimentation du rack
• Capacité de charge du sol du centre de données

6. Portabilité des modèles et des accélérateurs

Les normes de modules ouverts peuvent améliorer la flexibilité, mais la portabilité réelle dépend de la compatibilité logicielle.

Vérifier :

• Frameworks de modèles
• Moteurs d'inférence
• Support de la quantification
• Disponibilité des kernels
• Maturité des pilotes
• Outils de surveillance
• Remplacement des accélérateurs
• Processus de mise à niveau

7. Fiabilité et gouvernance

Les agents à longue durée de vie nécessitent un contrôle strict sur :

• Authentification
• Paramètres de permissions
• Gestion des clés
• Accès réseau
• Environnement de bac à sable
• Journaux d'audit
• Limitation de débit
• Approbation humaine
• Routage des modèles
• Conservation des données

La densité de l'infrastructure ne doit pas se faire au détriment de l'isolation opérationnelle.

Foire aux questions

Qu'est-ce que le rack d'agents à refroidissement liquide natif CPU d'Inspur ?

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.

Un rack peut-il vraiment exécuter 40 000 agents d'IA ?

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.

Pourquoi les agents d'IA ont-ils besoin d'autant de CPU ?

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.

Qu'est-ce que l'OCM 2.0 ?

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.

Qu'est-ce que le MetaBrain SD200 ?

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.

Qu'est-ce que l'API de fusion multi-modèles EPAI ?

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.

La fusion multi-modèles est-elle toujours meilleure qu'un modèle unique ?

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.

Quelle est la différence entre le SD200 et le SD200 Édition Entreprise ?

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.

Outils connexes

• Plateforme IA Entreprise Inspur EPA : Prend en charge la gestion des modèles, le développement d'applications, la recherche, le déploiement et les flux de travail multi-modèles.
• Solutions de refroidissement liquide Inspur : Solutions d'infrastructure pour le déploiement de serveurs CPU/GPU refroidis par liquide.
• Open Compute Project : Communauté industrielle développant des conceptions de matériel ouvert pour les serveurs, les racks, l'alimentation, le refroidissement et les centres de données.
• Kimi : Plateforme d'assistant et de modèle de Moonshot AI ; ses résultats d'optimisation sont cités dans le SD200 d'Inspur.

DeepSeek : Un fournisseur de modèles d'IA dont le modèle open source a été inclus dans la liste de compatibilité SD200.

Liens connexes

• Annonce de l'infrastructure d'agents intelligents Inspur : Publication officielle couvrant les baies CPU à refroidissement liquide, le SD200 et les super-nœuds de niveau entreprise.
• Annonce des performances du MetaBrain SD200 à 4,77 ms : Aperçu technique par Inspur sur l'optimisation du SD200 et les résultats de génération de tokens.
• API de fusion multi-modèles EPA : Explication officielle des mécanismes de génération de candidats, de révision, de fusion et du score DRACO.
• Page produit Inspur EPA : Informations produit sur la plateforme de développement de grands modèles de niveau entreprise.
• Solution de centre de données à refroidissement liquide Inspur : Informations officielles sur les solutions de déploiement de centres de données à refroidissement liquide.
• Sommet des technologies de calcul ouvert 2026 : Page d'activité OCTS 2026 et annonces connexes sur le calcul ouvert.
• Fondation du projet Open Compute : Informations officielles sur les normes d'infrastructure ouverte et les projets communautaires.

Résumé

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.