No te cases con tu modelo

Enrutamiento de LLM, tan de moda ahora mismo

La mayoría de los equipos de ingeniería eligen un modelo de lenguaje y se quedan con él. Un proveedor, un modelo, todas las tareas. Es como contratar a una persona para que haga tu programación, tu redacción y tus impuestos porque resultó ser buena en la primera entrevista.

En cualquier momento dado, un modelo es mejor para código, otro es mejor con contexto largo y desordenado, y otro es el caballo de batalla más barato para clasificación. Los nombres cambian. La forma del problema no. Tratar a un solo modelo como si fuera excelente en todo significa que estás pagando de más por tareas simples u obteniendo resultados peores en las especializadas.

Vi a un equipo quemar miles de dólares ejecutando análisis de sentimiento a través de un modelo de $30 por millón de tokens cuando un modelo de $0.50 habría hecho el trabajo igual de bien. Formateo simple de JSON, tareas básicas de clasificación, todo pasando por su proveedor premium. Lo único que se calentaba era su factura de AWS.

Hay una mejor manera, y no es particularmente complicada.

Delegación sobre devoción

¿Y si pudieras enrutar las solicitudes al modelo que realmente es el más adecuado para esa tarea específica? Usa tu modelo potente y caro para lo difícil, pero delega el análisis y el formateo simple a algo más barato. Obtén los beneficios de múltiples proveedores sin tener que manejarlos manualmente en tu código.

Mastra te permite construir exactamente este tipo de sistema. Configuras agentes especialistas para diferentes tipos de trabajo, luego creas un agente enrutador que determina qué especialista debe manejar cada solicitud. Los IDs de modelo de abajo son ejemplos, no una tabla de clasificación. Cámbialos por los modelos actuales que ganen tus evaluaciones y se ajusten a tu presupuesto.

Piénsalo así: tienes tres especialistas en tu equipo.

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'),
});

Cada uno tiene un trabajo. Tu agente de código debe ser el modelo que pasa tus evaluaciones de código específicas de tu repositorio. Tu agente de contexto largo debe ser el que sobreviva a tus documentos reales sin convertir el medio en sopa. Tu agente general debe ser barato, confiable y aburrido en el mejor sentido posible.

Aquí es donde se pone interesante. Añades un enrutador que actúa como un proxy inteligente:

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 },
});

El enrutador en sí se ejecuta en un modelo ligero porque solo está tomando decisiones sobre dónde enviar el tráfico. No estás pagando tarifas premium para averiguar qué otro modelo premium usar. Mide esto también; un mal enrutador convierte silenciosamente los ahorros en rutas equivocadas.

Cuando alguien pide una implementación de bubble sort, el enrutador lo reconoce como trabajo de código y se lo pasa a tu especialista en código. ¿Un prompt de escritura creativa? Eso va al modelo que hayas elegido para voz y alcance. ¿Una pregunta factual sobre eventos históricos? Enrútala al agente general, idealmente con recuperación cuando la actualidad o la citación importan.

Los beneficios prácticos

La eficiencia de costos importa más de lo que crees. Un modelo de enrutamiento pequeño que toma decisiones de delegación cuesta una fracción de ejecutar cada solicitud a través de tu proveedor más caro. Con el tiempo, especialmente a escala, esto se convierte en dinero real. Solo pagas por la inteligencia de alto rendimiento cuando realmente la necesitas.

La calidad mejora cuando emparejas modelos con tareas. El ganador cambia por mes, tarea y forma del prompt. Es por eso que la capa de enrutamiento debería depender de tus evaluaciones, no del modelo que estuviera ganando en Twitter la semana que escribiste la integración.

La resiliencia se convierte en un beneficio colateral. Cuando OpenAI tiene una de sus caídas periódicas (y las tienen), tu enrutador puede redirigir el tráfico a otros proveedores. No estás varado esperando a que una API específica vuelva a estar en línea.

Esto no se trata de ser inteligente por el simple hecho de serlo. Se trata de construir sistemas que tengan sentido tanto financiera como técnicamente. No usarías el mismo martillo para cada tarea de construcción, y probablemente tampoco deberías usar el mismo modelo de lenguaje para cada tarea de IA.

La belleza de este enfoque es que el código de tu aplicación no cambia. Sigues llamando a tu agente enrutador. La complejidad de decidir qué modelo usar para qué tarea vive en un solo lugar, configurado una vez, en lugar de estar dispersa por todo tu código en un montón de lógica condicional.

Recursos

• Documentación de Mastra.ai
• Repositorio de Mastra en GitHub

Lee la serie

1. Enrutamiento de LLM (Este post)
2. Seguridad y barreras de protección
3. Integraciones MCP y de herramientas
4. Flujos de trabajo y memoria