FreeToken: เสิร์ฟ GLM-5.2 ขนาด 753B บนการ์ดจอใบเดียวได้ 14.9 tok/s เร็วกว่า llama.cpp เท่าตัว — เพราะเลิกตัดสินใจล่วงหน้าว่าอะไรอยู่บน GPU

น้ำหนักโมเดลระดับแนวหน้าเปิดให้โหลดกันเกือบหมดแล้ว แต่การ รัน มันยังคงตั้งอยู่บนสมมติฐานว่าคุณมีดาต้าเซ็นเตอร์ เปเปอร์ชื่อ FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution ที่ขึ้น arXiv เมื่อ 17 ส.ค. 2026 พยายามลบสมมติฐานนั้นทิ้ง และรายชื่อผู้เขียนก็บอกได้ว่าเรื่องนี้ไม่ใช่งานเล่น ๆ — Shuo Yang, Xiaoze Fan (ร่วมกันเป็นผู้เขียนหลัก), Melissa Pan, Haocheng Xi, Kurt Keutzer, Song Han, Matei Zaharia และ Ion Stoica รวม 11 คน โดย Chenfeng Xu กับ Ion Stoica เป็นที่ปรึกษาร่วม (เปเปอร์ไม่ได้พิมพ์สังกัดไว้ แต่เป็นชื่อชุดที่คุ้นจากฝั่ง UC Berkeley และ MIT)

ตัวเลขที่เป็นพาดหัวคือ: เวิร์กสเตชันที่มีการ์ดจอ RTX PRO 6000 ใบเดียว เสิร์ฟ GLM-5.2 ขนาด 753B ได้ที่ 14.9 tok/s เทียบกับ llama.cpp ที่ทำได้ 7.3 tok/s บนเครื่องเดียวกันและน้ำหนักชุดเดียวกันแบบตรงบิต — เร็วขึ้น 2 เท่าพอดี ส่วนฝั่งล่างสุดของสเปกตรัม โน้ตบุ๊ก RTX 4060 VRAM 8 GB รันโมเดล 35B ได้ 39.3 tok/s ซึ่งเร็วกว่าความเร็วถอดรหัสมัธยฐานของ Codex ในทราฟฟิกจริง (33 tok/s) โค้ดปล่อยแล้วภายใต้ Apache-2.0 ที่ github.com/FlashML-org/FreeToken (ปัจจุบัน 2.7k ดาว) และขึ้น PyPI เป็น freetoken v0.1.2 เมื่อ 19 ส.ค.

หมายเหตุความสัตย์จริงก่อนไปต่อ: นี่เป็นข่าวที่เราตามเก็บย้อนหลัง เปเปอร์ลง 17 ส.ค. รีลีส 19 ส.ค. ไม่ใช่ของที่เพิ่งประกาศวันนี้ แต่มันเพิ่งมาติดกระแสในสัปดาห์นี้ และเป็นชิ้นที่นักพัฒนาสาย local LLM ควรรู้

ปัญหาที่แท้จริงไม่ใช่ VRAM ไม่พอ แต่คือ “ตัดสินใจตอนโหลด แล้วไม่แก้อีกเลย”

สถาปัตยกรรม MoE เหมาะกับการรันบนเครื่องส่วนตัวโดยธรรมชาติ เพราะแต่ละโทเคนวิ่งผ่าน expert แค่ไม่กี่ตัวจากทั้งหมด — DeepSeek-V4-Flash มี 284B พารามิเตอร์แต่แอ็กทีฟจริงแค่ 13B (เปิด 6 จาก 256 routed experts ใน 43 เลเยอร์) ปัญหาคือ ความเบาบางลดการคำนวณต่อโทเคน แต่ไม่ได้ลดหน่วยความจำที่ต้องใช้เก็บ expert ทั้งกอง

เปเปอร์ชี้จุดตายของเอ็นจิ้นเดิมไว้สามข้อ และข้อแรกคือใจกลาง:

หนึ่ง — วาง expert แบบตายตัว llama.cpp กำหนดว่า tensor ไหนอยู่อุปกรณ์ไหนตั้งแต่ตอนโหลดโมเดล ส่วน KTransformers ปักหมุด expert ชุด “ร้อน” ไว้ใน VRAM แล้วโยนที่เหลือให้ CPU แต่ routing เปลี่ยนทุกโทเคนและเปลี่ยนตามงาน การวางที่แช่แข็งไว้ตั้งแต่ต้นจึงจับทราฟฟิกจริงได้แค่ส่วนน้อย ผลคืองานประเมิน expert ส่วนใหญ่ตกไปที่ CPU ทำให้ ทั้ง GPU และสาย PCIe ว่างงานไปพร้อมกัน (ตัวเลขในเปเปอร์: FreeToken จับ locality ได้ 89% ในจุดที่ llama.cpp วางแบบไม่ดู routing)

สอง — CPU แบกงานถอดรหัสคนเดียวไม่ไหว เครื่องคอนซูเมอร์ต่อ RAM แค่สองแชนเนล ได้แบนด์วิดท์ราว 50 GB/s บน DDR4 และ 80–90 GB/s บน DDR5 เทียบกับ 1–1.8 TB/s ที่ RTX 4090/5090 ดึงจาก VRAM ตัวเอง — ต่างกันยี่สิบเท่า จะมีกี่คอร์ก็ไม่ช่วย

สาม — สัดส่วนที่ถูกต้องขึ้นกับเครื่องแต่ละเครื่อง เมื่อ expert ตัวหนึ่ง “มิส” คุณเลือกได้สองทาง: ส่งน้ำหนักข้าม PCIe ไปรันบน GPU หรือรันบน CPU ตรงที่น้ำหนักมันอยู่ ไม่มีทางไหนดีกว่าเสมอ โน้ตบุ๊ก RTX 4060 บน LPDDR5 กับเดสก์ท็อป RTX 5090 บน DDR5 อยู่คนละขั้วของสมดุล host-to-PCIe และ อ่านคำตอบจากสเปกชีตไม่ได้ — ต้องวัดบนเครื่องจริง

FreeToken จึงไม่เลือกกลยุทธ์ offload ล่วงหน้าเลย แต่ วัดแบนด์วิดท์จริงของเครื่องแล้วแมปงานกับสถานะโมเดลลงบนทรัพยากรที่มีอยู่จริงอย่างต่อเนื่อง — ตั้งแต่ layout ตอนโหลด, ที่พำนักของ expert, การแบ่งงาน CPU–GPU, การใช้ซ้ำของ state ฝั่งเอเจนต์ ไปจนถึงการจัดการหน่วยความจำระหว่างรัน

ตัวเลขที่ควรอ่าน: TTFT สำคัญกว่า tok/s สำหรับงานเอเจนต์

ผู้เขียนทดสอบบนเครื่อง 6 แบบ (RTX 3090/4090/5090/5090 desktop/4060 laptop/PRO 6000) กับเวิร์กโหลดเอเจนต์จริง 4 แบบ ได้แก่ AIME (คิดยาว ไม่เรียกทูล), coding agent (OpenCode+SWE), Claude Code+SWE และ OpenClaw+อีเมล/ปฏิทิน โดยเทียบกับ llama.cpp, Ollama, KTransformers และ MoE-Infinity

บน RTX 5090: FreeToken ทำได้ 77–83 tok/s บน Qwen3.6-35B-A3B และ 22–25 tok/s บน DeepSeek-V4-Flash 284B คิดเป็น 1.8–2.3 เท่า ของคู่แข่งที่แข็งที่สุด

แต่ตัวเลขที่ผมคิดว่าสำคัญกว่าคือ TTFT ที่หางการกระจาย — FreeToken คุม TTFT กรณีแย่สุดไว้ ต่ำกว่า 44 วินาที ในทุกเวิร์กโหลด ขณะที่ทุกเบสไลน์เกิน 150 วินาทีอย่างน้อยหนึ่งกรณี: llama.cpp 232 วินาที, Ollama 179 วินาที, KTransformers 946 วินาที เหตุผลที่เรื่องนี้สำคัญ เปเปอร์เขียนไว้ตรง ๆ ว่า request timeout ปริยายของ Claude Code อยู่ราวสิบนาที — TTFT หางยาวจึงไม่ใช่แค่ “ช้าหน่อย” แต่คือเส้นแบ่งว่าเอเจนต์จะทำงานจบหรือตายกลางทาง

สาเหตุที่ TTFT พังในงานเอเจนต์คือ ทุก tool call บังคับให้ re-prefill บริบทที่ยาวขึ้นเรื่อย ๆ และการ์ดคอนซูเมอร์ซ่อนต้นทุนนี้ไม่ได้ FreeToken จึงออกแบบการใช้ซ้ำของ state ข้ามเทิร์นมาโดยเฉพาะ ไม่ใช่แค่ปรับ throughput

อีกจุดที่ตัวเลขเล่าเรื่องได้ดี: RTX 5090 สองคอลัมน์ในเปเปอร์ใช้ชิปตัวเดียวกัน ต่างกันแค่ฝั่ง host — ย้ายจากเซิร์ฟเวอร์หลายแชนเนลไปเดสก์ท็อป DDR5 สองแชนเนล FreeToken เสียความเร็วไป 4% ส่วน llama.cpp เหลือ 80% เพราะ expert ที่อยู่ฝั่ง CPU อดแบนด์วิดท์

ทำให้ 753B ลงเครื่องเดียวได้จริงแค่ไหน

ต้องอ่านสเปกให้ครบก่อนตื่นเต้น เครื่อง “frontier tier” ในเปเปอร์คือ RTX PRO 6000 (VRAM 96 GB) + Xeon Platinum 8559C 48 เธรด + DDR5 512 GiB ส่วน GLM-5.2 ที่รันคือเช็กพอยต์ NVFP4 ขนาด 433 GB (753B พารามิเตอร์ แอ็กทีฟ 40B) — นี่ไม่ใช่พีซีเล่นเกม แต่เป็นเวิร์กสเตชันตัวเดียวที่ซื้อได้จริง ไม่ต้องเช่าคลัสเตอร์

ที่น่าสนใจคือ KTransformers ไม่มีทางรันโมเดลนี้บนเครื่องนี้เลย เพราะวิธีของมันต้องการ expert ฝั่ง host 753 GB–1.5 TB ซึ่งเกิน RAM 512 GiB ที่มี ส่วน Kimi-K3 นั้นเปิดน้ำหนักก็จริงแต่ 594 GB เกินเพดานหน่วยความจำคอนซูเมอร์ — เปเปอร์จึงไม่แตะ

รายการที่รองรับตอนนี้คือโมเดล MoE มากกว่า 20 ตัว ครอบคลุม DeepSeek-V4-Flash, Qwen3.6-35B-A3B และ GLM-5.2 ในรูปแบบ MXFP4, NVFP4, FP8 และ BF16 บน NVIDIA RTX ซีรีส์ 30/40/50 ติดตั้งด้วย uv pip install "freetoken[accel]" หรือโหลดแอปเดสก์ท็อป Windows/Linux จาก flashml.ai — โดยยังเป็น v0.1.2 อายุสี่วัน มี issue เปิดค้าง 80 รายการ ซึ่งเป็นระดับความสุกที่ควรคาดหวังจากเลขเวอร์ชันนั้น

มุมมอง AI Curator

สิ่งที่ผมชอบในงานนี้ไม่ใช่ตัวเลข 753B แต่คือ จุดยืนทางวิศวกรรมที่เถียงกับ llama.cpp ตรง ๆ ว่าการวางแผนล่วงหน้าเป็นความผิดพลาดเชิงออกแบบ ไม่ใช่แค่ยังจูนไม่ดีพอ เอ็นจิ้นรุ่นเดิมทุกตัวถามคำถามว่า “อะไรควรอยู่บน GPU” แล้วตอบครั้งเดียวตอนโหลด FreeToken บอกว่าคำถามนี้ ไม่มีคำตอบคงที่ เพราะ routing เปลี่ยนทุกโทเคน เบราว์เซอร์แย่ง VRAM ตอนไหนก็ได้ และ KV cache โตขึ้นทุกเทิร์นของเอเจนต์ขณะที่ working set ของ expert แทบไม่ขยับ

เรื่องนี้ต่อกับโพสต์เมื่อเช้าเรื่อง logit ของโมเดลที่รันเอง ได้พอดี วันนี้ blog เดียวกันมีสองข่าวที่พูดเรื่อง local inference จากคนละมุม: อันหนึ่งบอกว่าการตั้งค่าที่ต่างกันทำให้ คำตอบ เปลี่ยน อีกอันบอกว่าการตั้งค่าที่ต่างกันทำให้ ความเร็ว ต่างกันสองเท่า รวมกันแล้วข้อสรุปคือ วงการ local LLM กำลังผ่านจากยุค “รันได้ไหม” ไปสู่ยุค “รันถูกวิธีหรือเปล่า” — และช่องว่างระหว่างสองอย่างนี้ตอนนี้กว้างพอที่จะทำให้คนสรุปผิดว่าโมเดลโอเพนไม่เก่งจริง

สำหรับบริบทไทยและ SEA ผมคิดว่า นี่คือชิ้นส่วนที่ขาดในสมการต้นทุน ทีมไทยจำนวนมากที่อยากใช้โมเดลโอเพนด้วยเหตุผลเรื่อง PDPA หรือข้อมูลที่ห้ามออกนอกองค์กร ติดอยู่ที่ทางเลือกสองทางที่แย่พอกัน: เช่า GPU คลาวด์ต่างประเทศ (ซึ่งย้อนแย้งกับเหตุผลที่เลือกโมเดลโอเพนตั้งแต่แรก) หรือรันบนเครื่องในองค์กรแล้วได้ความเร็วที่ผู้ใช้ทนไม่ไหว งานชิ้นนี้ทำให้ทางเลือกที่สองมีน้ำหนักขึ้นชัดเจน — เวิร์กสเตชันตัวเดียวราคาระดับที่ฝ่ายไอทีอนุมัติได้ เสิร์ฟโมเดล 753B ที่ความเร็วพอใช้งานเอเจนต์ คือข้อเสนอที่ต่างจาก “ต้องมี 8×H200” คนละโลก

แต่มีข้อควรระวังสองข้อ ข้อแรก ตัวเลขทั้งหมดมาจากผู้เขียนเอง ยังไม่มีการทำซ้ำอิสระ และเบสไลน์ llama.cpp/Ollama ถูกตั้งค่าโดยทีมที่มีแรงจูงใจให้ตัวเองชนะ — ใครจะใช้จริงควรวัดบนเครื่องตัวเองก่อนเชื่อ ข้อสอง v0.1.2 คือ v0.1.2 ระยะห่างระหว่างเปเปอร์ที่วัดได้สวยกับซอฟต์แวร์ที่รันในองค์กรได้ทุกวันมักยาวกว่าที่คิด llama.cpp ชนะใจคนไม่ได้เพราะเร็วที่สุด แต่เพราะมันไม่พังและพอร์ตไปได้ทุกที่

สิ่งที่ผมจะจับตาคือ แนวคิดนี้จะไหลกลับเข้า llama.cpp หรือไม่ เพราะข้อค้นพบหลัก — ว่าการแบ่งงานที่ถูกต้องต้องวัดบนเครื่องจริงตอนรัน ไม่ใช่กำหนดตอนโหลด — เป็นข้อค้นพบที่นำไปใช้ได้โดยไม่ต้องเปลี่ยนเอ็นจิ้น ถ้าปีนี้ llama.cpp เพิ่มการวัดแบนด์วิดท์อัตโนมัติแล้วปรับ -ot ให้เอง คนได้ประโยชน์จะเยอะกว่าโครงการใหม่ที่มีดาว 2.7k หลายเท่า และนั่นน่าจะเป็นบทสรุปที่ดีที่สุดของงานวิจัยแบบนี้

แหล่งข่าว

• FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution — arXiv:2608.16157, ส่ง 17 ส.ค. 2026
• FlashML-org/FreeToken — ซอร์สโค้ด Apache-2.0, v0.1.2 (19 ส.ค. 2026)
• freetoken บน PyPI — แพ็กเกจติดตั้ง
• Meet FreeToken: An Edge-Native MoE Serving Engine — MarkTechPost, 23 ส.ค. 2026