2026 es distinto: la IA local ya viene de serie, pero no todo acelera lo mismo

En 2026, los principales sistemas operativos traen funciones de IA en el propio dispositivo y muchas apps ya recurren a aceleración heterogénea. En Windows 11, características como Recall y Windows Studio Effects se apoyan en la NPU para descargar trabajo de CPU y GPU, con umbrales mínimos de rendimiento claramente definidos. En macOS, Apple Silicon integra CPU, GPU, un Neural Engine y memoria unificada que favorecen cargas mixtas. En Linux, la madurez de CUDA/ROCm y las rutas de Vulkan siguen marcando el ritmo para creadores y desarrolladores.

La consecuencia práctica: no existe una única "especificación IA". Un portátil rápido en edición de vídeo con efectos de cámara en tiempo real puede no ser el mejor para inferir un LLLM grande o para generar imágenes por lotes. Esta guía descompone, con criterios verificables, qué hace cada acelerador, cuánta memoria necesita realmente un 7B/13B/70B con distintas cuantizaciones, y cómo aterrizarlo en decisiones de compra realistas para los próximos 3–6 meses. Además, clarifica qué significan las métricas habituales (TOPS, tokens/seg, latencias) y cómo relacionarlas con tus flujos de trabajo sin caer en comparativas poco útiles entre equipos de distinta arquitectura.

CPU, GPU y NPU: quién hace qué y con qué API se programa

- CPU: orquesta, pre/post‑proceso y por sí sola sirve para modelos pequeños o tooling (tokenización, E/S). Cuando la librería no tiene backend acelerado, la CPU es el salvavidas universal. La métrica útil es el rendimiento por hilo en tareas de punto flotante y la disponibilidad de instrucciones vectoriales; el escalado más allá de 8–10 hilos pierde eficiencia para LLMs por cuellos de memoria. También es relevante la latencia de acceso a memoria y el ancho de banda sostenido, porque el prefill y la actualización de la caché KV son sensibles a estas rutas incluso cuando parte del cómputo vive en un acelerador.

- GPU: domina en tensores grandes y lotes; es la vía principal para LLMs medianos y generación de imagen. En Windows, el camino "agnóstico" pasa por Windows ML con ONNX Runtime y su política de selección de proveedores de ejecución; en NVIDIA, CUDA sigue siendo la ruta más madura; en AMD, ROCm habilita kernels HIP. Vulkan y WebGPU empujan la portabilidad de cómputo, sobre todo en apps y navegadores modernos. En la práctica, las GPUs ofrecen mejor throughput cuando puedes agrupar peticiones (batching) o cuando la aplicación encadena varias etapas tensoriales con operadores bien soportados en el backend elegido.

- NPU: acelera inferencia de baja latencia y consumo en modelos optimizados (visión, efectos de cámara, asistentes del SO, algunas partes de LLMs compactos). En Windows, ciertas experiencias del sistema requieren un umbral de ~40 TOPS en la NPU. En macOS, el Neural Engine convive con GPU/Metal y la conversión a Core ML decide qué cae en ANE y qué en GPU. La clave con la NPU es que el path de ejecución esté preparado para aprovecharla; sin esa ruta, el trabajo volverá a GPU o CPU aunque el dispositivo tenga NPU disponible.

Modelos y memoria: 7B/13B/70B en fp16, int8 y 4‑bit, y por qué la RAM/VRAM manda

La memoria necesaria se descompone en dos piezas: pesos del modelo y caché KV. Como regla rápida, los pesos ocupan ~bytes_por_parámetro×n_parámetros: fp16/bf16 ≈ 2 B/param, int8 ≈ 1 B/param, y 4‑bit ≈ 0,5 B/param. Así, un 7B en fp16 ronda ~14 GB solo en pesos; el mismo 7B cuantizado a 4‑bit baja a ~3–4 GB, sacrificando algo de calidad. La caché KV puede sumar varios GB en contextos largos o alta concurrencia, y a menudo es el factor que colapsa la VRAM/RAM antes que los pesos. La caché KV crece con la longitud de contexto efectiva y con la profundidad del modelo, por lo que conviene dimensionar pensando en tu uso típico (por ejemplo, cadenas de herramientas con contexto extendido frente a prompts cortos).

En práctica de escritorio, un 7B cuantizado cabrá y responderá fluido con 8–16 GB de memoria disponible para el proceso; un 13B exige 16–24 GB razonables para ir holgado; un 70B en 4‑bit ya pisa 40 GB solo en fichero de pesos y requiere sistemas con mucha memoria unificada o desbordar a RAM. Si tu GPU tiene VRAM limitada, mover la KV cache a la RAM del sistema o partir el modelo entre GPU y CPU/NPU puede mantener la sesión, pero sube la latencia. Asegúrate también de considerar el coste del loader y de las bibliotecas del runtime, que añaden unos cientos de MB adicionales y pueden marcar la diferencia cuando el presupuesto de VRAM está ajustado.

NPU en 2026: cómo leer TOPS y cuándo manda la GPU

Los TOPS son una medida de operaciones por segundo en enteros (típicamente int8/int4) bajo supuestos específicos del fabricante. Sirven para filtrar compatibilidad mínima del sistema y estimar clases de tareas en tiempo real (por ejemplo, efectos de cámara, traducción en vivo, pequeñas redes de visión), pero no reemplazan métricas de tarea como tokens/segundo o latencia P95 en tu modelo objetivo. En Windows, funciones del sistema como Recall y la gama alta de Studio Effects activan requisitos mínimos alrededor de 40 TOPS de NPU, además de memoria y seguridad del dispositivo. En la comparación entre equipos, interpreta los TOPS como un umbral de capacidad funcional, no como una escala lineal de rendimiento entre marcas o generaciones distintas.

Para LLMs medianos o imágenes por difusión con lotes, la GPU sigue liderando en throughput y en soporte de operadores. La NPU gana cuando la app está adaptada (vía Windows ML/ONNX Runtime con política de "prefer NPU" o en Core ML con capas compatibles) y cuando prima la autonomía: es habitual ver ahorro energético sustancial frente a GPU en tareas continuas de baja potencia, aunque con límites en operadores y tamaño de modelo. En escenarios mixtos, una estrategia eficaz es dejar el prefill pesado a la GPU y descargar al NPU procesos de visión o de post‑processing, manteniendo el consumo contenido sin penalizar en exceso la latencia percibida.

Windows, macOS y Linux: estado real de toolchains y compatibilidad

- Windows (ARM y x86): Windows ML ofrece una capa uniforme sobre ONNX Runtime y permite elegir proveedor de ejecución (CPU, NPU, GPU vía DirectML, CUDA, etc.) o dejar que una política lo seleccione por "máximo rendimiento" o "máxima eficiencia". DirectML se apoya en cualquier GPU compatible con DirectX 12, útil para hardware diverso y para despliegues que no dependen de un único vendedor. Para apps que ya usan ONNX Runtime, incorporar una política como MAX_EFFICIENCY o PREFER_NPU es una forma práctica de equilibrar rendimiento y autonomía sin reescribir operadores.

- macOS (Apple Silicon): el flujo recomendado es convertir a Core ML (con coremltools) y dejar que Metal/ANE ejecute según compatibilidad. La memoria unificada simplifica cargas mixtas (modelo en GPU, preprocesado en CPU/ANE) y en la generación M5 se ofrecen configuraciones de hasta 128 GB unificados y mayor ancho de banda, lo que ayuda a contextos largos de LLMs y lotes en creación de contenido. En proyectos que mezclan visión, audio y texto, esta unificación reduce copias entre dispositivos y puede traducirse en latencias más estables bajo carga.

- Linux: CUDA mantiene la vía más pulida en NVIDIA; ROCm habilita AMD recientes con una matriz de compatibilidad que conviene revisar antes de comprar. Para soluciones portables y entornos sin CUDA/ROCm, Vulkan ofrece cómputo general y algunos runtimes experimentan rutas vía SPIR‑V. En el ecosistema open‑source, proyectos como llama.cpp exponen múltiples backends (CPU/Metal/CUDA/ROCm/Vulkan) con distinta madurez. Antes de decidir plataforma, valida que el backend elegido soporte los operadores críticos de tu modelo y que tus dependencias (drivers, kernel, librerías) estén en versiones compatibles.

Almacenamiento, E/S y puertos: por qué 1–2 TB NVMe no es capricho

Los ficheros de modelos ocupan espacio tangible incluso cuantizados: un 7B ronda 3–4 GB; un 13B, ~7–8 GB; un 70B, ~35–40 GB en 4‑bit. Si planeas alternar familias (Llama, Mistral, embedding, TTS, VAD) y mantener varias cuantizaciones/versiones, 1–2 TB NVMe evita estar limpiando continuamente. La lectura secuencial de modelos grandes beneficia el arranque de sesión y la recarga tras suspensión; además, tener margen libre ayuda a paging y a caches del framework. Mantener un único volumen NVMe rápido simplifica la gestión de checkpoints y reduce la tentación de mover modelos a medios más lentos que luego penalizan el tiempo hasta primer token.

En conectividad, Thunderbolt 5 y USB4 v2.0 elevan el techo de ancho de banda para SSDs externos o eGPU (donde sea compatible), y para monitores 8K/altas tasas. Para cargas IA, su interés práctico es conectar almacenamiento rápido externo y compartir bus sin estrangular la GPU interna. Si trabajas con chasis externos o docks, confirma certificación y versión para evitar cuellos de botella. Y si tu flujo depende de mover modelos entre máquinas, considera un SSD externo NVMe en caja compatible con TB5/USB4 v2.0: la mejora en tiempos de copia y carga respecto a USB heredado es notable en proyectos con varios gigabytes.

Cómo medir rendimiento útil y traducirlo a perfiles de compra

Métricas que importan: 1) tokens/seg en tu modelo y cuantización objetivo con el contexto típico; 2) latencia del primer token (prefill) y de decodificación; 3) throughput por lote en generación de imagen/audio. Evita comparar TOPS brutos o FLOPS teóricos sin relación con tu pipeline (tokenizador, KV cache, streaming). Siempre que puedas, usa bancos reproducibles y de código abierto del propio runtime que piensas emplear. Complementa con pruebas de energía cuando la autonomía sea prioritaria: la diferencia entre NPU y GPU en cargas mantenidas puede ser decisiva aunque el tiempo total sea similar.

Perfiles mínimos orientativos, si compras en 2026 Q4–2027 Q1: 1) Chat local 7B (4‑bit), multitarea ligera: CPU moderna de 8 núcleos, GPU integrada o dGPU modesta, 16 GB RAM y NPU si dependes de funciones del SO; 2) Asistente de código y transcripción acelerados: dGPU con ≥8–12 GB VRAM o Apple Silicon con ≥24–32 GB unificada; 3) Generación de imagen estable por lotes y LLM 13B cómodo: dGPU ≥16 GB VRAM o memoria unificada ≥48–64 GB; 4) Laboratorio local con 70B 4‑bit: sistemas de ≥64–96 GB efectivos (unificada o suma RAM+desbordo), asumiendo compromisos en latencia. Como regla operativa, prioriza memoria suficiente antes que pequeñas diferencias de TOPS/FLOPS y valida que las APIs que planeas usar (Windows ML/DirectML, Core ML, CUDA/ROCm, Vulkan/WebGPU) funcionen con tu pila de software.