Un modelo de 72B en un MacBook M2 Pro dio 1–2 tokens por segundo y sobrecalentó el portátil

Una historia típica: lees un par de artículos, escribes ollama pull en la terminal y de pronto tienes "tu propio agente de IA que conoce todo el código". El ingeniero de QA Egor Laptev, de SENSE, probó este escenario en un MacBook Pro M2 Pro con 32 GB de memoria y obtuvo una lección de manual sobre lo que no se cuenta en los tutoriales.

Qué salió mal

Tomó Qwen Coder 72B y la comprimió a Q2_K, unos 26 GB. Técnicamente, el modelo cabía en 32 GB. En la práctica, Ollama se quedó con casi toda la memoria, macOS entró en swap intensivo, el SSD empezó a zumbar y el procesador y la GPU estaban al 100%. Como Apple Silicon tiene memoria unificada, la carga recae sobre todo el sistema a la vez. El navegador iba con retraso, el IDE se congelaba y a los pocos minutos se activó el thermal throttling.

Limitar la memoria no salvó la situación. Los consejos habituales sobre 4 GB no funcionan: 26 GB no caben en ellos y Ollama simplemente devuelve un error. Tuvo que subir el límite a 28 GB. El modelo funcionó, pero a 1–2 tokens por segundo. Una consulta simple como "escribe un parser de JSON" se espera uno o dos minutos. La temperatura bajó de más de 95 °C a 85–90 °C; el portátil resultó utilizable para trabajar, pero no cómodo.

Hay también un coste oculto. El swap constante desgasta el SSD, así que este tipo de experimento no conviene mantenerlo durante horas. El propio autor, no obstante, informa de que el portátil está intacto: el throttling fue una reacción protectora, no una avería.

El sobremesa ayudó, pero no gratis

En un PC con RTX 4070 Ti Super (16 GB de VRAM), 32 GB de DDR5 e i5-13600KF, el mismo modelo daba 5–8 tokens por segundo. La respuesta a una consulta simple tardaba 10–20 segundos. Parte de los pesos seguía en la RAM del sistema, y se notaba. El principal inconveniente es que, mientras trabaja el agente, la tarjeta gráfica está ocupada al 80–90%. Solo se puede jugar o editar vídeo tras detener el agente.

RAG: ahí es donde sube la cuenta

Un modelo sin contexto aún no es un agente. Para que conozca el código, la documentación y los tickets hace falta RAG: base de datos vectorial, embeddings, búsqueda. El autor estimó los volúmenes. Un proyecto personal de 14 mil chunks ocupa unos 200 MB. La documentación interna de 1,4 millones de chunks, unos 20 GB. Un dominio completo de 14 millones de chunks llegaría a 200 GB. Al índice HNSW se suma un 30–50% de sobrecarga. Y si además se hace fine-tuning del modelo, los estados del optimizador multiplican la memoria aproximadamente por 3–4.

Balance de hardware: una estación de trabajo con RTX 4090 o A5000, 64 GB de RAM y 4 TB de SSD costará unos $6500. La electricidad añadirá $100–180 al año. Lo más caro, sin embargo, es que un dispositivo personal se convierte en servidor.

Qué hacer al respecto

La conclusión del autor es bastante sensata. En local conviene mantener modelos de 7B–14B en Q4_K_M o Q8: según su estimación, es cerca del 90% de la calidad con un tercio de los recursos. Sirven para tareas rápidas y para código privado. El razonamiento pesado, el RAG de cientos de gigabytes y el fine-tuning es mejor llevarlos a la nube o a un clúster de GPU.

También conviene señalar las limitaciones. Es una experiencia aislada en un hardware concreto, no un benchmark. Q2_K se eligió deliberadamente como prueba de estrés, y el propio autor reconoce que la calidad de ese modelo es baja. Las cifras de almacenamiento y coste son orientativas.

La lección práctica es sencilla: antes de meter un 72B en un portátil, calcula la memoria para los pesos, el contexto y el índice. Si falta en aunque sea uno de los puntos, usa un modelo más pequeño o la nube. Y no te fíes de los tutoriales que prometen que "todo es sencillo".