llama.cpp 0.5.0 ออกแล้ว + Vulkan int8 สำหรับ AMD RDNA3/4 — prompt processing บน Strix Halo เร็วขึ้นสูงสุด 1.36 เท่า แต่ต้องใช้ build b11160 ขึ้นไป ไม่ได้อยู่ใน 0.5.0

llama.cpp ปล่อย v0.5.0 เมื่อ 23 กันยายน 2026 เวลา 20:50 UTC ห่างจาก v0.4.0 ที่เราเขียนถึง ไม่ถึงสามสัปดาห์ บันทึกรีลีสบอกว่ารอบนี้ “focuses on backend performance and correctness, broader model coverage, and more robust server/router operation” ของใหม่ที่คนรัน llama-server จะได้ใช้ทันทีคือ --host ที่ผูกได้หลายแอดเดรสพร้อมกัน, function call ที่ส่งภาพกลับเข้าโมเดลได้ และ environment variable สำหรับค่า sampler

แต่ข่าวที่เจ้าของเครื่อง AMD น่าจะสนใจที่สุดมาหลังรีลีสหนึ่งวัน PR #27952 “vulkan: int8 coopmat1 matmul implementation for AMD RDNA3 and RDNA4” ถูก merge เมื่อ 24 ก.ย. เวลา 13:18 UTC ซึ่งช้ากว่าการตัด v0.5.0 จึง ไม่ได้อยู่ในแท็ก v0.5.0 ถ้าจะใช้ต้องดาวน์โหลด nightly ตั้งแต่ b11160 ขึ้นไป (b11160 build จาก merge commit ของ PR นี้โดยตรง ส่วน v0.5.0 ชี้ไปที่ commit เดียวกับ b11149)

Vulkan int8: ใช้ matrix core แบบ int8 บน RDNA3/4 แทน fp16

ก่อนหน้านี้ backend Vulkan ใช้ tensor/matrix core ได้เฉพาะคำสั่ง fp16 ขั้นตอนคือ dequantize น้ำหนักลง shared memory ก่อน แล้วค่อยคูณเมทริกซ์แบบ fp16 ผู้เขียน PR (0cc4m) ระบุว่า “many devices have higher throughput int8 tensor/matrix cores” จึงทำ shader MMQ แบบ coopmat int8 ขึ้นมา โดยต่อยอดแนวคิดจาก PR #27493 ของ pwilkin shader นี้รองรับ q4_0, q4_1, q5_0, q5_1, q8_0, q3_k, q4_k, q5_k, q6_k, mxfp4, nvfp4 และ iq4_nl แต่ จำกัดไว้แค่ RDNA3 และ RDNA4 เพราะ hardcode รูปแบบการเข้าถึง coopmat ของสองสถาปัตยกรรมนี้ไว้

ตัวเลข llama-bench pp512 (prompt processing, t/s) จาก PR:

เครื่อง / โมเดล	Vulkan เดิม	Vulkan int8	เทียบ Vulkan เดิม	เทียบ ROCm
Radeon 8060S (Strix Halo) · Llama-3-8B Q4_0	862.7	1075.7	1.25x	1.16x
Radeon 8060S · Qwen3.8-27B Q4_K_M	186.5	254.1	1.36x	1.07x
Radeon 8060S · Qwen3.6-35B-A3B Q4_0 (MoE)	883.7	1175.9	1.33x	1.58x
Radeon AI PRO R9700 (RDNA4) · gpt-oss-20B MXFP4 (MoE)	3936	5631	1.43x	1.33x
Radeon AI PRO R9700 · Qwen3.8-27B Q6_K	955	1040	1.09x	1.36x

อ่านตัวเลขให้ครบก่อนอัปเกรด

• RDNA4 กับโมเดล dense ได้ผลกลาง ๆ PR เขียนเองว่า “RDNA4 is more neutral” เช่น Llama-3-8B Q4_0 บน R9700 ได้ 0.98x คือช้าลงเล็กน้อย ส่วนที่ได้ชัดคือโมเดล MoE
• ควอนต์บางชนิดไม่ได้ใช้ทางใหม่ บน RDNA4 ปิด q4_1, q5_1, q4_k, q5_k และ nvfp4 สำหรับ MUL_MAT แล้วถอยกลับไปใช้ matmul fp16 เดิม เพราะ “run slower than existing fp16 matmul” ส่วน nvfp4 ถูกปิดสำหรับ MUL_MAT_ID ด้วย
• microbenchmark กับงานจริงไม่ตรงกันเสมอ บน RDNA4 ค่า geomean ของ MUL_MAT_ID ใน test-backend-ops ช้าลงในหลายควอนต์ (เช่น q4_0 0.86x) แต่ pp512 ของโมเดล MoE จริงกลับเร็วขึ้น ถ้าจะใช้ควรวัดบนโมเดลที่ใช้จริงเอง
• ทั้งหมดเป็นตัวเลข prompt processing PR ไม่ได้รายงานความเร็ว token generation จึงไม่ควรคาดหวังว่าจะพิมพ์คำตอบเร็วขึ้นในอัตราเดียวกัน
• ผู้เขียนเปิดเผยใน PR ว่า “AI was used for optimization loops” และระบุว่าตรวจโค้ดกับประสิทธิภาพเองด้วยมือ

ใน v0.5.0 มีอะไรบ้าง

• ggml 0.25.0 เพิ่มการรองรับ hyper-connection, flash attention และ fused MoE/SSM ในหลาย backend (ใน changelog มี commit bump เป็น 0.25.1 ด้วย)
• โมเดล: รองรับ HRM-Text / DFM Mimir 1B (#27625) ซึ่งวนรัน transformer สองชุดสลับกัน ตาม PR ต้นทางมี KV cache 128 ชั้นและ decode ช้าราว 4 เท่าของโมเดล dense ที่กว้างเท่ากัน, แปลง MiMo-V2.6 ได้ (#29257) และเพิ่ม DFlash ให้ HunyuanOCR
• เซิร์ฟเวอร์: --host รับรายการ TCP address คั่นด้วยจุลภาคและ UNIX socket ได้ (#28690) แก้ปัญหาที่ผูกกับ IP ของ VPN แล้ว localhost ใช้ไม่ได้ ถ้าผูกแอดเดรสใดไม่สำเร็จ เซิร์ฟเวอร์จะไม่เริ่มทำงาน, function_call_output รับ input_image ได้ (#22575) และตั้ง --temp, --top-p, --min-p กับ penalty ต่าง ๆ ผ่าน LLAMA_ARG_* ได้ (#27380) เหมาะกับการรันเป็น service ของ systemd
• ฝั่ง AMD ที่อยู่ในรีลีสแล้ว: Vulkan เพิ่ม kernel MMQ ของ IQ4_XS และ IQ3_S, รองรับ sparse flash attention และ build ROCm บน Ubuntu เพิ่ม gfx1103

มุมมอง AI Curator

ในไทย มินิพีซีที่ใช้ APU Strix Halo (Radeon 8060S ใช้หน่วยความจำร่วมกับ CPU) กลายเป็นตัวเลือกยอดนิยมของคนที่อยากรันโมเดล 27B–35B บนโต๊ะทำงานโดยไม่ต้องซื้อการ์ดจอแยก จุดอ่อนที่รู้กันคือ prompt processing ช้า ซึ่งเป็นปัญหาหลักของงานแบบ agent หรือ RAG ที่ต้องป้อน context ยาวทุกรอบ การได้ pp512 เพิ่ม 1.06–1.36 เท่าบนโมเดล dense (ส่วนใหญ่อยู่ราว 1.1–1.25 เท่า) และ 1.26–1.33 เท่าบน MoE จึงเห็นผลจริง ไม่ใช่แค่ตัวเลขใน benchmark

ที่น่าสนใจกว่านั้นคือ Vulkan ที่มี int8 path เร็วกว่า ROCm ในค่า pp512 บน Strix Halo ครบทุกโมเดลที่ PR ทดสอบ ทั้งที่ ROCm เป็น stack ของ AMD เอง สำหรับนักพัฒนาไทยที่เคยต้องเสียเวลาหลายชั่วโมงกับการลง ROCm ให้ตรงเวอร์ชันกับ gfx ของเครื่อง ข้อสรุปตอนนี้ง่ายขึ้นคือ ถ้าใช้ APU ตระกูลนี้ ให้ลอง Vulkan build ก่อน แต่บน RDNA4 ตัวเลือกยังขึ้นกับโมเดลและชนิดควอนต์

ข้อควรระวังคือเรื่อง เวอร์ชัน โปรเจกต์นี้มีทั้งแท็ก semver และ nightly bNNNNN คู่กัน ถ้าใครอ่านข่าวนี้แล้วติดตั้ง v0.5.0 จะยังไม่ได้ int8 path ส่วนใครที่ต้องการความนิ่งสำหรับ production อาจรอให้ฟีเจอร์นี้เข้าไปในแท็ก semver ถัดไป แล้วค่อยตรวจ changelog อีกครั้ง

แหล่งข่าว

• Release v0.5.0 — ggml-org/llama.cpp (GitHub, 23 ก.ย. 2026)
• PR #27952: vulkan: int8 coopmat1 matmul implementation for AMD RDNA3 and RDNA4
• Nightly build b11160 — build แรกที่มี Vulkan int8 matmul