vLLM v0.27.0 released August 10 (commit 4bdc8a7, 561 commits from 242 contributors). The change that matters most for production serving: two new warmup mechanisms that eliminate first-request compilation stalls, and a PyTorch 2.13.0 upgrade that is explicitly called out as a breaking environment change. Both are worth acting on now.

First-request latency gets a structural fix

Before this release, the first request to a vLLM server often hit a multi-second stall while Triton kernels compiled. That was invisible in dev (you tested once, everything looked fine) but painful in CI, health checks, and canary deploys where the very first probe can trigger a timeout.

Two mechanisms address this in v0.27.0:

  • JIT warmup infrastructure (#47451): a new subsystem that pre-compiles JIT-dependent code paths at startup.
  • Runner-owned Triton kernel warmup (#49903): the model runner now warms Triton kernels before accepting the first request.

The release notes also note FlashAttention 4 SM100 gains FP8 KV cache support (#42569) and headdim-256 (#42669), both backed by the warmup infrastructure. If you are on Hopper or Blackwell and using FlashAttention 4, the combination of FP8 KV cache plus warmup removes both the accuracy compromise of FP16 KV and the cold-start penalty. That is a real throughput win, not a theoretical one.

Torch 2.13.0 is a breaking change — plan the migration

The release upgrades to PyTorch 2.13.0, torchvision 0.28.0, and Triton 3.7.1 (#48155). The notes flag this as a breaking environment change. XPU (#48677) and CPU (#50412) runtimes followed to torch 2.13 as well, so if you run mixed GPU/CPU inference the jump is forced across the board.

What I would do before bumping: run your full eval suite against v0.27.0 in a staging environment with the new torch pin, and diff token-level outputs on at least your top-3 production models. Triton 3.7.1 can change kernel selection in edge cases, and the warmup path itself is new enough that I would not trust it with a zero-rolling-back production cluster on day one.

Kimi K3 lands as a full-stack model in one release

Kimi K3 support spans model files and kernels (#50089, #50000), Python frontend (#50093), Rust frontend (#50104), AttnRes kernels (#50090), DeepGEMM support (#50458), DSpark AR fusion (#50242), and optional shared-expert sharding (#50656). That is unusual — most new model integrations land over two or three releases with gaps between kernel support and frontend wiring. If you are evaluating Kimi K3 for production, v0.27.0 is the first version where the full path is available.

Other model additions in this release: Qwen3.5 text-only dense and MoE (#50210) with EVS video token pruning (#48912), K-EXAONE-2.0-750B-A37B (#50524), and jina-embeddings-v5-text-nano (#50688).

The catch

  • The warmup path is new. If you are on a strict no-downtime upgrade policy, roll out v0.27.0 with a canary and monitor first-request p99 for the first 24 hours.
  • Torch 2.13 + Triton 3.7.1 is a two-version jump in the kernel ecosystem. Custom Triton kernels in your deployment (if you have any) may need re-baselining.
  • v0.27.1 (#50424, released Aug 11) is a patch adding quantized DSpark Markov heads. Use 0.27.1, not 0.27.0.

Sources: