Arch Linux en un RTX Spark: 116 GB para IA local

Un maintainer de Arch metió Linux en un portátil RTX Spark y le sacó 6,3 GiB más de memoria que Windows

Un portátil con 128 GB de memoria unificada que la GPU puede usar entera es, sobre el papel, la máquina soñada para inferencia local. El problema: NVIDIA solo da soporte oficial a Windows en la plataforma RTX Spark. Un maintainer de paquetes de Arch Linux decidió que eso no era un obstáculo y publicó el resultado: su ASUS ProArt P16 H7607BA-SE033W corre Arch Linux ARM con 116,0 GiB reportados a la vez como RAM del sistema y como memoria total de CUDA, desde el mismo pool físico.

La cifra importa porque en Windows ese pool está dividido en tres regiones —GPU dedicada, compartida y solo-CPU— y las cargas de CPU no pueden tocar la región dedicada a la GPU. En Linux, el mismo espacio sirve para ambas cosas sin reiniciar entre tareas.

¿Qué hizo exactamente para que Linux arrancara en un RTX Spark?

El trabajo no fue un dd y a correr. Según el propio autor, partió del trabajo de kernel que NVIDIA ya venía haciendo para Ubuntu, corrigió la asignación de los overrides de ACPI y el mapeo del framebuffer para conseguir consola, y derivó los overrides de ACPI de las tablas del propio portátil. El teclado necesitó un hid-asus parcheado y el audio su propio driver de máquina. El firmware de los altavoces ASUS salió del paquete de drivers oficial del fabricante.

Todo eso lo empaquetó en un USB arrancable y extendió Archinstall 4.5 para que instalara el soporte de hardware. El repositorio incluye los scripts de build y los parches, con las entradas de build fijadas por hash y los paquetes firmados con su clave de Arch Linux Package Maintainer. Su unidad corre firmware H7607BA.300.

El detalle que menos se suele contar: el instalador mantiene el kernel, los drivers NVIDIA, la gestión de energía y los paquetes de firmware bajo IgnorePkg. Es decir, el sistema base sigue actualizándose desde Arch Linux ARM, pero esas piezas quedan congeladas a propósito. Es la decisión correcta para estabilidad y, a la vez, una deuda de mantenimiento que hay que asumir conscientemente.

Linux vs Windows: ¿pierde rendimiento por no usar el sistema oficial?

Aquí está la parte que más interesa a quien esté evaluando comprar. El autor corrió 7-Zip 26.04 nativo ARM64 con diccionario fijo de 32 MiB —una pasada de calentamiento y tres medidas por número de hilos, tomando medianas— y comparó contra resultados publicados de Windows en un HP OmniBook Ultra 16 con el mismo SoC N1X de 20 núcleos.

• Compresión a 1 hilo: 7,221 GIPS en Linux frente a 7,31 en Windows (−1,2%)
• Descompresión a 1 hilo: 10,779 frente a 10,87 (−0,8%)
• Compresión a 20 hilos: 165,754 frente a 157,9 (+5,0%)
• Descompresión a 20 hilos: 148,471 frente a 144,5 (+2,7%)

En un hilo es prácticamente un empate. Con los 20 hilos, la configuración Linux va por delante. El propio autor advierte la letra pequeña: la review del HP no especifica versión de 7-Zip ni tamaño de diccionario, así que esos porcentajes comparan dos portátiles, no aíslan el efecto del sistema operativo.

Un segundo contraste refuerza la idea: ComputerBase midió un ProArt P16 con el mismo N1X de 20 núcleos en Windows y obtuvo 155,774 GIPS, dentro del rango de las tres corridas del autor (155,759 a 157,193, mediana 157,084). La máquina de ComputerBase era la configuración de 64 GB y corría 7-Zip 26.00.

¿Cuánta memoria puede usar realmente la GPU?

La comparación más concreta viene de Frandroid, que probó un ProArt P16 de 128 GB en Windows. Con una reserva dedicada de 91 GiB, su equipo reportó un total de CUDA de 109,7 GiB incluyendo memoria compartida. El montaje Linux reporta 116,0 GiB: unos 6,3 GiB más.

Pero el punto no es solo el número. En Windows hay que mover el slider de reserva dedicada en la app de NVIDIA y reiniciar para cambiar el reparto entre cargas de CPU y GPU. En Linux no hay slider ni reinicio: el pool grande está disponible para ambas cosas al mismo tiempo. Para alguien que alterna entre procesar datos en CPU y correr un modelo en GPU durante la misma jornada, esa fricción se nota.

¿Se puede correr un modelo grande en local con esto?

El autor cargó el checkpoint Qwen3.8-Flash-Next-FP4-Local de NVIDIA a través de vLLM con kernels CUDA B12X, en un contenedor ARM64 nativo, con cuantización mixta y caché KV en FP8. Antes de cargar, Linux reportaba 110,9 GiB de RAM disponible. vLLM registró 68,2 GiB para la carga del modelo y asignó otros 21,1 GiB a la caché KV: casi 90 GiB dedicados a modelo y caché en un portátil.

La carga y compilación tardó unos 16 minutos antes de la primera petición. Después, con tres tareas repetidas tres veces cada una y respuestas conocidas para verificar:

• Revisión de código Python (208 tokens de entrada): primer token en 0,316 s, respuesta completa en 4,008 s, 3/3 correctas
• Encontrar el fallo en un log de incidencias de 128 registros (9.775 tokens de entrada): primer token en 4,532 s, respuesta completa en 5,768 s, 3/3 correctas
• Extracción de una nota de pago a JSON (87 tokens): primer token en 0,256 s, respuesta completa en 2,035 s, 3/3 correctas

El dato interesante es el segundo: leer casi 10.000 tokens y devolver la petición, la causa y la acción siguiente correctas en menos de 6 segundos. La respuesta tenía solo 39 tokens, o sea 6,8 tokens/s en el conjunto de la petición —casi todo el tiempo se fue en procesar el prompt, no en generar.

En velocidad de generación pura, el autor estimó 30,9 tokens/s (mediana de 3) para revisión de código. Frandroid, en Windows con llama.cpp y cuantización UD-IQ4_XS, obtuvo 29,4 y 31,4. Ambos rondan los 30 tokens/s, aunque con cuantizaciones, runtimes y métodos de medición distintos: es una comparación de dos configuraciones que funcionan, no un experimento controlado.

También probó concurrencia: cuatro revisiones de código a la vez terminaron en 5,314 s de mediana, con 86,6 tokens/s de salida agregada. Y dejó el sistema en bucle diez minutos: 150 peticiones, 50 de cada tarea, todas las respuestas pasaron las comprobaciones, con tiempos que crecieron menos de 1,6% entre las diez primeras y las diez últimas repeticiones. En total, 171 respuestas medidas, todas correctas.

¿Qué significa esto para tu startup?

El mensaje de fondo no es "instala Arch". Es que la memoria unificada cambió la economía de la inferencia local, y el software va por detrás del hardware. Un portátil de 128 GB con un pool coherente entre CPU y GPU puede sostener casi 90 GiB de modelo más caché KV, algo impensable en cualquier GPU discreta de portátil.

El contexto de mercado ayuda a dimensionarlo. Wccftech describe el RTX Spark como la primera plataforma completa de PC de NVIDIA, anunciada en Computex 2026, con el N1X de 20 núcleos, 6.144 núcleos CUDA, memoria LPDDR5X de hasta 9.400 MT/s y 300 GB/s de ancho de banda, en un TDP de 45 a 80 W. TweakTown recoge que los ProArt P16 y P14 abrieron preventa con envíos previstos desde el 16 de octubre de 2026 y precios desde US$2.599,99, con las configuraciones de 64 y 128 GB disponibles solo en canales limitados. En el extremo opuesto, Notebookcheck reporta que el Surface RTX Spark Dev Box de Microsoft, con los mismos 128 GB unificados y 2 TB, se vende a US$5.999.

Y la competencia no se queda quieta: TechTimes cubrió el lanzamiento comercial de la serie Ryzen AI Max PRO 400 de AMD en IFA 2026, con hasta 192 GB de memoria unificada y 160 GB asignables a la GPU, además de recordar que el DGX Spark de NVIDIA parte de US$4.699 en su Founders Edition con 128 GB. El mismo artículo advierte del viento de cara: los precios de contrato de LPDDR subieron cerca de 146% interanual hasta mediados de 2026, según datos de Supplyframe Commodity IQ.

Tres acciones concretas para tu equipo:

• Mide antes de comprar. Si tu caso de uso es inferencia, el cuello de botella es memoria y ancho de banda, no cómputo puro. Antes de comprometer presupuesto, corre tus propios prompts en un equipo de prueba y registra tiempo al primer token y tokens/s. Los benchmarks sintéticos no te dicen si tu agente aguanta una tarde de trabajo.
• Presupuesta el coste de salirte del camino oficial. El montaje del ProArt demuestra que Linux funciona, pero exige parches propios de ACPI, teclado y audio, y congelar kernel y drivers con IgnorePkg. Si nadie en tu equipo mantiene eso, el ahorro se lo come el soporte. Si lo tienes, ganas control total del stack y cero dependencia de una app de terceros para repartir memoria.
• Diseña para el pool compartido. Si vas a construir sobre hardware de memoria unificada, asume que CPU y GPU compiten por el mismo espacio. Deja margen para la caché KV: en esta prueba, 21,1 GiB de caché sobre 68,2 GiB de pesos es una proporción que crece rápido con el contexto.

Conclusión

El experimento no demuestra que Linux sea más rápido que Windows en RTX Spark —el propio autor se cuida de decirlo—. Demuestra algo más útil para quien decide compras: el hardware no está limitado por el sistema operativo oficial, y la memoria unificada se puede aprovechar completa si aceptas mantener tu propia pila de software. Para un equipo con perfil técnico que quiere inferencia local sin factura por token, es una vía real. Para el resto, es una advertencia: la máquina de 128 GB no rinde por sí sola si el reparto de memoria te obliga a reiniciar cada vez que cambias de carga.

Fuentes

• josie.lol — Putting Linux on my RTX spark laptop because I don't have a Microsoft account (fuente original)
• Wccftech — ASUS ProArt P16 "RTX Spark" Laptop Review
• TweakTown — ASUS launches ProArt P16 and P14 laptops powered by NVIDIA RTX Spark
• Notebookcheck — Microsoft launches compact local AI monster with 128 GB unified memory
• TechTimes — Ryzen AI Max PRO 400: 192GB Unified Memory Puts 300B-Parameter LLMs on Your Desk Without the Cloud