jueves, 5 de noviembre de 202617°General Pico · 10° / 26°Dólar Oficial $1.570Dólar Blue $1.560Dólar MEP $1.589Dólar Tarjeta $2.041
Laptops con Nvidia RTX Spark pierden velocidad en Linux por firmware cifrado
Según una prueba de mindstudio.ai, la GPU de estas laptops queda limitada a unos 780 MHz en Linux cuando están conectadas a la corriente. La causa es un controlador de energía cuya tabla de configuración está cifrada y que, por ahora, solo Windows puede leer.
Redacción PicoTecno
· Actualizada 5 de noviembre de 2026 a las 09:08
3 min de lectura
(mindstudio.ai)
Según informó mindstudio.ai, es posible instalar Linux en las laptops con la plataforma RTX Spark, como la MSI Prestige N16 Flip AI Plus, y usar la aceleración por GPU mediante el driver de kernel abierto de Nvidia. El inconveniente aparece en la velocidad de reloj: con el equipo enchufado, la GPU se queda fija en alrededor de 780 MHz bajo Linux, mientras que en Windows supera los 2 GHz. Esa diferencia reduce el rendimiento de forma notable al ejecutar modelos de lenguaje.
La plataforma RTX Spark está presente en equipos como la MSI Prestige, la Asus ProArt y la Dell XPS, y usa el mismo diseño de GPU que la estación de escritorio DGX Spark de Nvidia. La diferencia es que el DGX Spark viene con una versión de Linux propia de Nvidia, mientras que estas laptops salen de fábrica con Windows on ARM, es decir, Windows para procesadores de arquitectura ARM. Combinar esa arquitectura con CUDA, la plataforma de cómputo de Nvidia, es una novedad que llegó con este chip. Además, estas máquinas permiten una memoria unificada de hasta 128 GB compartida entre CPU y GPU, algo poco común en una laptop.
Gran parte de las herramientas de inteligencia artificial, como vLLM y SGLang, están pensadas primero para Linux, por lo que muchos desarrolladores quieren saber si pueden dejar Windows o, al menos, usar un arranque dual sin perder rendimiento. La instalación, sin embargo, no fue sencilla. Una distribución basada en Arch llamada Omarchy no funcionó bien en la MSI Prestige, donde la pantalla parpadeaba durante el arranque. Debian sí anduvo, aunque necesitó parches manuales, un adaptador Ethernet por USB para conectarse a internet y el agregado de soporte para teclado, touchpad y GPU.
Al volver a Omarchy, el problema de los drivers quedó resuelto, pero Linux solo veía 28 GB de los 128 GB de memoria unificada. La causa es que el firmware reserva 96 GB para la GPU y esa división solo puede ajustarse desde Windows. Al bajar esa reserva a 4 GB, Linux pudo usar 120 GB, y con ese cambio el equipo funcionó con escritorio en 4K a 120 Hz, con audio, teclado, touchpad y aceleración CUDA.
En las pruebas con el modelo GPT-OSS-120B, Windows alcanzó 65,4 tokens por segundo y WSL, el subsistema que ejecuta un entorno Linux dentro de Windows, llegó a 65,1. La estación DGX Spark, con Linux nativo de Nvidia, marcó 61. En cambio, Linux nativo en la laptop cayó a 13,9 tokens por segundo, unas cinco veces menos. Con ocho clientes simultáneos en vLLM, WSL llegó a 127 tokens por segundo y Linux nativo a 39,5. Las temperaturas se mantuvieron entre 40 y 47 °C, por lo que el problema no parece ser térmico, sino que la GPU no puede alcanzar su velocidad máxima.
El comportamiento cambia según la fuente de energía: con batería, Linux alcanzó una velocidad similar a la de Windows en LM Studio, pero conectado a la corriente bajó a unos 15 tokens por segundo. La causa está en un componente que Windows muestra como Nvidia Platform Controllers and Framework, encargado de repartir la energía entre CPU y GPU. Al desactivarlo en Windows, el rendimiento cayó de unos 83 a 31 tokens por segundo y el reloj volvió a 786 MHz, lo que indica que el cuello de botella está en ese controlador y no en el kernel, la distribución o el driver. El fondo del asunto es que la tabla de configuraciones de energía está cifrada: Windows tiene la clave, pero Linux no, y ninguna solución probada en las pruebas logró habilitarla. Extraer la clave del driver de Windows fue planteado como alternativa, aunque sería un parche frágil y válido solo para una máquina. Una solución real requeriría que Nvidia incorpore esa lógica de administración de energía en su driver para Linux.
Para la mayoría de los desarrolladores, WSL es por ahora la opción más práctica. Como se apoya en el stack de drivers de Windows, mantiene el comportamiento de boost de la GPU tanto enchufada como con batería y ejecuta herramientas como vLLM y SGLang sin el problema de throttling. Solo hace falta aumentar manualmente la memoria asignada, ya que WSL reserva 14 GB por defecto. Configurado así, su rendimiento queda cerca del de Windows nativo, hasta que Nvidia resuelva la brecha de su driver para Linux.
