vLLM ปล่อย AFD Plugin — แยก Attention กับ FFN ออกจากกันเพื่อเสิร์ฟโมเดล MoE ใหญ่ ๆ ให้คุ้มการ์ดขึ้น

ยุคที่โมเดลเปิดน้ำหนักตัวเก่ง ๆ เป็น MoE ขนาดหลายร้อย B ถึงหลายล้านล้านพารามิเตอร์ (DeepSeek, GLM, Kimi K3) ปัญหาไม่ได้อยู่ที่ “หาโมเดลมารัน” อีกต่อไป แต่อยู่ที่ “จะเสิร์ฟมันยังไงให้คุ้มการ์ด” — และวันที่ 23 ก.ค. 2026 ทีม vLLM ก็ปล่อยคำตอบใหม่ออกมาเป็นปลั๊กอินทดลองชื่อ AFD (Attention-FFN Disaggregation) ที่แยกสองส่วนหลักของโมเดลออกจากกันไปรันเป็นบริการคนละก้อน แล้วสเกลอิสระต่อกัน

ทำไมต้องแยก Attention ออกจาก FFN

หัวใจของไอเดียคือ สองส่วนนี้มีคอขวดคนละแบบ จึงไม่ควรถูกบังคับให้ใช้ฮาร์ดแวร์ก้อนเดียวกันในอัตราส่วนตายตัว:

• Attention เป็นงานที่ผูกกับ สถานะของแต่ละ request — คิว, ความยาว sequence และแรงกดบน KV cache มันคือส่วนที่ติดแบนด์วิดท์หน่วยความจำ (memory-bound)
• FFN / Experts คือการคำนวณ expert ที่ถูก route มา บวกการสื่อสารแบบ all-to-all ระหว่าง GPU — มันคือส่วนที่ติด compute และการสื่อสาร

ในดีพลอยแบบรวมก้อน (เช่น Expert Parallel ล้วน ๆ) เราปรับสองอย่างนี้แยกกันไม่ได้ — เพิ่มการ์ดเพื่อ attention ก็ต้องลาก expert มาด้วย AFD ทำให้ “ฝั่ง Attention” ขยายตามจำนวน request/ความยาวคอนเท็กซ์ ส่วน “ฝั่ง Experts” ขยายตาม load ของการ route ได้อิสระ จับคู่ทรัพยากรให้ตรงกับคอขวดจริง

ตัวเลขจริงบน DeepSeek-V3.2

vLLM รายงานผลบน DeepSeek-V3.2 (สถาปัตยกรรมที่ปลั๊กอินรองรับคือตระกูล DeepSeek V2/V3 และ GLM MoE DSA):

• อินพุต 16K: โครงสร้าง 64A16F (attention 64 / FFN 16) ทำได้ 258.9 tokens/s ต่อ die — เพิ่มขึ้น 11.3% เทียบ baseline EP64
• อินพุต 32K: 64A16F ทำได้ 183.3 tokens/s ต่อ die — เพิ่มขึ้น 9.0%
• Async prefill: ที่โหลด 12 request/วินาที ลด TTFT (เวลาได้โทเคนแรก) จาก 15.1 เหลือ 8.0 วินาที — ดีขึ้น ~47%

จุดที่นักพัฒนาสายอินฟราควรสนใจคือมันไม่ได้ผูกกับ NVIDIA อย่างเดียว — ปลั๊กอินมี connector ทั้งฝั่ง NVIDIA GPU (P2pNcclAFDConnector) และ Ascend NPU (CAMP2pAFDConnector, CAMAsyncAFDConnector) สะท้อนแรงกดดันเรื่องการรันบนฮาร์ดแวร์นอกค่าย NVIDIA

ใช้งานยังไง

AFD มาในรูป ปลั๊กอินภายนอกแบบทดลอง ไม่ใช่ฟีเจอร์ใน core — ต้องการ Python 3.10–3.13 และเล็งไปที่ vLLM 0.19.1 ติดตั้งจาก repo แล้วดีพลอยด้วย vllm serve โดยส่งค่าโครงสร้าง AFD ผ่าน --additional-config ที่สำคัญคือ endpoint ยังเป็น OpenAI-compatible เหมือนเดิม — โค้ดฝั่ง client ที่ยิงเข้า vLLM อยู่แล้วไม่ต้องแก้ เปลี่ยนแค่วิธีดีพลอยหลังบ้าน (เพราะยังเป็นของทดลอง ควรทดสอบบน staging ก่อนขึ้น production และล็อกเวอร์ชันให้ตรง)

มุมมอง AI Curator

AFD เป็นตัวอย่างที่ดีของเทรนด์ที่เงียบแต่สำคัญ: สนามแข่ง AI กำลังย้ายจาก “ใครเทรนโมเดลเก่งกว่า” ไปสู่ “ใครเสิร์ฟโมเดลเปิดตัวเดียวกันได้ถูกกว่า” เมื่อ DeepSeek, GLM, Kimi เปิดน้ำหนักให้ทุกคนเท่ากัน ความได้เปรียบจึงย้ายไปอยู่ที่ชั้น inference — และเทคนิคอย่าง disaggregation, prefill/decode split, MXFP4, speculative decoding คือที่ที่ต้นทุนต่อโทเคนถูกบีบลงจริง ๆ ตัวเลข +9–11% throughput อาจฟังดูไม่หวือหวา แต่ในสเกลที่รันการ์ดหลายร้อยใบ 24 ชั่วโมง มันคือค่าไฟและค่าเช่า GPU ที่ต่างกันเป็นเงินก้อนโต

สำหรับทีมไทย/อาเซียนที่คิดจะ self-host โมเดลเปิดใหญ่ ๆ แทนการจ่าย API ต่างชาติ บทเรียนคือ “ดาวน์โหลดโมเดลมาได้ฟรี” ไม่เท่ากับ “รันได้คุ้ม” — ความรู้เรื่อง serving stack (vLLM, SGLang, TensorRT-LLM) และเทคนิคแบบ AFD คือสิ่งที่แยกระหว่างองค์กรที่ self-host แล้วประหยัดจริง กับองค์กรที่ self-host แล้วเผาการ์ดทิ้งเพราะ utilization ต่ำ การที่ vLLM รองรับ Ascend NPU มาด้วยตั้งแต่ต้นก็เป็นสัญญาณที่อาเซียนควรจับตา ในวันที่การเข้าถึง GPU ตะวันตกยังเป็นข้อจำกัดเชิงภูมิรัฐศาสตร์

แหล่งข่าว:

• Announcing vLLM AFD Plugin: Disaggregating Attention and FFN for Flexible MoE Serving — vLLM Blog
• [RFC]: ATTN-FFN Disaggregation for MoE Models — vLLM GitHub Issue #22799
• vLLM Blog