El throttling de la GPU en Linux limita la velocidad de los LLM locales en portátiles RTX Spark

Los desarrolladores que intentan ejecutar Linux nativo en los nuevos portátiles Nvidia RTX Spark se enfrentan a un cuello de botella crítico de rendimiento que reduce drásticamente las velocidades de inferencia de IA. Una revisión técnica reciente del MSI Prestige N16 Flip AI Plus revela que, aunque el sistema operativo se instala correctamente, las velocidades del reloj de la GPU colapsan cuando el dispositivo está conectado a la fuente de alimentación. Esta limitación específica del hardware hace actualmente que el Subsistema de Windows para Linux (WSL) sea la única opción viable para el entrenamiento y la inferencia local de modelos de alto rendimiento en estas máquinas.

Qué ha ocurrido

La plataforma RTX Spark, presente en dispositivos como el MSI Prestige, Asus ProArt y Dell XPS, utiliza una arquitectura de memoria unificada diseñada para cargas de trabajo intensivas de IA. Estos portátiles se envían con Windows on ARM y admiten hasta 128 GB de RAM compartida entre la CPU y la GPU. Dado que muchas herramientas de ingeniería de IA se construyen primero para Linux, los desarrolladores intentan naturalmente hacer dual-boot o reemplazar Windows con una distribución Linux nativa. Sin embargo, esta transición provoca una grave regresión de rendimiento vinculada al firmware de gestión de energía.

Al ejecutar Linux nativo, la velocidad del reloj de la GPU cae a aproximadamente 780 MHz una vez que el portátil se conecta a una fuente de alimentación externa. En contraste, el mismo hardware ejecutando Windows o WSL mantiene velocidades de reloj superiores a 2 GHz bajo carga. Esta discrepancia no es térmica; las temperaturas permanecen bajas, entre 40 y 47 °C. En cambio, la GPU está artificialmente limitada por una lógica de firmware que el controlador de Linux no puede acceder ni anular actualmente. El resultado es una disminución de cinco veces en la velocidad de generación de tokens para modelos de lenguaje grandes.

Instalar Linux en estos dispositivos también requiere una configuración manual significativa. Las distribuciones estándar como Debian a menudo fallan al reconocer componentes de hardware esenciales como Wi-Fi, teclados o touchpads sin parches específicos del kernel. Las configuraciones exitosas suelen depender de distribuciones como Omarchy, que incluyen los controladores de kernel de código abierto de Nvidia. Incluso después de lograr un entorno de escritorio estable con salida 4K a 120 Hz, los usuarios deben ajustar la configuración de asignación de memoria en Windows antes de arrancar Linux para garantizar que el SO pueda acceder a más de una fracción de la RAM disponible.

Cómo funciona

La causa raíz del throttling es un componente de firmware exclusivo de Windows llamado Nvidia Platform Controllers and Framework. En un factor de forma de portátil, este controlador gestiona el presupuesto de energía compartido entre la CPU y la GPU, asegurando que ningún componente exceda los límites totales de entrega de potencia del chasis. A diferencia de la unidad DGX Spark de escritorio, que tiene líneas de alimentación dedicadas, el portátil debe equilibrar dinámicamente el uso de energía. El firmware proporciona una tabla cifrada de ajustes de potencia que el controlador de Windows puede descifrar y aplicar, permitiendo que la GPU alcance su frecuencia máxima.

Linux carece de un controlador equivalente capaz de descifrar esta tabla de potencia. Sin acceso a estos ajustes, el kernel de Linux recurre por defecto a un estado seguro de baja potencia cuando el dispositivo está enchufado, bloqueando el reloj de la GPU en aproximadamente 780 MHz. Curiosamente, este comportamiento se invierte cuando el portátil funciona con batería, donde el rendimiento de Linux coincide estrechamente con el de Windows porque las restricciones de potencia se manejan de manera diferente. Los intentos de eludir esta limitación mediante soluciones alternativas de software han fracasado, con algunos causando pánicos del kernel, lo que indica que la clave de cifrado está estrictamente vinculada a la pila de controladores de Windows.

Detalles clave

• Linux nativo en el MSI Prestige RTX Spark logra solo 13,9 tokens por segundo en GPT-OSS-120B, en comparación con 65,4 tokens por segundo en Windows.
• La velocidad del reloj de la GPU está bloqueada en aproximadamente 780 MHz en Linux cuando está enchufado, frente a 2,2 GHz en Windows.
• WSL se comporta casi idénticamente a Windows nativo, alcanzando 65,1 tokens por segundo, porque utiliza la pila de controladores de Windows.
• Los usuarios deben reducir la reserva de memoria de la GPU en Windows de 96 GB a 4 GB antes de instalar Linux para permitir que el SO vea 120 GB de RAM.
• El problema de throttling es causado por una tabla cifrada de gestión de energía accesible solo al controlador Nvidia Platform Controllers de Windows.
• Deshabilitar el controlador de plataforma en Windows reproduce la ralentización de Linux, confirmando que el componente es responsable de la brecha de rendimiento.

Por qué importa

Para los ingenieros de IA y los profesionales de ML, este hallazgo cambia fundamentalmente la recomendación de hardware para estaciones de desarrollo portátiles. La promesa de un portátil con Linux nativo que rivalice con el rendimiento del DGX Spark de escritorio está actualmente incumplida debido a este bloqueo de firmware. Los desarrolladores que compran estas máquinas de gama alta esperando ejecutar LLMs locales, afinar modelos o usar herramientas como vLLM en un entorno Linux nativo encontrarán un cuello de botella severo. La caída de rendimiento de 65 a 14 tokens por segundo hace que la interacción en tiempo real con modelos grandes sea impracticable en Linux nativo.

Esta situación destaca la creciente complejidad de soportar hardware de IA en diferentes sistemas operativos. A medida que Nvidia avanza en el mercado de Windows basado en ARM con soporte CUDA, el ecosistema Linux se queda atrás en madurez de controladores para estas arquitecturas híbridas específicas. Hasta que Nvidia porte la lógica del controlador de plataforma a su controlador de Linux, los desarrolladores se ven obligados a elegir entre la conveniencia de las herramientas de Linux y el rendimiento bruto de Windows. Esta fragmentación añade fricción a flujos de trabajo que idealmente deberían ser independientes de la plataforma.

Qué puedes hacer

• Usa el Subsistema de Windows para Linux (WSL) para todas las cargas de trabajo pesadas de IA para mantener las velocidades completas de boost de la GPU mientras accedes a herramientas compatibles con Linux.
• Aumenta manualmente la asignación de memoria de WSL, ya que el límite predeterminado de 14 GB es insuficiente para modelos grandes en máquinas con 128 GB de memoria unificada.
• Si debes usar Linux nativo, realiza todas las tareas intensivas de inferencia mientras funcionas con batería, donde no ocurre el throttling del reloj.
• Ajusta la reserva de memoria de la GPU en la configuración de Windows a 4 GB antes de instalar Linux para asegurar que el sistema operativo pueda acceder a la mayoría de la RAM del sistema.
• Evita confiar en instaladores estándar de Debian o Ubuntu sin verificar que incluyan los controladores de kernel de código abierto necesarios de Nvidia para el chip RTX Spark.
• Monitorea las notas de lanzamiento de los controladores de Nvidia para actualizaciones sobre el soporte de Platform Controllers and Framework en Linux, ya que este es el único camino hacia una solución permanente.