Linux en Snapdragon X2: qué cambia para la IA en el código

Qualcomm confirmó en el Snapdragon Summit que el soporte para Linux llegará a la serie Snapdragon X2. Si alguna vez intentaste instalar una distro en un portátil con el X Elite de la generación anterior, sabes por qué esto es noticia. Linux en Snapdragon X2 puede ser la primera vez que un portátil ARM con una NPU de verdad le sirve al dev que vive en la terminal. Al que usa Docker todo el día y quiere probar modelos de IA local sin pagar API.

El anuncio oficial está en el blog de Qualcomm. Viene envuelto en el discurso de los "PCs con IA agéntica", pero quiero hablar de lo que le importa a quien escribe código.

Lo que anunció Qualcomm, sin el marketing

En resumen: la línea X2, la de núcleos Oryon de tercera generación y NPU Hexagon en torno a los 80 TOPS, tendrá Linux como plataforma soportada. Ya no es "que la comunidad se las arregle". Al menos eso promete la empresa.

El contexto pesa. En la generación X1, Linux llegó tarde y a pedazos. Cada modelo de portátil necesitaba su propio device tree. Algunas máquinas arrancaban y otras no. Cosas básicas como el audio, la webcam y la suspensión funcionaban en un modelo y fallaban en otro. Salieron imágenes experimentales de Ubuntu y Linaro subió mucho código al kernel. Aun así, la recomendación honesta para un dev era: cómpralo si quieres jugar, no si quieres trabajar.

Con el X2, la promesa es empezar con el soporte ya planificado desde el lanzamiento, y no un año después. Si se cumple, las cuentas cambian.

Por qué Linux en Snapdragon X2 importa a quien usa IA en el código

Hoy, quien quiere IA local en el portátil tiene básicamente dos caminos:

• Un Mac con Apple Silicon, que ejecuta modelos bien gracias a la memoria unificada, pero te ata a macOS.
• Un portátil x86 con GPU dedicada, que funciona bien, se calienta, hace ruido y dura tres horas con batería.

Un ARM con NPU corriendo Linux nativo es un tercer camino que no existía de forma decente. Batería de ARM, entorno de servidor y un acelerador dedicado para inferencia.

Y hay un detalle del que poca gente habla. Buena parte de tu stack de producción ya corre en ARM. Graviton en AWS, Ampere en Oracle y en Hetzner, imágenes arm64 por todas partes. Desarrollar con el mismo conjunto de instrucciones que el servidor elimina toda una clase de bugs del tipo "en mi máquina funciona".

Una NPU sin driver abierto es solo un número bonito en la ficha técnica.

Lo que lo decide todo: la NPU en Linux

Aquí está mi opinión más fuerte. Una CPU ARM con Linux es un problema resuelto desde hace años. La prueba real del X2 es otra: ¿se puede usar la NPU en Linux sin apaños?

En Windows, Qualcomm expone la NPU a través de ONNX Runtime con el QNN Execution Provider y de su propio Qualcomm AI Stack. En Linux, la historia siempre fue más difusa. Existe un SDK con build para Linux, pero la integración con el ecosistema que usas a diario (llama.cpp, Ollama, PyTorch) es otra cosa.

Si la NPU queda atrapada en un SDK propietario, con binario cerrado y una versión de kernel específica, nadie la va a usar. El dev ejecutará todo en la CPU y la GPU y seguirá con su vida. Ya vi esta película con varias placas de "IA" en los últimos años.

Si el driver entra en el kernel principal (el subsistema accel existe justo para eso) y los runtimes populares ganan un backend, entonces sí. Ahí el X2 se convierte en una máquina de desarrollo de IA de verdad.

Así que mi consejo es simple: no compres por la promesa de la NPU. Si vas a comprar, hazlo por lo que ya funciona en la CPU y la GPU. La NPU es un extra hasta que demuestre lo contrario.

Lo que ya se puede hacer hoy, incluso sin NPU

La buena noticia es que se puede hacer bastante solo con los núcleos ARM. llama.cpp tiene optimizaciones para ARM desde hace tiempo, incluidas instrucciones de producto escalar y de matrices que aceleran mucho los modelos cuantizados. Un modelo de 7B u 8B en Q4 corre a una velocidad usable en una CPU ARM moderna.

El flujo es el mismo que en cualquier Linux:

# confirma la arquitectura
uname -m
# aarch64

# Ollama tiene build oficial para linux arm64
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen2.5-coder:7b

Desde ahí lo conectas a tu editor, a Continue o al agente que prefieras, apuntando a localhost:11434. Nada cambia en tu código. Solo la máquina de abajo.

Para quien usa Bun y Node, la vida también es tranquila. Los dos tienen binario linux-arm64 oficial. El problema suele aparecer en dependencias nativas antiguas, ese paquete que descarga un .node precompilado solo para x86. Vale la pena ejecutar esto antes de migrar:

# lista los paquetes con binario nativo en el proyecto
find node_modules -name "*.node" -type f | head -20

Si aparece algo raro, revisa si el paquete publica build para arm64 o si compila en el postinstall. En mi experiencia, sharp, bcrypt y esbuild ya lo resuelven solos. Lo que da dolores de cabeza son las librerías abandonadas.

¿Y Docker, PostgreSQL y el resto del stack?

Es la pregunta que todos hacen. La respuesta corta: en 2026 es lo que menos preocupa.

PostgreSQL oficial tiene imagen arm64. Redis también. La mayoría de las imágenes populares de Docker Hub son multi-arch. El riesgo está en la imagen interna de tu empresa, esa que alguien construyó en 2021 solo para amd64.

Ejecutar una imagen x86 en ARM funciona con emulación QEMU, pero es lento. Para un servicio que levantas y olvidas, está bien. Para la base de datos que corre los tests de integración 40 veces al día, no.

Lo correcto es construir multi-arch de una vez:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t mi-api:latest \
  --push .

Esto lo resuelve para ti y para quien haga deploy en Graviton después. Es el tipo de ajuste que haces una vez y olvidas.

Lo que todavía me hace desconfiar

No quiero sonar como un folleto de lanzamiento, así que vamos a las reservas.

Primero, el soporte por modelo de portátil. En la generación anterior, "el chip soporta Linux" no significaba que tu portátil lo soportara. A los fabricantes de portátiles rara vez les importa Linux. Antes de comprar, busca el modelo exacto y comprueba si alguien ya logró arrancar, suspender y despertar la máquina sin dramas.

Segundo, el firmware. Mucho de lo que hay en estos chips depende de firmware propietario que la distro tiene que extraer de Windows o descargar de algún sitio. Si Qualcomm no facilita su distribución, la instalación seguirá siendo un tutorial de 14 pasos en un foro.

Tercero, la GPU. La Adreno tiene driver abierto en Mesa (Freedreno, con Turnip para Vulkan), y es bueno. Pero el soporte para una generación nueva siempre llega con algo de retraso. Si tu plan es usar la GPU vía Vulkan en llama.cpp, espera unos meses de maduración.

Y por último, la parte graciosa: Qualcomm anunció Linux en una presentación sobre "IA agéntica". O sea, probablemente el primer agente que va a funcionar bien en estas máquinas eres tú, compilando el kernel a las dos de la mañana.

¿Vale la pena para el dev?

Mi lectura: es la noticia más interesante sobre portátiles ARM desde el M1, pero por otra razón. El M1 demostró que ARM sirve para trabajar. El X2 con Linux puede demostrar que se puede tener eso sin cambiar de sistema operativo ni de filosofía.

Si usas IA local a diario, yo esperaría a los primeros análisis con Linux ya instalado. Mejor si alguien prueba inferencia en la NPU y no solo benchmarks de CPU. Si solo quieres una máquina ligera con batería larga para programar en TypeScript y levantar algunos contenedores, el riesgo es menor y la recompensa llega antes.

En cualquier caso, ya vale la pena dejar tus proyectos listos para arm64 hoy. Cuesta poco y te deja libre para elegir la máquina después. Es lo que vengo haciendo en mis proyectos.

Qualcomm prometió Linux en el Snapdragon X2. Pero para quien programa, lo que importa es si la NPU va a funcionar.

En la generación X1, Linux llegó tarde y a pedazos. Cada portátil tenía un problema distinto.

Ahora la promesa es tener soporte desde el lanzamiento. Sería un portátil ARM con batería larga, el mismo entorno que el servidor e IA local sin pagar API.

El problema es que una NPU sin driver abierto es solo un número bonito en la ficha técnica. Si queda atrapada en un SDK cerrado, todos van a usar la CPU y olvidar que existe.

Mi consejo: no compres por la promesa. Mientras tanto, deja tus proyectos listos para arm64. Cuesta poco y te deja libre para elegir la máquina después.

Escribí el paso a paso completo en el blog, con Ollama, Docker multi-arch y las reservas que todavía me hacen desconfiar.

#Linux #ARM #InteligenciaArtificial #DesarrolloDeSoftware #Docker