--- title: "NVIDIA PAIR Test: AMD ROCm und Strix Halo" canonical: https://wavect.io/de/blog/nvidia-pair-amd-rocm-strix-halo/ language: de description: "So routet NVIDIA PAIR lokale KI-Jobs. Prüfe die AMD-ROCm-10- und Strix-Halo-Lücke sowie die Gates vor einem geschäftlichen Einsatz." image: "https://wavect.io/img/blog/headers/header_nvidia-pair-amd-rocm-strix-halo.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 Min Lesezeit · 4. September 2026 Zuletzt geprüft 4. September 2026 [**Weiter**](/de/blog/claude-rotate-multi-account-proxy/) # NVIDIA PAIR im Test: Lokales KI-Routing und die AMD-ROCm-Lücke TL;DR NVIDIA Personal AI Router, kurz PAIR, ist ein Apache-2.0-lizenzierter lokaler Inference-Router für unabhängige Anfragen an Ollama und LM Studio. Agenten nutzen einen vertrauten Endpoint. PAIR filtert Nodes nach Engine und vorhandenem Modell und ordnet geeignete Rechner dann anhand wartender Jobs und grobem GPU-Druck. Es bündelt weder VRAM noch teilt es ein Modell oder beschleunigt eine einzelne Anfrage über mehrere GPUs. NVIDIA berichtet für eine Demo mit fünf Subagenten von 18 Minuten auf einem RTX-Spark-Laptop gegenüber 8 Minuten 48 Sekunden auf einem Cluster mit drei Geräten, bezeichnet das Ergebnis aber selbst als konfigurationsspezifisch. AMD Strix Halo ist keine validierte Konfiguration. Unter Linux kann PAIR eine AMD-GPU auflisten, erfasst derzeit aber weder Speicher noch Auslastung. Ein belastbarer ROCm-10-Beitrag braucht daher AMD-SMI-Integration, korrekte Unified-Memory-Semantik, stabile Geräte-IDs, Fallbacks und Tests. Bis zur Upstream-Prüfung und Validierung mit echten Agent-Workloads bleibt der Beitrag experimentell. **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. | Frage | Aktuelle Antwort | Geschäftliche Bedeutung | | --- | --- | --- | | Was ist PAIR? | Ein lokaler Inference-Router unter Apache 2.0 | Routing-Layer prüfen, anpassen und selbst betreiben, ohne den Agent-Harness umzubauen. | | Welche Engines? | Ollama und LM Studio | Engine- und Modell-Kompatibilität bleibt Sache jedes Nodes. | | Was wird verteilt? | Unabhängige, vollständige Anfragen | Mehr parallele Jobs nutzen mehr Maschinen. Ein einzelner Job wird nicht automatisch schneller. | | Was entscheidet die Platzierung? | Node-Bereitschaft, Engine, Modell, wartende Jobs und grober GPU-Druck | Gut für elastische lokale Kapazität, kein vollständiger Kosten- oder Latenzoptimierer. | | Welche Hardware ist validiert? | RTX 20 Series und neuer, RTX PRO, DGX Spark und Apple M4+ | AMD-Nodes brauchen eigene Validierung, selbst wenn PAIR und Engine starten. | | Wie sind Peer-Anfragen geschützt? | Gepinnte Zertifikate und Mutual TLS | Inference bleibt im lokalen Netzwerk, doch das Netzwerk gehört zum Threat Model. | ## Was ist NVIDIA PAIR? Das [Open-Source-Repository von NVIDIA PAIR](https://github.com/NVIDIA/Personal-AI-Router) 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](https://docs.nvidia.com/local-ai/nvpair/architecture/) 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. | Architektur | Einheit der Platzierung | Hauptnutzen | Passender Wavect-Guide | | --- | --- | --- | --- | | NVIDIA PAIR | Eine vollständige Anfrage | Replikate über elastische lokale Nodes nutzen | Dieser Test | | Mesh LLM | Layer-Stages eines Modells | Ein Modell über den kombinierten Speicher mehrerer Rechner ausführen | [Mesh LLM für verteilte Inference](/de/blog/mesh-llm-distributed-inference-multiple-computers/) | | OmniRoute | Eine Anfrage an einen Modell-Provider | Zwischen lokalen und entfernten Provider-Endpoints wählen | [OmniRoute-Setup für Produktion](/de/blog/omniroute-ai-routing-setup/) | | LLM-Gateway | Eine Anfrage durch eine Policy-Schicht | Credentials, Fallbacks, Budgets und Telemetrie bündeln | [LLM-Gateways im Vergleich](/de/blog/llm-gateway-router-comparison-2026/) | 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](https://developer.nvidia.com/blog/nvidia-pair-virtual-inference-router-expands-available-compute-on-your-local-network/) 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](https://docs.nvidia.com/local-ai/nvpair/known-issues/) 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](https://github.com/NVIDIA/Personal-AI-Router/blob/main/services/nvpair-node-info/gpu_linux.go). 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](https://rocm.docs.amd.com/projects/amdsmi/en/latest/how-to/amdsmi-cli-tool.html). 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](https://rocm.docs.amd.com/en/develop/about/release-notes.html) 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](https://docs.ollama.com/gpu) 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? | Situation | Urteil | Warum | | --- | --- | --- | | Mehrere unabhängige Agent-Calls warten auf eine lokale GPU | **Starker Pilot** | Genau diesen Workload soll PAIR verteilen. | | Zwei oder mehr vertrauenswürdige Rechner halten dasselbe Modell | **Guter Fit** | Replikation gibt dem Scheduler echte Auswahl. | | Ein Modell ist für jeden einzelnen Rechner zu groß | **Falsches Werkzeug** | PAIR bündelt keinen Speicher und teilt das Modell nicht. | | Gemischtes NVIDIA-, Apple- und AMD-Homelab | **Experimentell** | Telemetrie, Engine-Support und Performance pro Node validieren. | | Kunden-API mit strikten Verfügbarkeitszielen | **Zuerst beweisen** | PAIR Beta hat kein SLA und nutzt eine eventual-consistent lokale Sicht. | | Nicht vertrauenswürdiges Büro-, Gast- oder geteiltes WLAN | **Nicht unverändert ausrollen** | Node-Telemetrie ist im Subnetz lesbar. | ## 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](/de/blog/local-models-vs-apis-break-even-eu-2026/), 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](/de/case-studies/twinsoft-ai/) zeigt den Weg vom KI-Workflow zum Produktionssystem. Der [Guide zur Technologie-Stack-Entscheidung](/de/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) 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. ## Häufig gestellte Fragen ### Was ist NVIDIA PAIR? NVIDIA Personal AI Router ist ein lokaler Open-Source-Inference-Router. Ollama- und LM-Studio-Clients erhalten einen vertrauten Endpoint. Jede unabhängige Anfrage wird an einen geeigneten Rechner im gekoppelten lokalen Cluster weitergeleitet. ### Kombiniert NVIDIA PAIR mehrere GPUs zu einer? Nein. PAIR bündelt kein VRAM, teilt keine Modell-Layer und zerlegt keine Anfrage. Jede Anfrage läuft vollständig auf einem Node. Mehr Nodes helfen nur bei unabhängigen Anfragen und passenden Modell-Replikaten. ### Wie wählt PAIR einen Node? Der Proxy behält zuerst Nodes mit laufender Engine und angefordertem Modell. Danach nutzt er die Scheduler-Reihenfolge aus wartenden PAIR-Jobs und grobem GPU-Druck. Eine stabile Node-ID löst Gleichstände deterministisch. ### Unterstützt NVIDIA PAIR AMD Strix Halo? AMD Strix Halo gehört nicht zu NVIDIAs validierten Konfigurationen. PAIR kann eine AMD-GPU unter Linux auflisten, laut aktueller Dokumentation fehlen ohne NVIDIA-Treiber aber Speicher- und Auslastungsdaten. Die Engine-Kompatibilität muss separat geprüft werden. ### Macht ROCm 10 Strix Halo automatisch mit PAIR kompatibel? Nein. ROCm 10 verbessert den AMD-Stack, doch PAIR braucht AMD-Telemetrie und korrektes Unified-Memory-Handling. Zusätzlich muss Ollama oder LM Studio den genauen Treiber, das Backend, Modell und den Workload unterstützen. ### Ist PAIR schneller als eine GPU? Ein paralleler Multi-Agent-Workload kann durch verteilte unabhängige Anfragen früher fertig werden. Eine einzelne Anfrage wird nicht beschleunigt. NVIDIAs Fünf-Subagenten-Demo verbesserte sich von 18 Minuten auf 8 Minuten 48 Sekunden, gilt aber nur für diese Konfiguration. ### Kann PAIR Prompts vertraulich halten? PAIR hält lokale Inference im lokalen Netzwerk und nutzt Mutual TLS zwischen gekoppelten Nodes. Betreiber brauchen dennoch ein vertrauenswürdiges Netz, Endpoint-Security, sichere Logs und das Wissen, dass Node-Telemetrie im Subnetz unverschlüsselt und ohne Authentifizierung abrufbar ist. ## Fazit PAIR löst ein reales und immer häufigeres Problem: Agent-Parallelität wächst schneller als die eine lokale GPU, auf die alle zeigen. Das Design ist angenehm fokussiert. Client-Interface behalten, geeignete Nodes entdecken, nach Modell filtern, nach Last ordnen und jeden Job an eine Maschine senden. Dieser Fokus ist zugleich die Grenze. PAIR ist weder geteiltes VRAM noch Model Parallelism oder Enterprise-Scheduler. Die AMD-Lücke zeigt den Wert von Open Source: Die Architektur kann dort erweitert werden, wo die erste validierte Hardware-Matrix endet. Ein sinnvoller Strix-Halo-Beitrag muss mehr tun, als einen Radeon-Namen zu erkennen. Er muss ehrliche Unified-Memory- und Auslastungsdaten liefern, ohne AMD-Tools sicher degradieren und den kompletten Engine-Pfad unter echter Agent-Last beweisen. So wird NVIDIA PAIR etwas weniger NVIDIA, ohne weniger zuverlässig zu werden. ## Das könnte dich auch interessieren.. [**Soll ein Modell mehrere Rechner überspannen?** PAIR routet vollständige Anfragen. Mesh LLM geht einen anderen Weg und verteilt unterstützte Modell-Layer über mehrere Maschinen.](/de/blog/mesh-llm-distributed-inference-multiple-computers/) [**AI Enablement vs allgemeine KI-Beratung** Vergleiche eine messbare Infrastruktur-Implementierung mit Beratung, die vor Production Evidence endet.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen Modellauswahl, Inferenzkosten, lokaler Betrieb, Kompression und Serving-Architektur. [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Tencent Hy4 Preview im Test: Lohnt sich das 1M-Kontextmodell?](/de/blog/tencent-hy4-preview-coding-agent-review/) - [PageLM im Check: Selbst hosten und kommerziell nutzen](/de/blog/pagelm-self-hosted-ai-study-platform/) - [M6 Mac mini vs. M5 Mac Studio für lokale KI: Kaufberatung](/de/blog/mac-mini-m6-vs-mac-studio-m5-local-ai/) - [FreeToken AI im Test: Frontier-MoE auf Consumer-GPUs?](/de/blog/freetoken-ai-inference-engine-review/) - [Darkbloom AI Test: Private Inferenz auf freien Macs](/de/blog/darkbloom-ai-private-inference-mac/) [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 Min Lesezeit · 4. September 2026 Zuletzt geprüft 4. September 2026 [**Weiter**](/de/blog/claude-rotate-multi-account-proxy/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/nvidia-pair-amd-rocm-strix-halo/#webpage", "@type": "WebPage", "dateModified": "2026-09-04", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-04", "url": "https://wavect.io/de/blog/nvidia-pair-amd-rocm-strix-halo/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "NVIDIA Personal AI Router, kurz PAIR, ist ein Apache-2.0-lizenzierter lokaler Inference-Router für unabhängige Anfragen an Ollama und LM Studio. Agenten nutzen einen vertrauten Endpoint. PAIR filtert Nodes nach Engine und vorhandenem Modell und ordnet geeignete Rechner dann anhand wartender Jobs und grobem GPU-Druck. Es bündelt weder VRAM noch teilt es ein Modell oder beschleunigt eine einzelne Anfrage über mehrere GPUs. NVIDIA berichtet für eine Demo mit fünf Subagenten von 18 Minuten auf einem RTX-Spark-Laptop gegenüber 8 Minuten 48 Sekunden auf einem Cluster mit drei Geräten, bezeichnet das Ergebnis aber selbst als konfigurationsspezifisch. AMD Strix Halo ist keine validierte Konfiguration. Unter Linux kann PAIR eine AMD-GPU auflisten, erfasst derzeit aber weder Speicher noch Auslastung. Ein belastbarer ROCm-10-Beitrag braucht daher AMD-SMI-Integration, korrekte Unified-Memory-Semantik, stabile Geräte-IDs, Fallbacks und Tests. Bis zur Upstream-Prüfung und Validierung mit echten Agent-Workloads bleibt der Beitrag experimentell.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur NVIDIA PAIR im Test: Lokales KI-Routing und die AMD-ROCm-Lücke TL;DR NVIDIA Personal AI Router, kurz PAIR, ist ein Apache-2.0-lizenzierter lokaler Inference-Router für unabhängige Anfragen an Ollama und LM Studio. Agenten nutzen einen vertrauten Endpoint. PAIR filtert Nodes nach Engine und vorhandenem Modell und ordnet geeignete Rechner dann anhand wartender Jobs und grobem GPU-Druck. Es bündelt weder VRAM noch teilt es ein Modell oder beschleunigt eine einzelne Anfrage über mehrere GPUs. NVIDIA berichtet für eine Demo mit fünf Subagenten von 18 Minuten auf einem RTX-Spark-Laptop gegenüber 8 Minuten 48 Sekunden auf einem Cluster mit drei Geräten, bezeichnet das Ergebnis aber selbst als konfigurationsspezifisch. AMD Strix Halo ist keine validierte Konfiguration. Unter Linux kann PAIR eine AMD-GPU auflisten, erfasst derzeit aber weder Speicher noch Auslastung. Ein belastbarer ROCm-10-Beitrag braucht daher AMD-SMI-Integration, korrekte Unified-Memory-Semantik, stabile Geräte-IDs, Fallbacks und Tests. Bis zur Upstream-Prüfung und Validierung mit echten Agent-Workloads bleibt der Beitrag experimentell. 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. NVIDIA PAIR für eine technische Kaufentscheidung FrageAktuelle AntwortGeschäftliche Bedeutung Was ist PAIR?Ein lokaler Inference-Router unter Apache 2.0Routing-Layer prüfen, anpassen und selbst betreiben, ohne den Agent-Harness umzubauen. Welche Engines?Ollama und LM StudioEngine- und Modell-Kompatibilität bleibt Sache jedes Nodes. Was wird verteilt?Unabhängige, vollständige AnfragenMehr parallele Jobs nutzen mehr Maschinen. Ein einzelner Job wird nicht automatisch schneller. Was entscheidet die Platzierung?Node-Bereitschaft, Engine, Modell, wartende Jobs und grober GPU-DruckGut für elastische lokale Kapazität, kein vollständiger Kosten- oder Latenzoptimierer. Welche Hardware ist validiert?RTX 20 Series und neuer, RTX PRO, DGX Spark und Apple M4+AMD-Nodes brauchen eigene Validierung, selbst wenn PAIR und Engine starten. Wie sind Peer-Anfragen geschützt?Gepinnte Zertifikate und Mutual TLSInference bleibt im lokalen Netzwerk, doch das Netzwerk gehört zum Threat Model. 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: Die Anwendung ruft den lokalen PAIR-Proxy auf, meist über den bereits erwarteten Port. Der Proxy liest Engine und angefordertes Modell aus. Nodes ohne laufende Engine oder exaktes Modell scheiden aus. Die übrigen Nodes werden anhand des Scheduler-Zustands geordnet. 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "Open-Source-Repository von NVIDIA PAIR", "url": "https://github.com/NVIDIA/Personal-AI-Router" }, { "@type": "WebPage", "name": "offizielle PAIR-Architekturdokumentation", "url": "https://docs.nvidia.com/local-ai/nvpair/architecture/" }, { "@type": "WebPage", "name": "PAIR-Launch-Demonstration", "url": "https://developer.nvidia.com/blog/nvidia-pair-virtual-inference-router-expands-available-compute-on-your-local-network/" }, { "@type": "WebPage", "name": "Seite mit bekannten PAIR-Problemen", "url": "https://docs.nvidia.com/local-ai/nvpair/known-issues/" }, { "@type": "WebPage", "name": "Linux-GPU-Detektor ruft zuerst nvidia-smi auf", "url": "https://github.com/NVIDIA/Personal-AI-Router/blob/main/services/nvpair-node-info/gpu_linux.go" }, { "@type": "WebPage", "name": "AMD-SMI-CLI bietet JSON-Ausgabe, UUIDs, BDF-Adressen, GFX-Auslastung und Speicherwerte", "url": "https://rocm.docs.amd.com/projects/amdsmi/en/latest/how-to/amdsmi-cli-tool.html" }, { "@type": "WebPage", "name": "Release Notes zu ROCm 10.0.0", "url": "https://rocm.docs.amd.com/en/develop/about/release-notes.html" }, { "@type": "WebPage", "name": "Ollama-Seite zum GPU-Support", "url": "https://docs.ollama.com/gpu" } ], "dateModified": "2026-09-04", "datePublished": "2026-09-04", "description": "NVIDIA Personal AI Router, kurz PAIR, ist ein Apache-2.0-lizenzierter lokaler Inference-Router für unabhängige Anfragen an Ollama und LM Studio. Agenten nutzen einen vertrauten Endpoint. PAIR filtert Nodes nach Engine und vorhandenem Modell und ordnet geeignete Rechner dann anhand wartender Jobs und grobem GPU-Druck. Es bündelt weder VRAM noch teilt es ein Modell oder beschleunigt eine einzelne Anfrage über mehrere GPUs. NVIDIA berichtet für eine Demo mit fünf Subagenten von 18 Minuten auf einem RTX-Spark-Laptop gegenüber 8 Minuten 48 Sekunden auf einem Cluster mit drei Geräten, bezeichnet das Ergebnis aber selbst als konfigurationsspezifisch. AMD Strix Halo ist keine validierte Konfiguration. Unter Linux kann PAIR eine AMD-GPU auflisten, erfasst derzeit aber weder Speicher noch Auslastung. Ein belastbarer ROCm-10-Beitrag braucht daher AMD-SMI-Integration, korrekte Unified-Memory-Semantik, stabile Geräte-IDs, Fallbacks und Tests. Bis zur Upstream-Prüfung und Validierung mit echten Agent-Workloads bleibt der Beitrag experimentell.", "headline": "NVIDIA PAIR im Test: Lokales KI-Routing und die AMD-Lücke", "image": "https://wavect.io/img/blog/headers/header_nvidia-pair-amd-rocm-strix-halo.svg", "inLanguage": "de", "keywords": "KI-Agenten, Lokale KI, GPU-Infrastruktur, Open Source", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/nvidia-pair-amd-rocm-strix-halo/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/nvidia-pair-amd-rocm-strix-halo/", "wordCount": 2399 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/nvidia-pair-amd-rocm-strix-halo/", "name": "NVIDIA PAIR Test: AMD ROCm und Strix Halo", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "NVIDIA Personal AI Router ist ein lokaler Open-Source-Inference-Router. Ollama- und LM-Studio-Clients erhalten einen vertrauten Endpoint. Jede unabhängige Anfrage wird an einen geeigneten Rechner im gekoppelten lokalen Cluster weitergeleitet." }, "name": "Was ist NVIDIA PAIR?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. PAIR bündelt kein VRAM, teilt keine Modell-Layer und zerlegt keine Anfrage. Jede Anfrage läuft vollständig auf einem Node. Mehr Nodes helfen nur bei unabhängigen Anfragen und passenden Modell-Replikaten." }, "name": "Kombiniert NVIDIA PAIR mehrere GPUs zu einer?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Der Proxy behält zuerst Nodes mit laufender Engine und angefordertem Modell. Danach nutzt er die Scheduler-Reihenfolge aus wartenden PAIR-Jobs und grobem GPU-Druck. Eine stabile Node-ID löst Gleichstände deterministisch." }, "name": "Wie wählt PAIR einen Node?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "AMD Strix Halo gehört nicht zu NVIDIAs validierten Konfigurationen. PAIR kann eine AMD-GPU unter Linux auflisten, laut aktueller Dokumentation fehlen ohne NVIDIA-Treiber aber Speicher- und Auslastungsdaten. Die Engine-Kompatibilität muss separat geprüft werden." }, "name": "Unterstützt NVIDIA PAIR AMD Strix Halo?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. ROCm 10 verbessert den AMD-Stack, doch PAIR braucht AMD-Telemetrie und korrektes Unified-Memory-Handling. Zusätzlich muss Ollama oder LM Studio den genauen Treiber, das Backend, Modell und den Workload unterstützen." }, "name": "Macht ROCm 10 Strix Halo automatisch mit PAIR kompatibel?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ein paralleler Multi-Agent-Workload kann durch verteilte unabhängige Anfragen früher fertig werden. Eine einzelne Anfrage wird nicht beschleunigt. NVIDIAs Fünf-Subagenten-Demo verbesserte sich von 18 Minuten auf 8 Minuten 48 Sekunden, gilt aber nur für diese Konfiguration." }, "name": "Ist PAIR schneller als eine GPU?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "PAIR hält lokale Inference im lokalen Netzwerk und nutzt Mutual TLS zwischen gekoppelten Nodes. Betreiber brauchen dennoch ein vertrauenswürdiges Netz, Endpoint-Security, sichere Logs und das Wissen, dass Node-Telemetrie im Subnetz unverschlüsselt und ohne Authentifizierung abrufbar ist." }, "name": "Kann PAIR Prompts vertraulich halten?" } ] } ```