Cuatro modos de fallo específicos de aarch64 al ejecutar vLLM en Blackwell GB10 con CUDA 13.0

Configuración y entorno

La configuración utiliza hardware GB10 con aarch64 (sbsa-linux), Python 3.12, CUDA 13.0 y vLLM v0.7.1. Los problemas surgieron en un entorno de prueba con reinicio diario y son específicos de aarch64 con CUDA 13.0.

Modo de fallo 1: No existe la rueda cu121 para aarch64

Usar el protocolo --index-url .../cu121 devuelve: ERROR: Could not find a version that satisfies the requirement torch (from versions: none). El índice cu121 no tiene binario para aarch64. El índice correcto para Blackwell aarch64 es cu130.

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

Modo de fallo 2: Símbolo indefinido ncclWaitSignal

Después de instalar torch cu130, la importación falla con: ImportError: libtorch_cuda.so: undefined symbol: ncclWaitSignal. El NCCL instalado con apt no tiene este símbolo, pero nvidia-nccl-cu13 instalado con pip sí lo tiene. El enlazador no lo encuentra automáticamente.

Solución: Forzarlo mediante LD_PRELOAD antes de cada llamada a Python:

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

Modo de fallo 3: No se encuentra numa.h durante la compilación de la extensión CPU de vLLM

El error: fatal error: numa.h: No such file or directory. La extensión CPU de vLLM requiere libnuma-dev, que no estaba instalado en el sistema reiniciado.

sudo apt-get install -y libnuma-dev

Modo de fallo 4: Incompatibilidad de ABI — Símbolo indefinido MessageLogger

Después de completar la compilación completa, iniciar vLLM falla con: ImportError: vllm/_C.abi3.so: undefined symbol: _ZN3c1013MessageLoggerC1EPKciib.

Diagnóstico con nm muestra:

• Lo que el binario de vLLM esperaba (firma antigua): U _ZN3c1013MessageLoggerC1EPKciib ← (const char*, int, int, bool)
• Lo que la biblioteca torch cu130 realmente proporciona (nueva firma): T _ZN3c1013MessageLoggerC1ENS_14SourceLocationEib ← (SourceLocation, int, bool)

Causa raíz: Aislamiento de compilación de pip. Al ejecutar pip install -e ., pip crea un entorno de compilación aislado y descarga una versión más antigua de torch basada en las restricciones de versión de pyproject.toml. vLLM se compila contra esos encabezados antiguos, pero en tiempo de ejecución se encuentra el torch cu130 más nuevo, causando incompatibilidad de firmas.

Solución: Usar --no-build-isolation con inyección explícita de subproceso:

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

Detalle importante: sudo -E solo no funciona porque la cadena de subprocesos de pip no lleva LD_PRELOAD. Necesitas sudo -E env VAR=value pip3 para inyectarlo explícitamente en el subproceso.

Verificar el sello ABI después de la instalación:

nm -D vllm/_C.abi3.so | grep MessageLogger
# Debe contener "SourceLocation" — si todavía dice "EPKciib", reinstalar

Nota adicional para sistemas multiagente

Si usas vLLM como backend para un sistema multiagente, agrega --served-model-name tu-nombre-de-modelo. Sin esto, vLLM sirve el modelo bajo su ruta de archivo completa y los agentes obtienen 404 cuando consultan por nombre.

El protocolo completo v2, incluyendo script de automatización y servicio systemd, está disponible en github.com/trgysvc/AutonomousNativeForge → docs/BLACKWELL_SETUP_V2.md. El repositorio es para ANF — una canalización de codificación autónoma de 4 agentes que se ejecuta sobre esta configuración, pero la documentación de configuración es independiente si solo necesitas las correcciones para Blackwell/vLLM.