Compromessi tra costo e latenza
Qualità, costo e velocità sono in tensione tra loro. Non puoi massimizzarli tutti e tre contemporaneamente — ma puoi spendere ciascuno dove conta e risparmiare ovunque altro.
Il triangolo
Un modello più grande è più intelligente ma più lento e costoso; uno più piccolo è veloce ed economico ma meno capace. La buona ingegneria consiste nel indirizzare ogni task al punto giusto di questo triangolo.
Le leve più importanti (più o meno in ordine)
- Dimensiona correttamente il modello. Non usare Opus per la classificazione. Parti da Sonnet, scendi a Haiku per i passaggi semplici/ad alto volume, riserva Opus per le parti difficili — Scegliere un modello.
- Stratificazione dei modelli / cascate. Usa prima un modello economico; passa a uno più potente solo quando serve (es. casi a bassa confidenza).
- Prompt caching. Riutilizza un prefisso di prompt stabile tra le chiamate — grossi risparmi per system prompt ripetuti, contesto RAG o cataloghi di strumenti degli agenti.
- Riduci i token di input. Invia solo ciò che conta; RAG batte l'inserimento dell'intera base di conoscenza. Input più brevi = più economici e spesso migliori.
- Limita l'output con
max_tokenssensati e istruzioni di formato rigorose. - Esegui in batch il lavoro offline dove la latenza non conta.
Vantaggi specifici per la latenza
- Usa lo streaming per le risposte così che gli utenti vedano subito l'output — enorme per la velocità percepita anche quando il tempo totale è invariato (Streaming).
- Parallelizza le sotto-chiamate indipendenti.
- Usa la cache per il lavoro ripetuto; pre-calcola dove puoi.
- Scegli un modello più piccolo per il percorso interattivo; svolgi il lavoro pesante in modo asincrono.
Non ottimizzare alla cieca
Misura prima: dove vanno davvero i token e i secondi? Poi ottimizza la voce di spesa più grande. E ricontrolla la qualità con gli evals dopo ogni taglio di costo — una configurazione più economica ma sbagliata non è più economica.