¿Por qué es tan lento un LLM local con i7 y 32 GB de RAM y sin GPU?

Instalas Ollama, ejecutas ollama run qwen2:7b en un portátil con un Intel i7 y 32 GB de RAM y lo conectas a un plugin de VS Code. Las primeras respuestas tardan segundos. Mandas una consulta más compleja y la interfaz se congela. El modelo de "menos parámetros" es el único que responde con algo de fluidez, pero la calidad ya no convence.

Esto no es un bug ni un problema de configuración. Es una consecuencia directa de cómo funcionan las inferencias de los LLMs a nivel de hardware.

Un LLM durante la inferencia necesita multiplicar matrices enormes: los pesos del modelo por los vectores de activación de cada token. Una GPU de gama media puede hacer decenas de miles de estas operaciones en paralelo. Una CPU de 8 núcleos hace las mismas operaciones de forma secuencial — el resultado es entre 10x y 50x más lento.

El segundo problema es el ancho de banda de memoria. Las GPUs tienen VRAM con bandwidths de 400-1000 GB/s. La RAM del sistema tiene un bandwidth de ~50 GB/s. Los pesos del modelo (que se leen en cada token generado) no caben en la caché de la CPU, lo que fuerza lecturas constantes desde RAM — un cuello de botella de bandwidth, no de compute.

Los M-series de Apple tienen una ventaja estructural: la memoria unificada (no hay VRAM separada) y el Neural Engine permiten correr modelos medianos con un throughput muy superior al de un Intel i7 con RAM convencional.

Correr el modelo es el primer paso. Para que sea útil en desarrollo asistido, el LLM necesita acceder al repositorio, entender la estructura de archivos, respetar las convenciones del proyecto. Un plugin de VS Code conectado a Ollama solo transmite el texto seleccionado — no pasa el contexto del repositorio.

Construir ese andamiaje (lecturas de archivos, memoria de sesión, reglas de proyecto) sobre un modelo local requiere un esfuerzo de integración que multiplica el setup inicial. Para la mayoría de equipos, ese tiempo de ingeniería excede el ahorro en tokens durante meses.