Durante un par de años, la sigla NPU fue sobre todo una etiqueta en cajas de portátil y una casilla marcada en la especificación del procesador. En 2025 eso ha cambiado lo suficiente como para que merezca la pena hacer una revisión honesta: qué hardware hay disponible, qué herramientas permiten aprovecharlo desde código real, qué tipo de cargas compensan y cuáles siguen siendo mejor en CPU o GPU. El panorama no es uniforme ni está terminado, pero hay lo bastante para que un desarrollador pueda decidir con criterio si dedicar tiempo a integrar una NPU en un producto concreto.
Qué hay en el mercado
Las tres familias dominantes en portátiles son Qualcomm Snapdragon X (Elite y Plus), Apple Silicon de M1 en adelante y AMD Ryzen AI 300 con XDNA. Intel entró más tarde con los Core Ultra Meteor Lake y Lunar Lake, que incluyen su propia NPU pero con un ecosistema de software menos rodado. Las cifras que venden los fabricantes giran en torno a TOPS, operaciones por segundo a baja precisión, y llegan a 45 en Snapdragon X Elite, 38 en Apple M4, 50 en Ryzen AI 300 y 48 en Lunar Lake.
Los TOPS son un número fácil de comparar pero engañoso. Lo que importa en la práctica es la combinación de capacidad bruta, precisión soportada, ancho de banda de memoria y la pila de software disponible para llegar al silicio. Un chip con 45 TOPS teóricos y herramientas inmaduras entrega menos inferencia real que uno con 30 TOPS y una cadena de herramientas pulida. En servidores y estaciones de trabajo también hay NPU en algunos sistemas, pero el foco natural de la conversación en 2025 es el portátil, porque es donde el caso de uso está claro y donde se notan los límites térmicos y de batería.
La cadena de herramientas: ONNX Runtime como denominador común
El elemento que ha hecho realista hablar de NPU para desarrolladores es ONNX Runtime con sus proveedores de ejecución específicos por fabricante. Para Qualcomm existe QNN EP; para Apple, CoreML EP; para AMD, el Vitis AI EP; para Intel, el OpenVINO EP. Todos siguen el mismo patrón: tomar un modelo en formato ONNX y dispatchar parte del grafo a la NPU, dejando el resto en CPU o GPU. El soporte no es uniforme y hay operadores que no se traducen, pero para los modelos más habituales de visión y de procesado de lenguaje la cobertura es suficiente.
Cada fabricante tiene también su cadena propia. Apple ofrece Core ML con su compilador coremltools que convierte modelos desde PyTorch o ONNX y genera paquetes nativos. AMD tiene Ryzen AI Software con un flujo basado en Vitis AI que compila modelos cuantizados a INT8. Qualcomm proporciona el AI Engine Direct SDK con utilidades de conversión a su formato binario QNN. Intel empuja OpenVINO, que además de su NPU soporta CPU y GPU integrada con la misma API.
La decisión práctica para un desarrollador que quiera cubrir varias plataformas es empezar con ONNX Runtime. Un modelo bien exportado a ONNX puede correr en CPU, GPU y las cuatro NPU principales con cambios mínimos en el código de inferencia. La cuantización a INT8 o incluso a precisiones menores es casi siempre necesaria: la mayoría de NPU están pensadas para enteros y sacar partido pleno exige reducir la precisión del modelo en la fase de exportación, no al cargarlo.
Qué se puede hacer hoy
El caso de uso mejor resuelto hoy es la inferencia de modelos de visión ligeros. Detección de objetos, clasificación de imágenes, segmentación, reconocimiento facial, todo eso corre bien en cualquier NPU actual con latencias de decenas de milisegundos y consumo significativamente menor que en la GPU integrada. Para aplicaciones de escritorio que procesan vídeo de cámara en tiempo real o analizan imágenes de usuario, la NPU es hoy la opción natural.
El segundo caso maduro es la transcripción de audio. Whisper en sus variantes pequeñas y medianas corre razonablemente bien en NPU tras la cuantización adecuada, y aplicaciones como subtítulos automáticos o notas de voz se benefician mucho del coste energético reducido frente a ejecutar el modelo en CPU o GPU. Apple tiene soporte muy pulido de Whisper en el Neural Engine a través de Core ML; los demás fabricantes han ido llegando durante 2025 con niveles variables de calidad.
El tercer caso, más reciente y más ambicioso, son los modelos de lenguaje pequeños. Phi-3 Mini, Llama 3.2 1B y 3B, Qwen 2.5 de pocos miles de millones de parámetros y variantes cuantizadas a INT4 ya corren en las NPU actuales con un tokens por segundo que empieza a ser útil para resúmenes, corrección de texto o asistentes locales. No es el terreno donde una NPU de portátil compite con GPU de datacenter; es el terreno donde compite con ejecutar el mismo modelo en CPU, y ahí la NPU suele ganar claramente tanto en latencia como en energía.
El cuarto, ya más especulativo, son los modelos generativos de imagen pequeños. Stable Diffusion en sus variantes destiladas, como los modelos Turbo o Lightning, funciona en NPU decentes con tiempos de generación de pocos segundos por imagen en tamaños moderados. La calidad no iguala a una GPU dedicada, pero para uso personal o integrado en aplicaciones la relación calidad coste energético empieza a ser interesante.
Dónde no compensa todavía
No todo es terreno favorable. Los modelos grandes siguen siendo de GPU o CPU con memoria abundante. Un modelo de 13 mil millones de parámetros no cabe en la memoria accesible para la NPU de un portátil, o cabe muy cuantizado con calidad degradada, y la GPU integrada con acceso a memoria unificada suele ganar el pulso. Lo mismo aplica a modelos de difusión grandes, a tareas de entrenamiento (ninguna NPU de consumo entrena hoy, son todas de inferencia) y a cargas con control de flujo complejo que no se compila bien al grafo estático que la NPU espera.
Tampoco compensa cuando la inferencia se hace en servidor y el cliente solo hace petición HTTP. Ahí el hardware del cliente es irrelevante y la pregunta no existe. El terreno de la NPU es la inferencia local, y si tu arquitectura no contempla ejecución local, la NPU es un no-problema.
Un detalle que sorprende a quien se acerca por primera vez es que ejecutar un modelo en NPU suele ser más lento que en GPU integrada para el primer arranque, porque hay coste de carga y compilación. El beneficio aparece en ejecuciones sucesivas o en escenarios de larga duración, donde la eficiencia energética compensa la latencia inicial. Esto hay que tenerlo en cuenta al diseñar la experiencia de la aplicación.
Ejemplo mínimo con ONNX Runtime
Para un desarrollador que quiera probar hoy, el camino corto es exportar un modelo a ONNX desde PyTorch, cuantizarlo y cargarlo con el proveedor de ejecución correspondiente. El código desde Python se parece bastante entre plataformas una vez tienes el entorno listo:
import onnxruntime as ort
import numpy as np
# En un portátil Snapdragon X Elite
providers = [
("QNNExecutionProvider", {"backend_path": "QnnHtp.dll"}),
"CPUExecutionProvider",
]
session = ort.InferenceSession("modelo_cuantizado.onnx", providers=providers)
entrada = np.random.randn(1, 3, 224, 224).astype(np.float32)
salida = session.run(None, {"input": entrada})En Apple se cambia el proveedor a CoreMLExecutionProvider, en AMD a VitisAIExecutionProvider, en Intel a OpenVINOExecutionProvider. La idea es que el mismo modelo y casi el mismo código corran en las cuatro, y que si algo falla en la NPU el runtime caiga a CPU automáticamente. La realidad tiene más aristas, pero la abstracción es útil como punto de partida.
Mi lectura
Después de seguir el área durante dos años, creo que las NPU de portátil son hoy una herramienta real pero no una solución mágica. Para casos concretos, visión ligera, audio, modelos de lenguaje pequeños, compensan claramente en latencia y en energía. Para casos grandes, no. La cadena de herramientas ha madurado lo bastante como para que un desarrollador con experiencia en inferencia pueda integrar una NPU en un producto en semanas, no en meses, siempre que acepte las limitaciones de la cuantización y dedique tiempo a las particularidades del fabricante objetivo.
El punto ciego más frecuente que veo en equipos es asumir que los números de TOPS se traducen directamente en rendimiento. No lo hacen. Lo que se traduce en rendimiento es la coincidencia entre el modelo, la cuantización, el grafo de operadores soportado y el ancho de banda de memoria disponible. Un equipo que mide en su propio caso de uso, en el hardware objetivo y con datos reales descubre rápidamente cuál de las cuatro plataformas le conviene y, sobre todo, si la NPU le conviene frente a la GPU integrada, que en muchos casos sigue siendo más predecible y más flexible.
La dirección del viaje, sin embargo, es clara: cada generación de portátil reduce el coste de inferencia local, los modelos pequeños ganan capacidad y la NPU se consolida como el sitio natural para ejecutarlos. Apuntar ahí en 2026 es una apuesta razonable para productos que quieran funcionar sin conexión o con baja latencia percibida. Lo que era marketing se está volviendo infraestructura; toca aprender a usarla.
