vLLM 0.32 ออกแล้ว — CORS ไม่เปิดให้ทุก origin อีกต่อไป, ตัด Python 3.10, `max_tokens` เลิกกินพื้นที่ context, `/v1/systemone` เปิดเป็นค่าเริ่มต้น และ NVFP4 KV cache ลงมาถึง RTX/Ampere

vLLM ปล่อยเวอร์ชัน 0.32.0 เมื่อ 18 ต.ค. 2026 (06:50 UTC) รวม 814 คอมมิตจากผู้ร่วมพัฒนา 363 คน ในจำนวนนี้เป็นหน้าใหม่ 121 คน ห่างจาก 0.31 ที่มาพร้อม vllm preload สองสัปดาห์ รอบนี้ฟีเจอร์ใหม่มีไม่น้อย แต่ส่วนที่คนรัน vLLM ใน production ควรอ่านก่อนคือรายการ breaking change เพราะมีหลายข้อที่เปลี่ยนพฤติกรรมของ server โดยไม่มี error เตือน

ข้อที่กระทบวงกว้างที่สุดคือ CORS ก่อนหน้านี้ค่าเริ่มต้นของ allowed origins คือ ["*"] ซึ่งหมายความว่าเว็บไซต์ใดก็ได้ที่เบราว์เซอร์ของผู้ใช้เปิดอยู่ สามารถอ่าน response จาก vLLM server ที่เบราว์เซอร์นั้นเข้าถึงได้ ตั้งแต่รุ่นนี้ค่าเริ่มต้นจะไม่อนุญาต origin ภายนอกเลย

Breaking change ที่ต้องเช็กก่อนอัปเกรด

• CORS ปิดเป็นค่าเริ่มต้น (#61009) — คำขอจาก origin อื่นจะไม่ได้ header Access-Control-Allow-Origin กลับไป และ preflight ของ JSON ก็จะไม่ผ่าน มีผลทั้ง frontend ฝั่ง Python และ Rust ถ้ามี web UI ที่เรียก vLLM จากเบราว์เซอร์โดยตรง ต้องระบุ --allowed-origins เอง
• ต้องใช้ Python 3.11 ขึ้นไป (#60402) — Python 3.10 หมดอายุแล้ว requires-python จึงเปลี่ยนเป็น >=3.11,<3.15 และต้องใช้ transformers>=5.16.1,<5.20.0 กับ tokenizers>=0.23.2
• max_tokens ไม่ถูกจองไว้ใน context แล้ว (#57035) — เดิม vLLM ถือว่า max_tokens ที่ client ส่งมาเป็นพื้นที่ที่ต้องจองไว้ ตัวอย่างใน PR คือโมเดลที่ context 128,000 กับ prompt ยาว 62,466 token และ max_tokens: 65535 จะถูกปฏิเสธ เพราะ 62,466 เกิน 128,000 − 65,535 ไปหนึ่ง token รุ่นใหม่จะรับ prompt นี้แล้วลด max_tokens ลงเหลือ 65,534 ซึ่งตรงกับสเปก OpenAI และตรงกับที่ client อย่าง Zed หรือ opencode ใช้กันอยู่ ข้อเสียคือระบบที่เคยใช้ error นี้เป็นตัวกันไม่ให้ prompt ยาวเกินไปจะไม่ได้ error นั้นอีก
• Responses API เปลี่ยนชื่อ event ของ reasoning (#59652) — จาก response.reasoning_part.added/done ที่ vLLM ตั้งขึ้นเอง เปลี่ยนเป็น response.content_part.added/done ที่มี part.type="reasoning_text" ตาม OpenAI SDK ถ้า client ฟัง event ชื่อเดิมอยู่ จะไม่เห็นจุดเริ่มและจบของ reasoning โดยไม่มี error ใด ๆ
• ตัด cascade attention, sequence parallelism / AsyncTP ใน torch.compile และ mamba_cache_mode="all" ออกแล้ว

ความปลอดภัย: แพตช์สามช่องโหว่ และค่าเริ่มต้นที่เข้มขึ้น

นอกจาก CORS แล้ว รุ่นนี้ยังปิดช่องโหว่ GHSA-4hhp-h66f-j5j7 (chat template ใช้ทรัพยากรจนหมด), GHSA-q97c-p368-75c4 (max_token_id ใน tokenizer) และ GHSA-frvg-qw88-hww9 (ZMQ socket ของ P2P ถูกใช้จนหมด) และเพิ่มการป้องกันอีกหลายจุด คือภาพจากแหล่งที่ไม่น่าเชื่อถือรับเฉพาะ raster format, handle ของ multimodal cache ใน shared memory ต้องมีลายเซ็น และ JSON schema ที่ซ้อนลึกเกิน 64 ชั้นจะถูกปฏิเสธ แนวนี้ต่อจาก 0.31 ที่เริ่มปฏิเสธ multimodal kwargs ที่ส่งมากับคำขอ ทีม vLLM กำลังเปลี่ยนค่าเริ่มต้นทีละข้อ จากเดิมที่ออกแบบให้ “รันในเครื่องตัวเองได้สะดวก” ไปเป็น “เปิดเป็น API ให้คนนอกเรียกได้อย่างปลอดภัย”

ฟีเจอร์ใหม่ที่น่าสนใจ

• /v1/systemone เปิดให้ใช้เป็นค่าเริ่มต้น — endpoint สำหรับ “ตัดสินใจแบบมีโครงสร้าง” ตอบคำถามแบบ choice, noul และ score จาก state ที่ส่งเข้าไป (รูปแบบเดียวกับที่ Ollama รองรับ) ตอนนี้รันกับ Cloudflare/clef-omni, LiquidAI/d1-3B และ DiffusionGemma ได้แล้ว
• parser แบบ hf — --tool-call-parser hf กับ --reasoning-parser hf อ่าน response_template จาก checkpoint เอง ถ้าโมเดลใดใส่ template มาให้ ก็ไม่ต้องรอใครเขียน parser เฉพาะโมเดลนั้นอีก
• NVFP4 KV cache ใช้ได้กว้างขึ้น — รองรับ SM8x (Ampere/RTX 30), SM12x (RTX 50/Blackwell สำหรับผู้บริโภค) และ SM90 ส่วน GLM-5.x บน SM100 จะใช้ FP8 KV cache เป็นค่าเริ่มต้น ซึ่งลดหน่วยความจำ KV ต่อ rank ลงครึ่งหนึ่ง แลกกับ TTFT ที่ช้าลง 7–11% ตาม benchmark ใน PR
• เปิดเร็วขึ้นและรับโหลดได้มากขึ้น — มีคำสั่ง vllm download-kernels สำหรับติดตั้ง kernel ของ FlashInfer ที่คอมไพล์ไว้แล้ว และ vllm preload --preload-autotune ที่เก็บตาราง autotune ไว้ใช้ข้ามการรีสตาร์ต ถ้าตั้ง --api-server-count มากกว่า 1 แต่ละ connection จะถูกส่งไปยัง API worker ที่ว่างที่สุด PR วัดได้ว่ารับ request สั้นได้มากขึ้น 43–85% (Qwen3-0.6B, input 32 / output 1 token ซึ่งเป็นกรณีที่ได้ผลชัดที่สุด)
• โมเดลใหม่ — EmbeddingGemma 2 (embedding แบบ omni-modal), MiniCPM-V 4.7 และ Nemotron 3.5 ASR (ถอดเสียงทั้งไฟล์ ยังไม่รองรับ streaming แบบ realtime)

มุมมอง AI Curator

ข้อที่ทีมไทยควรรีบเช็กคือ CORS เหตุผลเพราะ setup ที่พบบ่อยมากในบริษัทและมหาวิทยาลัยคือรัน vLLM บนเครื่อง GPU ใน LAN แล้วให้ web UI ภายในเรียกตรงจากเบราว์เซอร์ ค่าเดิม * ทำให้หน้าเว็บภายนอกใดก็ได้ที่พนักงานเปิดอยู่ แอบยิงคำขอไปที่ http://10.x.x.x:8000 แล้วอ่านคำตอบกลับไปได้ เครื่อง vLLM ที่ไม่ได้เปิดสู่อินเทอร์เน็ตจึงไม่ได้ปลอดภัยอย่างที่หลายทีมคิด การเปลี่ยนค่าเริ่มต้นครั้งนี้ปิดช่องนั้นให้โดยอัตโนมัติ แต่หลังอัปเกรด UI ภายในหลายตัวจะเรียกไม่ติด ทางแก้ที่ถูกคือใส่ --allowed-origins เฉพาะโดเมนของ UI ตัวเอง อย่าใส่ * กลับเข้าไปเพียงเพื่อให้ใช้ได้เหมือนเดิม

ข้อที่น่ากังวลกว่า CORS คือการเปลี่ยนแปลงที่ไม่มี error เตือน การเปลี่ยนเรื่อง max_tokens ถูกต้องตามสเปก แต่ใครที่เคยใช้ error ตัวนี้เป็นตัวกั้น prompt ยาวโดยไม่ตั้งใจ จะพบว่าคำตอบสั้นลงแทนที่จะได้ error ส่วนการเปลี่ยนชื่อ event ของ reasoning จะทำให้ UI ที่แสดงกล่อง “กำลังคิด” หยุดแสดงไปเฉย ๆ ทั้งสองข้อแบบนี้ไม่ทำให้ CI ล้ม ควรมี smoke test ที่ตรวจ prompt ยาวและ stream ของ reasoning ก่อนจะเลื่อนเวอร์ชันใน production

ภาพรวมของรุ่นนี้สอดคล้องกับที่เราเห็นมาหลายรอบ vLLM เลิกเป็นแค่ “ตัวรันโมเดลให้เร็ว” แล้ว และกำลังกลายเป็น API server เต็มรูปแบบที่มีค่าเริ่มต้นด้านความปลอดภัยของตัวเอง การที่ NVFP4 KV cache ลงมาถึงการ์ด RTX 30/50 ก็ทำให้เครื่องเล่นการ์ดจอเดียวรับ context ยาวได้มากขึ้นโดยไม่ต้องซื้อการ์ดใหม่ ซึ่งตรงกับสภาพของทีมเล็กในภูมิภาคนี้ที่ส่วนใหญ่ยังใช้การ์ดผู้บริโภคอยู่

แหล่งข่าว

• vLLM v0.32.0 release notes (GitHub)
• PR #61009 — Restrict default CORS origins
• PR #57035 — Treat max_tokens as output upper bound
• PR #59652 — Standard reasoning content-part events (Responses API)