NVIDIA PAIR: un router virtuale open source per distribuire inferenza AI sulla rete locale

Cosa è accaduto

NVIDIA ha pubblicato in beta PAIR (Personal AI Router), un router virtuale di inferenza open source che distribuisce richieste AI locali tra più macchine presenti sulla stessa rete. PAIR non è un nuovo motore di inferenza: si pone come proxy e scheduler, scoprendo nodi compatibili e instradando singole chiamate di modello verso il sistema idoneo, con l'obiettivo dichiarato di ridurre code e sprechi su macchine inattive.

Perché è importante

La novità risponde a un limite pratico dei flussi agentici locali: quando un lead agent genera decine di subagent, molte chiamate concorrenti possono saturare un singolo motore locale. PAIR evita che gli harness agent cambino API, perché si interpone sui punti di accesso Ollama- e LM Studio-compatibili (e offre anche endpoint compatibili OpenAI). Il software è distribuito come beta pubblica (v0.1.1), con installer firmati per Windows, macOS e Linux e codice sorgente rilasciato sotto licenza Apache 2.0 su GitHub.

Possibili impatti

Dal lato operativo, PAIR può ridurre i tempi di esecuzione aggregando capacità su più dispositivi locali. Nella demo presentata, abbinando PAIR a Hermes Desktop e usando Qwen 3.6 35B A3B tramite Ollama, un carico di cinque subagent è passato da una media di 18 minuti su un singolo laptop a 8 minuti e 48 secondi su un cluster di tre dispositivi (RTX Spark laptop, DGX Spark e RTX 5090). Queste misure ufficiali sono presentate come dimostrative e soggette a caveat.

La piattaforma è pensata per essere semplice da distribuire in ambienti domestici o di laboratorio: PAIR usa mDNS per la scoperta automatica dei nodi, accetta aggiunte manuali via IP, stabilisce fiducia con un PIN a sei cifre e protegge le comunicazioni fra nodi con mTLS. Inoltre può automatizzare l'installazione di Ollama o LM Studio e l'avvio dei download dei modelli sui sistemi accoppiati.

Al tempo stesso esistono limiti tecnici espliciti: PAIR assegna ciascuna richiesta a un solo nodo per tutta la durata dell'esecuzione. Non effettua pooling della VRAM, non unisce più GPU in un unico acceleratore logico e non shardizza una singola richiesta tra macchine. Il scheduler valuta cinque segnali di eleggibilità: presenza online e readiness del nodo, engine abilitato, presenza esatta del modello richiesto, job load e utilizzo GPU.

Una possibile lettura

PAIR appare come uno strumento pratico per aumentare l'utilizzo di risorse GPU disponibili in cluster locali eterogenei, particolarmente dove flussi agentici generano molte chiamate parallele verso motori locali. Per team e sperimentatori può semplificare il passaggio da un singolo endpoint a una capacità distribuita senza richieste di modifica agli harness agent.

Nel medio termine, l'efficacia reale dipenderà dall'evoluzione delle politiche di scheduling e dal supporto a scenari più complessi: ad esempio, la capacità di considerare classi di GPU, warmness dei modelli o strategie di caching e prefetching potrebbe determinare guadagni aggiuntivi rispetto alla politica iniziale, oggi descritta come unica e ancora insensibile ad aspetti come la VRAM aggregata o lo stato di warm start dei modelli.

Fonte: MarkTechPost