Nvidia PAIR verteilt Anfragen, nicht Modelle

Nvidia hat am 03.09.2026 auf der IFA den Personal AI Router vorgestellt, kurz PAIR. Er verteilt lokale KI-Anfragen über mehrere Geräte im eigenen Netz, steht unter Apache 2.0 und läuft auf Windows, Linux und macOS. Der Code lag übrigens schon länger da: Version 0.1.0 wurde am 26.08.2026 veröffentlicht, 0.1.1 am 28.08. Die Ankündigung kam eine Woche später.

Für alle, die lokale Modelle betreiben, ist das interessant. Zuerst sollte aber geklärt sein, was PAIR nicht macht, denn genau da liegt der naheliegende Irrtum.

Was PAIR nicht tut

Beim Stichwort "mehrere Rechner bündeln" drängt sich ein Gedanke auf: Endlich läuft ein großes Modell auf drei kleinen Kisten. Genau das Gegenteil ist der Fall.

Nvidia dementiert das in den eigenen Texten viermal, was zeigt, dass man mit dem Missverständnis rechnet. Aus dem Blogbeitrag:

"This is workload-level concurrency. PAIR does not make one inference request run across several GPUs. Every request is assigned to one eligible node and remains there for its lifetime."

Und aus dem README, dort eigens hervorgehoben:

"PAIR routes each independent request to one node. It does not pool GPU memory, combine GPUs into a larger logical GPU, shard one model across machines, or split an in-flight inference request between nodes."

Daraus folgen zwei Dinge, die man vor dem Aufsetzen wissen sollte. Erstens bleibt für jede einzelne Anfrage die GPU des ausführenden Geräts exakt die Grenze, und was auf eurer stärksten Maschine schon heute nicht läuft, wird auch mit PAIR im Netz nicht laufen. Zweitens braucht jeder Knoten, der ein bestimmtes Modell bedienen soll, eine eigene Kopie davon. Die Architektur-Doku ist da deutlich: "One copy of a model means no balancing for it. Every request naming it goes to the node advertising it, however loaded that node is."

Wer den anderen Weg sucht, also ein Modell auf mehrere Geräte aufteilen, ist bei llama.cpp RPC, exo oder distributed-llama richtig. Die machen genau das, was PAIR ausdrücklich nicht macht, und sind damit keine Konkurrenz, sondern die andere Achse. Auf derselben Achse liegt auch slotstream, das wir Anfang September beschrieben haben: ein 104-GB-Modell auf einem 48-GB-Mac, per Expertenladung von der SSD.

Ein Nebenaspekt aus dem Praxistest von XDA macht die Trennung anschaulich. Der Tester betreibt zwei DGX Sparks, die untereinander ihren Speicher poolen. Gegenüber PAIR erscheinen die beiden als ein einziger Knoten. Das Sharding passiert also eine Ebene tiefer, unterhalb des Verteilers.

Was PAIR stattdessen tut

Es routet gleichzeitige, voneinander unabhängige Anfragen auf verschiedene Geräte. Etwas zu verteilen gibt es also erst dort, wo eine Last mehrere Modellaufrufe parallel erzeugt, und das ist in der Praxis der Agent mit Subagenten.

Am klügsten gelöst ist die Integration. PAIR belegt die Standardports der Inferenz-Engines und schiebt diese eine Stelle weiter: Der Ollama-kompatible Proxy sitzt auf 11434, Ollama selbst wandert auf 11435. Der OpenAI-kompatible Proxy sitzt auf 1234, LM Studio auf 1235. Für den Agenten ändert sich damit nichts, er spricht weiter dieselbe Adresse an. Es gibt bewusst keine eigene Cluster-API, an die man sich anpassen müsste. Läuft auf dem Port schon eine Engine, übernimmt PAIR sie, statt eine zweite zu starten.

Unterstützt sind offiziell nur Ollama und LM Studio. Modelle müssen nicht auf allen Knoten identisch sein, gemischte Bestände sind ausdrücklich vorgesehen. Anfragen nach der Modellliste beantwortet der Proxy, indem er alle Knoten parallel fragt und die Antworten zusammenführt. Am Proxy erscheint deshalb das Inventar des ganzen Verbunds statt das einer einzelnen Maschine.

Die Geräte finden sich per mDNS, die Vertrauensbeziehung wird über eine sechsstellige PIN aufgebaut, danach läuft die Kommunikation über mTLS.

Die Demo-Zahlen, und was sie wert sind

Nvidias Beispiel ist eine Analyse mit fünf Subagenten auf Qwen 3.6 35B A3B, orchestriert über Hermes Desktop, ausgeführt von Ollama:

Nvidia schreibt selbst dazu: "Note that this is an unofficial, configuration-specific demo, not a general benchmark or a promise of linear scaling." Nicht angegeben sind die Anzahl der Durchläufe hinter "im Mittel", die Speicherbestückung der Geräte, die Netzgeschwindigkeit und die Quantisierung des Modells. Wir haben nichts davon nachgemessen. Die Richtung ist plausibel, die Zahl ist eine Herstellerangabe.

Nvidia benennt auch, wann es nichts bringt: "Highly sequential tasks, workloads dominated by one long model call, or configurations in which only one node has the requested model may see less benefit."

Eine Einordnung aus der Berichterstattung sollte man dagegen nicht übernehmen. heise schreibt, die Leistungsfähigkeit werde mit PAIR "immerhin nicht mehr so stark von der GPU eines einzelnen Heimatgeräts limitiert". Für die einzelne Anfrage stimmt das nicht, dort limitiert genau diese eine GPU weiterhin vollständig.

Der Reifegrad ist 0.1.1, und das merkt man

Hier wird es unbequem. Stand 05.09.2026 hat das Repository elf offene und null geschlossene Issues, und seit dem 28.08.2026 hat niemand mehr etwas hineingeschoben. Der Support ist laut eigener Aussage "best-effort. Maintainers do not guarantee a response or a resolution time."

Die gravierendsten offenen Punkte:

• Kernel-Panics auf Apple Silicon (Issue 19). Der Netzwerk-Scanner ruft eine Multicast-Abfrage alle fünf Sekunden auf allen Betriebssystemen auf, obwohl sie als Windows-Behelf gedacht war. Auf macOS führt das laut Melder zu Lock-Konflikten in der Routing-Tabelle, das System friert ein und startet neu.
• macOS bekommt keine Freigabe fürs lokale Netz (Issue 3). Dem ausgelieferten Bundle fehlt der nötige Schlüssel, es erscheint nie ein Berechtigungsdialog, mDNS scheitert. Der Melder hat mit ergänzten Schlüsseln selbst neu gebaut, es half nicht. Funktionierender Umweg: das Terminal-Interface statt der Desktop-App starten, dann erben die Prozesse die Freigabe des Terminals.
• Ein eingefrorener Knoten ist teurer als gar kein Knoten (Issue 6). Sauber gemessen mit 24 parallelen Anfragen auf zwei Maschinen:

Der eingefrorene Nachbar ist damit gut viermal so langsam wie ein gesunder Verbund. Ein geschlossener Socket antwortet sofort mit einer Abweisung, ein angenommener und dann stummer Socket kostet pro Anfrage einen vollen Verbindungs-Timeout. Das Aussortieren dauerte bis zu 75 Sekunden. Der Haken daran: Genau dieser Zustand ist der eines zugeklappten Notebooks, also des Geräts, das Nvidia als vollwertigen Knoten bewirbt.

Dazu kommen Grenzen, die Nvidia selbst auflistet. Der Verteiler zählt nur laufende Aufträge, nicht deren Größe: "A three-token completion and a long generation are the same unit of pending work." Er kennt weder GPU-Klasse noch freien Speicher noch gemessene Latenz. Er weiß nicht, auf welchem Knoten ein Modell schon warm im Speicher liegt. Und Inferenz, die direkt am Engine-Port vorbeigeht, sieht er gar nicht. Das README räumt ein, die aktuelle Verteilstrategie sei "a better fit for similar machines than a highly mixed cluster".

Was Nvidia hier richtig macht

Bei aller Kritik gehört ein Absatz in die andere Richtung. In dieser Branche ist er selten geworden.

Nvidia dokumentiert diese Schwächen selbst, in eigenen Dateien, unaufgefordert und in klarer Sprache. Es gibt eine Datei mit bekannten Problemen, einen Abschnitt "Scheduler Limitations", der die Grenzen laut Vorspann "stated plainly so you can predict where routing falls short" auflistet, und ein SECURITY.md, das mit diesem Satz beginnt:

"These statements describe security boundaries visible in the current source. They are not claims that every deployment is secure."

Wer schon einmal versucht hat, aus einer Herstellerdokumentation herauszulesen, was ein Produkt nicht kann, weiß, wie ungewöhnlich das ist. Bemerkenswert ist auch, wo die Kritik an PAIR steht. Sie steht in Nvidias eigenen Dateien und im Issue-Tracker, kaum in Foren: Die Hacker-News-Einreichungen dazu kommen auf einstellige Punktzahlen.

Bevor ihr das ins Firmennetz stellt

Gebaut ist PAIR fürs Heimnetz, und Nvidia sagt das auch. Aus dem SECURITY.md:

"Treat an untrusted Wi-Fi, shared office network, compromised router, and hostile local process as potentially adversarial. Network segmentation and host firewall rules remain the operator's responsibility."

Die Punkte, die dabei zählen: Die sechsstellige PIN ist ausdrücklich schwach und "not a durable credential". Die lokalen Schnittstellen haben kein Token pro Nachricht, wer den Endpunkt erreicht, kann Inferenz einkippen. Deshalb nimmt der Klartext-Endpunkt auch nur Verbindungen von der eigenen Maschine an, sonst wäre jeder Knoten ein offenes Relay. mTLS deckt die Verbindungen zwischen Knoten ab. Außen vor bleiben dabei die Engine-APIs dahinter, die lokale Kommunikation und die Erkennungsdaten, die teils über einfaches HTTP laufen. Die Arbeitsprozesse laufen mit den Rechten des angemeldeten Nutzers.

Und ein Satz, den man beim Stichwort lokale KI gern überliest, hier aber vom Hersteller kommt:

"'Local-first' describes the intended topology. It does not prove that no data leaves the machine or LAN."

Für eine DSGVO-Argumentation ist PAIR also kein Baustein, sondern höchstens ein Transportweg. Die Frage, ob Daten das Haus verlassen, beantworten weiterhin die Engine, der Modellkatalog und die Anwendung darüber.

Hardware, und was die Liste wirklich bedeutet

Als validierte Konfigurationen nennt Nvidia alle GeForce RTX ab der 20er-Serie, RTX-PRO-Karten ab Turing, DGX Spark sowie Apple-Silicon ab M4, dazu 8 GB Arbeitsspeicher. Eine VRAM-Untergrenze steht nirgends.

Diese Liste ist eine Aufzählung getesteter Kombinationen und keine technische Sperre. Im Quelltext gibt es keine Hardwareprüfung, die fremde GPUs abweist, und die Dokumentation führt Linux mit AMD- oder Intel-Grafik als bekannten Fall. Dort fehlt die Speicheranzeige. Folgen hat das keine: "The impact is display, not routing. Routing does not consider VRAM at all, because the scheduler counts workloads."

Das README bringt die eigentliche Regel auf den Punkt:

"PAIR running on a machine does not mean an engine will."

PAIR selbst stellt kaum Ansprüche. Die echten Anforderungen kommen von Ollama beziehungsweise LM Studio und vom Modell.

Was das für euch heißt

Fazit

PAIR löst ein echtes Problem, aber ein engeres, als die Ankündigung vermuten lässt. Wer lokale Agenten mit mehreren Subagenten betreibt und mehr als eine passende Maschine im Netz stehen hat, bekommt hier einen Weg, die zweite Maschine mitzunutzen, ohne den Agenten anzufassen. Das ist ordentlich gebaut, quelloffen und an der richtigen Stelle unsichtbar.

Wer drei kleine Geräte zu einem großen zusammenschalten will, ist hier falsch. Und wer heute Verlässlichkeit braucht, wartet besser auf ein paar geschlossene Issues.

Bemerkenswert bleibt der Zeitpunkt. Zwei Tage nachdem ChatGPT, Claude und Grok gleichzeitig ausgefallen sind, veröffentlicht der größte Profiteur des Cloud-Booms ein Werkzeug, dessen einziger Zweck es ist, Rechenleistung im eigenen Wohnzimmer besser auszunutzen.

Über Ollama führt der Einstieg in lokale Modelle weiterhin. Und die Frage nach der passenden Hardware beantwortet unser Test lokaler Modelle genauer als jede Kompatibilitätsliste.