Quatro modos de falha específicos do aarch64 ao executar o vLLM no Blackwell GB10 com CUDA 13.0

Configuração e ambiente

A configuração utiliza hardware GB10 com aarch64 (sbsa-linux), Python 3.12, CUDA 13.0 e vLLM v0.7.1. Os problemas surgiram em um ambiente de teste com reset diário e são específicos para aarch64 com CUDA 13.0.

Modo de falha 1: wheel cu121 não existe para aarch64

Usar o protocolo --index-url .../cu121 retorna: ERROR: Could not find a version that satisfies the requirement torch (from versions: none). O índice cu121 não possui binário para aarch64. O índice correto para Blackwell aarch64 é cu130.

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

Modo de falha 2: símbolo indefinido ncclWaitSignal

Após instalar o torch cu130, a importação falha com: ImportError: libtorch_cuda.so: undefined symbol: ncclWaitSignal. O NCCL instalado via apt não possui este símbolo, mas o nvidia-nccl-cu13 instalado via pip possui. O vinculador não o encontra automaticamente.

Solução: Forçar via LD_PRELOAD antes de cada chamada Python:

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

Modo de falha 3: numa.h não encontrado durante compilação da extensão CPU do vLLM

O erro: fatal error: numa.h: No such file or directory. A extensão CPU do vLLM requer libnuma-dev, que não estava instalado no sistema após o reset.

sudo apt-get install -y libnuma-dev

Modo de falha 4: Incompatibilidade de ABI — símbolo indefinido MessageLogger

Após completar a compilação completa, iniciar o vLLM falha com: ImportError: vllm/_C.abi3.so: undefined symbol: _ZN3c1013MessageLoggerC1EPKciib.

Diagnóstico com nm mostra:

• O que o binário do vLLM esperava (assinatura antiga): U _ZN3c1013MessageLoggerC1EPKciib ← (const char*, int, int, bool)
• O que a biblioteca torch cu130 realmente fornece (nova assinatura): T _ZN3c1013MessageLoggerC1ENS_14SourceLocationEib ← (SourceLocation, int, bool)

Causa raiz: isolamento de compilação do pip. Ao executar pip install -e ., o pip cria um ambiente de compilação isolado e baixa uma versão mais antiga do torch baseada nas restrições de versão do pyproject.toml. O vLLM compila contra esses cabeçalhos antigos, mas em tempo de execução o torch cu130 mais novo é encontrado, causando incompatibilidade de assinatura.

Solução: Usar --no-build-isolation com injeção explícita de subprocesso:

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

Detalhe importante: sudo -E sozinho não funciona porque a cadeia de subprocessos do pip não carrega LD_PRELOAD. É necessário sudo -E env VAR=value pip3 para injetar explicitamente no subprocesso.

Verifique o selo ABI após a instalação:

nm -D vllm/_C.abi3.so | grep MessageLogger
# Deve conter "SourceLocation" — se ainda disser "EPKciib", reinstale

Nota adicional para sistemas multiagente

Se usar vLLM como backend para um sistema multiagente, adicione --served-model-name seu-nome-de-modelo. Sem isso, o vLLM serve o modelo sob seu caminho completo de arquivo e os agentes recebem 404 quando consultam pelo nome.

O protocolo completo v2, incluindo script de automação e serviço systemd, está disponível em github.com/trgysvc/AutonomousNativeForge → docs/BLACKWELL_SETUP_V2.md. O repositório é para ANF — um pipeline de codificação autônoma com 4 agentes rodando sobre esta configuração, mas a documentação de configuração é independente se você só precisa das correções para Blackwell/vLLM.