L'errore che vedo più spesso con l'hosting degli agenti è dimensionare per la cosa sbagliata. Qualcuno fa girare un agente, usa 400 MB, e conclude che gli agenti sono economici da ospitare. Poi scala a una crew reale e la macchina inizia a fare swap alle 3 di notte.
Un agente è economico. Non è quello il caso interessante.
Dove va davvero la memoria
Un agente che solo lancia chiamate API a un modello è leggero — sta per lo più aspettando la rete. Potresti farne girare una dozzina su un piano piccolo e non accorgertene mai.
La RAM sparisce quando gli agenti iniziano a tenere lo stato. Cronologia della conversazione che cresce a ogni turno. Un working set che diversi agenti leggono e scrivono. Un vector store per la memoria a lungo termine seduto nello stesso processo. Nel momento in cui la tua architettura smette di essere "chiama API, dimentica" e diventa "ricorda, coordina, passa la mano", la memoria diventa il vincolo, non la CPU.
CrewAI, LangGraph, loop in stile AutoGPT — tendono tutti in questa direzione man mano che diventano seri. Il framework non mangia la RAM; lo stato sì.
Dimensionamento approssimativo, onestamente
Non farò finta che ci sia una formula, perché non c'è — dipende interamente da quanto ogni agente tiene in giro. Ma una sensazione pratica dall'eseguire questi:
- Agenti leggeri, legati all'API — qui non ti serve affatto Pro; un piano NAT o con IP dedicato ($3–20) lo gestisce. Pro si guadagna il posto una volta che lo stato condiviso ti spinge oltre i ~32 GB.
- 32 GB — il punto ideale per un vero sistema multi-agente: 5–10 agenti con memoria condivisa più un database vettoriale davvero utile. La maggior parte della gente atterra qui.
- 64 GB — flotte più grandi, cronologie più lunghe, un indice di memoria da milioni di vettori, o diversi servizi co-locati. È qui che una macchina sostituisce le tre più piccole che altrimenti staresti destreggiando.
- 80 GB — lavoro pesante e memory-bound: grandi dataset in memoria, molti agenti concorrenti, o agenti più inferenza di un modello locale sullo stesso host.
Parti sotto dove pensi di dover essere. Osserva htop per un giorno. Ridimensiona in su quando vedi lo swap, non prima — indovinare alto spreca solo denaro.
La parte difficile da comprare
Ecco la cosa che rende tutto scomodo: noleggiare 64 GB di RAM è facile. Noleggiare 64 GB con crypto e senza controllo d'identità no. La maggior parte degli host che vende memoria seria a buon mercato lo fa dietro una carta e un modulo KYC.
Se il tuo agente fa provisioning del proprio server, o il carico tocca dati che preferiresti non legare a un nome, quella combinazione — alta memoria, crypto, no KYC, e ordinabile dall'agente stesso tramite MCP — è il vero prodotto. Non è più economica per gigabyte, e ho scritto separatamente sul perché quel confronto inganna. È disponibile a condizioni che quasi nessuno offre.
Quindi cosa fai
Se i tuoi agenti sono leggeri e legati all'API, non pensarci troppo — un piccolo piano NAT o con IP dedicato è più che sufficiente, salta l'intera questione dell'alta memoria. Se stai facendo girare una vera flotta che tiene lo stato, dimensiona in base a ciò che è davvero in memoria, parti da 32 GB, e sali quando il grafico te lo dice.
Quando sei lì, la linea Pro copre da 32 a 80 GB con un IP dedicato e backup notturni. Scegli la fascia che corrisponde al tuo working set, non alle tue ambizioni.
Commenti
Ancora nessun commento. Sii il primo.