25 October 2026 EN ES
The Serving Desk

The stack under your AI product — models, serving, and what it costs

Serving

Run this PyTorch 2.13 gate before your next serving-stack upgrade

Small fleets should verify pins, imports, drift, and baselines before chasing serving latency.

Illustration: Run this PyTorch 2.13 gate before your next serving-stack upgrade

You are deciding whether a serving-stack upgrade is worth the risk. vLLM 0.28.0 shipped 584 commits from 270 contributors, including 76 new contributors. The trade-off is latency for environment risk: 584 commits divided among 270 contributors, with 76 new, is a broad compatibility surface, so a small fleet should gate the stack before it chases the new numbers. Read the release as a compatibility checklist.

Pin diffs fail before traffic

PR #48155 updated the PyTorch ecosystem versions from PyTorch 2.11.0 to 2.13.0, torchvision 0.26.0 to 0.28.0, and Triton 3.6.0 to 3.7.1. A stale pin can fail at import time, not request time, when the image still carries the old trio. Diff the image manifest, not just the package list, and put the pin diff first in the rollout record.

ABI and drift fail after startup

The PyTorch 2.13 update needed a workaround in the Qwen2-VL multi-image CPU test, limiting max_tokens and broadening logprob tolerance due to numerical drift. The same update disabled the nixl_ep import check as an expected failure while a prebuilt extension ABI mismatch awaited a rebuild. These are post-startup failure modes. Smoke-test the import path in the serving environment, and measure drift on a fixed prompt set before and after the bump. When logprob tolerance needs broadening, record the delta with the baseline.

Hardware-specific builds carry the same risk. vLLM Ascend v0.26.0rc1 was a model-restricted release candidate aligned with upstream vLLM v0.26.0. Its fully validated models included Kimi K3, GLM-5.2, DeepSeek V4 Flash 0731, and DeepSeek V4 Pro 0813. The earlier vLLM Ascend v0.23.0 was an official release aligned with upstream vLLM v0.23.0. Check your model against the validated list before you rely on it. When your model is not listed, treat it as unvalidated until your own drift check says otherwise, and keep that result with the baseline.

Baseline before you measure the latency win

vLLM 0.28.0 shipped sparse MLA for DeepSeek V4, disk-tier KV cache offloading, Model Runner V2 maturity, and 1.5-3x Kimi-K3 kernel speedups. Baseline TTFT and throughput before you enable the new kernels. Capture the numbers per model, not per image, because a kernel speedup for one model can hide a regression in another. Include long-context requests for any model that uses disk-tier KV cache offloading, and record the prompt set, seed, and GPU count in one note.

PR #48155 merged into vLLM main on July 23, 2026. Record that date in the change log so the environment change is separate from the feature change. For prefill decode disaggregation, the gate must cover every worker. A pin bump can change one worker and leave the other on the old ABI, so test the worker pair, not just the serving endpoint.

The gate turns measurement into a decision

Run the list below as the pre-upgrade gate before the image goes to production. Early items catch environment failures; later items turn measurement into a decision. Keep the gate short enough to finish before the rollout window, but complete enough to catch the failure modes above.

  • Verify the PyTorch, torchvision, and Triton pins match the new stack.
  • Smoke-test the ABI-sensitive import path before traffic.
  • Measure numerical drift on a fixed prompt set, using the Qwen2-VL CPU workaround as the warning sign.
  • Baseline TTFT and throughput for each target model before you enable the new kernels.
  • Set a rollback trigger on import failure, token drift, or a TTFT regression beyond your SLO.

Any item failure stops the rollout. Keep the old image tag, old pin file, and old baseline in the change record, with the date and model name. The new stack can pass import and drift but miss your TTFT target; decide with data instead of guessing. A fired trigger requires rollback before the next customer request.

Advertisement