NVIDIA PAIR: Routing de IA Local y la Brecha de AMD ROCm

NVIDIA Personal AI Router, o PAIR, es un plano de control local para peticiones independientes de inferencia de IA. Descubre los ordenadores de tu red, comprueba qué engine y modelo puede servir cada nodo, observa la carga y la presión sobre la GPU y reenvía cada petición nueva a un nodo elegible. El agente continúa hablando con un endpoint conocido, compatible con Ollama u OpenAI.

Piensa en Kubernetes para el montón de ordenadores de IA escondidos por casa, con una corrección importante. PAIR no es un orquestador de contenedores, no agrupa VRAM y no convierte varias GPUs en una GPU gigante. Coloca trabajos completos de inferencia en réplicas completas del modelo. Eso ayuda cuando cinco subagentes compiten por una GPU como palomas por una patata frita. No consigue que un modelo sobredimensionado quepa de repente en cinco máquinas.

La arquitectura resulta inusualmente clara para una beta tan nueva. La brecha interesante también: NVIDIA valida RTX, DGX Spark y Apple M4+, pero AMD Strix Halo queda fuera. Por eso di a un agente de programación un encargo concreto: añadir ROCm 10 y Strix Halo. En la fecha de publicación es una línea de trabajo de ingeniería, no soporte upstream. Este análisis explica lo que PAIR ya hace, lo que revela el código sobre AMD y qué debe demostrar un port creíble antes de comprar hardware en torno a él.

¿Qué es NVIDIA PAIR?

El repositorio open source de NVIDIA PAIR describe software para un grupo de ordenadores Windows, Linux y macOS compatibles en la misma red. PAIR descubre nodos, gestiona engines compatibles y presenta proxies compatibles con Ollama y OpenAI. El repositorio usa Apache 2.0. El paquete de escritorio publicado supervisa varios servicios pequeños escritos en Go detrás de una interfaz Electron.

Una petición sigue un recorrido sencillo:

1. La aplicación llama al proxy local de PAIR, normalmente en el puerto que ya esperaba.
2. El proxy interpreta el engine y el modelo solicitado.
3. Se descartan los nodos sin ese engine activo o sin el modelo exacto.
4. Los nodos restantes se ordenan según el estado del scheduler.
5. Un nodo ejecuta toda la petición y la respuesta vuelve en streaming por el mismo camino.

La documentación oficial de la arquitectura de PAIR separa elegibilidad del modelo y ranking por carga. El scheduler no conoce los modelos. Ordena nodos por trabajo pendiente más una puntuación aproximada derivada de la utilización suavizada de GPU. El proxy aplica ese orden únicamente a los nodos que anuncian el modelo pedido. Es una separación limpia entre capacidad funcional y presión actual.

¿PAIR combina GPUs o divide un modelo?

No. Cada petición de inferencia se ejecuta de principio a fin en un nodo. PAIR puede aumentar el throughput cuando una carga contiene llamadas independientes. No agrupa memoria de GPU, no divide capas, no reparte una petición activa y no la migra después del dispatch.

Esta distinción evita confundir keywords y tomar decisiones arquitectónicas caras. Elige PAIR cuando las réplicas caben en máquinas individuales y el problema son las colas. Elige paralelismo de modelo cuando el modelo no cabe. Elige un gateway cuando mandan la política de proveedores, los presupuestos o el fallback a la nube.

¿Cuánto acelera NVIDIA PAIR una carga multiagente?

La demostración de lanzamiento de PAIR usó Hermes Desktop, cinco subagentes, Ollama y Qwen 3.6 35B A3B. NVIDIA publica una media de 18 minutos en un portátil RTX Spark y 8 minutos 48 segundos en un clúster de tres dispositivos formado por ese portátil, un DGX Spark y una RTX 5090.

Es una reducción del 51 por ciento para esa demostración, no una promesa universal de 2x. NVIDIA la denomina inoficial y específica de la configuración. Paralelismo, réplicas del modelo, configuración del engine, red, forma del prompt y disponibilidad de nodos cambian el resultado. La métrica comercial correcta es el coste por tarea aceptada dentro de una latencia objetivo, no cuántas GPUs muestra PAIR.

El scheduler también tiene límites deliberados. No puntúa el modelo de GPU, la VRAM disponible, la latencia medida, si el modelo ya está caliente ni el tamaño previsto de la petición. Cada workload pendiente cuenta como uno. En un clúster mixto, una GPU pequeña y otra grande con la misma utilización reciben la misma presión. Es un comportamiento razonable para una beta, pero un piloto de empresa necesita pruebas propias de routing y latencia de cola.

¿Por qué AMD Strix Halo no es un nodo PAIR validado?

La respuesta es más matizada que «PAIR bloquea AMD». PAIR puede ejecutarse en sistemas x64 compatibles, y Ollama ya lista Ryzen AI Max en su tabla de GPU para Linux. Falta el camino completo y validado desde detección de hardware hasta telemetría, engine y política de soporte.

La página de problemas conocidos de PAIR indica que Linux sin un driver NVIDIA puede listar gráficos AMD o Intel por nombre, pero no muestra memoria ni utilización. En Windows, una GPU integrada o con memoria unificada puede enseñar una cifra demasiado baja porque PAIR solo cuenta memoria dedicada. NVIDIA aclara que la memoria mostrada no decide directamente la ruta, aunque la utilización ausente sí reduce la información de presión del scheduler.

El código concreta el límite de Linux. El detector de GPU para Linux llama primero a nvidia-smi. Si no existe, usa detección PCI genérica. Esta devuelve el nombre del adaptador, pero no el total de VRAM, una clave estable para unir la telemetría ni la utilización dinámica. Windows ya usa DXGI y contadores de Performance Data Helper neutrales respecto al fabricante. El mayor camino específico que falta está en la telemetría Linux y la interpretación de memoria unificada.

¿Qué exige un port real para ROCm 10 y Strix Halo?

No basta con cambiar una allowlist. La contribución debe conservar el comportamiento existente cuando falten herramientas AMD, impedir que un fallo de telemetría se convierta en un fallo de routing y representar con honestidad la memoria de Strix Halo.

1. Detectar dispositivos AMD con identidades estables. La CLI de AMD SMI ofrece JSON, UUID, direcciones BDF, utilización GFX y métricas de memoria. Un collector puede unir muestras estáticas y dinámicas sin analizar tablas para humanos.
2. Limitar la recogida. Hay que seguir el timeout, muestreo de fondo cada segundo, freshness y último valor válido que PAIR ya usa. Un driver bloqueado no debe detener node-info.
3. Tratar la memoria unificada como tal. La GPU gfx1151 de Strix Halo comparte un gran pool LPDDR5X. La VRAM dedicada infravalora la capacidad, mientras que toda la RAM del sistema puede exagerar lo que el engine puede asignar con seguridad. La interfaz debe indicar la fuente.
4. Separar telemetría y soporte del engine. Detectar una GPU AMD no prueba que Ollama o LM Studio ejecute bien el modelo. Versión, driver, backend, contexto y arquitectura siguen siendo gates distintos.
5. Probar clústeres mixtos. Las pruebas deben cubrir NVIDIA con AMD, datos antiguos de AMD SMI, herramienta ausente, muestras reales al cero por ciento, varios adaptadores, suspensión, reinicio y un modelo presente en un único nodo.

Las notas de ROCm 10.0.0 añaden trabajo de inferencia, herramientas y profiling, con mejor soporte del profiler para gfx1151. Es infraestructura útil, pero una nueva versión mayor de ROCm no certifica compatibilidad con PAIR. PAIR, AMD SMI, el driver, el engine y el modelo deben encajar.

La capa del engine requiere especial cautela. La página de soporte GPU de Ollama lista Ryzen AI Max+ 395, Max 390 y Max 385 para Linux y documenta rutas ROCm y Vulkan. Su contrato actual habla de ROCm v7, no de ROCm 10. Un experimento de PAIR con ROCm 10 necesita una matriz explícita del engine. Un port de telemetría no actualiza el backend de inferencia.

¿Es PAIR suficientemente seguro para datos empresariales?

PAIR mantiene el tráfico de inferencia en la red local cuando aplicación, engine, fuente del modelo y nodos son locales. Los nodos emparejados usan certificados fijados y TLS mutuo. El proxy solo acepta peticiones sin cifrar desde loopback, y una máquina no emparejada no puede entrar como miembro del clúster.

Local no significa invisible. La arquitectura indica que la telemetría del nodo viaja en texto claro y sin autenticación. Cualquier máquina de la misma subred puede leer hostname, inventario de hardware y utilización. El emparejamiento empieza con un PIN corto sin cifrar antes de fijar certificados. Usa una red fiable y segmentada, revisa el firewall, protege los equipos y evita guardar cuerpos sensibles en logs. Para datos regulados o de clientes, añade threat modeling, retención, responsabilidad de parches y respuesta a incidentes.

¿Cuándo debería una empresa usar NVIDIA PAIR?

Siete pasos para probar PAIR antes de comprar otra GPU

1. Define la tarea aceptada. Registra calidad, tool calls, contexto y timeout, no solo tokens por segundo.
2. Mide un nodo. Captura cola, primer token, tiempo total, energía y tasa de fallo.
3. Replica un modelo. Coloca el mismo artefacto en dos nodos para crear una decisión real de routing.
4. Añade concurrencia realista. Reproduce la cantidad y mezcla de subagentes de tu flujo.
5. Observa la colocación. Comprueba que Jobs, telemetría y logs coinciden sobre dónde corrió cada petición.
6. Rompe el clúster a propósito. Suspende un portátil, para un engine, elimina un modelo y ocupa una GPU con otra aplicación.
7. Compara todas las alternativas. Usa nuestro modelo de break-even entre LLM locales y APIs antes de llamar gratis al hardware ocioso.

Si el piloto procesa código o documentos propios, conecta el routing con evals, control de acceso y rollback. El caso de Twinsoft AI muestra cómo un flujo de IA se convierte en sistema de producción. La guía para elegir un stack tecnológico evita que un componente prometedor decida toda la arquitectura.

Fuentes y metodología

Revisamos este análisis el 4 de septiembre de 2026 con el repositorio, arquitectura, demostración de lanzamiento y problemas conocidos de NVIDIA, además de la documentación actual de AMD SMI, ROCm 10 y Ollama enlazada arriba. Inspeccionamos las implementaciones de telemetría para Linux y Windows y el código del scheduler. No reproducimos el benchmark de NVIDIA ni afirmamos que el trabajo para AMD esté integrado, soportado o completo. El soporte cambia rápido, así que fija la versión de PAIR, driver, engine y modelo del piloto.