La maggior parte del traffico LLM in produzione non è difficile. È classificazione, estrazione, riscritture brevi e routing, il tipo di lavoro che un modello piccolo e veloce fa correttamente e a basso costo. Eppure il pattern comune è collegare ogni chiamata al modello più grande disponibile, perché "funziona e basta", e poi chiedersi perché sia la bolletta che la latenza sono alte. Su Amazon Bedrock, Claude Haiku 4.5 e Claude Opus 4.5 sono entrambi disponibili, e il vantaggio ingegneristico non sta nello sceglierne uno, sta nell'instradare per classe di task, così il modello economico gestisce la maggioranza e quello costoso è un percorso di escalation, non un default.

Il modo utile di vederla: la scelta del modello è una decisione per task, non una decisione a livello di progetto. Dimensionare ogni richiesta sulla tua richiesta più difficile è lo stesso errore che far girare ogni workload sul tuo tipo di istanza più grande. Right-sizing significa far combaciare il modello con la difficoltà della singola chiamata, e per una grande fetta di chiamate la dimensione giusta è piccola.

Perché il modello grande è il default sbagliato

Puntare di default sul modello frontier sembra sicuro ed è costoso in due dimensioni. I modelli di classe Opus costano diverse volte in più per token di quelli di classe Haiku, quindi un workload che è meccanico al 90 percento paga prezzi frontier per un lavoro che un modello piccolo fa perfettamente. Sono anche più lenti, perché i modelli più capaci in genere impiegano più tempo a rispondere, quindi gonfi la latenza esattamente sulle chiamate ad alto volume e semplici dove gli utenti notano di più la velocità.

Il costo nascosto è che un modello grande su un task semplice raramente produce un risultato migliore. Estrarre una data da un'email o classificare un ticket in una di sei categorie non migliora se ci butti sopra più capacità. Paghi di più e aspetti di più per una risposta che un modello più piccolo avrebbe ottenuto correttamente comunque.

Instrada per classe di task

Il design che funziona è classificare la richiesta per difficoltà e mandarla al modello che ci sta bene. Non per utente, non per funzionalità, per classe di task:

  • Il lavoro meccanico va a Haiku. Classificazione, estrazione, conversione di formato, riassunti brevi, costruzione di argomenti per i tool, e decisioni di routing. Alto volume, bassa ambiguità, e un modello piccolo è sia più economico sia più veloce senza perdita di qualità.
  • Il lavoro di giudizio va a Opus. Ragionamento multi-step, istruzioni ambigue, sintesi a contesto lungo, e tutto ciò dove una risposta sbagliata è costosa. Basso volume, e vale il sovrapprezzo perché la capacità cambia davvero l'esito.
  • Il router stesso è economico. Un'euristica sulla lunghezza dell'input e sul tipo di task, o una singola chiamata a un modello piccolo, decide la classe. Il costo del routing è un errore di arrotondamento rispetto a quanto risparmi non impostando tutto di default sul modello migliore.

Il modello grande come percorso di escalation

Il pattern più affidabile è rendere il modello frontier un'escalation, non una porta d'ingresso. Prova prima il modello piccolo. Se ha successo, e per la maggioranza meccanica lo avrà, hai finito a una frazione del costo e della latenza. Se fallisce un controllo, bassa confidenza, un output non valido rispetto allo schema, un esplicito "non sono sicuro", fai l'escalation di quella singola richiesta al modello più grande.

result = invoke(HAIKU, task)
if not passes_check(result):
    result = invoke(OPUS, task)   # escalate only the hard cases
return result

Questo ribalta l'economia. Invece di pagare prezzi Opus su ogni richiesta per coprire il raro caso difficile, paghi prezzi Haiku sul caso comune e ricorri a Opus solo quando il tentativo economico è visibilmente insufficiente. Il compromesso è una chiamata extra sulla minoranza di richieste che ne ha bisogno, contro un grande risparmio sulla maggioranza che non ne ha bisogno.

Misura prima di assumere la ripartizione

Il punto dove i team sbagliano è indovinare il mix di task invece di misurarlo. Prima di instradare, campiona traffico reale ed etichetta quanto è genuinamente meccanico e quanto è genuinamente difficile. Il numero è quasi sempre più meccanico di quanto il team si aspetti, ed è esattamente per questo che puntare di default sul modello grande spreca così tanto. Ti dice anche dove impostare il trigger di escalation: se il modello piccolo gestisce il 92 percento del traffico in modo pulito, il tuo tasso di escalation dovrebbe essere vicino all'8 percento, e un tasso molto più alto significa che il tuo controllo è troppo severo o il tuo routing è mal calibrato.

Il punto chiave

Sia Haiku che Opus sono su Bedrock da mesi, e il punto non è scegliere tra i due, è usare ciascuno dove è adatto. Instrada per classe di task: manda la maggioranza meccanica al modello piccolo e veloce e riserva il modello frontier alla minoranza che richiede giudizio, idealmente come percorso di escalation innescato da un controllo fallito piuttosto che come default. Misura il tuo mix reale di task prima di tarare la ripartizione. Il model right-sizing è la stessa disciplina dell'instance right-sizing, e il sistema più veloce ed economico è quello che smette di pagare prezzi frontier per un lavoro che un modello piccolo fa correttamente.

Leggi questo dopo

Per il lato platform di routing e capacità tra i modelli, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.