Amazon Bedrock fa girare la batch inference al 50 percento del prezzo dei token on-demand, e l'unica cosa a cui rinunci è l'immediatezza. Invii un file di richieste, il job gira in modo asincrono quando c'è capacità, e raccogli i risultati più tardi. Per qualsiasi workload dove nessun umano è seduto lì ad aspettare la risposta, pagare il prezzo pieno per l'inferenza in tempo reale significa lasciare metà dei soldi sul tavolo per una velocità di cui nessuno aveva bisogno.

L'errore è impostare per default ogni chiamata al modello sul percorso sincrono in tempo reale solo perché è così che è stato scritto il primo prototipo. La chat interattiva deve essere in tempo reale. Un job notturno che classifica i ticket di supporto di ieri no. Sono requisiti di latenza diversi, e Bedrock li prezza diversamente. La domanda ingegneristica è semplicemente quali dei tuoi workload hanno davvero bisogno di una risposta subito rispetto a quali ne hanno bisogno prima o poi.

Come funziona il batch su Bedrock

La batch inference è un job, non una chiamata. Il flusso è deliberatamente noioso:

1. write requests as JSONL to S3   (one record per line)
2. create a batch inference job     (input S3 -> output S3)
3. job runs asynchronously          (minutes to hours)
4. read results from the output S3 prefix

Ogni record di input porta un record ID e lo stesso input di modello che invieresti in tempo reale. L'output viene scritto su S3, un risultato per input, indicizzato da quel record ID così puoi associare i risultati agli input. Non c'è endpoint da tenere caldo, nessuna concorrenza da regolare, nessun throttling da intercettare. Scambi il ciclo richiesta-risposta con un ciclo invia-e-raccogli, e ottieni la tariffa scontata per aver accettato che il job finisca secondo i tempi del servizio, non i tuoi.

Dove la latenza davvero non conta

I workload che si adattano sono quelli in cui il risultato alimenta un processo, non una persona che aspetta davanti allo schermo:

  • Classificazione ed etichettatura di massa. Categorizza un arretrato di documenti, ticket o prodotti. La risposta finisce in un database, non davanti a un utente.
  • Pipeline di arricchimento. Riassunti, estrazioni o embedding generati in anticipo e memorizzati, così il percorso in tempo reale legge semplicemente un valore precalcolato.
  • Valutazione offline. Punteggio di un modello o di una modifica al prompt su migliaia di casi di test. È un report, e i report possono aspettare un'ora.
  • Reportistica periodica. Qualsiasi cosa che gira su una pianificazione e produce un output che un umano legge più tardi, non istantaneamente.

Il filo comune: la scadenza è misurata in ore, e il volume è abbastanza grande che dimezzare il prezzo dei token è denaro vero e non un arrotondamento.

La matematica del costo

Lo scambio è netto quando lo metti sulla carta. Prendi un job di un milione di record, ciascuno con un costo medio fisso in token:

Real-time path:
  1,000,000 requests x on-demand token price
  + endpoint kept responsive
  + throttling handling under load

Batch path:
  1,000,000 records x (0.5 x on-demand token price)
  + S3 storage (negligible)
  + the willingness to wait

La colonna batch è metà della bolletta dei token e meno superficie operativa, perché non c'è un endpoint dal vivo da proteggere da un picco. Il punto di pareggio non riguarda il volume, riguarda la scadenza. Se la risposta può aspettare, il batch vince sia sul costo che sulla semplicità. Se non può, nessuno sconto rende accettabile un job asincrono.

Quando il batch è lo strumento sbagliato

Non forzarlo dove la forma non si adatta. Il batch è sbagliato quando un utente sta aspettando l'output, quando una richiesta dipende dal risultato di quella precedente, o quando il job è abbastanza piccolo che lo sconto è irrilevante e la meccanica asincrona non vale la pena. È sbagliato anche come soluzione di ripiego per il throttling: se il tuo traffico in tempo reale viene limitato, la soluzione è la pianificazione della capacità e il prompt caching, non spingere richieste interattive attraverso un job che restituisce ore dopo. Il batch è per lavoro che era comunque destinato a essere rimandato, non per nascondere un problema di latenza.

Il punto chiave

Metà di una grande bolletta di token vale un'architettura che la maggior parte dei team ha già in giro: scrivi su S3, invia un job, leggi i risultati più tardi. Lo sconto non è ingegnoso, è semplicemente pagare per capacità differita invece che per capacità on-demand. Audita le tue chiamate al modello e ordinale per chi sta aspettando. Tutto ciò che ha un umano dall'altra parte resta in tempo reale. Tutto il resto, la classificazione, l'arricchimento, la valutazione e la reportistica che alimenta una pipeline anziché una persona, appartiene a un job batch con il 50 percento di sconto. I risparmi sono nascosti nei workload che non hai mai messo in discussione.

Da leggere ora

Per il playbook più ampio di ottimizzazione dei costi e delle pipeline su AWS, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.