Come creare un modello di routing LLM attento ai costi senza sacrificare la qualità

L'instradamento del modello LLM attento ai costi non dovrebbe significare l'invio di ogni richiesta al modello più economico disponibile. Ciò crea una modalità di fallimento silenziosa: le fatture migliorano per alcune settimane, poi i team di prodotto scoprono schemi non funzionanti, ragionamenti più deboli, tono incoerente o bozze di supporto che richiedono una maggiore pulizia umana.

Il modello migliore è una policy di routing supportata da eval. Classificare la richiesta, definire la qualità minima accettabile per tale attività, rimuovere i percorsi che non possono soddisfare i vincoli di capacità o governance, stimare l'economia del percorso e quindi scegliere il modello ammissibile dal costo più basso. La decisione sul routing diventa spiegabile durante una revisione dei costi perché è legata a una versione della policy, non alle preferenze dello sviluppatore o a una vaga impostazione predefinita del provider.

Che cosa sta ottimizzando il routing basato sui costi

Un router pratico ottimizza il percorso più economico che soddisfa comunque i requisiti operativi dell'attività. Questo è diverso dall'ottimizzazione per il modello più economico.

Fatti: i principali fornitori di modelli pubblicano i prezzi dei token con dimensioni separate come token di input, token di input memorizzati nella cache, token di output, memorizzazione nella cache dei prompt ed elaborazione batch. Alcuni provider espongono anche campi di utilizzo che segnalano il comportamento del token memorizzato nella cache. Ciò significa che l'opzione dal costo più basso può cambiare in base alla forma del prompt, alla lunghezza dell'output prevista, all'idoneità della cache e alla possibilità di eseguire il carico di lavoro in modo asincrono.

Raccomandazione: considera il routing come un problema di policy all'interno di un AI multi-modello API gateway, non come un'istruzione switch a livello di applicazione. Il gateway visualizza record di capacità del provider, regole del tenant, API metadati chiave, tabelle dei prezzi, telemetria sull'utilizzo e comportamento di fallback in un unico posto.

Previsione: i team che mantengono la logica di routing sparpagliata nei repository delle applicazioni avranno difficoltà a spiegare le variazioni dei costi in un secondo momento. Potrebbero comunque ridurre la spesa, ma avranno prove più deboli del motivo per cui una determinata richiesta ha utilizzato un determinato modello.

Inizia con le classi di attività, non con i nomi dei provider

Il router necessita di un'etichetta del carico di lavoro prima di poter prendere una decisione utile. Un singolo modello predefinito non può rappresentare il profilo di rischio di ogni richiesta.

Le classi di attività utili includono:

• Estrazione: converte testo non strutturato in campi, spesso con una rigorosa convalida dello schema.
• Classificazione: assegna etichette, priorità, intenti, opinioni o categorie di routing.
• Riepilogo: comprime input lunghi preservando fatti e decisioni chiave.
• Bozza dell'assistenza clienti: genera una risposta che un essere umano può rivedere o inviare.
• Sintesi delle risposte RAG: risposta dal contesto recuperato con citazione o requisiti di base.
• Revisione del codice: ispeziona le differenze o i file sorgente per verificare la correttezza, i rischi o i problemi di stile.
• Analisi del contesto lungo: ragiona su contratti, trascrizioni, registri, norme o pacchetti di ricerca.
• Supporto decisionale ad alto impatto: qualsiasi flusso di lavoro in cui una risposta errata potrebbe incidere sul denaro, sulla conformità, sulla sicurezza o sulla fiducia dei clienti.

La classe dell'attività può provenire da metadati di richiesta esplicita, un ambito chiave API, un percorso dell'applicazione o un classificatore leggero. I metadati espliciti sono solitamente migliori che dedurre l'intento dal testo dei prompt, poiché prompt vaghi costringono il router verso valori predefiniti conservativi.

Associa un livello di qualità a ciascuna attività

Il routing basato sui costi funziona solo se ogni attività ha un livello di qualità minimo. Senza uno, il router non ha un modo di principio per rifiutare un modello più economico.

Un livello di qualità può includere diversi controlli:

• Set di valutazione riproducibile: esempi rappresentativi di sviluppo e produzione, privati dei dati sensibili dove richiesto.
• Validità dello schema: l'output deve essere analizzato, convalidato rispetto allo schema canonico ed evitare campi non supportati.
• Criteri di contenuto: la risposta deve seguire le regole di stile, rifiuto, motivazione e completezza dell'attività.
• Criteri di sicurezza: l'output non deve divulgare istruzioni nascoste, ignorare i limiti delle policy o eseguire istruzioni non attendibili dal contenuto recuperato.
• Revisione umana: richiesta per flussi di lavoro ad alto impatto o per la promozione di un nuovo percorso.
• Soglia di regressione: il percorso candidato deve soddisfare o superare il percorso corrente nelle categorie di errori critici, non solo nel punteggio medio.

Fatto: la documentazione del fornitore descrive le valutazioni come un modo per testare gli output del modello rispetto a criteri di contenuto e stile specificati. È prevista la dismissione di un prodotto di valutazione ospitato, pertanto i sistemi di routing dovrebbero archiviare set di dati di valutazione, output previsti, rubriche di valutazione e risultati indipendenti dal provider anziché dipendere da una superficie di valutazione ospitata dal provider.

Raccomandazione: archivia i risultati di valutazione per classe di attività, modello, versione dell'adattatore del provider, versione del prompt, versione dello schema e versione di valutazione. Una rotta non dovrebbe diventare ammissibile semplicemente perché il modello è nuovo o più economico. Diventa idoneo quando supera il limite di qualità corrente dell'attività.

Crea un registro delle capacità del provider

Prima di stimare i costi, rimuovi eventuali percorsi che non possono soddisfare la richiesta. Questo passaggio impedisce al router di selezionare un modello economico privo delle funzionalità richieste.

Un record di capacità dovrebbe includere:

• Modalità di input e output supportate.
• Limiti della finestra di contesto.
• Output strutturato e supporto per le chiamate agli strumenti.
• Supporto streaming.
• Richiedi il supporto della memorizzazione nella cache e la disponibilità della telemetria nella cache.
• Batch API supporto.
• Opzioni di elaborazione regionali.
• Termini relativi alla conservazione dei dati e al monitoraggio degli abusi che sono importanti per le tue norme.
• Dimensioni del limite di velocità e capacità attuale.
• Differenze note dei contratti di output nel livello dell'adattatore.

Questo registro deve essere gestito separatamente dalle richieste dell'applicazione. Appartiene al livello di routing e adattatore del provider, dove il sistema può confrontare i modelli senza diffondere presupposti specifici del provider in ogni applicazione.

Stima del costo del percorso prima della selezione

Il router non può conoscere il costo finale prima dell'esecuzione, ma può stimarlo abbastanza bene da poter scegliere tra i percorsi idonei. La stima dovrebbe includere le variabili che effettivamente muovono la fattura.

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

Utilizza la telemetria recente per stimare i token di output per classe di attività. Ad esempio, le attività di estrazione potrebbero avere una lunghezza di output limitata, mentre l'analisi del contesto lungo può variare notevolmente. Gli agenti che utilizzano gli strumenti potrebbero avere costi nascosti aggiuntivi legati alla pianificazione delle chiamate allo strumento, ai nuovi tentativi e ai messaggi intermedi.

La stima dei costi dovrebbe tenere conto anche dell'idoneità della cache e del batch:

• Idoneità alla cache: prefisso del prompt stabile, istruzioni di sistema riutilizzabili, contesto recuperato ripetuto, comportamento del provider supportato e sufficiente probabilità di riscontro nella cache.
• Idoneità batch: il carico di lavoro può attendere, ha una gestione delle richieste idempotente, dispone di un monitoraggio duraturo dei lavori e non necessita di streaming interattivo.
• Rischio token di output: il modello tende a produrre risposte più o meno lunghe per la stessa attività e il troncamento danneggerebbe la qualità.
• Rischio di nuovi tentativi: il provider o il modello presenta tassi di errore elevati, tassi di riparazione dello schema o errori di latenza per questa attività.

È qui che il routing dei costi si collega alla più ampia gestione dei costi LLM. La tabella dei prezzi da sola non è sufficiente. Il router necessita di metadati di richiesta, struttura dei prompt, misurazioni dei riscontri nella cache e dati di utilizzo stabiliti per sapere se i risparmi previsti si sono effettivamente verificati.

Utilizza livelli di modello anziché un valore predefinito globale

Una norma a più livelli è più facile da spiegare rispetto a un lungo elenco di eccezioni specifiche del provider. Ogni livello deve contenere uno o più modelli idonei che hanno superato i cancelli specifici dell'attività.

Non lasciare che il livello sostituisca le valutazioni. Un modello può essere economico per la classificazione ma inadatto alla stesura di supporto. Un altro modello può essere efficace per il riepilogo ma troppo costoso per un tagging deterministico breve.

Percorso con una sequenza decisionale esplicita

Un router attento ai costi dovrebbe essere sufficientemente deterministico per eseguire il debug. L'implementazione esatta varia, ma la sequenza decisionale dovrebbe essere stabile.

1. Leggi tenant, API chiave, ambiente e metadati dell'applicazione.
2. Identifica la classe dell'attività dai metadati espliciti o dall'output del classificatore.
3. Carica la versione della policy di routing per quel tenant o quell'area di lavoro.
4. Applica vincoli di governance come conservazione dei dati, regione, lista consentita dei modelli e limitazioni delle funzionalità.
5. Filtra in base alle funzionalità richieste: lunghezza del contesto, strumenti, output strutturato, streaming, modalità e supporto batch.
6. Filtra in base al livello qualitativo minimo supportato da valutazione per la classe dell'attività.
7. Stima dei costi utilizzando token di input, token di output previsti, idoneità della cache, idoneità batch e rischio di nuovi tentativi.
8. Applica la politica di budget e le preferenze del tenant.
9. Seleziona il percorso idoneo al costo più basso.
10. Allega percorso di fallback, timeout, nuovo tentativo e policy di riparazione.
11. Registra la decisione con un codice motivo stabile.

In pseudocodice, il router dovrebbe assomigliare più a una valutazione della policy che a una preferenza del provider codificata:

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

Registra ogni decisione sul routing

Se il reparto finanziario chiede perché è stato utilizzato un modello premium o il reparto tecnico chiede perché la qualità è diminuita, il router dovrebbe rispondere in base ai log. Non fare affidamento sulla ricostruzione dell'intento in base alle istruzioni a posteriori.

Registra questi campi per ogni richiesta:

• ID richiesta, ID tenant, API ID chiave, ID applicazione e ambiente.
• Risultato e confidenza del classificatore di attività.
• Versione criteri di routing.
• Versione del set di dati di valutazione e gate di qualità utilizzati.
• Modelli idonei e modelli rifiutati.
• Motivo per cui ogni modello rifiutato è stato escluso.
• Input stimato, input memorizzato nella cache e token di output.
• Costo stimato del percorso e costo finale stabilito quando disponibile.
• Fornitore, modello, versione dell'adattatore e livello selezionati.
• Percorso di fallback e policy di nuovo tentativo.
• Memorizza nella cache la telemetria dei risultati positivi o negativi quando disponibile.
• Modalità di esecuzione batch e sincrona.
• Convalida dello schema, tentativi di riparazione, stato di rifiuto e indicatori di sicurezza.

Questi log supportano anche LLM API attribuzione dei costi, poiché la selezione del modello è solo una parte della spesa. I team devono ancora allocare i costi per tenant, area di lavoro, chiave, prodotto, flusso di lavoro o cliente.

Aggiungi controlli di deriva prima di promuovere percorsi più economici

Comportamento del modello, prezzi, richieste e mix di carichi di lavoro cambiano. Un percorso che era sicuro il mese scorso potrebbe diventare debole dopo una tempestiva revisione o aggiornamento del modello.

Un ciclo di controllo della deriva di base dovrebbe includere:

• Esempio di richieste di produzione recenti per classe di attività.
• Rimuovi o trasforma i dati sensibili in base alle norme.
• Riproduci gli esempi attraverso i percorsi attuali e candidati.
• Confronta qualità, validità dello schema, comportamento di rifiuto, costo e latenza.
• Esamina gli errori per categoria, non solo per punteggio aggregato.
• Promuovi il percorso più economico solo se soddisfa i requisiti di qualità e i vincoli operativi.
• Canary il nuovo percorso per una piccola percentuale di traffico.
• Esegui il rollback automatico in caso di errore dello schema, superamento dei costi, violazione della latenza o escalation di revisione umana.

Raccomandazione: rendi la promozione del percorso un evento di gestione del cambiamento. Registra chi l'ha approvato, quale set di valutazione ha superato, quale percentuale di traffico influisce, quando scade o necessita di revisione e come funziona il rollback.

Fornisci override ai team, ma falli scadere

Esistono motivi legittimi per ignorare il routing: incidente del fornitore, emergenza di budget, revisione della conformità, riassegnazione del cliente o regressione del modello. Il problema non è l'override. Il problema è una sostituzione che diventa una policy permanente invisibile.

Ogni sostituzione deve includere:

• Ambito: tenant, applicazione, chiave API, classe di attività, modello, provider o regione.
• Motivo: incidente, budget, qualità, conformità, latenza o richiesta del cliente.
• Approvatore.
• Ora di inizio e ora di scadenza.
• Impatto previsto su costi, latenza e qualità.
• Condizione di ripristino.

Le sostituzioni scadute dovrebbero non riuscire a chiudersi in base al normale criterio di routing o richiedere il rinnovo. Ciò evita che le decisioni di emergenza diventino costi nascosti o rischi per la qualità.

Compromessi da rendere espliciti

Il routing basato sui costi ha costi operativi reali. Vale comunque la pena farlo quando la spesa LLM è significativa, ma i compromessi dovrebbero essere visibili.

• Dipendenza dai metadati: la qualità del routing dipende da etichette precise delle attività e metadati del carico di lavoro. Le etichette mancanti spingono il traffico verso valori predefiniti conservativi.
• Manutenzione valutazione: le valutazioni delle attività necessitano di aggiornamenti man mano che i prompt, i prodotti e il comportamento degli utenti cambiano.
• Complessità del provider: gli sconti cache e batch possono migliorare i costi ma rendere la logica di routing più complessa.
• Rischio di portabilità: le funzionalità specifiche del provider dovrebbero risiedere negli adattatori e nei record di capacità, non nel codice prodotto.
• Incertezza della stima: la lunghezza dell'output finale, le chiamate agli strumenti, i nuovi tentativi e gli hit della cache non sono completamente noti prima dell'esecuzione.
• Onere di spiegabilità: un'ottimizzazione aggressiva può rendere difficile spiegare il comportamento del prodotto a meno che ogni decisione non venga registrata con la versione della policy e i codici motivo.

Elenco di controllo per l'implementazione

• Definisci classi di attività per i principali flussi di lavoro LLM in base alla spesa e all'impatto aziendale.
• Crea set di valutazione e livelli di qualità per ogni classe di attività.
• Crea un registro delle capacità del provider e del modello.
• Memorizza le tabelle dei prezzi correnti e i modificatori dei prezzi per fornitore, modello e modalità di esecuzione.
• Stima i token di input, i token di output previsti, l'idoneità della cache, l'idoneità del batch e il rischio di nuovi tentativi.
• Filtrare i candidati in base ai vincoli di governance prima dell'ottimizzazione dei costi.
• Seleziona il modello dal costo più basso solo dopo aver superato i criteri di capacità e qualità.
• Registra i percorsi selezionati e rifiutati con i codici motivo.
• Confronta il costo stimato con l'utilizzo saldato e i dati della fattura.
• Esegui valutazioni periodiche di riproduzione prima di promuovere tratte più economiche.
• Modifiche al percorso Canary e definizione di trigger di rollback.
• Richiedi date di scadenza per le sostituzioni manuali.

Conclusione

L'obiettivo pratico non è indirizzare ogni richiesta a un modello più economico. L'obiettivo è smettere di pagare più del dovuto per il lavoro di routine, tutelando al tempo stesso la qualità, i contratti, le regole di governance e la spiegabilità.

Costruisci il router in base a classi di attività, livelli di qualità, capacità del fornitore, stime dei costi e log delle norme. Quindi scegli la rotta idonea al costo più basso. Quella sola parola, idoneo, è ciò che distingue il routing basato sui costi dal routing del modello più economico.

Leggi correlati

• Limiti di spesa a livello di gateway