Non sposare il tuo modello

LLM Routing, così di tendenza adesso

La maggior parte dei team ingegneristici sceglie un modello linguistico e ci resta. Un provider, un modello, tutti i compiti. È come assumere una persona per scrivere codice, copywriting e tasse perché è risultata brava al primo colloquio.

In qualsiasi momento, un modello è migliore nel codice, un altro è migliore con contesti lunghi e disordinati, e un altro ancora è il cavallo da lavoro più economico e noioso per la classificazione. I nomi cambiano. La forma del problema no. Trattare un modello come se eccellesse in tutto significa che stai spendendo troppo per compiti semplici o ottenendo risultati inferiori su quelli specializzati.

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

C’è un modo migliore, e non è particolarmente complicato.

Delegare, non adorare

E se potessi instradare le richieste al modello effettivamente più adatto per quel compito specifico? Usa il tuo powerhouse costoso per le cose difficili, ma scarica la formattazione e il parsing semplici su qualcosa di più economico. Ottieni i vantaggi di provider multipli senza doverli gestire manualmente nel tuo codebase.

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

Pensalo 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 lavoro. Il tuo agente di codice dovrebbe essere il modello che supera le tue eval specifiche per il repository. Il tuo agente per contesti lunghi dovrebbe essere quello che sopravvive ai tuoi documenti reali senza trasformare il mezzo in zuppa. Il tuo agente generale dovrebbe essere economico, affidabile e noioso nel miglior modo possibile.

È qui che diventa interessante. Aggiungi un router che agisce come 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 gira su un modello leggero perché sta solo prendendo decisioni su dove inviare il traffico. Non stai pagando tariffe premium per capire quale altro modello premium usare. Misura anche questo; un router cattivo trasforma silenziosamente i risparmi in instradamenti errati.

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

I benefici pratici

L’efficienza dei costi conta più di quanto pensi. Un piccolo modello di routing che prende decisioni di delega costa una frazione dell’eseguire ogni singola richiesta attraverso il tuo provider più costoso. Nel tempo, specialmente su larga scala, questo si somma a soldi veri. Paghi per l’intelligenza pesante solo quando ne hai effettivamente bisogno.

La qualità migliora quando abbini i modelli ai compiti. Il vincitore cambia per mese, compito e forma del prompt. Ecco perché il layer di routing dovrebbe dipendere dalle tue eval, non da qualunque modello stesse vincendo su Twitter la settimana in cui hai scritto l’integrazione.

La resilienza diventa un beneficio collaterale. Quando OpenAI ha una delle sue interruzioni periodiche (e le ha), il tuo router può reindirizzare il traffico verso altri provider. Non resti bloccato in attesa che un’API specifica torni online.

Non si tratta di essere intelligenti per il gusto di esserlo. Si tratta di costruire sistemi che abbiano senso sia finanziariamente che tecnicamente. Non useresti lo stesso martello per ogni compito di costruzione, e probabilmente non dovresti usare lo stesso modello linguistico per ogni compito AI.

La bellezza di questo approccio è che il codice della tua applicazione non cambia. Chiami sempre il tuo agente router. La complessità di decidere quale modello usare per quale compito vive in un posto, configurato una volta, piuttosto che sparsa in tutto il tuo codebase in 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. MCP e Integrazioni Tool
4. Workflows e Memoria