Riduci i costi delle API LLM con processi batch e memorizzazione nella cache dei prompt: un manuale pratico

Molti team pagano più del dovuto per le API LLM perché inviano ogni richiesta attraverso lo stesso percorso sincrono. Ciò è appropriato per chat, assistenti di codifica, agenti di supporto, flussi di pagamento e qualsiasi cosa in attesa di un utente. È uno spreco per valutazioni, tag, arricchimento, controlli di moderazione, incorporamento di backfill, report notturni e pre-elaborazione dei contenuti.

La domanda pratica non è "Quale modello è il più economico?" Si tratta di: quale lavoro necessita effettivamente di una risposta immediata e quale lavoro può attendere? Una volta risposto, il controllo dei costi dell'API AI diventa un flusso di lavoro ingegneristico: classificare il traffico, inviare lavori con tolleranza alla latenza all'elaborazione batch ove supportato, strutturare richieste ripetute per la memorizzazione nella cache e misurare i risparmi reali dopo errori, tentativi e spese generali operative.

Inizia con una verifica dei costi in base al carico di lavoro, non al modello

Prima di modificare l'architettura, esporta un campione dell'utilizzo recente dell'API e raggruppalo per carico di lavoro. Una tabella di controllo utile dovrebbe includere:

• Endpoint e modello: completamenti della chat, risposte, incorporamenti, moderazione o endpoint specifici del provider.
• Token di input e output medi: separa i prompt lunghi dalle attività di classificazione brevi.
• Forma del prompt: istruzioni di sistema stabili, esempi riutilizzabili, schemi, contesto di recupero e dati utente dinamici.
• Requisito di latenza: secondi, minuti, ore o il giorno lavorativo successivo.
• Visibilità dell'utente: se una persona sta aspettando il risultato.
• Tasso di tentativi e errori: richieste non valide, errori di convalida, timeout del provider, processi scaduti e invii duplicati.
• Proprietà: progetto, team, cliente, chiave API o account partner.
• SLA aziendale: l'ultimo momento in cui il risultato è ancora utile.

Questo controllo solitamente rivela che il "traffico LLM" non è un carico di lavoro. Si tratta di un mix di funzionalità interattive del prodotto, automazione interna, reporting, preparazione dei dati e valutazione della qualità. Trattarli come un unico centro di costo nasconde i risparmi più facili.

Utilizza un classificatore del carico di lavoro a tre corsie

Un semplice classificatore impedisce ai team di spostare il traffico sbagliato in batch e di essere poi sorpresi dalle aspettative mancate.

Corsia 1: richieste interattive in tempo reale

Mantienili sincroni. Includono UX di chat, copiloti, agenti di supporto, revisione human-in-the-loop, flussi di ricerca o recupero in tempo reale e chiamate a strumenti con effetti collaterali immediati. Se un utente sta aspettando, il valore di una risposta più economica può essere cancellato dalla latenza.

Raccomandazione: ottimizza questa corsia con la selezione del modello, il taglio rapido, la gestione dei limiti di velocità, la memorizzazione nella cache ove applicabile e tentativi attenti. Non inviarlo a una coda batch di 24 ore a meno che il prodotto non lo presenti esplicitamente come attività in background.

Corsia 2: richieste quasi in linea che possono attendere minuti

Questi lavori non devono necessariamente bloccare il caricamento di una pagina, ma potrebbero comunque avere la stessa sessione o la stessa ora prevista. Gli esempi includono l'analisi del documento post-caricamento, l'arricchimento del CRM dopo l'invio del modulo o un report che può avvisare l'utente quando è pronto.

Raccomandazione: posiziona il lavoro quasi in linea dietro una coda con stati di stato espliciti. A seconda del supporto e della scadenza del fornitore, eseguilo tramite piccoli batch o lavoratori sincroni con priorità inferiore. Questa corsia beneficia di ID lavoro, webhook e progressi visibili all'utente.

Corsia 3: richieste batch offline che possono attendere fino a 24 ore

Questa è la principale via di ottimizzazione dei costi. I buoni candidati includono:

• valutazioni su larga scala;
• etichettatura del set di dati;
• arricchimento catalogo o CRM;
• riepilogo notturno;
• code di revisione della conformità;
• incorporamento di riempimenti;
• moderazione;
• generazione di report periodici;
• pre-elaborazione dei contenuti prima dell'indicizzazione o della pubblicazione.

Fatto: i principali fornitori ora offrono API batch asincrone per carichi di lavoro adeguati. L'API Batch di OpenAI legge le richieste da un file caricato, scrive i risultati in un file di output e mira all'elaborazione entro 24 ore. OpenAI afferma che l'utilizzo supportato dell'API Batch viene offerto con uno sconto sul costo del 50% rispetto alle API sincrone. L'API Message Batches di Anthropic è progettata per grandi volumi di richieste di messaggi, elaborazione asincrona, throughput più elevato e costi inferiori del 50%. L'API Gemini Batch di Google è progettata per richieste asincrone di grandi volumi al 50% del costo standard, con un tempo di consegna target di 24 ore.

Compromesso: "fino a 24 ore" è eccellente per i backfill e le valutazioni, ma inaccettabile per i flussi di lavoro interattivi. Il batch è una strategia di pianificazione, non un sostituto universale dell'inferenza sincrona.

Progetta il percorso batch come ciclo di vita del lavoro

L'errore di implementazione da evitare è trattare il batch come una singola chiamata API. È un ciclo di vita: accettare il lavoro, convalidarlo, persisterlo, inviarlo, sondarlo, riconciliarlo ed esporre i risultati.

Architettura di riferimento

1. Accetta una richiesta normalizzata: mantieni la forma della richiesta vicino al formato API esistente compatibile con OpenAI, ove possibile. Aggiungi metadati come progetto, team, cliente, chiave di idempotenza, scadenza richiesta e centro di costo.
2. Classifica il carico di lavoro: assegna la richiesta al batch in tempo reale, quasi in linea o offline. Questo dovrebbe essere basato su policy, non nascosto nel codice dell'applicazione.
3. Crea un ID lavoro: restituisce immediatamente un identificatore di lavoro per il lavoro Nearline e Offline.
4. Convalida compatibilità: controlla se il provider selezionato e il modello supportano il batch per l'endpoint, la modalità, la dimensione del file, gli strumenti, il formato di risposta e altre funzionalità richiesti.
5. Mantieni righe di richiesta: archivia righe JSONL normalizzate o payload specifici del provider. Includi un ID riga stabile per la riconciliazione.
6. Invia il batch: carica il file di richiesta o il payload batch in linea a seconda dei limiti del provider e delle dimensioni del lavoro.
7. Stato sondaggio: monitora gli stati del fornitore come convalida, in corso, completato, non riuscito, scaduto, annullamento e annullato ove applicabile.
8. Memorizza righe di output: scrivi risposte riuscite, errori a livello di riga, utilizzo dei token, conteggi dei token memorizzati nella cache, ove disponibili, e identificatori del provider.
9. Informa i consumatori: espone un endpoint di recupero, un webhook, una notifica sul dashboard o un avviso di Telegram.
10. Riconcilia la fatturazione: attribuisci il costo al progetto originale, al team, al cliente, alla chiave API e all'ID lavoro.

Questo modello semplifica l'applicazione. I team di prodotto inviano il lavoro e ricevono gli stati del lavoro. Il gateway o il livello di orchestrazione gestisce le differenze tra i provider, i file batch, i tentativi e la contabilità.

Utilizza stati lavoro espliciti

Definisci gli stati interni anche se ciascun provider utilizza nomi diversi:

• in coda: accettato ma non inviato;
• convalida: il provider o il gateway sta controllando il file;
• in esecuzione: inviato e in fase di elaborazione;
• completato: tutti i risultati disponibili raccolti;
• completed_with_errors: alcune righe non hanno superato la convalida o l'esecuzione;
• scaduto: scadenza trascorsa prima che tutte le righe fossero completate;
• annullato: interrotto dall'utente, dal sistema o dalla policy;
• fallito: errore a livello di lavoro che richiede intervento.

Fatto: OpenAI documenta gli stati dei batch tra cui convalida, non riuscito, in_progress, completato, scaduto, annullato e annullato. Si rileva inoltre che se un batch scade, il lavoro già completato viene restituito e addebitato mentre il lavoro rimanente viene annullato.

Raccomandazione: non dare mai per scontato che i processi batch siano tutto o niente. Crea la gestione dello stato a livello di riga dall'inizio.

Calcola i risparmi dopo guasti e spese generali

Un semplice modello di risparmio è sufficiente per la maggior parte dei team:

costo_di_base = costo_input_sincrono + costo_output_sincrono
costo_batch = costo_input_batch_scontato + costo_output_batch_scontato
costo_batch_aggiustato = costo_batch + costo_orchestrazione + costo_archiviazione + costo_riesecuzione
risparmio_stimato = costo_di_base - costo_batch_aggiustato

Quindi calcolalo in base al carico di lavoro, non a livello globale. Una suite di valutazione notturna può far risparmiare sostanzialmente. Un flusso di lavoro quasi in linea con molte righe dal formato errato, fallback urgenti o ripetizioni ripetute potrebbe far risparmiare meno del previsto.

Monitora almeno queste metriche:

• sincronizzazione rispetto alla spesa di token batch;
• token di input e output per modello;
• conteggio dei lavori batch e media di righe per lavoro;
• tasso di errore a livello di riga;
• tariffa lavoro scaduto;
• costo di ripetizione;
• costo di fallback-to-sync;
• costo per team, progetto, chiave, cliente e account partner.

Consiglio: considera il fallback sincrono automatico come un'eccezione e non come un'impostazione predefinita. Protegge le scadenze, ma se abusato può cancellare i risparmi attesi. Aggiungi una norma come "fallback solo se la scadenza aziendale è entro due ore e il lavoro non è iniziato".

Aggiunta la memorizzazione nella cache dei prompt per prefissi lunghi ripetuti

L'elaborazione batch riduce il prezzo unitario del lavoro idoneo. La memorizzazione nella cache dei prompt riduce il costo effettivo e la latenza dei prompt lunghi e ripetuti quando il comportamento del provider lo supporta.

Fatto: la memorizzazione nella cache dei prompt OpenAI si applica automaticamente ai prompt più lunghi di 1.024 token sui modelli supportati, memorizza nella cache il prefisso più lungo calcolato in precedenza e segnala cached_tokens nei dettagli sull'utilizzo dell'API. OpenAI afferma che le cache dei prompt vengono generalmente cancellate dopo 5-10 minuti di inattività e rimosse entro un'ora dall'ultimo utilizzo e che le cache dei prompt non vengono condivise tra le organizzazioni.

Il modello di implementazione è semplice: metti prima i contenuti stabili e poi quelli volatili.

Migliore struttura dei prompt per la memorizzazione nella cache

Istruzioni di sistema
Testo politico stabile
Schema di output stabile
Esempi stabili
Contesto di riferimento riutilizzabile
---
Ingresso dinamico specifico del record
Metadati dinamici di utenti o righe

Ad esempio, un lavoro di arricchimento del catalogo potrebbe riutilizzare la stessa tassonomia, schema di output, regole del marchio ed esempi per 50.000 prodotti. Ogni riga modifica solo il titolo, la descrizione e gli attributi del prodotto. L'inserimento per primo del prefisso riutilizzabile offre al provider maggiori possibilità di riutilizzare il calcolo memorizzato nella cache, ove supportato.

Compromesso: la memorizzazione nella cache non è un'archiviazione permanente e non deve essere trattata come garantita. Le finestre della cache, l'isolamento, la lunghezza minima dei prompt e i report variano in base al provider. Misura i token memorizzati nella cache anziché ipotizzare risparmi.

Convalidare il supporto del fornitore prima dell'invio

Le API batch differiscono. Il gateway dovrebbe convalidare l'idoneità prima di inviare un lavoro.

Fatti: l'API OpenAI Batch non supporta lo streaming e prevede limiti di velocità batch separati. Limitazioni batch di documenti Anthropic, tra cui un limite di dimensione batch di 100.000 richieste o 256 MB, scadenza di 24 ore, disponibilità dei risultati di 29 giorni, limiti di velocità e la possibilità che i batch possano superare leggermente i limiti di spesa dell'area di lavoro configurati. Google supporta richieste batch in linea per lavori più piccoli di dimensioni inferiori a 20 MB e file di input JSONL per richieste batch più grandi.

Utilizza un elenco di controllo di compatibilità:

• Il modello richiesto è disponibile tramite l'API batch di quel fornitore?
• L'endpoint è supportato?
• La richiesta richiede lo streaming? Se sì, rifiuta il lotto.
• Utilizza strumenti o effetti collaterali che devono verificarsi immediatamente?
• Il file batch supera i limiti del provider?
• Il risultato atteso è ancora utile entro la finestra di completamento del fornitore?
• Gli output sono disponibili abbastanza a lungo da consentire ai sistemi a valle di recuperarli?
• Il carico di lavoro può tollerare il completamento parziale?

Raccomandazione: fallire la convalida in anticipo con un motivo chiaro. Un candidato batch rifiutato è più economico di un lavoro scaduto o non valido che deve essere rielaborato in seguito.

Tutela per team, agenzie e partner

I sistemi batch possono tranquillamente spendere molti soldi perché elaborano file di grandi dimensioni in background. Aggiungi controlli prima dell'implementazione generale:

• Budget batch per team: limiti di spesa online e offline separati.
• Dimensione massima del file e numero di righe: applica i limiti del provider e i tuoi limiti operativi.
• Coda di messaggi non recapitabili: conserva le righe non valide con errori di convalida per la revisione.
• Chiavi di idempotenza: impediscono addebiti duplicati derivanti da un nuovo invio accidentale.
• Revisione PII: i file batch possono creare nuovi obblighi di conservazione dei dati e privacy.
• Criterio di conservazione: definisce per quanto tempo vengono archiviati i file di richiesta, i file di output e i registri.
• Politica di notifica: avvisa i proprietari quando i lavori falliscono, scadono o superano il budget.
• Attribuzione: registra progetto, team, cliente, chiave API, modello, fornitore, ID lavoro e ID riga.

Per agenzie e rivenditori, l'attribuzione è particolarmente importante. Se un partner esegue lavori di arricchimento o valutazione per molti clienti, il sistema dovrebbe riportare i costi per cliente e per lavoro, non solo per fattura del fornitore.

Come questo si associa a un gateway API AI

Un gateway API AI è il luogo naturale per implementare tutto ciò perché si trova già tra applicazioni e fornitori di modelli. Il gateway può preservare una superficie API compatibile con OpenAI per gli sviluppatori aggiungendo allo stesso tempo una pianificazione consapevole dei costi.

Le funzionalità utili del gateway includono:

• Fatturazione unificata: confronta la spesa sincrona, batch, memorizzata nella cache e di riserva in un unico posto.
• Analisi dell'utilizzo dell'AI: suddividi l'utilizzo per modello, provider, endpoint, team, progetto e chiave API.
• Controlli del team: imposta budget separati per i carichi di lavoro interattivi e offline.
• Attribuzione chiave API: identifica quale servizio o cliente ha creato ciascun lavoro.
• Notifiche di stato: invia avvisi quando i processi batch vengono completati, falliscono, scadono o si avvicinano a una scadenza.
• Flussi di lavoro API partner: consentono ad agenzie o rivenditori di creare lavori e recuperare risultati per conto dei clienti preservando la contabilità a livello di cliente.

Previsione: più team gestiranno i costi LLM con politiche di pianificazione, non solo sostituzioni di modelli. Man mano che il supporto batch matura tra i fornitori, l'architettura vincente verrà instradata in base all'urgenza, alla compatibilità delle funzionalità e ai requisiti contabili prima di essere instradata in base al prezzo del modello.

Lista di controllo per l'implementazione

• Esporta 30 giorni di utilizzo dell'API LLM.
• Classificare ogni carico di lavoro come in tempo reale, quasi in linea o offline.
• Scegli un carico di lavoro offline con una proprietà chiara e una scadenza permissiva.
• Convalidare il supporto batch del provider per l'endpoint e il modello richiesti.
• Definire gli stati interni del lavoro e gli stati a livello di riga.
• Aggiungi chiavi di idempotenza, ID lavoro e ID per riga.
• Archivia record di richieste e risposte normalizzate con controlli di conservazione.
• Invia il primo batch dietro un flag di funzionalità.
• Misura il costo di base sincrono rispetto al costo batch rettificato.
• Ristrutturare le richieste lunghe e ripetute per mettere prima i prefissi stabili.
• Tieni traccia dei token memorizzati nella cache, delle righe non riuscite, dei processi scaduti e della spesa di riserva.
• Espandere solo dopo che i risparmi e il comportamento operativo sono visibili nelle analisi.

Conclusione attuabile

Non avviare il controllo dei costi dell'API AI chiedendo a ogni team di utilizzare un modello più economico. Inizia separando il lavoro urgente dal lavoro che può aspettare. Mantieni le richieste interattive sincrone. Sposta le valutazioni, gli arricchimenti, i tag, i backfill, i controlli di moderazione e i report in batch quando il supporto del fornitore e le scadenze aziendali si adattano. La struttura ripeteva lunghe richieste di memorizzazione nella cache. Quindi misura i risparmi effettivi dopo errori, ripetizioni, archiviazione e costi di fallback.

La migliore implementazione è volutamente noiosa: ID lavoro, convalida, stati a livello di riga, budget, analisi dell'utilizzo e proprietà chiara. Questo livello operativo è ciò che trasforma gli sconti dei fornitori in risparmi affidabili.

Leggi correlati

• Attribuzione chiave API e controlli della spesa del team
• politiche di routing, nuovi tentativi e fallback per le API LLM
• note relative all'implementazione di Model Gate