NVIDIA ha publicado como código abierto Personal AI Router (PAIR), un proyecto pensado para distribuir peticiones de inferencia de inteligencia artificial entre varios ordenadores conectados a una misma red local. PAIR busca aprovechar mejor el hardware disponible cuando aplicaciones y agentes ejecutan varias tareas simultáneas, aunque hay una diferencia esencial frente a la computación distribuida tradicional: no suma las GPU ni su memoria, y tampoco divide un mismo modelo entre diferentes máquinas.
Las claves de NVIDIA PAIR en 20 segundos
- PAIR reparte peticiones de inferencia entre varios equipos de una red local.
- Funciona en Windows, Linux y macOS, con x64 y arm64.
- Es compatible con endpoints de Ollama y OpenAI y trabaja con motores como Ollama y LM Studio.
- Cada inferencia completa se ejecuta en un único nodo: no agrega VRAM.
- NVIDIA lo distribuye como código abierto bajo licencia Apache 2.0.
La idea encaja especialmente bien con una tendencia que está ganando peso alrededor de la IA local: cada vez hay más ordenadores personales capaces de ejecutar modelos, pero sus recursos suelen permanecer aislados. Un PC con una GPU potente, un portátil y un Mac pueden tener capacidad disponible al mismo tiempo sin que una aplicación disponga de una forma sencilla de repartir automáticamente sus peticiones entre ellos.
PAIR coloca una capa de coordinación delante de esas máquinas. Una aplicación envía su solicitud a un endpoint local y el sistema decide qué nodo compatible debe ejecutarla.
La comparación con un pequeño Kubernetes doméstico ayuda a visualizar el concepto, pero técnicamente es limitada. PAIR no pretende orquestar aplicaciones completas ni proporciona una gran GPU virtual. Su cometido actual es mucho más específico: programar peticiones independientes de inferencia sobre diferentes equipos.
Una capa para coordinar la IA que ya existe en casa o en la oficina
Cada ordenador incorporado a PAIR actúa como un nodo. Los equipos pueden combinar Windows 11, Linux y macOS, así como arquitecturas x64 y arm64. Windows sobre ARM figura por ahora como experimental.
La documentación también deja claro que instalar PAIR en un ordenador no garantiza que cualquier modelo pueda ejecutarse en él.
La compatibilidad real depende del motor de inferencia, el sistema operativo, la GPU, los controladores y la cantidad de memoria disponible. Un nodo únicamente entra en la lista de candidatos cuando dispone de un motor compatible en funcionamiento y puede atender el modelo solicitado.
Entre los motores contemplados actualmente aparecen Ollama y LM Studio, además de una integración más limitada con llama.cpp en Linux.
Para las aplicaciones, uno de los elementos más interesantes es la compatibilidad con interfaces ya utilizadas habitualmente en IA local.
PAIR presenta endpoints proxy compatibles con Ollama y con el formato de la API de OpenAI. Un agente puede enviar una petición como esta:
curl http://127.0.0.1:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model":"qwen4:12b",
"messages":[
{"role":"user","content":"Explain quantum computing"}
]
}'PAIR recibe la petición y selecciona una máquina capaz de atenderla.
Ese mecanismo puede ser especialmente útil en sistemas multiagente. Si cinco agentes necesitan realizar inferencias simultáneamente y existen varias máquinas disponibles, las solicitudes pueden repartirse en lugar de esperar todas a que quede libre una única GPU.
La arquitectura, simplificada, funciona así:
Agentes de IA
↓
PAIR
↓
┌────┼────┐
↓ ↓ ↓
PC Mac Workstation
↓ ↓ ↓
LLM LLM LLMPero existe una frontera que NVIDIA recalca en la documentación.
PAIR asigna cada petición independiente a un solo nodo.
Si un modelo necesita 80 GB de memoria para cargarse y hay cuatro equipos con 24 GB disponibles cada uno, PAIR no convierte automáticamente esos 96 GB en memoria compartida.
Tampoco realiza model sharding, tensor parallelism ni divide una inferencia en curso entre diferentes máquinas.
Su objetivo no es ejecutar un modelo demasiado grande para una GPU, sino distribuir mejor muchas tareas que sí pueden ejecutarse individualmente en los nodos disponibles.
El scheduler es la pieza más interesante y también una de las más inmaduras
La decisión sobre dónde ejecutar cada petición recae en el planificador de PAIR.
Según la documentación publicada, la política actual combina el trabajo que ya está en cola con una señal suavizada de utilización de GPU. El sistema intenta así evitar que nuevas solicitudes continúen llegando a una máquina que ya está ocupada.
NVIDIA reconoce que el mecanismo todavía tiene margen de mejora.
El scheduler actual no considera el modelo concreto de GPU, la memoria disponible, si un modelo ya está cargado en memoria ni el coste estimado de una petición. La propia documentación señala que PAIR funciona por ahora mejor con máquinas relativamente parecidas que con un clúster formado por hardware muy heterogéneo.
Entre las posibles líneas futuras aparece precisamente utilizar más señales para tomar esas decisiones y permitir diferentes políticas de planificación. NVIDIA presenta esas posibilidades como ideas para la evolución del proyecto, no como funciones comprometidas para una versión concreta.
Esta limitación ya ha provocado experimentos de la comunidad.
Uno de ellos intenta incorporar AMD Strix Halo con ROCm 10. Su autor explica que utilizó un agente de programación para trabajar sobre el repositorio y añadir la compatibilidad que necesitaba.
No se trata actualmente de soporte oficial de NVIDIA ni de una función que pueda darse por disponible en PAIR. Sin embargo, el experimento refleja una de las consecuencias de publicar el proyecto bajo Apache License 2.0: cualquier desarrollador puede modificar el código y proponer posteriormente sus cambios al proyecto.
Es también una situación curiosa dentro de la evolución reciente de la IA local. Un agente de programación puede trabajar sobre el código de una herramienta destinada, precisamente, a repartir las inferencias de otros agentes entre diferentes ordenadores.
PAIR apuesta por una IA local distribuida, pero sin salir de la red
Otro de los argumentos del proyecto está relacionado con dónde se procesan los datos.
PAIR está diseñado para que prompts y respuestas puedan permanecer dentro de la red local cuando todos los componentes utilizados sean también locales: cliente, motor, modelo y máquinas.
Eso no significa que PAIR garantice por sí mismo que ninguna aplicación se comunique con Internet. Un cliente configurado para utilizar servicios externos continuará teniendo sus propias comunicaciones. La privacidad depende del conjunto completo utilizado alrededor del router.
La comunicación entre los nodos también incorpora mecanismos específicos de confianza.
Los equipos se emparejan mediante un PIN de seis cifras y, una vez establecida la relación, utilizan TLS mutuo (mTLS) para las conexiones del clúster. La documentación recomienda realizar el proceso únicamente sobre redes consideradas fiables.
Este enfoque sitúa a PAIR dentro de una categoría que probablemente ganará importancia a medida que aumente la capacidad de los ordenadores personales para ejecutar modelos.
Hasta ahora las opciones más evidentes para aumentar recursos eran instalar una GPU mayor o trasladar la inferencia a infraestructura cloud. PAIR plantea utilizar mejor una tercera fuente de capacidad: el conjunto de máquinas que una persona o una organización ya tiene disponibles.
Eso puede tener aplicaciones en estaciones de trabajo de desarrolladores, laboratorios domésticos, pequeñas oficinas o entornos donde varios agentes de IA necesitan trabajar simultáneamente.
La utilidad aumenta cuanto más paralelas sean las tareas.
Un agente principal puede delegar programación a un modelo, documentación a otro y análisis a un tercero. PAIR podría enviar esas peticiones hacia distintas máquinas si todas disponen del modelo necesario.
No convierte esos ordenadores en un supercomputador. Los convierte en un grupo de recursos de inferencia que puede utilizarse de manera coordinada.
Esa diferencia explica tanto las posibilidades como las limitaciones del proyecto.
PAIR todavía está en una fase temprana y su scheduler tiene pendiente entender mejor las diferencias entre GPU, memoria y modelos. Pero su publicación como código abierto permite que esas limitaciones puedan ser estudiadas y modificadas fuera de NVIDIA.
La prueba con AMD Strix Halo es un primer ejemplo de lo que puede ocurrir cuando esa infraestructura deja de ser una caja cerrada.
Preguntas frecuentes
¿Qué es NVIDIA PAIR?
Personal AI Router es un proyecto de código abierto que distribuye peticiones independientes de inferencia de IA entre varios ordenadores conectados a una red local.
¿NVIDIA PAIR permite sumar la VRAM de varias GPU?
No. PAIR no agrega memoria ni divide un modelo entre diferentes máquinas. Cada petición completa se ejecuta en un único nodo que debe disponer de recursos suficientes para cargar el modelo.
¿Qué motores de IA funcionan con PAIR?
La documentación contempla Ollama y LM Studio, además de soporte limitado para llama.cpp en Linux. La compatibilidad final depende también del hardware, sistema operativo y controladores de cada nodo.
¿PAIR permite ejecutar IA sin utilizar la nube?
Sí, siempre que los modelos, motores, aplicaciones y nodos utilizados sean locales. PAIR está diseñado para mantener ese tráfico dentro de la red, pero no puede impedir que otros componentes configurados por el usuario contacten con servicios externos.
