llama.cpp 0.4.0 ออกแล้ว — โหลดเทนเซอร์แบบขี้เกียจลด RAM ได้ 16%, --n-cpu-ffn สำหรับโมเดล dense และ sparse FA ที่เร็วขึ้น 2 เท่าเมื่อคอนเท็กซ์ยาว

เมื่อ 4 กันยายน 2026 เวลา 19:56 UTC โปรเจกต์ llama.cpp ปล่อย v0.4.0 ซึ่งเป็นการปล่อยที่ต่อเนื่องจากเรื่องที่เราเคยเขียนไว้เมื่อ 18 สิงหาคม ตอนที่โปรเจกต์เพิ่งเริ่มติดแท็กแบบ semantic versioning หลังใช้เลข build อย่าง b10485 มาหลายปี — และคำถามที่เราตั้งไว้ตอนนั้นว่า “เลข minor จะวิ่งเร็วแค่ไหน” ตอนนี้มีคำตอบแล้ว: v0.1.0 ถึง v0.4.0 ใช้เวลา 18 วัน

ที่เปลี่ยนไปอีกอย่างคือ v0.1.2 ยังติดสถานะ pre-release อยู่ ส่วน v0.2.0 (21 ส.ค.), v0.3.0 (25 ส.ค.) และ v0.4.0 ถอดธงนั้นออกหมดแล้ว — คือ GitHub ถือว่าเป็นรีลีสจริง ไม่ใช่ของทดลองอีกต่อไป (nightly ยังเดินคู่ขนานตามเดิม โดยรีลีสนี้ระบุ nightly ที่ตรงกันไว้ว่า b10809)

แต่สิ่งที่นักพัฒนาควรสนใจไม่ใช่เลขเวอร์ชัน มันคือฟีเจอร์สามอย่างที่กระทบคนรันโมเดลบนเครื่องตัวเองโดยตรง

--lazy-mode: แลกความเร็ว 8-11% กับ RAM 16%

ฟีเจอร์เด่นของรีลีสนี้คือ การอ่านเทนเซอร์แบบ on-demand จาก PR #27794 ของ ngxson (เมิร์จ 27 ส.ค.) แนวคิดคือโมเดลที่มี PLE หรือ engram embedding ไม่จำเป็นต้องโหลดตาราง embedding ทั้งก้อนขึ้น RAM — อ่านผ่าน mmap ตามต้องการได้

ควบคุมด้วย --lazy-mode on|off|auto (ชื่อเดิมในตัว PR คือ --tensor-read-lazy ก่อนถูกเปลี่ยนใน #27969) โดย auto จะทำ lazy เฉพาะเทนเซอร์ที่ใหญ่เกิน 4 GiB ซึ่งเป็นการตั้งค่าที่ระวังไว้แล้วว่าจะไม่ทำร้ายโมเดลเล็ก

ตัวเลขที่ผู้เขียน PR วัดเองกับ unsloth/gemma-4-E4B-it-GGUF:Q4_K_M โดยเทนเซอร์ที่ถูกทำ lazy คือ per_layer_token_embd.weight ขนาด 1.94 GB หรือ 39% ของไฟล์ 4.96 GB

คอนฟิก	peak RSS	tg (t/s)
baseline (prefetch ปกติ)	7.37 GB	105.8
lazy: ข้าม prefetch + MADV_RANDOM	6.16 GB	94.2-94.7 (-10.7%)
lazy: ข้าม prefetch อย่างเดียว	—	97.0-97.3 (-8%)

อ่านตารางนี้ให้ตรง: นี่คือการแลก ไม่ใช่ของฟรี peak RSS ลดจาก 7.37 GB เหลือ 6.16 GB (ราว 16%) แต่ token generation ช้าลง 8-10.7% ผู้เขียนระบุเองว่าสำหรับโมเดลเล็กอย่าง gemma 4 ผลกระทบต่อความเร็ว “มีนัยสำคัญ” เพราะความหน่วงในการอ่านเทียบกับเวลา generate ต่อโทเคนนั้นสูง ส่วนโมเดลใหญ่อย่าง qwen4 ผลกระทบจะน้อยกว่ามาก — ซึ่งก็สมเหตุสมผล เพราะเป็นกรณีที่การประหยัด RAM มีค่าที่สุดพอดี

คนที่ได้ประโยชน์ชัดที่สุดคือคนที่ โมเดลใหญ่กว่า RAM อยู่นิดเดียว ถ้าเดิมต้อง swap หรือรันไม่ขึ้นเลย การช้าลง 10% ก็ไม่ใช่ราคาที่ต้องคิดนาน

--n-cpu-ffn: ตัวเลือกที่คนใช้การ์ด 16 GB รอมานาน

ออปชัน --n-cpu-moe มีมานานสำหรับโมเดล MoE แต่สำหรับ โมเดล dense การผลักเลเยอร์ไป CPU ผ่าน --ngl ทำให้ช้าลงอย่างรุนแรง PR #26622 เพิ่ม --n-cpu-ffn ที่ให้ระบุจำนวน FFN sublayer ที่จะวางไว้บน CPU ได้ตรง ๆ

ผู้เขียน PR (John-194) รายงานผลบนฮาร์ดแวร์ที่หลายคนน่าจะมี — RTX 4070 Ti SUPER (VRAM 16 GB), i5-13600KF, DDR5 32 GB — ว่าได้ความเร็ว generate ที่ 15-25 t/s บนโมเดล Q4_K_M ที่คอนเท็กซ์เกิน 90,000 โทเคน ซึ่งเป็นระดับที่ใช้งานจริงได้ เขาระบุตรงไปตรงมาว่าเวอร์ชันนี้ทำแบบง่ายที่สุดคือ หยิบ N เลเยอร์แรกจาก 0 ไปเลย และมีการปรับให้เลือกเลเยอร์ FFN ที่ใหญ่ที่สุดก่อนได้ ซึ่งจะให้ tg เพิ่มอีกราว 10% เป็นงานของ PR ในอนาคต

sparse flash attention: 2.03 เท่าที่คอนเท็กซ์ยาว แต่ 1.00 เท่าที่คอนเท็กซ์สั้น

PR #27970 เพิ่ม sparse flash attention สำหรับ DeepSeek-V4/GLM และ Qwen4exp ตัวเลขที่วัดบน DGX Spark ด้วย DeepSeek-V4 แบบ IQ2_XXS (2.0625 bpw) เล่าเรื่องที่ชัดมาก

ความยาวคอนเท็กซ์	ก่อน (t/s)	หลัง (t/s)	เร็วขึ้น
pp2048 (ไม่มี depth)	563.31	563.53	1.00x
@d32768	389.50	461.63	1.19x
@d131072	204.63	315.26	1.54x
@d262144	122.99	216.94	1.76x
@d524288	66.09	134.30	2.03x

กล่าวคือ ที่คอนเท็กซ์สั้นแทบไม่ได้อะไรเลย ประโยชน์เริ่มโผล่ที่ราว 32K และเพิ่มขึ้นเรื่อย ๆ จนได้สองเท่าที่ครึ่งล้านโทเคน ถ้างานของคุณคือ chat สั้น ๆ ฟีเจอร์นี้ไม่ใช่เหตุผลให้อัปเกรด แต่ถ้าเป็นการอ่านโค้ดเบสทั้งก้อนหรือเอกสารยาว มันคือความต่างระหว่างรอ 30 วินาทีกับรอหนึ่งนาที

ด้านล่าง ggml ถูก bump จาก v0.22.0 เป็น v0.23.0 ซึ่งเป็นที่มาของ API ใหม่ที่รองรับเรื่องนี้ (ggml_flash_attn_ext_set_n_kv_max) พร้อม RPC event/async API และ Apple RDMA over Thunderbolt เป็น transport ของ RPC จาก PR #26421 — ผู้เขียนอ้างอิงเอกสาร TN3205 ของ Apple และระบุความต่างจากฝั่ง Linux ไว้ชัด เช่นใช้ UC (unreliable connection) แทน RC และ stride คงที่ 128 KiB (ทดสอบแล้วว่าดีที่สุดในกลุ่ม 32/64/128/256)

โมเดลใหม่และการเปลี่ยนพฤติกรรมที่ควรรู้

รีลีสนี้เพิ่มการรองรับ Qwen3.8-Flash-Next (สถาปัตยกรรม qwen4exp) โดยระบุเองว่า “optimization improvements are still pending” — คือรันได้แล้วแต่ยังไม่เร็วที่สุด นอกจากนี้มี NVIDIA Nemotron-3-Puzzle-75B-A9B, DSpark สำหรับ Nemotron 3.5, nanbeige4.2-3B และฝั่ง multimodal เพิ่ม DeepSeek-V4-Flash-Vision-Exp พร้อมออปชัน --video-* สำหรับอินพุตวิดีโอ

ส่วนที่คนรัน llama-server ควรอ่านก่อนอัปเกรด เพราะเป็นการเปลี่ยนพฤติกรรมดีฟอลต์

• preserve_reasoning ถูกเปิดเป็นดีฟอลต์แล้ว (#28174) — เนื้อหาส่วน reasoning จะถูกเก็บไว้ ไม่ถูกตัดทิ้งเหมือนเดิม
• ปฏิเสธ prefilled assistant tool call (#27626) ถ้าโค้ดคุณส่ง tool call ที่เติมไว้ล่วงหน้า มันจะไม่ผ่านอีกต่อไป
• เพิ่ม per-slot context limit (#24124) จำกัดคอนเท็กซ์ต่อ slot ได้แล้ว ซึ่งสำคัญมากเวลารันหลาย session พร้อมกันบนเครื่องเดียว
• เซิร์ฟเวอร์รับ data: URL สำหรับสื่อได้แล้ว และฝั่ง UI แทนที่ MCP overrides ด้วย tool policy (#27745)

มุมมอง AI Curator

รีลีสนี้อ่านเหมือนรายการซ่อมบำรุงธรรมดา แต่ถ้าดูสามฟีเจอร์หลักพร้อมกันจะเห็นทิศทางที่ชัดเจน: llama.cpp กำลังปรับตัวเข้าหาโมเดลที่ใหญ่เกินเครื่องของผู้ใช้ --lazy-mode คือการยอมรับว่าโมเดลไม่พอดี RAM แล้ว, --n-cpu-ffn คือการยอมรับว่า VRAM 16 GB คือความจริงของคนส่วนใหญ่ ไม่ใช่ 80 GB, และ sparse FA คือการยอมรับว่าคอนเท็กซ์ครึ่งล้านโทเคนกลายเป็นกรณีใช้งานปกติไปแล้ว ทุกฟีเจอร์คือการต่อรองกับข้อจำกัดของฮาร์ดแวร์ ไม่ใช่การไล่ตามคะแนนเบนช์มาร์ก

สำหรับนักพัฒนาไทย นี่คือเรื่องที่มีผลจริงมากกว่าข่าวโมเดลใหม่รายวัน เพราะการ์ดที่หาซื้อได้ในราคาที่จ่ายไหวคือระดับ 12-16 GB และตัวเลข 15-25 t/s ที่คอนเท็กซ์ 90K บน RTX 4070 Ti SUPER คือเกณฑ์อ้างอิงที่ตรวจสอบได้ ก่อนจะตัดสินใจซื้อการ์ดใหม่หรือย้ายไป API รายเดือน ลองอัปเกรดแล้ววัดด้วย llama-bench บนเครื่องเดิมก่อน — ในหลายกรณีความต่างระหว่าง “รันไม่ได้” กับ “รันได้” คือแค่ธงบรรทัดคำสั่งที่เพิ่งมีสัปดาห์นี้

สิ่งที่ต้องระวังคือ ผลกระทบด้านลบถูกวัดโดยผู้ส่ง PR เอง ไม่ใช่โดยบุคคลที่สาม ตัวเลข -8% ถึง -10.7% ของ --lazy-mode มาจากเครื่องเดียว โมเดลเดียว และ quant เดียว บนฮาร์ดแวร์ที่มีความเร็วดิสก์ต่างกัน (NVMe เทียบกับ SATA SSD) ผลจะไม่เหมือนกันเลย เพราะกลไกทั้งหมดขึ้นกับ mmap และการอ่านจากดิสก์ ใครที่ใช้ external drive หรือ network storage ควรทดสอบก่อนเปิด --lazy-mode on แบบถาวร — และ auto ที่เป็นดีฟอลต์ก็เป็นทางเลือกที่ปลอดภัยกว่าอยู่แล้ว

สุดท้าย เรื่องจังหวะการปล่อย: minor สี่ตัวใน 18 วันแปลว่า การผูก v0.x ไว้ใน Dockerfile ยังไม่ให้ความนิ่งอย่างที่หวัง ข้อดีคือตอนนี้อย่างน้อยก็มี changelog ที่อ่านรู้เรื่องและมี PR ให้ตามได้ทุกบรรทัด ซึ่งดีกว่าการไล่เทียบ b10485 กับ b10809 แบบเดิมมาก แต่ทีมที่ต้องการความนิ่งจริงควรตรึงเลขเวอร์ชันแบบเต็ม (v0.4.0) ไม่ใช่ช่วง และอ่านหัวข้อ “Server changes” ทุกครั้งก่อนอัปเกรด เพราะรีลีสนี้เปลี่ยนดีฟอลต์ไปสองอย่างโดยไม่มีคำว่า breaking อยู่ในชื่อเวอร์ชัน

แหล่งข่าว

• llama.cpp v0.4.0 — GitHub Releases (4 ก.ย. 2026)
• PR #27794 — llama: model_loader: add TENSOR_READ_LAZY (ตารางวัด peak RSS/tg)
• PR #26622 — llama: add —n-cpu-ffn option (ผลบน RTX 4070 Ti SUPER)
• PR #27970 — CUDA + ggml: add sparse-fa for DSV4/GLM (ตารางความเร็วตามความยาวคอนเท็กซ์)