Hopp til hovedinnhold

Søndag 8. november

vLLM 0.32.0 stenger CORS som standard og kjører NVFP4 KV-cache på flere GPU-generasjoner

søndag 18. oktober · KI-generert · Kilde: GitHub

Innholdet er KI-generert og kan inneholde feil. Sjekk originalkilden.

Oppgrader til vLLM 0.32.0 for å lukke CORS-hullet i selvhostede servere, men sjekk Python-versjon og nettleserklienter først.

814 commits fra 363 bidragsytere havnet i vLLM 0.32.0, som vLLM-prosjektet publiserte på GitHub 18. oktober. Den viktigste endringen for deg som kjører vLLM selv er likevel liten i kode: standarden for CORS er endret fra * til en tom liste, i både Python- og Rust-frontenden.

Endringen kommer fra PR #61009, flettet 11. oktober. Med den gamle standarden kunne en hvilken som helst nettside du hadde åpen, lese svar fra en vLLM-server nettleseren din nådde, så lenge serveren ikke krevde API-nøkkel. En vLLM-boks i hjemmenettet uten nøkkel er akkurat det oppsettet.

«Nettleserskript kunne dermed lese API-svar fra nåbare installasjoner som ikke hadde konfigurert en API-nøkkel.» — PR #61009 i vLLM-repoet på GitHub

Har du en web-frontend som kaller vLLM-API-et direkte fra nettleseren, slutter den å virke etter oppgraderingen til du legger adressen dens inn i --allowed-origins. Agenter og skript som kaller API-et fra en backend merker ingenting, fordi CORS håndheves av nettleseren. Release-notatene lister også rettinger for tre GHSA-varsler, og flere steder strammes inn: bilder fra ukjente kilder begrenses til rasterformater, JSON-skjemaer nestet dypere enn 64 nivåer avvises, og håndtakene til den delte multimodale cachen signeres.

På ytelsessiden kjører NVFP4 KV-cache nå på SM8x og SM12x, altså Ampere-kort som RTX 30-serien og Blackwell-kort som RTX 50-serien, i tillegg til Hopper (SM90). For GLM-5.x på SM100 er FP8 KV-cache blitt standard, og ROCm får en 4-bits KV-cache med omtrent dobbelt så høy tetthet som FP8.

«Halverer KV-minnet per rank, med 2,3 til 5,5 % mer gjennomstrømning mot 7 til 11 % høyere TTFT i PR-ens benchmark.» — release-notatene for vLLM 0.32.0

Kjører du flere API-prosesser med --api-server-count over 1, går hver tilkobling nå til den minst belastede. Det ga 43 til 85 % flere forespørsler per sekund på korte forespørsler med Qwen3-0.6B i prosjektets egen måling. Den nye hf-parseren leser response_template fra sjekkpunktet, så modeller som leverer den trenger ikke lenger en modellspesifikk verktøy-parser.

Oppgraderingen har skarpe kanter. Python 3.10 er droppet (minimum er 3.11), transformers må ligge mellom 5.16.1 og 5.20.0, og cascade attention er fjernet. max_tokens er nå en øvre grense for output i stedet for å reserveres fra kontekstvinduet, så lange prompter avvises ikke lenger. Strømmer du resonnering fra Responses API, har hendelsene nye navn: response.content_part.added/done med part.type="reasoning_text" erstatter response.reasoning_part.added/done.

Hva bør du gjøre?

  1. Sjekk at miljøet kjører Python 3.11 eller nyere, eller bruk Docker-imaget vllm/vllm-openai:v0.32.0 (CUDA 13.0) eller v0.32.0-cu129 hvis driveren din stopper på CUDA 12.9.
  2. Legg inn adressen til web-frontenden din i --allowed-origins hvis den kaller vLLM fra nettleseren, og sett en API-nøkkel uansett.
  3. Test strømmeklienter mot Responses API før du bytter i produksjon, siden resonneringshendelsene har fått nye navn.

Pulsen · norske KI-nyheter for deg som bygger. Sakene er KI-generert fra originalkilden, som alltid lenkes.