DeepSeek V4 รันบนเครื่องตัวเองได้แล้ว — llama.cpp เพิ่มซัพพอร์ตเต็มรูปแบบ (build b9840) เปิดทางโฮสต์โมเดลโอเพนเวตระดับฟรอนเทียร์แบบ self-host

โมเดลที่เก่งที่สุดในกลุ่มโอเพนเวตของปีนี้ตัวหนึ่ง เพิ่งข้ามเส้นสำคัญ — จาก “รันได้เฉพาะบนคลาวด์/ดาต้าเซ็นเตอร์” มาเป็น “รันบนเครื่องตัวเองได้” เมื่อ llama.cpp merge ซัพพอร์ต DeepSeek V4 เต็มรูปแบบ เข้า build b9840 ซึ่งออกเมื่อวันที่ 29 มิถุนายน 2026 ผ่าน PR #24162 ตามด้วย build ต่อเนื่อง b9842/b9843 ที่ตามมาแก้รายละเอียดในวันเดียวกันถึงเช้าวันที่ 30

DeepSeek V4 เปิด open weights มาตั้งแต่ปลายเดือนเมษายน — แต่ตัว “น้ำหนัก” เปล่า ๆ ไม่ได้แปลว่ารันได้ทันทีบนเครื่องทั่วไป เพราะสถาปัตยกรรม attention แบบใหม่ของมันต้องมี runtime ที่เข้าใจมันก่อน การที่ llama.cpp ซึ่งเป็น local runner ที่นักพัฒนาใช้กันมากที่สุด รองรับ V4 อย่างเป็นทางการ คือชิ้นส่วนที่หายไปของสมการ “self-host โมเดลฟรอนเทียร์” — และนี่คือข่าวสายนักพัฒนาตัวจริงของรอบนี้

ทำไม “แปลงเป็น GGUF ได้” ถึงสำคัญกว่าที่คิด

DeepSeek V4 มาเป็น 2 รุ่น: V4-Pro ขนาด 1.6 ล้านล้าน parameter (activate 49B) และ V4-Flash 284B (activate 13B) ทั้งคู่เป็น Mixture-of-Experts (MoE) รองรับ context ถึง 1 ล้าน token จุดที่ทำให้มันรันยากคือ hybrid attention ที่ผสม Compressed Sparse Attention (CSA — บีบทุก 4 token เหลือ 1 โดยคงหน้าต่าง 8 token) กับ Heavily Compressed Attention (HCA — บีบระดับ 128 ต่อ 1 พร้อม sliding window) ซึ่งไม่เหมือนกับ attention มาตรฐานที่ runtime เดิม ๆ รู้จัก

สิ่งที่ b9840 เพิ่มเข้ามาจึงไม่ใช่แค่ “โหลดโมเดลได้” แต่เป็นชุดเครื่องมือครบ:

• convert: add dsv4 conversion — แปลง weights ต้นทางเป็นไฟล์ GGUF ฟอร์แมตที่ llama.cpp ใช้ ทำให้ quantize ลงเหลือ 4-bit/5-bit ได้เพื่อย่อขนาดให้พอกับ VRAM ที่มี
• รองรับ MoE ของ V4 จริง (เปลี่ยน moe.score_func มาเป็น expert_gating_func ให้ตรงกับ gating ของโมเดล)
• save/load state, Flash Attention, graph reuse และการจอง KV-cache แบบ worst-case — ทั้งหมดคือ optimization ที่ทำให้ inference บนเครื่องบ้านเป็นไปได้จริง ไม่ใช่แค่ “โหลดขึ้นได้แต่ช้าจนใช้ไม่ได้”
• เข้ากันได้กับ GGUF ของ DeepSeek V4 ที่ชุมชนทำไว้ก่อนแล้ว (รวมถึงชุดที่ antirez ผู้สร้าง Redis ทำ ds4 GGUF เผยแพร่) — ใครที่เตรียมไฟล์รอไว้ก่อนหน้านี้หยิบมาใช้ต่อได้เลย

ข้อจำกัดที่ทีมระบุตรง ๆ คือ เวอร์ชันแรกนี้ รองรับ n_seq=1 (รันทีละ sequence) ก่อน ส่วน multi-sequence จะตามมา — เป็นเรื่องปกติของการ merge ฟีเจอร์ใหญ่ที่เน้นให้ใช้งานได้ก่อน แล้วค่อยขยาย throughput

รันได้จริงบนฮาร์ดแวร์แค่ไหน

เลขที่นักพัฒนาอยากรู้ที่สุดคือ “เครื่องบ้านรันไหวไหม” จากเธรดของ PR มีคนรายงานผลทดสอบจริงไว้บ้าง: บน DGX Spark ได้ prompt processing ราว 148 token/วินาที (ที่ 2048 token) และ token generation ราว 6 token/วินาที ส่วนการ์ดระดับคอนซูเมอร์ มีคนรันได้บน RTX 3080 20GB คู่ ด้วยกลยุทธ์ quantization ที่เก็บความละเอียดไว้กับ tensor สำคัญและบีบ expert หนัก ๆ เพื่อให้พอดีกับ VRAM

ต้องพูดให้ตรง: นี่ยังไม่ใช่ “รันลื่นบนโน้ตบุ๊กเครื่องเดียว” — V4-Pro ขนาด 1.6T ยังต้องการ RAM/VRAM รวมระดับสูงแม้ quantize แล้ว และ generation 6 token/วินาทีคือพอใช้สำหรับงาน batch/agent ที่ไม่เร่ง ไม่ใช่แชตเรียลไทม์ลื่น ๆ แต่ความหมายเชิงโครงสร้างชัดเจน: เส้นทางจาก “weights เปล่า” ไป “inference บนเครื่องตัวเอง” เปิดครบแล้ว เหลือแค่เรื่องของฮาร์ดแวร์และ quantization ที่จะดีขึ้นเรื่อย ๆ ตามชุมชน

ใครได้ประโยชน์ และต่างจากข่าว DSpark อย่างไร

ข่าวนี้คนละชิ้นกับ DSpark/DeepSpec ที่เพิ่งรายงานไปเมื่อวาน — DSpark คือ speculative decoding ที่เร่งความเร็ว V4 บน เซิร์ฟเวอร์ production ของ DeepSeek เอง (ผู้ใช้ API ได้ฟรี) ส่วน b9840 คือการเปิดทางให้ คุณรัน V4 บนเครื่องของคุณเอง โดยไม่ต้องพึ่ง API ของใคร สองอย่างนี้เสริมกัน: ทิศทางหนึ่งทำให้ของเดิมเสิร์ฟถูกลง อีกทิศหนึ่งทำให้ของเดิมเป็นเจ้าของได้

กลุ่มที่ได้ประโยชน์ตรง ๆ คือทีมที่มีเงื่อนไข data sovereignty — ต้องเก็บข้อมูลในองค์กร รันบน on-prem ไม่ส่งออกคลาวด์ต่างประเทศ — รวมถึงนักวิจัยและคนทำ fine-tune ที่อยากแกะ/ปรับโมเดลระดับฟรอนเทียร์โดยไม่ติดกำแพง API

มุมมอง AI Curator

เรื่องนี้เป็นภาพย่อของพลวัตที่กำหนดทิศทางโลก AI ปี 2026 ได้ดี: คุณค่าจริงของโมเดลโอเพนเวตไม่ได้อยู่ที่วันเปิดน้ำหนัก แต่อยู่ที่วันที่ runtime ของชุมชนตามทัน ช่องว่างระหว่างสองวันนี้ — เมษายนถึงปลายมิถุนายน เกือบสองเดือน — คือ “ภาษีความซับซ้อน” ที่สถาปัตยกรรมใหม่อย่าง CSA/HCA เรียกเก็บ ใครที่ประกาศว่า “โอเพนแล้ว” ตั้งแต่วันแรกควรเข้าใจว่านั่นเป็นแค่ครึ่งทาง ครึ่งหลังคือแรงของอาสาสมัครใน llama.cpp ที่ไม่มีใครจ้าง

สำหรับบริบทไทยและเอเชียตะวันออกเฉียงใต้ จุดนี้สำคัญกว่าที่หลายคนคิด ธนาคาร ประกัน โรงพยาบาล และหน่วยงานรัฐที่ติดเงื่อนไขข้อมูลในประเทศ มักถูกตัดสิทธิ์จากโมเดลฟรอนเทียร์เพราะมันรันได้แค่บน API ต่างชาติ การที่ V4 ระดับ SWE-bench ~80% มา self-host ได้ผ่าน llama.cpp หมายความว่าตัวเลือก “ฉลาดพอ + รันในกำแพงตัวเอง” เริ่มมีจริง แม้วันนี้ throughput ยังไม่สวย แต่ทิศทางชัด: ต้นทุนฮาร์ดแวร์ลง quantization เก่งขึ้น และโมเดลโอเพนเวตจะค่อย ๆ กลายเป็น default ของงานที่อ่อนไหวต่อ data sovereignty มากกว่าจะเป็นทางเลือกรอง สิ่งที่ทีมไทยควรเริ่มทำตั้งแต่ตอนนี้คือ ทดสอบ pipeline self-host บน V4-Flash (เบากว่า) ให้พร้อม เพื่อไม่ต้องเริ่มนับหนึ่งตอนที่ความต้องการมาถึง

แหล่งข่าว:

• llama.cpp Release b9840 — DeepSeek V4 support (GitHub)
• PR #24162 — DeepSeek V4 (CSA/HCA attention, GGUF conversion)
• llama.cpp Releases (builds b9840–b9843)
• DeepSeek V4 เปิด open weights — 1.6T MoE + 1M context (บทความก่อนหน้า)