Wie beeinflusst die NUMA-Lokalität die KI-Inferenz mit mehreren GPUs zu Hause?

NUMA-Lokalität beeinflusst die Inferenz, wenn CPU-Threads, Hauptspeicher und GPUs über nichtlokale Domänen hinweg kommunizieren, anstatt in der Nähe ihres PCIe-Pfads zu bleiben.

Ein KI-Heimserver mit zwei Sockeln kann zwei große RAM-Pools und mehrere GPUs als eine Maschine bereitstellen, doch der Zugriff ist nicht gleichmäßig. Ein Worker, der auf einem Sockel eingeplant wurde, kann Tensoren zunächst in Speicher vorbereiten, der am anderen Sockel angeschlossen ist, bevor er sie an eine GPU unter einer anderen PCIe-Root-Anbindung überträgt. Die Auswirkungen hängen von der Modellplatzierung, dem Host-Staging, dem Datenverkehr beim Tensor-Parallelismus, der Interconnect-Topologie, der Batch-Größe und davon ab, ob die Arbeitslast rechen- oder transfergebunden ist.

NUMA macht aus einem Speicherpool einen zugriffsabhängigen Entfernungsraum

In einem NUMA-System verfügt jeder CPU-Sockel oder jede Rechendomäne über Speicher, der einigen Kernen näher ist als anderen. Die Software kann die kombinierte Kapazität adressieren, doch ein Remote-Zugriff muss eine Interconnect-Verbindung überqueren. Dieser Pfad weist normalerweise eine andere Latenz und verfügbare Bandbreite auf als lokaler Speicher.

Die NUMA-Topologie beeinflusst auch GPU-DMA, da sich Host-Speicherseiten weit vom PCIe-Root-Komplex der GPU entfernt befinden können. CPU-Scheduling und Speicherplatzierung sind getrennte Entscheidungen, und eine virtuelle Maschine erkennt möglicherweise nicht automatisch die Host-Topologie, die für ihre Abstimmung erforderlich ist.

Die Auswirkungen sind gering, wenn der Speicherverkehr des Hosts im Vergleich zur GPU-Berechnung unbedeutend ist. Sie nehmen beim Laden von Modellen, beim CPU-Offloading, bei der Tokenisierung, bei Kopien in gepinnte Puffer, bei häufigen Synchronisierungen oder bei Arbeitslasten zu, die den VRAM überschreiten. NUMA-Kapazität garantiert keine NUMA-Lokalität.

Die GPU-Platzierung fügt dem Modellpfad eine zweite Topologie hinzu

Mehrere GPUs können an unterschiedliche CPU-Sockel, PCIe-Switches oder On-Package-Partitionen angeschlossen sein. Ein Tensor, der zwischen zwei Beschleunigern übertragen wird, kann einen direkten Peer-Pfad, eine dedizierte GPU-Verbindung, einen PCIe-Switch oder eine Route verwenden, die den Hauptspeicher und einen Hop zwischen den Sockeln einbezieht. Diese Pfade sind nicht gleichwertig.

Forschungen zu GPUs mit mehreren Partitionen zeigen, dass nicht uniforme Zugriffe und die Kommunikation zwischen Partitionen Contention und Kernel-Latenz verstärken können. Die Platzierungsstrategien unterscheiden sich je nachdem, ob Daten global, teilweise oder nur innerhalb einer einzelnen Workgroup oder Partition gemeinsam genutzt werden.

Die Modellpartitionierung sollte der Topologie folgen, über die der häufigste Datenverkehr läuft. Benachbarte Schichten oder Attention-Zustände, die über eine langsame Grenze hinweg platziert werden, können bei jedem Token kommunizieren, während eine weniger kommunikationsintensive Aufteilung die Entfernung möglicherweise toleriert. Wer nur GPUs zählt, ohne ihre Verbindungen abzubilden, übersieht den entscheidenden Zusammenhang.

First-Touch und Thread-Migration können ein geplantes Layout aufbrechen

Betriebssysteme platzieren Speicher häufig in der Nähe des Threads, der jede Seite zuerst berührt. Wenn die Initialisierung auf einem Sockel läuft und die Inferenz-Worker später auf einem anderen ausgeführt werden, können die Seiten entfernt bleiben. Durch eine Migration des Schedulers können CPU-Vorbereitungsthreads außerdem von dem Speicher und der GPU wegbewegt werden, die sie eigentlich bedienen sollten.

NUMA-Bewusstsein verbindet lokale Speicherbänke mit den CPU-Sockeln, die am effizientesten auf sie zugreifen. CPU-Threads zu binden, ohne die Speicherzuweisung zu kontrollieren, oder Speicher zu binden, ohne die GPU abzustimmen, löst nur einen Teil des Pfads.

Ein stabiles Layout kann CPU-Affinität, Speicherrichtlinien, Gerätezuweisung und einen topologiebewussten Prozessstart erfordern. Container und virtuelle Maschinen fügen eine weitere Zuordnungsebene hinzu. Das Ziel besteht nicht darin, blind alles zu binden, sondern stark frequentierte Produzenten-, Puffer- und Verbraucherpfade innerhalb der nächstgelegenen praktikablen Domäne zu halten.

Lokalität ist in bestimmten Inferenzphasen besonders wichtig

Beim Laden des Modells stehen die Übertragungen vom Speicher zum Host und vom Host zur GPU im Vordergrund. Beim Prefill werden viele Prompt-Tokens verarbeitet, wodurch größere Matrixoperationen genutzt werden können. Beim Decode werden dagegen wiederholt ein oder wenige Tokens verarbeitet, wodurch die Phase empfindlich gegenüber Speicherbandbreite, Synchronisierung und dem Overhead von Kernel-Starts werden kann. Die NUMA-Auswirkungen können sich daher innerhalb einer einzigen Anfrage verändern.

NUMA-Effekte von GPUs zeigen, dass eine platzierungsbewusste Planung Attention verbessern kann, indem Arbeit an Speicherdomänen und die Wiederverwendung von Caches angepasst werden. Die Erkenntnis ist enger gefasst als eine allgemeine Geschwindigkeitssteigerung: Der Vorteil entsteht dort, wo das Sharing-Muster des Kernels zur topologiebewussten Zuordnung passt.

Ein Benchmark, der nur durchschnittliche Tokens pro Sekunde meldet, kann eine hohe Latenz bis zum ersten Token oder eine schlechte Skalierung bei einer bestimmten Batch-Größe verbergen. Erfasse Ladezeit, Prefill-Durchsatz, Inter-Token-Latenz, Datenverkehr über GPU-Verbindungen, entfernte NUMA-Zugriffe und CPU-Speicherbandbreite getrennt.