DanLevy.net

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

Маршрутизация LLM — сейчас в центре внимания

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

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

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

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

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

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

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

Представьте, что в вашей команде три специалиста.

./src/mastra/index.ts
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'), // Use a cheap model for routing!
  agents: {
    claudeAgent,
    geminiAgent,
    gptAgent,
  },
});


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

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

Когда кто‑то просит реализовать пузырьковую сортировку, роутер распознаёт задачу как код и передаёт её вашему специалисту по коду. Запрос на креативное написание? Он попадает к модели, выбранной для творческого голоса и диапазона. Фактический вопрос о исторических событиях? Маршрутизируется к общему агенту, желательно с подключённым поиском, когда важны актуальность или ссылки.

Практические выгоды

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

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

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

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

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

Ресурсы

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

  1. Маршрутизация LLM (этот пост)
  2. Безопасность и ограничительные меры
  3. MCP и интеграции инструментов
  4. Рабочие процессы и память
Loading comments...