Quatre modes de défaillance spécifiques à aarch64 lors de l'exécution de vLLM sur Blackwell GB10 avec CUDA 13.0

Configuration et environnement

La configuration utilise du matériel GB10 avec aarch64 (sbsa-linux), Python 3.12, CUDA 13.0 et vLLM v0.7.1. Les problèmes sont apparus dans un environnement de test réinitialisé quotidiennement et sont spécifiques à aarch64 avec CUDA 13.0.

Mode de défaillance 1 : la roue cu121 n'existe pas pour aarch64

L'utilisation du protocole --index-url .../cu121 renvoie : ERROR: Could not find a version that satisfies the requirement torch (from versions: none). L'index cu121 ne contient pas de binaire aarch64. L'index correct pour Blackwell aarch64 est cu130.

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

Mode de défaillance 2 : symbole non défini ncclWaitSignal

Après l'installation de torch cu130, l'importation échoue avec : ImportError: libtorch_cuda.so: undefined symbol: ncclWaitSignal. Le NCCL installé via apt ne possède pas ce symbole, mais nvidia-nccl-cu13 installé via pip l'a. L'éditeur de liens ne le trouve pas automatiquement.

Solution : le forcer via LD_PRELOAD avant chaque appel Python :

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

Mode de défaillance 3 : numa.h introuvable lors de la compilation de l'extension CPU de vLLM

L'erreur : fatal error: numa.h: No such file or directory. L'extension CPU de vLLM nécessite libnuma-dev, qui n'était pas installé sur le système réinitialisé.

sudo apt-get install -y libnuma-dev

Mode de défaillance 4 : Incompatibilité ABI — symbole non défini MessageLogger

Après avoir terminé la compilation complète, le lancement de vLLM échoue avec : ImportError: vllm/_C.abi3.so: undefined symbol: _ZN3c1013MessageLoggerC1EPKciib.

Diagnostic avec nm montre :

• Ce que le binaire vLLM attendait (ancienne signature) : U _ZN3c1013MessageLoggerC1EPKciib ← (const char*, int, int, bool)
• Ce que la bibliothèque torch cu130 fournit réellement (nouvelle signature) : T _ZN3c1013MessageLoggerC1ENS_14SourceLocationEib ← (SourceLocation, int, bool)

Cause racine : l'isolation de compilation de pip. Lors de l'exécution de pip install -e ., pip crée un environnement de compilation isolé et télécharge une version plus ancienne de torch basée sur les contraintes de version de pyproject.toml. vLLM se compile contre ces anciens en-têtes, mais au moment de l'exécution, la version plus récente de torch cu130 est trouvée, provoquant une incompatibilité de signature.

Solution : Utiliser --no-build-isolation avec injection explicite de sous-processus :

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

Détail important : sudo -E seul ne fonctionne pas car la chaîne de sous-processus de pip ne transmet pas LD_PRELOAD. Vous devez utiliser sudo -E env VAR=value pip3 pour l'injecter explicitement dans le sous-processus.

Vérifiez la compatibilité ABI après l'installation :

nm -D vllm/_C.abi3.so | grep MessageLogger
# Doit contenir "SourceLocation" — si c'est toujours "EPKciib", réinstallez

Note supplémentaire pour les systèmes multi-agents

Si vous utilisez vLLM comme backend pour un système multi-agents, ajoutez --served-model-name your-model-name. Sans cela, vLLM sert le modèle sous son chemin de fichier complet et les agents obtiennent une erreur 404 lorsqu'ils interrogent par nom.

Le protocole complet v2, incluant le script d'automatisation et le service systemd, est disponible sur github.com/trgysvc/AutonomousNativeForge → docs/BLACKWELL_SETUP_V2.md. Le dépôt est pour ANF — un pipeline de codage autonome à 4 agents fonctionnant sur cette configuration, mais la documentation de configuration est autonome si vous avez juste besoin des correctifs Blackwell/vLLM.