Por qué la GPU de un portátil RTX Spark (Linux) se vuelve cinco veces más lento al cargar

En el instante en que se conecta el cable de alimentación del portátil, la velocidad de la GPU cae a una quinta parte, y al desconectarlo vuelve a su velocidad normal, ¿cuál es la causa? Se trata de un fenómeno inverso que se reporta de forma habitual al usar Linux en portátiles con IA actuales, como el MSI Prestige RTX Spark. Según la comparación directa de varios sistemas operativos realizada por MindStudio.ai sobre el mismo equipo, el rendimiento de inferencia de Linux nativo en estado de carga se limitó a 13,9 tokens/s (número de tokens generados por segundo; un token es una pequeña unidad de texto en la que se divide una frase para facilitar su análisis), mientras que Windows y WSL (Windows Subsystem for Linux) registraron velocidades prácticamente idénticas de 65,4 y 65,1 tokens/s, respectivamente ¹. Las temperaturas oscilaron entre 40 y 47 °C, valores bajos que descartaron el estrangulamiento térmico (throttling), es decir, la reducción de velocidad provocada por el calor ¹. El problema no radica en el calor del hardware, sino en la reacción del software ante las diferentes formas de alimentación eléctrica.

Motivos para usar Linux en portátiles con IA y la existencia de RTX Spark

RTX Spark es una plataforma que traslada el diseño de la GPU GB10, empleada en el equipo de sobremesa DGX Spark, al formato portátil. Se integra en familias de productos como MSI Prestige, Asus ProArt y Dell XPS, y adopta una arquitectura de memoria unificada en la que la CPU y la GPU comparten hasta 128 GB de memoria ¹. Gracias a la posibilidad de emplear toda esa memoria de forma integrada, los desarrolladores interesados en ejecutar localmente modelos de lenguaje de gran tamaño, como los de 120 000 millones de parámetros, tienen la mirada puesta en este dispositivo. No obstante, estos equipos salen de fábrica con Windows basado en ARM preinstalado ¹.

El obstáculo reside en el ecosistema de herramientas de IA. Programas ampliamente utilizados para la inferencia en IA, como vLLM y SGLang, tienden a desarrollarse priorizando Linux. La inferencia en Linux se refiere al proceso computacional mediante el cual un modelo de lenguaje genera tokens, uno a uno, en respuesta a las preguntas del usuario. Para gestionar este trabajo sin dilaciones, la GPU debe realizar cálculos continuamente a alta velocidad (frecuencia de reloj). Por esta razón, los usuarios de estos portátiles recurren al arranque dual (dual-boot), un método que permite elegir entre dos sistemas operativos en el mismo dispositivo sin eliminar Windows ¹. Los experimentos de MindStudio.ai parten precisamente de este punto.

Temperaturas y rendimientos revelados en los cuatro entornos del mismo portátil

MindStudio.ai midió tres entornos (Windows, WSL y Linux nativo) en un MSI Prestige RTX Spark ejecutando un modelo de 120 000 millones de parámetros (GPT-OSS-120B), y utilizó además la velocidad de inferencia del mismo modelo en un equipo de sobremesa Nvidia DGX Spark como referencia comparativa. Al organizar los resultados en una tabla, la diferencia se aprecia de forma clara.

[Fuente de la tabla: ¹]

Únicamente el entorno de Linux nativo en el mismo portátil alcanzó los 13,9 tokens/s, quedando aproximadamente cinco veces por debajo del resto ¹. Esta brecha se reproduce de otras maneras. En un experimento de vLLM procesando ocho solicitudes simultáneamente, WSL registró 127 tokens/s y Linux nativo, 39,5 tokens/s ¹. En términos temporales, Windows tardó aproximadamente 8 minutos frente a los 37 minutos de Linux; durante ese periodo, la GPU mantuvo una frecuencia de unos 2,2 GHz en Windows y de unos 790 MHz en Linux ¹.

El aspecto más revelador es la inversión de esta tendencia. Al desconectar el portátil de la toma de corriente y ejecutarlo con batería, la frecuencia de la GPU en Linux se eleva hasta cerca de 1 800 MHz, recuperando un rendimiento similar al de Windows ¹. La velocidad de inferencia en estado de batería, verificada mediante el programa LM Studio, fue de 61 a 67 tokens/s, mientras que la misma prueba, realizada con el cable de carga conectado, cayó a cerca de 15 tokens/s ¹. En consecuencia, el cargador no es un enemigo del rendimiento; más bien, bajo la condición de tener un cargador conectado es cuando se hace visible la anomalía.

La causa: un componente exclusivo de Windows que reparte el 'presupuesto energético'

![La causa: un componente exclusivo de Windows que reparte el 'presupuesto energético']](https://static.klipy.com/ii/925f17378dd1893b674a723c07535afe/91/ae/0rH6BDFt.jpg)

La pista clave para resolver esta paradoja es un componente de software denominado 'Nvidia Platform Controllers and Framework', visible en el Administrador de dispositivos de Windows. Mientras que en un equipo de sobremesa como el DGX Spark basta con alimentar la GPU mediante líneas eléctricas independientes, el caso del portátil es diferente. Al compartir un presupuesto energético predeterminado, la CPU y la GPU requieren un coordinador que regule en tiempo real cuánta energía destinar a cada unidad ¹. Este coordinador es precisamente Platform Controllers and Framework (identificador de hardware: ACPI\NVDA0820) ².

MindStudio.ai llevó a cabo un experimento de control desactivando este coordinador en Windows. Como resultado, la velocidad de inferencia descendió de 83 a unos 31 tokens/s, la frecuencia de reloj bajó de 2 GHz a 786 MHz y se reprodujo exactamente el mismo cuello de botella observado en el estado de carga bajo Linux. Al reactivarlo, la velocidad normal se restableció de forma inmediata ¹. Por tanto, la causa no es el kernel, ni la distribución, ni el propio controlador de la GPU, sino este único componente.

¿Por qué se comporta como si estuviera averiado bajo Linux? Para distribuir la energía, el coordinador debe leer la 'tabla de configuraciones de alimentación' que le transmite el firmware (programa de bajo nivel integrado en el hardware). Sin embargo, esta tabla está cifrada. Windows dispone de la clave de descifrado necesaria para leerla, pero el controlador actual de Linux carece de ella y, por consiguiente, no puede interpretarla ¹. Al no disponer de la clave, en situaciones de carga donde se debe recalcular la distribución de energía, el sistema no puede emitir la orden de llevar la GPU a su frecuencia máxima, quedando esta estancada en torno a los 780 MHz. Durante la experimentación se intentaron varios parches de software que resultaron fallidos, y en una de las pruebas se reportó incluso un fallo crítico del kernel (kernel panic, detención del sistema operativo) ¹. Cabe señalar que la comunidad ha debatido el motivo del cifrado por parte de Nvidia, oscilando entre la explicación de la 'protección de la propiedad intelectual' y la crítica de la 'dependencia intencionada de Windows'; ninguna de las dos hipótesis se ha confirmado experimentalmente ³.

WSL: la respuesta más realista disponible en la actualidad

Hasta que Nvidia incorpore esta lógica de gestión de energía al controlador de Linux o publique la clave de descifrado, WSL (Windows Subsystem for Linux) se mantiene como la alternativa de facto ¹, ³. Dado que WSL superpone un entorno Linux dentro de Windows, hereda directamente el mecanismo de boost de la GPU (aumentar su frecuencia) que Windows ya posee. Esto permite ejecutar herramientas de IA optimizadas para Linux, como vLLM, sin penalización de frecuencia, ya sea con el portátil conectado a la red eléctrica o funcionando con batería ¹.

No obstante, ArchWiki advierte de manera específica que el firmware GSP puede causar fallos totales en ciertos portátiles equipados con GPU de la arquitectura Ampere. Por ello, es necesario verificar la configuración del controlador en el hardware de cada usuario ⁴.

En resumen, la caída de la velocidad de inferencia bajo Linux en un portátil RTX Spark no se debe al 'calor' ni a un 'defecto de hardware', sino a la limitación del controlador de Linux, que carece de la clave para interpretar la tabla cifrada de gestión de energía ¹. El cable de carga no merma el rendimiento per se; más bien, esta carencia se manifiesta exclusivamente en el momento de conectar la corriente, cuando debe recalcularse la distribución de energía entre la CPU y la GPU. Esta conclusión se ha verificado con la combinación de Linux nativo y el modelo GPT-OSS-120B en el MSI Prestige RTX Spark. Hasta que Nvidia no añada la misma lógica de gestión energética al controlador de Linux, la opción más segura es obtener el rendimiento completo mediante WSL, apoyándose en la pila de controladores de Windows.