Replicate AI: come usarlo, quanto costa e quando conviene

Verifica su prezzi e documentazione online di Replicate effettuata il 5 novembre 2026. La valutazione si basa sul comportamento documentato e su esempi di costo calcolati.

Che cos'è Replicate AI e come funziona?

Replicate esegue su un'infrastruttura gestita un modello, cioè un programma confezionato per ricevere input e restituire output. L'applicazione invia un prompt, un file o un altro input previsto dal modello; Replicate crea una prediction, il termine con cui indica una singola esecuzione, e restituisce il risultato oppure un identificativo da controllare in seguito. Il catalogo comprende modelli open source e proprietari: essere disponibili su Replicate non significa essere open source. Replicate appartiene ora a Cloudflare: l'annuncio di Replicate del novembre 2025 prevedeva la continuità del marchio e dell'API, mentre l'annuncio di completamento di Cloudflare ha confermato l'ingresso ufficiale in Cloudflare il 1 dicembre 2025. Questo passaggio di proprietà non rende ogni modello Replicate un servizio eseguito all'edge: la scelta va fatta sulle funzionalità documentate per l'endpoint che si userà.

A chi conviene Replicate e quando scegliere altro?

Replicate è adatto a chi vuole aggiungere l'inferenza, cioè l'esecuzione di un modello già addestrato, a un prodotto che dispone già di un sistema per gestire utenti, elaborazioni e file. Può essere una funzione di generazione immagini in un'app SaaS, un editor video asincrono o un classificatore di immagini personalizzato. Si evita la gestione dei server GPU, ma il flusso del prodotto e la scelta degli output accettabili restano responsabilità di chi sviluppa.

Le alternative da valutare dipendono da cosa si deve mettere in servizio. Le indicazioni seguenti riguardano i carichi di lavoro, non sono classifiche di velocità misurata.

Modal è più indicato quando si vuole definire in Python un'applicazione GPU personalizzata e il suo ambiente. Il suo modello di esecuzione definito nel codice offre maggiore controllo sull'applicazione, ma lascia anche più codice di servizio da gestire. L'analisi dei prezzi di Modal chiarisce i costi di questa scelta.

fal AI o Replicate: quale valutare per primo?

Per un prodotto incentrato sui contenuti multimediali generativi, fal merita il primo confronto. Replicate va valutato per primo quando la stessa applicazione richiede anche modelli della community o un modello confezionato in proprio. Se entrambi offrono il modello scelto, bisogna confrontare opzioni di input, unità di output, controlli operativi e politiche sui dati di quegli endpoint. Affermare che una piattaforma sia sempre più veloce o economica non è un criterio d'acquisto utile.

Se invece la decisione riguarda ormai l'acquisto continuativo di capacità hardware, partire dal catalogo dei modelli non è più l'approccio giusto. Il confronto tra fornitori di GPU cloud affronta questo passaggio successivo. Allo stesso modo, chi non ha competenze tecniche e cerca un agente di assistenza o un'applicazione di montaggio video pronta all'uso dovrebbe acquistare l'applicazione: un endpoint di modello lascia ancora molto prodotto da costruire.

Eseguire un modello: dalla scelta alla chiamata API

Replicate semplifica la prima integrazione, ma è comunque lo schema API del modello, ossia l'elenco degli input accettati e dei campi restituiti, a stabilire cosa l'applicazione deve inviare e ricevere.

Come scegliere i modelli di Replicate AI

Replicate distingue i modelli ufficiali da quelli della community. La documentazione sui modelli ufficiali promette istanze sempre pronte, API di input e output stabili, manutenzione attiva e fatturazione prevedibile basata su input o output. Per chiamare un modello ufficiale bastano proprietario e nome, senza identificativo di versione.

La documentazione sui modelli della community descrive condizioni diverse: le chiamate API indicano una versione specifica, la fatturazione segue in genere il tempo hardware e i modelli usati di rado possono richiedere un avvio a freddo. Fissare la versione significa richiedere una precisa revisione del pacchetto; non rende uguali le licenze o i campi di input di tutti i modelli.

Per sviluppare una funzione di prodotto, il modello va scelto prima di scrivere l'integrazione. Occorre verificarne licenza, tipi di file accettati, parametri obbligatori, struttura dell'output e unità di fatturazione. Copiare la richiesta di un modello per immagini e sostituirne il nome con quello di un modello vocale non basta: gli input sono diversi.

Generare immagini con Replicate AI

Su Replicate la generazione di immagini passa attraverso gli endpoint dei singoli modelli. Black Forest Labs FLUX Schnell, per esempio, riceve un prompt testuale e restituisce immagini generate. Chi vuole aggiungere al proprio prodotto la generazione di immagini concettuali può prima impostare gli input nell'interfaccia web del modello, quindi usare lo stesso schema dal backend.

Creare un token API nell'account e inserirlo nella variabile d'ambiente REPLICATE_API_TOKEN del backend. La documentazione sui token li equipara a password: non devono comparire nel codice inviato al browser e vanno separati per ambiente.

Una volta impostata la variabile, questa richiesta HTTP è pronta per l'esecuzione. Usa l'account Replicate e può comportare l'addebito previsto per il modello.

curl --fail-with-body --silent --show-error \
  https://api.replicate.com/v1/models/black-forest-labs/flux-schnell/predictions \
  --request POST \
  --header "Authorization: Bearer $REPLICATE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Prefer: wait" \
  --data '{"input":{"prompt":"A matte ceramic teapot on a wooden kitchen table","num_outputs":1}}' \
  > prediction.json

La risposta è un oggetto prediction. Vanno controllati i campi status, output ed error: il successo della richiesta HTTP non implica che la generazione sia terminata. La documentazione sulla creazione delle prediction specifica un'attesa predefinita di 60 secondi quando si usa Prefer: wait. È un'impostazione dell'attesa della richiesta, non una promessa sulla latenza. Se l'esecuzione non è conclusa, la risposta contiene una prediction in stato starting o processing e un indirizzo urls.get per i controlli successivi.

Rimuovendo Prefer: wait si usa il comportamento asincrono predefinito: l'API restituisce l'identificativo dell'elaborazione senza attenderne il completamento. Modelli ufficiali, modelli della community e deployment usano percorsi di creazione diversi, descritti nel riferimento dell'API HTTP. Va usato l'esempio generato per il modello o il deployment scelto.

Gestire video, voce e testo con elaborazioni in background

Per le elaborazioni più lunghe, Replicate funziona al meglio quando l'applicazione registra il lavoro e raccoglie i risultati dopo l'invio. Un webhook, cioè una notifica HTTP inviata al server, permette di reagire al completamento senza tenere l'utente in attesa su una richiesta aperta.

Si pensi a un prodotto che trasforma un copione approvato dal cliente in una clip illustrata. Bisogna generare i contenuti, associare l'ID della prediction al lavoro del cliente e raccogliere i file completati prima di assemblare il risultato finale. La documentazione sui webhook prevede esplicitamente il salvataggio dei dati delle prediction e il passaggio dell'output di un modello a un altro. L'orchestrazione e lo stato finale del lavoro mostrato al cliente restano responsabilità dell'applicazione.

Per i video, consultare la raccolta text-to-video, quindi l'API del modello scelto. Un modello text-to-video e uno image-to-video richiedono materiali di partenza diversi. Salvare insieme al lavoro il modello selezionato e gli input permette di ricostruire in seguito le cause di un errore o di un risultato insoddisfacente.

Sintesi vocale con Replicate

La raccolta text-to-speech di Replicate offre modelli che trasformano testo scritto in audio. Per una presentazione narrata del prodotto, serve un modello con lingua e controlli vocali adatti al copione; si genera la narrazione e si salva l'audio insieme al resto del lavoro. La presenza di modelli vocali non ne dimostra l'idoneità a una conversazione telefonica interattiva: bisogna valutare il comportamento delle risposte dell'endpoint scelto all'interno dell'applicazione.

Replicate ospita anche modelli linguistici di grandi dimensioni, capaci di generare e interpretare testo, presenti tra l'altro nella raccolta di modelli linguistici. Si possono usare per preparare la narrazione o classificare una richiesta in arrivo, verificandone poi l'output prima di passarlo alla fase successiva. La revisione del copione e l'assemblaggio finale devono restare nel flusso dell'applicazione, per evitare che un risultato intermedio scadente diventi un prodotto finito consegnato al cliente.

Mettere online un modello proprio con Cog

Replicate può mettere in servizio un modello già addestrato quando il catalogo pubblico non offre la logica necessaria. Cog è lo strumento open source che racchiude codice, dipendenze e pesi del modello in un container, cioè un ambiente software riproducibile.

Un rivenditore che possiede già un classificatore di immagini di prodotto, per esempio, può confezionarlo ed esporlo come API privata. È un percorso di deployment per un modello che esiste già: caricare una cartella non basta ad addestrare un classificatore utile.

La guida al deployment di modelli personalizzati e la guida al push con Cog descrivono il percorso seguente.

Il vero impegno resta la gestione del pacchetto. Non si deve più amministrare il cluster GPU, ma servono comunque codice di inferenza funzionante, dipendenze compatibili, hardware adeguato e un modello capace di produrre risultati utili. Se il modello richiede più memoria di quella disponibile sulla macchina scelta, esporlo tramite API non elimina quel requisito.

Controllare la capacità con un deployment

I deployment di Replicate offrono un endpoint dedicato e il controllo su hardware e scalabilità. Diventa importante quando il prodotto dipende da un modello e una coda condivisa non è più una scelta operativa accettabile.

La documentazione sui deployment descrive il numero minimo e massimo di istanze, la riduzione a zero, il monitoraggio e gli aggiornamenti progressivi di versione. Un'istanza è una copia in esecuzione del modello. Un minimo di 1 mantiene una copia disponibile; un minimo di 0 consente al servizio di spegnere la capacità inutilizzata. Tenere una copia pronta non significa poter assorbire un picco illimitato di traffico senza capacità aggiuntiva.

Per un classificatore di immagini usato dai clienti, il minimo va scelto in base alla reattività necessaria e il massimo in base alla capacità che si è disposti a finanziare. Monitorare istanze attive, inattive e in avvio insieme a errori e latenza delle richieste. Se un deployment resta inattivo per gran parte della giornata, la capacità scelta va riesaminata nell'analisi dei costi. Se raggiunge ripetutamente il massimo, aumentare i tentativi API non crea ulteriore capacità configurata.

Quanto costa Replicate?

Replicate addebita l'utilizzo, con un'unità di fatturazione stabilita modello per modello. La pagina dei prezzi online indica che alcuni modelli si pagano in base a hardware e tempo, altri in base a input e output. Non esiste un prezzo unico per richiesta che descriva l'intera piattaforma.

Quelli che seguono sono esempi di listino: non indicano necessariamente i modelli più recenti o più adatti al proprio carico di lavoro.

Per un piccolo team di sviluppo, il punto di partenza ragionevole è un modello pubblico con l'output e l'unità di fatturazione adatti. Con un modello pubblico fatturato a tempo si paga l'elaborazione delle richieste; setup e inattività sono gratuiti. Con i deployment e la maggior parte dei modelli privati, invece, sono fatturabili il tempo di setup, quello attivo e quello di inattività delle istanze. L'eccezione documentata per i modelli privati riguarda i fine-tune contrassegnati come fast booting, per i quali si paga soltanto il tempo di elaborazione attiva.

La documentazione sulla fatturazione distingue inoltre gli account prepagati da quelli con pagamento a consuntivo. Nei primi, l'utilizzo viene scalato dal credito; nei secondi, l'addebito avviene all'inizio del mese per i consumi del mese precedente.

Due esempi calcolati mostrano perché la distinzione conta. 10,000 immagini prodotte con FLUX Schnell in un mese costano $30 alla tariffa di output indicata, esclusi altri servizi o ulteriori immagini generate. Separatamente, una T4 mantenuta online per un mese di 30 giorni costa $583.20: 720 ore moltiplicate per $0.81, prima di eventuali istanze aggiuntive attivate dall'autoscaling. Sono due modalità di acquisto diverse, non un benchmark che dimostri che una T4 riproduca l'output o la capacità di elaborazione del servizio di immagini.

In generale, le esecuzioni fallite non vengono addebitate. La documentazione mantiene però gli addebiti per le istanze attive di modelli privati e deployment, il tempo consumato prima dell'annullamento nei modelli fatturati a tempo e gli eventuali costi di annullamento dei modelli ufficiali. Un modello che ne chiama altri può inoltre generare costi a valle anche quando l'esecuzione complessiva fallisce. La stima deve coprire l'intero flusso che si intende eseguire.

I limiti da considerare prima di andare in produzione

Replicate elimina la gestione delle GPU dalla prima integrazione, ma la documentazione indica comunque limiti concreti che l'applicazione deve saper gestire.

Avvii a freddo e capacità condivisa

Replicate chiama cold boot l'avvio a freddo: prima di elaborare la richiesta, il modello deve caricare ambiente e pesi. La descrizione dell'architettura della piattaforma spiega che i modelli pubblici più popolari vengono spesso mantenuti pronti dall'utilizzo continuo, mentre quelli meno usati incontrano più spesso avvii a freddo. Per i modelli ufficiali vale l'impegno distinto a mantenerli sempre pronti, descritto sopra.

La conseguenza è precisa: una funzione interattiva basata su un modello della community usato saltuariamente deve prevedere uno stato di attesa oppure un deployment configurato per mantenere capacità disponibile. Un'elaborazione batch in background può tollerare l'avvio in modo diverso da un utente che aspetta un risultato immediato. Non esiste una latenza universale che sostituisca la valutazione di quel modello e di quel carico di lavoro.

Con poco credito, i limiti sulle richieste diventano più stretti

La documentazione sui limiti di frequenza specifica 600 richieste di creazione di prediction al minuto e 3,000 richieste al minuto per gli altri endpoint. Sono possibili brevi picchi oltre i valori predefiniti; il superamento dei limiti restituisce HTTP 429 e per soglie più alte occorre contattare Replicate. Sono limiti sulle richieste API, non una promessa che il modello completi altrettante elaborazioni al minuto.

Un vincolo meno evidente riguarda il saldo dell'account. Replicate restringe ulteriormente i limiti quando il credito scende e consiglia la ricarica automatica per mantenerlo sopra $20. Gli account con credito assegnato e senza un metodo di pagamento hanno un limite separato di 1 richiesta al secondo, fino a un massimo di 6 al minuto.

Una coda può quindi rallentare per ragioni di fatturazione prima ancora che il team tecnico modifichi le impostazioni del deployment. Occorre monitorare il credito insieme agli errori delle richieste, limitare i nuovi tentativi e distanziarli progressivamente in caso di throttling, ed evitare un polling aggressivo che consumi la quota degli altri endpoint.

API e browser conservano i dati in modo diverso

La documentazione sulla conservazione dei dati indica che, per impostazione predefinita, parametri di input, valori di output, file prodotti e log delle prediction via API vengono eliminati dopo un'ora. L'applicazione deve salvare prima i dati di cui ha bisogno. L'URL di un file restituito non è quindi un archivio permanente dei propri contenuti.

I dati delle prediction create dal browser vengono conservati a tempo indeterminato. Il sito offre l'azione Delete per eliminare una prediction e i relativi dati e file di output. Una prova nel browser e un'integrazione API hanno dunque comportamenti diversi: ciò che si osserva nell'una non va esteso all'altra.

In produzione, i contenuti completati vanno salvati in uno spazio controllato dall'applicazione, conservando anche modello, input e stato del lavoro necessari all'assistenza. La visibilità del modello è una questione separata: rendere privato un modello personalizzato controlla chi può accedervi, ma non stabilisce una promessa diversa sulla conservazione. Allo stesso modo, la sola pagina sulla conservazione non basta a sostenere affermazioni generali sull'uso dei dati per l'addestramento, sulla residenza geografica o sul rispetto di ogni requisito contrattuale di trattamento.

La scelta del modello resta responsabilità dell'applicazione

Il catalogo di Replicate è un livello di distribuzione ed esecuzione. I permessi per l'uso commerciale dipendono comunque dalla licenza del modello scelto e gli schemi dei modelli della community variano. Cambiare modello va trattato come una modifica all'applicazione: prima di spostare il traffico di produzione, verificare validazione degli input, file prodotti, permessi e costi. Una piattaforma uniforme non rende intercambiabili tutti i modelli.

Il verdetto: partire dal servizio condiviso, dedicare capacità quando serve

Replicate è una scelta solida quando il valore del prodotto sta in ciò che si costruisce intorno al modello e rinunciare alla gestione delle GPU permette di distribuirlo prima. Conviene iniziare da un endpoint pubblico adatto. Un modello ufficiale è preferibile quando disponibilità documentata, interfaccia stabile e unità di fatturazione rispondono alle esigenze.

Il passaggio a un deployment deve avere un motivo preciso: codice di inferenza personalizzato, controllo sull'hardware, capacità dedicata o un'istanza sempre pronta per una funzione usata dai clienti. I costi di setup e inattività fanno parte di quella scelta. Se il requisito centrale è invece un catalogo multimediale specializzato, l'erogazione di modelli linguistici, un deployment dall'Hub o un'applicazione di calcolo Python più ampia, le alternative indicate sopra sono il punto di partenza.

Il primo traguardo dell'implementazione dovrebbe essere un'elaborazione completa: inviarla, rilevarne il completamento, salvarne l'output e contabilizzarne il costo. Solo dopo si decide se portare in produzione l'endpoint pubblico o un deployment dedicato.

Domande frequenti su Replicate

La checklist per l'audit dei flussi di lavoro aziendali con l'AI aiuta a mappare le attività intorno al modello prima di impegnarsi nello sviluppo della funzione.