Configuración y Pruebas de vLLM en Servidor con 10x NVIDIA V100 y 320GB de VRAM

Configuración de Hardware y Notas de Construcción
Un desarrollador ha construido un servidor de IA local con 10 GPUs Tesla V100 SXM2 de 32GB (320GB de VRAM total) en un sistema AMD Threadripper PRO. La configuración utiliza Ubuntu 24.04 sin interfaz gráfica con controlador NVIDIA 580.126.20. La topología de GPU consiste en dos mallas cuadradas NVLink (GPUs 0-3, 4/5/8/9) más un par NV6 (GPUs 6-7).
Lo que Funciona en V100 con vLLM
- FP16 sin cuantizar: Ruta principal usando
--dtype half - bitsandbytes de 4 bits: Funciona para modelos demasiado grandes para FP16
- TRITON_ATTN: Retroceso automático ya que FlashAttention2 requiere SM 80+
- Paralelismo de Tensor/Pipeline: TP=4 y TP=4 PP=2 ambos probados exitosamente
Lo que No Funciona en V100
- GPTQ: Kernels ExLlamaV2 rotos en SM 7.0 (problema vLLM #2165)
- AWQ: Requiere SM 75+
- FP8: Requiere SM 75+. MiniMax M2.5 usa FP8 internamente — sin posibilidades desde el inicio.
- FlashAttention2: Requiere SM 80+
- DeepSeek MLA: Solo para Hopper/Blackwell. DeepSeek V3/R1 completo no puede ejecutarse en vLLM + V100.
Requisitos de Construcción y Correcciones Críticas
PyTorch 2.11.0+cu126 es requerido — cu126 es la última versión con soporte para V100 ya que cu128+ elimina Volta. La compilación desde fuente requiere TORCH_CUDA_ARCH_LIST="7.0" y MAX_JOBS=20. Se necesita un parche de kernel MoE para el problema #36008, cambiando B.size(1) a B.size(0) en fused_moe.py (2 líneas). PYTHONNOUSERSITE=1 es requerido para aislar el entorno conda de paquetes del sistema obsoletos.
Corrección Crítica de Dependencia NCCL: pip install -e . trae nvidia-nccl-cu13 junto con nvidia-nccl-cu12. La biblioteca cu13 se carga en tiempo de ejecución y hace referencia a símbolos CUDA 13 que no existen en el entorno de ejecución cu126, resultando en "error NCCL: error de cuda no manejado" en cada lanzamiento multi-GPU. La solución implica desinstalar todos los paquetes nvidia-* y gestionar las dependencias cuidadosamente.
📖 Leer la fuente completa: r/LocalLLaMA
👀 Ver también

Los modelos Qwen3.x fallan silenciosamente en OpenClaw debido a una incompatibilidad en el formato de salida en flujo continuo.
Los modelos Qwen3.x en modo de transmisión envían su salida al campo 'reasoning' en lugar de 'content', lo que hace que OpenClaw pase silenciosamente a los modelos de respaldo. Un proxy que traduce los formatos de API e inyecta 'think: false' soluciona el problema, permitiendo la evaluación completa de llamadas a herramientas.

Configuración de Instancia Canary para Actualizaciones Seguras de OpenClaw
Un usuario de Reddit comparte una metodología detallada de canary para probar actualizaciones de OpenClaw antes de producción: raíz de configuración aislada, puerto separado, matriz de pruebas de humo y un formato de informe de actualización estructurado.

Correcciones de Qwen 3.5 en la Llamada de Herramientas para Uso Agéntico: Estado del Servidor y Soluciones en el Lado del Cliente
Un análisis detallado identifica cuatro errores que rompen la llamada a herramientas de Qwen 3.5 en configuraciones agenticas, rastrea las correcciones del servidor hasta abril de 2026 y proporciona una función de Python del lado del cliente para analizar las llamadas a herramientas XML cuando los servidores fallan.

Solucionando el Inflado de Indicaciones y los Bucles Lentos de Respuesta en OpenClaw
Usuarios que experimentan demoras prolongadas desde 2026.4.26 pueden recuperar rendimiento reduciendo la hinchazón del contexto: recortar archivos siempre inyectados, limitar habilidades visibles y evitar pegar grandes salidas de herramientas en el chat principal.