vLLM v0.26.0 ออกแล้ว — 411 commit จาก 212 คน: เลือก attention backend แยกต่อ KV-cache group ได้ และ KV offloading ขึ้นชั้น object store เต็มตัว

เช้าวันนี้ (27 ก.ค. 2026 เวลา 01:06 UTC) ทีม vLLM ปล่อย v0.26.0 ออกมา — เป็นรอบที่ใหญ่มากอีกครั้ง: 411 commit จากผู้ร่วมพัฒนา 212 คน (ในจำนวนนี้เป็นหน้าใหม่ 61 คน) ห่างจาก v0.25.0 เพียงราวสองสัปดาห์ครึ่ง

ถ้าจะสรุปธีมของรอบนี้ให้เหลือประโยคเดียว: vLLM กำลังเลิกมองว่าโมเดลทุกตัวเหมือนกัน — ทั้งเรื่อง attention backend, ชั้นเก็บ KV cache และเส้นทางฮาร์ดแวร์ ล้วนถูกแยกให้ปรับแยกส่วนได้มากขึ้นแทนที่จะเป็นค่าเดียวทั้งเซิร์ฟเวอร์

เลือก attention backend ต่อ KV-cache group — ของที่โมเดล hybrid รอมานาน

ของที่ควรจับตาที่สุดในรอบนี้คือ การเลือก attention backend แยกกันได้ต่อ KV-cache group (PR #48012) และการยก sliding window ขึ้นเป็น “ความสามารถของ backend” อย่างเป็นทางการ (#48011)

ทำไมถึงสำคัญ: โมเดลรุ่นใหม่จำนวนมากเป็น hybrid — บางเลเยอร์ใช้ full attention บางเลเยอร์ใช้ sliding-window บางตัวผสม Mamba/linear attention เข้าไปด้วย เดิมที vLLM บังคับให้ทั้งโมเดลใช้ backend เดียว ทำให้ต้องเลือก backend ที่ “รองรับทุกอย่าง” แทนที่จะเป็น backend ที่ “เร็วที่สุดสำหรับแต่ละส่วน” ตอนนี้แต่ละกลุ่ม KV cache เลือกทางของตัวเองได้

ประกอบกับการรีแฟกเตอร์ KV-cache layout ที่แพ็ก K/V เข้าไปในมิติ content ร่วมกันข้าม backend (#44455) นี่คืองานฐานรากที่จะทำให้โมเดล hybrid รุ่นถัด ๆ ไปเสียบเข้า vLLM ได้เร็วขึ้นมาก

KV offloading โตขึ้นจนใช้ในโปรดักชันได้

หมวดที่มีของใหม่เยอะที่สุดในรอบนี้คือ KV offloading / tiered storage — คือการย้าย KV cache ที่ยังไม่ใช้ออกจาก HBM ไปพักไว้ชั้นล่าง แล้วดึงกลับมาเมื่อ prefix เดิมถูกเรียกซ้ำ ของที่เพิ่มเข้ามา:

• ชั้นรองแบบ object store พร้อม workload identity (#47063, #47274, #48150) — ไม่ใช่แค่ offload ลง CPU RAM อีกต่อไป แต่ไปถึง object storage จริง ๆ พร้อมระบบยืนยันตัวตนของ workload
• เมตริกครบชุด (#45958) — แยกการใช้ CPU cache เป็นเกจ read/write คนละตัว (#47666) และแยก tiering-lookup-delay เป็นฮิสโตแกรม sync/async (#47679)
• tier-owned event handling + BlockStored events (#46544, #47923) และ tiering ที่รู้จัก DP replica (#47987)
• blocks_per_chunk สำหรับกลุ่ม KV ที่ไม่เหมือนกัน (#48878)

จุดที่ผมคิดว่าคนดูแลระบบจะรู้สึกได้ก่อนใครคือ เมตริก — ที่ผ่านมา KV offloading เป็นกล่องดำที่บอกไม่ได้ว่าช่วยจริงหรือทำให้ช้าลง พอมีฮิสโตแกรมของ lookup delay แยก sync/async ก็เริ่มตอบได้ว่าควรเปิดหรือปิด

โมเดลใหม่และงานเร่งความเร็ว

ฝั่งรองรับโมเดล รอบนี้ ตระกูล Inkling ของ Thinking Machines ได้สแตกเต็ม: modeling พื้นฐาน (#48799), piecewise CUDA graph (#48822), Hopper FA4 relative attention (#48858), speculative decoding แบบ MTP=1 (#48869), LoRA (#48884) และ quantization NVFP4 มาตรฐานของ ModelOpt (#48990) — ครบพอที่จะเอาไปเสิร์ฟจริง ไม่ใช่แค่ “โหลดได้”

ฝั่ง DeepSeek-V4 มีงานเร่งหลายจุด ซึ่งการ์ดรีลีสระบุตัวเลขไว้ตรง ๆ: routing kernel เฉพาะทางลด E2E TPOT ได้ 2.94% (#48660), fused_topk_bias เร็วขึ้นระดับ 1.5–2 เท่าที่ตัวเคอร์เนล (#47463) และการตัด repeat/copy ที่ซ้ำซ้อนออกอีก 1.8% TPOT (#48137) — ตัวเลขไม่หวือหวารายตัว แต่รวมกันแล้วมีผลกับบิลค่า GPU จริง

ของอื่นที่น่าสังเกต:

• fp32 lm_head ผ่าน head_dtype (#48390) ขยายไปถึงเส้นทาง LoRA (#48525) — แลกหน่วยความจำนิดหน่อยเพื่อความแม่นยำของ generation head
• โมเดลใหม่: Cosmos3 Edge Reasoner (#48291), Cosmos3-Super, TranslateGemma-12b-it, BertForMaskedLM, XLM-Roberta สำหรับ token classification
• Transformers 5.13.0 (#47867) พร้อมย้าย Olmo/Olmo2, MistralLarge3, HunyuanVL ไปใช้ Transformers modeling backend
• Rust frontend รับวิดีโอ (#47959) และเสียง (#48554) แบบ multimodal ได้แล้ว พร้อมพอร์ต vllm-bench เป็น native (#48107)
• ROCm/AMD ได้ของเยอะผิดปกติในรอบนี้ — two-stage compressor สำหรับ DSv4 prefill, sparse decode/prefill หลายตัว, MXFP8 GEMM ของ MiniMax-M3 และ DSpark speculative decoding
• CPU/สถาปัตยกรรมอื่น: มี wheel สำหรับ macOS arm64 แบบ native แล้ว (#48289) รวมถึง s390x NUMA topology และ IBM Power

มุมมอง AI Curator

รีลีสนี้อ่านแล้วเห็นทิศทางชัด: vLLM กำลังเปลี่ยนจาก “engine ที่รันโมเดลได้เร็ว” ไปเป็น “ระบบปฏิบัติการของ inference” — เรื่องที่ได้พื้นที่มากที่สุดไม่ใช่เคอร์เนลใหม่ แต่เป็น ชั้นเก็บ KV cache, เมตริก, identity ของ workload และ การแยกค่าคอนฟิกให้ละเอียดขึ้น นี่คือคำศัพท์ของทีม infra ไม่ใช่คำศัพท์ของทีมวิจัย และมันสะท้อนว่าผู้ใช้หลักของ vLLM ย้ายจากแล็บไปเป็นคนที่ต้องตื่นมาดู dashboard ตอนตีสาม

สิ่งที่นักพัฒนาไทยควรเอาไปใช้ทันทีมีสองข้อ ข้อแรกคือ object-store tier ของ KV offloading — สำหรับทีมที่รันบนคลาวด์ในไทย/สิงคโปร์ด้วยการ์ดจำนวนจำกัด ความสามารถในการเก็บ prefix cache ไว้นอก GPU แล้วดึงกลับมาใช้ซ้ำ มีผลตรงกับงานลักษณะ “prompt ยาวเหมือนกันทุกครั้ง” เช่นระบบ RAG ที่แนบเอกสารนโยบายชุดเดิมทุกคำถาม หรือ agent ที่มี system prompt ยาวเป็นหมื่นโทเคน — และตอนนี้มีเมตริกให้พิสูจน์แล้วว่าคุ้มไหม ไม่ต้องเดา

ข้อสองคือ wheel macOS arm64 แบบ native ซึ่งฟังดูเล็กแต่เปลี่ยนขั้นตอนการทำงานได้จริง: ทีมที่ dev บน MacBook แล้ว deploy ขึ้น Linux + NVIDIA จะทดสอบเส้นทางโค้ดเดียวกันบนเครื่องตัวเองได้โดยไม่ต้องสลับไปใช้ runtime คนละตัว (ช้าแน่นอน แต่ “รันได้บนเครื่องเดียวกับที่เขียนโค้ด” คือสิ่งที่ทำให้ CI ในเครื่องเป็นไปได้)

ข้อสังเกตสุดท้ายที่ควรพูดให้ตรง: จังหวะการออกเวอร์ชันระดับ 400–550 commit ทุกสองสัปดาห์ครึ่ง เป็นดาบสองคม ของดีมาเร็วก็จริง แต่ v0.25.1 ที่ออกก่อนหน้านี้เป็นแพตช์แก้บั๊กที่ทำให้โมเดล NVFP4 พ่นแต่ !!!!! ออกมา — เตือนว่าการอัปเกรด vLLM ในโปรดักชันควรมี smoke test ที่เช็ก คุณภาพเอาต์พุต ไม่ใช่แค่ว่าเซิร์ฟเวอร์บูตขึ้น ถ้าทีมคุณยังไม่มี ให้ทำก่อนขึ้น 0.26.0

แหล่งข่าว

• vLLM v0.26.0 Release Notes — GitHub
• vLLM v0.25.1 (แพตช์แก้บั๊ก NVFP4)
• vLLM Blog