Errores que un laboratorio de IA local debe evitar
Guía práctica para no llenar el disco, agotar la memoria, medir con temperatura inestable, exponer APIs o confiar en un backup que nunca se restauró.

La IA local no suele romperse por una sola gran catástrofe. Se rompe por supuestos pequeños: una descarga sin espacio, un contexto que nadie ha calculado, un endpoint abierto o un benchmark sin condiciones. Esta es la lista que usamos como revisión antes de llamar «resultado» a algo.
1. Descargar sin mirar el disco
Los pesos, los archivos temporales y las conversiones pueden necesitar bastante más espacio
que el archivo final. Antes de empezar, revisa df -h, calcula un margen y decide qué
artefactos son recuperables. Si una descarga falla, elimina solo los temporales identificados.
Regla: no empieces una descarga grande sin espacio para terminarla y hacer rollback.
2. Reservar un contexto enorme porque existe
La KV cache crece con el contexto y la concurrencia. Un límite anunciado por el modelo no significa que tu máquina pueda usarlo con comodidad.
Regla: empieza con el contexto de tu tarea real, mide memoria y sube gradualmente. Si aparece swap, detén la prueba y registra la condición.
3. Cerrar una sesión SSH sin una ruta de recuperación
Desactivar contraseñas es una buena práctica solo después de verificar una clave de repuesto,
la configuración efectiva y un acceso local. Revisa los ficheros de
sshd_config.d/, authorized_keys y los logs antes de tocar el servicio.
Regla: prueba una segunda conexión antes de cerrar la primera.
4. Confundir calentamiento con rendimiento
Un modelo puede rendir distinto en frío, después de varias peticiones o cuando el sistema entra en throttling. Un número sin temperatura, memoria, potencia, versión y carga no es comparable.
Regla: fija un periodo de calentamiento, repite la medida y guarda las condiciones junto al resultado.
5. Elegir por un benchmark que no habla tu idioma
Los exámenes generales sirven como filtro, no como veredicto para reuniones, contratos o soporte en español. Prepara prompts reales, criterios de corrección y ejemplos de respuesta aceptable antes de adoptar un modelo.
Regla: incluye tareas en español y comprueba nombres propios, cifras, formato y alucinaciones.
6. Tener un backup que nunca se restauró
Un backup puede existir y seguir siendo inútil. Programa una restauración de prueba en un entorno aislado, verifica la base de datos, los ficheros y los permisos, y documenta cuánto tiempo tardó.
Regla: una copia no se considera fiable hasta que una restauración reciente funciona.
La moraleja
Todos estos errores comparten patrón: asumir que las cosas funcionaban como imaginábamos sin verificar. Por eso las recetas y los benchmarks de En Local separan medido, derivado y pendiente. La evidencia no tiene que ser espectacular; tiene que poder repetirse.
Los errores concretos que hemos cometido nosotros, con su causa y cómo evitarlos, están en Trampas. Y si tienes un fallo que merezca entrar, escríbenos.