Ejecutar dos modelos de lenguaje grandes de forma coresidente en una sola GPU exige un cálculo de memoria preciso, algo que el parámetro gpu_memory_utilization de vLLM no resuelve por sí solo. Este artículo recoge la experiencia práctica de desplegar Qwen3-Next-80B-Instruct-FP8 y Qwen3-4B-Instruct-2507 en un DGX Spark con 119,67 GiB de memoria unificada GB10, usando vLLM detrás de un proxy LiteLLM.
El autor describe tres iteraciones necesarias hasta alcanzar una configuración estable. El primer intento falló porque gpu_memory_utilization se calcula sobre la memoria total de la GPU, no sobre la libre: con dos procesos vLLM es imprescindible que la suma de sus fracciones no supere 0,95 para dejar margen al overhead de CUDA. El segundo tropiezo vino del modelo: Qwen3-Next-80B-Thinking solo opera en modo razonamiento, por lo que con tool_choice: "auto" nunca emite llamadas a herramientas; la solución fue sustituir el backbone Thinking por la versión Instruct. El tercer problema apareció al ampliar el contexto a 64k: la residentcia real del 80B a 0,85 consumía 101,5 GiB y no dejaba sitio al 4B, lo que obligó a reajustar las cuotas a 0,80 y 0,10 respectivamente.
La conclusión operativa es clara: hay que cargar primero el modelo más pesado, medir su residentcia real con nvidia-smi y dimensionar el segundo modelo contra el espacio libre menos 5 GiB de overhead. La residentcia real puede diferir hasta en 8 GiB del valor planificado, y en arquitecturas Mamba como Qwen3-Next la demanda de caché KV no escala linealmente con la longitud de contexto, sino con el alineamiento de páginas Mamba.