Red Hat y Netris: multi-tenancy real para IA en 2026

Red Hat y Netris anunciaron el 9 de mayo de 2026 una colaboración para llevar aislamiento multi-tenant con hardware enforcement a clouds soberanas y neoclouds de IA. La plataforma Netris NAAM (Network Automation, Abstraction, and Multi-Tenancy) se integra sobre Red Hat AI Factory with NVIDIA para automatizar VPCs, load balancers y NAT gateways en infraestructura bare-metal con hardware de NVIDIA Spectrum-X, Quantum InfiniBand y BlueField DPUs.

Nvidia es una empresa estadounidense fundada en 1993 que diseña y fabrica procesadores gráficos (GPUs) y sistemas de cómputo. Sus productos se utilizan principalmente en computación acelerada, inteligencia artificial, centros de datos y computación de alto rendimiento.

¿Qué es Netris NAAM y la colaboración Red Hat-Netris?

Netris NAAM es una plataforma de automatización, abstracción y multi-tenancy de red que lleva la API de cloud pública a infraestructura física. En términos concretos: con NAAM podés crear VPCs, configurar peering entre ellas, asignar Elastic IPs, desplegar load balancers y NAT gateways sobre switches y DPUs físicos, igual que lo harías en AWS o en cualquier cloud pública, pero con el control y la soberanía de una infraestructura propia.

La asociación con Red Hat trae esa capacidad directamente al stack de Red Hat AI Factory with NVIDIA, que ya era la base para despliegues de IA acelerada. Lo que le faltaba a ese stack era justamente la capa de red con multi-tenancy automatizado y aislamiento real entre clientes. Eso es exactamente lo que NAAM cierra.

El problema que resuelven no es menor: muchos despliegues de IA de hoy todavía dependen de entornos de red fragmentados, provisionados a mano, que no escalan bien ni garantizan aislamiento entre tenants. Para clouds soberanas y neoclouds, eso es un bloqueador.

Aislamiento duro: multi-tenancy en hardware

Acá viene lo bueno: el aislamiento que ofrece NAAM no es solo un firewall en software o unas reglas de VLAN mal parcheadas. Es “hard isolation”, aplicado directamente en el hardware de red: switches, DPUs y fabrics.

La diferencia importa. El aislamiento en software depende de capas que pueden ser comprometidas, tienen overhead por los túneles de overlay, y pueden romperse si una VM o un contenedor explota. El aislamiento en hardware es una barrera aplicada antes de que el paquete ni siquiera entre en el plano de forwarding compartido. Para operadores que manejan múltiples clientes en el mismo clúster de IA, eso es la diferencia entre un contrato que podés firmar y uno que no.

Las DPUs de NVIDIA BlueField juegan un rol central acá: concentran el procesamiento de red offloading del CPU principal y aplican las políticas de aislamiento a nivel de interfaz, no a nivel de hipervisor. Eso sí: requiere que la infraestructura esté equipada con el hardware correcto, no es algo que instalás sobre cualquier servidor viejo. Tema relacionado: herramientas de integración continua.

Arquitectura: Spectrum-X, InfiniBand y BlueField

La solución soporta tres fabrics de NVIDIA:

• NVIDIA Spectrum-X Ethernet: fabric de alta velocidad orientado a cargas de IA, con optimizaciones para tráfico all-to-all y reducción de congestión en GPU-to-GPU.
• NVIDIA Quantum InfiniBand: fabric de baja latencia para los clústeres más exigentes, donde el throughput y la latencia son críticos para entrenamiento distribuido.
• NVIDIA BlueField DPUs: los smartNICs que hacen el trabajo pesado del offloading de red, seguridad y aislamiento de tenants directamente en el hardware de interfaz.

NAAM abstrae los tres en una API unificada. El operador define sus VPCs y políticas una sola vez; la plataforma traduce esas definiciones a configuración específica de cada hardware subyacente. Si mañana el operador agrega switches Spectrum-X o migra de InfiniBand a Ethernet, la capa de abstracción absorbe el cambio sin que los tenants noten nada.

Ponele que tenés un neocloud corriendo 200 GPUs para tres clientes distintos. Con una solución manual, separar el tráfico de cada cliente implica horas de configuración y un riesgo de error humano considerable. Con NAAM, definís tres VPCs, aplicás las políticas de aislamiento, y la plataforma lo aprovisiona en todos los switches y DPUs de forma automática. (Spoiler: cuando lo hacés a mano, tarde o temprano se te escapa una regla.)

Neoclouds y clouds soberanas: casos de uso reales

Un neocloud es un proveedor de infraestructura cloud que se especializa en cargas de IA acelerada: ofrece acceso a GPUs modernas sin los lock-ins y las estructuras de precios de los hiperescaladores tradicionales. Empresas como CoreWeave o Lambda Labs son ejemplos del modelo. Según datos de marzo de 2026, Netris ya capturó el 12% del mercado global de neoclouds en apenas 10 meses, con 622% de crecimiento.

La cloud soberana es un modelo diferente: infraestructura de cloud que cumple con requisitos regulatorios de localización de datos, control gubernamental y privacidad. Europa, América Latina y varios países de Asia tienen iniciativas activas en este sentido, donde una empresa o gobierno no puede usar simplemente AWS us-east-1 porque la regulación exige que los datos permanezcan en territorio nacional y bajo control local.

Para ambos modelos, la integración Red Hat Netris networking multi-tenant resuelve el mismo problema: cómo servir múltiples clientes sobre la misma infraestructura física sin que unos puedan ver o afectar a los otros.

Automatización en la nube: VPCs, peering, load balancers y NAT gateways

NAAM lleva las construcciones de cloud pública al mundo bare-metal. Las cinco principales: Para más detalles técnicos, mirá optimización para mercados globales.

• VPCs (Virtual Private Clouds): redes privadas aisladas para cada tenant, con su propio espacio de direcciones IP y políticas de routing.
• VPC Peering: conexión controlada entre VPCs cuando un tenant necesita comunicación entre proyectos, sin pasar por el tráfico de otros.
• Elastic IPs: IPs públicas asignables dinámicamente a cualquier recurso dentro de la infraestructura.
• Load Balancers: distribución de tráfico automatizada entre instancias de GPU o servicios, con failover.
• NAT Gateways: salida a internet para recursos privados sin exponer IPs internas.

Cualquiera que haya tenido que configurar todo esto a mano en switches físicos sabe que el proceso implica horas de CLI, documentación inconsistente entre vendors, y al menos un par de llamadas de soporte. NAAM lo abstrae en una API que funciona igual que la de AWS o GCP, pero ejecuta la configuración en el hardware físico automáticamente.

Problemas que resuelve: noisy neighbor, aislamiento de tenants y congestión

El problema del “noisy neighbor” en redes de IA multi-tenant es real: un tenant que lanza un job de entrenamiento intensivo puede saturar el fabric y degradar el rendimiento de todos los demás en el mismo clúster físico. Sin aislamiento de red en hardware, no hay nada que impida ese efecto.

NAAM aplica QoS y políticas de aislamiento a nivel de switch y DPU, no solo en el hipervisor. Eso significa que aunque un tenant intente consumir toda la banda, el hardware aplica los límites antes de que el tráfico llegue a afectar a otros. (En la práctica, esto es lo que separa un SLA creíble de uno que se rompe en cuanto hay carga real.)

¿Y el overhead de los overlays? Los túneles VXLAN o similares que usan soluciones puramente software agregan latencia y consumen CPU. Con offloading en BlueField DPUs, ese procesamiento se saca del CPU principal y se ejecuta en el smartNIC, manteniendo la latencia de red cerca de lo que ofrece el bare-metal puro. Para cargas de entrenamiento distribuido donde la latencia GPU-to-GPU importa, esa diferencia es medible.

Integración con Red Hat AI Factory y roadmap futuro

Red Hat AI Factory with NVIDIA ya es el stack de referencia para despliegues de IA acelerada sobre OpenShift. La integración con Netris cierra la última brecha que tenía ese stack: la capa de networking multi-tenant automatizado. Relacionado: plataformas cloud convencionales.

Para un operador de neocloud, esto significa poder desplegar un nuevo tenant con red completamente aislada en minutos, no días. El flujo es: definir la VPC en la API de NAAM, asignar recursos de GPU en Red Hat AI Factory, y la plataforma coordina la configuración de red en todos los switches y DPUs del clúster. Si usás infraestructura de donweb.com o cualquier proveedor que esté adoptando el stack NVIDIA + Red Hat, el modelo de despliegue es el mismo.

El roadmap público todavía no detalla fechas concretas para integraciones adicionales, así que tomalo con pinzas cuando leas promesas de expansión sin fechas. Lo que sí está confirmado al 9 de mayo de 2026 es la disponibilidad del modelo de colaboración inicial con soporte para Spectrum-X, InfiniBand y BlueField.

Errores comunes al implementar multi-tenancy de red en IA

Confundir aislamiento de software con aislamiento real. Muchos operadores asumen que las reglas de firewall en el hipervisor son suficientes. No lo son para entornos regulados o donde el SLA exige garantías de aislamiento. Si el tenant A puede saturar el fabric y degradar al tenant B, el aislamiento es incompleto.

Subestimar la complejidad del provisionamiento manual. El modelo “lo configuramos a mano en el switch cada vez que entra un cliente nuevo” no escala. A partir de 5-10 tenants con configuraciones dinámicas, el error humano y el tiempo de operación se vuelven bloqueadores reales.

Asumir que cualquier fabric sirve para IA. Spectrum-X e InfiniBand no son intercambiables: cada uno tiene características específicas para distintos perfiles de carga. Elegir el fabric incorrecto para el workload de entrenamiento o inferencia puede costar fácilmente 20-30% de rendimiento de GPU.

Ignorar el overhead de overlay antes de ponerlo en producción. Un benchmark de latencia en un entorno de un solo tenant sin carga no refleja lo que vas a ver con múltiples tenants y tráfico real. Medí con carga concurrente antes de comprometerte con un SLA. Esto se conecta con lo que analizamos en provisioning automático en AWS.

Preguntas Frecuentes

¿Qué es Netris NAAM y para qué sirve?

Netris NAAM (Network Automation, Abstraction, and Multi-Tenancy) es una plataforma que lleva la API de cloud pública a infraestructura bare-metal. Permite crear VPCs, load balancers, NAT gateways y Elastic IPs sobre switches físicos y DPUs, con aislamiento entre tenants aplicado en hardware. Sirve para que operadores de neocloud o cloud soberana puedan ofrecer entornos aislados a múltiples clientes sobre la misma infraestructura física, sin provisionamiento manual.

¿Cómo funciona el aislamiento multi-tenant en infraestructura de IA?

El aislamiento multi-tenant en infraestructura de IA se aplica a nivel de switches físicos y DPUs (como las BlueField de NVIDIA), no solo en software. Cada tenant tiene su propia VPC con políticas de routing y QoS aplicadas en hardware, lo que garantiza que el tráfico de un tenant no pueda afectar ni ver el tráfico de otro. NAAM automatiza la configuración de estas políticas en todos los nodos del clúster cada vez que se agrega o modifica un tenant.

¿Cuál es la diferencia entre cloud soberana y cloud pública?

Una cloud soberana es infraestructura que cumple con requisitos legales de localización de datos y control dentro de un territorio específico: los datos no pueden salir del país y la operación está bajo jurisdicción local. Una cloud pública como AWS o Azure opera en múltiples regiones globales bajo las políticas del proveedor, sin garantías de localización para todos los servicios. Para entidades reguladas (gobiernos, salud, finanzas), la cloud soberana es a veces un requisito legal, no una preferencia.

¿Qué es un neocloud y por qué es importante para IA?

Un neocloud es un proveedor de infraestructura cloud especializado en cargas de IA acelerada, centrado en acceso a GPUs modernas con menos lock-in que los hiperescaladores. Son importantes para IA porque ofrecen hardware específico (NVIDIA H100, H200) con configuraciones optimizadas para entrenamiento e inferencia, a precios y con flexibilidad que los grandes clouds no siempre dan. Según datos de marzo de 2026, Netris capturó el 12% del mercado global de neoclouds en 10 meses, lo que muestra el crecimiento acelerado del segmento.

¿Cómo Red Hat y Netris mejoran la seguridad de nubes soberanas?

La combinación de Red Hat AI Factory y Netris NAAM mejora la seguridad de nubes soberanas al aplicar el aislamiento en hardware (switches y DPUs), no solo en capas de software que pueden ser comprometidas. El modelo de VPCs con hard isolation garantiza que un tenant no puede acceder al tráfico ni los recursos de otro, incluso ante errores de configuración en software. Para entornos regulados donde una brecha entre tenants puede ser un incidente legal, esa garantía de hardware es un requisito, no un nice-to-have.

Conclusión

La colaboración Red Hat Netris networking multi-tenant cierra un gap real: hasta ahora, la infraestructura de IA acelerada tenía compute y storage automatizados y abstraídos, pero la red seguía siendo mayormente manual y sin garantías de aislamiento real entre tenants. NAAM + Red Hat AI Factory resuelve eso con hardware enforcement, automatización de construcciones cloud y soporte para los tres fabrics principales de NVIDIA.

Para operadores de neocloud o cloud soberana en Latinoamérica, esto reduce el tiempo de onboarding de nuevos tenants, mejora los SLAs que se pueden comprometer legalmente, y elimina trabajo operativo de bajo valor. Si estás evaluando montar infraestructura de IA multi-tenant, el stack combinado es ahora una referencia concreta con la que comparar otras opciones. El roadmap todavía tiene partes sin fechar, pero lo disponible desde mayo de 2026 ya es suficiente para casos de uso productivos.

Fuentes

• Red Hat Blog — Red Hat and Netris bring multi-tenant networking to sovereign AI clouds (mayo 2026)
• BusinessWire — Netris 622% de crecimiento y 12% del mercado neocloud (marzo 2026)
• Red Hat AI Factory with NVIDIA — página oficial del producto
• Netris.io — plataforma NAAM
• Red Hat — Sovereign AI: contexto y definición