Open‑weight LLM догнали закрытые? Проверка на продакшене

Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу, почему фраза «open‑weight модели догнали закрытые» почти верна для бенчмарков и опасна для вашего продакшена.

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

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

«А зачем мы платим в десятки раз больше?»

• Ответ «так надёжнее» его не устроит.

• Ответ «переводим всё на open‑weight» звучит смело, но через месяц может закончиться ночным откатом.

С апреля по август выходили DeepSeek V4, Kimi K3, GLM-5.3, а Meta неожиданно вернулась к открытым весам, так что такие скриншоты теперь приходят чуть ли не каждую неделю.

Похожий разговор у меня случался не один раз, поэтому я проверил тезис по четырём направлениям:

1. независимые измерения;

2. деньги; 

3. лицензии;

4. железо.

Open‑weight против закрытых моделей: почему об этом заговорили именно сейчас

С апреля по август 2026 года крупные открытые релизы шли почти без пауз:

• 24 апреля DeepSeek выложил превью V4 с весами под MIT: версия Pro на 1,6 трлн параметров (49 млрд активных) и Flash на 284 млрд (13 млрд активных), обе с контекстом в 1 млн токенов. 13 августа Pro вышла из превью.

• 16 июля Moonshot AI представила Kimi K3: 2,8 трлн параметров, из них 104 млрд активных, контекст в миллион токенов. Веса выложили 27 июля.

• 10 августа Meta выпустила Muse Glimmer на 30 млрд параметров под Apache 2.0, которая запускается на одной потребительской видеокарте.

• 14 августа Zhipu выпустила GLM-5.3 через API, а веса опубликовала только 28 августа, после двухнедельной проверки на кибербезопасность.

Возвращение Meta показательно. Весной её флагман Muse Spark стал доступен только в продуктах Meta и в закрытом API‑превью для отдельных партнёров, без открытых весов, а последние два года темп в открытых моделях задавали китайские лаборатории. По опубликованному анализу данных OpenRouter, к маю на китайские open‑weight модели приходилось около 61% потреблённых там токенов. Оговорюсь: это статистика одного маршрутизатора, а не всего рынка, но тренд она показывает наглядно.

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

Что говорят не пресс‑релизы, а измерения

Чтобы не спорить на уровне ощущений, я свёл вместе три источника: независимый сводный индекс возможностей, публичные цены и лицензии моделей (проверены 16 сентября 2026 года) и один громкий производственный кейс. Сверху наложил собственный опыт перевода задач на открытые модели.

Начну с индекса.

Мне как‑то попалась методика, которая нравится мне больше сравнения по одному тесту. Аналитики Epoch AI считают сводный индекс возможностей ECI по множеству бенчмарков. Их вывод по данным с 1 января по 28 мая 2026 года: лучшие открытые модели отстают от закрытого фронтира в среднем на четыре месяца. В пунктах индекса это около 8, примерно как разница между GPT-5 и GPT-5.5.

Два нюанса из того же исследования я бы повесил на стену каждому, кто принимает решение о миграции:

1. Разрыв не сократился, а слегка вырос. По данным за период с 2023 по октябрь 2025 года он был около трёх месяцев.

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

Обновлённого пересчёта с учётом летних релизов я у Epoch не нашёл.

Есть экспертная оценка Натана Ламберта: после выхода Kimi K3 он предположил, что разрыв сократился примерно до 3–5 месяцев. Это интерпретация, а не независимое измерение по методике Epoch, но она показывает сопоставимый масштаб разрыва.

Признаюсь, когда я впервые увидел цифру в четыре месяца, воспринял её как «почти ничего».

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

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

Точнее всего это можно сформулировать так: по агрегированным метрикам лучшие открытые модели находятся в нескольких месяцах от фронтира, но это не паритет с сегодняшним фронтиром.

А дальше приходится различать три разных утверждения:

• паритет на бенчмарке;

• паритет на вашей задаче;

• паритет в продакшене.

Наблюдение 1. Средний разрыв ничего не говорит о вашем сценарии

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

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

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

Стоп. Здесь возникает типичная ошибка интерпретации: из результата на одной задаче делают вывод о модели в целом. Честный вывод можно сделать только о паре «модель плюс задача».

С тех пор на любой демонстрации новой модели я первым делом спрашиваю не «какой у неё балл», а «на каких наших примерах её гоняли».

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

Наблюдение 2. Экономика убедительная, но цены не константа

Посмотрим, как менялась цена одной и той же модели, DeepSeek V4-Pro, за миллион выходных токенов, по официальному changelog DeepSeek. Это исторический срез: перед решением цифры нужно сверять с текущим прайсингом провайдера.

Даже после подорожания непиковый выход у V4-Pro примерно в 12 раз дешевле, чем у Claude Opus 4.8. Экономия реальна.

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

Имя эндпоинта — не неизменный идентификатор модели. Клиентский API‑контракт при этом не потребовал изменений, но отсутствие изменений в контракте не гарантирует совместимость по качеству и смыслу ответов.

Могу себе представить, как это выглядит на планёрке.

Бюджет на LLM посчитали в июне, объёмы не выросли, а счёт за август вдруг вырос в разы. Пиковые часы у DeepSeek — это 01:00–04:00 и 06:00–10:00 по UTC в будни, то есть с 4 до 7 и с 9 до 13 по Москве. Ровно тогда, когда у российского сервиса основной дневной трафик.

В этой ситуации я бы чётко разделял два понятия: «открытые веса» и «API провайдера, который эти веса обслуживает».

Веса, скачанные с зафиксированной ревизией, остаются вашими. API остаётся внешней зависимостью, как любой SaaS, со своим changelog, который надо читать.

Наблюдение 3. «Открытая» — это про лицензию, а не про свободу

Термин open‑weight сегодня используется для моделей с очень разными условиями распространения. Веса и репозиторий DeepSeek V4 распространяются под MIT, Muse Glimmer — под Apache 2.0. У остальных условия приходится читать внимательнее.

Kimi K3 выходит под собственной лицензией. Компании, которая продаёт доступ к модели как сервис и чья выручка превышает 20 млн долларов за любые 12 месяцев подряд, нужно отдельное соглашение с Moonshot.

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

Самый поучительный пример августа — Zhipu. GLM-5.2 выходила под MIT, а GLM-5.3, построенная на той же базовой модели с упором на дообучение, получила собственную лицензию. В ней появилось требование пройти проверку безопасности для операторов модели как сервиса с выручкой больше 10 млрд долларов. При этом GLM-5.3-Flash, выпущенная за два дня до публикации весов старшей модели, осталась под чистым MIT.

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

Лучшая иллюстрация того, как это работает на практике, — история Cursor. 19 марта 2026 года компания представила модель для кодинга Composer 2: “уровень фронтира”, 0,50 доллара за миллион входных и 2,50 за миллион выходных токенов. О базовой модели в анонсе не было ни слова. На следующий день пользователь нашёл в ответах API идентификатор, указывающий на Kimi K2.5 от Moonshot AI.

Дальше события развивались быстро. Вице‑президент Cursor Ли Робинсон подтвердил, что Composer 2 вырос из открытой базы. По его словам, на неё пришлась примерно четверть вычислений финальной модели, остальное дало собственное дообучение и RL. Сооснователь Аман Сангер рассказал, что команда сравнивала несколько базовых моделей и Kimi K2.5 оказалась сильнейшей. Он же признал ошибкой то, что базу не назвали сразу. Moonshot публично подтвердила, что всё шло в рамках авторизованного коммерческого партнёрства через Fireworks AI.

В мае вышел Composer 2.5 на той же базе. А в июне на своей конференции Compile Cursor объявил, что следующая модель, Composer 3, обучается с нуля, уже без внешней базы.

Что я вынес из этой истории как инженер:

• Сильная открытая база плюс дообучение на своих данных — рабочая стратегия. Для Cursor она стала основой собственного конвейера дообучения и RL, а следующим шагом компания объявила обучение модели с нуля.

• Юридическая сторона и доверие пользователей — не одно и то же. Cursor и Moonshot заявили, что использование шло в рамках авторизованного партнёрства, но умолчание о происхождении модели всё равно вызвало широкую дискуссию о прозрачности.

• Лицензию нужно читать до первого коммита и перечитывать при каждом обновлении версии.

Наблюдение 4. Self‑hosting LLM — это инфраструктура, а не кнопка «скачать»

Когда на планировании звучит «скачаем и развернём у себя», все почему‑то представляют одну видеокарту. Реальность другая. Объём памяти под веса MoE‑модели зависит от общего числа параметров, а не от числа активных на токен. Базе GLM-5.x на 744 млрд параметров в FP8 нужно около 800 ГБ видеопамяти только под веса. Сверху идут KV‑кэш, активации и служебная память движка, поэтому типовая конфигурация — узел из восьми H200. Для Kimi K3 Moonshot рекомендует минимум 64 ускорителя.

На другом полюсе — Muse Glimmer: в 4-битной квантизации языковая модель занимает меньше 20 ГБ. Но у неё другое назначение: локальные агенты на одной машине, а не серверный инференс флагманского уровня. Сравнивать её с флагманами на длинных агентных задачах я бы не стал.

В стеке для инференса выбор тоже сместился. Hugging Face TGI с декабря 2025 года находится в режиме поддержки, и для новых проектов я бы в первую очередь рассматривал vLLM или SGLang.

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

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

Теперь про деньги. В опубликованных оценках для зарезервированных GPU встречается порядок 2–5 млн токенов в день как точка окупаемости собственного железа, например в гайде Codersera. Но это не универсальный порог: против дорогого фронтир‑API окупаемость наступает намного раньше, чем против дешёвого API той же открытой модели у провайдера. Поэтому честнее сравнивать полную стоимость владения при своих допущениях:

TCO self-hosted = амортизация GPU + электричество и охлаждение
                + хосты, сеть и хранилище + резерв под отказоустойчивость
                + время платформенной команды и SRE

TCO API         = входные токены × цена входа + выходные токены × цена выхода
                + кэш и вспомогательные вызовы, с учётом пиковых тарифов

Для self‑hosting особенно чувствителен коэффициент утилизации GPU: простаивающий зарезервированный ускоритель продолжает стоить денег, и реальная цена токена равна месячным затратам, делённым на фактически обслуженные токены, а не на теоретическую пропускную способность.

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

Для FinTech есть аргумент, который может перевесить калькулятор. В ряде организаций и юрисдикций определённые классы персональных и платёжных данных нельзя передавать внешнему AI‑провайдеру или можно только при дополнительных договорных и технических условиях. Для таких задач вопрос «брать ли open‑weight» уже не стоит. Стоит вопрос «какую модель и на каком железе».

Что делают команды, которые переживают смену модели без боли

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

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

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

На этом контуре держатся пять практик, и за каждой стоит история из разобранного выше.

1. Контракт возможностей, а не только совместимый API. OpenAI‑совместимый эндпоинт даёт одинаковый HTTP‑интерфейс, но не одинаковое поведение. Модели различаются поддержкой вызова инструментов и JSON Schema, максимальной длиной входа и выхода, режимами рассуждений, мультимодальностью, семантикой стриминга и чувствительностью к параметрам генерации. Поэтому для каждой модели в реестре я бы явно фиксировал, что она умеет, и маршрутизировал задачи только туда, где требования совпадают. Совместимость API не равна совместимости поведения.

2. Fallback по типу ошибки и состоянию запроса. Переключаться на резервную модель имеет смысл при 5xx или таймауте соединения, пока ответ ещё не начал приходить. На 429 политика ограничения запросов выбирает между ожиданием по Retry‑After с backoff и переключением на другой бэкенд, причём резерв не должен сидеть в том же пуле квот. Ошибка в самом запросе, переполнение контекста или отказ по политике требуют другой обработки. Если стриминг ответа уже начался, fallback перестаёт быть прозрачной заменой: повтор запроса целиком покажет клиенту две разные попытки, поэтому запрос нужно явно завершать ошибкой. Для агентов всё ещё строже. Представьте: агент уже вызвал инструмент, списание прошло, а ответ модели завис. Шлюз переключает запрос на резервную модель, та повторяет вызов инструмента, и вы получаете двойное списание. Поэтому для агентных сценариев автоматический fallback на уровне шлюза я бы отключал, а повтор решал в приложении с учётом идемпотентности и состояния вызовов.

3. Многоступенчатый eval под версионным контролем. Набор из 100–300 примеров годится для первичной проверки, но не для решения о миграции: при двадцати классах это пять‑пятнадцать примеров на класс. Дальше нужен квалификационный набор на тысячи примеров с редкими категориями и сложными случаями, а после него — теневой прогон на реальном трафике без влияния на пользователей. Квалификационный набор должен быть отделён от данных, на которых дообучают модель или подбирают промпты, иначе вы проверяете модель на том, что она уже видела. Cursor, по словам сооснователя, выбирал базу именно через собственные оценки.

4. Воспроизводимость. Идентичность модели в продакшене — это не только название и ревизия весов, но и ревизия токенизатора, версия движка инференса, хэш его конфигурации, квантизация, шаблон промпта и версия политики маршрутизации. Одна и та же ревизия в разных рантаймах может вести себя по‑разному. Модель за именем у провайдера, как у DeepSeek в августе, может смениться, даже если об этом написано только в changelog, и без этих данных вы не поймёте, что именно изменилось.

5. Для критичных нагрузок — минимум два квалифицированных семейства моделей. После истории с GLM-5.3 это уже не перестраховка, а план на случай, если юристы скажут «нет». Для некритичных сервисов второе семейство может не окупить расходы на eval и поддержку промптов.

Вот как это выглядит в конфигурации шлюза:

model_list:
  # Массовая задача без side effects: self-hosted open-weight модель за vLLM
  - model_name: payments-classifier
    litellm_params:
      model: hosted_vllm/glm-5.3
      api_base: http://vllm-glm.llm.svc.cluster.local:8000/v1
      timeout: 15

  # Резерв: закрытая фронтир-модель через API
  - model_name: payments-classifier-frontier
    litellm_params:
      model: anthropic/<frontier-model-id>   # ID берём из документации провайдера
      api_key: os.environ/ANTHROPIC_API_KEY
      timeout: 30

  # Eval-алиасы: те же деплойменты, но без fallback, чтобы мерить ровно одну модель
  - model_name: eval-glm-5.3
    litellm_params:
      model: hosted_vllm/glm-5.3
      api_base: http://vllm-glm.llm.svc.cluster.local:8000/v1
      timeout: 60

  - model_name: eval-frontier
    litellm_params:
      model: anthropic/<frontier-model-id>
      api_key: os.environ/ANTHROPIC_API_KEY
      timeout: 60

litellm_settings:
  num_retries: 0   # повторы решаем в приложении, по типу ошибки
  fallbacks:
    # Только для классификатора: у него нет side effects.
    # Для агентных сценариев fallback на уровне шлюза не настраиваем.
    - payments-classifier: ["payments-classifier-frontier"]

А так поднимается сама модель с зафиксированными ревизиями:

# Версию vLLM фиксируем в deployment manifest digest'ом образа (image@sha256:...), а не тегом;
# здесь — ревизии весов, кода модели и токенизатора на Hugging Face
vllm serve <org>/<glm-5.3-fp8-repo> \
  --revision <commit-sha-весов> \
  --code-revision <commit-sha-кода> \
  --tokenizer-revision <commit-sha-токенизатора> \
  --served-model-name glm-5.3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072 \
  --port 8000
# --code-revision нужен, если модель подтягивает код из репозитория (trust_remote_code).
# Контекст намеренно ограничен 128K вместо 1M: классификатору длинный контекст не нужен,
# а ограничение снижает потенциальный расход памяти под KV-кэш и оставляет больше ресурса
# для конкурентных запросов. Фактический эффект зависит от gpu-memory-utilization и планировщика.

Скрипт первичной квалификации я держу простым. Сервисы у нас на Kotlin, но такой скрипт быстрее собрать на Python. Он ходит в eval‑алиасы без fallback: однажды я сам радовался «качеству» открытой модели, пока не выяснил, что часть запросов по таймауту незаметно уходила на резервную.

Скрипт раздельно считает долю валидных ответов, точность среди валидных и сквозной успех задачи. Для двадцати несбалансированных классов одной точности мало, поэтому он добавляет macro‑F1 и полноту по каждому классу: так видно, если модель проваливает редкую, но критичную категорию.

Ошибки транспорта классифицируются по HTTP‑коду, прогрев идёт на отдельном файле, а набор прогоняется при фиксированной конкурентности 16 запросов. Это функциональная квалификация, а не нагрузочный тест: TTFT, пропускную способность и другие уровни конкурентности он не меряет.

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

JSON здесь намеренно запрашивается инструкцией в промпте ради переносимости между кандидатами; в продакшене, если все кандидаты это поддерживают, лучше structured output с валидацией схемы (Python):

import json
import statistics
import time
from collections import Counter
from concurrent.futures import ThreadPoolExecutor

import openai
from openai import OpenAI

# Eval-алиасы в шлюзе настроены без fallback: меряем ровно одну модель
client = OpenAI(base_url="http://litellm.llm.svc.cluster.local:4000/v1", api_key="sk-local", max_retries=0)

CANDIDATES = ["eval-glm-5.3", "eval-frontier"]
CONCURRENCY = 16
PROMPT = (
    'Определи категорию обращения. Верни только JSON вида {{"label": "<категория>"}}. '
    "Допустимые категории: {labels}.\n\nТекст: {text}"
)


def ask(model: str, row: dict, labels: list[str]) -> dict:
    true = row["label"].lower()
    started = time.perf_counter()
    try:
        resp = client.chat.completions.create(
            model=model,
            temperature=0,
            max_tokens=32,  # с запасом над длиной JSON; для моделей с рассуждениями лимит подбирают отдельно
            messages=[{"role": "user", "content": PROMPT.format(labels=", ".join(labels), text=row["text"])}],
        )
    except openai.APITimeoutError:
        return {"status": "timeout", "true": true, "pred": None, "latency": time.perf_counter() - started}
    except openai.APIConnectionError:
        return {"status": "connection_error", "true": true, "pred": None, "latency": time.perf_counter() - started}
    except openai.APIStatusError as exc:  # общий класс HTTP-ошибок: классифицируем по коду ответа
        return {"status": f"http_{exc.status_code}", "true": true, "pred": None, "latency": time.perf_counter() - started}
    # Ошибки программирования и конфигурации не перехватываем: прогон должен упасть
    latency = time.perf_counter() - started
    try:
        pred = json.loads(resp.choices[0].message.content)["label"].strip().lower()
    except (json.JSONDecodeError, KeyError, TypeError, AttributeError):
        pred = None
    if pred not in labels:
        return {"status": "malformed_output", "true": true, "pred": None, "latency": latency}
    return {"status": "valid", "true": true, "pred": pred, "latency": latency}


def p95(values: list[float]) -> float | None:
    if len(values) < 20:
        return None
    return round(statistics.quantiles(values, n=20, method="inclusive")[-1], 2)


def per_class(results: list[dict], labels: list[str]) -> tuple[dict, float]:
    recall, f1_scores = {}, []
    for label in labels:
        tp = sum(r["true"] == label and r["pred"] == label for r in results)
        support = sum(r["true"] == label for r in results)
        predicted = sum(r["pred"] == label for r in results)
        rec = tp / support if support else 0.0
        prec = tp / predicted if predicted else 0.0
        recall[label] = round(rec, 3)
        f1_scores.append(2  prec  rec / (prec + rec) if prec + rec else 0.0)
    return recall, round(sum(f1_scores) / len(f1_scores), 3)


def evaluate(model: str, warmup_rows: list[dict], eval_rows: list[dict], labels: list[str]) -> dict:
    with ThreadPoolExecutor(max_workers=CONCURRENCY) as pool:
        list(pool.map(lambda r: ask(model, r, labels), warmup_rows))  # прогрев, в метрики не идёт
        results = list(pool.map(lambda r: ask(model, r, labels), eval_rows))
    total = len(results)
    valid = [r for r in results if r["status"] == "valid"]
    correct = sum(r["pred"] == r["true"] for r in valid)
    recall_by_class, macro_f1 = per_class(results, labels)  # невалидный ответ — промах по своему классу
    return {
        "model": model,
        "valid_response_rate": round(len(valid) / total, 3),
        "accuracy_among_valid": round(correct / len(valid), 3) if valid else None,
        "task_success_rate": round(correct / total, 3),
        "macro_f1": macro_f1,
        "recall_by_class": recall_by_class,
        "failures": dict(Counter(r["status"] for r in results if r["status"] != "valid")),
        "p95_all_requests_sec": p95([r["latency"] for r in results]),
        "p95_valid_requests_sec": p95([r["latency"] for r in valid]),
    }


def load(path: str) -> list[dict]:
    with open(path, encoding="utf-8") as f:
        return [json.loads(line) for line in f]


if name == "__main__":
    warmup_rows = load("warmup.jsonl")    # отдельный набор, не пересекается с golden set
    eval_rows = load("golden_set.jsonl")  # не используется для дообучения и подбора промптов
    labels = sorted({row["label"].lower() for row in eval_rows})
    for model in CANDIDATES:
        print(evaluate(model, warmup_rows, eval_rows, labels))

Open‑weight или закрытая модель: что именно сравнивать в продакшене

Когда меня спрашивают «так что в итоге брать?», я прохожу с командой по одному и тому же маршруту из вопросов. Он показан на рис. 3.

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

Где мой вывод не работает

Честно о границах этого разбора:

• Цены и лицензии проверены на 16 сентября 2026 года, события в моделях описаны по конец августа. На этом рынке всё меняется помесячно, поэтому цифры стоит перепроверить на дату своего решения.

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

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

• Cursor может себе позволить серьёзный бюджет на RL. Средней продуктовой команде повторить путь «дообучили открытую базу до уровня фронтира» так просто не получится.

Вывод: почти догнали, но не везде и не бесплатно

Так догнали ли открытые модели закрытые? По агрегированным метрикам они отстают от фронтира на месяцы, а не на поколения.

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

Что можно сделать уже на этой неделе:

1. Выписать все LLM‑вызовы в сервисе и разделить их на массовые без side effects и агентные с инструментами.

2. Собрать 100–300 размеченных примеров для самой дорогой массовой задачи как первую ступень eval.

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

4. Спрятать модели за шлюзом с телеметрией по модели и ревизии, даже если пока остаётесь на закрытом API.

Open‑weight модель — не бесплатный обед, а просто другой счёт. Вместо оплаты за токены вы платите вниманием к лицензиям, версиям и инфраструктуре. Хорошая новость в том, что над этим счётом у вас намного больше контроля, чем над тарифом API. Плохая — взамен вы берёте на себя инфраструктурные риски.

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

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

На открытых уроках разберём практические подходы к работе с LLM в реальных системах:

• 12 октября в 20:00. «Сколько стоит один ответ вашего AI‑агента — и почему он думал 40 секунд». Записаться.

• 20 октября в 20:00. «Tool Calling и MCP: интеграция ИИ‑агентов с корпоративными системами». Записаться.

• 27 октября в 18:00. «Langfuse в AgentOps: наблюдаемость и оценка LLM‑агентов». Записаться.