NVIDIA PAIR im Test: Lokales KI-Routing und die AMD-ROCm-Lücke

NVIDIA Personal AI Router, kurz PAIR, ist eine lokale Control Plane für unabhängige KI-Inference-Anfragen. PAIR entdeckt Rechner im Netzwerk, prüft, welche Engine und welches Modell jeder Node bedienen kann, beobachtet Workload und GPU-Druck und leitet jede neue Anfrage an einen geeigneten Node weiter. Dein Agent spricht weiter mit einem vertrauten Ollama- oder OpenAI-kompatiblen Endpoint.

Stell dir Kubernetes für den Stapel KI-Rechner vor, der sich in deinem Zuhause versteckt, aber mit einer wichtigen Korrektur. PAIR ist kein Container-Orchestrator, bündelt kein VRAM und macht aus mehreren GPUs keine riesige GPU. Es platziert vollständige Inference-Jobs auf vollständigen Modell-Replikaten. Das hilft fünf Subagenten, die sonst um eine GPU streiten wie Tauben um eine Pommes. Ein zu großes Modell passt dadurch nicht plötzlich auf fünf Maschinen.

Die Architektur ist für eine neue Beta ungewöhnlich gut lesbar. Auch die interessante Lücke ist klar: NVIDIA validiert RTX, DGX Spark und Apple M4+, AMD Strix Halo fehlt. Ich habe einem Coding Agent deshalb einen konkreten Auftrag gegeben: ROCm 10 und Strix Halo ergänzen. Zum Veröffentlichungszeitpunkt ist das ein Engineering-Workstream, kein offizieller Upstream-Support. Dieser Test erklärt, was PAIR bereits kann, was der Sourcecode über AMD verrät und was ein glaubwürdiger Port beweisen muss, bevor jemand dafür Hardware kauft.

Was ist NVIDIA PAIR?

Das Open-Source-Repository von NVIDIA PAIR beschreibt Software für kompatible Windows-, Linux- und macOS-Rechner im selben Netzwerk. PAIR entdeckt Nodes, verwaltet unterstützte Engines und bietet Ollama- sowie OpenAI-kompatible Proxy-Endpoints. Das Repository steht unter Apache 2.0. Das veröffentlichte Desktop-Paket beaufsichtigt mehrere kleine Go-Services hinter einer Electron-Oberfläche.

Eine Anfrage folgt einem einfachen Pfad:

1. Die Anwendung ruft den lokalen PAIR-Proxy auf, meist über den bereits erwarteten Port.
2. Der Proxy liest Engine und angefordertes Modell aus.
3. Nodes ohne laufende Engine oder exaktes Modell scheiden aus.
4. Die übrigen Nodes werden anhand des Scheduler-Zustands geordnet.
5. Ein Node führt die ganze Anfrage aus und streamt die Antwort über denselben Pfad zurück.

Die offizielle PAIR-Architekturdokumentation trennt Modell-Eignung von Last-Ranking. Der Scheduler kennt Modelle nicht. Er ordnet Nodes nach wartender Arbeit plus einem groben Druckwert aus geglätteter GPU-Auslastung. Der Proxy wendet diese Reihenfolge nur auf Nodes an, die das angeforderte Modell melden. Das trennt Capability und aktuelle Last sauber.

Kombiniert PAIR GPUs oder teilt es ein Modell?

Nein. Jede Inference-Anfrage läuft von Anfang bis Ende auf einem Node. PAIR kann den Durchsatz erhöhen, wenn ein Workload unabhängige Calls enthält. Es bündelt keinen GPU-Speicher, teilt keine Modell-Layer, zerlegt keine laufende Anfrage und migriert sie nach dem Dispatch nicht.

Diese Trennung verhindert Keyword-Verwirrung und teure Architekturfehler. Wähle PAIR, wenn Replikate auf einzelne Rechner passen und Queueing das Problem ist. Wähle Model Parallelism, wenn das Modell selbst nicht passt. Wähle ein Gateway, wenn Provider-Policy, Budgets oder Cloud-Fallback die harte Grenze bilden.

Wie viel schneller ist NVIDIA PAIR für mehrere Agenten?

NVIDIAs PAIR-Launch-Demonstration nutzte Hermes Desktop, fünf Subagenten, Ollama und Qwen 3.6 35B A3B. NVIDIA berichtet im Mittel 18 Minuten auf einem RTX-Spark-Laptop und 8 Minuten 48 Sekunden auf einem Cluster aus diesem Laptop, einem DGX Spark und einer RTX 5090.

Das sind 51 Prozent weniger Laufzeit für genau diese Demonstration, keine allgemeine 2x-Aussage. NVIDIA nennt den Test ausdrücklich inoffiziell und konfigurationsspezifisch. Parallelität, Modell-Replikate, Engine-Einstellungen, Netzwerk, Prompt-Form und Node-Verfügbarkeit verändern das Ergebnis. Die richtige Business-Metrik ist Kosten pro akzeptierter Aufgabe bei einer Ziel-Latenz, nicht die Zahl der GPUs in der PAIR-Oberfläche.

Der Scheduler hat bewusste Grenzen. GPU-Modell, verfügbares VRAM, gemessene Request-Latenz, warmer Modellzustand und erwartete Request-Größe fließen nicht ein. Jeder wartende Workload zählt als eins. In einem gemischten Cluster erhalten eine kleine und eine große GPU bei gleicher Auslastung denselben Druckwert. Das ist nachvollziehbares Beta-Verhalten, verlangt im Unternehmenspilot aber eigene Routing- und Tail-Latency-Evidenz.

Warum ist AMD Strix Halo kein validierter PAIR-Node?

Die Antwort ist differenzierter als „PAIR blockiert AMD“. PAIR selbst kann auf unterstützten x64-Betriebssystemen laufen. Ollama führt Ryzen AI Max inzwischen in seiner Linux-GPU-Tabelle. Es fehlt der vollständige validierte Pfad von Hardware-Erkennung über Telemetrie und Engine-Verhalten bis zur Support-Policy.

NVIDIAs Seite mit bekannten PAIR-Problemen erklärt: Linux-Rechner ohne NVIDIA-Treiber können AMD- oder Intel-Grafik beim Namen auflisten, melden aber weder GPU-Speicher noch Auslastung. Unter Windows kann bei integrierten GPUs mit Unified Memory ein zu kleiner Speicherwert erscheinen, weil PAIR nur dedizierten GPU-Speicher zählt. Laut NVIDIA entscheidet die Speicheranzeige nicht direkt über Routen. Fehlende Auslastung schwächt dennoch das Verständnis des Schedulers für aktuellen Druck.

Der Sourcecode macht die Linux-Grenze konkret. Der Linux-GPU-Detektor ruft zuerst nvidia-smi auf. Fehlt das Tool, fällt er auf generische PCI-Erkennung zurück. Diese liefert einen Adapter-Namen, aber kein VRAM-Gesamtvolumen, keinen stabilen Join-Key für Telemetrie und keine dynamische Auslastung. Windows nutzt bereits herstellerneutrales DXGI und Performance-Data-Helper-Counter. Der größte hardwarespezifische fehlende Pfad betrifft damit Linux-Telemetrie und die Interpretation von Unified Memory.

Was braucht ein echter ROCm-10- und Strix-Halo-Port?

Eine Hardware-Allowlist zu ändern reicht nicht. Ein Beitrag muss das bestehende Verhalten ohne AMD-Tools erhalten, Telemetriefehler von Routingfehlern trennen und Strix-Halo-Speicher ehrlich modellieren.

1. AMD-Geräte stabil identifizieren. Die AMD-SMI-CLI bietet JSON-Ausgabe, UUIDs, BDF-Adressen, GFX-Auslastung und Speicherwerte. Ein Collector kann statische und dynamische Samples verbinden, ohne eine menschlich formatierte Tabelle zu parsen.
2. Collection begrenzen. Timeout, Hintergrund-Sampling im Sekundentakt, Freshness und Last-Good-Value sollten den bestehenden Mustern folgen. Ein hängender Treiber darf den Node-Info-Service nicht blockieren.
3. Unified Memory korrekt behandeln. Die gfx1151-GPU in Strix Halo teilt sich einen großen LPDDR5X-Pool. Dediziertes VRAM unterschätzt die Kapazität. Gesamter Systemspeicher kann überschätzen, was die Engine sicher allozieren darf. Die UI sollte die Quelle benennen.
4. Telemetrie und Engine-Support trennen. Eine erkannte AMD-GPU beweist nicht, dass Ollama oder LM Studio das gewählte Modell korrekt ausführt. Version, Treiber, Backend, Kontextlänge und Modellarchitektur bleiben eigene Gates.
5. Gemischte Cluster testen. Abdecken sollte man NVIDIA plus AMD, alte AMD-SMI-Daten, fehlende Tools, echte Null-Prozent-Samples, mehrere Adapter, Suspend, Restart und ein Modell auf nur einem Node.

Die Release Notes zu ROCm 10.0.0 nennen breitere Inference-, Tooling- und Profiling-Arbeit, einschließlich verbessertem Profiler-Support für gfx1151. Das ist nützliche Infrastruktur, aber eine neue ROCm-Hauptversion ist kein PAIR-Kompatibilitätszertifikat. PAIR, AMD SMI, Treiber, Engine und Modell müssen zusammenpassen.

Die Engine-Schicht verdient besondere Vorsicht. Die Ollama-Seite zum GPU-Support listet Ryzen AI Max+ 395, Max 390 und Max 385 für Linux und dokumentiert ROCm- sowie Vulkan-Pfade. Der aktuelle Support-Vertrag nennt ROCm v7, nicht ROCm 10. Ein ROCm-10-Experiment mit PAIR braucht daher eine explizite Engine-Matrix. Ein Telemetrie-Port aktualisiert das Inference-Backend nicht automatisch.

Ist PAIR sicher genug für vertrauliche Unternehmensdaten?

PAIR hält Inference-Traffic im lokalen Netzwerk, wenn Anwendung, Engine, Modellquelle und Nodes lokal sind. Gekoppelte Nodes nutzen gepinnte Zertifikate und Mutual TLS. Klartext-Anfragen akzeptiert der Proxy nur über Loopback. Nicht gekoppelte Maschinen können den Cluster-Ingress nicht als Mitglieder aufrufen.

Lokal bedeutet nicht unsichtbar. Laut Architektur sind Node-Telemetriedaten unverschlüsselt und nicht authentifiziert. Eine Maschine im selben Subnetz kann Hostname, Hardware-Inventar und Auslastung lesen. Die Kopplung beginnt mit einer kurzen PIN über Klartext, bevor Zertifikate gepinnt werden. Nutze ein vertrauenswürdiges segmentiertes Netzwerk, prüfe Firewall-Freigaben, sichere die Rechner selbst und halte sensible Request-Bodies aus Logs. Bei regulierten Daten brauchst du zusätzlich Threat Modeling, Retention-Regeln, Patch-Verantwortung und einen Incident-Prozess.

Wann sollte ein Unternehmen NVIDIA PAIR einsetzen?

Sieben Schritte für einen PAIR-Piloten vor dem nächsten GPU-Kauf

1. Akzeptierte Aufgabe definieren. Qualität, Tool-Call-Korrektheit, Kontextlänge und Timeout erfassen, nicht nur Tokens pro Sekunde.
2. Einzelnen Node messen. Queue-Zeit, Time to First Token, Gesamtzeit, Strom und Fehlerquote aufnehmen.
3. Ein Modell replizieren. Dasselbe Modell auf zwei Nodes ablegen, damit Routing eine echte Wahl hat.
4. Realistische Parallelität hinzufügen. Zahl und Mischung der Subagenten aus dem echten Workflow abspielen.
5. Platzierung beobachten. Prüfen, ob Jobs-Ansicht, GPU-Telemetrie und Engine-Logs denselben Ausführungsort zeigen.
6. Cluster absichtlich brechen. Laptop schlafen legen, Engine stoppen, Modell entfernen und GPU anderweitig sättigen.
7. Vollständige Alternativen vergleichen. Nutze das Break-even-Modell für lokale LLMs und APIs, bevor ungenutzte Hardware als kostenlos gilt.

Enthält der Pilot proprietären Code oder Dokumente, verbinde die Routing-Entscheidung mit Evals, Zugriffskontrolle und Rollback. Unsere Twinsoft-AI-Case-Study zeigt den Weg vom KI-Workflow zum Produktionssystem. Der Guide zur Technologie-Stack-Entscheidung verhindert, dass eine spannende Komponente die ganze Architektur bestimmt.

Quellen und Methodik

Dieser Test wurde am 4. September 2026 mit NVIDIAs Repository, Architektur, Launch-Demonstration und Known-Issues-Dokumentation sowie den aktuellen Dokumentationen zu AMD SMI, ROCm 10 und Ollama geprüft. Wir haben die Linux- und Windows-Telemetrieimplementierung sowie den Scheduler-Sourcecode untersucht. NVIDIAs Benchmark wurde nicht reproduziert. Wir behaupten nicht, dass die geplante AMD-Arbeit gemergt, unterstützt oder abgeschlossen ist. Produkt-Support ändert sich schnell. Pinne im Piloten deshalb PAIR-Release, Treiber, Engine und Modell.