llama.cpp b11195 เพิ่ม tiled mul_mat บน CPU — prompt processing ของโมเดล 27B แบบ k-quant เร็วขึ้น 1.9–3.5 เท่าบน x86 แต่ MoE ได้น้อยกว่ามาก และ ARM ยังไม่รองรับ

สองวันหลัง llama.cpp 0.5.0 และ Vulkan int8 สำหรับ AMD มีอีก PR ที่คนรันโมเดลบน CPU ล้วน ควรรู้ PR #27851 “ggml-cpu: tiled mul_mat for k-quants” ของ jbooth (+3,050/−1,326 บรรทัด) ถูก merge เมื่อ 26 ก.ย. 05:38 UTC และอยู่ใน nightly b11195 (08:27 UTC) เป็นต้นไป ยังไม่อยู่ในแท็ก semver ใด ๆ

เปลี่ยนอะไร

ผู้เขียนสังเกตว่า matmul บน CPU แบบเดิม (อิง vec_dot) ต้อง unpack ควอนต์ซ้ำหลายรอบ จึงเขียนใหม่ให้ unpack น้ำหนักเป็นไทล์ int8 ขนาด 256×256 ครั้งเดียว (ลดงาน unpack ลง 256 เท่าเมื่อเทียบกับเดิม) แล้วใช้ microkernel ขนาดเล็กคำนวณซ้ำบนไทล์นั้น ถ้างานน้อยเกินไปจนแบ่งให้ทุกคอร์ไม่พอ ระบบจะลดขนาด chunk เป็น 128, 64 ตามลำดับ

เส้นทางนี้เปิดใช้เฉพาะเมื่อ batch สูงพอ คือช่วง prefill / prompt processing ถ้าแถวน้อยกว่า 64 จะถอยไปใช้ทางเดิม เพราะช่วง generate ทีละโทเคน (GEMV) แบบ tiled ช้ากว่าเดิม คำอธิบายเริ่มต้นของ PR ระบุว่าที่ GEMV ล้วนเหลือราว 80% ของความเร็วเดิม

ตัวเลขที่ควรดู

ตัวเลข “3-7x” ในหัว PR มาจาก microbenchmark ขนาด 8192×8192 บน Ryzen 9950X3D ที่มี AVX-512 VNNI ตัวเลขที่ใกล้งานจริงกว่าคือผลของ bartowski (ผู้ทำ GGUF รายใหญ่ ซึ่งร่วมรีวิว PR) ที่วัด prompt eval ของโมเดลจริงก่อน merge:

โมเดล (ubatch 512)	stock t/s	tiled t/s	เร็วขึ้น
27B Q2_K	49.73	94.49	1.90x
27B Q3_K	34.41	99.48	2.89x
27B Q4_K	42.98	105.90	2.46x (1.47x เทียบ CPU repack เดิม)
27B Q5_K	30.32	105.93	3.49x
27B Q6_K	42.82	95.61	2.23x
35B-A3B Q4_K (MoE)	233.09	285.71	1.23x (≈ เท่า repack)
35B-A3B Q5_K (MoE)	190.25	291.90	1.53x

ข้อสังเกต:

• โมเดล dense ได้ประโยชน์มาก ส่วน MoE ได้น้อย เพราะ MoE แต่ละ expert ได้โทเคนไม่กี่ตัวต่อ batch จึงคล้าย GEMV มากกว่า
• Q5_K และ Q3_K ได้มากที่สุด เพราะเดิมไม่มี kernel repack บน x86 ส่วน Q4_K ซึ่งมี repack อยู่แล้วได้เพิ่มน้อยกว่า
• ที่ ubatch 8 หลายแบบช้าลง (Q6_K บน 27B เหลือ 0.72x) คนที่ตั้ง ubatch ต่ำเพื่อลด latency ควรวัดเอง
• perplexity เปลี่ยนไม่เกินราว ±1% ในทุกแถว ส่วนใหญ่อยู่ในระดับ 0.0x–0.2%
• CPU ที่มีแค่ AVX2 ได้น้อยกว่ามาก ผู้เขียนรายงานในเธรดว่าได้ราว 1.6 เท่าบน llama-bench prompt 2048 ในช่วงหนึ่งของ PR และหลังปรับจูน “even/profitable” แทบทุกแบบ ยกเว้น iq4_xs ที่ช้ากว่า IQP ราว 10% ผู้ใช้ i5 รุ่นเก่ารายหนึ่งรายงานว่าช้าลงเล็กน้อยก่อนการปรับจูน
• ARM (รวม Apple Silicon) ยังไม่รองรับ ผู้เขียนออกแบบให้เพิ่มสถาปัตยกรรมใหม่ได้โดยเขียนแค่ microkernel กับฟังก์ชัน unpack และระบุว่าเป็นงานถัดไป

ผู้เขียนเปิดเผยว่าใช้ AI เขียนฟังก์ชัน unpack กับ microkernel หลังจากเขียนโครงหลักเองแล้ว

มุมมอง AI Curator

ในไทย เซิร์ฟเวอร์ที่ไม่มี GPU ยังเป็นเครื่องส่วนใหญ่ในองค์กรและหน่วยงานรัฐ ทั้ง VM บนคลาวด์ในประเทศและเครื่อง on-prem ที่มี Xeon หรือ EPYC รุ่นใหม่ ซึ่ง มี AVX-512 VNNI อยู่แล้ว การที่ prompt processing ของโมเดล 27B แบบ dense เร็วขึ้นสองถึงสามเท่าโดยไม่ต้องซื้ออุปกรณ์ใหม่ ทำให้ RAG กับเอกสารยาวบน CPU ล้วนใช้งานได้จริงขึ้นมาก เพราะคอขวดของงานแบบนี้คือการอ่าน context ไม่ใช่การพิมพ์คำตอบ

แต่ต้องอ่านตัวเลขอย่างระวัง ตัวเลข “3-7x” เป็น microbenchmark ขณะที่งานจริงบนโมเดล 27B ได้ 1.9–3.5x และบน MoE ซึ่งเป็นโมเดลที่คนนิยมรันบน CPU เพราะ active parameter น้อย ได้แค่ 1.1–1.5x ความเร็วตอนตอบ (token generation) ไม่ได้เพิ่ม สำหรับคนที่ใช้ Mac หรือเครื่อง ARM ยังต้องรอ ข้อแนะนำคือถ้าเซิร์ฟเวอร์ของคุณเป็น x86 รุ่นใหม่และใช้โมเดล dense ควอนต์ Q3_K–Q6_K ให้ลอง nightly b11195 ขึ้นไป วัด llama-bench บนโมเดลของตัวเอง แล้วตัดสินใจจากตัวเลขนั้น

แหล่งข่าว

• PR #27851: ggml-cpu: tiled mul_mat for k-quants — ggml-org/llama.cpp
• Nightly build b11195 (26 ก.ย. 2026)