La promesa era simple: un portátil con 128 GB de memoria unificada, pensado para correr modelos de IA local. La realidad la comprobó un desarrollador que instaló Linux nativo en un MSI Prestige con el chip RTX Spark de Nvidia. Corriendo el mismo modelo, en la misma GPU: Windows movÃa 65,4 tokens por segundo, WSL llegaba a 65,1, y el Linux nativo se quedaba en 13,9. Cinco veces más lento. No era driver faltante: el open de Nvidia estaba funcionando. El problema estaba más abajo, en el firmware.
Un controller que solo Windows puede leer
El culpable se llama Nvidia Platform Controllers and Framework: un componente de firmware que reparte el presupuesto de energÃa entre CPU y GPU. En los portátiles con este chip —el MSI Prestige, el Asus ProArt, algunos Dell XPS— ese controller recibe una tabla de configuración de energÃa encriptada, y la llave la tiene únicamente el driver de Windows. Linux no la puede leer. Al enchufar el cargador, la GPU queda estacionada en unos 780 MHz, contra los 2,2 GHz de Windows.
La confirmación fue quirúrgica: desactivaron el controller directo en Windows y la velocidad se cayó de 83 a 31 tokens por segundo, con el clock aterrizando en los mismos 786 MHz que ve Linux. Reactivado, todo volvió a la normalidad. Causa aislada: no es el kernel ni el driver de la GPU. Es el firmware, y un intento de extraerle la llave terminó en kernel panic.
La ironÃa: enchufado corre peor
Lo más absurdo del cuento es la dirección del problema. Con baterÃa, Linux alcanzaba entre 61 y 67 tokens por segundo, casi igual que Windows; enchufado a la pared, se caÃa a 15. Al revés de lo que cualquiera esperarÃa. Y la ironÃa suprema: WSL, que es Linux corriendo encima de Windows, va más rápido que Linux nativo, porque hereda el driver stack completo de Windows. Con vLLM y ocho clientes concurrentes: 127 tokens por segundo en WSL contra 39,5 en nativo. Y una corrida larga: una tarea que Windows terminaba en 8 minutos a Linux le tomó 37, con la GPU trabada en ~790 MHz todo el rato y temperaturas de apenas 40-47 °C. No es throttling térmico: la GPU simplemente no tiene permiso de ir a toda velocidad.
Lo que le aprendo a esto
Llevo años operando servidores Linux de todo tipo, y el patrón ya me cansa: te venden «soporte open» cuando lo que abre es apenas una capa del stack. El driver del kernel es open, bacán, pero el firmware que decide cuánta energÃa recibe la GPU es una caja negra encriptada que solo un sistema operativo en particular puede descifrar. En mi fleet de VPS pasa parecido: puedo auditar todo el software de arriba, pero el BMC y el firmware de bajo nivel son fe de fe del fabricante.
La segunda pata es la memoria. La máquina reservaba 96 GB de los 128 GB para la GPU y solo Windows exponÃa el ajuste para cambiar ese reparto. Al partir, Linux veÃa 28 GB del total; hubo que bajar la reserva a 4 GB desde Windows para que Linux viera 120 GB. Si el interruptor que libera la RAM vive del lado de Windows, quedaste amarrado a un dual boot solo para tocar un número.
Yo no creo que sea sabotaje: es descuido con prioridad clara. Nvidia tiene su propio build de Linux para la unidad de escritorio DGX Spark y ahà todo funciona, a 61 tokens por segundo. Para los portátiles, el fix depende de que Nvidia mande la lógica del controller a su driver Linux; mientras tanto, la lección al comprar hardware «para IA local» es revisar qué partes del stack quedan bajo llave del fabricante. Si Windows tiene la llave y Linux no, la mitad del rendimiento te la venden amarrada.
Si auto-alojas IA en Linux, mi posición es simple: hoy este hardware corre mejor bajo WSL que en tu sistema operativo real, algo que hace diez años habrÃa parecido un chiste malo. Exigir que el driver Linux traiga la lógica de power management es la única solución seria, y no un parche de la comunidad con una llave extraÃda a mano.
Fuente de inspiración: Linux on the Nvidia RTX Spark Laptop: What Actually Works
