Приёмка Kimi K3 в vLLM в 2026: CUDA и кэш

По официальному рецепту Kimi K3 для vLLM образ поставляется только как сборка CUDA 13, а хосту требуется драйвер NVIDIA ветки R580 или новее. Поэтому приёмка Kimi K3 в vLLM не может завершаться на этапе успешного старта процесса: к production допускается только среда, где подтверждены совместимость, запас памяти под реальной нагрузкой, фактический reuse prefix caching и корректная работа Agent-интерфейса.

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

Этот материал предназначен для трёх групп:

• инженеров, уже запустивших Kimi K3 на vLLM и готовящих переход из тестовой среды в production;
• SRE и руководителей платформ, которым нужно подписать go/no-go решение и принять ресурсный риск;
• технических руководителей, сравнивающих самостоятельное развёртывание, временное расширение и удалённую поставку GPU-среды.

Последнее обновление: 13 августа 2026 года. Факты сверены с официальным recipe vLLM, публикацией о поддержке Kimi K3, документацией vLLM по метрикам и матрицей совместимости NVIDIA. Статус pre-release и требования образа нужно повторно проверять при каждом изменении официального рецепта.

Четыре результата приёмки вместо бинарного «работает / не работает»

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

Для подписания результата лучше заранее использовать четыре класса:

Фиксированный тестовый набор должен быть близок к реальному Agent-трафику. В него входят системная инструкция, описание инструментов, история нескольких ходов, tool result, структурированный ответ и повторный вызов. Короткий prompt без схемы инструментов даёт слишком оптимистичную картину.

CUDA 13 и NVIDIA R580: совместимость нужно подтвердить с трёх сторон

Официальный рецепт vLLM на 13 августа 2026 года помечает Kimi K3 как pre-release. В нём указан специальный образ vllm/vllm-openai:kimi-k3, сборка CUDA 13 и требование к хосту — NVIDIA R580+. Там же отдельно отмечено, что стандартного тега под CUDA 12.9 для этого сценария нет. Подробности следует сверять в официальном рецепте Kimi K3.

NVIDIA в руководстве по совместимости CUDA указывает для CUDA 13.x минимальную ветку драйвера 580. Это не означает, что любая комбинация будет одинаково пригодна для production: конкретный образ может требовать дополнительные возможности драйвера, runtime и соответствующие версии библиотек.

Проверка должна идти по трём источникам:

Минимальная процедура выглядит так:

1. Сохранить digest используемого Docker-образа и команду запуска.
2. Внутри контейнера проверить версию CUDA runtime и наличие библиотек, с которыми запускается vLLM.
3. На каждом узле записать вывод nvidia-smi, модель GPU и версию драйвера.
4. Проверить, что контейнер видит все GPU, заявленные в tensor-parallel-size, expert-parallel или другом профиле.
5. Сопоставить первые строки startup log с официальным recipe.
6. Отдельно проверить NCCL, RDMA, NVLink или другой транспорт, если запуск многосерверный.
7. Сохранить результат в артефакт приёмки, а не только в терминал CI.

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

Для Kimi K3 это особенно важно: официальная публикация vLLM прямо отмечает, что текущий сценарий зависит от сложных компонентов и Docker-образы являются рабочим способом запуска на момент публикации. В официальной статье о поддержке Kimi K3 также приведены параметры запуска с --enable-prefix-caching, tool-call parser и reasoning parser.

OOM: сначала определяется стадия отказа, затем выбирается расширение

Для Kimi K3 нельзя использовать абстрактное правило вида «оставить несколько гигабайт запаса». Итог зависит от модели GPU, числа узлов, формата весов, tensor или expert parallel профиля, длины контекста, числа одновременных запросов и поведения кэша.

Официальный recipe указывает для NVIDIA-сценария минимум 8 GPU класса GB300 и отдельно отмечает, что для реального production-трафика нужен многосерверный профиль. Это архитектурный ориентир, а не универсальный SLA или гарантия конкретной пропускной способности. Он должен быть подтверждён на фактическом железе и нагрузке.

Нагрузочный тест делится на этапы:

1. Загрузка модели.
   Проверяется, проходит ли инициализация без OOM, NCCL error и нештатного fallback. Сохраняется пиковое потребление памяти во время загрузки.

2. Один длинный запрос.
   Используется фиксированный большой prompt, близкий к Agent-контексту. Сравнивается память на prefill и decode. Если отказ возникает здесь, проблема, вероятно, связана с max-model-len, форматом кэша или недостаточной ёмкостью одного профиля.

3. Конкурентные запросы.
   Постепенно увеличивается число одновременных сессий. Фиксируются running, waiting, queue time и kv_cache_usage_perc, если метрика доступна в применяемой версии.

4. Смешанный поток.
   В один профиль добавляются короткие, длинные, холодные и повторные запросы. Это показывает, вытесняют ли длинные сессии общий кэш и растёт ли очередь.

5. Продолжительная работа.
   Сервис оставляют под стабильной нагрузкой на заранее согласованный период. Важны не только отсутствие OOM, но и рост памяти, ошибки коммуникации, зависшие запросы и перезапуски.

В журнале отказа обязательны:

• временная шкала памяти GPU до и после OOM;
• длина prompt и ожидаемый объём генерации;
• число активных и ожидающих запросов;
• значение max-model-len;
• параметры параллелизма;
• список узлов и схема соединения;
• последние строки лога перед завершением процесса.

Один OOM на этапе загрузки и OOM после длительного роста KV — разные решения. В первом случае проверяется совместимость профиля и распределение весов. Во втором анализируются контекст, конкурентность, cache retention и баланс prefill/decode. Если снижение лимита конкурентности делает тест стабильным, выпуск возможен только с этим лимитом, отражённым в конфигурации и алертах.

Если же OOM повторяется при нескольких допустимых настройках, не следует бесконечно менять отдельные флаги. Это уже ресурсный вывод: выбранная топология не выдерживает заявленный workload. Тогда рассматриваются дополнительные GPU, другой тип межсоединения, разнесение prefill и decode или временный удалённый ресурс.

Prefix caching: включённый флаг не равен полезному reuse

В официальной статье vLLM для Kimi K3 команда запуска содержит --enable-prefix-caching. При этом текущая логика гибридного кэша отличается от обычной схемы для Transformer: Kimi K3 сочетает KDA-состояние и full-attention KV blocks. Поэтому проверять нужно не наличие аргумента, а повторное использование конкретного общего префикса.

Для теста создаётся пара запросов:

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

После этого добавляется третий запрос с изменённым system prompt. Он нужен как контроль: если все запросы показывают одинаковый результат, тест не подтверждает полезность кэша.

vLLM предоставляет Prometheus-метрики vllm:prefix_cache_queries и vllm:prefix_cache_hits. Их назначение описано в документации vLLM по метрикам. В зависимости от версии также следует проверить vllm:cache_config_info, где можно увидеть, включён ли prefix caching в конфигурации.

Официальная статья отдельно описывает prompt-end retention, интервальные контрольные точки и selective retention. В частности, для KDA-состояния нельзя сохранять снимок на каждой позиции: это слишком затратно по памяти. Поэтому длинный общий контекст может не дать полного совпадения на каждом запросе, даже если prefix caching включён корректно.

Результаты сохраняются отдельно для холодных и горячих запросов. Нельзя объявлять cache неработающим после одной пары запросов: первый повтор может только создать условия для selective retention. Нельзя и объявлять функцию рабочей по одному росту hits: нужно связать счётчики с одинаковым префиксом, длиной prompt и изменением latency.

Agent-интерфейс: корректный текст не заменяет корректный tool call

У Kimi K3 есть отдельная зона риска — формат вызова инструментов. Официальный рецепт предупреждает, что модель иногда может сформировать tool-call формат, который не ожидает её parser; в качестве меры предлагаются schema validation и retry.

Проверка должна включать минимум пять шагов:

1. Отправить system prompt с настоящим описанием инструментов.
2. Проверить JSON Schema до передачи запроса модели.
3. Выполнить многоходовой диалог: user → assistant tool call → tool result → assistant.
4. Сравнить отдельные поля content, reasoning output и tool_calls.
5. Повторить тест с ошибочным или неполным результатом инструмента.

Слой ошибки фиксируется отдельно:

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

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

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

Сводная чек-лист-приёмка Kimi K3 vLLM

Этот список удобно прикрепить к change request. Каждый пункт закрывается ссылкой на лог, график или набор запросов.

• [ ] Зафиксирован статус официального recipe и дата его последней проверки.
• [ ] Сохранены digest Docker-образа и полная команда запуска.
• [ ] Подтверждена сборка CUDA 13 внутри фактического контейнера.
• [ ] На каждом узле зафиксирован NVIDIA R580 или более новый драйвер.
• [ ] Проверено, что runtime видит все заявленные GPU.
• [ ] Startup log не содержит fallback, ошибок NCCL или нештатной замены backend.
• [ ] Отдельно проверена межузловая коммуникация для выбранной топологии.
• [ ] Выполнен тест загрузки модели с сохранением пикового использования памяти.
• [ ] Выполнен тест длинного контекста с зафиксированными параметрами.
• [ ] Выполнен тест конкурентных запросов с графиком очереди и cache usage.
• [ ] Продолжительный тест не вызвал воспроизводимый OOM или перезапуск процесса.
• [ ] Для OOM сохранены параметры запроса и график памяти до отказа.
• [ ] Prefix caching включён в фактической конфигурации, а не только в command line.
• [ ] Выполнены холодный, горячий и контрольный запросы.
• [ ] Сопоставлены prefix_cache_queries, prefix_cache_hits и задержка prefill.
• [ ] Проверены tool calls, reasoning output и structured output.
• [ ] Сценарий schema failure завершается безопасным retry или отказом.
• [ ] Для каждого риска назначен владелец и срок повторной проверки.
• [ ] Подписано одно из решений: выпуск, наблюдение, rebuild или расширение ресурсов.

Как выбрать между rebuild, ограничением и расширением

Если не проходит совместимость CUDA 13 и NVIDIA R580, расширение GPU не исправит проблему. Сначала переделывается образ или узел. Если проходит только локальный smoke test, но при длинном prompt растёт память, ограничивается контекст и повторяется нагрузка. Если после ограничения SLA становится неприемлемым, нужна новая топология.

Сценарий с несколькими узлами требует учитывать сетевые задержки и пропускную способность. Для Kimi K3 официальные рекомендации различают RDMA и NVLink-профили, а также указывают отдельные backend-настройки для коммуникации. Их следует брать из актуального recipe vLLM, а не переносить из старой конфигурации другой модели.

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

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

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

• running и waiting requests;
• queue time, time to first token и end-to-end latency;
• prompt и generation tokens;
• использование KV-кэша;
• prefix cache queries и hits;
• частота retry для tool calls;
• OOM, рестарты и ошибки NCCL;
• распределение нагрузки по узлам и GPU.

Условия rollback формулируются заранее. Примеры: повторный OOM на согласованном production-профиле, потеря schema validation, рост очереди выше установленного SLO, массовое падение cache hit ratio после изменения system prompt или ошибки межузловой передачи состояния.

Частые вопросы перед подписанием результата

Kimi K3 vLLM запускается без ошибки — что проверять дальше?
Проверяются не только HTTP 200 и наличие процесса. Нужны версии образа и драйвера, тест длинного контекста, конкурентная нагрузка, график памяти, cache metrics и полноценный Agent-сценарий. Приёмка считается завершённой только тогда, когда каждый риск связан с доказательством и конкретным действием при отклонении.

Как понять, что CUDA 13 и драйвер действительно совместимы?
Сверяются три слоя: CUDA внутри образа, NVIDIA R580+ на хосте и фактический startup log. Затем проверяется доступ всех GPU и выбранный communication backend. Строка nvidia-smi полезна, но недостаточна: она не показывает весь набор библиотек и зависимостей, с которыми работает vLLM внутри контейнера.

Как проверить prefix caching на реальном Agent-трафике?
Нужно повторить запрос с неизменным system prompt, tool schema и общей историей, сохранив холодный и горячий результаты. Затем сравнить prefix_cache_queries, prefix_cache_hits, cached prompt tokens и prefill latency. Контрольный запрос с изменённым префиксом нужен, чтобы исключить ошибочное толкование случайного совпадения.

Допустим ли выпуск после OOM во время теста?
Только если OOM был устранён изменением явно определённого лимита, а повторный тест с production-профилем стабилен. Такой выпуск получает ограничение по контексту или конкурентности и отдельный алерт. Воспроизводимый OOM без понятной границы означает, что ресурсный профиль ещё не принят.

Когда Kimi K3 нужно переустановить, а когда расширять кластер?
Несовместимую версию образа, CUDA или драйвера исправляют rebuild-ом. Расширение применяется после подтверждения, что совместимая среда упирается в память, очередь или сеть при нужной нагрузке. Если добавление GPU не меняет узкое место, следует пересмотреть topology, а не просто увеличивать число устройств.

Текущая схема на неподходящем узле или в старом CUDA-окружении обычно проигрывает не из-за одной ошибки запуска. Она даёт скрытый fallback, непредсказуемое потребление памяти и сложный rollback. Самостоятельное расширение также может занять больше времени, чем планировалось, особенно когда нужно повторно проверять драйверы, контейнерный runtime и межузловую сеть.

Если после заполнения чек-листа требуется временная вычислительная среда для повторной приёмки, разумно сопоставить текущие версии драйвера, Docker-информацию, образ, Agent-нагрузку и графики OOM с доступным профилем ProxyMac. Это помогает отделить задачу rebuild от реальной потребности в расширении и не обещает фиксированную производительность или цену до проверки конкретной конфигурации.

FAQ