Самостоятельный запуск триллионных моделей

У Kimi K3 заявлено 2,8 трлн параметров, но на один токен активируются только 16 из 896 экспертов. Это снижает вычислительную работу на токен, а не превращает модель в модель на 50 млрд параметров: официальная модельная карта Kimi K3. Поэтому победитель в большинстве предварительных проверок — не немедленное самостоятельное размещение, а API или временный многосерверный кластер, пока команда не подтвердит полный путь памяти и стабильную скорость на реальной нагрузке.

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

Активные параметры и вес модели отвечают на разные вопросы

Главная ошибка возникает, когда активные параметры напрямую подставляют в формулу объёма видеопамяти. Для MoE-модели это неверная замена переменных.

Нужно разделять как минимум четыре понятия:

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

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

У Kimi K3 официальная документация указывает 2,8 трлн общих параметров и активацию 16 экспертов из 896 на токен. В той же документации описаны собственная архитектура внимания, нативная мультимодальность и контекст до 1 млн токенов. Эти характеристики нельзя свести к одной строке «активно около 50 млрд», потому что у каждой есть отдельное влияние на память и производительность. Подтверждение архитектуры и режима запуска опубликовано в репозитории Moonshot AI.

По общему числу или по активным параметрам считать память MoE-модели?

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

DeepSeek V4 показывает ту же проблему в другом масштабе. В официально опубликованных материалах описываются варианты Pro и Flash, различающиеся общим объёмом, шириной и числом экспертов. Текущие карточки на Hugging Face указывают для DeepSeek-V4-Pro около 1,6 трлн параметров, а для DeepSeek-V4-Flash — около 158 млрд параметров; значения следует проверять по актуальному репозиторию перед расчётом, поскольку модельные файлы и конфигурации могут обновляться. Сводные архитектурные сведения доступны в документации Transformers для DeepSeek V4 и в официальном пространстве моделей DeepSeek.

Практический вывод простой: активность экспертов отвечает на вопрос «сколько вычислять», а общий вес — на вопрос «что необходимо разместить и обслуживать».

Теоретическая разрядность не равна готовому объёму видеопамяти

Вторая ошибка — умножить число параметров на фиксированное количество байтов и принять результат за требуемую ёмкость GPU.

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

память весов ≈ общее число параметров × среднее число байтов на параметр.

Она полезна только как нижняя граница. В реальном файле появляются:

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

Поэтому MXFP4, FP4 или FP8 нельзя трактовать как обещание точного значения «байт на параметр». Разрядность описывает представление данных, но не весь путь от файла до рабочего адресного пространства GPU.

Для Kimi K3 официальный репозиторий указывает нативные веса MXFP4 и активации MXFP8, а также рекомендуемые движки запуска. В описании интеграции Kimi K3 в vLLM отдельно показаны параметры запуска, требования к Docker-образам и особенности поддержки FlashInfer. Это важнее рекламного расчёта по одной разрядности: команда должна проверить, поддерживает ли выбранный стек именно такой формат и не создаёт ли временную копию при загрузке.

Для DeepSeek V4 ситуация также зависит от варианта модели и движка. В материалах vLLM указана поддержка Pro и Flash, но разработчики отдельно отмечают, что это первоначальная реализация и дальнейшие оптимизации продолжаются. Описание запуска и ограничений опубликовано в официальной записи vLLM о DeepSeek V4.

Можно ли после сжатия запустить триллионную модель на одном сервере?

Иногда файл весов действительно можно разместить на одном сервере с большим объёмом памяти. Но «файл помещается» и «модель стабильно обслуживает запросы» — разные результаты проверки. Один сервер должен одновременно выдержать загрузку весов, рабочие буферы, KV Cache, фрагментацию памяти, служебные процессы и целевую конкуренцию запросов.

Если хотя бы один из этих пунктов не измерен, вывод «модель работает на одной машине» преждевременный.

Вес загружается, но запуск всё равно может завершиться ошибкой

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

Основные дополнительные области:

• KV Cache — состояние внимания для уже обработанных токенов;
• буферы активаций — промежуточные результаты вычислений;
• рабочая память ядер — пространство для fused-операций, маршрутизации и преобразования форматов;
• коммуникационные буферы — данные для tensor parallelism, expert parallelism и коллективных операций;
• граф выполнения — память, которую движок резервирует для заранее подготовленных операций;
• резерв фреймворка — часть памяти, недоступная приложению из-за политики аллокатора;
• память мультимодального входа — изображения, видео, промежуточные признаки и токены специальных форматов.

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

DeepSeek V4 специально оптимизирует работу с длинным контекстом. В техническом разборе на Hugging Face показана архитектура, уменьшающая относительный размер KV Cache по сравнению с традиционным подходом. Это полезное архитектурное преимущество, но оно не отменяет необходимость измерять реальный кэш в выбранном движке, при заданном числе последовательностей и конкретной длине входа.

До покупки или аренды узлов нужно зафиксировать:

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

Без этих параметров расчёт памяти остаётся только оценкой файла, а не оценкой сервиса.

Многосерверная схема устраняет дефицит памяти, но добавляет коммуникационный долг

Разделение модели по узлам не означает автоматического появления производственного сервиса. Оно меняет тип проблемы.

При tensor parallelism часть операций требует обмена между GPU. При expert parallelism маршрутизируемые токены могут проходить через узлы, где находятся выбранные эксперты. При длинном контексте увеличивается объём состояния, который нужно хранить и синхронизировать. Если сеть или топология не соответствуют характеру обмена, суммарная память всех узлов не превращается в суммарную полезную производительность.

Нужно отдельно проверять:

• пропускную способность и задержку межузловой сети;
• расположение экспертов;
• объём all-to-all-обмена;
• устойчивость к потере одного узла;
• время повторной загрузки весов;
• поведение при переполнении KV Cache;
• возможность поэтапного обновления;
• журналирование ошибок на всех узлах;
• синхронность версий драйвера, CUDA, контейнера и движка.

Официальный рецепт vLLM для Kimi K3 показывает запуск с tensor parallelism на нескольких GPU и прямо указывает на сложность зависимостей: для текущего варианта рекомендуются готовые Docker-образы с предварительными компонентами. Это означает, что совместимость следует проверять не по названию архитектуры, а по точному сочетанию версии движка, образа, ускорителей и параметров запуска. Рецепт запуска Kimi K3 в vLLM служит исходной точкой, но не доказательством готовности любой произвольной топологии.

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

Короткий успешный запуск не доказывает пригодность для AI Agent

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

Для Kimi K3 дополнительно важно учитывать, что модель ориентирована на агентские сценарии, а её официальное описание требует сохранять полный ответ ассистента при многошаговых диалогах и вызовах инструментов, включая reasoning-содержимое и tool calls. Это меняет размер истории, которую приложение может передавать обратно. Детали описаны в официальной модели Kimi K3.

Тестовый набор должен включать не только короткие вопросы. Минимальная программа проверки:

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

Записывать нужно не одну среднюю скорость, а четыре группы свидетельств:

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

Если тест длился несколько минут и использовал один короткий запрос, он подтверждает только факт запуска. Он не подтверждает пригодность к постоянной агентской нагрузке.

Чек-лист перед решением о собственном кластере

Ниже — минимальная последовательность, которую можно передать платформенной команде и использовать как условие перехода от эксперимента к эксплуатации.

• [ ] Зафиксирована точная версия модели, файл конфигурации, лицензия и способ загрузки весов.
• [ ] Общее число параметров не смешано с активными параметрами и вычислительной плотностью.
• [ ] Проверен фактический формат весов: MXFP4, FP4, FP8 или другой режим, указанный в официальной документации.
• [ ] Рассчитан не только размер весов, но и запас под метаданные, рабочие буферы и фрагментацию.
• [ ] Заданы длина контекста, размер ответа, параллельность и политика динамического батча.
• [ ] Измерен KV Cache при обычной и пиковой нагрузке.
• [ ] Зафиксированы версии драйвера, контейнера, CUDA, библиотек ядер и inference engine.
• [ ] Проверена схема tensor parallelism или expert parallelism на фактической межузловой сети.
• [ ] Протестированы холодный старт, перезапуск процесса, потеря узла и повторная загрузка.
• [ ] Агентский тест включает инструменты, длинную историю, повторные вызовы и ошибки.
• [ ] Зафиксированы задержка первого токена, стабильная скорость, пик памяти и результаты восстановления.
• [ ] Определено, кто отвечает за обновление модели, исправление несовместимости и ночные сбои.
• [ ] Сформулирована причина, по которой API или временный кластер уже не подходят по цене, задержке, контролю данных или доступности.

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

Когда самостоятельное размещение нужно остановить

У самостоятельного запуска должна быть заранее определённая граница отказа. Иначе команда продолжает добавлять GPU к схеме, которая уже не соответствует бизнес-требованиям.

Отказ от текущей конфигурации нужен в трёх случаях.

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

Топология запускается, но не даёт нужной скорости. Если межузловой обмен съедает преимущество от распределения, добавление серверов может увеличить стоимость без пропорционального роста полезного потока. В таком случае нужно менять архитектуру, движок, модель или возвращаться к API, а не бесконечно расширять кластер.

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

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

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

Что нужно проверить перед самостоятельным запуском Kimi K3 и DeepSeek V4?

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

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

На практике текущая схема на базе обычного локального сервера или случайно собранного Linux-кластера часто проигрывает не только по памяти. Она требует заранее купить ускорители, самостоятельно поддерживать сложный стек, ждать загрузки больших весов и принимать на себя риск несовместимости после обновления движка. Для команд, которым нужен контрольный контур, но не требуется постоянно держать веса на собственном оборудовании, логичнее разделить архитектуру: управление агентами, доступами и сценариями оставить на Mac, а тяжёлый слой весов проверять в удалённой вычислительной среде. Такой подход не отменяет расчёты, зато позволяет сначала провести реальный тест и только затем решать, нужен ли долгосрочный кластер. Оценивать доступные варианты можно через актуальные условия ProxyMac, а не начинать с необратимой закупки инфраструктуры.