Passa al contenuto principale

Compromessi tra costo e latenza

Intermedio
What you'll learn
  • Il triangolo costo/qualità/velocità — perché non puoi massimizzare tutti e tre contemporaneamente
  • Le sei leve più grandi per spendere dove conta e risparmiare ovunque altro
  • Come una cascata cheap-first indirizza il 90% del volume a un modello piccolo e taglia i costi del ~70% senza sacrificare la qualità sui casi difficili
  • I vantaggi specifici per la latenza (streaming, parallelismo, caching, async) che ridisegnano la velocità percepita
  • Perché 'ottimizzare alla cieca' brucia qualità — misura prima, difendi con gli evals dopo

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)​

Guided walkthrough1 of 6
  1. 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. La leva singola più grande — vedi /docs/api/choosing-a-model.

Esempio pratico: una cascata cheap-first​

La cascata è la leva che le persone saltano perché suona vaga. Rendiamola concreta. Diciamo che devi triage-are 100.000 email di supporto. L'approccio ingenuo passa ogni email attraverso il tuo modello più forte. Una cascata indirizza la maggior parte del volume a un modello economico ed escala solo i casi difficili:

Supponiamo che il modello economico risolva il 90% dei casi da solo e che un modello più potente costi circa 5× di più per token. Contando in unità di costo relative (1 = una passata cheap su una email):

  • Tutto-forte: 100k × 5 = 500k unità di costo.
  • Cascata: 100k × 1 (ogni email riceve la passata cheap) + 10k × 5 (il 10% che escala) = 150k unità di costo.

Questo è circa un taglio del 70%, e i casi genuinamente difficili ricevono ancora il tuo modello migliore. I moltiplicatori e la ripartizione sono illustrativi — inserisci i tuoi conteggi di token e tariffe e misura il tasso di escalation reale con gli evals. La lezione vale comunque: i risparmi vengono da quanto raramente paghi la tariffa costosa, non dalla tariffa in sé.

Vantaggi specifici per la latenza​

Pro tip
  • Usa lo streaming per le risposte — gli utenti vedono i primi token istantaneamente, quindi la velocità percepita balza anche quando il tempo totale è invariato (/docs/api/streaming).
  • Parallelizza le sotto-chiamate indipendenti — una richiesta che si dirama su tre tool finisce in max(latency), non sum(latency).
  • Usa la cache per il lavoro ripetuto e pre-calcola dove puoi — i token più veloci sono quelli che non devi generare.
  • Scegli un modello più piccolo per il percorso interattivo; sposta il lavoro pesante in modo asincrono così l'utente non aspetta.
  • Riduci max_tokens di output per gli endpoint interattivi — le generazioni lunghe sono la fonte dominante di tail-latency.

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.

Verifica

0/4
  1. Qual è DI SOLITO la leva di costo singola più grande?
  2. In una cascata cheap-first, da dove vengono realmente i risparmi?
  3. Vuoi che l'utente senta una risposta come più veloce. Quale leva aiuta DI PIÙ senza cambiare la scelta del modello?
  4. Hai tagliato i costi passando da Sonnet a Haiku su un workflow. Qual è il prossimo passo richiesto?
Key takeaways
  • Il triangolo è reale: qualità, costo e velocità sono in tensione tra loro — ingegnerizzare significa indirizzare ogni task al punto giusto, non massimizzare tutti e tre.
  • Dimensionare correttamente il modello è la leva singola più grande; le cascate la moltiplicano pagando le tariffe flagship solo sulla minoranza difficile.
  • Prompt caching, max_tokens stretti e trimming degli input guidato da RAG si compongono con la scelta del modello.
  • La percezione della latenza è un asse separato — streaming, sotto-chiamate parallele e lavoro pesante async ridisegnano la UX senza cambiare il costo grezzo.
  • Ogni taglio di costo deve essere difeso dagli evals — una configurazione più economica ma sbagliata non è più economica.

Prossimi passi​