Mi GPU sudaba inferencia: monté una NPU y esto pasó

La noche que mi GPU pidió auxilio (y una NPU le dio la réplica)

Te voy a contar una historia real. Bueno, real como la vida misma de cualquier dev que un día decide que quiere ejecutar sus modelos de IA en local, sin depender de APIs ajenas, sin pagar por token, sin que un servidor en Virginia se entere de lo que escribo.

Empieza mal. Empieza, como casi todo, con una factura de la luz.

Yo tenía una torre decente. CPU de gama alta, 32 GB de RAM, una GPU con más VRAM que mi nevera de litros. Todo iba bien hasta que empecé a jugar con modelos de lenguaje medianos en local. Y ahí descubrí tres verdades incómodas:

• Primera: la GPU, cuando le metes inferencia sostenida, se convierte en una estufa con ventiladores.
• Segunda: el consumo se dispara como si estuvieras minando cripto de 2017.
• Tercera: la latencia no era mala, pero el ventilador sonaba como si la torre estuviera a punto de despegar hacia Marte.

Así que me puse a investigar. Y me topé con una palabra que hasta hace poco sonaba a marketing: NPU. Unidad de Procesamiento Neuronal. Un chip diseñado específicamente para hacer lo que una GPU hace por accidente: multiplicar matrices con eficiencia brutal.

La pregunta era sencilla: ¿puedo montarme una estación de trabajo con una NPU dedicada y olvidarme del ruido, del calor y del susto en la factura?

La respuesta, spoiler: sí. Pero el camino tiene más curvas que un circuito de montaña.

Paso 1: entender qué demonios es una NPU (sin dormirte)

Imagina que tu CPU es un todoterreno. Sabe hacer de todo: llevar la contabilidad, mover cajas, cambiar una rueda. La GPU es un camión de mudanzas: mucha capacidad de carga en paralelo, pero traga gasolina como si no hubiera mañana.

La NPU, en cambio, es una cinta transportadora especializada. No sabe hacer de todo. Pero lo que hace —operaciones tensoriales, cuantización, inferencia de redes neuronales— lo hace con una eficiencia que da risa.

No es magia. Es diseño. Menos flexibilidad, más rendimiento por vatio.

Y ahí está la clave del asunto: rendimiento por vatio. Porque una NPU no compite con una GPU en potencia bruta. Compite en hacer lo mismo gastando una fracción de la energía y generando una fracción del calor.

Paso 2: elegir el hardware sin arruinarme (del todo)

Aquí viene la parte donde uno se da cuenta de que el mercado está fragmentado como un cristal roto.

Hay NPUs integradas en procesadores de portátiles modernos. Hay NPUs dedicadas en tarjetas de expansión. Hay aceleradores externos que se conectan por USB o por ranura de alta velocidad. Y hay, cómo no, ecosistemas cerrados que solo funcionan con su framework propietario.

Mi criterio fue claro desde el principio:

• Compatibilidad con frameworks abiertos. Si solo funciona con un runtime exclusivo, paso.
• Soporte para cuantización en 8 y 4 bits. Sin eso, no cabe nada en memoria.
• Drivers decentes en Linux. Porque sí, uso Linux. Y me gusta dormir.
• Consumo contenido. Si necesita una fuente de 1000 W, no es una NPU, es un horno.

Tras semanas de leer benchmarks, foros y algún que otro hilo lleno de gente discutiendo como si les fuera la vida en ello, me decidí por una configuración híbrida: CPU potente para orquestar, NPU dedicada para inferencia, y la GPU relegada a tareas puntuales donde realmente aporta.

La torre quedó silenciosa. Casi sospechosamente silenciosa.

Paso 3: el despliegue (o cómo aprendí a amar los drivers)

Aquí es donde la historia se pone interesante. Porque montar el hardware es la parte fácil. Lo difícil es que el software se entere de que existe.

1. El primer obstáculo: el runtime de inferencia. Quería algo que hablara con la NPU sin obligarme a reescribir mis modelos. La solución pasó por un runtime que soporta múltiples backends y permite delegar capas específicas al acelerador.
2. El segundo obstáculo: los drivers. Siempre los drivers. Instalé, reinicié, comprobé, maldije, volví a instalar. La NPU aparecía en el sistema, pero el framework no la veía. Resultó ser una versión de kernel demasiado nueva para el módulo. Bajé una versión, recompilé, y por fin: la NPU apareció como dispositivo disponible.
3. El tercer obstáculo: la cuantización. Mis modelos originales en precisión completa no cabían con holgura. Los convertí a 8 bits. La calidad apenas se resintió. Los convertí a 4 bits. Ahí ya se notaba, pero seguía siendo usable para muchas tareas.

Y entonces llegó el momento de la verdad: ejecutar el modelo y medir.

Paso 4: la medición (donde la realidad te da una bofetada cariñosa)

Monté un pequeño banco de pruebas. Nada sofisticado: un script que lanza prompts de longitud variable, mide el tiempo hasta el primer token (TTFT), la latencia por token, y la latencia total. Repetí cada prueba varias veces para tener percentiles.

Los resultados fueron... interesantes.

• CPU sola: funcionaba. Lento, pero funcionaba. TTFT alto, latencia por token aceptable en modelos pequeños, insufrible en modelos medianos.
• GPU: rápida. Muy rápida. Pero el consumo se disparaba y el ventilador entraba en modo turbina.
• NPU: aquí viene lo bueno. El TTFT no era el mejor de los tres. La latencia por token tampoco ganaba por goleada. Pero el consumo era ridículamente bajo. Y la latencia era consistente. Sin picos. Sin throttling. Sin sustos.

En cargas sostenidas, la NPU ganaba por cansancio del rival. La GPU empezaba fuerte y luego se ahogaba. La NPU empezaba moderada y se mantenía igual durante horas.

Y eso, para un dev que quiere tener un asistente local siempre disponible, vale más que un benchmark espectacular.

Paso 5: las lecciones (o lo que aprendí a golpes)

• Primera lección: la NPU no sustituye a la GPU, la complementa. Si haces entrenamiento, necesitas GPU. Si haces inferencia sostenida, la NPU es tu amiga.
• Segunda lección: el ecosistema importa más que el papel. Un chip con números espectaculares pero drivers lamentables es un pisapapeles caro. Antes de comprar, mira si tu framework favorito lo soporta.
• Tercera lección: la cuantización no es opcional. Es la diferencia entre que quepa o no quepa, entre que vaya fluido o vaya a tirones.
• Cuarta lección: mide siempre en tu carga real. Los benchmarks de laboratorio con prompts de tres palabras no te dicen nada. Lanza tus prompts, los largos, los feos, los que usas de verdad.
• Quinta lección, y la más importante: el silencio también es un feature. Poder trabajar con un modelo de lenguaje corriendo en local sin que parezca que tienes un secador industrial en el escritorio cambia por completo la experiencia.

Reflexión final: el futuro es híbrido (y silencioso)

Montar una estación de trabajo con NPU dedicada no es la solución definitiva a todos los problemas. No es barato. No es plug-and-play. Y el ecosistema todavía está madurando, con frameworks que van y vienen y drivers que a veces parecen escritos por alguien con prisa.

Pero hay algo profundamente satisfactorio en tener un modelo de IA corriendo en tu propia máquina, sin depender de nadie, sin enviar tus datos a ningún sitio, y sin que la factura de la luz te haga llorar a final de mes.

La NPU no es el futuro porque sea más rápida. Es el futuro porque es sostenible. Porque permite que la IA local deje de ser un experimento de fin de semana y se convierta en una herramienta de trabajo real.

Y eso, para quienes llevamos años peleándonos con GPUs que parecen calefactores