MoE-модель: развернуть самому или выбрать API в 2026

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

Быстрое решение: при низкой загрузке, резких пиках или меняющихся весах выбирать API либо короткую аренду вычислений; к долгосрочному самостоятельному запуску переходить только после проверки полного резидентного объёма, совместимости среды и фактической загрузки.

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

MoE-модель: развернуть самому или выбрать API по фактической вместимости

Главная ошибка в расчётах — использовать активные параметры как прямой эквивалент требуемой видеопамяти.

У MoE-модели в каждом проходе действительно активируется только часть экспертов. Но это не означает, что остальные веса можно полностью исключить из требования к памяти. Конкретный рантайм может:

• загружать все веса на ускорители;
• распределять экспертов между устройствами;
• читать часть данных с CPU или диска;
• использовать экспертный параллелизм;
• оставлять реплицированными слои внимания и общие компоненты.

Поэтому расчёт должен разделять минимум четыре слоя:

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

Удобная базовая формула выглядит так:

M_необходимая =
M_веса
+ M_метаданные
+ M_рабочая
+ M_KV
+ M_резерв

Это не формула цены. Это фильтр реализуемости.

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

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

Для Kimi K3 официальная карточка указывает 2,8 триллиона параметров, 896 экспертов, активацию 16 экспертов и контекст до 1 миллиона токенов. Эти данные полезны для понимания архитектуры, но сами по себе не являются готовым требованием к памяти производственного сервиса. (huggingface.co)

Официальная карточка Kimi K3 и технический отчёт модели должны использоваться отдельно от приблизительных оценок сообщества.

Почему файл весов ещё не означает готовое окружение

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

Формат квантования

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

Проверяются:

• тип квантования весов;
• поддержка формата в выбранном рантайме;
• наличие нужных ядер на целевом ускорителе;
• требования к типу данных активаций;
• возможность использовать квантованный KV-кэш;
• необходимость специального пользовательского кода.

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

Распределение по устройствам

У MoE-сервиса могут одновременно применяться:

• tensor parallelism — разделение тензорных операций;
• pipeline parallelism — разнесение слоёв по этапам;
• expert parallelism — распределение экспертов;
• data parallelism — копии обслуживающих процессов.

В официальной документации vLLM экспертный параллелизм описан как отдельный режим: эксперты распределяются по группе EP, а части внимания могут работать через tensor parallelism. В качестве примера документация показывает конфигурацию с TP и DP, формирующими общую группу экспертного параллелизма. Это означает, что число устройств определяется не только объёмом весов, но и выбранной схемой коммуникации. (docs.vllm.ai)

Документация vLLM по экспертному параллелизму полезна именно как проверка топологии, а не как обещание готовой производительности для любой модели.

Связь между узлами

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

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

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

Сравнение трёх маршрутов до покупки инфраструктуры

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

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

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

Как полезная загрузка меняет стоимость одного запроса

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

Для собственного размещения:

C_самостоятельно =
C_вычисления
+ C_хранение
+ C_передача
+ C_инженеры
+ C_мониторинг
+ C_восстановление
+ C_резерв
+ C_простой

Цена завершённого запроса:

P_запрос =
C_самостоятельно / N_успешных_запросов

Где N_успешных_запросов — не число входящих обращений, а число запросов, которые завершились в целевой задержке и без ручного повтора.

Для API:

C_API =
C_входные_токены
+ C_выходные_токены
+ C_режим_рассуждения
+ C_инструменты
+ C_повторы

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

Минимальный журнал должен содержать:

• число запросов;
• входную и выходную длину;
• параллельность;
• распределение по часам;
• долю пиков;
• целевую задержку;
• тайм-ауты;
• повторы;
• долю запросов с инструментами;
• процент неуспешных завершений.

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

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

Точка баланса появляется там, где обе схемы обслуживают одинаковый трафик при одинаковом качестве:

C_API(Q, L, R, S) =
C_самостоятельно(Q, L, R, S)

Здесь:

• Q — объём запросов за выбранный период;
• L — распределение входных и выходных токенов;
• R — уровень параллельности и пики;
• S — целевая задержка и допустимая доля ошибок.

Если меняется хотя бы один из этих параметров, точка равенства сдвигается.

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

Для крупной MoE-модели следует отдельно считать:

• вместимость весов в выбранном формате;
• рабочую память рантайма;
• KV-кэш при целевом контексте;
• память под пакетирование;
• коммуникационную нагрузку;
• резерв для обновления и аварийного перезапуска.

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

Kimi K3, DeepSeek V4 и неподтверждённая строка Qwen3.8 Max

Kimi K3 и DeepSeek V4 можно использовать как разные калибровочные примеры, но не как рейтинг производительности.

В официальной карточке Kimi K3 заявлены 2,8 триллиона параметров, 16 активных экспертов из 896 и контекст до 1 миллиона токенов. Это показывает, почему число активных параметров нельзя напрямую превращать в объём памяти: модель разреженная, но её полная структура и режим контекста влияют на размещение и KV-кэш. (huggingface.co)

Для DeepSeek V4 официальные материалы описывают варианты Pro и Flash с разным общим и активным объёмом параметров, а также смешанные форматы FP4 и FP8 для соответствующих компонентов. Такие сведения должны использоваться только вместе с конкретной карточкой, индексом файлов и инструкцией запуска. (github.com)

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

Для каждой модели стоит вести три отдельные колонки:

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

Такой порядок не позволяет подменить эксплуатационный результат размером файла в репозитории.

Пошаговая проверка перед долгосрочным обязательством

Первый шаг: зафиксировать бизнес-нагрузку

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

Второй шаг: определить сервисную цель

Записать допустимую задержку, максимальную параллельность, контекст, длину ответа и допустимую долю повторов. Без этого невозможно определить размер KV-кэша и полезный throughput.

Третий шаг: подтвердить модельные файлы

Проверить официальный README, конфигурацию, индекс весов, лицензию и формат квантования. Для DeepSeek V4 следует использовать официальную карточку модели, а не стороннее описание.

Четвёртый шаг: проверить рантайм

Сверить версию vLLM или другого выбранного движка, поддержку модели, квантования, tensor parallelism и expert parallelism. В документации vLLM отдельно указывается, что экспертный параллелизм меняет поведение MoE-слоёв и требования к коммуникации. (docs.vllm.ai)

Пятый шаг: измерить три уровня результата

Зафиксировать:

• запускается ли процесс;
• выдаёт ли модель ответы;
• выдерживает ли сервис целевую параллельность.

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

Шестой шаг: пересчитать стоимость успешного запроса

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

Седьмой шаг: установить дату отказа

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

Частые вопросы перед выбором маршрута

Активные параметры — это достаточная основа для оценки памяти?

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

Как понять, что запросов уже достаточно для собственного запуска?

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

Что включать в эксплуатационную стоимость?

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

Что делать при частой смене весов?

Использовать API или короткие периоды аренды, пока не подтверждены версия модели, формат квантования и производственный сценарий.

Сравнимы ли Kimi K3 и DeepSeek V4?

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

Решение по пяти признакам

Перед покупкой долгосрочной инфраструктуры команда должна отметить каждый пункт:

• [ ] Полный объём весов, метаданных, рабочей памяти и KV-кэша подтверждён для выбранного формата.
• [ ] Рантайм действительно поддерживает модель, квантование и схему параллелизма.
• [ ] Реальный журнал запросов содержит пики, длины токенов, повторы и целевую задержку.
• [ ] Стоимость простоя, мониторинга, восстановления и инженерного сопровождения включена в расчёт.
• [ ] Есть проверенный сценарий перезапуска и восстановления после сбоя.
• [ ] Версия модели достаточно стабильна, чтобы оправдать долгосрочное обязательство.
• [ ] Команда может обслуживать межузловую коммуникацию и обновления среды.

Если не отмечен первый или второй пункт, закупку нужно остановить: вместимость или совместимость ещё не доказаны.

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

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

Где проходит практическая граница между API, арендой и собственным узлом

API предпочтительнее, когда:

• запросы приходят неравномерно;
• модель и её веса быстро меняются;
• команда не готова поддерживать распределённый рантайм;
• приоритетом является скорость запуска и возможность отказаться.

Краткосрочная аренда предпочтительнее, когда:

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

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

Долгосрочное самостоятельное размещение оправдано, когда:

• трафик стабилен;
• требования к контролю данных существенны;
• модель и формат зафиксированы;
• команда умеет поддерживать TP, EP, мониторинг и восстановление;
• стоимость простоя уже включена в расчёт;
• API действительно становится дороже на одинаковой полезной нагрузке.

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

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

FAQ