Kimi K3 и Qwen3.8: память для своего сервера

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

Самое быстрое решение: не покупать оборудование по формуле «параметры × разрядность». Для Kimi K3 и любого другого крупного MoE-моделя сначала считают веса, KV Cache, служебную память, межузловой обмен и резерв отказоустойчивости. При стабильной высокой загрузке и строгих требованиях к данным подходит самостоятельный запуск; на этапе проверки и при неровном трафике безопаснее двойной контур из API и краткосрочной аренды вычислительных ресурсов.

Эта статья рассчитана на три группы:

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

Сначала проверяется не память, а возможность запуска

У крупной открытой модели есть несколько независимых критериев готовности:

1. опубликованы ли полные веса, а не только демонстрационный API;
2. понятна ли лицензия для коммерческого и внутреннего использования;
3. доступен ли нужный формат квантования;
4. поддерживает ли формат стабильная версия inference-фреймворка;
5. можно ли загрузить все необходимые компоненты без ручных исправлений;
6. подтверждена ли работа с нужной длиной контекста и инструментальными вызовами.

У Kimi K3 официальная карточка указывает архитектуру MoE, 2,8 трлн общих параметров, 104 млрд активных параметров, 93 слоя, 896 экспертов, 16 выбранных экспертов на токен, контекст до 1 048 576 токенов и веса MXFP4 при активациях MXFP8. В качестве рекомендуемых движков названы vLLM, SGLang и TokenSpeed. Это уже позволяет строить предварительную модель ресурсов, но не заменяет нагрузочный тест. Официальная карточка Kimi K3

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

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

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

Kimi K3 и Qwen3.8: как считать память

Общий параметр MoE показывает размер всего набора весов. Активный параметр показывает, какая часть вычислительного графа участвует в обработке конкретного токена. Эти величины нельзя подменять друг другом.

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

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

Память модели =
  память весов
+ метаданные квантования
+ неquantизированные слои
+ runtime-буферы
+ KV Cache
+ коммуникационные буферы
+ запас на фрагментацию
+ резерв отказоустойчивости

Для весов используется более точная запись:

Память весов =
  число параметров × фактическое число байт на параметр
+ scales
+ zero-points
+ упаковка блоков
+ служебные индексы

Для грубой оценки MXFP4 можно взять 0,5 байта на параметр, но это только нижняя арифметическая граница до учёта масштабов и исключённых слоёв. У Kimi K3 официально заявлено 2,8 трлн параметров и MXFP4-веса. Арифметическая оценка составляет около 1,4 ТБ только для идеализированного массива весов: 2,8 × 10¹² × 0,5 байта. Реальный файл и фактический расход загрузчика могут быть больше из-за упаковки, масштабов, неquantизированных компонентов, мультимодального блока и служебных буферов.

Отсюда ответ на вопрос о минимальной памяти для Kimi K3 после квантования: одного числа в гигабайтах не существует. Для исследовательской загрузки требуется вместить полный набор весов с запасом. Для сервиса добавляются кэш, параллельные запросы, межузловая связь и резерв. Любой ответ вроде «активно только 104 млрд, значит достаточно памяти для 104 млрд параметров» будет некорректным.

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

P_total = официальное общее число параметров
b_weight = фактический формат весов
P_active = активные параметры на токен
L = число слоёв
H = размер скрытого состояния
B_kv = байт на элемент KV Cache
T = длина контекста
S = число одновременно обслуживаемых последовательностей

Оценка KV Cache для обычной архитектуры записывается так:

KV Cache =
  L × T × S × число KV-голов × размер головы
  × 2 × B_kv

Число 2 появляется потому, что кэшируются ключи и значения. Для GQA, MLA или гибридной линейной attention-архитектуры формула изменяется. Поэтому нельзя переносить оценку KV Cache от одной модели к другой только по общему числу параметров.

Современные движки поддерживают отдельное квантование KV Cache, включая FP8-варианты. Это может увеличить вместимость кэша, но меняет требования к версии движка, backend-реализации и качеству на конкретной модели. Документация vLLM по квантованию KV Cache

Память, контекст и параллельность

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

Минимальная проверка должна включать три режима:

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

В каждом режиме фиксируются:

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

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

Практически это означает следующее:

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

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

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

Сравнение вариантов до закупки

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

Вариант	Что считается	Когда подходит	Главный риск
Самостоятельный запуск	Веса, KV Cache, узлы, сеть, хранение, мониторинг, резерв	Стабильная загрузка и строгий контроль данных	Простой и длительный цикл обновления
Краткосрочная аренда	Фактические часы или дни, передача данных, настройка, хранение	Проверка загрузки, фреймворка и Agent-сценария	Ограниченный срок и возможная разница конфигураций
API	Входные и выходные токены, кэширование, лимиты, пиковые запросы	Неровная нагрузка и быстрый запуск	Зависимость от тарифа, лимитов и внешнего контура
Двойной контур	API для пиков плюс аренда для проверки и частых задач	Переходный период и неопределённый спрос	Нужно поддерживать два маршрута и правила данных

Для API нельзя подставлять только среднее число запросов. Расчёт должен включать:

Стоимость API =
  входные токены × тариф входа
+ выходные токены × тариф выхода
+ запросы без попадания в кэш
+ резерв на пик

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

Собственная инфраструктура требует отдельной строки для расходов, которые редко попадают в презентацию:

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

Опытный ориентир: если команда не может назвать владельца обновления, срок восстановления и процедуру отката, самостоятельный запуск ещё не является эксплуатационным решением. Это пока лабораторный эксперимент.

Пошаговая проверка перед решением

1. Зафиксировать границы нагрузки

Записываются длина входа, средняя длина ответа, максимальный контекст, число параллельных пользователей, доля Agent-запросов и допустимое время до первого токена. Нельзя использовать только среднее значение: размер инфраструктуры определяет пик.

2. Проверить официальные файлы

Для каждой модели проверяются README, config, лицензия, список файлов, формат весов, токенизатор и требования trust_remote_code, если они есть. Контрольные суммы фиксируются в журнале поставки.

3. Рассчитать четыре независимых бюджета

Минимум нужны отдельные строки для весов, KV Cache, runtime и резерва. Если модель мультимодальная, vision-компоненты и проекторы записываются отдельно. Они не должны исчезать внутри округлённого числа «память модели».

4. Выбрать схему параллелизма

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

5. Провести три нагрузочных теста

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

6. Повторить тест после прогрева

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

7. Сопоставить стоимость с загрузкой

Используется фактическая месячная загрузка:

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

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

Три модели в едином реестре проверки

Поскольку проверенных публичных данных по полной конфигурации Qwen3.8 на момент подготовки недостаточно, его строка не должна содержать выведенную «минимальную видеопамять». Для DeepSeek V4 также требуется разделять API-доступ от подтверждённой доступности полных весов для самостоятельного запуска.

Модель	Что подтверждено	Что нельзя утверждать без теста	Статус решения
Kimi K3	2,8 трлн общих параметров, 104 млрд активных, MXFP4, 93 слоя, 896 экспертов, 1 048 576 токенов контекста	Точный пик памяти, стабильный throughput, требуемое число узлов	Верификация возможна
Qwen3.8	В официальном доступном репозитории отдельная полная карточка не подтверждена	Память, лицензия, формат, совместимость и производительность	Только проверочный список
DeepSeek V4	Официально опубликованы модельная страница и API-документы	Возможность самостоятельной загрузки без подтверждённых весов и тестов	Разделить API и self-hosting

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

Для Qwen3.8 следует дождаться полного набора подтверждений. Сообщения сообщества о предполагаемых размерах и сроках выхода могут объяснять интерес к модели, но не заменяют официальную документацию. До этого момента закупка оборудования «под Qwen3.8» — ставка на слухи.

Когда для DeepSeek V4 выгоднее собственный кластер, а когда API?
Собственный кластер имеет смысл при измеримой постоянной загрузке, жёстких требованиях к хранению данных и наличии команды эксплуатации. API предпочтительнее, если трафик скачет, модель ещё сравнивается с альтернативами, а стоимость простоя и сопровождения выше платы за токены. Для переходного периода рационален двойной контур: чувствительные или регулярно повторяемые задачи проверяются в изолированной среде, пики уходят в API после фильтрации данных.

Точка безубыточности и линия отказа

Решение принимается не по цене одного токена в идеальном режиме, а по четырём показателям:

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

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

1. нагрузка достаточно стабильна, чтобы сервер не простаивал большую часть расчётного периода;
2. данные нельзя или нежелательно передавать во внешний API;
3. команда умеет обслуживать распределённый inference-стек, мониторинг и аварийное восстановление.

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

Линия отказа должна быть заранее подписана:

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

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

Итоговое решение для команды

Для Kimi K3 и других крупных MoE моделей самостоятельный запуск оправдан только после расчёта полной памяти и теста реальной нагрузки. Общие параметры определяют объём размещаемых весов. Активные параметры помогают оценить вычисления. KV Cache определяет цену контекста и параллельности. Runtime, сеть и резерв превращают лабораторную загрузку в производственную спецификацию.

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

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

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