Mistral Large 4 у себя: уроки, которые дорого стоят

Когда Mistral выпустила веса Mistral Large 4, модели примерно на 1 триллион параметров с около 52 миллиардами активных, у меня в почте появился один и тот же вопрос: можем ли мы запустить это сами? Self-hosting открытых весов перестал быть хобби и стал полноценным архитектурным вариантом, а значит, команды скоро начнут делать много дорогих ошибок. Я уже видел несколько таких случаев. Эта статья написана как сборник уроков: конкретные способы, которыми практики неправильно подходят к self-hosting, и как в каждом случае выглядит правильное решение.

Ошибка 1: считать «открытые веса» значит «делай что хочешь»

Первая ошибка случается ещё до того, как кто-то прикоснётся к GPU. Mistral Large 4 распространяется по модифицированной лицензии в духе MIT с важным исключением: если вы или ваши аффилированные лица управляете бизнесом на основе модели как сервиса, перед коммерческим использованием нужна отдельная коммерческая лицензия от Mistral. Для компании, которая запускает инференс внутри себя, например для суммаризации документов или для ассистента программиста сотрудников, это, скорее всего, нормально. А стартап, который планирует перепродавать инференс, упирается в стоп-сигнал, пока не напишет Mistral.

Ошибаются в обе стороны. Одни видят слово «open» в пресс-релизе, строят на весах коммерческий продукт и узнают об ограничении во время аудита перед инвестициями, что хуже всего возможного. Другие перестраховываются и считают, что лицензия запрещает любое коммерческое использование, хотя она на самом деле направлена против конкурирующих провайдеров инференса. Решение скучное, но обязательное: пусть юристы прочитают сам текст лицензии, а не анонс. Называете ли вы это «открытыми весами» или «доступными весами», а сообщество из-за этого громко спорит, и спорит не зря, инженерное решение должно опираться на то, что условия реально позволяют вашему бизнесу.

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

Ошибка 2: считать железо по маркетинговой странице, а не по математике

Вот ошибка, которая сжигает больше всего денег. Инженер читает «1T параметров», смотрит на четыре H200 в серверной компании и решает, что 540 ГБ видеопамяти — примерно достаточно. Это не так, и причина в арифметике, которая занимает девяносто секунд и избавляет от квартала неловкости.

При точности BF16 триллиону параметров нужно около 2 ТБ памяти только под веса. Квантование до 8 бит снижает это примерно до 1 ТБ, а до 4 бит — примерно до 500–560 ГБ, и это ещё без KV-кэша, активаций и накладных расходов на сервинг. Сервер на 540 ГБ вмещает модель в 4 битах, только если вас устраивает короткое контекстное окно и несколько одновременных пользователей. Архитектура mixture-of-experts (52 млрд активных параметров на токен) помогает с вычислениями на токен, но для памяти ничего не делает: все триллион параметров всё равно должны где-то лежать и быть адресуемыми. А в MoE веса экспертов используются непредсказуемо, поэтому вынос их в оперативную память CPU убивает задержку сильнее, чем для плотных моделей.

Решение — идти от требований к сервингу, а не от железа. Сначала определите целевую длину контекста, конкурентность и токены в секунду, затем выберите уровень квантования, который можете себе позволить, и только потом подбирайте железо. Если получится восемь H200 или пара узлов класса NVL72, и от этого числа станет не по себе, — хорошо, значит, модель работает как надо. Смежную проблему мы разбирали в статье что делать, когда у GPU кончается VRAM. Описанные там варианты (выгрузка, более мелкие кванты, меньшие модели) применимы и здесь, только в масштабе дата-центра.

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

Обратите внимание: честная версия таблицы включает KV-кэш и накладные расходы. Нечестная, где учтены только веса, — именно так команды получают модель, которая загружается, но не может обслужить больше трёх пользователей.

Ошибка 3: считать квантование бесплатным обедом

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

Картина, которую я видел много раз: команда тестирует своё 4-битное развёртывание на тестах с множественным выбором в духе MMLU, видит падение на 1%, и релиз уходит в прод. Потом пользователи жалуются, что длинные рефакторинги кода по нескольким файлам ломаются или что JSON для вызова инструментов с малой вероятностью, но часто портится. Агрессивное квантование непропорционально бьёт по долгим, структурированным задачам и задачам с низкой температурой, то есть именно по агентным и кодовым сценариям, ради которых вообще берут модель топ-уровня. Среднее почти не меняется, а хвост разваливается.

Квантуйте ровно настолько, насколько позволяет оценка на вашей задаче, а не настолько, насколько заставляет VRAM. Прогоните промпты вашей нагрузки через сборки FP8, 4 бита и 3 бита и сравните. Если 3 бита проходят ваши оценки, поздравляю: счёт за железо только что уменьшился вдвое. Если не проходят, никакое среднее по бенчмаркам не спасёт. И предпочитайте нативные квантованные релизы, когда лаборатория их выпускает: Mistral опубликовала вариант NVFP4 вместе с весами BF16, и квант от производителя с измеренной потерей качества лучше конвертации GPTQ от сообщества, которую вы проверили за один вечер.

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

Ошибка 4: сравнить цену API с ценой GPU и назвать это анализом TCO

Классическая таблица: «API стоит $2,10 за миллион выходных токенов, зарезервированный GPU-узел стоит X долларов в час, значит, self-hosting окупается при Y токенах в месяц». Такая таблица почти всегда неверна, и ошибается она в дорогую сторону.

Что она упускает: загрузку. API даёт 100% загрузки чужих мощностей, и вы платите за токен. Ваш собственный кластер даёт ту загрузку, которую выдаёт ваш трафик, а большинство внутренних нагрузок пиковые: нагрузка днём, простой ночью, всплески вокруг релизов. Кластер, рассчитанный на пик, большую часть дня простаивает. Добавьте затраты, которых нет в таблице: дежурства по стеку сервинга, где теперь есть обновления vLLM, несовпадения драйверов CUDA и вызов в два ночи, когда KV-кэш фрагментируется; постоянную смену моделей (вы же будете перепроверять каждый новый релиз весов, и ваш набор оценок этого требует); и упущенную выгоду от ML-инженера, который вместо создания продукта стал нянькой для GPU.

Есть и проблема движущейся цели, которую никто не закладывает в расчёты. Mistral снизила цену API на эту модель почти вдвое между превью и полным релизом: входные токены подешевели с $1,36 до $0,70 за миллион. Любой расчёт окупаемости self-hosting, сделанный по старой цене, теперь фантастика. Топовый инференс дешевеет с квартальной периодичностью, а железо амортизируется на многолетней. Эта асимметрия тихо убивает большинство бизнес-кейсов self-hosting.

Решение: поднимайте собственный инференс только по причинам, которые API структурно не может обеспечить. Такие причины существуют и реальны, но «дешевле в масштабе» среди них редко встречается на тех масштабах, где работает большинство компаний.

Когда self-hosting действительно выигрывает

Так когда же запуск моделей класса Mistral локально бьёт API? Понаблюдав за командами, которые делали это правильно и неправильно, выигрышные случаи сводятся к четырём группам:

• Резидентность данных и суверенитет. Регулируемые отрасли, работа, связанная с оборонкой, и европейские организации с жёсткими требованиями к юрисдикции. Одно ограничение, с которым я сталкивался на практике: компании запретили использовать модели китайского происхождения по соображениям комплаенса. Открытые веса от европейской лаборатории с проверяемым происхождением решили задачу, которую не решил ни один договор с API.
• Изолированные или периодически подключённые среды. Если сеть нельзя считать гарантированно доступной, локальные веса — это и есть вся архитектура. Мы разбирали этот подход в статье как построить LLM, которая работает офлайн.
• Постоянные, предсказуемые нагрузки большого объёма. Пакетная обработка документов, работающая круглосуточно с ровной пропускной способностью, действительно может победить оплату за токен, потому что по своей природе решает проблему загрузки.
• Дообучение и модификация. Нельзя дообучить чужой API дальше того, что позволяет их эндпоинт для файнтюнинга. Владение весами означает владение циклом обучения: продолжение претрейна на доменных корпусах, собственное выравнивание, дистилляция в более компактные развёртывания.

Обратите внимание, чего в списке нет: задержки. Self-hosting MoE на триллион параметров не даст меньшей задержки, чем хорошо настроенный API, если вы не готовы агрессивно вкладываться в спекулятивное декодирование и сервинг, оптимизированный под batch-1. И обратите внимание на ещё одно отсутствующее пункт: «избавление от зависимости от вендора». Веса, которые вы скачиваете сегодня, через год будут отставать на два поколения, и вы снова окажетесь перед тем же решением. Это, кстати, неплохой аргумент в пользу привычки некоторых практиков хранить локальные копии значимых релизов весов. Хранилище дешёвое, а возможности ценны.

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

Ошибка 5: оценивать по бенчмаркам, а не по своей нагрузке

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

Публичные бенчмарки отвечают на вопрос «модель в целом способна?». Они не отвечают на вопрос «классифицирует ли эта модель наши тикеты поддержки с нужным тоном и форматом, в 4 битах, при нашей конкурентной нагрузке?». Мы уже писали о том, почему AI-бенчмарки не видят 90% реальной работы, и self-hosting делает этот разрыв только заметнее: теперь вы отвечаете за все переменные, которыми раньше управлял провайдер API. Стек развёртывания, настройки сэмплера, соглашения о системном промпте, с которыми обучалась модель, всё это теперь ваше, и всё это можно сделать неправильно.

Решение — трёхуровневая система оценки, которую вы строите до того, как зафиксируете железо:

1. Эталонный набор из продакшена. Несколько сотен реальных промптов с проверенными идеальными ответами, покрывающих ваше реальное распределение задач, включая длинные, запутанные многоходовые случаи.
2. Регрессионный стенд. Каждый кандидат (API или локальная модель, FP8 или 4 бита, старые веса или новый релиз) автоматически проходит эталонный набор. Оценивайте с помощью сильной модели-судьи и выборочной проверки людьми; не доверяйте судье вслепую на структурированных выводах.
3. Теневой период. Две недели запускайте локальное развёртывание параллельно с API на живом трафике, сравнивая ответы и измеряя реальную задержку под реальной нагрузкой. Именно здесь проявляются ошибки в расчёте KV-кэша и провалы на хвосте квантования.

Этот стенд окупается при первом же новом релизе весов, когда вы за один день сможете ответить на вопрос «стоит ли обновляться?» данными, а не ощущениями на совещании.

Главный вывод: открытые веса изменили вопрос, а не ответ

Год назад вопрос «стоит ли нам поднимать у себя модель топ-уровня?» был гипотетическим: передовые модели нельзя было скачать. Mistral Large 4 вместе с волной других моделей на триллион параметров превратил его в реальное решение с реальными деньгами. Но сама схема принятия решения не изменилась, просто теперь её нужно применять обязательно.

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