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 tramite 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 data la risposta, il controllo dei costi dell'AI API 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 sovraccarico operativo.

Inizia con un controllo dei costi in base al carico di lavoro, non al modello

Prima di modificare l'architettura, esporta un campione dell'utilizzo recente 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à utente: se una persona sta aspettando il risultato.
• Tasso di tentativi e errori: richieste con formato non valido, errori di convalida, timeout del provider, processi scaduti e invii duplicati.
• Proprietà: progetto, team, cliente, API chiave 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 rimanere poi sorpresi da aspettative deluse.

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.

Consiglio: ottimizza questa corsia con la selezione del modello, il taglio dei prompt, 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 dopo il caricamento, l'arricchimento del CRM dopo l'invio del modulo o un report che può avvisare l'utente quando è pronto.

Raccomandazione: posiziona il lavoro Nearline 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 del catalogo o del CRM;
• riepilogo notturno;
• code per la revisione della conformità;
• incorporamento dei backfill;
• spostamenti di 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 adatti. Il batch API 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 del batch supportato API viene offerto con uno sconto sul costo del 50% rispetto alle API sincrone. I batch di messaggi API di Anthropic sono progettati per grandi volumi di richieste di messaggi, elaborazione asincrona, throughput più elevato e costi inferiori del 50%. Il Gemini Batch API di Google è progettato 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, eseguire il polling, riconciliarlo ed esporre i risultati.

Architettura di riferimento

1. Accetta una richiesta normalizzata: mantieni la forma della richiesta vicino al formato esistente OpenAI-compatibile API 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. Dovrebbe essere basato su policy e non nascosto nel codice dell'applicazione.
3. Crea un ID lavoro: restituisce immediatamente un identificatore 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: memorizza 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 dove disponibili e identificatori del provider.
9. Invia notifica ai consumatori: espone un endpoint di recupero, un webhook, una notifica sul dashboard o un Telegram avviso.
10. Riconcilia la fatturazione: attribuisce 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 nuovi tentativi e la contabilità.

Utilizza stati lavoro espliciti

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

• queued: accettato ma non inviato;
• validating: il provider o il gateway sta controllando il file;
• running: inviato e in fase di elaborazione;
• completed: tutti i risultati disponibili raccolti;
• completed_with_errors: alcune righe non hanno superato la convalida o l'esecuzione;
• expired: scadenza superata prima che tutte le righe fossero completate;
• cancelled: interrotto dall'utente, dal sistema o dal criterio;
• failed: errore a livello di lavoro che richiede intervento.

Fatto: OpenAI documenta gli stati dei batch, tra cui convalida in corso, non riuscito, in_progress, completato, scaduto, annullato e annullato. Si nota 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:

baseline_cost = synchronous_input_cost + synchronous_output_cost
batch_cost = discounted_batch_input_cost + discounted_batch_output_cost
adjusted_batch_cost = batch_cost + orchestration_cost + storage_cost + rerun_cost
estimated_savings = baseline_cost - adjusted_batch_cost

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 non valido, fallback urgenti o ripetizioni ripetute potrebbe far risparmiare meno del previsto.

Monitora almeno queste metriche:

• sincronizzazione rispetto alla spesa in batch dei token;
• token di input e output per modello;
• conteggio dei lavori in batch e media di righe per lavoro;
• tasso di errori a livello di riga;
• tasso di lavoro scaduto;
• costo della replica;
• costo di riserva per la sincronizzazione;
• costo per team, progetto, chiave, cliente e account partner.

Raccomandazione: considera il fallback sincrono automatico come un'eccezione, non come l'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".

Aggiungi 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: OpenAI la memorizzazione nella cache dei prompt 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 riporta cached_tokens in API dettagli sull'utilizzo. 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

System instructions
Stable policy text
Stable output schema
Stable examples
Reusable reference context
---
Dynamic record-specific input
Dynamic user or row metadata

Ad esempio, un processo di arricchimento del catalogo potrebbe riutilizzare la stessa tassonomia, schema di output, regole del brand 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 una migliore 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.

Convalida il supporto del fornitore prima dell'invio

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

Fatti: OpenAI Il batch API non supporta lo streaming e ha limiti di velocità batch separati. Anthropic documenta le limitazioni dei batch, 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 inferiori a 20 MB e file di input JSONL per richieste batch più grandi.

Utilizza un elenco di controllo della compatibilità:

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

Raccomandazione: fallisci 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 su vasta scala:

• 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 potrebbero creare nuovi obblighi in materia 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 log.
• Criterio di notifica: avvisa i proprietari quando i processi non riescono, scadono o superano il budget.
• Attribuzione: registra progetto, team, cliente, API chiave, 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 viene associato a un AI API gateway

Un gateway AI API è il luogo naturale in cui implementare questa funzionalità perché si trova già tra applicazioni e fornitori di modelli. Il gateway può preservare una superficie OpenAI-compatibile API per gli sviluppatori aggiungendo al contempo 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: suddivide l'utilizzo per modello, provider, endpoint, team, progetto e API chiave.
• Controlli del team: imposta budget separati per i carichi di lavoro interattivi e offline.
• API-attribuzione chiave: 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.
• Partner API flussi di lavoro: consenti 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.

Elenco di controllo per l'implementazione

• Esporta 30 giorni di utilizzo LLM API.
• Classifica ogni carico di lavoro come in tempo reale, quasi online o offline.
• Scegli un carico di lavoro offline con una proprietà chiara e una scadenza permissiva.
• Convalida il supporto batch del provider per l'endpoint e il modello richiesti.
• Definisci gli stati interni del processo 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 previsto sincrono rispetto al costo batch rettificato.
• Ristruttura le richieste lunghe e ripetute per mettere prima i prefissi stabili.
• Monitora i token memorizzati nella cache, le righe non riuscite, i job scaduti e la spesa di riserva.
• Espandi solo dopo che i risparmi e il comportamento operativo sono visibili nelle analisi.

Conclusione attuabile

Non avviare il controllo dei costi dell'AI API 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

• API controlli chiave di attribuzione e spesa del team
• politiche di routing, nuovi tentativi e fallback per le API LLM
• correlato Model Gate note di implementazione