vLLM 0.25.0 มาแล้ว: ก่อนอัปเกรด inference stack อย่าเดา ให้ทำ Canary Test

ข่าวนี้คืออะไรในภาษาคนทำงาน: vLLM ออกเวอร์ชัน 0.25.0 และมีหลายจุดที่กระทบคนที่รัน LLM เองจริง ๆ ไม่ใช่แค่คนอ่าน benchmark

ใน release นี้ Model Runner V2 กลายเป็น default สำหรับ dense models, PagedAttention legacy implementation ถูกถอดออก, Transformers modeling backend ถูกระบุว่าเร็วขึ้นจนเทียบ native vLLM ได้ และมีทั้ง model support, speculative decoding, streaming parser, hardware performance และ security fixes จำนวนมาก

ถ้าคุณไม่ได้รัน inference เอง ข่าวนี้อาจดูไกลตัว

แต่ถ้าทีมคุณมี chatbot, RAG, coding agent, internal copilot, OCR pipeline หรือ workflow agent ที่เรียก open model ผ่าน vLLM อยู่ ข่าวนี้คือสัญญาณว่า inference runtime ไม่ใช่ชิ้นส่วนที่ควรอัปเกรดแบบเงียบ ๆ แล้วหวังว่าทุกอย่างจะเหมือนเดิม

1) เกิดอะไรขึ้น

vLLM เป็นหนึ่งใน runtime สำคัญของโลก open-source LLM เพราะช่วย serve โมเดลให้เร็วขึ้น ใช้ memory คุ้มขึ้น และต่อเข้ากับ production API ได้ง่ายขึ้น

ใน v0.25.0 จุดที่ควรอ่านก่อนมีอย่างน้อย 5 เรื่อง:

1. Model Runner V2 เป็น default สำหรับ dense models หมายความว่า execution path หลักของหลาย workload เปลี่ยนไป ไม่ใช่แค่เพิ่ม option ใหม่
2. PagedAttention ถูกถอดออก legacy path ที่หลายคนคุ้นชื่อไม่ได้อยู่เป็น fallback แบบเดิมแล้ว
3. Transformers modeling backend เร็วขึ้น release note ระบุว่า backend นี้เร็วเท่า native vLLM มากขึ้น และ Hugging Face ก็ออก transformers v5.13.1 เพื่อรองรับ latest vLLM release
4. รองรับ model และ parser ใหม่มากขึ้น เช่น Hy3, GLM-5, DeepSeek-V3.2, streaming parser engine, reasoning parser และ speculative decoding แบบใหม่
5. มี security และ robustness fixes เช่น ป้องกัน image decompression-bomb OOM, ป้องกัน infinite loop ใน audio split ที่มี NaN, จำกัด tokenizer work บางกรณี และ block request-level backend selection

อ่านแบบ release note อาจรู้สึกว่าเป็นเรื่องของ infra engineer

แต่อ่านแบบ operator นี่คือข่าวว่า engine ที่อยู่ใต้ agent และ AI app จำนวนมากกำลังเปลี่ยนพฤติกรรมพื้นฐานบางส่วน

2) ทำไม founder/operator/ทีมเล็กควรสนใจ

ทีมเล็กจำนวนมากไม่ได้เริ่มจาก infrastructure ใหญ่โต

หลายทีมเริ่มจาก API ของ vendor ก่อน แล้วค่อยเริ่มลอง open model เพราะอยากคุมต้นทุน, คุมข้อมูล, ลด vendor lock-in หรือทำงานที่ต้องใช้ model เฉพาะทาง

พอเริ่มรัน LLM เอง สิ่งที่มักถูกมองข้ามคือ runtime ไม่ได้เป็นแค่ท่อส่งคำตอบ

runtime มีผลกับ:

• latency ของลูกค้า
• throughput ตอนมี request พร้อมกัน
• memory ที่ใช้ต่อ GPU
• output format ที่ agent parse ต่อ
• tool call หรือ reasoning parser
• compatibility ของ model ที่ใช้จริง
• error pattern ที่ monitoring ต้องจับ
• cost ต่อ request

ดังนั้น release แบบ vLLM 0.25.0 ไม่ควรถูกอ่านว่า “มีอะไรเร็วขึ้นบ้าง” อย่างเดียว

ควรถูกอ่านว่า “อะไรในงานของเราที่อาจเปลี่ยนเมื่อ engine ใต้ระบบเปลี่ยน”

โดยเฉพาะถ้าคุณใช้ vLLM เป็นหลังบ้านให้ agent งานจริง เช่น:

• customer support bot ที่ต้องตอบเร็วและไม่หลุด format
• RAG assistant ที่ต้อง cite เอกสาร
• coding agent ที่ต้อง stream reasoning หรือ tool output
• OCR หรือ multimodal pipeline
• internal copilot ที่คนในทีมใช้ทุกวัน
• batch workflow ที่รันข้อมูลลูกค้าเป็นรอบ ๆ

ถ้าระบบเหล่านี้สะดุด คำว่า “release ใหม่เร็วขึ้น” ไม่ช่วยลูกค้าคุณครับ

3) วิธีเอาไปใช้จริง

ถ้าทีมคุณใช้ vLLM อยู่หรือกำลังจะใช้ ผมแนะนำให้ทำแบบนี้

3.1 อ่าน release note แบบจับผลกระทบ ไม่ใช่อ่านทุก PR

อย่าพยายามอ่าน 558 commits ทั้งหมดในครั้งเดียว

ให้ mark ก่อนว่า workload ของคุณแตะอะไรบ้าง:

• dense model หรือ MoE
• Transformers backend หรือ native model implementation
• multimodal input
• reasoning parser หรือ tool-call parser
• speculative decoding
• GPU รุ่นไหน เช่น H100, A100, Blackwell, AMD ROCm, Intel XPU, CPU
• model family เช่น Qwen, DeepSeek, GLM, MiniMax, Hy3, LLaVA

จากนั้นอ่านเฉพาะ section ที่ชนกับ workload จริงของทีม

3.2 อย่า deploy ด้วย tag latest

ถ้าใช้ container, pin image tag ให้ชัด

ถ้าใช้ pip, pin version ให้ชัด

ถ้าใช้ Kubernetes, แยก deployment สำหรับ canary แทนการ replace ทั้ง cluster

เป้าหมายไม่ใช่ทำให้ process เท่ขึ้น แต่ทำให้ rollback ได้ภายในไม่กี่นาทีถ้าเจอ regression

3.3 ทำ canary ด้วย workload จริง

benchmark สวย ๆ มีประโยชน์ แต่ไม่แทน workload ของคุณ

ให้เลือก request จริงที่ anonymize แล้วหรือ synthetic test ที่จำลองงานจริง 20 ถึง 50 เคส เช่น:

• prompt สั้น
• prompt ยาว
• RAG context หลาย chunk
• JSON output
• tool-call output
• streaming response
• multimodal input ถ้ามี
• request ที่เคยทำระบบล่มหรือช้า

แล้วเทียบ version เดิมกับ version ใหม่ใน metric เดียวกัน

3.4 ตรวจ output drift ไม่ใช่แค่ latency

inference runtime อาจไม่ได้เปลี่ยน model weight แต่ execution path, parser, scheduler, tokenizer behavior หรือ backend อาจทำให้ output ที่ระบบข้างบนเห็นต่างไปได้

ให้ตรวจอย่างน้อย:

• JSON ยัง parse ได้ไหม
• tool-call schema ยังถูกไหม
• citation ยังอยู่ไหม
• streaming chunk ยังไม่ทำ UI พังไหม
• stop condition ยังเหมือนเดิมไหม
• error message ยังถูกจับโดย monitoring เดิมไหม

นี่คือจุดที่ทีมเล็กพลาดบ่อย เพราะดูแค่ response time แล้วคิดว่าผ่าน

3.5 มี rollback note ที่คนอื่นทำตามได้

ก่อนอัปเกรด ให้เขียนสั้น ๆ ว่า:

• version เดิมคืออะไร
• version ใหม่คืออะไร
• deploy command คืออะไร
• rollback command คืออะไร
• dashboard ไหนต้องดู
• error pattern ไหนต้องหยุด rollout
• ใครเป็นคนตัดสินใจเปิดต่อหรือถอยกลับ

ถ้าคำตอบนี้อยู่ในหัวคนเดียว ยังไม่พร้อมแตะ production

Operator Kit: vLLM Canary Test Card

ใช้การ์ดนี้ก่อนอัปเกรด inference runtime

A) Scope

• ระบบที่จะทดสอบ: ____________________
• vLLM version เดิม: ____________________
• vLLM version ใหม่: 0.25.0
• model ที่เกี่ยวข้อง: ____________________
• traffic ที่ให้ canary: 1%, 5%, 10% หรือ internal only
• rollback owner: ____________________

B) Workload sample

เลือกอย่างน้อย 20 เคสจากงานจริง

• prompt สั้น 5 เคส
• prompt ยาว 5 เคส
• structured output 5 เคส
• streaming 5 เคส
• edge case ที่เคยพัง 5 เคส ถ้ามี

C) Metrics ที่ต้องเทียบ

Metric	Version เดิม	vLLM 0.25.0	ผ่านหรือไม่
p50 latency
p95 latency
tokens/sec
GPU memory
error rate
timeout rate
output parse success
cost ต่อ 1,000 requests

D) Output QA

สุ่มตรวจอย่างน้อย 20 outputs

• คำตอบยังอยู่ในภาษาและโทนที่ต้องการไหม
• JSON หรือ schema ยังถูกไหม
• citation หรือ reference ยังอยู่ไหม
• tool call ยังมี field ครบไหม
• streaming UI ยังไม่กระตุกหรือแสดง token แปลกไหม
• error message ยังถูกส่งเข้าระบบ monitoring ไหม

E) Decision rule

เปิดต่อได้เมื่อ:

• p95 latency ไม่แย่กว่าเดิมเกิน threshold ที่ตั้งไว้
• error rate ไม่เพิ่มแบบมีนัยสำคัญ
• output parse success ไม่ตก
• ไม่มี regression ในงานที่แตะลูกค้าหรือ production data
• rollback command ผ่านการทดสอบแล้ว

ถ้าไม่ผ่าน ให้ถอยกลับ version เดิมก่อน แล้วค่อยแยกสาเหตุ ไม่ต้องฝืนเพราะ release ใหม่ดูดีใน changelog

4) Caveat ที่ควรรู้

บทความนี้ไม่ได้บอกว่า vLLM 0.25.0 มีปัญหา

ตรงกันข้าม release นี้ดูเป็น release ใหญ่ที่มีงานเยอะมาก ทั้ง performance, backend, model support และ security fixes

แต่ยิ่ง release มีผลกับ core runtime มากเท่าไร ทีมที่ใช้ในงานจริงยิ่งควรทดสอบแบบมีหลักฐานมากขึ้นเท่านั้น

อีกจุดคือถ้าคุณใช้ managed API อย่างเดียว คุณอาจไม่ได้แตะ vLLM โดยตรง แต่บทเรียนยังเหมือนเดิม: เมื่อ engine ใต้ระบบ AI เปลี่ยน อย่าวัดแค่ความเร็ว ให้วัดความถูกต้องของ workflow, output contract และ rollback path ด้วย

5) เริ่มลองวันนี้

ถ้าคุณมีทีมเล็กและอยากเริ่มแบบไม่หนักเกินไป วันนี้ทำ 3 อย่างพอ:

1. จดว่าระบบไหนในบริษัทเรียก LLM ผ่าน vLLM หรือ inference server ภายใน
2. เลือก workload เดียวที่เสี่ยงต่ำและมี metric ชัด
3. ทำ Canary Test Card ด้านบนให้ครบก่อนอัปเกรดจริง

AI infra ที่ดีไม่ใช่ infra ที่วิ่งตาม release เร็วที่สุด

แต่คือ infra ที่อัปเกรดแล้วรู้ว่าอะไรดีขึ้น อะไรเสี่ยงขึ้น และถ้าผิดทางจะถอยกลับอย่างไร

Data-Espresso จะช่วยย่อยข่าว AI แบบนี้ให้เป็น workflow, checklist และ playbook ที่ทีมเอาไปลองใช้ได้จริง ไม่ใช่แค่อ่านแล้วรู้ว่ามี release ใหม่ครับ