Vier aarch64-spezifische Fehlermodi beim Ausführen von vLLM auf Blackwell GB10 mit CUDA 13.0

Einrichtung und Umgebung

Die Einrichtung verwendet GB10-Hardware mit aarch64 (sbsa-linux), Python 3.12, CUDA 13.0 und vLLM v0.7.1. Die Probleme traten in einer täglich zurückgesetzten Testumgebung auf und sind spezifisch für aarch64 mit CUDA 13.0.

Fehlermodus 1: cu121-Wheel existiert nicht für aarch64

Die Verwendung des --index-url .../cu121-Protokolls liefert: ERROR: Could not find a version that satisfies the requirement torch (from versions: none). Der cu121-Index enthält kein aarch64-Binary. Der korrekte Index für Blackwell aarch64 ist cu130.

sudo pip3 install --pre torch torchvision torchaudio \
--index-url https://download.pytorch.org/whl/nightly/cu130 \
--break-system-packages

Fehlermodus 2: ncclWaitSignal undefiniertes Symbol

Nach der Installation von cu130 torch schlägt der Import fehl mit: ImportError: libtorch_cuda.so: undefined symbol: ncclWaitSignal. Das über apt installierte NCCL enthält dieses Symbol nicht, aber das über pip installierte nvidia-nccl-cu13 schon. Der Linker findet es nicht automatisch.

Lösung: Erzwingen Sie es über LD_PRELOAD vor jedem Python-Aufruf:

export LD_PRELOAD=/usr/local/lib/python3.12/dist-packages/nvidia/nccl/lib/libnccl.so.2

Fehlermodus 3: numa.h während des vLLM-CPU-Erweiterungsbuilds nicht gefunden

Der Fehler: fatal error: numa.h: No such file or directory. Die CPU-Erweiterung von vLLM benötigt libnuma-dev, das auf dem zurückgesetzten System nicht installiert war.

sudo apt-get install -y libnuma-dev

Fehlermodus 4: ABI-Inkompatibilität – MessageLogger undefiniertes Symbol

Nach Abschluss des vollständigen Builds schlägt das Starten von vLLM fehl mit: ImportError: vllm/_C.abi3.so: undefined symbol: _ZN3c1013MessageLoggerC1EPKciib.

Diagnose mit nm zeigt:

• Was die vLLM-Binary erwartete (alte Signatur): U _ZN3c1013MessageLoggerC1EPKciib ← (const char*, int, int, bool)
• Was die cu130 torch-Bibliothek tatsächlich bereitstellt (neue Signatur): T _ZN3c1013MessageLoggerC1ENS_14SourceLocationEib ← (SourceLocation, int, bool)

Ursache: Pips Build-Isolation. Bei Ausführung von pip install -e . erstellt pip eine isolierte Build-Umgebung und lädt ein separates, älteres torch basierend auf den pyproject.toml-Versionsbeschränkungen herunter. vLLM kompiliert gegen diese alten Header, aber zur Laufzeit wird das neuere cu130 torch gefunden, was zu einer Signaturinkompatibilität führt.

Lösung: Verwenden Sie --no-build-isolation mit expliziter Subprozess-Injektion:

sudo -E env \
LD_PRELOAD="/usr/local/lib/python3.12/dist-packages/nvidia/nccl/lib/libnccl.so.2" \
LD_LIBRARY_PATH="/usr/local/lib/python3.12/dist-packages/torch/lib:..." \
MAX_JOBS=8 \
pip3 install -e . --no-deps --no-build-isolation --break-system-packages

Wichtiges Detail: sudo -E allein funktioniert nicht, weil die Subprozesskette von pip LD_PRELOAD nicht weitergibt. Sie benötigen sudo -E env VAR=value pip3, um es explizit in den Subprozess zu injizieren.

Überprüfen Sie den ABI-Verschluss nach der Installation:

nm -D vllm/_C.abi3.so | grep MessageLogger
# Muss "SourceLocation" enthalten – wenn es immer noch "EPKciib" sagt, neu installieren

Zusätzlicher Hinweis für Multi-Agenten-Systeme

Wenn Sie vLLM als Backend für ein Multi-Agenten-System verwenden, fügen Sie --served-model-name your-model-name hinzu. Ohne dies dient vLLM das Modell unter seinem vollständigen Dateipfad, und Agenten erhalten 404, wenn sie nach Namen abfragen.

Das vollständige v2-Protokoll, einschließlich Automatisierungsskript und systemd-Dienst, ist verfügbar unter github.com/trgysvc/AutonomousNativeForge → docs/BLACKWELL_SETUP_V2.md. Das Repo ist für ANF – eine 4-Agenten-autonome Codierungspipeline, die auf diesem Setup läuft, aber die Einrichtungsdokumente stehen allein, wenn Sie nur die Blackwell/vLLM-Korrekturen benötigen.