OOM Kimi K3 в vLLM: настройка или расширение?

Последнее обновление: 16 августа 2026 года. Данные проверены по официальному recipe vLLM для Kimi K3 и публикации vLLM о поддержке модели.

В официальном recipe для Kimi K3 указан путь с восемью ускорителями GB300, а для производственного трафика рекомендуется многузловая схема. Поэтому при OOM Kimi K3 в vLLM сначала определите фазу сбоя: OOM во время загрузки весов обычно нельзя исправить снижением конкурентности, а OOM после запуска сервера можно проверять через контекст, число последовательностей и prefix caching. (официальный recipe vLLM)

Эта статья нужна вам, если вы:

• проверяете Kimi K3 в личном исследовательском стенде или POC;
• разрабатываете небольшой Agent-сервис с повторяющимися системными промптами и инструментами;
• отвечаете за GPU-кластер, драйверы, контейнеры и межузловую сеть;
• принимаете производственное решение: дальше настраивать текущую среду или расширять её.

Загрузка весов против обработки запросов

OOM на этапе инициализации

Ищите ошибку до сообщения о готовности движка. Типичные признаки:

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

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

Проверьте среду по официальному пути: для Kimi K3 указан специальный образ vLLM, сборка под CUDA 13 и драйвер NVIDIA R580 или новее. Эти требования относятся к совместимости стека, а не к предполагаемой производительности.

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

OOM во время prefill или decode

Вторая категория появляется после успешной инициализации:

• сервер запускается;
• короткий запрос возвращает ответ;
• сбой появляется на длинном контексте;
• несколько Agent-сессий вызывают резкий рост памяти;
• ошибка возникает при расширении KV cache или добавлении новой последовательности.

Здесь уже допустимо исследовать:

• max-model-len;
• число одновременных последовательностей;
• размер истории диалога;
• объём описаний инструментов;
• режим prefix caching;
• распределение prefill и decode;
• экспертный или многузловой параллелизм.

Если Kimi K3 загрузился, но падает на длинном запросе, сначала снижайте нагрузку и повторяйте тот же тест. Если модель не проходит инициализацию, меняйте среду или топологию, а не очередь запросов.

Успешный запуск на пустом стенде доказывает только возможность загрузки. Он не доказывает, что сервис выдержит целевое число сессий, длинную историю Agent-цикла и восстановление после отказа.

Исследовательский стенд против POC-команды

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

Рабочая последовательность:

1. Зафиксируйте образ, версию vLLM, драйвер и список видимых GPU.
2. Сохраните команду запуска в файл, чтобы каждый прогон был воспроизводимым.
3. Начните с короткого контекста и одного запроса.
4. Затем проверьте один вызов инструмента.
5. Добавьте несколько последовательных Agent-шагов.
6. Только после этого увеличивайте длину истории или число одновременных запросов.
7. После каждого изменения записывайте фазу сбоя и пиковое потребление памяти.

Официальная команда для Kimi K3 использует параметры, связанные с tensor parallelism, загрузкой fast safetensors, удалённым кодом модели, разбором tool calling и prefix caching. Не переносите отдельный параметр в другой стек без проверки версии образа и документации: поведение флагов может зависеть от конкретной сборки. (публикация vLLM о Kimi K3)

Можно ли исправить OOM при загрузке весов Kimi K3 только настройками?
Иногда причина действительно находится в неправильном образе, несовместимом драйвере или ошибочном распределении модели. Но снижение конкурентности после запуска не освобождает память, требуемую для инициализации весов. Если модель не загружается на официальной аппаратной схеме, не перебирайте случайные флаги бесконечно. Перенесите проверку в совместимое окружение и отдельно подтвердите аппаратную ёмкость.

Для POC можно считать проверку успешной, если:

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

Такая среда подходит для функционального прототипа, но не является доказательством production-готовности.

Небольшая Agent-команда: контекст против кэша

В Agent-сервисе повторяются не только пользовательские сообщения. В запросах могут снова передаваться:

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

Из-за этого одинаковое уменьшение контекста может повлиять и на качество Agent-цикла, и на расход памяти. Отключение prefix caching способно уменьшить удерживаемый кэш, но одновременно заставит систему чаще выполнять повторный prefill.

Поддержка prefix caching для Kimi K3 подтверждена, однако по состоянию на 16 августа 2026 года он не должен считаться включённым автоматически во всех сценариях: в официальном пути его требуется включать явно. (официальный recipe Kimi K3)

После включения prefix caching память всё равно заканчивается — что проверять первым?
Не отключайте кэш без измерения. Возьмите один и тот же набор запросов и проведите три сравнения:

1. сохраните кэш и уменьшите конкурентность;
2. сохраните конкурентность и укоротите историю;
3. измените политику удержания кэшированных состояний.

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

Для каждого режима сохраняйте:

• пиковое потребление памяти;
• hit rate prefix caching;
• время до первого токена;
• полное время ответа;
• число вытесненных последовательностей;
• количество ошибок при целевой конкурентности;
• долю Agent-циклов, завершившихся успешно.

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

Платформенная команда: совместимость против самосборки

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

Перед пересборкой контейнера проверьте:

• можно ли обновить драйвер на хосте;
• разрешено ли использовать официальный образ;
• доступен ли CUDA 13 в рабочем окружении;
• поддерживает ли сеть выбранный all-to-all backend;
• есть ли RDMA или NVLink там, где это требуется;
• можно ли менять tensor, expert и pipeline parallelism;
• кто отвечает за NCCL, прошивки и откат;
• можно ли повторить тест после обновления без простоя критичного сервиса.

В официальном recipe описаны разные пути all-to-all для RDMA и NVLink. Для RDMA приведена конфигурация UCX_TLS="rc,cuda_copy". Там же описаны дополнительные меры для отдельных ошибок регистрации памяти, но их нельзя смешивать с лечением обычного OOM: исправление сетевого или драйверного сбоя не увеличивает физическую ёмкость GPU. (recipe vLLM с требованиями к топологии)

Экспертный параллелизм также требует отдельной проверки. При включении expert parallelism эксперты распределяются между группами, а механизмы балансировки могут создавать дополнительные копии и увеличивать расход памяти. Поэтому добавление EP без контрольного прогона способно ухудшить ситуацию вместо её исправления. (документация vLLM по expert parallelism)

Стоит ли самостоятельно собирать окружение, если текущий GPU-кластер не соответствует Kimi K3?
Это имеет смысл, когда вы управляете драйвером, образом, сетью и процессом сопровождения. Если вам разрешено менять только контейнер, а хост и межузловой слой закрыты, собственная сборка часто превращается в постоянную поддержку нестандартного стека. В таком случае быстрее получить контрольный запуск в совместимой среде, чем месяцами компенсировать ограничения случайными параметрами.

Порядок проверки:

1. Снимите nvidia-smi с версией драйвера и перечнем устройств.
2. Убедитесь, что контейнер использует CUDA 13.
3. Сверьте аппаратную схему с официальным recipe.
4. Запустите модель на одном узле без Agent-нагрузки.
5. Проверьте межузловую связь отдельным тестом.
6. Выполните короткий запрос через будущий API-маршрут.
7. Добавьте инструменты и только затем целевую конкурентность.

Производственная среда: запас против факта запуска

Production-решение нельзя принимать по принципу «модель запустилась». В расчёт входят:

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

Для крупных нагрузок vLLM рассматривает разделение prefill и decode. Это позволяет отдельно масштабировать узлы, занятые обработкой длинного входа и генерацией ответа. Но результат зависит от интерконнекта, передачи KV-состояния, распределения запросов и версии программного стека. Число GPU нельзя умножать линейно и выдавать за прогноз ёмкости.

Официальная страница Kimi K3 описывает несколько направлений: TP8, TEP16, TP8 с pipeline parallelism и раздельные prefill/decode-схемы. Используйте их как проверенные варианты для дальнейшего тестирования, а не как готовую формулу для любого кластера. (официальный recipe с многузловыми рекомендациями)

Опубликованные показатели производительности также относятся к конкретной топологии. Например, vLLM приводит 118 токенов в секунду без speculative decoding и 370 токенов в секунду с DSpark на 16 NVIDIA GB300 в конфигурации NVL72. Эти данные нельзя переносить на другую сеть, другой тип ускорителей, другую длину контекста или иной профиль запросов без повторного измерения. (результаты тестирования vLLM)

Пять шагов перед расширением

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

Чек-лист решения

• [ ] Фаза OOM отмечена в логах.
• [ ] Подтверждено завершение инициализации.
• [ ] Короткий запрос возвращает ответ.
• [ ] Сохранены образ, версия vLLM, драйвер и команда запуска.
• [ ] Проверены CUDA 13 и драйвер R580 или новее.
• [ ] Один и тот же набор запросов использован до и после настройки.
• [ ] Записаны пик памяти, задержка и ошибки.
• [ ] Prefix caching не отключался без сравнения hit rate.
• [ ] Проверены межузловая сеть и all-to-all backend.
• [ ] Целевая production-нагрузка описана числами и примерами запросов.
• [ ] Указано условие перехода от настройки к расширению.
• [ ] Сохранена процедура повторного теста после обновления vLLM.

Матрица выбора по типу команды

Решение по результатам повторного теста

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

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