vLLM 0.28.0 прискорила Kimi-K3 і додала багаторівневий KV-кеш

vLLM 0.28.0 став одним із найбільших оновлень платформи інференсу за останні місяці: 584 коміти від 270 учасників принесли оптимізації для Kimi-K3 і DeepSeek V4, нові режими спекулятивного декодування, багаторівневе вивантаження KV-кешу та помітно зріліший Model Runner V2. Реліз орієнтований не на косметику, а на пропускну здатність, час до першого токена й керування пам’яттю у великих production-кластерах.

Оптимізація Kimi-K3 і DeepSeek V4

Для Kimi-K3 команда додала Decode Context Parallel, об’єднані ядра FlashKDA для decode і prefill, підтримку SiTU-активацій у MegaMoE та GEMM-RS для sequence parallelism. У release notes зазначено прискорення об’єднаних all-gather операцій на рівні ядра в 1,5–3 рази. Адаптивний бюджет спекулятивних токенів, за даними авторів, приблизно на 60% покращив TTFT у сценарії DSpark, а розподілення shared experts може заощадити близько 17 ГіБ пам’яті на GPU.

Ці числа не слід переносити на будь-який кластер автоматично: результат залежить від моделі, довжини контексту, топології прискорювачів і профілю трафіку. Проте напрям зрозумілий — vLLM дедалі більше оптимізує не окреме ядро, а весь шлях запиту від планувальника до колективних операцій.

DeepSeek V4 отримав end-to-end sparse MLA для звичайного декодування, MTP і DSpark, підтримку AMD Quark NVFP4, оптимізації sparse top-k metadata та роботу на ROCm для gfx11 і gfx950. Для команд із неоднорідним парком GPU це важливо: частина нових можливостей більше не прив’язана виключно до CUDA.

Спекулятивне декодування й Model Runner V2

У релізі з’явився DFlash2 із локальною згорткою та селектором кандидатів, DSpark із перевіркою за рівнем упевненості, а асинхронне планування для draft-моделей тепер вмикається автоматично. Ідея спекулятивного декодування залишається тією самою: легша модель або спеціальний механізм пропонує кілька токенів наперед, а основна модель перевіряє їх пакетом. Виграш можливий лише тоді, коли частка прийнятих токенів компенсує додаткову роботу.

Model Runner V2 додав розділення етапів encode, prefill і decode, вивантаження ваг, багатошаровий KV-кеш для MTP, CUDA graphs для encoder-частини та token-wise pooling. Також з’явилася підтримка attention-free моделей і параметра thinking_token_budget. Це робить V2 реальнішим кандидатом для production, але перед міграцією потрібно перевірити сумісність конкретної архітектури та плагінів.

KV-кеш тепер можна розкладати по рівнях

Багаторівневе offloading отримало дисковий шар, зовнішні менеджери другого рівня через module_path, часткові результати завантаження та окремі метрики tiering. Практично це дає змогу будувати ієрархію GPU — RAM — локальний диск, зменшуючи кількість повторних prefill для довгих або повторюваних контекстів.

Практична порада: кеш на диску не є безкоштовною пам’яттю. Вимірюйте hit rate, затримку відновлення, пропускну здатність накопичувача й деградацію хвостових percentile, інакше дешевший рівень може лише приховати проблему планування.

Нові значення за замовчуванням і несумісності

max_num_batched_tokens збільшено з 8192 до 16384, prefix caching для Mamba увімкнено автоматично, а ліміт захоплення CUDA graph на Blackwell піднято до 1024. Після оновлення це може змінити споживання пам’яті та характер пакетування навіть без правок конфігурації.

Є й ламаючі зміни: bitsandbytes винесено в окремий плагін, Transformers оновлено до 5.15.0, а застарілі calculate_kv_scales та override_attention_dtype прибрано. Оновлювати production-кластер варто через canary: зафіксувати старі метрики, прогнати репрезентативні запити, порівняти TTFT, throughput, GPU memory і якість результатів, а вже потім розширювати розгортання.

Джерело та права

Матеріал є самостійним українським переказом release notes vLLM 0.28.0 від 26 серпня 2026 року. Репозиторій і його документація поширюються за Apache License 2.0. Твердження про продуктивність наведено як результати авторів релізу; вони потребують перевірки на власному навантаженні. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста».