Hugging Face + vLLM: แบ็กเอนด์ transformers วิ่งเร็วเท่าโค้ดที่เขียนมือแล้ว — เสิร์ฟโมเดลไหนก็ได้บน vLLM ด้วยแฟล็กเดียว

8 กรกฎาคม 2026 — Hugging Face เผยแพร่โพสต์ “Native-speed vLLM transformers modeling backend” ประกาศสิ่งที่คนรันโมเดลเองรอมานาน: แบ็กเอนด์ transformers ใน vLLM ทำ throughput ได้เท่าหรือดีกว่าอิมพลิเมนต์ที่ทีม vLLM เขียนด้วยมือ สำหรับสถาปัตยกรรม LLM จำนวนมาก

เพื่อให้เห็นภาพว่าทำไมนี่ถึงสำคัญ ต้องเข้าใจการแลกเปลี่ยนแบบเดิมก่อน: vLLM เร็วเพราะทีมงานเขียนโค้ดโมเดลใหม่ด้วยมือให้เข้ากับเอนจิน — แต่นั่นแปลว่า โมเดลใหม่ที่เพิ่งออกต้องรอคิวจนกว่าจะมีคนเขียนโค้ดรองรับ ส่วนแบ็กเอนด์ transformers รองรับทุกโมเดลบน Hub ทันทีตั้งแต่วันแรก แต่แลกมาด้วยความเร็วที่ช้ากว่า นักพัฒนาจึงต้องเลือกระหว่าง “รองรับทันที” กับ “เร็ว” มาตลอด

การแลกเปลี่ยนนั้นเพิ่งหายไป

ทำได้อย่างไร: dynamic layer fusion

หัวใจของการอัปเดตนี้คือ dynamic layer fusion ตอนรันไทม์ — ระบบใช้ torch.fx วิเคราะห์กราฟแบบ static ร่วมกับการแปลง AST เพื่อรวม (fuse) โอเปอเรชันเข้าด้วยกันโดยอัตโนมัติ

พูดง่าย ๆ คือ แทนที่จะให้มนุษย์มานั่งเขียนเคอร์เนลที่ fuse ไว้ล่วงหน้าสำหรับแต่ละสถาปัตยกรรม ระบบจะ อ่านโค้ดโมเดล transformers ธรรมดา แล้วปรับโครงสร้างให้เองตอนโหลด ผลคือได้ประสิทธิภาพระดับที่เคยต้องเขียนมือ โดยผู้เขียนโมเดลไม่ต้องแตะอะไรเลย

ตัวเลขการทดสอบ

ทีมงานวัดผลกับโมเดลตระกูล Qwen3 สามขนาด ครอบคลุมโหมดการขนานที่ต่างกัน:

โมเดล	การตั้งค่า
Qwen3 4B (dense)	GPU ตัวเดียว
Qwen3 32B (dense)	tensor parallelism
Qwen3 235B FP8 (MoE)	data + expert parallelism บน H100 จำนวน 8 ใบ

ทั้งสามกรณี แบ็กเอนด์ transformers “เท่าหรือชนะ” (meets or beats) throughput ของอิมพลิเมนต์ native ใน vLLM — รวมถึงเคสที่ยากที่สุดอย่าง MoE ขนาด 235B แบบ FP8 ที่ต้องกระจายทั้งข้อมูลและ expert

ใช้งานจริงอย่างไร

เปิดใช้ด้วยแฟล็กเดียว:

vllm serve <model-id> --model-impl transformers

สิ่งที่ได้ตามมา:

• เสิร์ฟโมเดลบน Hub ตัวไหนก็ได้ รวมถึงโมเดลคัสตอมและโมเดลที่ยังไม่มีใครเขียนโค้ดรองรับใน vLLM
• ผู้เขียนโมเดลไม่ต้องดูแลโค้ดสองชุด — เขียนใน transformers ชุดเดียว ได้ความเร็วระดับโปรดักชันฟรี
• โมเดลใหม่ใช้งานได้ตั้งแต่วันแรก ไม่ต้องรอ PR รองรับ

โพสต์นี้เขียนร่วมกันโดยผู้มีส่วนร่วมกว่า 18 คนจากทั้งฝั่ง Hugging Face และโปรเจกต์ vLLM

มุมมอง AI Curator

ข่าวนี้ดูเป็นเรื่องเทคนิคแห้ง ๆ แต่ผลกระทบเชิงระบบนิเวศใหญ่กว่าที่เห็น สิ่งที่หายไปคือ “ภาษีของการเป็นโมเดลใหม่” — ที่ผ่านมา สถาปัตยกรรมแปลกใหม่ต้องแบกต้นทุนแฝง: ต่อให้โมเดลคุณดีแค่ไหน ถ้าไม่มีคนเขียนโค้ดรองรับใน vLLM คนก็เสิร์ฟมันในโปรดักชันไม่ได้ ผลลัพธ์คือ แรงจูงใจเงียบ ๆ ที่ผลักให้ทุกคนออกแบบโมเดลให้เหมือน Llama เพราะสถาปัตยกรรมที่คุ้นเคยเท่านั้นที่จะได้เคอร์เนลเร็ว ๆ เมื่อ dynamic fusion ทำงานได้กับโค้ด transformers ทั่วไป ค่าใช้จ่ายของการทดลองสถาปัตยกรรมใหม่ก็ลดลง — และนั่นดีต่อความหลากหลายของโมเดลในระยะยาว

อีกมุมที่คนมองข้าม: นี่เป็น การรวมศูนย์ที่ชาญฉลาด ของ Hugging Face โดยการทำให้ transformers เป็น “รูปแบบอ้างอิง” ที่เร็วพอสำหรับโปรดักชัน HF ก็ยิ่งตอกย้ำตำแหน่งของตัวเองในฐานะชั้นมาตรฐานที่ทุกคนต้องผ่าน — เขียนโมเดลลง transformers แล้วทุกเอนจินได้ประโยชน์ ในเชิงกลยุทธ์นี่คือการเปลี่ยนจาก “ไลบรารีที่คนใช้ตอนวิจัย” เป็น “รันไทม์มาตรฐานที่คนใช้ตอนเสิร์ฟ” — ตำแหน่งที่มีอำนาจกว่ามาก

สำหรับทีมไทยและอาเซียนที่รันโมเดลเอง (ไม่ว่าจะเพราะ PDPA, ต้นทุน, หรือ latency) ประโยชน์ตรงและใช้ได้ทันที: โมเดลไทยหรือโมเดลที่ fine-tune เองด้วยสถาปัตยกรรมนอกกระแส — Typhoon, SEA-LION, OpenThaiGPT หรือโมเดลที่คุณดัดแปลงเอง — ตอนนี้เสิร์ฟบน vLLM ได้ด้วยความเร็วเต็มที่โดยไม่ต้องรอใคร สิ่งที่เคยเป็นข้ออ้างว่า “โมเดลท้องถิ่นเสิร์ฟยาก เลยต้องใช้ API ต่างชาติ” อ่อนแรงลงไปอีกหนึ่งข้อ ข้อควรระวังตามปกติ: ตัวเลขที่รายงานมาจากทีมผู้พัฒนาเองและวัดบน Qwen3 เป็นหลัก — ก่อนย้ายโปรดักชันควรวัด throughput และ latency กับโมเดลและ workload จริงของคุณเสมอ

แหล่งข่าว

• Native-speed vLLM transformers modeling backend — Hugging Face Blog
• Transformers as modeling backend — Hugging Face Docs
• Transformers modeling backend integration in vLLM — vLLM Blog