Выбор подходящей модели под задачу и бюджет

Полезная мысленная схема: сначала тип задачи, затем модель

На практике я классифицирую задачи для LLM по пяти параметрам, прежде чем вообще смотреть на названия моделей:

Выбрать модель становится гораздо проще, когда вы перестаете спрашивать «какая модель умнее?» и начинаете спрашивать «риск какого сбоя я снижаю этими затратами?»

Например:

• Сервису создания сводок по запросам на сброс пароля нужны стабильность и низкая стоимость.
• Помощнику по миграции кода нужны рассуждение и работа с инструментами.
• Инструменту сравнения договоров нужен большой контекст, а также точное указание источников.
• Агенту, который общается с клиентами, предсказуемость задержки важнее максимальных результатов в тестах.
• Для конвейера пакетного обогащения данных объем обработки на потраченный доллар может быть важнее изящества ответов.

Неподходящая модель часто оказывается неверным выбором не с технической, а с экономической точки зрения.

Практическая лестница моделей

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

Модели класса Haiku: выбор по умолчанию для дешевой и быстрой работы с языком

Модели класса Haiku отлично подходят для первого прохода. Я использую их для задач, где ответ короткий, входные данные чистые, а формат результата ограничен.

Подходящие задачи:

• Проставление тегов обращениям
• Краткие сводки
• Классификация тональности
• Нормализация тем электронных писем
• Сопоставление с часто задаваемыми вопросами
• Простое извлечение JSON
• Предварительные фильтры модерации с низким риском

Пример промпта для недорогого классификатора первого этапа:

{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}

Ожидаемый результат:

{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}

Распространённая ловушка: команды просят недорогие модели одновременно рассуждать и безупречно форматировать результат за один вызов. Если модель иногда выдаёт некорректный JSON, не переходите сразу на Opus. Сначала уточните задачу:

• Задайте temperature: 0
• Используйте схему JSON или вызов инструмента
• Сократите объём инструкций
• Отделите классификацию от объяснения
• Проверьте результат и повторите попытку один раз

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

Модели класса Sonnet: рабочая лошадка для реальной продуктовой логики

Для интерактивных функций продукта я обычно выбираю модели класса Sonnet. Они достаточно сильны в рассуждениях, достаточно стабильны при работе с инструментами и обычно достаточно быстры для пользовательских сценариев.

Подходящие задачи:

• Подготовка ответов службы поддержки
• Агентные рабочие процессы с инструментами
• Объяснение кода и небольшой рефакторинг
• Многоэтапные ответы на вопросы по документам
• Рабочие процессы с ИИ-помощником для продаж или сопровождения клиентов
• Извлечение структурированных данных из неупорядоченных входных материалов

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

Пример: агент поддержки, который может изучить заказ, правила и предыдущие обращения.

SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}

Вот что на самом деле происходит при запуске такого рабочего процесса в рабочей среде: большинство сбоев вызвано не тем, что «модель глупая». Это сбои интеграции.

• Инструмент возвращает устаревшее состояние.
• Модель получает слишком много нерелевантного контекста.
• Документ с правилами содержит противоречивые положения.
• Агенту разрешено продолжать работу после неудачного вызова инструмента.
• Промпт требует и внутреннего анализа, и текста, готового для отправки клиенту, не разделяя их.

Модель класса Sonnet достаточно умна, чтобы справиться с некоторой неупорядоченностью, но это не отменяет необходимости в чётких контрактах инструментов.

Модели класса Opus: дорогие, но иногда дешевле ошибок

Модели класса Opus предназначены для задач, в которых цена плохого ответа значительно превышает стоимость инференса.

Я выбираю Opus, когда:

• Входные данные неоднозначны, а цена ошибки высока
• Есть много взаимосвязанных ограничений
• Пользователь ожидает глубоких рассуждений
• Задача связана с компромиссами в коде, правилах или архитектуре
• Неудачная попытка с недорогой моделью приведёт к потере рабочего времени людей

Примеры:

• Проверка плана миграции базы данных
• Анализ хронологии инцидента в рабочей среде
• Подготовка сложного сравнительного анализа юридических норм и правил для проверки специалистом
• Отладка сбоя агента, затрагивающего несколько сервисов
• Оценка безопасности автоматизированного действия

Я не использую Opus для каждой «важной» задачи. Важность и сложность — разные вещи. Миллион обращений для сброса пароля важен для пользователей, но каждое отдельное обращение несложно. Одна миграция с неочевидными нюансами удаления данных может быть и важной, и сложной.

Полезный подход — «переходить на более мощную модель при неопределённости»:

def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"

Он намеренно прост. Маршрутизатор должен быть настолько незамысловатым, чтобы ваша команда могла отладить его в 2 часа ночи.

Fable 5 и контекст 1M: используйте, когда проблема в поиске данных

Модели с длинным контекстом привлекательны тем, что избавляют от значительной части инженерной работы по поиску данных. Контекстное окно 1M у Fable 5 меняет круг задач, которые можно решать напрямую: проверка целых документов, обобщение огромных расшифровок, изучение больших репозиториев и анализ правил в нескольких файлах.

Но длинный контекст — не волшебство.

Окно на 1M токенов помогает, когда сложность заключается в том, что «нужный факт может находиться где угодно». Оно не гарантирует, что модель будет безупречно рассуждать по всему миллиону токенов, и не делает нерелевантный контекст бесплатным. Длинные промпты по-прежнему стоят денег, увеличивают задержку и могут рассеивать внимание.

Я использую длинный контекст, как у Fable, когда:

• Материалы слишком тесно взаимосвязаны для простого разбиения на фрагменты
• Пропустить одну деталь хуже, чем заплатить за дополнительный контекст
• Пользователь готов ждать ответа дольше
• Для задачи полезно видеть исходные материалы вокруг нужного фрагмента

Пример архитектуры для проверки больших документов:

User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer

Этот гибридный подход работает лучше, чем «всегда помещать всё в контекст». На практике модели с длинным контекстом наиболее полезны как запасной вариант, когда уверенность в результатах поиска низкая.

Модели с открытыми весами: контроль, стоимость и пропускная способность

Модели с открытыми весами, такие как Llama, Qwen, DeepSeek, MiniMax и Kimi, — не просто «более дешёвые альтернативы». Их выбор определяет подход к эксплуатации.

Они подходят, когда вам нужны:

• Локальное развёртывание или развёртывание в VPC
• Предсказуемая стоимость пакетной обработки больших объёмов
• Дообучение или дистилляция
• Специализированные оптимизации инференса
• Контроль над местом хранения и обработки данных
• Крайне низкая стоимость каждой дополнительной операции после настройки

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

Пример схемы локального обслуживания запросов:

vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Затем вызывайте модель через клиент, совместимый с OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)

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

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

Маршрутизация с недорогой модели и переходом на более мощную

Хороший маршрутизатор — это не рейтинг моделей. Это система контроля рисков.

Вот подход, подходящий для рабочей среды:

1. Попробуйте самую дешёвую модель, которая должна справиться с задачей.
2. Проверьте результат автоматически.
3. Попросите модель выполнить откалиброванную самопроверку только по наблюдаемым критериям.
4. Переходите на более мощную модель, если проверка не пройдена, уверенность низкая или риск высокий.
5. Записывайте выбранный маршрут и результат в журнал для последующей настройки.

Пример маршрутизатора:

def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response

Главное, чтобы переход на более мощную модель основывался на измеримых сигналах, а не на ощущениях.

Полезные сигналы для перехода на более мощную модель:

• Некорректный JSON
• Отсутствуют обязательные поля
• Противоречивый ответ
• Не удалось вызвать инструмент
• Найденные подтверждающие сведения недостаточно убедительны
• Пользователь запрашивает необратимое действие
• Входные данные превышают обычную длину
• Модель явно указывает на неопределённость
• Классификатор обнаруживает юридическую, медицинскую, финансовую тематику или вопросы безопасности

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

Задержка, цена и пользовательский опыт

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

Для интерактивных систем я ориентируюсь на допустимые задержки:

Не скрывайте медленные рассуждения за индикатором загрузки без обратной связи. Если задаче с Opus или Fable требуется 90 секунд, явно обозначьте её как задачу анализа:

Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety

Это меняет восприятие пользователя, потому что работа системы становится видимой.

Кроме того, используйте потоковую выдачу везде, где это возможно. Она не сокращает общее время выполнения, но значительно снижает воспринимаемую задержку в чате и при подготовке черновиков.

Практический выбор для конкретных задач

Вот какие конкретные варианты я выбрал бы сегодня.

Первичная обработка обращений в поддержку

Сначала используйте Haiku.

• Входные данные: краткий текст обращения
• Результат: категория, срочность, очередь для обработки
• Передавайте задачу Sonnet при спорах об оплате, недовольстве клиентов или неоднозначности правил
• Проверка человеком для возвратов средств выше установленного порога

Это классический процесс, в котором сначала используется дешёвая модель.

Агент поддержки для общения с клиентами

Используйте Sonnet.

• Требуется использование инструментов
• Требуется контроль тона общения
• Требуется работа с правилами
• Требуется корректная передача сложных случаев на следующий уровень

Используйте Haiku только для предварительной обработки. Используйте Opus для дополнительной проверки случаев с высоким риском.

Помощник для проверки кода

Используйте Sonnet для обычной проверки PR. Используйте Opus для изменений, затрагивающих архитектуру, параллельного выполнения, безопасности, миграций данных и проверки тонких аспектов корректности.

Распространённая ошибка — по умолчанию передавать весь репозиторий. Начните с diff, графа зависимостей и связанных файлов. Переходите к Fable или другой модели с длинным контекстом, только когда изменение затрагивает много областей.

Сравнение длинных договоров или нормативных документов

Для узких вопросов используйте поиск по материалам вместе с Sonnet. Используйте Fable 5, когда вопрос охватывает весь материал, например: «Найди все противоречия между этими документами».

Если результат влияет на реальное юридическое решение или решение о соблюдении требований, используйте модель для подготовки анализа, а не для принятия решения.

Обогащение данных в больших объёмах

Используйте модель с открытыми весами, если объём велик, а задача стабильна.

Пример:

• Нормализация названий компаний
• Извлечение отраслевых меток
• Классификация входящих лидов
• Создание кратких внутренних сводок

Запускайте ночную пакетную обработку, проверяйте выборки и передавайте пограничные случаи облачной модели.

Помощник для исследований по большим архивам

Используйте Gemini 3, GPT-5.5, Opus или Fable в зависимости от длины контекста и требований к рассуждениям. Я бы не начинал здесь с дешёвой модели, если только запрос не является очевидно простым. Ошибки в исследованиях часто остаются незаметными: модель даёт правдоподобный ответ, упуская ключевой документ.

Планирование бюджета без самообмана

Самый простой способ выйти за рамки бюджета — оптимизировать стоимость отдельного вызова, игнорируя повторные попытки, исправления человеком и неудачные рабочие процессы.

Отслеживайте эти метрики по типу задачи и модели:

• Число входных токенов
• Выходные токены
• Задержка p50/p95
• Доля ошибок валидации
• Доля передач на следующий уровень
• Доля решений, изменённых человеком
• Доля повторных попыток со стороны пользователя
• Стоимость успешно выполненной задачи, а не стоимость вызова

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

Если вы используете шлюз для нескольких моделей, в том числе такой сервис, как доступ через API AI Prime Tech к семействам Claude, GPT и Gemini, главное преимущество заключается не только в возможности выбирать поставщика. Такой шлюз упрощает маршрутизацию и измерение показателей для разных классов моделей. Но самой сложной частью по-прежнему остаётся проектирование задачи.

Практические рекомендации

• Начните с характера задачи: преобразование, извлечение, рассуждение, синтез на основе длинного контекста или пакетное обогащение.
• Используйте модели класса Haiku для дешёвой, быстрой работы с чёткими ограничениями и автоматической проверкой.
• Используйте модели класса Sonnet по умолчанию для функций продукта, которым нужны рассуждения, инструменты или качественный результат для пользователей.
• Используйте модели класса Opus, когда ошибки обходятся дорого, неоднозначность высока или важны глубокие рассуждения.
• Используйте длинный контекст, как у Fable 5, когда главная проблема — неопределённость поиска нужных материалов, а не как стандартный способ свалить все данные в промпт.
• Используйте модели с открытыми весами, когда стабильность нагрузки, конфиденциальность, пропускная способность или контроль над развёртыванием оправдывают самостоятельную организацию инференса.
• Постройте маршрутизацию, начинающуюся с дешёвой модели, с явными сигналами для передачи на следующий уровень: некорректный результат, слабые подтверждения, сбои инструментов, действия с высоким риском и неопределённость.
• Измеряйте стоимость успешно выполненной задачи, а не стоимость токена или вызова.
• Делайте маршрутизаторы достаточно простыми, чтобы их можно было отлаживать в напряжённой ситуации.
• Рассматривайте выбор модели как инструмент инженерного управления, а не как разовое решение о поставщике.