vLLM 0.31 ออกแล้ว — ใช้ `vllm preload` คำสั่งเดียวก็เก็บน้ำหนักค้างบน GPU ได้, snapshot ทั้ง engine ด้วย CRIU ลดเวลาเปิดจาก 54.7 เหลือ 20.4 วินาที และ endpoint สาธารณะปลอดภัยขึ้นเพราะปฏิเสธ multimodal kwargs ที่ส่งมากับคำขอเป็นค่าเริ่มต้น

vLLM ปล่อยเวอร์ชัน 0.31.0 เมื่อ 5 ต.ค. 2026 รวม 717 คอมมิตจากผู้ร่วมพัฒนา 307 คน (หน้าใหม่ 96 คน) ห่างจาก 0.30 ที่เปิดตัว Fast Start สองสัปดาห์ รุ่นนี้ยังเดินตามแนวเดิม คือทำให้รีสตาร์ต engine ได้เร็วขึ้น แต่คราวนี้ใช้งานจริงได้ง่ายขึ้นมาก Fast Start ที่เมื่อก่อนต้องเรียก daemon ผ่าน python -m ... ตอนนี้กลายเป็นคำสั่ง vllm preload แล้ว และยังมี snapshot ทั้ง engine แบบทดลองที่ใช้ CRIU เพิ่มเข้ามาด้วย

ส่วนที่คนเปิด endpoint ให้คนภายนอกเรียกต้องอ่านคือ breaking change ด้านความปลอดภัย ตั้งแต่รุ่นนี้ server จะปฏิเสธพารามิเตอร์ multimodal ที่ client ส่งมากับคำขอเป็นค่าเริ่มต้น ถ้าระบบของคุณพึ่งพารามิเตอร์นี้อยู่ อัปเกรดแล้วจะได้ error ทันที

vllm preload กับ snapshot — รีสตาร์ตเป็นวินาที

vllm preload (#56680) รวม weight-cache daemon ของ 0.30 มาไว้ในคำสั่งเดียว ระบบจะรัน daemon หนึ่งตัวต่อ GPU คอยถือน้ำหนักที่ quantize และแบ่ง TP แล้วไว้ในหน่วยความจำ GPU จากนั้น engine ที่สตาร์ตด้วย --load-format ipc_cache จะแมปน้ำหนักชุดนั้นผ่าน CUDA IPC แบบ zero-copy โดยไม่ต้องอ่านจากดิสก์ใหม่

vllm preload --model meta-llama/Llama-3.1-8B-Instruct --tensor-parallel-size 4
vllm serve meta-llama/Llama-3.1-8B-Instruct \
    --tensor-parallel-size 4 --load-format ipc_cache

(ตัวอย่างจากเอกสาร docs/features/preload.md) ก่อนเริ่มให้บริการ engine จะเทียบ fingerprint ของน้ำหนักกับ daemon ทั้งเนื้อหา checkpoint, สถาปัตยกรรม, TP/DP rank, dtype, วิธี quantize, revision และเวอร์ชัน vLLM และตรวจด้วยว่า GPU UUID ตรงกัน ถ้ามีอะไรไม่ตรงจะกลับไปโหลดจากดิสก์เอง ในรุ่นนี้รองรับ data parallelism, MTP draft model และมี endpoint /health เพิ่มด้วย ใช้ได้เฉพาะบน CUDA/ROCm และถ้าเป็น pipeline parallelism จะถูกปฏิเสธ

vllm snapshot create/restore (#51360 ยังเป็นฟีเจอร์ทดลอง) ไปไกลกว่านั้น คือใช้ CRIU dump โปรเซสของ engine ที่ init เสร็จแล้วทั้งก้อน แล้ว restore กลับมาก่อน bind HTTP ตอน restore จะสร้าง token ทดสอบหนึ่งตัวมาเทียบกับผลที่บันทึกไว้ ถ้าไม่ตรงจะล้มทันทีแทนที่จะเปิดให้บริการต่อ ตัวเลขใน PR วัดจาก Qwen3-32B BF16 TP1 บน H100 PCIe 80GB ได้ดังนี้

วิธี	เวลาเปิด (median, n=3)
เปิดโปรเซสปกติ (cache อุ่นแล้ว)	54.7 วินาที
restore จาก snapshot	20.4 วินาที

ลดลง 62.7% แต่การสร้าง snapshot ใช้เวลา 78.5 วินาที (วัดครั้งเดียว) จึงคุ้มทุนตั้งแต่การเปิดครั้งที่สาม ตอนนี้ยังจำกัดอยู่ที่ TP1 บน Linux x86-64 เครื่องเดียวกัน และ PR เตือนไว้ว่าไฟล์ CRIU อาจมี secret ของโปรเซสติดอยู่ ต้องเก็บเป็นไฟล์ส่วนตัว

Breaking change ด้านความปลอดภัย — ปฏิเสธ multimodal kwargs ที่มากับคำขอ

เดิมที client ส่ง mm_processor_kwargs และ media_io_kwargs มากับแต่ละคำขอได้ ค่าพวกนี้ถูกส่งต่อไปตอนโหลดและย่อขยายภาพ/วิดีโอ PR #58830 อธิบายว่าคำขอที่ไม่น่าไว้ใจจึง บังคับค่าภาพหรือวิดีโอแบบสุดโต่งจนหน่วยความจำหมดได้ ตั้งแต่ 0.31 ค่าเหล่านี้จะถูกปฏิเสธเป็นค่าเริ่มต้น ถ้าระบบเชื่อถือ client ได้ให้เปิดเองด้วย --trust-request-mm-kwargs ส่วน --mm-processor-kwargs ระดับ server และการเรียกผ่าน LLM แบบออฟไลน์ยังทำงานเหมือนเดิม

แพตช์ความปลอดภัยข้ออื่นในรุ่นนี้:

• prefix-cache แยก extra key ตามแหล่งที่มา ทำให้ชื่อ LoRA ชนกับ cache_salt ไม่ได้อีก และนำ path ของ LoRA ไปรวมใน block hash ด้วย
• ไม่ยอมให้ cache multimodal ที่ค้างอยู่เขียนทับ payload ใหม่
• ค่า min_tokens ที่เกิน max_tokens ถูกปฏิเสธ จากเดิมที่ทำให้ engine ค้าง
• ไม่รับ LoRA adapter ที่ตั้งชื่อซ้ำกับโมเดลที่ให้บริการอยู่

อื่น ๆ ที่ควรรู้

• DeepSeek-V4.1-Flash: บน SM100 ใช้ FlashMLA mega attention คู่กับ KV cache แบบ NVFP4 เป็นค่าเริ่มต้นแล้ว และ fuse เคอร์เนลเพิ่มอีกหลายจุด
• Scheduler: มี --max-num-active-seqs จำกัดจำนวนคำขอที่รันพร้อมกันแยกจาก max_num_seqs จึงลด batch ของ decode ได้โดยไม่ต้อง capture CUDA graph ใหม่ ส่วน --long-prefill-token-threshold ปรับตามจำนวน prefill ที่รอคิวอยู่
• API: มี --tool-strict-level, ใช้ response_format คู่กับ tool_choice=auto ได้, ปิด thinking ใน /v1/messages แบบ Anthropic ได้ และมี FIM completion ของ DeepSeek-V4
• Speculative decoding: มี drafter ใหม่ชื่อ LiLiCorr และ Model Runner V2 รองรับ draft model แล้ว

Breaking changes อื่น — เช็กก่อนอัปเกรด

• ถอด tokenizer_mode="slow" ออกแล้ว (ใน Transformers v5 โหมดนี้ทำงานเหมือน "hf" อยู่แล้ว)
• quantization="fp8" แบบ online ถูก redirect ไปที่ fp8_per_tensor และถอด AllSpark INT8 W8A16 ออก
• เปลี่ยนชื่อ --enable-mamba-fine-grained-prefix-cache เป็น --enable-mamba-shared-prefix-checkpoint
• ถอด env VLLM_PLE_CPU_OFFLOAD แล้ว ให้ใช้ --engram-config แทน
• --enforce-eager ปิด JIT kernel warmup ไปด้วย และตอนนี้ transformers มีเพดานเวอร์ชันใน requirements

มุมมอง AI Curator

ทีม vLLM ทำเรื่อง “เวลาเปิด engine” ต่อเนื่องมาสามรุ่นแล้ว ตั้งแต่ Model Runner V2 มาจนถึง Fast Start และ preload ในรุ่นนี้ ซึ่งบอกว่าคอขวดของคนรันโมเดลเองย้ายไปแล้ว throughput ต่อ GPU ตอนรันไปเรื่อย ๆ ดีพอแล้ว สิ่งที่ยังกินเงินคือ GPU ที่ว่างอยู่ระหว่างรอโหลดน้ำหนักครั้งละหลายนาที ทุกครั้งที่ deploy, autoscale หรือ engine ล่ม การรีสตาร์ตที่ลดเหลือหลักวินาทีจึงทำให้ scale-to-zero และ rolling update กับโมเดลขนาดใหญ่เป็นเรื่องที่ทำได้จริง ไม่ใช่แค่ไอเดีย

ทีมในไทยและอาเซียนที่เช่า GPU รายชั่วโมงหรือใช้ GPU ร่วมกันในคลัสเตอร์มหาวิทยาลัยได้ประโยชน์ตรง ๆ เพราะจ่ายตามเวลาที่ GPU ถูกจองไว้ ไม่ใช่ตามจำนวน token ที่ให้บริการ แต่ snapshot ยังเป็นฟีเจอร์ทดลองที่จำกัดแค่ TP1 และไฟล์ dump มี secret ติดอยู่ ควรลอง preload ก่อน เพราะใช้ใน production ได้แล้วและมี fallback กลับไปโหลดจากดิสก์ให้

ข้อที่สำคัญกว่าสำหรับคนที่เปิด vLLM เป็น API สาธารณะคือ #58830 ถ้าคุณรันโมเดลภาพหรือวิดีโอเป็น endpoint ที่ใครก็เรียกได้ รุ่นก่อนหน้านี้เปิดช่องให้คำขอเดียวทำ GPU หน่วยความจำเต็มได้ ไม่ว่าจะอัปเกรดตอนนี้หรือไม่ ควรตรวจว่า gateway ข้างหน้ากรองพารามิเตอร์พวกนี้ไว้แล้ว และก่อนอัปเกรดควรหาใน client code ว่ามีส่วนไหนส่ง mm_processor_kwargs อยู่ ถ้ามี ให้ตัดสินใจก่อนว่าจะเปิด --trust-request-mm-kwargs หรือย้ายค่าไปตั้งที่ server

แหล่งข่าว

• vLLM v0.31.0 release notes (GitHub)
• เอกสาร Preload — docs/features/preload.md
• PR #51360 — initialized-engine snapshots (ตัวเลขเวลาเปิด)
• PR #58830 — gate per-request multimodal processor kwargs