El error que veo más a menudo con el hosting de agentes es dimensionar para lo equivocado. Alguien ejecuta un agente, usa 400 MB, y concluye que los agentes son baratos de alojar. Luego escala a una crew de verdad y la máquina empieza a hacer swap a las 3 de la madrugada.
Un agente es barato. Ese no es el caso interesante.
A dónde va realmente la memoria
Un agente que solo dispara llamadas de API a un modelo es ligero — sobre todo espera a la red. Podrías ejecutar una docena de esos en un plan pequeño y nunca notarlo.
La RAM desaparece cuando los agentes empiezan a mantener estado. Historial de conversación que crece cada turno. Un conjunto de trabajo que varios agentes leen y escriben. Un almacén vectorial para memoria de largo plazo sentado en el mismo proceso. En el momento en que tu arquitectura deja de ser «llama a la API, olvida» y se convierte en «recuerda, coordina, entrega», la memoria se vuelve la restricción, no la CPU.
CrewAI, LangGraph, bucles estilo AutoGPT — todos tienden en esta dirección cuando se ponen serios. El framework no se come la RAM; el estado sí.
Dimensionamiento aproximado, con honestidad
No voy a fingir que hay una fórmula, porque no la hay — depende por completo de cuánto mantiene cada agente. Pero una sensación práctica de operar estos:
- Agentes ligeros y ligados a la API — aquí no necesitas Pro en absoluto; un plan NAT o con IP dedicada (3–20 $) lo maneja. Pro se gana su lugar una vez que el estado compartido te empuja por encima de ~32 GB.
- 32 GB — el sweetspot para un sistema multiagente de verdad: 5–10 agentes con memoria compartida más una base de datos vectorial que es realmente útil. La mayoría de la gente aterriza aquí.
- 64 GB — flotas más grandes, historiales más largos, un índice de memoria de millones de vectores, o varios servicios colocados juntos. Aquí una máquina reemplaza las tres más pequeñas que de otro modo jonglearías.
- 80 GB — trabajo pesado ligado a la memoria: grandes conjuntos de datos en memoria, muchos agentes concurrentes, o agentes más inferencia de modelo local en el mismo host.
Empieza por debajo de donde crees que necesitas estar. Vigila htop un día. Amplía cuando veas swap, no antes — adivinar alto solo desperdicia dinero.
La parte que es difícil de comprar
Aquí está lo que hace esto incómodo: alquilar 64 GB de RAM es fácil. Alquilar 64 GB con cripto y sin verificación de identidad no lo es. La mayoría de los hosters que venden memoria seria barata lo hacen detrás de una tarjeta y un formulario KYC.
Si tu agente aprovisiona su propio servidor, o el workload toca datos que preferirías no atar a un nombre, esa combinación — alta memoria, cripto, sin KYC, y pedible por el propio agente mediante MCP — es el producto de verdad. No es más barato por gigabyte, y he escrito por separado sobre por qué esa comparación engaña. Está disponible en condiciones que casi nadie ofrece.
Entonces, qué haces
Si tus agentes son ligeros y ligados a la API, no le des demasiadas vueltas — un plan pequeño NAT o con IP dedicada es de sobra, sáltate toda la cuestión de la alta memoria. Si estás ejecutando una flota de verdad que mantiene estado, dimensiona por lo que hay realmente en memoria, empieza en 32 GB, y sube cuando el gráfico te lo diga.
Cuando estés ahí, la línea Pro cubre de 32 a 80 GB con una IP dedicada y copias de seguridad nocturnas. Elige el nivel que coincida con tu conjunto de trabajo, no con tus ambiciones.
Comentarios
Aún no hay comentarios. Sé el primero.