Non Sposare il Tuo Modello

LLM Routing, una figata pazzesca

La maggior parte dei team di engineering sceglie un modello linguistico e ci resta fedele. Un provider, un modello, tutti i compiti. È come assumere una persona per scrivere codice, fare copywriting e gestire le tasse solo perché è stata brava al primo colloquio.

In ogni momento, un modello è migliore per il codice, un altro per contesti lunghi e complessi, e un altro ancora è il più economico e affidabile per la classificazione. I nomi cambiano. La struttura del problema no. Trattare un modello come se eccellesse in tutto significa pagare troppo per compiti semplici o ottenere risultati scadenti su quelli specializzati.

Ho visto un team bruciare migliaia di dollari eseguendo analisi del sentiment con un modello da 30 dollari per milione di token, quando un modello da 0,50 dollari avrebbe fatto perfettamente il lavoro. Semplice formattazione JSON, compiti di classificazione di base, tutto passava attraverso il loro provider premium. L’unica cosa che si scaldava era il loro conto AWS.

Esiste un modo migliore, e non è particolarmente complicato.

Delega, non Devozione

E se potessi instradare le richieste al modello effettivamente più adatto per quel compito specifico? Usa il tuo potente motore per le cose difficili, ma scarica la semplice analisi e formattazione su qualcosa di più economico. Ottieni i vantaggi di più provider senza doverli gestire manualmente nel tuo codice.

Mastra ti permette di costruire esattamente questo tipo di sistema. Configuri agenti specializzati per diversi tipi di lavoro, poi crei un agente router che decide quale specialista deve gestire ogni richiesta. Gli ID dei modelli qui sotto sono esempi, non una classifica. Sostituiscili con i modelli attuali che vincono i tuoi eval e si adattano al tuo budget.

Pensala così: hai tre specialisti nel tuo team.

import { Mastra } from '@mastra/core';
import { Agent } from '@mastra/core/agent';
import { openai } from '@ai-sdk/openai';
import { anthropic } from '@ai-sdk/anthropic';
import { google } from '@ai-sdk/google';

export const claudeAgent = new Agent({
  id: 'claude-agent',
  instructions: 'You are an expert engineer. Write bugs? You are fired.',
  model: anthropic(process.env.CODE_MODEL ?? 'claude-sonnet-4-5'),
});

export const geminiAgent = new Agent({
  id: 'gemini-agent',
  instructions: 'You are a creative writer. Be weird.',
  model: google(process.env.LONG_CONTEXT_MODEL ?? 'gemini-3-pro-preview'),
});

export const gptAgent = new Agent({
  id: 'gpt-agent',
  instructions: 'You are a helpful assistant. Be boring.',
  model: openai(process.env.GENERAL_MODEL ?? 'gpt-5.2'),
});

Ognuno ha un compito. Il tuo agente per il codice dovrebbe essere il modello che supera i tuoi eval specifici del repository. Il tuo agente per contesti lunghi dovrebbe essere quello che sopravvive ai tuoi documenti veri senza trasformare la parte centrale in zuppa. Il tuo agente generale dovrebbe essere economico, affidabile e noioso nel modo migliore possibile.

Qui le cose si fanno interessanti. Aggiungi un router che funge da proxy intelligente:

export const routerAgent = new Agent({
  id: 'router-agent',
  name: 'The Boss',
  instructions: `You are an intelligent router.
  - Coding -> Claude
  - Poetry -> Gemini
  - Facts -> GPT

  Do not do the work yourself. Delegate.`,
  model: openai(process.env.ROUTER_MODEL ?? 'gpt-5-mini'), // Use a cheap model for routing!
  agents: {
    claudeAgent,
    geminiAgent,
    gptAgent,
  },
});

export const mastra = new Mastra({
  agents: { routerAgent, claudeAgent, geminiAgent, gptAgent },
});

Il router stesso funziona su un modello leggero perché deve solo prendere decisioni su dove inviare il traffico. Non stai pagando tariffe premium per capire quale altro modello premium usare. Anche questo va misurato: un router scadente trasforma silenziosamente i risparmi in instradamenti errati.

Quando qualcuno chiede un’implementazione di bubble sort, il router riconosce che è un lavoro di codice e lo passa al tuo specialista del codice. Prompt di scrittura creativa? Finisce al modello che hai scelto per voce e creatività. Domanda fattuale su eventi storici? Instradala all’agente generale, idealmente con retrieval quando la freschezza o la citazione contano.

I Vantaggi Pratici

L’efficienza dei costi conta più di quanto pensi. Un modello di routing piccolo che prende decisioni di delega costa una frazione dell’inviare ogni singola richiesta al tuo provider più costoso. Con il tempo, specialmente su larga scala, la cifra diventa significativa. Paghi per l’intelligenza pesante solo quando ne hai davvero bisogno.

La qualità migliora quando abbini i modelli ai compiti. Il vincitore cambia ogni mese, a seconda del compito e della forma del prompt. Ecco perché il livello di routing deve dipendere dai tuoi eval, non dal modello che spopolava su Twitter la settimana in cui hai scritto l’integrazione.

La resilienza diventa un beneficio collaterale. Quando OpenAI ha uno dei suoi periodici down (e li ha), il tuo router può reindirizzare il traffico verso altri provider. Non sei fermo in attesa che una specifica API torni online.

Non si tratta di essere furbi per il gusto di esserlo. Si tratta di costruire sistemi che abbiano senso sia dal punto di vista finanziario che tecnico. Non useresti lo stesso martello per ogni compito di costruzione, e probabilmente non dovresti usare lo stesso modello linguistico per ogni compito di IA.

La bellezza di questo approccio è che il codice della tua applicazione non cambia. Continui a chiamare il tuo agente router. La complessità di decidere quale modello usare per quale compito vive in un unico posto, configurato una volta sola, invece di essere sparsa in giro per il codice con una serie di logiche condizionali.

Risorse

• Documentazione Mastra.ai
• Repository GitHub di Mastra

Leggi la Serie

1. LLM Routing (Questo Post)
2. Sicurezza e Guardrails
3. Integrazioni MCP e Strumenti
4. Workflow e Memoria