Los errores del Laboratorio, Vol. 1: todo lo que rompimos aprendiendo IA local
Compilación honesta (y con humor) de nuestros mejores fracasos: discos llenos, contextos imposibles, SSH imposible, modelos que no arrancaban y noches largas. Para que tú no los repitas.
Prometimos contar también los fracasos. Este post es el primero de la serie “Los errores del Laboratorio”: una colección de momentos en los que las máquinas ganaron. Que sirva de vacuna.
1. El disco lleno a las 2AM (91% y subiendo)
Qué pasó: descargamos un modelo de 97GB sin mirar el disco. A mitad de descarga, el sistema empezó a comportarse como si estuviera borracho.
Qué aprendimos: los archivos .part y las descargas de HuggingFace duplican espacio
temporalmente. Ahora: df -h antes de CUALQUIER descarga, y limpieza automática semanal
de cachés (con cron, no con fe).
La frase: “¿Por qué ncdu no era parte del setup desde el día 1?”
2. El contexto de 256K “porque podíamos”
Qué pasó: configuramos un modelo con 256K de contexto máximo en una máquina con 121GB. El KV cache se comió 40GB+ antes de la primera conversación real. El escritorio empezó a hacer swap y todo fue a cámara lenta.
Qué aprendimos: el contexto no es gratis — es memoria RAM/VRAM reservada. Ahora configuramos el contexto que REALMENTE usamos (32-64K) y el KV cache cuantizado (q8_0).
La regla: contexto máximo usado en el último mes + margen del 50%. Nada más.
3. El SSH imposible (la saga completa)
Qué pasó: un servidor con PasswordAuthentication no que no recordábamos haber
configurado, claves en authorized_keys que no correspondían con las que ofrecíamos, y
tres máquinas (server + 2 sparks) donde cada una confiaba en claves distintas. Horas de
“Permission denied (publickey)”.
Qué aprendimos:
sshd_config.d/*.confSOBREESCRIBE lo que pongas ensshd_config. Míralo siempre.- Un solo fichero
known_hostsy un~/.ssh/configbien mantenido valen oro. - La solución siempre estuvo en los logs:
journalctl -u sshdecía exactamente qué fallaba. Leerlos a tiempo = 3 horas ahorradas.
La frase: “El error no está en tu clave. Está en tu config.d.”
4. El benchmark que derretía la Spark
Qué pasó: probando un modelo grande en agosto, con 30°C ambiente, el benchmark de inferencia disparó las temperaturas hasta el throttling silencioso. Resultados 30% peores sin ningún mensaje de error. Casi sacamos conclusiones erróneas del hardware.
Qué aprendimos: monitorizar SIEMPRE temperaturas durante cualquier medición
(nvtop, sensors). Y los benchmarks serios se hacen con refrigeración decente, no con
un ventilador de sobremesa apuntando con cariño.
5. El modelo que no hablaba español
Qué pasó: un modelo top del benchmark global, desplegado con ilusión para ser “nuestro asistente familiar”… que respondía en español con construcciones tan raras que parecía traducción automática de los 90.
Qué aprendimos: los benchmarks globales no miden calidad de idioma. Para tareas en español: probar SIEMPRE con prompts reales en español antes de adoptar un modelo. Algunos modelos “top” son mediocres en español; algunos discretos son excelentes.
La consecuencia: nuestro mini-benchmark casero incluye 3 prompts exclusivamente en español coloquial. Es el filtro más valioso que tenemos.
6. El backup que nunca se probó
Qué pasó: teníamos backup automático del servidor. Lo que no teníamos era UNA PRUEBA de restauración. Cuando tocó restaurar… el backup existía, estaba incompleto, y faltaba la base de datos.
Qué aprendimos: un backup sin restauración probada no es un backup, es un deseo. Mensualmente: restaurar a un contenedor limpio y verificar.
La moraleja del Laboratorio
Todos estos errores comparten patrón: asumimos que las cosas funcionaban como imaginábamos sin verificar. La IA local es maravillosa pero no perdona los supuestos.
Por eso todas nuestras recetas incluyen la sección “errores de novatos”: son estos, y son reales. Que te sirvan. 🫡
¿Tienes un error glorioso que contar? Escríbenos y lo publicamos (con cariño).