Linux en Snapdragon X2: qué cambia para quienes programan

Qualcomm aprovechó el Snapdragon Summit de 2026 para anunciar que Linux llegará a la línea Snapdragon X2. Si alguna vez intentaste instalar una distro en una laptop con el X Elite de primera generación, sabes por qué esto es noticia. El soporte de Linux en Snapdragon X2 responde a una queja antigua de la comunidad. La promesa es tratar a Linux como ciudadano de primera clase, y no como un proyecto paralelo que la empresa deja en manos de voluntarios.

El anuncio original está en el blog OnQ de Qualcomm. Viene acompañado de mucho discurso sobre "PCs con IA agéntica". Voy a separar las dos cosas, porque para quien escribe código solo una de ellas pesa ahora.

Qué pasó con Linux en Snapdragon X2

La línea X2 es la segunda generación de chips ARM de Qualcomm para laptops. Trae una CPU Oryon nueva, GPU Adreno y una NPU Hexagon de unos 80 TOPS, el número que Qualcomm repite desde el lanzamiento. Hasta ahora el foco era 100% Windows on ARM.

Lo que cambia es el compromiso público con Linux. La empresa dice que llevará soporte a la plataforma X2, y eso incluye el trabajo de kernel y drivers que faltó en la primera generación.

Vale la pena recordar cómo fue la última vez. En el X Elite, el soporte llegó a pedazos:

• El kernel mainline recibió soporte básico para el SoC bastante rápido.
• Cada laptop necesitaba su propio device tree, y muchos modelos pasaron meses sin uno.
• Cosas como suspensión, webcam, audio y aceleración de GPU funcionaban en un modelo y fallaban en otro.
• La NPU, que era el gran argumento de venta, quedó prácticamente inaccesible para quien no usaba Windows.

O sea, funcionaba, pero solo si aceptabas jugar a mantenedor de distro los fines de semana.

Por qué esto importa a quien desarrolla

La mayor parte del código que escribimos corre en Linux. Tu backend en Node o Bun, tu Postgres, tu contenedor de CI, tu función serverless. Todo eso es Linux, y cada vez más es Linux en ARM. Graviton en AWS, Ampere en Oracle Cloud, Axion en Google Cloud.

Desarrollar en x86 y desplegar en ARM funciona, pero tiene fricción. Imágenes Docker sin build para arm64. Dependencias nativas que compilan distinto. Benchmarks locales que no dicen nada sobre producción.

Una laptop ARM con Linux de verdad cierra ese ciclo. Desarrollas en la misma arquitectura y en el mismo sistema donde va a correr el código. La Mac con Apple Silicon ya ofrece la mitad de eso, la arquitectura. La otra mitad, el sistema operativo, sigue exigiendo una VM.

Desarrollar en la misma arquitectura que corre en producción elimina una categoría entera de bugs.

También está el tema de la batería. Los chips ARM de Qualcomm ofrecen una autonomía que una laptop x86 con Linux rara vez alcanza. Si la gestión de energía funciona en Linux como en Windows, eso solo ya justifica mirarlo con cariño.

¿Y la parte de IA en el código?

Aquí se pone interesante, y es donde pido calma.

Qualcomm vende el X2 como plataforma para IA agéntica: agentes corriendo en local, llamando herramientas, sin depender de la nube. Para quien desarrolla, la traducción práctica es correr modelos de código en la propia laptop. Autocompletado local, un agente que lee tu repositorio sin mandar nada afuera, embeddings para búsqueda semántica en el código.

Hoy, en Linux sobre ARM, ese trabajo cae casi todo en la CPU. Y la CPU del X2 aguanta bastante. Un modelo pequeño, de 3B a 8B parámetros cuantizado, corre de forma usable con llama.cpp u Ollama. Ni siquiera necesitas la NPU para empezar:

# confirma que de verdad estás en ARM
uname -m
# aarch64

# Ollama ya tiene build para arm64
ollama run qwen2.5-coder:7b

La NPU es otra historia. Para usar esos 80 TOPS necesitas un driver en el kernel y un runtime que sepa hablar con el Hexagon. En el ecosistema de Qualcomm eso pasa por su SDK de IA, y la pregunta que nadie ha respondido bien todavía es: ¿cuánto de eso va a estar disponible, abierto e integrado en los runtimes que usamos, como ONNX Runtime y llama.cpp?

Si la respuesta es "un SDK propietario que solo corre en una distro específica", la NPU seguirá siendo una calcomanía en la caja. Si es "driver upstream más backend en ONNX Runtime", ahí cambia el juego para la IA local en Linux.

Mi opinión firme: una NPU sin soporte en los runtimes populares no vale nada para quien desarrolla. Nadie va a reescribir su pipeline de inferencia para el SDK de un solo fabricante. La prueba real es si un pip install o un bun add de una librería común puede usar la NPU sin ceremonia.

Qué cambia en tu flujo de trabajo

Suponiendo que el soporte llegue bien pulido, algunas cosas se vuelven más simples en el día a día.

Docker sin emulación. Construyes y corres imágenes arm64 de forma nativa. Para publicar en las dos arquitecturas, el flujo sigue igual, solo que ahora la emulada es la x86:

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

Dependencias nativas expuestas temprano. Si una librería de tu package.json no tiene binario para linux-arm64, lo descubres en tu máquina, no en el pipeline de deploy. Cosas como sharp, bcrypt o drivers de base de datos con binding nativo ya tienen build ARM hace tiempo, pero siempre hay alguna dependencia olvidada en el fondo de node_modules.

Runtime JavaScript sin drama. Node y Bun tienen build oficial para linux-arm64. React Native es un caso aparte: el emulador de Android en ARM incluso se vuelve más liviano, porque la imagen del sistema también es ARM. El build de iOS, en cambio, sigue exigiendo una Mac, y eso ningún chip de Qualcomm lo va a resolver.

IA local en el editor. Con un modelo corriendo en local, puedes apuntar tu editor a un endpoint en tu propia máquina:

const res = await fetch('http://localhost:11434/api/generate', {
  method: 'POST',
  body: JSON.stringify({
    model: 'qwen2.5-coder:7b',
    prompt: 'Explica esta query SQL: SELECT ...',
    stream: false,
  }),
})
const { response } = await res.json()

El código privado de la empresa no sale de la laptop. Para mucha gente, esa es la diferencia entre poder o no usar IA en el trabajo.

¿Vale la pena comprar una laptop con X2 para correr Linux?

Todavía no. Al menos no el día del lanzamiento.

Un anuncio de soporte es una intención. Lo que importa es el estado del kernel en la laptop específica que quieres comprar. La primera generación enseñó que "el SoC tiene soporte" y "tu modelo funciona" son frases muy distintas.

Antes de gastar, yo revisaría:

• Si el modelo tiene device tree en el kernel mainline, no solo en un fork del fabricante.
• Si suspender y despertar funciona, y cuánta batería pierde mientras duerme.
• Si la GPU tiene aceleración con driver abierto (Freedreno, en Mesa, cubre Adreno).
• Si la NPU es accesible desde algún runtime común o solo desde un SDK propietario.
• Si hay reportes de usuarios reales usándola en el día a día, no solo un video de arranque.

Si tres de esas cinco están en verde, ya se puede pensar. Si solo arranca, es un juguete caro.

Y va el chiste inevitable: el "año de Linux en el escritorio" ahora viene con NPU. Al menos esta vez hay un fabricante de chips firmando abajo.

Mi lectura

Me gusta el anuncio. Qualcomm por fin entendió que quienes desarrollan son justo el público que compra laptops potentes, quiere buena batería y usa Linux. Ignorar a ese grupo en la primera generación fue un error, y corregirlo es una buena noticia para todo el ecosistema ARM.

Pero yo juzgo por el kernel, no por el escenario. Si en seis meses las principales laptops X2 están en mainline y la NPU funciona con ONNX Runtime o llama.cpp, ARM con Linux se vuelve una opción seria como máquina de desarrollo. Hasta entonces, es una promesa interesante que vale la pena seguir.

Sigo probando IA local en mis propios proyectos, y algunos están aquí en el portafolio.

Laptop ARM con Linux de verdad: Qualcomm prometió dar soporte de primera clase al Snapdragon X2.

Quien intentó instalar una distro en el X Elite lo recuerda bien: suspensión rota, webcam muda y NPU inaccesible fuera de Windows.

Casi todo lo que escribimos corre en Linux, y cada vez más en ARM. Desarrollar en la misma arquitectura que producción elimina una categoría entera de bugs.

Pero una NPU que no funciona con ONNX Runtime o llama.cpp no vale nada para quien programa. Nadie va a reescribir su pipeline para el SDK de un solo fabricante.

Yo juzgo por el kernel, no por el escenario. Antes de comprar, revisa si tu modelo está en mainline.

Escribí en el blog qué cambia en el flujo de trabajo y el checklist completo. ¿Cambiarías tu laptop por un X2 con Linux?

#Linux #ARM #Snapdragon #DevLife #IALocal