Воспроизведение ошибок Kimi K3 в vLLM

Последнее обновление: 9 августа 2026 года. Мы повторно сверили материал с официальным рецептом vLLM для Kimi K3, публикацией о поддержке Kimi K3, документацией по воспроизводимости и актуальными параметрами кэширования.

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

Эта методика предназначена для инженеров инфраструктуры, которые уже несколько раз меняли среду Kimi K3, но каждый запуск заканчивался новым сообщением об ошибке. Она также полезна платформенным командам, которым нужно отделить OOM, CUDA, prefix caching и сетевые сбои, а техническим руководителям — решить, оправдано ли дальше занимать общий кластер.

Первый час: заморозьте неуспешный запуск

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

Одновременное изменение нескольких переменных создаёт минимум четыре скрытые проблемы:

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

Цель минимального воспроизведения — не немедленно поднять рабочий сервис. Сначала нужно добиться стабильного попадания в один и тот же этап: например, «ошибка при обнаружении устройства», «сбой после загрузки весов» или «OOM после первого запроса». Только после этого имеет смысл исправлять причину.

Зафиксируйте в одном файле:

• полный тег контейнера или digest образа;
• вывод nvidia-smi;
• фактически видимые GPU и значение CUDA_VISIBLE_DEVICES;
• версию vLLM и путь к модели;
• все переменные окружения;
• полную команду запуска без сокращений;
• первый стек исключения, а не только последнюю строку;
• неизменный запрос и параметры генерации;
• время запуска и последовательность изменений.

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

Базовая совместимость должна быть проверена до параметров инференса

На 9 августа 2026 года официальный рецепт vLLM указывает для Kimi K3 специализированный Docker-образ vllm/vllm-openai:kimi-k3. В рецепте отдельно сказано, что этот образ собран только под CUDA 13, то есть cu130; тега cu129 для него нет. Для хост-системы требуется драйвер NVIDIA ветки r580 или новее. Там же указана конфигурация как минимум с 8 GPU GB300 для CUDA-варианта. Эти ограничения относятся к текущей официальной инструкции и могут измениться после выпуска новой совместимой сборки. (recipes.vllm.ai)

Практический вывод простой: если на хосте установлен драйвер r575, не следует сначала менять max-model-len, число последовательностей или размер KV-кэша. Сначала нужно устранить несовместимость драйвера и контейнерного CUDA-стека. Иначе последующие ошибки памяти будут диагностироваться на заведомо нестабильной базе.

Проверяйте три уровня отдельно.

Хост. Снимите версию драйвера, список GPU, состояние устройств и наличие процессов, удерживающих память. Команда nvidia-smi показывает состояние хоста, но сама по себе не доказывает, какие библиотеки увидел процесс внутри контейнера.

Контейнер. Проверьте, что используется именно ожидаемый образ, а не локальный тег с тем же коротким именем. Сохраните digest, список CUDA-библиотек и вывод python -c "import torch; print(torch.version.cuda)", если этот импорт предусмотрен конкретной сборкой.

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

Официальная страница рецепта также указывает требование vLLM 0.27.0 или новее и предупреждает, что текущие Kimi K3-образы завязаны на отдельные зависимости. Эти сведения нужно воспринимать как границу проверки, а не как приглашение смешивать nightly-сборки с готовым образом. (recipes.vllm.ai)

Минимальная команда отделяет запуск двигателя от бизнес-обвязки

После фиксации среды уберите всё, что не нужно для проверки самого движка:

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

Официальная быстрая команда vLLM для Kimi K3 содержит tensor parallel size 8, доверенный удалённый код, fastsafetensors, включение prefix caching и параметры разбора tool calls. Для минимального воспроизведения мы не обязаны возвращать все эти функции сразу. Сначала оставляем только параметры, без которых конкретная сборка не может загрузить модель. Полную команду из официального материала следует использовать как контрольный ориентир, а не как единственную диагностическую конфигурацию. (vllm.ai)

Пример рабочего шаблона для журнала:

docker run --rm --gpus all \
  --ipc=host \
  --shm-size=16g \
  vllm/vllm-openai:kimi-k3 \
  vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --trust-remote-code \
  --load-format fastsafetensors

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

Фиксируйте первый сбой по временной шкале:

1. контейнер стартовал или нет;
2. GPU стали видимыми или нет;
3. CUDA инициализировалась или нет;
4. NCCL и межпроцессное взаимодействие прошли или нет;
5. веса начали загружаться или нет;
6. движок завершил инициализацию или нет;
7. HTTP-интерфейс стал готов или нет.

Если ошибка появляется на втором или третьем этапе, нельзя переходить к обсуждению OOM и cache hit. Если процесс стабильно доходит до загрузки весов, но падает позднее, только тогда имеет смысл проверять распределение памяти и параметры параллелизма.

Одиночный запрос создаёт вторую контрольную точку

Успешный запуск процесса ещё не означает, что Kimi K3 стабилен. После появления готового API отправьте один и тот же запрос с одинаковыми параметрами:

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

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

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

Здесь важно разделять три типа результата:

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

vLLM не обещает полную воспроизводимость онлайн-сервера, поскольку сетевое расписание и порядок поступления запросов могут меняться. Даже при специальных настройках документация ограничивает воспроизводимость одинаковой аппаратной средой и одинаковой версией vLLM. Поэтому мы фиксируем не только ответ модели, но и класс ошибки, этап появления и ключевые строки журнала. (docs.vllm.ai)

Функции добавляются по одной, с обязательным возвратом

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

Рекомендуемый порядок такой:

1. добавить prefix caching;
2. повторить тот же запрос;
3. отправить второй запрос с идентичным префиксом;
4. проверить признаки повторного использования;
5. увеличить контекст;
6. добавить ограниченную конкуренцию;
7. вернуть многоузловой режим;
8. включить дополнительные backend- и агентные функции.

Для Kimi K3 prefix caching нельзя считать доказанным только потому, что команда принялась без ошибки. Нужно проверить именно повторное использование общего префикса. Используйте два запроса, в которых системная часть и начало пользовательского ввода полностью совпадают, а хвост меняется. Если меняется и порядок сообщений, и длина контекста, и число запросов, результат не будет диагностически чистым.

Официальный материал vLLM для Kimi K3 показывает явный флаг --enable-prefix-caching, а документация по автоматическому prefix caching описывает повторное использование уже обработанного общего префикса. Поэтому для минимального запуска эту функцию лучше добавлять после проверки базового запроса, а не смешивать её с первым тестом CUDA или загрузки весов. (vllm.ai)

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

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

• [ ] Образ сохранён по полному тегу или digest, а не только по короткому имени.
• [ ] Драйвер хоста проверен фактическим выводом nvidia-smi.
• [ ] Сохранены список GPU и значение CUDA_VISIBLE_DEVICES.
• [ ] Версии vLLM, CUDA-библиотек и PyTorch записаны из реально используемого контейнера.
• [ ] Полная команда запуска помещена в файл без ручных изменений между попытками.
• [ ] Первый стек ошибки отделён от финальной строки об аварийном завершении.
• [ ] Один фиксированный запрос сохранён вместе с параметрами генерации.
• [ ] Стабильно определён этап сбоя: устройство, CUDA, NCCL, веса, движок, API или запрос.
• [ ] Каждая последующая правка меняет только одну переменную.
• [ ] Для каждой правки сохранены результат и команда отката.
• [ ] Prefix caching проверяется отдельным повторным запросом, а не косвенным ощущением ускорения.
• [ ] Описано, почему результат считается стабильным или почему онлайн-воспроизводимость ограничена.

Оценка результата определяет следующий расход ресурсов

Мы используем простую оценку по пяти признакам:

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

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

Когда общий кластер пора заменить изолированным узлом

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

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

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

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

Частые вопросы

Какие параметры фиксировать при разных ошибках на каждом запуске?

Нужно зафиксировать не только команду, но и фактически загруженную среду: digest образа, драйвер, видимые GPU, CUDA-пути, переменные окружения, версию vLLM и идентичный запрос. Отдельно записывайте первый стек и порядок изменений. Если одновременно сменить контейнер, драйвер и параметры памяти, последующий результат нельзя корректно связать с одной причиной.

Как отличить настоящий OOM от последствия CUDA-сбоя?

Смотрите на временной порядок. Ошибка при обнаружении устройств, инициализации CUDA, NCCL или загрузке ядра появилась раньше сообщения о памяти — значит, OOM может быть вторичным симптомом. Повторите минимальный запуск без длинного контекста, конкуренции и кэширования. Только после стабильной инициализации движка следует анализировать память как самостоятельную причину.

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

Проверяйте чистый процесс и чистый узел, а не только список установленных пакетов. Сохраните nvidia-smi, идентификатор контейнера, CUDA-пути и логи инициализации. Перезапуск узла помогает исключить старые процессы, а запуск по digest — локальный контейнерный тег. Различие между фактическим драйвером хоста и библиотеками процесса нужно зафиксировать отдельно.

Добавлять ли prefix caching в самый первый запуск?

Для проверки CUDA, видимости GPU и загрузки весов — нет. Сначала добейтесь стабильного одиночного запроса. Затем добавьте --enable-prefix-caching, оставьте остальные параметры прежними и отправьте два запроса с одинаковым началом. Так можно отделить проблему запуска движка от поведения гибридного KV-кэша Kimi K3.

Когда переходить из исходного кластера в тестовую среду?

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

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

FAQ