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 ...
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:
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.
La inferencia tradicional de modelos grandes suele seguir un patrón simple:
La ruta de ejecución de una aplicación de agente es mucho más larga.
Una sola tarea empresarial puede implicar:
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.
Las GPU siguen siendo indispensables para:
Las CPU manejan una gran cantidad de trabajo periférico:
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.
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.
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.
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:
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)
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:
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.
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:
Los resultados reales dependen de la compatibilidad ecológica, la interoperabilidad y la disponibilidad de componentes complementarios.
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:
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.
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:
Declaración no admitida:
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:
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.
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.
Un modelo ligero puede ser suficiente para:
Múltiples modelos pueden ser útiles para:
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.
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:
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:
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.
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
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:
Capacidades
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.
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.
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.
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 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.
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.
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.
Inspur afirma que el SD200 ha completado la optimización de rendimiento para varios modelos de código abierto populares, incluyendo:
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.
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:
Esta edición empresarial está dirigida principalmente a las siguientes cargas de trabajo:
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.
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:
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.
No solo cuente usuarios activos, también:
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.
Se debe medir:
Un tiempo de generación de token bajo en puntos de referencia no garantiza baja latencia en flujos de trabajo de extremo a extremo.
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:
Los racks de refrigeración líquida nativa requieren infraestructura de instalaciones compatible.
Se debe verificar:
Los estándares de módulos abiertos pueden mejorar la flexibilidad, pero la portabilidad real depende de la compatibilidad del software.
Se debe verificar:
Los agentes de larga duración necesitan un control sólido sobre:
La densidad de la infraestructura no debe sacrificar el aislamiento operativo.
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.
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.
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.
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.
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.
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.
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.
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.
DeepSeek: Proveedor de modelos de IA, cuyos modelos de código abierto han sido incluidos en la lista de compatibilidad SD200.
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.
Empieza con una sola frase y obtén un sitio completo en minutos.
