Версия Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Путь декодирования Kimi K3 в vLLM достиг 842 токенов в секунду в конкретном тесте на GB300

> vLLM сообщает о совокупной скорости декодирования Kimi K3 в 842 против 488 токенов в секунду на 16 GPU GB300 при определённой конфигурации DSpark. Предзаполнение не учитывается.

By BIG CHANGE Editorial

Published: 2026-10-18T20:03:34.885Z
Updated: 2026-10-18T20:03:34.885Z
Canonical: https://bigchange.ai/blog/kimi-k3-vllm-gpu-inference-benchmark

![Conceptual charcoal illustration of the rear of a generic compute cabinet with rack units and secured cables in a data-center aisle.](https://bigchange.ai/api/media/file/kimi-k3-decode-cabinet-concept-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual GB300 chassis, vLLM installation or measured result is depicted.

vLLM включил необязательный специализированный для Kimi K3 путь декодирования на GPU NVIDIA Blackwell. В своём [описании от 16 октября](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) проект сообщает о генерации 842 токенов в секунду против 488 у стандартного vLLM, то есть о приросте в 1.73×. Сравнение ограничено конкретными условиями: один запрос за раз, тензорный параллелизм на 16 GPU GB300, спекулятивное декодирование DSpark с семью черновыми токенами, синтетическая длина принятия шесть, вход из одного токена и выход из 1000 токенов. Показатель измеряет совокупную пропускную способность декодирования после предзаполнения. Он не измеряет, насколько быстро завершается весь пользовательский запрос.

Для инженеров, решающих, стоит ли оценивать этот путь, полезное изменение заключается в сочетании существенного результата декодирования с довольно ясным описанием области применения. [Включённая реализация](https://github.com/vllm-project/vllm/pull/61867) активируется явно через `decode_backend: latency_specialized`; настройка по умолчанию `auto` по-прежнему использует стандартное декодирование. По словам vLLM, специализированный путь рассчитан на развёртывания GB300 с восемью или 16 GPU в одном домене NVLink, тогда как предзаполнение, смешанные пакеты и неподдерживаемые шаги возвращаются к стандартному прямому проходу модели.

## На что уходило время

Kimi K3 — крупная модель смеси экспертов, согласно её [карточке модели](https://huggingface.co/moonshotai/Kimi-K3). При декодировании система инференса многократно выполняет внимание, выбирает экспертов и обменивается данными между GPU для генерации следующих токенов. Команда vLLM создала путь на CuTe DSL, специализирующий эти операции под ожидаемые формы тензоров. В описании приведены разные ядра проекции внимания для малых и более крупных пакетов; объединение выходной проекции внимания, редукции между GPU и последующих остаточных операций; разделённые вычисления маршрутизатора; перекрытие работы общих и маршрутизируемых экспертов; а также предварительная выборка весов во время обмена данными. В показанной в публикации послойной трассировке специализированный путь использует 13 ядер и 69 микросекунд, а стандартный vLLM — 23 ядра и 130 микросекунд. Это опубликованная трассировка для показанной конфигурации, а не показатель задержки приложения.

Область применения важна не меньше устройства ядер. [Pull request](https://github.com/vllm-project/vllm/pull/61867) описывает проверку на GB300 при TP8 и TP16, неспекулятивное декодирование вплоть до пакета 64, верификацию DSpark с тремя–семью черновыми токенами и необязательный контекстный параллелизм декодирования. Указано, что для оптимизации производительности использовались кеш KV FP8, кеш SSM FP32 и веса поставщика модели. Этот путь не меняет веса модели, планирование, семплирование и генератор черновиков DSpark. Это позволяет команде инференса сравнивать изменённую реализацию декодирования при знакомом остальном стеке, но также означает, что оптимизация ускоряет не все части обслуживания.

## Читайте две таблицы бенчмарков отдельно

Результат 842 против 488 получен с использованием **TP16 на 16 GPU GB300, пакета 1, DSpark с семью черновыми токенами, синтетической длины принятия шесть, DL=7, ISL=1 и OSL=1k**. vLLM называет метрику совокупным числом токенов декодирования в секунду и исключает предзаполнение. Синтетическое принятие фиксирует, сколько предложенных токенов примет бенчмарк; это не доля принятия, измеренная на пользовательских промптах. Развёртыванию с другими промптами, поведением принятия, размерами пакетов или длинами входа нужны собственные измерения.

В публикации также есть [таблица без спекулятивного декодирования](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#decode-performance-without-speculation). Например, при TP16 сообщается о 256.4 токена в секунду при пакете 1 и 3606.1 при пакете 64, с приростом в 1.88× и 1.62× относительно соответствующих стандартных конфигураций. Это совокупные результаты TP-группы без спекулятивного декодирования. Их нельзя объединять с числом DSpark, чтобы утверждать, что при пакете 64 отдельный пользователь получает более быстрый сервис.

Другое число в публикации относится к [AgentX](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel#improvement-on-agentx) — нагрузке, воспроизводящей шаблоны трафика программирующих агентов с синтетическим содержимым. vLLM сообщает об интерактивности P90 в 403.2 против 223.7 токена в секунду на пользователя при одновременности один. Оптимизированный результат получен на **16 GPU GB300**, тогда как предыдущее сравнение выполнялось на **восьми**. Поскольку вместе с реализацией меняется число GPU, это сравнение в 1.8× не выделяет отдельно улучшение пути декодирования. AgentX также включает более длинные контексты, ходы диалога, паузы и повторное использование кеша, поэтому его метрика отвечает на другой вопрос, чем чистый бенчмарк декодирования.

Между публичной публикацией и более ранней [таблицей производительности pull request](https://github.com/vllm-project/vllm/pull/61867) есть небольшое расхождение: в последней указаны 838 против 489 токенов в секунду для TP16, пакета 1, DSpark DL7 и синтетического принятия шесть. Источник приведённого здесь значения 1.73× — сравнение 842 против 488 в публикации. Более ранняя таблица служит полезным свидетельством похожего запуска, но смешивать две пары нельзя. vLLM опубликовал код и собственную валидацию; BIG CHANGE не воспроизводил ни один из запусков.

## Что потребуется для оценки

Содержательное локальное сравнение началось бы с [включённого PR и заявленной в нём конфигурации](https://github.com/vllm-project/vllm/pull/61867): те же веса Kimi K3 от поставщика модели, система GB300 с 16 GPU в одном домене NVLink, TP16, форматы кеша и точная конфигурация DSpark для основного теста. Запустите стандартный режим `auto` и явно включаемый `latency_specialized` на одной нагрузке, затем запишите пропускную способность декодирования отдельно от предзаполнения, времени до первого токена, выходной пропускной способности и задержки на уровне запроса. Рабочая станция или меньший пул GPU не может напрямую воспроизвести основной результат на 16 GB300. Публикация не устанавливает стоимость аренды такой конфигурации.

В [описании валидации PR](https://github.com/vllm-project/vllm/pull/61867) сообщается о численных проверках и оценках модели, включая AIME25, GPQA-Diamond и тест MRCR с длинным контекстом. Там также описаны обнаруженная при разработке ошибка синхронизации и вариативность тестов с длинным выходом. Эти проверки дают читателю больше материала для изучения, чем график скорости, но остаются свидетельствами самих разработчиков реализации. Команде инференса предстоит решить, достаточно ли её реальные оборудование, пакетирование, длины контекста и спекулятивное принятие близки к поддерживаемым конфигурациям, чтобы оправдать измерение этого необязательного пути на собственном трафике.

## Главное изменение

Включённый в vLLM путь Kimi K3 предоставляет специализированную необязательную GPU-реализацию декодирования с документированным бенчмарком и историей валидации. Наиболее заметный публичный результат — **842 против 488 совокупных токенов декодирования в секунду, или 1.73×, при TP16 на 16 GPU GB300, пакете 1, семи черновых токенах DSpark и синтетической длине принятия шесть**. Предзаполнение исключено. Улучшится ли конкретный сервис, зависит от его оборудования и полной нагрузки пользовательских запросов.

## Источники и дополнительное чтение

- [Техническая публикация vLLM от 16 октября](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) объясняет изменения декодирования и содержит конфигурацию 842/488, таблицу без спекулятивного декодирования и сравнение AgentX. Результаты сообщены проектом и участником разработки от NVIDIA Benjamin Chislett.
- [Включённый pull request vLLM #61867](https://github.com/vllm-project/vllm/pull/61867) документирует необязательную настройку, поддерживаемые конфигурации, границы реализации, валидацию и более раннюю таблицу DSpark с 838/489. Это история кода и результатов, а не независимое воспроизведение.
- [Карточка модели Kimi K3 от Moonshot AI](https://huggingface.co/moonshotai/Kimi-K3) указывает модель и веса, на которые ссылается реализация.
- [Методология AgentX](https://inferencex.semianalysis.com/agentx) описывает нагрузку воспроизведения трафика, лежащую в основе отдельного сравнения интерактивности.

## Sources

- [vLLM, Глубокая оптимизация Kimi K3 в vLLM: быстрое и ответственное продвижение (2026-10-16)](https://vllm.ai/blog/2026-10-16-kimi-k3-megakernel) — Техническое описание из первых рук и источник результата 842/488, 1.73×. Указаны TP16 на 16 GPU GB300, пакет 1, DSpark DL7, синтетический AL6, ISL1, OSL1k и совокупные TPS декодирования без предзаполнения. Также приведены отдельные неспекулятивные результаты и результаты AgentX.
- [Pull request vLLM #61867, специализированное декодирование Kimi K3](https://github.com/vllm-project/vllm/pull/61867) — Включённая реализация и запись проверок, выполненных авторами. Документирует окончательную необязательную настройку, поддерживаемые конфигурации и возврат к стандартному пути. В более ранней таблице DSpark указаны 838/489 при TP16 B1 и синтетическом AL6, поэтому эти числа не объединяются с парой из блога.
- [Moonshot AI, карточка модели Kimi K3](https://huggingface.co/moonshotai/Kimi-K3) — Указывает модель и веса её поставщика; не устанавливает производительность vLLM независимо.
- [InferenceX, Методология и наборы данных AgentX](https://inferencex.semianalysis.com/agentx) — Описывает нагрузку воспроизведения трафика, использованную в отдельно опубликованном сравнении интерактивности. В сравнении vLLM также меняется число GPU.