Artificial intelligence news.
Straight from the original announcements.

vLLM Speeds Up Kimi K3 Decoding on GB300 With Agent-Written Kernels

October 16, 2026Source: vLLM
vLLM Speeds Up Kimi K3 Decoding on GB300 With Agent-Written Kernels
Image: vLLM

The vLLM team has published an optimized decode path for Kimi K3 on NVIDIA GB300 GPUs, built with help from coding agents. According to vLLM, it delivers over 840 tokens/s at batch 1 on 16 GB300 GPUs with DSpark (synthetic AL=6), alongside a new process meant to keep review and maintenance manageable.

Key points
  • vLLM built a unified CuTe DSL decode path for Kimi K3 on NVIDIA GB300 using agent-assisted development.
  • Reported results: over 840 tokens/s at batch 1 on 16 GB300 GPUs with DSpark (synthetic AL=6), 1.5-2× higher decode throughput in several configurations, up to 1.8× higher P90 interactivity on AgentX.
  • Per layer, the specialized path uses 69 microseconds and 13 kernels versus 130 microseconds and 23 kernels in stock vLLM.
  • A proposed fast-track RFC isolates changes within model code and relies on systematic validation to reduce review burden.
  • Kimi K3 is the first contribution under the fast-track approach.

What vLLM built for Kimi K3

According to vLLM, the new path uses agent-assisted development to create a unified CuTe DSL decode implementation covering attention, MoE and communication across 8 or 16 GPUs. It replaces and fuses almost all operations with customized CuTe DSL kernels tuned for specific subproblems.

The team reports 1.5-2× higher decode throughput in several tested configurations and up to 1.8× higher P90 interactivity on the AgentX workload. A kernel timeline in the post compares stock vLLM, which uses 130 microseconds and 23 kernels per layer, with the specialized decode path at 69 microseconds and 13 kernels.

The path targets NVIDIA Blackwell GPUs with 8 or 16 GPUs, decode batches from 1 to 64, and optional decode context parallelism for long contexts. The GPUs must share one NVLink domain with multicast support.

Four optimization techniques

vLLM describes four main areas of work.

  • Shape tuning: small-matrix kernels are used for attention input projections at batch sizes 1-2, and split-K kernels at larger batches. KDA gets its own CuTe DSL decode kernel, and decode context parallelism splits the KV cache across GPUs for long contexts.
  • Overlapping compute and communication: the attention output projection is fused with its all-reduce and the following attention-residual computation. At larger batches, a two-stage reduction reduces data movement between GPUs.
  • MoE scheduling: router scores and latent input projection, which the baseline computes in full on every GPU, are split across TP ranks and combined into one matrix multiplication. The shared expert runs on a separate stream.
  • Weight prefetching: in small-batch inference, which is often memory-bound, a dedicated kernel on a side stream loads upcoming weights into cache while communication runs, raising cache hit rates.

A fast-track model for agent-written code

The post argues that agent-optimized inference code is outpacing the team's review and maintenance workflow. Understanding every line of every kernel and testing every supported configuration is very time-consuming, but skipping that work risks shipping buggy software that fails in production. vLLM points to a proposed fast-track model optimization RFC as the foundation for its answer, with the stated aim of decreasing review burden while managing risk.

The approach rests on isolating changes within the model's code, bounding the scope, validating correctness systematically, and scaling validation by letting contributors run standard evaluations on their own GPUs and share reproducible results before requesting maintainer attention. Kimi K3 is the first contribution made this way.

Isolation has a cost. vLLM says input preparation, sampling and KV cache management are excluded, because they are shared across most deployments and changing them for one workload risks breaking other stable configurations. Work there should involve core maintainers more closely.

Bounded scope does not mean dropping features. For K3, initial hardware validation covers GB300 with TP8 and TP16, decode batches up to 64, speculative decoding with various draft lengths, and decode context-parallel configurations within one NVLink domain. Full-context serving, temperature sampling and structured output are treated as first-class features that belong in the validation plan.

What it means for vLLM users and contributors

For operators running Kimi K3 on GB300 hardware within the supported configurations, the reported gains point to higher decode throughput and better interactivity. The benefits apply only where the optimization is defined to apply.

For contributors, vLLM says agents should build tests, run evaluations and benchmarks, investigate failures and document the conditions under which an optimization works. Human reviewers would still judge the design and the evidence, but from a higher level than a line-by-line code review. The team says it believes the community can build this together, bringing more models, GPUs and workloads closer to the speed of light.

Related news

vLLM adds day-0 support for Mistral Large 4, a 1-trillion-parameter MoE model
For developersOctober 29, 2026

vLLM adds day-0 support for Mistral Large 4, a 1-trillion-parameter MoE model

The vLLM inference project now supports Mistral Large 4 from day 0. According to vLLM, the model is Mistral's new frontier mixture-of-experts, natively multimodal model…

Cline hits 11,840 tokens per second on one GPU with Nemotron 3.5 Super VL
For developersOctober 27, 2026, 20:12

Cline hits 11,840 tokens per second on one GPU with Nemotron 3.5 Super VL

Cline says it reached 11,840 aggregate output tokens per second on a single GB300 running NVIDIA's Nemotron 3.5 Super VL with 256 concurrent requests. The team published…

vLLM Adds Day-0 Support for MiniMax-M3.1-Flash on NVIDIA and AMD GPUs
For developersOctober 23, 2026

vLLM Adds Day-0 Support for MiniMax-M3.1-Flash on NVIDIA and AMD GPUs

The vLLM project says it supports MiniMax-M3.1-Flash from day 0 on NVIDIA Blackwell and Rubin GPUs and on AMD MI350-series GPUs. According to vLLM, the model is built…