llama.cpp ยกเครื่อง Hexagon backend เช้านี้ — รัน NPU หลายตัวพร้อมกันบน Snapdragon, ทำงานแบบ async เต็มรูปแบบ และมาพร้อมชุดเครื่องมือ build/run/profile ของตัวเอง

การรันโมเดลบนเครื่องตัวเองมักถูกเล่าในบริบทของ “การ์ดจอตัวไหน” เสมอ แต่ silicon lane ที่สามซึ่งอยู่ในมือคนไทยหลายสิบล้านเครื่องอยู่แล้วคือ NPU — และ เช้าวันนี้ 27 สิงหาคม 2026 เวลา 01:46 UTC (08:46 น. ตามเวลาไทย) llama.cpp merge PR #26501 ซึ่งเป็นการรื้อ Hexagon backend ของ Qualcomm ใหม่แทบทั้งก้อน: แก้ 44 ไฟล์ เพิ่ม 5,314 บรรทัด ลบ 3,139 บรรทัด และขึ้นเป็น release build b10643 ในอีก 28 นาทีถัดมา

เจ้าของ PR คือ max-krasnyansky ซึ่งเป็นคนที่ดูแลสาย Hexagon ของโปรเจกต์นี้มาตลอด และเขาเขียนสรุปงานตัวเองไว้ตรง ๆ ว่า “kind of a big overhaul” ที่ทำสองเรื่องพร้อมกัน — รองรับอุปกรณ์ที่มี NPU หลายตัว และ ทำให้ backend เป็น asynchronous จริง ๆ ไม่ใช่แค่บางส่วน

จาก NPU ตัวเดียว เป็นการกระจายน้ำหนักข้าม NPU หลายตัว

ของเดิม Hexagon backend มองเห็น NPU เป็นชุด session ชื่อ HTP0…HTP4 บนชิปตัวเดียว รอบนี้เปลี่ยนระบบตั้งชื่อใหม่เป็น HTP<physical>:<virtual> เช่น HTP0:0 กับ HTP1:0 โดยเลขแรกคือ NPU ตัวจริงบนซิลิคอน และเลขหลังคือ virtual session บน NPU ตัวนั้น (ชื่อแบบเดิมยังใช้ได้ถ้าตั้ง environment variable GGML_HEXAGON_NDEV ไว้ แต่ถูกประกาศ deprecated แล้ว โดยของใหม่คือ GGML_HEXAGON_DEVICES)

ความต่างไม่ได้อยู่ที่ชื่อ แต่อยู่ที่สิ่งที่ชื่อนั้นเปิดให้ทำได้:

• GGML_HEXAGON_DEVICES=HTP0:0,HTP0:1 — สร้างสอง session บน NPU ตัวเดียว ซึ่งเอกสารระบุว่ามีประโยชน์เวลาชนเพดานหน่วยความจำต่อ session
• GGML_HEXAGON_DEVICES=HTP0:0,HTP1:0 — จอง session ละหนึ่งตัวบน NPU สองตัวที่แยกกันจริง ๆ บนบอร์ดที่มี dual-NPU

เมื่อรวมกับการต่อเข้ากับ meta backend ของ llama.cpp ก็ได้ --split-mode tensor ข้าม NPU ตัวอย่างที่ผู้เขียนรันไว้ในคำอธิบาย PR คือ gemma-4-E4B (GGUF q4_0 แบบ QAT) บนบอร์ด IQ9 EVK ด้วยคำสั่ง

./scripts/snapdragon/run.py --target ubuntu:maxk@192.168.1.87 --device HTP0:0,HTP1:0 -- \
  llama-completion -m gemma-4-E4B_q4_0-it.gguf -f sample_prompt_1024.txt \
  --jinja -st --split-mode tensor --ctx-size 8192

จุดที่ควรอ่านให้ชัดคือชิปที่ระบุในหัวข้อ PR — IQ9 และ IQ10 series — ไม่ใช่ชิปมือถือ แต่เป็นสายงาน IoT/edge ของ Qualcomm ฉะนั้นผู้ได้ประโยชน์ทันทีจากโหมด multi-NPU คือคนทำ กล่อง edge, หุ่นยนต์, ตู้คีออสก์, งานอุตสาหกรรม ที่ต้องรันโมเดลในเครื่องโดยไม่ต่อคลาวด์ ส่วนมือถือ Snapdragon ทั่วไปจะได้รับอานิสงส์จากอีกครึ่งของ PR แทน คือส่วน async

ทำไม “async เต็มรูปแบบ” ถึงกินงานเยอะกว่าที่คิด

สิ่งที่ทำในรอบนี้ไม่ใช่แค่ทำให้ graph_compute ไม่บล็อก แต่รวมถึง async event, async tensor-copy และ cross-device fence ทั้งชุด — และผู้เขียนอธิบายไว้ว่าการจะใช้งานได้จริงมันลากงานอื่นตามมาเป็นทอด ๆ:

• ต้องเปลี่ยนไปใช้ non-host buffer เป็นค่าเริ่มต้น เพื่อบังคับให้ copy และ repack เป็นแบบ async
• ซึ่งทำให้ต้องรองรับชนิดข้อมูลเพิ่มใน SET_ROWS / GET_ROWS
• และต้องปรับ op CPY ให้เร็วขึ้น ไม่ให้กลายเป็นคอขวดใหม่ พร้อมรองรับ fused FENCE op เพื่อให้ copy เป็น async ได้จริง

นี่คือเหตุผลที่ diff บวมถึงห้าพันบรรทัด: ไฟล์ที่ถูกแตะครอบคลุมตั้งแต่ matmul-ops.c, flash-attn-ops.c, act-ops.c, cpy-ops.c, get-rows-ops.c, set-rows-ops.c ไปจนถึง dma-queue.h และ allreduce-ops.c — พูดง่าย ๆ คือแทบทุกชั้นของ HTP runtime

ชุดเครื่องมือใหม่: build.py, run.py, profiler และ tracer

ส่วนที่นักพัฒนาจะได้ใช้เร็วที่สุดอาจเป็นของที่ไม่ใช่โค้ดเคอร์เนลเลย PR นี้เพิ่ม scripts/snapdragon/ เข้ามาทั้งโฟลเดอร์ พร้อมเอกสารแยกสำหรับ Linux และ Windows บน Snapdragon:

• build.py — ดึง Docker image ของ Qualcomm Snapdragon Toolchain (ghcr.io/snapdragon-toolchain/arm64-android:v0.7 หรือ arm64-linux:v0.7 ซึ่งมี Android NDK, OpenCL SDK, Hexagon SDK, CMake และ cross-compiler มาให้ครบ) แล้ว build/install/push ให้เสร็จในคำสั่งเดียว: ./scripts/snapdragon/build.py --target adb --push
• run.py — ตัวห่อสำหรับสั่งรัน โดยแปลงออปชัน CLI เป็น environment variable ให้อัตโนมัติ และรันได้ทั้งในเครื่อง ผ่าน ADB หรือผ่าน SSH ไปยังบอร์ดปลายทาง
• ggml-hexagon-profile.py และ ggml-hexagon-trace.py — สำหรับอ่านผลจาก GGML_HEXAGON_PROFILE ที่ให้ทั้ง usecs, cycles และ PMU counter ต่อ op (ไพป์เข้าเครื่องมือได้ตรง ๆ)

ยังมีตัวช่วยดีบักที่ตรงประเด็นมากอีกตัวคือ GGML_HEXAGON_OPFILTER ซึ่งรับ regex สำหรับ ปิด op เฉพาะตัว ให้ตกกลับไปทำบน CPU หรือ GPU แทน เช่น GGML_HEXAGON_OPFILTER="FLASH_ATTN_EXT" — เวลาเจอผลลัพธ์เพี้ยนบน NPU นี่คือวิธีไล่หาว่า op ไหนพัง โดยไม่ต้อง build ใหม่

บน Snapdragon ตอนนี้ llama.cpp มีสาม backend ให้เลือกผ่าน --device คือ CPU, Adreno GPU (OpenCL) และ Hexagon NPU โดย NPU จะทำตัวเหมือน “GPU” ในแง่ของ -ngl และออปชันฝั่ง offload และตัว build จะออกไลบรารีมาหลายเวอร์ชันตาม Hexagon arch — libggml-htp-v73.so, v75, v79, v81

ตัวเลขที่ควรตั้งความคาดหวังให้ถูก

เอกสารใหม่มีผล llama-bench ตัวอย่างของ Llama-3.2-1B-Instruct Q4_0 (729.75 MiB, 1.24B พารามิเตอร์) บนอุปกรณ์ Android ที่รายงาน Hexagon arch v79:

test	ผลลัพธ์
pp128 (prompt processing)	169.42 ± 1.75 t/s
tg64 (token generation)	51.54 ± 1.13 t/s

ตัวเลขนี้ไม่ได้ชนะการ์ดจอเดสก์ท็อป และไม่ควรถูกอ่านแบบนั้น สิ่งที่ NPU ให้คือ โทเคนต่อวัตต์ กับการไม่แย่ง GPU ไปจากงานอื่นในเครื่อง — โมเดล 1B ที่พ่นได้ราว 50 โทเคน/วินาทีบนชิปมือถือโดยไม่ต้องต่อเน็ต คือระดับที่ใช้ทำ on-device assistant, สรุปข้อความ หรือ tool-calling เบา ๆ ได้จริง และอย่าลืมว่า llama.cpp ยังติดป้าย Hexagon backend ว่า experimental อยู่

เกร็ดท้าย: PR นี้มีช่อง “AI usage disclosure” ตามกติกาของ llama.cpp และผู้เขียนกรอกว่าใช้ Antigravity ช่วย refactor ทดสอบ ดีบัก และเขียนสคริปต์ Python จำนวนมาก — เป็นภาพสะท้อนที่ตรงไปตรงมาว่างานระดับ backend runtime ก็ถูกเขียนด้วยความช่วยเหลือของเอเจนต์แล้ว และโปรเจกต์โอเพนซอร์สใหญ่ ๆ เริ่มบังคับให้ประกาศเรื่องนี้ในหน้า PR

มุมมอง AI Curator

สิ่งที่ทำให้ PR นี้น่าสนใจกว่าตัวเลขเบนช์มาร์ก คือมันเป็นสัญญาณว่าการรัน LLM บน NPU กำลังข้ามจากขั้น “พิสูจน์ว่าทำได้” ไปสู่ขั้น “วิศวกรรมของจริง” — ของที่เพิ่มเข้ามารอบนี้เกือบทั้งหมดเป็นของที่คนทำระบบ production ต้องการ ไม่ใช่ของที่คนทำเดโมต้องการ: การกระจายโหลดข้ามชิป, การไม่บล็อก, profiler ที่อ่าน PMU counter ได้, สวิตช์ปิด op รายตัวเวลาไล่บั๊ก และ toolchain ที่ห่อมาใน Docker จนคนที่ไม่เคยแตะ Hexagon SDK ก็ build ได้

สำหรับไทย ผมมองว่าประเด็นอยู่ที่ edge มากกว่ามือถือ ในระยะสั้น ตลาดมือถือไทยเป็น Android/Snapdragon หนัก ก็จริง แต่ผู้ใช้ทั่วไปเข้าถึง on-device LLM ผ่านแอปที่ผู้ผลิตทำมาให้ ไม่ได้ผ่าน llama-cli ส่วนคนที่หยิบของชิ้นนี้ไปใช้ได้ทันทีคือทีมที่ทำ ฮาร์ดแวร์ในประเทศ — ตู้บริการ, ป้ายอัจฉริยะ, ระบบตรวจสอบในโรงงาน, อุปกรณ์การเกษตร — ที่เจอโจทย์เดียวกันทุกราย คือ “ลูกค้าไม่ยอมให้ข้อมูลออกนอกโรงงาน” กับ “ค่าอินเทอร์เน็ตและความหน่วงรับไม่ได้” การมีเส้นทางที่ชัดเจนตั้งแต่ build.py --target linux:user@host --push ไปจนถึงการแบ่งโมเดลลง NPU สองตัว ย่นระยะจากไอเดียไปเป็นต้นแบบได้จริงเป็นสัปดาห์

อีกมุมที่อยากให้จับตา คือการแข่งขันภายในเครื่องเดียวกัน ตอนนี้ Snapdragon ให้เลือกได้ทั้ง CPU, Adreno ผ่าน OpenCL และ Hexagon ผ่าน HTP ซึ่งแปลว่าคำถาม “ควรรันบนอะไร” กลายเป็นคำถามที่ต้องวัด ไม่ใช่เดา — และ GGML_HEXAGON_OPFILTER กับ profiler ที่มากับ PR นี้ ทำให้การวัดนั้นเป็นงานที่วิศวกรคนเดียวทำได้ในบ่ายเดียว นี่คือประเภทของงานที่ไม่เป็นข่าวใหญ่ แต่เปลี่ยนว่าใครสามารถส่งสินค้าที่มี AI ในตัวออกมาได้บ้าง

แหล่งข่าว

• llama.cpp PR #26501 — hexagon: support for multi-NPU devices (IQ9, IQ10) and fully asynchronous backend
• เอกสาร Snapdragon backend ของ llama.cpp
• llama.cpp release b10643
• Qualcomm Dragonwing IQ9 series