Montar un agente de IA en casa: lo que cuesta de verdad

Llevo meses con agentes de IA corriendo dentro de mi propia red: uno que gestiona tareas del día a día, otro que vigila servicios y otro que escribe documentación. Cuando cuento que “tengo agentes en casa”, la pregunta es siempre la misma: ¿y eso cuánto cuesta? La respuesta honesta es que depende de una cosa que casi nadie mide bien: qué modelo usas para cada tarea.

Lo primero: local no significa gratis

Hay una idea muy extendida de que si el modelo corre en tu máquina, el coste es cero. Es falso, solo se paga en otra moneda:

Hardware: un modelo de 7-8B en cuantización Q4 necesita unos 6 GB de VRAM libres para ir cómodo. En una GPU integrada, o tiras de CPU, o no cabe.
Energía y calor: una GPU al 100% durante horas se nota en la factura y en el ruido.
Tiempo: la primera respuesta de un modelo cargado en frío puede tardar 20 o 30 segundos. Eso mata cualquier flujo interactivo.

En mi caso, la conclusión fue clara: local para lo que se repite y no necesita cabeza, API para lo que sí. Un modelo pequeño local para clasificar, resumir o extraer campos; un modelo grande remoto para razonar, escribir o decidir.

La aritmética que de verdad importa

El error típico es mirar solo el precio por millón de tokens de entrada y salida. Lo que cambia la factura es el tamaño del contexto que arrastras en cada llamada. Si tu agente manda 12.000 tokens de historial en cada iteración de un bucle de 8 pasos, has pagado 96.000 tokens de entrada para una tarea que quizá necesitaba 2.000.

Tres reglas que aplico siempre:

Contexto mínimo viable. Cada herramienta externa que expones al modelo añade tokens a cada llamada. Si tienes 30 herramientas descritas, estás pagando por las 30 en todas las peticiones.
Recorta el historial, no lo acumules. Resumir los turnos viejos cuesta una llamada barata y ahorra muchas caras.
Mide. Sin métricas por tarea no sabes si el gasto viene de un bucle que se repite o de un contexto inflado.

# Mal: el agente arrastra todo el historial en cada paso
messages = history + [nuevo_mensaje]

# Bien: ventana recortada + resumen de lo anterior
messages = [resumen_previo] + history[-6:] + [nuevo_mensaje]

Latencias: el enemigo silencioso

Un agente que tarda 4 minutos en hacer algo que tú harías en 30 segundos no se usa. Y el tiempo se va casi siempre en tres sitios:

Cadenas de herramientas que se llaman en secuencia cuando podrían ir en paralelo.
Reintentos silenciosos: un proveedor que devuelve error y el agente reintenta tres veces con backoff exponencial. El usuario solo ve que “va lento”.
Arranque en frío del modelo local.

Medir el tiempo por paso, y no solo el total, fue lo que me dejó ver que la mitad del tiempo se iba en un reintento que no hacía falta.

Cosas que rompen y nadie te cuenta

Credenciales que caducan. Un token expirado convierte un agente en un generador de errores. Si tienes varias tareas programadas, van a fallar todas a la vez y a la misma hora. Merece la pena tener un chequeo periódico que valide la credencial antes de que lo haga el trabajo real.
Procesos que mueren en silencio. Un listener que nadie supervisa deja de funcionar y la tarea que dependía de él se queda esperando para siempre. Si un componente es crítico, necesita su propio servicio con reinicio automático, no un proceso lanzado a mano.
El estado compartido. Si dos agentes se coordinan por un canal (Redis, cola, fichero), ese canal es infraestructura: hay que tratarlo como tal, con su autenticación y su monitorización.

Un agente no es un script con esteroides: es un servicio más. Si no lo despliegas, monitorizas y respaldas como tal, te va a despertar de noche.

Cómo lo tengo montado hoy

Modelo pequeño local para tareas de clasificación y extracción: coste cero por llamada y datos que no salen de casa.
Modelo grande remoto para razonamiento y redacción, con contexto recortado y medición por tarea.
Credenciales centralizadas y un chequeo diario que avisa si alguna ha dejado de valer.
Todo bajo supervisión: los componentes críticos corren con reinicio automático y logs rotados, porque un log de 1,5 GB también es un fallo de diseño.

Qué haría distinto si empezara hoy

Empezaría por medir antes de optimizar: registrar tokens, latencia y coste por tarea desde el primer día. Y separaría desde el principio lo que es infraestructura de lo que es experimento. La mayor parte del tiempo perdido no vino de elegir mal el modelo, sino de tratar como juguete algo que estaba sosteniendo tareas reales.