Photo by Azwedo L.LC on Unsplash. Source: https://unsplash.com/photos/a-man-sitting-at-a-desk-working-on-a-computer-g4c1wNljbBI (Unsplash License).

The interesting number in vLLM’s Kimi K3 work is not the speedup. It is who wrote the code.

  • Coding agents built a unified CuTe DSL decode path for Kimi K3, covering attention, MoE and communication across 8 or 16 Blackwell GPUs.
  • One transformer layer went from 23 kernels and 130 microseconds to 13 kernels and 69 microseconds.
  • Gains run from 1.88 times at batch one on 16 GB300 GPUs down to 1.62 times at batch 64, so the whole curve moves rather than a single point.
  • With DSpark the same 16 GPU setup clears 842 tokens per second at batch one, 1.73 times stock vLLM under identical speculation.
  • The team proposed a fast-track RFC that keeps each optimization inside the model’s code and requires published correctness and performance evidence before a maintainer reviews it.

The review process, not the kernel, is the constraint now, and that is the harder problem to buy your way out of. Read the full analysis.

By Ivan Tarin

Ivan Tarin is a Principal Product Marketing Manager at SUSE, where he owns go-to-market strategy and positioning for a seven-product cloud-native portfolio spanning Kubernetes, virtualization, storage, security, and observability. A former full-stack developer who shipped production code for enterprise and public-sector clients including U.S. national laboratories, Ivan translates complex infrastructure and AI technology into messaging that lands with developers, platform teams, and enterprise buyers. He has presented at KubeCon, SUSECON, and AWS Developer Week, and is currently pursuing an MS in Artificial Intelligence at the University of Colorado Boulder.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the next one before it is old news

Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.