La maggior parte dei team chiama un fornitore di modelli direttamente dal codice applicativo. La chiave API sta in una variabile d’ambiente, la chiamata SDK è di tre righe e funziona al primo colpo. Cloudflare AI Gateway esiste per ciò che succede dopo. Arriva la fattura e nessuno sa dire quale funzionalità l’ha causata. Il fornitore ha un pomeriggio storto e si porta dietro il vostro prodotto. Un prompt di sistema viene modificato e non resta traccia di che cosa restituiva quello vecchio.

Un gateway è un proxy fra la vostra applicazione e il fornitore. Ogni richiesta lo attraversa, quindi ogni richiesta può essere contata, registrata, messa in cache, limitata nel tasso e, quando il fornitore cade, ritentata altrove. È la correzione strutturale più economica per tre problemi che altrimenti si risolvono tardi e a mano.

Quello che segue è che cosa fa, che cosa impone invece di limitarsi a osservare, quanto costa in denaro e in millisecondi e dove stanno i limiti onesti.

Mettere un gateway davanti alla vostra API del modello fa davvero risparmiare? Non direttamente. Il nucleo di Cloudflare AI Gateway è gratuito su tutti i piani e non aggiunge alcun ricarico sull’inferenza, quindi il risparmio nasce da ciò che vi mostra piuttosto che da ciò che blocca. L’attribuzione dei costi per funzionalità vi dice quale parte del prodotto è cara, la cache elimina le chiamate identiche ripetute dove è sicuro farlo e il routing di fallback impedisce che un disservizio del fornitore diventi il vostro. Il limite di budget esiste, ma che cosa succede quando il budget finisce è una decisione di prodotto, non di configurazione.

Le tre domande a cui una chiamata diretta al modello non sa rispondere

Ogni argomento a favore di un gateway si riduce a una di tre domande che una chiamata SDK diretta lascia senza risposta. La versione astratta, visibilità e controllo, non convince nessuno che debba giustificare il lavoro.

Nessuno riesce ad attribuire la fattura

La fatturazione a token si basa sul consumo e le fatture dei fornitori aggregano. Ricevete un totale mensile per chiave API, non un totale per funzionalità. Se un riassuntore, un assistente conversazionale e un lavoro notturno di classificazione condividono una chiave, la fattura non può dire quale dei tre è triplicato. La risposta abituale è una chiave per funzionalità, che funziona finché non avete undici funzionalità e una politica di rotazione.

Nessuno riesce a riprodurre il guasto

Quando una chiamata fallisce dentro il codice applicativo, ciò che sopravvive è quello che il vostro logger ha catturato, di solito un codice di stato e un messaggio troncato. Raramente il prompt esatto, la versione del modello che ha risposto o la latenza alla quale ha rinunciato. Riprodurre un incidente il giorno dopo diventa un indovinello sugli input. Nel frattempo un disservizio del fornitore si propaga dritto fino ai vostri utenti.

Niente mette un tetto a un ciclo impazzito

Un agente che si ritenta da solo, un consumatore di coda che riconsegna in caso di errore, o un ciclo la cui condizione di uscita un modello continua a giudicare non soddisfatta: ciascuno può generare migliaia di chiamate prima che qualcuno se ne accorga. Senza qualcosa nel percorso che conti, il primo segnale è la fattura. I limiti per utente e gli stop netti non esistono finché un componente nel percorso non li impone, e il codice applicativo è un posto pessimo per farlo, perché ogni punto di chiamata deve ricordarsene.

Che cos’è Cloudflare AI Gateway e dove si colloca nel percorso della richiesta

La panoramica di AI Gateway di Cloudflare descrive un servizio che sta fra la vostra applicazione e i fornitori di modelli di IA, così da monitorare l’uso e gestire come l’applicazione scala. Le funzioni sono analisi, logging, cache, limitazione del tasso e ritentativo con fallback, su tutti i piani Cloudflare. Cloudflare sostiene che per iniziare basti una riga di codice, e la forma dell’integrazione spiega perché è quasi vero.

L’integrazione è un cambio di URL di base

Invece di puntare il vostro SDK al fornitore, lo puntate a un indirizzo di gateway che porta l’identificativo del vostro account, quello del gateway e il nome del fornitore. Cloudflare documenta la forma OpenAI come https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai, fornita come baseURL quando si costruisce il client. Nomi dei modelli, parametri, streaming e analisi della risposta restano come erano. L’elenco dei fornitori di Cloudflare copre due dozzine di servizi con lo stesso schema, fra cui OpenAI, Anthropic, Google Vertex AI, Amazon Bedrock, Azure OpenAI, Mistral, Groq, DeepSeek, xAI e il Workers AI di Cloudflare.

Che cosa implica questa forma

L’adozione è davvero economica: un valore di configurazione per servizio, reversibile rimettendolo com’era, il che ne fa uno dei pochi cambiamenti infrastrutturali che si possono provare senza un piano di progetto.

La vostra chiave del fornitore ora passa attraverso Cloudflare, perché il proxy deve inoltrarla, a meno che non passiate alle chiavi memorizzate o alle credenziali gestite da Cloudflare. È una decisione di fiducia, non un dettaglio.

E tutto ciò che viene offerto è limitato da quello che un proxy può vedere. Vede richieste e risposte, non l’intenzione della vostra applicazione, ed è per questo che l’attribuzione richiede che siate voi a etichettare le richieste, invece di aspettarvi che il gateway indovini a che cosa servisse una chiamata.

Analisi e logging sono le funzioni che fanno risparmiare

Il gateway conta ogni richiesta. La documentazione sul logging di Cloudflare elenca che cosa contiene una voce: il prompt dell’utente, la risposta del modello, il fornitore, l’orario, lo stato della richiesta, il consumo di token, il costo, la durata e lo user agent del client. Per richiesta invece che per mese, e interrogabile.

Siate espliciti sul perché il denaro stia qui e non nelle funzioni di imposizione. Bloccare la spesa fa risparmiare il costo delle chiamate che avete fermato, che è limitato. Sapere dove va la spesa cambia quello che costruite, e questo non lo è.

L’attribuzione non è automatica. I metadati personalizzati allegano etichette vostre, per esempio il nome della funzionalità o del cliente, così che l’analisi possa raggrupparle. Saltate quel passo e ottenete un totale, cioè ciò che la fattura vi dava già.

La cache, e i casi in cui un hit rovina il prodotto

La cache è la funzione attivata più spesso per il motivo sbagliato, e quella più capace di rompere un prodotto in silenzio.

Come viene costruita la chiave di cache

La documentazione sulla cache di Cloudflare spiega che la chiave è un hash SHA-256 di fornitore, endpoint, modello, header di autenticazione e corpo completo della richiesta. Una corrispondenza esatta su tutto è un hit, qualsiasi altra cosa è un miss. Un hit richiede quindi una richiesta identica byte per byte, cosa rara dopo il primo turno su un endpoint conversazionale che porta con sé la cronologia accumulata. La durata minima è di 60 secondi e la massima di un mese. Il controllo per singola richiesta arriva da cf-aig-cache-ttl, cf-aig-skip-cache e cf-aig-cache-key, mentre cf-aig-cache-status restituisce HIT o MISS così potete misurare il tasso reale.

Quando un hit è sicuro e quando non lo è

Un hit è sicuro dove input identici devono produrre output identici e una risposta non recentissima è accettabile: classificazione, estrazione strutturata, traduzione di stringhe fisse, embedding di documenti immutati, traffico di valutazione. Non è sicuro ovunque il valore del prodotto dipenda dalla variazione. Se due utenti fanno la stessa domanda e il secondo riceve una risposta generata per il primo, la vostra impostazione della temperatura è decorativa.

Il guasto peggiore riguarda la riservatezza. Se il corpo della richiesta non porta nulla che distingua gli utenti, una risposta in cache può attraversare il confine fra due utenti, il che è una divulgazione e non un problema di qualità. La cache copre inoltre solo risposte di testo e immagini.

Limitazione del tasso, ritentativi e routing di fallback

Queste tre cose vengono descritte insieme come funzioni di affidabilità. Solo una di esse vincola davvero il costo.

La limitazione del tasso conta le richieste, non i token

Cloudflare offre una finestra fissa e una finestra scorrevole, e le richieste oltre il limite ricevono un 429. Notate che cosa viene contato: le richieste. Una singola chiamata che porta un contesto molto grande costa assai più di una breve, e il limitatore non sa distinguerle. La limitazione del tasso vi protegge da un ciclo impazzito e da un endpoint abusato, non da un prompt costoso, e trattarla come controllo dei costi è l’errore comune.

Ritentativi e timeout

Gli header di gestione della richiesta di Cloudflare consentono fino a 5 tentativi con cf-aig-max-attempts, un ritardo fino a 5000 millisecondi con cf-aig-retry-delay e una strategia costante, lineare o esponenziale con cf-aig-backoff. L’header cf-aig-request-timeout si misura da quando arriva la prima parte della risposta, quindi su una chiamata in streaming è un limite sul tempo al primo byte piuttosto che sulla durata totale. All’ultimo tentativo il gateway aspetta il completamento della richiesta, per quanto a lungo serva.

Il routing di fallback ha cambiato forma

L’Universal Endpoint, che prendeva un array di oggetti fornitore e lo percorreva in caso di errore, è deprecato. Cloudflare ora indirizza le nuove integrazioni verso l’endpoint compatibile con OpenAI, e verso Dynamic Routing per fallback, ritentativi e routing condizionale. Una rotta dinamica è un flusso denominato e versionato, costruito visivamente o come JSON, fatto di nodi modello, nodi condizionali che si ramificano in base al corpo della richiesta, agli header o ai metadati, nodi percentuale per i test A/B e nodi di limite di tasso e di budget che deviano su un fallback al superamento. La invocate mettendo il nome della rotta dove andrebbe il nome del modello.

Ispezionare che cosa entra e che cosa torna indietro

Poiché il proxy tiene entrambe le metà dello scambio, può valutarle. I Guardrails di Cloudflare intercettano i prompt degli utenti e le risposte dei modelli, segnalano contenuti per revisione o ne bloccano il passaggio, e applicano una sola politica indipendentemente da quale fornitore abbia risposto.

L’argomento a favore della politica nel percorso invece che nel codice è che la moderazione a livello applicativo va scritta una volta per ogni punto di chiamata, e il punto di chiamata aggiunto la settimana scorsa è quello che se la dimentica. Il costo è che l’ispezione è essa stessa inferenza: i Guardrails sono fatturati come uso di Workers AI a token, quindi il prezzo cresce con la lunghezza di ciò che ispezionate. La scansione per la prevenzione della perdita di dati è gratuita su tutti i piani.

Che cosa è cambiato durante l’Agents Week di agosto 2026

Cloudflare ha tenuto la sua prima Agents Week dal 3 al 7 agosto 2026 e nell’ultimo giorno ha pubblicato l’unificazione di Workers AI e AI Gateway in un unico piano di controllo. Separate ciò che è stato rilasciato da ciò che è stato annunciato.

Che cosa è stato rilasciato: un solo binding IA invece di due, così env.AI.run() copre sia i modelli Workers AI sia i fornitori esterni. Il routing tramite gateway è diventato il comportamento predefinito per Workers AI invece che facoltativo, con gateway: { id: 'default' } che crea il gateway al primo uso e porta logging delle richieste, conteggio dei token e attribuzione dei costi senza altre modifiche. I crediti sono diventati spendibili fra fornitori, quindi Workers AI si paga dallo stesso saldo prepagato di OpenAI o Anthropic.

Che cosa non è stato rilasciato: il routing per modello, in cui chiedete un modello e la piattaforma sceglie il fornitore, è il prossimo passo e non è disponibile, e uno smart router che classifica i prompt resta un pilota interno. È un consolidamento di fatturazione, binding e dashboard, non una capacità nuova. Se già chiamavate Workers AI sull’edge senza un gateway, ora ottenete l’osservabilità per impostazione predefinita.

Quanto costa Cloudflare AI Gateway

La pagina dei prezzi di AI Gateway di Cloudflare afferma che le funzioni di base disponibili oggi sono offerte gratuitamente, il che copre analisi da dashboard, cache e limitazione del tasso su tutti i piani. Tutte le cifre qui sotto sono i prezzi in dollari statunitensi pubblicati da Cloudflare, citati nella valuta in cui Cloudflare li pubblica.

Dove compaiono davvero gli addebiti

I log persistenti sono gratuiti da usare ma limitati dal piano: 100.000 log su tutti i gateway con Workers Free e 10 milioni per gateway con Workers Paid. Logpush, che esporta quei log altrove, è una funzione del piano Paid, con 10 milioni al mese e 0,05 USD per ogni milione aggiuntivo. Workers AI stesso, secondo la sua pagina dei prezzi, include 10.000 neurons al giorno senza costi e addebita 0,011 USD ogni 1.000 neurons oltre quella soglia sul piano Paid, dove un neuron è l’unità di calcolo GPU di Cloudflare.

La fatturazione unificata costa il 5 per cento

Se usate credenziali gestite da Cloudflare invece delle vostre chiavi del fornitore, gli acquisti di credito portano una commissione del 5 per cento. L’esempio di Cloudflare è un acquisto di credito da 100 USD fatturato 105 USD. L’inferenza viene ribaltata senza ricarico. Se portate la vostra chiave la fatturazione unificata non si applica, perché una richiesta che porta l’autenticazione del fornitore o una chiave memorizzata la salta.

Il controllo dei costi fatto come si deve

Un gateway impone in modo affidabile tre cose: un tasso di richieste, un limite di budget dentro una rotta dinamica e se una richiesta viene servita dalla cache. Tutto il resto di ciò che fa è misura. Confondere le due categorie è il motivo per cui certi team ne installano uno, spuntano ogni casella e restano comunque sorpresi dalla fattura.

Un tetto di budget rigido è una decisione aziendale prima che una configurazione. Qualcosa deve succedere quando il tetto viene raggiunto, e ogni opzione è cattiva a modo suo. Far fallire la richiesta peggiora il prodotto per chi ha chiesto per ultimo, e sembra un bug. Ripiegare su un modello più economico peggiora la qualità in silenzio. Accodare converte un problema di costo in un problema di latenza. Scegliere fra queste opzioni è il vero lavoro.

Il risparmio che arriva a una fattura di solito viene dall’osservabilità più che dall’imposizione. Una volta che la spesa si raggruppa per funzionalità, la cosa cara è quasi sempre risolvibile senza cambiare modello: un prompt di sistema sovradimensionato spedito a ogni turno, l’intera cronologia della conversazione rimandata dove basterebbe un riassunto scorrevole, un ciclo di ritentativi che insiste su un errore che non sarebbe mai riuscito. Un log li trova tutti. Un limitatore di tasso non ne trova nessuno.

La latenza che state aggiungendo

Un salto in più non è gratis, e sostenere il contrario è il modo in cui una buona decisione viene presa per un cattivo motivo. La vostra richiesta ora termina in un data centre di Cloudflare, viene elaborata lì e inoltrata al fornitore, il che aggiunge un handshake TLS e una tratta di rete che prima non pagavate.

Nel caso normale è piccola rispetto a ciò che avvolge. Un completamento conversazionale va da qualche centinaio di millisecondi a diversi secondi ed è dominato dal tempo di generazione, e il gateway sta sulla rete edge di Cloudflare, quindi la prima tratta termina vicino a chi chiama. Contro un completamento di due secondi l’overhead è rumore.

Dove smette di essere rumore è nelle chiamate brevi, economiche e molto numerose. Una richiesta di embedding che torna ben sotto un decimo di secondo è un caso in cui l’overhead fisso diventa una percentuale visibile. Lo streaming è l’altro, perché il numero che gli utenti sentono è il tempo al primo token, e tutto ciò che si aggiunge prima di quel token pesa sulla metrica che conta. Misuratelo dalla durata che il gateway registra, contro la stessa chiamata fatta in diretta.

Strategia multifornitore e il lock-in a cui non sfuggite

La promessa è che un gateway renda i fornitori intercambiabili, e a livello di trasporto è vero. L’endpoint compatibile con OpenAI vi dà una sola forma di richiesta, il routing dinamico vi dà il failover senza un deploy, e cambiare il nome di un modello diventa configurazione invece che codice.

Il livello di trasporto non è mai stato la parte cara. Cambiare modello costa perché i modelli si comportano diversamente. Un prompt di sistema affinato per mesi su un modello produce un altro output su un altro. I formati e l’affidabilità delle chiamate agli strumenti cambiano. Il comportamento di rifiuto cambia, quindi contenuti che prima passavano vengono respinti. L’aderenza a una forma JSON richiesta cambia, e un parser scritto sulle abitudini di un modello si rompe su quelle di un altro. Le finestre di contesto cambiano.

Quello che comprate davvero è che un cambio diventi un pomeriggio di valutazione invece di uno sprint di idraulica, e che il failover in caso di disservizio esista senza che siate voi a costruirlo. Vale la pena averlo, ma non è portabilità. Una dipendenza di secondo ordine merita di essere nominata: il gateway ora sta nel percorso di ogni chiamata al modello, quindi la sua disponibilità diventa la vostra. È lo stesso compromesso che abbiamo esaminato confrontando Cloudflare Workers e AWS Lambda.

Registrare i prompt significa trattare dati personali

Questa è la sezione che viene saltata e quella con un’esposizione legale attaccata. Il logging è attivo per impostazione predefinita su ogni gateway, e una voce contiene per intero il prompt dell’utente e la risposta del modello. Se i vostri utenti scrivono qualcosa su di sé, incollano un documento o descrivono una situazione medica o finanziaria al vostro assistente, quel contenuto è dato personale in un archivio di log di terze parti, e sotto il UK GDPR ne restate voi il titolare.

Oscurate prima che lasci la vostra applicazione

L’unico posto affidabile per rimuovere qualcosa è prima che venga spedito. Il gateway offre cf-aig-collect-log-payload: false per tenere i metadati scartando i corpi, e cf-aig-collect-log: false per non registrare nulla. Ma la minimizzazione dei dati consiste nel non raccogliere più del necessario fin dall’inizio, quindi la correzione duratura sta a monte: togliete numeri di conto, identificativi e campi di testo libero che al modello non servono prima che la richiesta lasci il vostro processo.

La conservazione è una decisione che dovete prendere

La guida dell’ICO sulla limitazione della conservazione non fissa periodi. Richiede che non teniate i dati personali più a lungo del necessario, che sappiate giustificare il periodo scelto, che abbiate una politica con periodi standard e che riesaminiate e poi cancelliate o rendiate anonimo ciò che non vi serve più. Un archivio di log con un tetto legato al piano non è una politica di conservazione, perché un tetto è un limite di spazio e non un periodo giustificato.

Le alternative, nominate con onestà

Ci sono tre alternative vere, e la scelta riguarda soprattutto chi gestisce la cosa.

Un proxy LLM open source auto-ospitato vi dà lo stesso percorso di richiesta con i log su un’infrastruttura che controllate, il che è giusto quando la sensibilità dei prompt è essa stessa il problema. Il costo è gestire un componente sul percorso critico di ogni chiamata al modello.

Un fornitore specializzato in osservabilità degli LLM va più a fondo su valutazione, versionamento dei prompt e ispezione delle tracce. Se il vostro problema è che gli output sono sbagliati e non che i costi sono opachi, quello si adatta meglio, e le due cose non si escludono.

Costruirlo da soli è difendibile quando il bisogno è ristretto. Un wrapper che registra richiesta, risposta, conteggi di token ed etichetta della funzionalità nel vostro stack di osservabilità esistente sono forse due giorni di lavoro e rispondono alla domanda sull’attribuzione. Quello che non otterrete a poco prezzo è la cache con una chiave corretta e il fallback fra fornitori.

La regola: se nessuno sa dove va la spesa, un gateway è la correzione più rapida e il piano gratuito lo dimostra. Se i prompt non devono lasciare la vostra infrastruttura, ospitatelo voi. Se gli output sono sbagliati, nessun gateway aiuta e servono strumenti di valutazione.

Che cosa richiede l’implementazione e che cosa restituisce

Per un singolo servizio che già chiama un fornitore, mezza giornata. Creare il gateway, cambiare l’URL di base nella configurazione, rilasciare dietro un flag così che tornare indietro sia una variabile d’ambiente e non un rilascio, guardare i log riempirsi, confermare che lo streaming si comporta ancora bene.

Per un prodotto vero, mettete in conto da tre a cinque giornate di sviluppo, e la maggior parte non è il gateway. È decidere uno schema di metadati perché l’attribuzione risponda alle domande che porrete davvero, verificare ogni punto di chiamata compresi i lavori pianificati e il codice che nessuno apre da un anno, capire quali endpoint si possono mettere in cache senza rischi e scrivere il passo di oscuramento. Aggiungete un giorno per il routing di fallback, perché un fallback vale la pena solo dopo che avete verificato che il modello di riserva produce un output accettabile.

Il ritorno non è spettacolare. Smettete di essere sorpresi dalla fattura, il che per la maggior parte dei team vale più del risparmio assoluto. Un disservizio del fornitore diventa una risposta degradata invece di un incidente. I team che costruiscono flussi di lavoro con agenti ne traggono il vantaggio maggiore, perché una singola azione dell’utente che si dirama in decine di chiamate al modello è il punto in cui le stime divergono dalla realtà, uno schema che abbiamo trattato in quanto costano gli agenti IA e dove falliscono.

Metterne uno senza rompere la produzione

La sequenza che funziona è noiosa di proposito. Mettete il gateway nel percorso con il logging attivo e nient’altro abilitato. Raccogliete una settimana di dati. Leggete l’attribuzione. Poi abilitate esattamente le funzioni che i dati giustificano, e abilitate la cache per ultima, solo sugli endpoint dove sapete spiegare perché una risposta ripetuta è una risposta corretta.

Mecanik costruisce e gestisce questo livello come parte del nostro lavoro di integrazione IA, e il nostro servizio di integrazione dell’API OpenAI copre il lato fornitore. Gli incarichi cominciano quasi sempre allo stesso modo, con una settimana di logging e nessun’altra modifica, perché i dati di attribuzione di solito riordinano la lista delle priorità.

Domande frequenti

Cloudflare AI Gateway è gratuito? Le funzioni di base sono gratuite su tutti i piani, che la pagina dei prezzi di Cloudflare descrive come analisi da dashboard, cache e limitazione del tasso, e anche la scansione per la prevenzione della perdita di dati è gratuita. Gli addebiti compaiono ai bordi: Logpush è una funzione del piano Paid, i Guardrails sono fatturati come inferenza Workers AI a token, e lo spazio per i log è limitato dal piano invece che tariffato per singolo log.

Un AI gateway aggiunge latenza alle chiamate al modello? Sì, aggiunge un handshake TLS e una tratta di rete. Rispetto a un completamento conversazionale che dura da qualche centinaio di millisecondi a diversi secondi, quell’overhead è di solito trascurabile. Diventa visibile sulle chiamate brevi e molto numerose come gli embedding o le piccole classificazioni, e sulle risposte in streaming dove la metrica che gli utenti sentono è il tempo al primo token invece della durata totale.

Quando non è sicuro mettere in cache le risposte di un LLM? Ogni volta che il valore del prodotto dipende dalla variazione fra le risposte, oppure quando il corpo della richiesta non distingue un utente da un altro. Cloudflare costruisce la chiave di cache da fornitore, endpoint, modello, header di autenticazione e corpo completo, quindi un hit significa una richiesta identica byte per byte. La cache si adatta a classificazione, estrazione ed embedding, non a risposte conversazionali che devono differire per utente.

Un gateway rende facile cambiare fornitore di modelli? A livello di trasporto sì. Una sola forma di richiesta, una sola modifica di configurazione e il failover senza deploy. La parte cara del cambio resta intatta: i prompt affinati su un modello si comportano diversamente su un altro, i formati delle chiamate agli strumenti e il comportamento di rifiuto cambiano, l’aderenza al JSON cambia e le finestre di contesto cambiano. Un gateway toglie l’idraulica, non il lavoro di valutazione.

Che cosa ha cambiato Cloudflare ad agosto 2026? Il 7 agosto 2026, alla fine dell’Agents Week, Cloudflare ha unificato Workers AI e AI Gateway in un unico piano di controllo: un binding IA che copre sia Workers AI sia i fornitori esterni, il routing tramite gateway attivo per impostazione predefinita su Workers AI e crediti spendibili fra fornitori da un unico saldo prepagato. Il routing per modello è stato annunciato come prossimo passo, non rilasciato.