vLLM 0.28 dobler token-budsjettet, bitsandbytes blir plugin

vLLM-prosjektet publiserte versjon 0.28.0 på GitHub 26. august, bygget på 584 commits fra 270 bidragsytere. 76 av dem bidro for første gang. Det er den brede kontaktflaten som gjør denne utgivelsen risikabel å rulle rett inn i produksjon.

Den viktigste endringen for deg som kjører vLLM selv står under «Breaking Changes». Støtten for bitsandbytes er flyttet ut av kjernen og lever nå som en ekstern plugin. Laster oppsettet ditt bitsandbytes-kvantiserte vekter, stopper serveren til pluginen er på plass. I tillegg er calculate_kv_scales fjernet, override_attention_dtype er borte, og Transformers er løftet til 5.15.0.

Standardverdiene har også flyttet seg. max_num_batched_tokens går fra 8192 til 16384, prefix-caching slås på som standard for Mamba-modeller, og grensen for CUDA-graf-innfanging på Blackwell heves til 1024. Et doblet token-budsjett gir høyere gjennomstrømning, men også høyere minnetopp per steg. Har du dimensjonert GPU-minnet tett, er dette parameteren du senker først.

Sikkerhetsdelen inneholder én rettelse og én advarsel. En tjenestenekt-sårbarhet der forfalsket samplingsrate omgikk vakten på lydavkodingens varighet, er nå tettet. Advarselen er verdt mer: dokumentasjonen slår nå fast at --api-key ikke beskytter alle endepunkter. Har du eksponert vLLM internt i tillit til det flagget, er antakelsen feil.

For beskjeden maskinvare er det to lyspunkter. KV-cachen kan nå avlastes til disk, og en ny MLA-backend lar DeepSeek-V2 og V3 kjøre på CPU.

Hva bør du gjøre?

1. Sjekk om oppsettet ditt laster bitsandbytes-vekter før du oppgraderer, og installer pluginen i samme operasjon.
2. Sett max_num_batched_tokens eksplisitt i konfigurasjonen, slik at den doblede standardverdien ikke overrasker minnebudsjettet.
3. Gå gjennom hvilke vLLM-endepunkter som faktisk er eksponert, og legg autentisering foran serveren i stedet for å stole på --api-key.