Wie verteilt man lokale KI-Inferenz auf mehrere Rechner? Antwort darauf gibt NVIDIA Personal AI Router, kurz PAIR. Das ist kein Modell und keine Chat-Oberfläche, sondern eine Vermittlungsschicht. Sie fasst mehrere Rechner im selben Netzwerk zusammen und entscheidet für jede Anfrage, welcher Rechner sie ausführt. Wer Ollama oder LM Studio bisher auf einem einzelnen Gerät laufen lässt und dort an Grenzen stößt, kann den nächsten Schritt gehen. Er sollte nur wissen, was PAIR tut und was nicht.
Die Grundidee ist unspektakulär. Ein lokaler KI-Inferenz-Router löst kein Rechenproblem, sondern ein Verteilungsproblem. Er macht die Hardware nicht schneller, er sorgt dafür, dass sie überhaupt beschäftigt wird. In vielen Heimnetzwerken steht auf einem Rechner ein Modell im Leerlauf, während auf dem anderen eine Anfrage in der Warteschlange hängt. PAIR will diese Lücke schließen.
Was der Router im Heimnetzwerk tatsächlich tut
Ein Bild dafür: eine Werkstatt mit mehreren Werkbänken. Jede Werkbank hat eigene Maschinen und eigenes Werkzeug, und nicht jede Werkbank kann jede Arbeit erledigen. PAIR ist der Meister, der die Aufträge an der Tür entgegennimmt. Er schaut, welche Werkbank das passende Werkzeug hat und gerade frei ist, und schickt den Auftrag dorthin. Der Auftrag selbst wird nicht zerteilt. Er landet vollständig auf einer Werkbank und wird dort fertiggestellt.
Technisch heißt das: PAIR entdeckt teilnehmende Knoten im Netzwerk, verwaltet die unterstützten Inferenz-Engines und stellt Anwendungen zwei Proxy-Endpunkte bereit. Der eine spricht Ollama, der andere OpenAI. Unabhängige Anfragen werden nach Engine-Verfügbarkeit, Modell-Verfügbarkeit und aktueller Auslastung auf passende Knoten geroutet. Ein Knoten kommt erst dann als Kandidat in Frage, wenn dort tatsächlich eine kompatible Engine läuft. Knoten, die ein Modell schon im Speicher haben, kommen zuerst dran.
Viel ist das nicht, aber darum geht es bei verteilter Inferenz im Kleinen. Wer mehrere Agenten gleichzeitig laufen lässt, merkt das. Ein einzelner Rechner serialisiert die Arbeit, zwei oder drei Rechner im Verbund arbeiten daran parallel. Die Anfragen bleiben im lokalen Netz — vorausgesetzt, alle beteiligten Teile sind lokal: Clients, Modellquellen, Engines und Knoten. Nur dann verlassen Prompts und Antworten das Heimnetz nicht.
Ollama und LM Studio rechnen, PAIR verteilt
PAIR rechnet nicht selbst. Die Rechenarbeit übernehmen Ollama und LM Studio, und jedes dieser Programme stellt eigene Anforderungen an Betriebssystem, Grafikkarte und Treiber. Ob ein bestimmtes Modell auf einem bestimmten Rechner läuft, entscheidet also nicht PAIR, sondern die Engine auf diesem Rechner. Vor dem Koppeln lohnt deshalb der Blick in die Dokumentation der Engine, nicht in die von PAIR.
Die Oberfläche ist als Desktop-Anwendung gedacht, das ist der empfohlene Weg. Auf einer Knotenkarte lässt sich die Engine direkt installieren, PAIR lädt und richtet sie ein. Ebenso wird ein Modell über die Karte hinzugefügt; im Beispiel der Dokumentation ist das qwen4:12b. Danach steht der Endpunkt bereit. Wer einen schnellen Test will, schickt einen gewöhnlichen Aufruf an den lokalen Port:
curl http://127.0.0.1:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen4:12b","messages":[{"role":"user","content":"In one sentence, what does a router do?"}]}'Zurück kommt gewöhnliches JSON im OpenAI-Format, mit Modellname, Antworttext und Finish-Reason. Wenn du einen anderen Port benutzt oder statt Ollama LM Studio einsetzt, kopierst du die Adresse besser aus dem Bereich Endpunkte, statt die obige Zeile anzupassen. Anschließend taucht der Auftrag unter den Jobs auf, inklusive des Knotens, der ihn ausgeführt hat. Damit ist allerdings erst ein Rechner im Spiel, von Verteilung also noch keine Spur.
PAIR auf Windows, Linux und macOS installieren und einrichten
Für den Einstieg gibt es fertige Pakete: einen Windows-Installer, ein Debian-Paket und ein macOS-Disk-Image. Der Installer ist signiert, richtet Hintergrunddienste und Desktop-Anwendung gemeinsam ein und legt unter Windows die nötigen Firewall-Regeln an. Unter Linux installiert man das Paket aus dem Download-Verzeichnis heraus, etwa mit sudo apt install ./NVPAIR-Setup-....deb. Liegen mehrere Pakete dort, nennst du den vollständigen Dateinamen, um das richtige zu erwischen.
Die Anwendung läuft auf Windows 11, Linux und macOS, jeweils auf x64 und arm64; Windows on ARM gilt als experimentell. Entscheidend für gemischte Umgebungen: Knoten mit unterschiedlichen Betriebssystemen lassen sich miteinander koppeln. Ein Windows-Rechner, ein Linux-Server und ein Mac können denselben Verbund bilden. Auf Maschinen ohne grafische Oberfläche gibt es eine Terminal-Oberfläche, die dieselben Hintergrunddienste startet und die Aufgaben im Vollbild des Terminals erledigt.
Ein selbst gebauter Build ist dagegen unsigned und prüft keinen Update-Feed. Du müsstest ihn per Pull und Neubau aktualisieren. Wer die Desktop-Variante nutzt, bekommt in den Einstellungen unter Dienst angezeigt, wenn eine neue Version vorliegt, und installiert sie auf Zuruf. Für die meisten Haushalte ist das der einfachere Weg.
Zwei Rechner koppeln: der sechsstellige PIN
Die Verteilung entsteht erst mit dem zweiten Knoten, und die Kopplung ist einfach. Der einladende Rechner zeigt einen sechsstelligen PIN, der eingeladene Rechner gibt ihn ein. Beides läuft über die Cluster-Einstellungen. Danach wiederholst du auf der zweiten Maschine die Schritte für Engine und Modell, sonst kann sie nichts beitragen.
Zum Prüfen muss man keine eigene Anfrage schreiben. PAIR kann selbst Verkehr erzeugen und schickt für etwa eine Minute Inferenz durch denselben Pfad. In der Übersicht siehst du dann Aufträge auf beiden Maschinen laufen und beide Knoten ihren Live-Verbrauch an Grafikspeicher und Arbeitsspeicher melden. Es zeigt sofort, ob die Verteilung greift oder ein Knoten stumm bleibt.
Für eigene Anwendungen sind die Endpunkte der eigentliche Anknüpfungspunkt. Weil sie Ollama-kompatibel und OpenAI-kompatibel sind, funktionieren bestehende Clients und Agenten-Frameworks in der Regel ohne Umbau. Du tauschst schlicht die Basis-URL. Wer mehrere Agenten parallel betreibt, profitiert hier.
Was PAIR ausdrücklich nicht leistet
Die Projektseite ist an dieser Stelle deutlich. PAIR leitet jede unabhängige Anfrage an genau einen Knoten. Es bündelt keinen Grafikspeicher, es fasst keine Grafikkarten zu einer größeren logischen Einheit zusammen, es verteilt kein einzelnes Modell über mehrere Maschinen und es teilt keine laufende Inferenz auf. Aus der Werkstatt-Analogie folgt: Man kann nicht zwei kleine Werkbänke zu einer großen verschmelzen. Ein Auftrag, der auf keiner einzelnen Werkbank Platz hat, bleibt liegen.
Auch die Auswahlpolitik ist derzeit schlicht. PAIR kombiniert wartende Arbeit mit einem groben, geglätteten Signal für die GPU-Auslastung. Es berücksichtigt weder das Modell der Grafikkarte noch den freien Speicher, noch ob ein Modell bereits warm im Speicher liegt, noch wie teuer eine Anfrage vermutlich wird. Das Projekt nennt das selbst eine offene Baustelle und sammelt Vorschläge über Issues. Wenn du heute planst, rechne mit dieser einen Politik, nicht mit einer ausgefeilten Lastverteilung.
Der zweite Punkt betrifft das Aufräumen. PAIR zu entfernen und die eigenen Daten zu löschen sind getrennte Vorgänge, und der Standard behält die Daten. Unter Linux trennt apt remove von apt purge, unter macOS macht ein Skript im App-Bundle die Arbeit, und unter Windows fragt der Deinstaller nach. Wichtig: Modellgewichte bleiben in jedem Fall erhalten, sie liegen im Speicher der Engine, etwa unter ~/.ollama. Willst du Speicher freimachen, löschst du Modelle über die Engine oder entfernt deren Verzeichnis.
Wann sich der lokale Router im Heimnetz lohnt
Für den typischen Einzelplatz mit einer Grafikkarte ändert PAIR wenig. Das Modell läuft ohnehin dort, und die Verteilung hat kein Ziel. Interessant wird es, sobald mehrere Rechner mit eigener GPU im Haushalt stehen und gleichzeitig Anfragen anfallen. Ein Spielrechner unter Windows, ein kleiner Linux-Server und ein Mac mit Apple-Chip sind das Szenario, für das der Verbund gedacht ist. Voraussetzung bleibt, dass auf jedem Knoten eine Engine mit dem passenden Modell läuft.
Ein Detail, das man beim Ausprobieren leicht übersieht: Wer einen Knoten aus einem Verbund nimmt, sollte ihn vorher verlassen oder ihn von einem anderen Knoten aus entfernen. Sonst listen die übrigen Maschinen ihn weiter als Mitglied. Der zweite Weg funktioniert auch nachträglich, ein vergessener Austritt ist also reparabel. Für einen Neustart nach einem kaputten Cluster gibt es den Befehl zum Zurücksetzen der App-Daten, der Einstellungen, Logs, Cluster-Identität und die von PAIR installierten Engines entfernt. Die Modellbibliothek bleibt auch hier unberührt.
Unterm Strich schafft NVIDIA Personal AI Router keine zusätzliche Leistung. Er verteilt, was da ist. Wer mehrere Maschinen im Heimnetzwerk betreibt und lokale KI ohne Cloud nutzen will, kann damit Inferenz auf mehrere Rechner aufteilen. Die Grenzen sollte man kennen, und die Auswahlpolitik wird noch wachsen.
Quelle: github.com
