Source: https://aiprimetech.io/ru/blog/choosing-the-right-model-cost/ 21 июня, 2026 · 6 мин · API # Выбор подходящей модели под задачу и бюджет A Автор: [AI Prime Tech](https://aiprimetech.io/ru/) · При участии ИИ Во вторник в 9:17 утра наш сервис создания сводок по обращениям в поддержку выглядел «исправным» на панели мониторинга: 99.4% успешных запросов, задержка p95 менее 3 секунд, очередь не накапливалась. Счет за использование показывал другую картину. Мы тратили суммы уровня Opus на сводки по обращениям вроде: ``` { "subject": "Can I reset my password?", "messages": 3, "language": "en", "attachments": 0 } ``` Это не задача на рассуждение. Это не задача, требующая контекста 1M. Это едва ли вообще задача на работу с языком. Решением было не «везде использовать самую дешевую модель». Такой подход дает сбой, как только возникает спор о возврате средств, запутанный отчет об ошибке или эскалация, требующая соблюдения нормативных требований. Решением стала маршрутизация: начинать с дешевой модели, оценивать уверенность и переходить к более мощной только тогда, когда задача действительно этого заслуживает. Выбор подходящей модели — это не столько поиск «лучшей модели ИИ», сколько создание скучной, надежной системы принятия решений: - Что требуется для этой задачи? - Насколько сильно модель может ошибиться? - Какой объем контекста необходим? - Какую задержку пользователь готов терпеть? - Каков порядок повторных попыток и перехода к более мощной модели? Именно здесь у Haiku, Sonnet, Opus, Fable, GPT, Gemini и моделей с открытыми весами есть свое реальное место. ## Полезная мысленная схема: сначала тип задачи, затем модель На практике я классифицирую задачи для LLM по пяти параметрам, прежде чем вообще смотреть на названия моделей: | Тип задачи | Пример | Лучший начальный выбор | Когда переходить к более мощной модели | Простое преобразование | Переписывание, классификация, создание сводок по коротким текстам | Модель класса Haiku или небольшая открытая модель | Некорректный формат результата или низкая уверенность | Извлечение структурированных данных | Разбор счетов, обращений, журналов | Haiku/Sonnet или открытая модель с ограничениями вывода | Неоднозначные поля, запись высокой ценности | Рассуждение в продуктовых задачах | Планирование действий агента, отладка, многоэтапная поддержка | Модель класса Sonnet/GPT/Gemini | Сбои инструментов, противоречия, низкая уверенность | Глубокий анализ | Проверка архитектуры, сравнение политик с правовыми аспектами, сложные рассуждения о коде | Opus/GPT-5.5/Gemini 3 | При высоких ставках обычно стоит начинать с этого уровня | Синтез на основе огромного контекста | Весь репозиторий, большой архив расшифровок, длинные документы | Fable 5 или модель с большим контекстным окном | После поиска нужны точные рассуждения по конкретным фрагментам | Большие объемы в закрытой или автономной среде | Предварительная фильтрация для модерации, классификация в задачах, связанных с эмбеддингами, внутренние пакетные задания | Llama/Qwen/DeepSeek/MiniMax/Kimi с открытыми весами | Пограничные случаи, решения, подпадающие под нормативные требования Выбрать модель становится гораздо проще, когда вы перестаете спрашивать «какая модель умнее?» и начинаете спрашивать «риск какого сбоя я снижаю этими затратами?» Например: - Сервису создания сводок по запросам на сброс пароля нужны стабильность и низкая стоимость. - Помощнику по миграции кода нужны рассуждение и работа с инструментами. - Инструменту сравнения договоров нужен большой контекст, а также точное указание источников. - Агенту, который общается с клиентами, предсказуемость задержки важнее максимальных результатов в тестах. - Для конвейера пакетного обогащения данных объем обработки на потраченный доллар может быть важнее изящества ответов. Неподходящая модель часто оказывается неверным выбором не с технической, а с экономической точки зрения. ## Практическая лестница моделей Вот лестница, которую я использую для большинства систем в рабочей среде. ### Модели класса 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"} ] ) ``` Компромисс заключается в ответственности за инженерную часть. При использовании передовых моделей у внешнего провайдера кто-то другой занимается вычислительными ресурсами, обновлениями, выбором способов квантования и оптимизацией производительности на уровне вычислительных ядер. С открытыми моделями это становится вашей работой. Модели с открытыми весами отлично подходят для стабильной нагрузки. Они менее удачный выбор, когда продукт меняется каждую неделю, а качество промптов важнее собственно стоимости обслуживания запросов. ## Маршрутизация с недорогой модели и переходом на более мощную Хороший маршрутизатор — это не рейтинг моделей. Это система контроля рисков. Вот подход, подходящий для рабочей среды: - Попробуйте самую дешёвую модель, которая должна справиться с задачей. - Проверьте результат автоматически. - Попросите модель выполнить откалиброванную самопроверку только по наблюдаемым критериям. - Переходите на более мощную модель, если проверка не пройдена, уверенность низкая или риск высокий. - Записывайте выбранный маршрут и результат в журнал для последующей настройки. Пример маршрутизатора: ``` 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 не является откалиброванной вероятностью. Она всё же полезна, если ограничить её конкретными проверками: «Содержали ли входные данные достаточно информации для ответа?» лучше, чем «Насколько вы уверены?» ## Задержка, цена и пользовательский опыт Самая быстрая модель не всегда обеспечивает лучший пользовательский опыт. Лучший пользовательский опыт — тот, который приводит пользователя к правильному результату за приемлемое время ожидания. Для интерактивных систем я ориентируюсь на допустимые задержки: | Сценарий | Примерный лимит задержки | Стратегия выбора моделей | Автодополнение или встроенный помощник | 100–500 мс по ощущению пользователя | Небольшая или открытая модель, потоковая передача, активное кеширование | Ответ в чате | 1–5 секунд | Модели класса Haiku/Sonnet с потоковой выдачей | Агентный процесс с использованием инструментов | 5–20 секунд | Модели класса Sonnet, параллельное использование инструментов, сообщения о ходе работы | Глубокий анализ | 30–180 секунд | Модели класса Opus/Fable/GPT/Gemini, асинхронная задача | Пакетная обработка | От минут до часов | Модель с открытыми весами или самый дешёвый тариф облачного сервиса Не скрывайте медленные рассуждения за индикатором загрузки без обратной связи. Если задаче с 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, когда главная проблема — неопределённость поиска нужных материалов, а не как стандартный способ свалить все данные в промпт. - Используйте модели с открытыми весами, когда стабильность нагрузки, конфиденциальность, пропускная способность или контроль над развёртыванием оправдывают самостоятельную организацию инференса. - Постройте маршрутизацию, начинающуюся с дешёвой модели, с явными сигналами для передачи на следующий уровень: некорректный результат, слабые подтверждения, сбои инструментов, действия с высоким риском и неопределённость. - Измеряйте стоимость успешно выполненной задачи, а не стоимость токена или вызова. - Делайте маршрутизаторы достаточно простыми, чтобы их можно было отлаживать в напряжённой ситуации. - Рассматривайте выбор модели как инструмент инженерного управления, а не как разовое решение о поставщике. [Модели](/ru/blog/tag/models/)[API](/ru/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/ru/) Этот блог публикует AI Prime Tech. Статьи готовятся с помощью ИИ; прежде чем полагаться на сведения, зависящие от версии, такие как идентификаторы моделей, цены и лимиты, сверяйте их с официальной документацией. Получите более дешёвый доступ к API Claude Один ключ API для Claude Opus 5.5, Sonnet 5, Haiku 4.5 и Fable 5.1, а также GPT-6 моделей. Оплата по мере использования, без подписки. [Получить ключ API →](/register) AI Prime Tech — независимый сторонний API-шлюз. Claude™ и Anthropic® — товарные знаки Anthropic, PBC. Связь с этой компанией или одобрение с её стороны не подразумеваются.