Aggiungere un router a un sistema agentico sembra una vittoria facile: mandare le richieste semplici a modelli più economici, tenere quelli costosi per i task difficili, oppure instradare per specializzazione. Un classificatore decide, i costi scendono, le performance restano. In un post su Hugging Face, il team di IBM Research spiega perché nella pratica non è così semplice: quello che sembra un problema di model selection diventa in fretta un problema di ottimizzazione di sistema.
Il costo non è solo il prezzo del modello
Su 417 task dell’AppWorld Test Challenge con lo stesso agente CodeAct, Claude Sonnet 4.6 è costato 79 dollari totali (0,19 per task) mentre GPT-4.1 ne è costati 155 (0,37 per task), quasi il doppio. Sulla carta non ha senso: il prezzo per token di GPT-4.1 è più basso sia in input sia in output, e Sonnet usa circa tre volte i reasoning step per completare gli stessi task. La spiegazione è il caching: i workload agentici riusano grandi porzioni di contesto tra uno step e l’altro, e il prezzo di cache-read più basso di Sonnet ha ribaltato il conto. Il costo reale dipende dall’interazione tra modello, workload e serving infrastructure, non dai listini.
Complessità e latency non sono quello che sembrano
Stimare la difficoltà di un task e mandarlo al modello più forte è intuitivo, ma spesso la difficoltà è invisibile al momento del routing: un “riassumi questo contratto” può innescare retrieval, compliance check e più round di refinement. E anche stimandola bene resta un solo segnale: in produzione il router deve bilanciare costo, latency, specializzazione e affidabilità, con in più i vincoli enterprise di data residency, privacy e liste di modelli approvati. Anche la latency non dipende solo dalla dimensione del modello: overhead del routing, hardware, cache calda e carico dell’endpoint dominano spesso il tempo end-to-end.
La svolta, secondo IBM Research, è smettere di trattare il routing come classificazione e trattarlo come ottimizzazione simultanea di costo, qualità e latency. Sull’AppWorld Test Challenge la configurazione ottimizzata per la latency raggiunge l’84% di accuratezza a 93 dollari e 83 secondi: una riduzione di costo del 21% e di latency del 9% rispetto al solo Opus, con un calo di accuratezza del 4%. L’ottimizzazione resta leggera, circa 6 ms e 2 kB di memoria per task, così il router non diventa a sua volta il collo di bottiglia.
- Il costo effettivo di un modello emerge solo misurando cache hit rate e trajectory sul workload reale, non dai prezzi per token.
- Un router di produzione bilancia costo, qualità, latency e vincoli di governance insieme, non un solo segnale di difficoltà.
- Trattare il routing come ottimizzazione dà una frontiera di operating point tra cui scegliere secondo la priorità del momento.
Fonte: Model Routing Is Simple. Until It Isn’t. — https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt
Hai qualcosa da aggiungere? Unisciti alla discussione.