บทความโดยทีม AIServer.in.th — 11 กันยายน 2026
ถ้าคุณตามวงการ Local AI มาตั้งแต่ต้นปี คุณคงเคยได้ยินชื่อ DS4 หรือ DwarfStar 4 เครื่องยนต์ (interence engine) สำหรับรันโมเดลที่ Salvatore Sanfilippo หรือ antirez ผู้สร้าง Redis เขียนขึ้นมาใหม่ทั้งตัวด้วยภาษา C เพื่อรัน DeepSeek V4 Flash บน Mac เครื่องเดียว มันเป็นโปรเจกต์ที่โตเร็วมาก มีคนพอร์ตไป CUDA ไป ROCm มี fork ที่ทำ batching ทำ SSD-offload และล่าสุดมีคนเอา Qwen3.8-Flash-Next ไปรันบนมันได้แล้ว
ทีมเราอยู่กับ DS4 มาตลอดตั้งแต่ต้น ทั้งใช้จริง วัดจริง และเอาไปเทียบกับ llama.cpp บน DGX Spark หลายรอบ รอบล่าสุดคือเมื่อวานกับวันนี้ (10–11 กันยายน) ที่เราเอา Qwen3.8-Flash-Next แบบ Q5 พร้อมตาราง PLE แบบ FP8 มาวัดกับ DS4 สายใหม่ล่าสุด
คำตอบสั้นของบทความนี้คือ รอบนี้เรายังอยู่กับ llama.cpp แต่คำตอบยาวน่าสนใจกว่ามาก เพราะมันเป็นเรื่องของปรัชญาการเขียนซอฟต์แวร์สองแบบที่ต่างกันสุดขั้ว และเรื่องของการวัดผลที่ทำให้เราต้องกลับคำพูดตัวเองมาแล้วครั้งหนึ่ง
ชงกาแฟแล้วค่อยๆ อ่านครับ
ตอนที่ 1 — พฤษภาคม 2026: ผู้สร้าง Redis เขียนเครื่องยนต์ LLM ใหม่ทั้งตัว
เดือนเมษายน 2026 DeepSeek ปล่อย DeepSeek V4 Flash เป็นโมเดลเปิด: Mixture-of-Experts ขนาด 284 พันล้านพารามิเตอร์ แต่ใช้งาน Active แค่ 13 พันล้านต่อโทเคน context ยาว 1 ล้านโทเคน มันเป็นโมเดลเปิดตัวแรกที่หลายคนรู้สึกว่า “ใกล้ frontier พอที่จะใช้ทำงานจริง” และด้วยการบีบอัด 2 บิตกับ 8 บิตผสมกัน มันพอจะยัดลง Mac ที่มีแรม 96–128 GB ได้
ต้นเดือนพฤษภาคม antirez เปิด repo antirez/ds4 (commit แรก 7 พฤษภาคม 2026) พร้อมโพสต์ใน Hacker News ว่านี่คือ “DeepSeek 4 Flash local inference engine for Metal” ตัวเลขที่เขาโชว์บน M3 Max คือสร้างข้อความราว 30 โทเคนต่อวินาที อ่าน prompt 460 โทเคนต่อวินาที และกินไฟแค่ 50 วัตต์ระหว่างสร้างข้อความ สำหรับโมเดลเกือบ 300B นี่เป็นตัวเลขที่ทำให้คนหยุดอ่าน
สิ่งที่ทำให้ DS4 ต่างจากโปรเจกต์อื่นไม่ใช่ตัวเลข แต่เป็น การตัดสินใจเชิงปรัชญา ที่เขาอธิบายชัดในกระทู้นั้น: แทนที่จะไปปรับแต่งข้างใน llama.cpp ซึ่งมีชั้น abstraction รองรับฮาร์ดแวร์หลายสิบแบบ เขาเลือกเขียนเครื่องยนต์เฉพาะทางที่รู้จักโมเดลตระกูลเดียวและชิปตระกูลเดียว เพราะเมื่อตัดชั้นกลางออกหมด คุณจะ optimize ให้ตรงกับคู่ “GPU + โมเดล” นั้นได้แบบไม่ต้องประนีประนอม
README ของโปรเจกต์เขียนไว้ตรงตัวว่า “The code is self-contained and deliberately narrow, not a general GGUF runner.” มันไม่ใช่ตัวรัน GGUF ทั่วไป มันคือเครื่องยนต์ของโมเดลตัวเดียว
น่าสนใจว่าเขาไม่ได้ทำท่าเป็นศัตรูกับ llama.cpp เลย โค้ดของ DS4 ไม่ลิงก์กับ GGML แต่ README ยอมรับ “หนี้ก้อนใหญ่” ที่มีต่อ llama.cpp ทั้งฟอร์แมต GGUF และตรรกะของ kernel บางส่วนที่ดัดแปลงมาภายใต้ MIT
ในบทความ “A few words on DS4” ที่เขาเขียนหลังจากโปรเจกต์ดังเกินคาด เขาเล่าว่าช่วงแรกทำงาน “เฉลี่ยวันละ 14 ชั่วโมง” และบอกว่านี่เป็นครั้งแรกที่เขาใช้โมเดลบนเครื่องตัวเองทำงานจริงจังแทนที่จะพึ่ง Claude หรือ GPT เขาสรุปเหตุผลทั้งหมดไว้ในประโยคเดียวที่กลายเป็นคำขวัญของชุมชน: “AI is too critical to be just a provided service.”
เคล็ดลับที่ทำให้ 284B ลง 128 GB ได้: บีบ 2 บิตแบบ “ไม่สมมาตร”
ก่อนเล่าต่อ ต้องหยุดที่คำถามที่คนถามเรามากที่สุด: DeepSeek V4 Flash ขนาด 284 พันล้านพารามิเตอร์ ถ้าเก็บที่ 16 บิตต่อตัวคือราว 568 GB แล้ว antirez เอาลง Mac 96–128 GB ได้อย่างไรโดยที่โมเดลยังฉลาดพอจะเขียนโค้ดและเรียกเครื่องมือได้
คำตอบไม่ใช่ “บีบทุกอย่างเป็น 2 บิต” แต่เป็นสูตรที่เขาเรียกเองว่า quant แบบไม่สมมาตรสุดขั้ว (extremely asymmetric) README เขียนไว้ชัด: “only the routed MoE experts are quantized, up/gate at IQ2_XXS, down at Q2_K. They are the majority of all the model space: the other components (shared experts, projections, routing) are left untouched to guarantee quality.”
แปลเป็นภาพ: โมเดล MoE แบบนี้มี 43 ชั้น ชั้นละ 256 “ผู้เชี่ยวชาญ” (routed experts) แต่ละโทเคนใช้แค่ 6 คน น้ำหนักของผู้เชี่ยวชาญเหล่านี้กินพื้นที่เกือบทั้งหมดของโมเดล แต่แต่ละคนถูกเรียกนานๆ ครั้ง antirez จึงบีบเฉพาะส่วนนี้ลงเหลือ 2 บิต (เทนเซอร์ gate/up ใช้ IQ2_XXS ที่ประหยัดที่สุด ส่วน down ใช้ Q2_K ที่เก็บรายละเอียดได้มากกว่านิดหนึ่ง เพราะมันคือขั้นที่ผลลัพธ์ของผู้เชี่ยวชาญถูกรวมกลับ) ขณะที่ ทุกอย่างที่ทุกโทเคนต้องผ่าน ไม่ว่าจะเป็น attention, shared expert, ตัว router ที่เลือกผู้เชี่ยวชาญ และ output head ถูกเก็บไว้ที่ 8 บิตหรือเต็มความละเอียด นี่คือส่วนที่ “ตัดสินใจ” ว่าคำตอบจะไปทางไหน ถ้าส่วนนี้เพี้ยน ทุกอย่างเพี้ยน
ชั้นที่สองคือ imatrix (importance matrix) DS4 ไม่ได้ใช้ imatrix ทั่วไป แต่เก็บจากกราฟการคำนวณของ DS4 เองด้วยชุด prompt แบบแชตที่ render ผ่าน template จริงของโมเดล: สำหรับ gate/up มันบันทึกกำลังสองของ activation ขาเข้าหลัง normalize ส่วนสำหรับ down มันบันทึกกำลังสองของแถว SwiGLU หลังถ่วงน้ำหนักด้วยคะแนนของ router แล้ว ผลคือตัวบีบอัดรู้ว่าคอลัมน์ไหนของผู้เชี่ยวชาญคนไหนถูกใช้หนักจริงในการใช้งาน แล้วเอา “งบความละเอียด” ที่มีจำกัดไปวางตรงนั้น เขาให้ตัวเลือกสามแบบ: q2-imatrix สำหรับเครื่อง 96–128 GB, q2-q4-imatrix ที่ปล่อยหกชั้นสุดท้ายเป็น Q4 และ q4-imatrix สำหรับเครื่อง 256 GB ขึ้นไป ไฟล์ Q2 ที่ได้อยู่ราว 81 GB
ทำไมมันไม่พัง มีเหตุผลซ้อนกันสี่ข้อที่เราสอนในคอร์ส Quantization ของเรา: โครงข่ายประสาทมีน้ำหนักเกินความจำเป็นและถูกฝึกให้ทน noise, ความคลาดจากการปัดนับล้านตัวในชั้นเดียวหักล้างกันทางสถิติ, เส้นทางที่ตัดสินใจถูกเก็บไว้เต็มความละเอียด และในโมเดล MoE ผู้เชี่ยวชาญแต่ละคนกระทบคำตอบแค่ 6 ใน 256 ส่วน สิ่งที่ antirez ยืนยันในเอกสารและเป็นจุดที่เราชอบที่สุดคือเขาไม่ได้วัดคุณภาพด้วย perplexity สวยๆ อย่างเดียว แต่ระบุว่า quant 2 บิตชุดนี้ “behave well, work under coding agents, call tools in a reliable way” เพราะการเรียกเครื่องมือคือสิ่งแรกที่พังเมื่อบีบแรงเกินไป
ตัวเลขบน MacBook Pro M3 Max 128 GB ที่เขาบันทึกไว้กับ Q2 นี้: prompt สั้น อ่าน 58 โทเคนต่อวินาที สร้าง 26.7 โทเคนต่อวินาที ส่วน prompt ยาว 11,709 โทเคน อ่านได้ 250 โทเคนต่อวินาที และยังสร้างได้ 21.5 โทเคนต่อวินาที บนโน้ตบุ๊ก
เขายังบอกด้วยว่า DS4 ไม่ได้ผูกกับ DeepSeek V4 Flash ตลอดไป เป้าหมายคือ “โมเดลเปิดที่ดีที่สุด ณ ตอนนั้น ที่รันได้เร็วจริงบน Mac ระดับสูง” ถ้าวันหนึ่งมีโมเดลที่ดีกว่า DS4 ก็จะย้ายไปหาโมเดลนั้น
ตอนที่ 2 — สามเดือนที่มันโตเร็วกว่าใคร
สิ่งที่เกิดขึ้นในสามเดือนถัดมาเร็วจนตามแทบไม่ทัน
- CUDA และ ROCm ตามมาจากชุมชน DS4 รันได้บน DGX Spark, บนเครื่องหลาย GPU ตระกูล Ada/L40S และบน AMD Strix Halo (Framework Desktop) README ปัจจุบันระบุว่าชุด L40S แปดตัวสร้างข้อความรวมได้ราว 126 โทเคนต่อวินาทีเมื่อเปิด 16 session พร้อมกัน
- DSpark วิธี speculative decoding เฉพาะของ DeepSeek V4 ที่ใช้หัว MTP ของโมเดลเป็นตัวร่าง ทำให้ decode เร็วขึ้นโดยไม่เปลี่ยนคำตอบ
- Distributed inference ทั้งแบบ tensor parallel ผ่าน RDMA ระหว่าง Mac 128 GB สองเครื่อง และ pipeline parallel ข้ามเครื่อง ซึ่งเป็นสิ่งที่ antirez เขียนไว้ใน roadmap ตั้งแต่บทความแรก
- โมเดลเพิ่ม DeepSeek V4 PRO และตระกูล GLM 5.2 / 5.3 / 5.3 Flash
- Vector steering บังคับโทนหรือพฤติกรรมของโมเดลด้วยเวกเตอร์ทิศทางโดยไม่ต้องสร้าง KV cache ใหม่ (ทีมเราเคยเขียนถึงเรื่องนี้แยกต่างหากในคอร์ส Steering)
- ds4-agent โค้ดดิ้งเอเจนต์ในตัวที่เรียกเครื่องมือได้ และ HTTP server แบบหลาย session
อีกอย่างที่ README เขียนอย่างเปิดเผยคือซอฟต์แวร์นี้ “พัฒนาด้วยความช่วยเหลืออย่างมากจาก AI coding agents” โดยที่ไอเดียและการทดสอบยังเป็นของคน มันคือหนึ่งในโปรเจกต์ระบบขนาดใหญ่ชุดแรกๆ ที่ยอมรับตรงๆ ว่าเครื่องยนต์ CUDA ของมันถูกเขียนร่วมกับเอเจนต์
ตอนที่ 3 — สาย fork: เมื่อเครื่องยนต์ “แคบ” ถูกทำให้กว้าง
ธรรมชาติของโปรเจกต์ที่แคบและอ่านง่ายคือคนจะ fork มันไปทำในทางที่ตัวเองต้องการ DS4 มี fork สำคัญสองสายที่เกี่ยวกับเราโดยตรง
Entrpi/ds4 เก็บส่วน Metal ของต้นน้ำไว้ แล้วสร้างฝั่ง CUDA/Linux ขึ้นใหม่ให้เป็น เซิร์ฟเวอร์แบบ continuous batching รับหลายคำขอพร้อมกัน แทรก prefill ของคำขอใหม่ระหว่าง decode ของคำขอเก่า มี prefix cache ที่ทำให้คำถามต่อเนื่องเริ่มตอบเร็วขึ้นหลายเท่า เครื่องอ้างอิงของ fork นี้คือ DGX Spark นี่คือตัวที่เราใช้ทำงานจริงตลอดเดือนสิงหาคม
Baekpica/ds4 (branch dfm) ไปอีกทาง มันขยาย DS4 ให้รองรับโมเดลถึงหกตระกูล และทำสิ่งที่ฉลาดมากกับ Qwen3.8-Flash-Next โมเดลนี้มีตาราง n-gram ที่เรียกว่า PLE ขนาด 51.2 พันล้านพารามิเตอร์ ซึ่งเป็นแค่ตารางค้นหา ไม่ใช่ส่วนคำนวณ Baekpica เลยเอาตารางนี้ไปวางบน NVMe (“SSD-PLE”) ดึงเฉพาะหน้าที่ต้องใช้ผ่านตัวจัดการ cache แล้วเอาแรมที่ประหยัดได้ไปใส่ตัวโมเดลหลักที่ความละเอียด Q5 หรือ Q6 แทน Q2 บน Spark 128 GB มันคือการเปลี่ยน “แรมไม่พอ” ให้เป็น “ดิสก์ช่วยได้”
เดือนกันยายน สายนี้ถูกยกขึ้นเป็น ds4-dfm-rs ที่ใช้ Rust เป็น host ครอบ kernel CUDA เดิม ออกเวอร์ชัน 0.1.0 วันที่ 7 กันยายน และ 0.1.2 วันที่ 10 กันยายน พร้อมรองรับ PLE แบบ FP8 ที่ทำให้ไฟล์ตาราง 51 พันล้านพารามิเตอร์เหลือ 51 GB จาก 102 GB
ส่วน DS4 ต้นน้ำของ antirez เอง ณ วันนี้ยังไม่มี Qwen บน CUDA มี pull request สองชุดที่เปิดวันที่ 6 กันยายน (#990 และ #991) เป็นพอร์ต Qwen3.8-Flash-Next บน Metal ทั้งคู่ ผู้เขียนคนหนึ่งใส่โค้ด “ปฏิเสธ” ไว้ให้ CUDA และ ROCm อย่างชัดเจน โดยบอกตรงๆ ว่าไม่มีเครื่องทดสอบ
ตอนที่ 4 — เส้นทางของเรากับ DS4
ทีนี้มาถึงส่วนที่เป็นประสบการณ์ตรงของเรา
ต้นเดือนสิงหาคม DeepSeek ออก V4 Flash รุ่นอัปเดต 0731 เราลงบน DGX Spark สองทาง: Entrpi/ds4 กับ llama.cpp ตัวเลขแรกที่เห็นทำให้ตื่นเต้น Entrpi อ่าน prompt ได้ 916 โทเคนต่อวินาที เร็วกว่า llama.cpp ราวสองเท่า มี prefix cache ที่ทำให้ TTFT ของคำถามต่อเนื่องดีขึ้น 7 เท่า และรับ 8 คำขอพร้อมกันได้รวม 63 โทเคนต่อวินาที เราเลยให้ thClaws ซึ่งเป็นเอเจนต์ของเราใช้ DS4 เป็น backend หลัก
2 สิงหาคม llama.cpp mainline รับ DSpark เข้าไป (PR #25784) เท่ากับว่าจุดขายเรื่อง speculative decoding ไม่ได้เป็นของ DS4 คนเดียวอีกต่อไป
3 สิงหาคม เราวัดใหม่ทั้งหมดแบบ “แฟร์”: prompt เดียวกัน วิธีวัดเดียวกัน (สองจุด max 1 กับ max 256 โทเคน ไม่ใช่ streaming) เปิด DSpark ทุกตัว ผลคือ decode ของทุกเครื่องยนต์ทุก quant อยู่แถว 18–22 โทเคนต่อวินาทีเท่ากันหมด ตัวเลข “40” ที่เราเคยเห็นจาก llama.cpp มาจากเครื่องมือวัดคนละตัวและ prompt คนละแบบ ส่วน “DS4 เร็วสองเท่า” ที่เราเคยพูด ตอนวัดครั้งแรก DS4 ไม่ได้เปิด DSpark และเราเทียบกับตัวเลขที่ยังไม่ได้เปิดของอีกฝั่ง สรุปคือเราเคยพูดผิด และเราเขียนไว้ในบันทึกภายในตัวโตๆ ว่า “BUSTED”
สิ่งที่ยังจริงหลังวัดแฟร์คือ Entrpi ชนะเรื่อง batching (8 สายรวม 63 ต่อ 40) และใช้แรมน้อยสุด (81 GB) ส่วน llama.cpp ชนะเรื่อง TTFT (110 ต่อ 200 มิลลิวินาที) และความยืดหยุ่น: ใช้ quant ไหนก็ได้ ทำ steering ได้ และในชุดทดสอบภาษาไทยของเรา DeepSeek แบบ IQ3 บน llama.cpp ได้ 95.0% ขณะที่ Q2 ของ DS4 ได้ 92.8%
24 สิงหาคม เราตัดสินใจครั้งแรกเรื่องสินค้า: ยังไม่เอา DS4 เข้าชุดที่ส่งให้ลูกค้า จนกว่า fork กับต้นน้ำจะรวมกันเป็นเวอร์ชันที่นิ่ง เพราะลูกค้าของเราต้องกดอัปเดตแล้วได้ของที่ทำงาน ไม่ใช่ branch
ตอนที่ 5 — Flash-Next มาถึง และ DS4 ก็ตามมาบน Spark
26 สิงหาคม Qwen ปล่อย Qwen3.8-Flash-Next สถาปัตยกรรม qwen4_exp ที่ใหม่จริง: linear attention แบบ Gated DeltaNet ผสม MoE บวกตาราง PLE 51B และ hyper-connections ไฟล์ bf16 ใหญ่ 360 GB
llama.cpp รองรับผ่าน PR #27742 ที่ merge เข้า master วันที่ 27 สิงหาคม เราจึงออก pack ให้ลูกค้าได้ตั้งแต่วันแรกที่ mainline รองรับ ด้วย quant UD-Q2 ของ Unsloth ขนาด 75 GB นี่คือข้อดีข้อแรกของการอยู่กับ mainline: โมเดลใหม่มาถึงลูกค้าในวันเดียวกับที่โลกได้ใช้
ฝั่ง DS4 Baekpica เริ่มกระทู้ใน NVIDIA forum วันที่ 26 สิงหาคมว่ากำลังทำ Qwen3.8-Flash-Next บน Spark ด้วย SSD-PLE และภายในสองวันก็มี build ที่ตอบคำถามได้ที่ context 262K
8 กันยายน เราวัดครั้งแรก: DS4 (ds4-dfm-rs v0.1.0) กับ Q5 + PLE BF16 เทียบ llama.cpp UD-Q2 บน Spark เครื่องเดียว ผลสายเดียวเกือบเท่ากัน DS4 27 โทเคนต่อวินาที llama.cpp 29 แต่ที่ต่างกันมากคือความละเอียด: DS4 รัน Q5 ขณะที่ llama.cpp รัน Q2 การได้ Q5 ที่ความเร็วเดียวกับ Q2 คือความสำเร็จของไอเดีย SSD-PLE โดยตรง
แต่พอวัดหลายสาย ภาพกลับด้าน llama.cpp ที่ --parallel 4 ได้รวม 54 โทเคนต่อวินาที ส่วน DS4 แบบสองแบงก์ได้รวม 29 เท่าเดิม การ batching ของสาย Qwen ยังไม่ทำให้ throughput รวมเพิ่ม
ตอนที่ 6 — รอบนี้ (11 กันยายน): PLE FP8 กับ build ล่าสุด
คำถามที่เราอยากตอบวันนี้มีสองข้อ: PLE แบบ FP8 ที่เล็กลงครึ่งหนึ่งทำให้เร็วขึ้นไหม และ build ล่าสุดของ ds4-dfm-rs (11 กันยายน มี Inkling prefill ที่ optimize บน GB10 หลายรอบ) ต่างจากรุ่น 8 กันยายนไหม
เราโหลด PLE FP8 51 GB มาเพิ่ม build ds4-dfm-rs จาก main ล่าสุด แล้ววัดทุกอย่างในวันเดียวกัน prompt ไทยและอังกฤษชุดเดิม 256 โทเคน context 16K เปิด MTP draft 2
| ตั้งค่า | 1 สาย (tok/s) | TTFT | 4 สาย รวม / ต่อสาย |
|---|---|---|---|
| ds4 Q5 + PLE BF16 | 25.0 | 0.29 วิ | รวม 24.1 / 12.6 |
| ds4 Q5 + PLE FP8 | 25.0 | 0.29 วิ | รวม 24.5 / 12.9 |
| llama.cpp UD-Q2 | 28.9 | 0.10 วิ | รวม 55.7 / 15.0 |
ข้อสรุปตรงไปตรงมา:
- FP8 กับ BF16 เร็วเท่ากันเป๊ะ ที่ 25.0 การค้นตาราง PLE ไม่ใช่คอขวดของ decode ประโยชน์ของ FP8 คือดิสก์ที่ประหยัดได้ 51 GB ซึ่งบนเครื่อง 4 TB ก็มีความหมายอยู่
- build ใหม่ช้ากว่ารุ่น 8 กันยายนเล็กน้อย (25 ต่อ 27) การ optimize prefill ที่เพิ่มมาไม่ได้ช่วยงานตอบสั้นๆ ของเรา
- สายเดียว DS4 Q5 ยังเกือบเท่า llama.cpp Q2 และยังเป็นข้อได้เปรียบเรื่องความละเอียด แต่ หลายสาย llama.cpp ยังนำสองเท่า
เราวัดคุณภาพภาษาไทยด้วย (ThaiEval v3 ของเรา 170 ข้อ ปิด thinking ทั้งคู่) ผลไม่ได้เป็นไปตามที่คาดจากตัวเลข quant: DS4 Q5 ชนะหมวดภาษา (0.894 ต่อ 0.864) และความรู้ (0.888 ต่อ 0.876) แต่แพ้ชัดในหมวดงานเขียนร้อยแก้ว (0.666 ต่อ 0.877) และการทำตามคำสั่ง (0.954 ต่อ 0.992) ค่าเฉลี่ยอย่างง่ายทั้งเจ็ดหมวด llama.cpp Q2 ได้ราว 0.94 ส่วน DS4 Q5 ได้ราว 0.91 บทเรียนคือ ระดับ quant ไม่ใช่ตัวแปรเดียว วิธีที่เครื่องยนต์จัดการ chat template, การปิด thinking และการ sampling มีผลต่อคำตอบภาษาไทยไม่น้อยไปกว่าจำนวนบิต
ระหว่างทางเราเจอบทเรียนเชิงปฏิบัติสองข้อที่บอกได้ว่าสายนี้ยัง “ใหม่”: ครั้งแรกที่รัน ds4-server โหลดโมเดลตรง มันวางน้ำหนักบน GPU แค่ 28 จาก 78 GB ที่เหลืออยู่ในแรมแบบ pinned ผลคือ 9 โทเคนต่อวินาที ต้องใช้กระบวนการ “weight owner” แยกที่จอง VMM ให้เต็มก่อนถึงได้ 81 GB บน GPU และ PLE FP8 ต้องมีไฟล์ scale ขนาด 2 ไบต์วางคู่กัน ไม่งั้นเครื่องยนต์ปฏิเสธทั้งชุด รายละเอียดแบบนี้เอกสารยังไม่ครบ ต้องอ่านโค้ดหรืออ่าน log
ตอนที่ 7 — ทำไมรอบนี้เรายังอยู่กับ llama.cpp
เราไม่ได้เลือก llama.cpp เพราะมันเร็วที่สุดในทุกเซลล์ของตาราง เราเลือกเพราะเราขายเครื่องที่ลูกค้าต้องกดอัปเดตแล้วใช้ต่อได้ และเหตุผลต่อไปนี้หนักกว่าตัวเลขสายเดียว
- มันคือ mainline โมเดลใหม่ทุกตัวที่ชุมชนรองรับจะมาที่ llama.cpp ก่อน Flash-Next มาถึงลูกค้าเราในวันที่ PR merge ชุดสินค้าของเราตอนนี้มี 12 โมเดลบนเครื่องยนต์เดียว ตั้งแต่ Qwen3.8-27B, Flash-Next, GLM-5.3-Flash ถึง DeepSeek V4 Flash ถ้าเราใช้ DS4 เราจะต้องดูแล fork คนละสายต่อโมเดลตระกูล
- หลายผู้ใช้พร้อมกัน เครื่อง Spark ในองค์กรมักถูกใช้โดยทีม ไม่ใช่คนเดียว
--parallelของ llama.cpp ให้ throughput รวมเพิ่มเกือบเป็นเส้นตรงถึง 4 สาย สาย Qwen ของ DS4 ยังไม่ให้แบบนั้น - quant อะไรก็ได้ งานที่เราภูมิใจที่สุดคือ Thai imatrix quant ที่ปรับการบีบอัดให้เหมาะกับภาษาไทย ทำได้เพราะ llama.cpp เปิดให้เลือกทุกระดับทุกเทนเซอร์ DS4 รับ quant เฉพาะแบบที่มันรู้จัก
- ระบบนิเวศ mmproj สำหรับภาพ, DSpark และ MTP, RPC ข้ามเครื่อง, เครื่องมือวัด, และคนหลายพันคนที่ช่วยกันแก้บั๊ก MTP สำหรับ Flash-Next บน llama.cpp กำลังจะเข้ามาผ่าน PR #27836 ซึ่งเรารอ merge ก่อนใส่ในสินค้าตามหลักเดิม
- เส้นทางอัปเดต เราส่ง binary ของ llama.cpp ที่ build บน Spark ไปในแพ็กเกจ ลูกค้ากดปุ่มเดียว สาย DS4 ที่เราต้องการยังกระจายอยู่ในสาม repo (antirez, Entrpi, Baekpica) ที่ยังไม่รวมกัน
- เครื่องยนต์เดียวที่เราเข้าใจลึก เวลาลูกค้าโทรมาตอนสองทุ่ม เราอยากรู้ว่า log บรรทัดไหนหมายความว่าอะไร
แล้ว DS4 ชนะตรงไหน เราตอบตรงๆ ว่าชนะจริงในสามกรณี: ผู้ใช้คนเดียวที่ต้องการความละเอียดสูงสุดบนแรมจำกัด (Q5 ที่ความเร็ว Q2 ผ่าน SSD-PLE), งานเอเจนต์ที่มี prompt ยาวและมีคำถามต่อเนื่อง (prefix cache กับ prefill ของ Entrpi ยังเร็วกว่า) และคนที่อยากอ่านโค้ดเครื่องยนต์ทั้งตัวจบในสุดสัปดาห์เพื่อเข้าใจว่า MoE ทำงานอย่างไร
ตอนที่ 8 — สิ่งที่เราเรียนจาก antirez แม้จะไม่ได้ใช้ของเขา
การอยู่กับ DS4 หนึ่งฤดูร้อนเปลี่ยนวิธีคิดของทีมเราสามอย่าง
หนึ่ง เครื่องยนต์แคบสอนเราให้วัดให้แฟร์ เพราะ DS4 ทำให้เรากล้าตั้งคำถามกับตัวเลขของ llama.cpp เอง เราจึงต้องสร้างวิธีวัดที่ใช้กับทุกเครื่องยนต์ได้จริง และพบว่าตัวเลขที่เราเคยเชื่อผิดไปทั้งสองฝั่ง ตารางเทียบความเร็วในหน้าเว็บของเราวันนี้มาจากวิธีนั้น
สอง ไอเดีย SSD-PLE เป็นของจริง เครื่อง 128 GB ไม่จำเป็นต้องยอมแพ้ให้โมเดลที่มีตารางค้นหาขนาด 100 GB ถ้าตารางนั้นเข้าถึงแบบสุ่มเป็นหน้าเล็กๆ NVMe รับไหว เราเชื่อว่าไอเดียนี้จะไปโผล่ในเครื่องยนต์กระแสหลักในไม่ช้า และเราจะรอมัน
สาม กล้าเขียนใหม่ DS4 ทั้งตัวเกิดจากคนหนึ่งคนกับเอเจนต์เขียนโค้ด ภายในเวลาไม่กี่สัปดาห์ มันพิสูจน์ว่าในยุคนี้ต้นทุนของการ “เขียนใหม่ให้ตรงงาน” ต่ำลงมากจนปรัชญา “ใช้ของกลางที่รองรับทุกอย่าง” ไม่ใช่คำตอบเดียวอีกต่อไป
เราจะกลับมาวัด DS4 อีกเมื่อเกิดหนึ่งในสามอย่างนี้: ต้นน้ำของ antirez รับ Qwen บน CUDA เข้าไป, สาย Baekpica ทำ batching หลายสายให้ scale ได้ หรือมีโมเดลใหม่ที่ DS4 รองรับก่อน llama.cpp อย่างมีนัยสำคัญ ถึงตอนนั้นเราจะเขียนเล่าอีกครั้ง พร้อมตารางเดิม วิธีวัดเดิม และถ้าเราต้องกลับคำพูดอีก เราก็จะเขียนคำว่า BUSTED ตัวโตๆ เหมือนเดิม
สุขสันต์วันหยุดครับ
ตัวเลขทั้งหมดในบทความวัดบน NVIDIA DGX Spark (GB10, แรมรวม 128 GB) เครื่องเดียว ระหว่างวันที่ 3 สิงหาคม ถึง 11 กันยายน 2026 สคริปต์และผลดิบเก็บไว้ในระบบภายในของทีม ถ้าอยากเห็นเครื่องจริง ตารางความเร็วที่วัดแบบเดียวกันอยู่ที่หน้า ผลวัด และนัดเดโมได้ที่ หน้าติดต่อเรา
อ้างอิง
– antirez/ds4 บน GitHub และบทความ “A few words on DS4” (antirez.com/news/165)
– กระทู้เปิดตัวใน Hacker News: “DeepSeek 4 Flash local inference engine for Metal”
– Entrpi/ds4 (batched CUDA serving บน DGX Spark), Baekpica/ds4 branch dfm และ Baekpica/ds4-dfm-rs
– Pull request #990 และ #991 ของ antirez/ds4 (Qwen3.8-Flash-Next บน Metal)
– llama.cpp PR #25784 (DSpark), #27742 (Qwen3.8-Flash-Next), #27836 (MTP draft head)
– NVIDIA Developer Forums: “Qwen3.8-Flash-Next DS4 Support” (DGX Spark / GB10)