Lokale KI-NUMA-Lokalität: Warum die Speicherplatzierung die Datenzufuhrrate des Beschleunigers verändert

Die NUMA-Lokalität verändert die Zufuhrrate zum Beschleuniger, da Host-Vorverarbeitung und Transfers schneller sind, wenn CPU-Threads, Speicherseiten und das Gerät einen nahegelegenen Pfad gemeinsam nutzen.

In einer Home-Workstation mit mehreren Sockeln kann jeder CPU-Kern auf den gesamten Arbeitsspeicher zugreifen, aber die Zugriffskosten sind nicht überall gleich. Eine GPU oder ein anderer Beschleuniger ist normalerweise über den PCIe-Root-Komplex eines Sockels angebunden. Wenn die Vorverarbeitung auf einem anderen Knoten läuft und Puffer dort zugewiesen werden, müssen die Daten möglicherweise die Sockelverbindung passieren, bevor sie das Gerät erreichen, was zusätzliche Auslastung und variable Latenzen verursacht.

NUMA macht die Entfernung zum Host-Speicher messbar

Ein NUMA-System teilt CPUs und Speicher in Knoten mit unterschiedlichen Zugriffsabständen auf. Linux weist eine Speicherseite üblicherweise dem Knoten zu, der dem CPU-Kern lokal ist, der den ersten Seitenfehler auslöst. Die Platzierung von Threads beim Laden des Modells oder bei der Vorbereitung von Eingaben kann daher bestimmen, wo große Puffer physisch liegen.

Die Dokumentation zu NUMA-Speicherrichtlinien von Linux beschreibt Richtlinien für Tasks, VMAs, gemeinsam genutzten Speicher, Bindung, Bevorzugung und Interleaving. Sie weist außerdem darauf hin, dass Richtlinien hauptsächlich Seiten beeinflussen, die nach ihrer Aktivierung zugewiesen werden, wodurch die Initialisierungsreihenfolge wichtig wird. Diese Unterscheidung bleibt auch unter realistischen Bedingungen im Haushalt relevant.

Bei lokaler Inferenz kann der kritische Pfad Tokenisierung, Bilddekodierung, Tensorvorbereitung, angeheftete Puffer und Gerätetransfers umfassen. Eine entfernte Platzierung erzeugt einen Engpass auf der Host-Seite, selbst wenn der Beschleuniger selbst noch freie Rechenkapazität meldet. Der Zwischenzustand sollte bei späteren Diagnosen und Überprüfungen weiterhin sichtbar bleiben.

Die PCIe-Topologie verbindet einen Beschleuniger mit bestimmten CPU-Knoten

Der kürzeste Pfad zwischen Host und Gerät führt normalerweise über den CPU-Sockel, dessen Root-Komplex den Beschleuniger verwaltet. Wenn die CPU-Threads des Workers und die Speicherzuweisungsrichtlinie an diese Umgebung gebunden werden, kann dies die Bandbreite verbessern und Schwankungen reduzieren, insbesondere wenn große Eingaben oder häufige Transfers die Verbindung stark auslasten.

Die CUDA-NUMA-Anleitung von NVIDIA enthält NUMA-Empfehlungen und warnt, dass eine automatische Lastverteilung GPU-Anwendungen in manchen Fällen beeinträchtigen kann. Sie empfiehlt, die Topologie zu untersuchen und die Richtlinie für den tatsächlichen Knoten anzupassen, statt Knoten­nummern einfach vorauszusetzen.

Die Platzierung ist ein Graphproblem und keine Regel, nach der Knoten null am schnellsten ist. Die richtige Zuordnung hängt von der Verdrahtung des Mainboards, der IOMMU-Konfiguration, anderen Geräten sowie davon ab, ob mehrere Worker um dieselben Speicherkanäle oder PCIe-Verbindungen konkurrieren.

Eine Bindung kann schaden, wenn die Arbeitslast mehr als einen Knoten nutzt

Eine strikte Bindung des Speichers an einen einzigen Knoten kann dessen Bandbreite oder Kapazität erschöpfen, während andere Knoten ungenutzt bleiben. Eine Pipeline kann eine GPU nahe einem Sockel nutzen, aber auch eine Capture-Karte, ein NVMe-Gerät oder einen zweiten Beschleuniger nahe einem anderen Sockel. Eine Platzierung kann Transfers optimieren und zugleich die Vorverarbeitung oder den Speicherzugriff verlangsamen.

Das GPU-Affinitätsprojekt von NVIDIA ordnet Prozesse den mit GPUs verbundenen CPU-Kernen zu und weist darauf hin, dass die richtige Affinität die Leistung stabilisieren kann. Seine verschiedenen Modi zeigen, warum eindeutige, zusammenhängende, sockelbezogene und NUMA-Bereiche für unterschiedliche Workloads mit mehreren Prozessen geeignet sind.

Die Fehlergrenze liegt darin, einen Benchmark für ein einzelnes Gerät auf den gesamten Server zu übertragen. Binden Sie integrierte Speichersysteme, Systeme mit nur einem Knoten oder Pipelines über mehrere Geräte nicht blind; messen Sie End-to-End-Latenz, Bandbreite und Konkurrenzsituationen unter der vorgesehenen Parallelität.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Benchmarken Sie die Topologie, nicht nur den Beschleuniger

Erfassen Sie CPU-Knoten, Speicherkapazität, PCIe-Geräte und die Lokalität des Beschleunigers. Führen Sie dieselbe Inferenz-Workload mit der Standardplatzierung, einer Bindung nur der CPU, einer Bindung nur des Speichers und einer abgestimmten Bindung von CPU und Speicher aus. Protokollieren Sie die Host-zu-Gerät-Bandbreite, die Seitenplatzierung, die Token pro Sekunde und die p95-Latenz.

Wenn Modell-Shards aus Netzwerkspeicher geladen werden, wie bei vernetztem Modellspeicher, trennen Sie die Dateilesezeit von Seitenplatzierung und Gerätetransfer. Erwärmen Sie für jeden Durchlauf dieselben Daten und wiederholen Sie den Test anschließend mit den vorgesehenen gleichzeitig arbeitenden Workern, um eine Konkurrenz um Speicherkanäle sichtbar zu machen.

Übernehmen Sie eine Bindung nur, wenn die abgestimmte Topologie wiederholbare End-to-End-Ergebnisse verbessert, ohne einen anderen Dienst auszubremsen. Wenn die Gewinne nach dem Aufwärmen verschwinden oder sich bei Parallelität umkehren, lassen Sie die Platzierung flexibel oder isolieren Sie nur die für Transfers kritischen Threads und Puffer.