Приёмка Kimi K3 и Qwen3.8 для запуска

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

Эта инструкция предназначена для трёх групп:

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

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

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

Для Kimi K3 это особенно важно: в опубликованных материалах модель описывается как MoE-система с общим объёмом около 2,8 триллиона параметров, 896 экспертами и выбором 16 экспертов для токена; также заявлен контекст до 1 000 000 токенов. Эти величины нельзя превращать в готовую спецификацию сервера: активные параметры, формат весов, KV Cache и служебная память создают разные профили нагрузки. Обзор архитектуры Kimi K3 и квантования MXFP4

Перед закупкой мы разделяем требования на жёсткие и оптимизируемые.

Скрытые расходы обычно появляются не в строке «объём памяти», а в других местах:

1. Запас памяти. Свободная память после загрузки весов нужна для KV Cache, временных буферов, коммуникаций между устройствами и неожиданных пиков. Сервер, который работает только при одном коротком запросе, не является безопасно рассчитанным сервером.
2. Совместимость. Ошибка формата квантования или неподдерживаемого ядра может выглядеть как нехватка памяти. Поэтому сначала фиксируются версии загрузчика, драйвера, сервера инференса и формата весов.
3. Данные и права. Для внутренней базы знаний или AI Agent важно заранее определить, где сохраняются журналы запросов, кто имеет доступ к промптам и допускается ли отправка содержимого во внешний API.
4. Простой. Даже если оборудование куплено, обновление модели, перезапуск процесса и восстановление после сбоя требуют времени инженеров.
5. Непостоянная загрузка. При редких обращениях дорогостоящий узел может простаивать большую часть дня, тогда как API или временная аренда лучше соответствуют переменному спросу.

Предварительная проверка весов, разрешений и цепочки запуска

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

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

Подготовка должна идти в таком порядке:

1. Сохраните точное имя модели, ссылку на официальный репозиторий и дату проверки.
2. Сверьте наличие всех обязательных файлов, конфигурации, токенизатора и инструкции запуска.
3. Проверьте контрольные суммы или иной механизм целостности, если он опубликован.
4. Отделите официальный формат от конвертированных сообществом файлов. Производная квантованная сборка требует описания метода, исходной версии и параметров конвертации.
5. Зафиксируйте версии операционной системы, драйвера, библиотек, загрузчика и сервера инференса.
6. Проверьте, поддерживает ли целевая среда выбранный формат квантования, распределение по устройствам и нужный режим параллелизма.
7. Запустите тестовый сценарий без производственных данных.

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

Для предварительной оценки памяти используйте формулу, но не принимайте по ней решение о покупке:

память для запуска ≈ память весов + KV Cache + рабочая память + резерв.

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

Первый час: проверка полного цикла инференса

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

Шаг 1. Загрузите веса с чистого окружения

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

Шаг 2. Выполните одиночный запрос

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

Шаг 3. Проверьте структурированный ответ

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

Шаг 4. Проверьте вызов инструмента

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

Шаг 5. Перезапустите сервис

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

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

Настоящая нагрузка начинается в первый день

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

Соберите тестовый набор из собственных данных:

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

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

Минимальная запись теста должна содержать:

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

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

Первая неделя показывает настоящую стоимость владения

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

План первой недели включает пять испытаний:

1. Непрерывная нагрузка. Оставьте сервис под типичным потоком и проверьте накопление памяти, рост очереди и деградацию после длительной работы.
2. Перезапуск процесса. Проверьте штатный и аварийный сценарии, включая повторную загрузку модели.
3. Потеря узла или среды. Зафиксируйте, что происходит при недоступности вычислительного узла, и сколько шагов требуется для возврата сервиса.
4. Откат версии. Верните предыдущую рабочую сборку и проверьте совместимость кэша, шаблонов запросов и формата журналов.
5. Воспроизведение окружения. Соберите окружение заново из описанной конфигурации, а не из личной рабочей директории инженера.

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

Проверьте также четыре операционных слоя:

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

Для отдельного AI Agent это особенно важно: ошибка модели может проявиться не падением сервера, а некорректным вызовом функции, повторным выполнением операции или потерей результата предыдущего шага. Поэтому журналы должны позволять связать запрос, ответ, вызов инструмента и итоговое действие. Для сценариев с Kimi K3 полезно заранее изучить разбор воспроизводимых ошибок в серверном окружении на странице JexMac о диагностике Kimi K3.

Критерии решения: продолжать, работать в двух режимах или остановиться

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

• [ ] Официальный источник весов, модельная документация и лицензия сохранены в карточке проверки.
• [ ] Для Qwen3.8 подтверждён фактический статус весов именно на дату проверки, а не по публикации сообщества.
• [ ] Выбранный формат квантования имеет описание происхождения и совместим с целевым сервером.
• [ ] Пиковая память измерена на реальном контексте и включает KV Cache, рабочее пространство и резерв.
• [ ] Структурированный вывод проходит схему без ручного исправления.
• [ ] Вызов инструмента и возврат результата проверены на рабочем сценарии AI Agent.
• [ ] Измерены задержка первого токена, скорость вывода, хвостовая задержка, очередь, ошибки и эффективная производительность.
• [ ] Нагрузка проверена при целевой параллельности, а не только на одном запросе.
• [ ] Перезапуск, откат и восстановление выполнены другим инженером по инструкции.
• [ ] В течение первой недели учтены простои, ручные вмешательства и неуспешные запросы.
• [ ] Назначены ответственный, ссылка на доказательство, дата повторной проверки и условие пересмотра.

Оценивать результат удобно по пяти воротам. Каждому присваивается статус «пройдено», «условно пройдено» или «провалено».

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

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

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

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

На практике текущая схема — локальный сервер или постоянная облачная машина — часто проигрывает не из-за самой модели, а из-за трёх ограничений: оборудование простаивает между пакетами запросов, масштабирование требует нового закупочного цикла, а восстановление и обновление остаются обязанностью внутренней команды. Поэтому перед долгосрочной покупкой разумнее арендовать у JexMac изолированную среду на срок, достаточный для первого дня и первой недели проверки, передав модель, серверный движок, целевую параллельность и сценарии AI Agent. Такой формат не отменяет самостоятельную закупку, если нагрузка постоянная и есть собственная эксплуатационная команда, но позволяет не превращать неподтверждённый запуск Kimi K3 или Qwen3.8 в необратимое аппаратное решение.

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