Выбор LLM для продакшен-нагрузок в 2026 году

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

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

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

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

Пригодность к продакшену начинается с контракта нагрузки

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

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

Зафиксируйте пять частей контракта:

• Диапазон входных данных, включая языки, размеры документов, качество изображений, длину диалога и вредоносное содержимое.
• Обязательный результат: текст, строгая JSON-схема, ссылки на предоставленные материалы или вызов инструмента.
• Допуск на сбои с отдельными пределами для безобидных стилистических промахов, неверных фактов, опасных действий и незаметного искажения данных.
• Целевые параметры сервиса, включая время до первого полезного результата, полное время выполнения, параллельную нагрузку и доступность.
• Экономическую цель, рассчитанную на выполненную бизнес-задачу, а не на токен.

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

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

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

Лидерборды отвечают на чужой вопрос

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

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

К заявлениям поставщиков нужна та же сдержанность. В актуальном руководстве OpenAI по моделям командам советуют сравнивать конфигурации на характерных задачах при смене модели или уровня рассуждения. В руководстве Google Gemini Models сказано, что большинству продакшен-приложений стоит использовать конкретную стабильную модель, а не псевдоним, который провайдер может незаметно переназначить. Оба совета разумны, но ни один поставщик не знает ваших критериев приемки. В документации описан доступный механизм. Пригодность определяет ваша оценка.

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

Разделяйте качество модели и качество системы. Поиск данных, разбор документов, описания инструментов, сборка промпта и последующая обработка могут сильнее всего влиять на результат. Если все кандидаты проваливают одни случаи, сначала проверьте конвейер, а не покупайте более крупную модель. Если ошибается один кандидат, вы узнали что-то о модели. Такое различие не дает командам принять архитектурную ошибку за нехватку интеллекта.

Соберите тестовый набор из реальной работы

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

Разделите случаи на четыре группы. Обычные случаи представляют повседневную работу. Пограничные охватывают редкие, но допустимые входные данные: несколько языков, пустые поля, длинную историю или сканы плохого качества. Атакующие случаи содержат инъекции в промпт, противоречивые инструкции, испорченные результаты инструментов и запросы вне полномочий. Регрессионные случаи сохраняют каждый продакшен-сбой, который нельзя допустить снова.

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

{"id":"refund-017","input_ref":"fixtures/refund-017.json","expected_action":"needs_human_review","must_preserve":["account_id","currency"],"must_not_claim":["refund_approved"],"max_total_ms":4500,"risk":"financial_action"}

Такая запись ловит знакомый сбой. Ответ может звучать участливо, правильно пересказывать правила и при этом выдумать, что возврат одобрен. Оценщик стиля поставит ему высокий балл. Правило must_not_claim сразу провалит ответ, потому что неверная фраза способна создать финансовое обязательство.

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

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

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

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

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

Жесткие сбои важнее предпочтений

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

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

1. Пороги допуска проверяют регион развертывания, правила работы с данными, нужные типы входных данных, стабильность версии и лимиты нагрузки.
2. Пороги безопасности проверяют запрещенные действия, раскрытие данных, устойчивость к инъекциям и правильную передачу человеку.
3. Успех задачи показывает, достигнута ли цель пользователя со всеми обязательными фактами и результатами.
4. Операционные показатели сравнивают задержку, стоимость, долю повторных попыток и труд разработчиков у прошедших кандидатов.

Не поручайте LLM оценку всего подряд. Точные проверки должны валидировать JSON, идентификаторы, суммы, даты, перечисления, ссылки на источники и аргументы инструментов. Детерминированные проверки дешевы, воспроизводимы и понятны при отладке. Модельных оценщиков применяйте для смысла и стиля только после сверки с оценками людей, а личность кандидата от оценщика скрывайте.

Напишите правила решения до запуска сравнения. Например:

reject_if:
  unsafe_action_rate: "> 0"
  schema_valid_rate: "< 0.995"
  p95_total_ms: "> 4500"
rank_survivors_by:
  task_success: 0.60
  cost_per_success: 0.25
  reviewer_preference: 0.15

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

Разбирайте сбои по категориям, а не только по общей цифре. Две модели с успешностью 88 процентов могут создавать совершенно разные риски. Одна ошибается в безобидном форматировании, другая проваливает каждый запрос на испанском. Среднее скрывает, у кого сломается продукт и как именно. Разбивайте результаты по языку, типу клиента, длине входа, пути инструментов и классу риска, если эти параметры влияют на функцию.

Для задержки нужно распределение, а не среднее

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

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

Показывайте p50, p95 и p99 вместо среднего. Медиана описывает обычный опыт. Хвост показывает, что происходит при длинном контексте, нехватке мощности, зависшем инструменте или повторной попытке модели. Продуктовые команды часто улучшают медиану, потому что ее видно на демонстрациях. Клиенты запоминают хвост, потому что он прерывает работу.

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

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

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

Считайте цену успешной задачи

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

Используйте простой расчет, который можно воспроизвести по логам:

cost_per_attempt = model_tokens + tool_calls + retrieval + infrastructure
cost_per_success = sum(all_attempt_costs) / accepted_tasks
monthly_feature_cost = forecast_tasks * attempts_per_task * cost_per_attempt

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

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

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

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

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

Инструменты и структурированный результат проверяют враждебными тестами

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

Создайте почти одинаковые инструменты с разными полномочиями, например read_invoice и issue_refund, а затем дайте задачи, разрешающие только один. Возвращайте пустые результаты, таймауты, испорченные поля, дубли записей и противоречивые статусы. Помещайте недоверенные инструкции в найденные данные. Модель должна считать их данными, соблюдать приоритет системных и пользовательских правил и запрашивать одобрение перед любым действием, которое ваша политика считает значимым.

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

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

Ограничивайте циклы программно. Задайте максимум ходов модели, вызовов инструментов, прошедшего времени и расходов. Требуйте явное конечное состояние: completed, needs_human_review или failed_dependency. После ошибки модели иногда повторяют правдоподобный вызов, а вежливая просьба не повторяться не заменяет жесткий счетчик.

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

Конфиденциальность и жизненный цикл могут исключить победителя

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

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

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

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

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

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

Группа моделей лучше одного корпоративного победителя

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

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

Разумная последовательность выпуска состоит из четырех этапов:

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

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

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

Выбор модели меняет и устройство команды. Кто-то должен отвечать за тестовые данные, оценщиков, маршрутизацию, разбор инцидентов и миграции между провайдерами. Если обязанности раскиданы между разработчиками, каждый из которых предпочитает свою модель, решения быстро превращаются в набор историй. Во время Team & AI Audit я ищу такой пробел в ответственности вместе с инженерными расходами, которые он создает, потому что неправильная организация работы способна съесть экономию от хорошего технического выбора.

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

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