Inspur construye infraestructura para agentes inteligentes: 40,000 agentes por rack y colaboración multi-modelo
La infraestructura de IA está superando la era de atender una solicitud de modelo a la vez. Un agente inteligente de nivel de producción no solo acepta indicaciones y devuelve respuestas; puede descomponer tareas en múltiples etapas, invocar herramientas externas, mantener contexto, coordinarse con subagentes, revisar resultados intermedios y permanecer activo durante largos períodos. Cuando las empresas despliegan miles de estos agentes a la vez, los requisitos de infraestructura difieren drásticamente de la inferencia de un chatbot común. En la tecnología de computación abierta de 2026...
Inspur construye infraestructura para agentes inteligentes: 40,000 agentes por rack y colaboración multi-modelo
Introducción
La infraestructura de IA está superando la era de procesar una sola solicitud de modelo a la vez.
Un agente de nivel de producción no solo recibe una indicación y devuelve una respuesta. Puede dividir una tarea en múltiples fases, invocar herramientas externas, mantener contexto, coordinarse con subagentes, revisar resultados intermedios y permanecer activo durante largos períodos. Cuando una empresa despliega miles de estos agentes simultáneamente, los requisitos de infraestructura difieren drásticamente de la inferencia de un chatbot común.
En la Cumbre de Tecnología de Computación Abierta 2026 en Pekín, Inspur Information propuso dos direcciones de infraestructura para esta nueva carga de trabajo:
- Servidores rack refrigerados por líquido nativos en CPU, diseñados para soportar más de 40,000 agentes concurrentes dentro de un solo rack.
- La combinación del Supernodo MetaBrain SD200 con la API de fusión de múltiples modelos EPAI, que permite que múltiples modelos grandes generen, revisen y combinen respuestas para tareas complejas.
La primera dirección se centra en la escala: mantener en línea una gran cantidad de agentes de larga duración. La segunda se centra en la calidad: permitir que múltiples modelos con diferentes fortalezas trabajen juntos, en lugar de forzar a un solo modelo a manejar cada parte de una tarea difícil.
Los desafíos de infraestructura que plantean las cargas de trabajo de agentes
La inferencia tradicional de modelos grandes suele seguir un patrón simple:
- Un usuario envía una solicitud.
- El modelo realiza la inferencia.
- El sistema devuelve una respuesta.
- La sesión termina o espera la siguiente solicitud.
La ruta de ejecución de una aplicación de agente es mucho más larga.
Una sola tarea empresarial puede implicar:
- Planificación
- Descomposición de tareas
- Recuperación
- Invocación de herramientas
- Ejecución de código
- Verificación de permisos
- Procesos de sandbox
- Inferencia de múltiples rondas
- Coordinación de subagentes
- Validación de resultados
- Agregación de resultados
- Gestión de estado de larga duración
Por lo tanto, la infraestructura no solo debe soportar la inferencia del modelo, sino también una gran cantidad de procesos de software persistentes.
En entornos empresariales, el número de agentes activos puede pasar de docenas a miles o incluso decenas de miles. Algunos agentes pueden ejecutarse continuamente, mientras que otros se crean dinámicamente para tareas cortas y se destruyen al finalizar.
Esto cambia el equilibrio entre los recursos de CPU y GPU.
GPU generan tokens
Las GPU siguen siendo indispensables para:
- Inferencia de modelos grandes
- Precarga y decodificación
- Generación de embeddings
- Procesamiento multimodal
- Producción de tokens de alto rendimiento
- Ejecución paralela de modelos
CPU ejecutan el entorno del agente
Las CPU manejan una gran cantidad de trabajo periférico:
- Programación de procesos de agentes
- Invocación de herramientas
- Gestión de contexto y estado
- Interacción con sistemas empresariales
- Ejecución de sandbox
- Operaciones de red y almacenamiento
- Autenticación y permisos
- Coordinación de flujos de trabajo
- Preparación de resultados
El modelo puede encargarse de generar razonamiento o texto, pero la CPU normalmente ejecuta el entorno operativo del agente.
Por lo tanto, la infraestructura de agentes está pasando de un diseño centrado en la GPU a un sistema que coordina CPU, GPU, red, almacenamiento, refrigeración y software de orquestación.
Por qué la densidad de CPU es cada vez más importante
En los servidores empresariales comunes, la densidad de CPU tradicionalmente ha estado limitada por la potencia, la refrigeración, el espacio, el cableado, los ventiladores y los requisitos de mantenimiento.
El despliegue de agentes cambia el modelo económico.
Si miles de agentes necesitan recursos de CPU para orquestación, invocación de herramientas y entornos de ejecución aislados, los racks de CPU de baja densidad ocuparán más espacio en el centro de datos, conexiones de red e infraestructura auxiliar.
Al mismo tiempo, los centros de datos de IA están evolucionando hacia mayores potencias de rack.
Según fuentes de información, Inspur Information prevé que la potencia de los racks de IA en China se acercará a los 300 kilovatios, mientras que algunos diseños globales ya apuntan a sistemas de rack de megavatios. La refrigeración por aire tradicional, que normalmente se limita a decenas de kilovatios por rack, será cada vez más difícil a esta densidad.
Por lo tanto, la refrigeración líquida ya no es un problema exclusivo de las GPU.
Los racks de CPU que soportan cargas de trabajo de agentes también deben adaptarse a la arquitectura de potencia y refrigeración de la próxima generación de centros de datos de IA.
Un solo rack puede soportar más de 40,000 agentes
Inspur lanzó lo que afirma es el primer servidor rack del mundo con refrigeración líquida nativa en CPU.
Este sistema se basa en la arquitectura de refrigeración líquida OCM 2.0 y es compatible con procesadores x86 y Arm.
Sus principales parámetros incluyen:
| Característica | Parámetros reportados por el fabricante |
|---|---|
| Número máximo de CPU por rack | 384 |
| Número de agentes concurrentes soportados | Más de 40,000 |
| Arquitectura de procesadores | x86 y Arm |
| Rango de refrigeración | CPU, memoria, SSD, tarjeta de red, módulos ópticos y otros componentes que generan calor |
| Densidad de computación | 4 CPU integradas en un espacio de 0.5U |
| Método de mantenimiento | Mantenimiento de ciclo de vida completo con refrigeración líquida |
| Escenarios objetivo | Centros de datos de IA de alta densidad y nivel de gigavatio |
Este sistema no considera la refrigeración líquida como un complemento añadido después de que el servidor esté diseñado.
Por el contrario, la disposición de la computación y la arquitectura de refrigeración se desarrollan de forma conjunta.
Expansión de la placa fría de la CPU a la refrigeración de todos los componentes
Los servidores tradicionales con placa fría
pueden enfriar directamente el procesador, pero los componentes de memoria, red, almacenamiento, fuente de alimentación y otros dispositivos aún dependen de ventiladores para la disipación de calor.
A medida que aumenta la densidad, este método se vuelve menos efectivo.
La arquitectura de refrigeración líquida nativa de Inspur integra los principales componentes generadores de calor en un sistema de refrigeración unificado:
- CPU
- Memoria
- Tarjeta de red
- Módulos ópticos
- Unidades de estado sólido
- Componentes de comunicación
Esto reduce la dependencia del flujo de aire interno, permitiendo una disposición más compacta de los componentes.
Abajo hay tres íconos azules: "Arquitectura de refrigeración líquida", "Conexión de refrigeración líquida" y "Operación y mantenimiento de refrigeración líquida". Esta imagen está estrechamente relacionada con el contexto y muestra visualmente la presentación del servidor de arquitectura de refrigeración líquida de Inspur, en consonancia con el diseño de arquitectura de refrigeración líquida descrito en el documento.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)
Unidad de cómputo compacta
Este informe describe una unidad de cómputo compacta que integra múltiples grupos de procesadores y componentes periféricos en un chasis delgado y ligero.
El objetivo de diseño es recuperar el espacio ocupado originalmente por los siguientes componentes:
- Ventiladores grandes
- Conductos de aire
- Tuberías de refrigeración
- Cables internos
- Bandejas de servidores tradicionales
La disposición de componentes planos permite que una sola placa fría de gran área cubra más zonas del sistema.
El rack adopta un diseño interno sin cables o con pocos cables, lo que permite el mantenimiento sin detener el sistema. Inspur afirma que esto mejora la eficiencia de implementación y mantenimiento de todo el rack.
Por qué es importante OCM
OCM son las siglas de Open Compute Module (Módulo de Cómputo Abierto).
La arquitectura modular busca desacoplar el módulo de procesador del diseño general del sistema. Este diseño permite admitir más fácilmente procesadores de diferentes generaciones o arquitecturas, sin necesidad de rediseñar todo el rack para cada procesador.
Para las empresas y operadores de centros de datos, este esquema puede aportar las siguientes ventajas:
- Más opciones de hardware
- Mayor facilidad para actualizar plataformas
- Reducción del trabajo de diseño repetitivo
- Mejor compatibilidad con arquitecturas x86 y Arm
- Prolongación del ciclo de vida de la infraestructura del rack
Los resultados reales dependen de la compatibilidad ecológica, la interoperabilidad y la disponibilidad de componentes complementarios.
Tamaño no es igual a inteligencia
Ejecutar decenas de miles de agentes inteligentes para resolver problemas de capacidad no mejora automáticamente la calidad de las respuestas.
Los grandes modelos de lenguaje tienen sus propias especialidades.
Algunos modelos pueden ser mejores en:
- Razonamiento lógico
- Escritura de código
- Análisis de textos largos
- Investigación técnica
- Escritura natural
- Extracción estructurada
- Tareas multilingües
Incluso los modelos de muy gran escala tienen limitaciones en ciertas capacidades.
Al procesar tareas complejas, un solo modelo puede pasar por alto problemas clave que otros modelos pueden detectar. Un solo modelo también puede dar respuestas con confianza, sin exponer incertidumbre o considerar interpretaciones alternativas.
Por lo tanto, la segunda dirección de infraestructura de Inspur se centra en la colaboración de múltiples modelos.
Colaboración de múltiples modelos en la misma tarea
La API de fusión de múltiples modelos EPAI distribuye tareas complejas en paralelo a varios modelos candidatos.
Cada modelo genera respuestas de forma independiente. Además, un modelo de revisión y fusión compara las respuestas candidatas para identificar:
- Conclusiones comunes
- Juicios contradictorios
- Información omitida
- Perspectivas únicas
Declaración no admitida:
- Áreas que requieren coordinación
Luego, la plataforma genera una respuesta integrada.
Esto no es simplemente una votación mayoritaria ni una concatenación directa de todas las respuestas. El flujo de trabajo esperado es el siguiente:
- Generación de candidatos
- Revisión entre modelos
- Análisis de diferencias y omisiones
- Fusión en una salida final
Inspur informa que el sistema alcanzó un 53.9 % en la evaluación DRACO, superando a cada modelo individual en el grupo de candidatos utilizado en esa prueba.
Este resultado debe considerarse como un punto de referencia reportado por la plataforma, no como una afirmación de que la fusión de modelos siempre superará al mejor modelo individual. El rendimiento dependerá de los modelos candidatos, el modelo de evaluación, la lógica de enrutamiento, el tipo de tarea, las indicaciones y el método de puntuación.
Tareas simples aún usan un solo modelo
Si cada solicitud ejecutara múltiples modelos, aumentaría innecesariamente el costo y la latencia.
Por lo tanto, EPAI distingue entre tareas cortas y predecibles y tareas complejas.
Tareas adecuadas para un solo modelo
Un modelo ligero puede ser suficiente para:
- Preguntas y respuestas simples
- Conversión de formato
- Extracción básica
- Tareas de clasificación
- Llamadas a herramientas cortas
- Conversión de contenido rutinario
Tareas más adecuadas para fusión de múltiples modelos
Múltiples modelos pueden ser útiles para:
- Investigación profunda
- Comparación técnica
- Análisis de arquitectura
- Planificación compleja
- Razonamiento con textos largos
- Revisiones de alto impacto
- Tareas con evidencia ambigua
- Salidas que requieren verificación independiente
Este principio de enrutamiento es crucial para los sistemas de producción.
La colaboración de múltiples modelos es más valiosa cuando la posible mejora en calidad compensa el costo adicional de tokens, tiempo de GPU y latencia de respuesta.
Flujo de trabajo de fusión de múltiples modelos EPAI
La API de EPAI está diseñada para ocultar la orquestación de múltiples modelos detrás de una interfaz unificada.
Los desarrolladores envían una solicitud a la plataforma. EPAI gestiona:
- Selección de modelos candidatos
- Distribución paralela de tareas
- Recopilación de respuestas
- Ejecución del modelo de evaluación
- Análisis de diferencias
- Generación de la respuesta final
La misma interfaz se puede integrar en aplicaciones de agentes y marcos de desarrollo, sin necesidad de que cada equipo construya sistemas personalizados de enrutamiento y evaluación de modelos.
Esta arquitectura es adecuada para empresas que utilizan una combinación de modelos:
- Modelos de código abierto
- Modelos propietarios
- Modelos de uso general
- Modelos específicos de dominio
- Modelos desplegados localmente
- Modelos de API en la nube
El principal desafío operativo es que varios grandes modelos pueden necesitar estar disponibles simultáneamente. Esto impone mayores requisitos en la memoria del acelerador, el ancho de banda de interconexión, la programación y la comunicación de baja latencia.
MetaBrain SD200 proporciona el motor de tokens
El supernodo MetaBrain SD200 es la plataforma de hardware que respalda el flujo de trabajo de fusión de múltiples modelos.
Este sistema adopta una arquitectura de comunicación multihost y con semántica de memoria de baja latencia. Según Inspur, puede interconectar de manera unificada 64 aceleradores GPU de fabricación nacional en un solo sistema.
Su diseño incluye:
- Arquitectura de cómputo abierta OCM y OAM
- Interconexión 3D Mesh
- Direccionamiento unificado de aceleradores
- Comunicación entre pares de alta velocidad
- Memoria compartida de gran capacidad
Capacidades
- Soporte para múltiples modelos con billones de parámetros
- Optimización coordinada de hardware y software
Se afirma que este supernodo puede admitir un solo modelo de hasta cuatro billones de parámetros, o múltiples modelos con billones de parámetros utilizados simultáneamente por aplicaciones de agentes.
Tiempo de generación de tokens en pruebas de Inspur: 4.77 milisegundos
Inspur informa que el SD200 reduce el tiempo de generación de un solo token del modelo Kimi K2.6 con billones de parámetros a 4.77 milisegundos.
La compañía también informa una reducción del 35 % en el tiempo de generación del primer token en comparación con implementaciones anteriores.
Estos datos corresponden a resultados en entornos de optimización y pruebas específicos, y no deben interpretarse como una latencia garantizada para cada modelo, implementación, longitud de indicación, nivel de concurrencia o carga de trabajo de producción.
Estas mejoras se atribuyen a varias tecnologías.
Predicción de múltiples tokens
Los modelos autorregresivos generalmente generan primero un token, verifican el nuevo estado y luego generan el siguiente.
La predicción de múltiples tokens intenta generar varios tokens candidatos en un solo paso y verificarlos juntos.
Cuando la precisión de la predicción es alta, se pueden reducir las rondas de decodificación secuencial.
Cuantización W4A8
La optimización utiliza pesos INT4 y cálculos de activación INT8 en parte de la carga de modelos de mezcla de expertos.
En comparación con los cálculos BF16, esto puede reducir:
- La presión sobre el ancho de banda de memoria
- El uso de memoria del acelerador
- Los requisitos de cálculo
- El costo de inferencia por token
La cuantización puede afectar la calidad del modelo, por lo que los equipos de producción deben evaluar la precisión en función de su propia carga de trabajo, no solo basarse en los resultados de velocidad.
Compilación de kernel en tiempo real (JIT)
La compilación JIT genera kernels de acelerador especializados en tiempo de ejecución según la forma del tensor, el diseño y el tipo de datos.
En comparación con las implementaciones estáticas genéricas, los kernels especializados pueden reducir las ramas innecesarias y mejorar el acceso a la memoria.
Separación de prefilling y decodificación
La precarga de indicaciones y la decodificación de tokens tienen diferentes características de rendimiento.
Separar las dos fases permite asignar recursos de manera diferenciada y transferir de forma asíncrona la caché KV, reduciendo la contención entre el cálculo y la comunicación.
Compatibilidad de modelos
Inspur afirma que el SD200 ha completado la optimización de rendimiento para varios modelos de código abierto populares, incluyendo:
- Kimi K2.6
- DeepSeek V4
- GLM 5.2
- MiniMax M3
La compatibilidad no implica necesariamente que cada modelo alcance la misma latencia o rendimiento.
La arquitectura del modelo, la cantidad de parámetros, el diseño MoE, la longitud del contexto, la cuantización, el procesamiento por lotes y el software de servicio afectan el rendimiento.
Edición empresarial reduce la barrera de implementación
El supernodo de 64 aceleradores es adecuado para proyectos de infraestructura de IA a gran escala, pero para muchas empresas es demasiado grande y costoso.
Inspur también ha lanzado el YuanNao SD200 Edición Empresarial.
La edición empresarial reduce el dominio de cómputo de escalado vertical de 64 aceleradores a 16, con el objetivo de implementar localmente modelos de billón de parámetros.
Sus características declaradas incluyen:
- Dominio de interconexión unificada de 16 aceleradores
- Comunicación con semántica de memoria nativa
- Direccionamiento unificado
- Memoria unificada de acelerador de nivel de terabyte
- Mejora de más del 40% en el tiempo de generación del primer token para inferencia de billón de parámetros
- Soporte nativo para modelos líderes de billón de parámetros de código abierto
- Costos de migración y adaptación inferiores a los del sistema SD200 completo
Esta edición empresarial está dirigida principalmente a las siguientes cargas de trabajo:
- Comprensión de documentos largos
- Razonamiento lógico complejo
- Implementación de modelos privados
- Colaboración multiagente
- Investigación interna
- Aplicaciones comerciales sensibles
Proporciona un punto de entrada más pequeño para organizaciones que necesitan control local del modelo pero no pueden justificar un supernodo de 64 aceleradores.
La pila de infraestructura se está volviendo más integrada
Los productos lanzados en OCTS 2026 muestran una arquitectura de tres capas.
| Capa | Responsabilidad principal |
|---|---|
| Plataforma de software | Acceso a modelos, enrutamiento de tareas, orquestación, permisos, evaluación y fusión de resultados |
| Infraestructura de CPU | Procesos de agente, invocación de herramientas, ejecución en sandbox, gestión de contexto e interacción con sistemas empresariales |
| Supernodo GPU | Inferencia de modelos grandes, generación de tokens de alto rendimiento y ejecución de múltiples modelos |
El sistema solo funciona correctamente cuando las tres capas trabajan en conjunto.
Un clúster de GPU rápido no puede compensar una programación de agentes deficiente. Un rack de CPU de alta densidad no puede mejorar la calidad de inferencia si no puede acceder a modelos potentes. Una API de fusión compleja no puede proporcionar latencia útil si los modelos subyacentes no se pueden cargar o conectar de manera eficiente.
Este es el cambio principal en la competencia de infraestructura de agentes.
El mercado temprano se centraba principalmente en qué tan bien un solo servidor soportaba un solo modelo grande. La era de los agentes ha desplazado la atención hacia el rendimiento a nivel de sistema:
- ¿Cuántos procesos de agente pueden permanecer en línea?
- ¿Qué tan rápido invocan modelos y herramientas?
- ¿Se pueden ejecutar múltiples modelos simultáneamente?
- ¿Cómo se comparte o aísla la memoria?
- ¿Cómo se ejecutan los permisos?
- ¿Puede la plataforma enrutar de manera diferente tareas simples y complejas?
- ¿Puede el sistema mantener la estabilidad bajo concurrencia de alta presión?
- ¿Qué tan eficientemente genera tokens útiles?
Qué deben evaluar las empresas antes de implementar
Los números brillantes proporcionados por los proveedores son útiles, pero insuficientes para elegir una plataforma de infraestructura de agentes.
Una evaluación de producción debe medir la carga de trabajo completa.
1. Concurrencia de agentes
No solo cuente usuarios activos, también:
- Subagentes por tarea
- Procesos de herramientas
- Sandboxes
- Trabajos en segundo plano
- Sesiones persistentes
- Picos de ráfaga
- Procesos de recuperación de fallos
2. CPU y memoria por agente
Un agente de recuperación ligero tiene características de demanda de recursos muy diferentes a las de un agente de codificación con un entorno de desarrollo independiente.
La métrica "número de agentes por rack" debe asignarse a la memoria real, CPU, almacenamiento y requisitos de red de la aplicación objetivo.
3. Latencia del modelo
Se debe medir:
- Tiempo hasta el primer token
- Latencia entre tokens
- Tiempo total de la tarea de extremo a extremo
- Latencia de cola
- Latencia de invocación de herramientas
- Latencia bajo escenarios concurrentes
Un tiempo de generación de token bajo en puntos de referencia no garantiza baja latencia en flujos de trabajo de extremo a extremo.
4. Economía de múltiples modelos
La fusión de múltiples modelos puede mejorar la calidad, pero puede llevar a un aumento exponencial de los costos de inferencia.
El equipo debería comparar:
- Precisión de un solo modelo
- Precisión de modelos fusionados
- Número de tokens consumidos
- Utilización de GPU
- Tiempo de respuesta
- Costo del modelo de revisión
- Tasa de fallos
- Reducción de revisión manual
5. Compatibilidad con refrigeración e instalaciones
Los racks de refrigeración líquida nativa requieren infraestructura de instalaciones compatible.
Se debe verificar:
- Unidades de distribución de refrigerante
- Temperatura de suministro y retorno de agua
- Requisitos de presión y caudal
- Detección de fugas
- Procesos de mantenimiento
- Planes de recuperación de calor residual
- Capacidad de alimentación del rack
- Capacidad de carga del piso del centro de datos
6. Portabilidad de modelos y aceleradores
Los estándares de módulos abiertos pueden mejorar la flexibilidad, pero la portabilidad real depende de la compatibilidad del software.
Se debe verificar:
- Frameworks de modelos
- Motores de inferencia
- Soporte de cuantización
- Disponibilidad de kernels
- Madurez de los controladores
- Herramientas de monitoreo
- Reemplazo de aceleradores
- Procesos de actualización
7. Fiabilidad y gobierno
Los agentes de larga duración necesitan un control sólido sobre:
- Autenticación
- Configuración de permisos
- Gestión de claves
- Acceso a la red
- Entornos sandbox
- Registros de auditoría
- Límites de velocidad
- Aprobación humana
- Enrutamiento de modelos
- Retención de datos
La densidad de la infraestructura no debe sacrificar el aislamiento operativo.
Preguntas frecuentes
¿Qué es el rack de agente de CPU refrigerado por líquido nativo de Inspur?
Es un servidor de rack de CPU completo diseñado en torno a un sistema de refrigeración, en lugar de agregar refrigeración líquida a un diseño de refrigeración por aire tradicional. Inspur afirma que puede albergar hasta 384 CPU y soportar más de 40,000 agentes concurrentes.
¿Un rack realmente puede ejecutar 40,000 agentes de IA?
Esa cifra es el valor máximo informado por los proveedores en el informe de arquitectura de referencia de Inspur. La capacidad real depende de la CPU, memoria, almacenamiento, red y recursos de aislamiento sandbox requeridos por cada agente.
¿Por qué los agentes de IA necesitan tantas CPU?
Los modelos de lenguaje pueden ejecutarse en GPU, pero los agentes también necesitan CPU para programación, ejecución de herramientas, gestión de estado, acceso a sistemas empresariales, comprobaciones de seguridad y entornos de ejecución aislados. Los flujos de trabajo de larga duración y multiagente aumentan aún más esta demanda de CPU.
¿Qué es OCM 2.0?
OCM es una arquitectura de módulo de cómputo abierto para separar el módulo de cómputo del diseño de rack más amplio. El sistema OCM 2.0 refrigerado por líquido de Inspur soporta múltiples arquitecturas de CPU y refrigeración líquida de todos los componentes.
¿Qué es MetaBrain SD200?
MetaBrain SD200 es un supernodo de IA de Inspur, diseñado para inferencia de modelos grandes y cargas de trabajo multimodelo. Utiliza una arquitectura de escalado de 64 aceleradores, que soporta direccionamiento unificado e interconexión de alta velocidad.
¿Qué es la API de fusión multimodelo EPAI?
Es una API que puede enviar una tarea a múltiples modelos candidatos, recopilar sus respuestas independientes y
emplear un modelo de revisión y fusión para identificar consenso, divergencias, omisiones e ideas únicas antes de generar la respuesta final.
¿La fusión multimodelo es siempre mejor que un solo modelo?
No. Los modelos múltiples pueden mejorar el rendimiento en tareas complejas, pero aumentan el consumo de tokens, los costos computacionales y la latencia. Las tareas simples son más adecuadas para enrutarlas a un solo modelo ligero.
¿Cuál es la diferencia entre el SD200 y el SD200 Edición Empresarial?
El SD200 completo utiliza un dominio de escalado de 64 aceleradores para manejar cargas de trabajo a muy gran escala. El SD200 Edición Empresarial reduce el dominio a 16 aceleradores, dirigido a empresas que necesitan implementar modelos locales de billón de parámetros con barreras de infraestructura más bajas.
Herramientas relacionadas
- Inspur EPA Plataforma de IA de nivel empresarial: soporta gestión de modelos, desarrollo de aplicaciones, recuperación, implementación y flujos de trabajo multimodelo.
- Soluciones de refrigeración líquida de Inspur: Soluciones de infraestructura para implementar servidores de CPU/GPU refrigerados por líquido.
- Proyecto de Cómputo Abierto: Comunidad industrial que desarrolla diseños de hardware abiertos para servidores, racks, fuentes de alimentación, refrigeración y centros de datos.
- Kimi: Plataforma de asistente y modelo de Dark Side of the Moon, cuyos resultados de optimización se citan en el Inspur SD200.
DeepSeek: Proveedor de modelos de IA, cuyos modelos de código abierto han sido incluidos en la lista de compatibilidad SD200.
Enlaces relacionados
- Anuncio de la infraestructura de agentes de Inspur: Publicación oficial sobre racks de CPU refrigerados por líquido, SD200 y supernodos de nivel empresarial.
- Anuncio de rendimiento de 4.77 ms de MetaBrain SD200: Resumen técnico de Inspur sobre la optimización del SD200 y los resultados de generación de tokens.
- API de fusión de modelos múltiples de EPA: Descripción oficial de la generación de candidatos, revisión, mecanismo de fusión y puntuación DRACO.
- Página de producto EPA de Inspur: Información del producto sobre la plataforma de desarrollo de modelos grandes de nivel empresarial.
- Solución de centro de datos refrigerado por líquido de Inspur: Información oficial sobre soluciones de implementación de centros de datos refrigerados por líquido.
- Cumbre de Tecnología de Computación Abierta 2026: Página del evento OCTS 2026 y anuncios relacionados con la computación de código abierto.
- Fundación del Proyecto de Computación Abierta: Información oficial sobre estándares de infraestructura abierta y proyectos comunitarios.
Resumen
Los anuncios de Inspur en OCTS 2026 abordan dos problemas principales causados por los agentes empresariales.
Los racks nativos con refrigeración líquida para CPU se centran en la escalabilidad, proporcionando un entorno intensivo para la programación de agentes, herramientas, sandboxes, gestión de contexto y ejecución de procesos largos. El flujo de trabajo de fusión de modelos múltiples de SD200 y EPA se enfoca en la inteligencia, permitiendo que varios modelos grandes colaboren en tareas complejas, con un modelo de revisión que integra los resultados de salida.
La lección más amplia es que la infraestructura de agentes no puede reducirse a un único acelerador más rápido. Los sistemas de producción necesitan coordinar CPU, GPU, memoria, interconexiones, refrigeración, orquestación, permisos y evaluación.
El estándar central para medir la infraestructura de agentes está pasando de la eficiencia de ejecución de un solo modelo a la capacidad de todo el sistema para programar de manera eficiente miles de agentes y generar resultados confiables de forma continua.