TL;DR: real-time e Batch API risolvono problemi diversi. Se una persona aspetta la risposta davanti a WordPress, serve il real-time. Se il risultato può arrivare entro il giorno successivo, il batch taglia il costo dell’inferenza del 50% sulle API OpenAI e Gemini documentate oggi. La mia scelta per una PMI è ibrida: real-time solo per le interazioni con uno SLA breve, batch per classificazioni, audit e lavorazioni editoriali in volume.
Il criterio: tempo utile, non velocità assoluta
Il confronto non parte dal modello. Parte dal momento in cui il risultato diventa utile. Una risposta a una ricerca interna, un assistente nel back office o una verifica richiesta dall’utente perdono valore dopo pochi secondi. La classificazione di 2.000 prodotti, la preparazione di alt text da revisionare o un audit notturno possono aspettare ore senza danneggiare il processo.
Questo è il criterio che conta: latenza richiesta dal lavoro, costo per unità completata e complessità di recupero dagli errori. Scegliere sempre il real-time perché “è più veloce” significa pagare per una velocità che molti processi non usano. Scegliere sempre il batch perché costa meno significa costruire code e polling anche dove una persona sta aspettando.
Approccio A: richieste AI real-time
Nel real-time l’applicazione invia una richiesta e riceve la risposta nella stessa interazione. Con lo streaming, l’API può emettere eventi mentre il modello genera il contenuto: l’interfaccia mostra subito un avanzamento invece di lasciare l’utente davanti a una schermata ferma.
Il vantaggio principale è il feedback. Un utente può correggere il prompt, interrompere un’operazione o scegliere tra due proposte senza uscire dal flusso. Per WordPress è l’approccio giusto in un assistente editoriale, in una ricerca semantica visibile sul sito o in un controllo richiesto manualmente nel back office.
I contro sono operativi. La pagina o l’azione dipendono dalla latenza del provider, dai suoi rate limit e dai timeout della tua infrastruttura. Se la chiamata parte dentro il rendering PHP, un rallentamento esterno diventa un rallentamento del sito. Meglio separare l’interfaccia dalla richiesta con REST/AJAX, mostrare uno stato leggibile e prevedere timeout, annullamento e fallback. Il real-time non elimina la coda: spesso la nasconde dentro una singola richiesta.
Approccio B: Batch API
Il batch accetta molte richieste, le elabora in modo asincrono e rende disponibile un risultato successivo. OpenAI documenta una finestra di completamento di 24 ore con uno sconto del 50%; il file di input può contenere fino a 50.000 richieste. Gemini indica lo stesso rapporto di prezzo rispetto all’API interattiva e un obiettivo di completamento entro 24 ore, spesso più rapido ma non garantito per il singolo job.
Per una PMI il vantaggio non è solo il prezzo. Il batch sposta il lavoro fuori dalla navigazione, assorbe volumi elevati e rende più semplice misurare quante unità sono state completate o fallite. È adatto a descrizioni prodotto, classificazione di ticket, estrazione di campi, valutazioni periodiche e bozze editoriali che verranno comunque revisionate.
Il costo nascosto è l’orchestrazione. Devi creare il job, conservare il suo identificatore, controllarne lo stato, associare ogni output alla richiesta corretta e gestire errori parziali. La documentazione Gemini avverte inoltre che la creazione di un batch non è idempotente: inviare due volte la stessa creazione produce due job. Senza una chiave locale di deduplicazione puoi pagare due volte e applicare due volte lo stesso risultato.
Confronto operativo
| Criterio | Real-time | Batch API |
|---|---|---|
| Tempo di risposta | Secondi, con streaming possibile | Asincrono, fino alla finestra del provider |
| Costo | Prezzo interattivo standard | 50% sulle offerte OpenAI e Gemini verificate |
| Esperienza utente | Adatto a una persona in attesa | Adatto a lavori senza attesa diretta |
| Implementazione | Timeout e fallback per richiesta | Job, polling, mapping, deduplica e retry |
| Errore | Visibile subito sulla singola azione | Può essere parziale dentro un lotto |
Il confronto economico va fatto sul lavoro completato, non sui token acquistati. Un batch al 50% che richiede due giorni di sviluppo, controlli manuali e rilanci duplicati può costare più del real-time su cento richieste mensili. Su decine di migliaia di elementi ripetibili, invece, quella differenza diventa strutturale.
Cosa cambia per WordPress e le automazioni
Su WordPress non affiderei un batch importante al solo WP-Cron di un sito con poco traffico. La documentazione ufficiale ricorda che gli eventi vengono controllati al caricamento delle pagine: se nessuno visita il sito all’ora prevista, l’esecuzione può slittare. Per submit e polling userei un cron di sistema, una coda gestita o l’orchestratore che già governa l’automazione.
Il database deve conservare almeno: identificatore interno dell’item, versione o hash dell’input, job del provider, stato, numero di tentativi, errore e riferimento all’output. Prima di scrivere su WordPress, il worker verifica che la sorgente non sia cambiata. È lo stesso principio della deduplicazione delle richieste AI in WordPress: una risposta corretta applicata alla versione sbagliata resta un errore.
I casi batch più sensati sono quelli già separati dalla pubblicazione: generare bozze di alt text, classificare media, preparare excerpt, controllare link o valutare un archivio. Le bozze di alt text generate con l’AI, per esempio, non devono bloccare l’upload e non vanno pubblicate senza controllo. Il real-time resta utile quando l’editor chiede una proposta su un singolo elemento e vuole valutarla subito.
La mia take: separare lo SLA dal modello
Non costruirei due stack AI distinti. Costruirei un solo livello di validazione, logging e controllo dei permessi, con due modalità di esecuzione. Ogni task dichiara uno SLA: secondi, minuti o entro domani. Solo i task che richiedono secondi passano dal real-time; quelli ripetibili e differibili vanno in batch quando il volume giustifica l’orchestrazione.
Per una PMI partirei real-time su pochi casi ad alto valore, misurerei volume e costo, poi sposterei in batch le lavorazioni stabili. Il batch non è la versione lenta del real-time. È un contratto diverso: rinunci alla risposta immediata in cambio di costo e throughput migliori. Se il processo non sa usare quel tempo, lo sconto non vale nulla.