Un desarrollador ha identificado y solucionado un problema grave que afecta a los usuarios que trabajan con múltiples GPU Intel Arc en inferencia de modelos de lenguaje local. El fallo provocaba que el consumo de memoria RAM del sistema se disparase hasta el 100%, causando bloqueos del sistema y fallos de memoria incluso cuando los modelos cabían completamente en la memoria de vídeo disponible.
El problema se manifestaba de manera particular en configuraciones con dos Intel Arc Pro B70 (32 GB de VRAM cada una, 64 GB en total), donde un modelo de 15 GB causaba un consumo de 46 GB de RAM del sistema. Los procesos de escritorio se cerraban automáticamente, el sistema se hacía irresponsable o devolvía al usuario a la pantalla de inicio de sesión.
La raíz del problema residía en la forma en que el backend SYCL de llama.cpp, el popular software para ejecutar modelos de lenguaje en local, asignaba memoria en las GPU Intel. Cada llamada a la función sycl::malloc_device() provocaba que el controlador xe de Intel creara un espejo 1:1 de la asignación de GPU en la RAM del sistema a través del mecanismo DMA-buf/TTM. Esto ocurría durante la asignación de memoria, no durante la inferencia misma.
Las pruebas revelaron una diferencia dramática: mientras que sycl::malloc_device() con 4 GB de VRAM consumía 4.112 MB adicionales de RAM del sistema, la alternativa zeMemAllocDevice() de Level Zero solo consumía 8 MB. Una diferencia de 500 veces en el impacto en memoria del sistema para la misma asignación en la misma GPU y controlador.
El controlador xe de Intel posee dos rutas internas diferentes en el kernel para la memoria de dispositivo. La primera, DMA-buf/TTM, refleja la VRAM en la RAM del sistema, y es la que dispara sycl::malloc_device(). La segunda, SVM/P2P, proporciona acceso directo PCIe BAR con consumo mínimo de RAM del sistema, que es la que utiliza zeMemAllocDevice() de Level Zero.
La solución consistió en reemplazar sycl::malloc_device() con zeMemAllocDevice() en todo el backend SYCL de llama.cpp. El desarrollador implementó funciones auxiliares centralizadas con respaldo automático a la función original en caso de que la interoperabilidad de Level Zero no estuviera disponible. El parche toca únicamente cuatro archivos, reemplaza tres sitios de asignación y tres de liberación de memoria, y se enlaza contra ze_loader.
Los resultados fueron espectaculares. Con un modelo Q4_K_M de 15,6 GB y 48 K contexto en configuración de GPU dual, el consumo máximo de RAM del sistema bajó de 60 GB (al 100%, causando bloqueos) a 6,7 GB (al 10%, completamente estable). En el caso de un modelo Q8_0 de 26,6 GB con 32 K contexto, el consumo permaneció plano alrededor del 10% durante todas las pruebas de GPU dual, sin bloqueos ni fallos.
El rendimiento no se vio afectado negativamente. Las velocidades de procesamiento de tokens se mantuvieron o mejoraron ligeramente. La salida fue idéntica byte por byte entre configuraciones de GPU única y dual cuando se usaba la misma semilla aleatoria.
El descubrimiento pone de manifiesto una diferencia fundamental en cómo los controladores de GPU manejan la memoria. Mientras que CUDA (Nvidia) y ROCm (AMD) tienen su propia gestión de memoria punto a punto que no pasa por la ruta genérica DMA-buf del kernel, Intel posee una ruta SVM/P2P funcional en kernel 7.0 en adelante, pero sycl::malloc_device() dispara la ruta DMA-buf más antigua en lugar de utilizarla.
Este problema afectaba especialmente a usuarios en Linux que experimentaban lo que parecía ser una limitación fundamental de las GPU Arc para inferencia local. La solución demuestra que no se trataba de un problema de hardware o limitación de arquitectura, sino de una decisión de implementación del software que podía ser revertida.
El hallazgo cobra relevancia en el contexto actual de adopción de Intel Arc como alternativa de bajo coste a las GPU de Nvidia y AMD para aplicaciones de IA local. Muchos usuarios abandonaron las GPU Arc tras experimentar este comportamiento, cuando en realidad una actualización del software habría resuelto completamente el problema.
