Не женитесь на своей модели

LLM-маршрутизация — это прямо сейчас в тренде

Большинство инженерных команд выбирают одну языковую модель и придерживаются её. Один провайдер, одна модель, все задачи. Это как нанять одного человека для написания кода, копирайтинга и ведения бухгалтерии просто потому, что он хорошо прошёл первое собеседование.

В любой момент времени одна модель лучше справляется с кодом, другая — с длинным и запутанным контекстом, а третья — дешёвая рабочая лошадка для классификации. Названия меняются. Форма задачи остаётся прежней. Относиться к одной модели так, будто она преуспевает во всём — значит либо переплачивать за простые задачи, либо получать посредственные результаты на специализированных.

Я видел, как команда сжигала тысячи долларов, запуская анализ тональности через модель за $30 за миллион токенов, когда с задачей справилась бы модель за $0,50. Простое форматирование JSON, базовые задачи классификации — всё шло через их премиум-провайдер. Единственное, что нагревалось — это их счёт от AWS.

Есть способ лучше, и он не особенно сложный.

Делегирование вместо преданности

Что если маршрутизировать запросы к модели, которая действительно лучше всего подходит для конкретной задачи? Используйте дорогой флагман для сложной работы, но сбрасывайте простые задачи парсинга и форматирования на что-то подешевле. Получите преимущества нескольких провайдеров без необходимости вручную жонглировать ими в кодовой базе.

Mastra позволяет построить именно такую систему. Вы настраиваете специализированных агентов для разных типов работы, а затем создаёте агента-маршрутизатор, который решает, какой специалист должен обработать каждый запрос. Идентификаторы моделей ниже — примеры, а не лидерборд. Замените их на текущие модели, которые проходят ваши эвалы и вписываются в бюджет.

Думайте об этом так: у вас три специалиста в команде.

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

У каждого своя работа. Ваш агент для кода должен быть моделью, которая проходит ваши специфические для репозитория эвалы. Ваш агент для длинного контекста должен быть тем, кто выживает в ваших реальных документах, не превращая середину в кашу. Ваш общий агент должен быть дешёвым, надёжным и скучным в самом лучшем смысле этого слова.

Вот тут становится интересно. Вы добавляете маршрутизатор, который действует как интеллектуальный прокси:

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'), // Используйте дешёвую модель для маршрутизации!
  agents: {
    claudeAgent,
    geminiAgent,
    gptAgent,
  },
});

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

Сам маршрутизатор работает на легковесной модели, потому что он просто принимает решения о том, куда направить трафик. Вы не платите по премиальным тарифам за то, чтобы выяснить, какую другую премиальную модель использовать. Измеряйте и это; плохой маршрутизатор тихо превращает экономию в ошибки маршрутизации.

Когда кто-то просит реализовать пузырьковую сортировку, маршрутизатор распознаёт это как работу с кодом и передаёт её вашему специалисту по коду. Творческий запрос? Это отправляется модели, которую вы выбрали за её голос и диапазон. Фактический вопрос об исторических событиях? Направьте его общему агенту, в идеале с поиском (retrieval), когда важна актуальность или цитирование.

Практические преимущества

Экономия затрат важнее, чем вы думаете. Небольшая модель маршрутизации, принимающая решения о делегировании, стоит долю от запуска каждого запроса через вашего самого дорогого провайдера. Со временем, особенно в масштабе, это складывается в реальные деньги. Вы платите за тяжёлую интеллектуальную работу только тогда, когда она действительно нужна.

Качество растёт, когда вы сопоставляете модели с задачами. Победитель меняется от месяца к месяцу, от задачи к задаче, от формы промпта к форме промпта. Поэтому слой маршрутизации должен зависеть от ваших эвалов, а не от того, какая модель выигрывала Twitter на неделе, когда вы писали интеграцию.

Устойчивость становится побочным преимуществом. Когда у OpenAI случается один из его периодических сбоев (а они случаются), маршрутизатор может перенаправить трафик на других провайдеров. Вы не сидите без дела в ожидании, когда конкретный API вернётся в строй.

Речь не о том, чтобы быть хитрым ради хитрости. Речь о построении систем, которые имеют смысл и финансово, и технически. Вы бы не использовали один и тот же молоток для каждой строительной задачи, и, вероятно, не стоит использовать одну и ту же языковую модель для каждой AI-задачи.

Красота этого подхода в том, что код вашего приложения не меняется. Вы по-прежнему просто вызываете свой агент-маршрутизатор. Сложность решения, какую модель использовать для какой задачи, живёт в одном месте, настроенная один раз, а не размазана по всей кодовой базе в куче условной логики.

Ресурсы

• Документация Mastra.ai
• Репозиторий Mastra на GitHub

Читайте серию

1. Маршрутизация LLM (этот пост)
2. Безопасность и гардрейлы
3. MCP и интеграции инструментов
4. Воркфлоу и память