colibri v1.11 รัน DeepSeek-V4.1-Flash 552B บนเครื่อง CPU โดยสตรีม expert จาก SSD ได้ราว 1 โทเคน/วินาที — เอนจินภาษา C 30,000 ดาวที่ยอมช้า แต่ไม่ยอมแอบเปลี่ยนโมเดล

วันที่ 13 กันยายน 2026 colibri (เขียนว่า colibrì แปลว่านกฮัมมิงเบิร์ด) ออกเวอร์ชัน v1.11.0 ซึ่งรวม 56 pull request และเพิ่มโมเดลตระกูลที่เก้าคือ DeepSeek-V4.1-Flash ขนาด 552B พารามิเตอร์ ที่เราเขียนถึงไปเมื่อ 10 ก.ย. ตามบันทึกของรีลีส โมเดลนี้ “รันบนเครื่อง CPU โดยสตรีม expert จาก SSD” และอ่าน checkpoint ที่ DeepSeek ปล่อยมาได้ตรง ๆ โดยไม่ต้องแปลงไฟล์

colibri เป็นเอนจินอินเฟอเรนซ์ภาษา C ไม่พึ่งไลบรารีภายนอก ใช้ไลเซนส์ Apache-2.0 รีโปเปิดเมื่อ 1 ก.ค. และตอนนี้มีดาวราว 30,200 ดวง fork อีกกว่า 3,200 ถือเป็นโปรเจกต์ใหญ่ที่สุดในกลุ่ม “สตรีม expert จาก SSD” แต่ขณะที่เราเคยเขียนถึง Deltafin และ edge0 ไปแล้ว เรายังไม่เคยเขียนถึงตัวมันเลย โพสต์นี้จึงเป็นทั้งข่าวรีลีสใหม่และการตามเก็บโปรเจกต์ที่พลาดไป

ไอเดีย: มองว่า VRAM, แรม และ SSD เป็นหน่วยความจำก้อนเดียวกัน

README อธิบายด้วยตัวอย่าง GLM-5.2 ขนาด 744B ว่าโมเดล MoE ใช้พารามิเตอร์แอ็กทีฟแค่ราว 40B ต่อโทเคน และส่วนที่เปลี่ยนไปในแต่ละโทเคนจริง ๆ คือ routed expert ประมาณ 11 GB โมเดลจึงไม่จำเป็นต้อง “ใส่ให้พอดี” หน่วยความจำเร็ว แค่ต้อง “จัดวางให้ถูกที่” ส่วน dense (attention, shared expert, embedding ราว 17B พารามิเตอร์) เก็บไว้ในแรมแบบ int4 ประมาณ 9.9 GB ส่วน expert ถูกดึงจาก NVMe ตามที่ router เลือก โดยมี LRU แยกรายเลเยอร์, ระบบ pin expert ที่ใช้บ่อยตามสถิติการใช้งานจริง และการ prefetch ล่วงหน้าหนึ่งเลเยอร์

ตอนนี้รองรับเก้าตระกูล คือ GLM-5.2/5.3 (744B), GLM-5.3-Flash (321B), Inkling (975B), Kimi K3 (2.8T), DeepSeek V4 Flash (284B), DeepSeek V4.1 Flash (552B), Qwen3.8-Flash-Next, Qwen3.6-35B-A3B และ OLMoE 7B โดยแต่ละตระกูลเขียนเป็นไฟล์ C ไฟล์เดียว และใช้คำสั่ง coli chat / coli serve / coli web ชุดเดียวกัน รองรับ CPU, CUDA, Metal และเครื่อง NUMA

หลักการที่เขียนไว้ใน README คือ “ไม่รับประกันความเร็ว แต่รับประกันความหมาย” ค่าเริ่มต้นจะไม่ลดความแม่นยำของโมเดลหรือเปลี่ยนการทำงานของ router แบบเงียบ ๆ ถ้าหน่วยความจำเร็วไม่พอ ผลคือช้าลง ไม่ใช่ได้โมเดลอีกตัวที่คุณภาพต่ำกว่า ข้อนี้ต่างจาก edge0 ที่เราเขียนถึงเมื่อเช้า ซึ่ง runtime ตัดจำนวน expert ต่อโทเคนจาก 8 เหลือ 4

DeepSeek-V4.1-Flash บน SSD: ตัวเลขที่วัดจริง

เอกสาร docs/deepseek-v41.md แยกไฟล์ 510 GB ออกเป็นสามก้อน

• engram (ตาราง n-gram สองชุดที่เลเยอร์ 1 และ 14) 203 GB ซึ่งไม่เคยถูกโหลดขึ้นแรมเลย แต่ละโทเคนอ่านแค่ราว 13 KB เป็นการอ่านแบบสุ่มครั้งละ 264 ไบต์ไม่กี่สิบครั้ง
• routed expert 289 GB มีทั้งหมด 15,360 ตัว ตัวละ 18.8 MB เป็น fp4 อยู่แล้ว router เลือก 6 จาก 384 ตัวต่อเลเยอร์ รวมเป็น 4.5 GB ต่อโทเคน เทียบกับ GLM-5.2 ที่อ่าน 12.7 GB ต่อโทเคน โมเดลที่ใหญ่กว่าตัวนี้จึงเบากว่าบน SSD
• dense, embedding และ vision ราว 18 GB ซึ่งเก็บไว้ในหน่วยความจำ

วัดแบบ cold (ล้าง page cache ก่อนทุกรอบ) ด้วย prompt 26 โทเคนและสร้าง 24 โทเคน บน Samsung PM9A1 สองลูกที่ทำ striping เอนจินอ่าน expert รวม 88.5 GB ต่อเทิร์น ตัวเลขทั้งเทิร์น (รวม prefill) ดีขึ้นทีละขั้นดังนี้

ขั้นตอน	เวลาทั้งเทิร์น	tok/s
อ่านทีละตัว, kernel แบบ scalar	78.7 วินาที	0.305
อ่าน expert เป็นชุด (read depth 8, ~6.8 GB/s)	42.4 วินาที	0.566
อ่าน matrix ของ attention ครั้งเดียวต่อบล็อกตำแหน่ง	29.5 วินาที	0.812
MoE แบบ expert-major	25.1 วินาที	0.957

ใน 25.1 วินาทีนั้นเป็น prefill 10.7 วินาที และ decode 13.8 วินาที รีลีสยังระบุว่าแชตห้าเทิร์นต่อเนื่องได้ 1.14–1.58 tok/s และทุกขั้นให้ผลเหมือนเดิมทุกบิตเมื่อเทียบกับขั้นก่อน ความถูกต้องทั้งหมดตรวจใน CI เทียบกับโค้ดอ้างอิงที่ทีมเขียนเองด้วย PyTorch บน CPU (เพราะโค้ด forward ของ DeepSeek เองต้องใช้ kernel tilelang บน GPU) ให้ผลตรงกันทุกโทเคน ส่วน vision tower คลาดเคลื่อนไม่เกิน 5e-06

ส่วนที่ควรอ่านมากกว่าตัวเลขคือ สิ่งที่ไม่เวิร์ก ทีมลองซ่อนเวลาอ่านดิสก์ไว้หลังการคำนวณสองแบบ แล้วถอดออกทั้งคู่ แบบแรกใช้ posix_fadvise(WILLNEED) ซึ่งเพิ่มเวลาทั้งเทิร์น 4 วินาทีเพื่อลดเวลาดิสก์ 1 วินาที แบบที่สองใช้ reader thread pool ซึ่งลดเวลารอดิสก์จาก 10.4 เหลือ 1.0 วินาที แต่เวลาคูณเมทริกซ์ของ expert พุ่งจาก 7.6 เป็น 18.1 วินาที เพราะการ pread ครั้งละ 5.9 MB ไปแย่ง memory bandwidth กับการคูณเมทริกซ์ ส่วน speculative decoding ด้วยหัว MTP ในตัว (DSpark) เร็วขึ้น 17% บนเซิร์ฟเวอร์ CPU 16 เธรด (0.206 → 0.242 tok/s) เอกสารบอกตรง ๆ ว่าการวัดครั้งแรกเคยสรุปว่ามันช้าลง 32% ซึ่งผิด เพราะสองรอบนั้นเริ่มจาก cache คนละสถานะ และสรุปว่า “ต้อง cold ไม่งั้นไม่ใช่ตัวเลข”

ในรีลีสเดียวกัน และตัวเลขจากเครื่องของผู้ใช้

v1.11 ยังเพิ่มเส้นทาง Metal (ไม่เปิดเป็นค่าเริ่มต้น) ให้ GLM-5.3-Flash บน Apple Silicon ซึ่งวัดบน M4 Max ได้ 0.469 → 0.621 tok/s และสูงสุด 2.15 tok/s เมื่อจูน expert cache แล้ว มี CI สำหรับ Windows CUDA และ musl และแก้บั๊กจริงห้าตัวใน engine สี่ตัว เช่น OLMoE ที่ไม่สนใจค่า --ram จน prompt 2,291 โทเคนบนเครื่องของผู้แจ้งบั๊กใช้เวลา 675 วินาที ซึ่งตอนนี้เหลือ 353 วินาทีโดยไม่ต้องตั้งค่าอะไร

หน้า benchmark ของโปรเจกต์รวบรวมผลที่ผู้ใช้ส่งมา (ส่วนใหญ่เป็น GLM-5.2 744B) ช่วงของตัวเลขกว้างมาก

• เครื่องพัฒนาเดิม (WSL2, แรม 25 GB): 0.05–0.1 tok/s แบบ cold
• Mac mini M4 Pro แรม 48 GB ผ่าน Metal: 0.30 tok/s
• Ryzen 9 9950X กับ Samsung 9100 PRO PCIe 5.0: 0.28 tok/s
• M5 Max แรม 128 GB ผ่าน Metal และ pin expert ไว้ 46.9 GB: 2.06 tok/s
• RTX 5090 หกใบที่เก็บ expert ครบใน VRAM+แรม: 6.84 tok/s

หน้าเดียวกันแยก “ค่าที่คาดการณ์” ออกจาก “ค่าที่วัดจริง” ไว้ชัดเจน ส่วน README ขอให้ผู้ร่วมพัฒนาส่งผลการทดลองที่ล้มเหลวมาด้วย

มุมมอง AI Curator

ข่าวที่ใหญ่กว่าตัวเลข 1 tok/s คือ โมเดลรุ่นใหม่เริ่มถูกออกแบบให้เข้ากับลำดับชั้นของหน่วยความจำ DeepSeek-V4.1-Flash เอาข้อมูล 40% ของ checkpoint ไปไว้ในตาราง n-gram ที่อ่านแค่ไม่กี่สิบแถวต่อโทเคน และใช้ expert ที่อ่านแค่ 4.5 GB ต่อโทเคน ผลคือโมเดล 552B ที่ “เบากว่า” โมเดล 744B เมื่อรันจาก SSD ถ้าแนวนี้ไปต่อ ความจุ NVMe กับแบนด์วิดท์อ่านแบบสุ่มจะสำคัญพอ ๆ กับจำนวน VRAM ในการเลือกฮาร์ดแวร์สำหรับรันโมเดลในเครื่อง

แต่ต้องพูดตรง ๆ ว่า 1 tok/s ยังไม่ใช่ความเร็วสำหรับแชต มันเหมาะกับงานแบบ batch เช่น สรุปเอกสารภายในทั้งคืน หรือตรวจสัญญาเป็นชุด ที่ข้อมูลออกนอกเครื่องไม่ได้ สำหรับองค์กรไทยที่ต้องทำตาม PDPA หรือหน่วยงานรัฐที่ห้ามส่งเอกสารไปคลาวด์ต่างประเทศ การมีโมเดลไลเซนส์ MIT ระดับนี้รันบนเวิร์กสเตชันที่มี NVMe สองลูกได้ถือว่าเปลี่ยนสมการเดิม ส่วนงานภาษาไทย ให้ทดสอบเองก่อนเสมอ เพราะยังไม่มีใครวัดผลภาษาไทยบนเส้นทางนี้

สิ่งที่ทำให้ colibri น่าเชื่อกว่าหลายโปรเจกต์ในกลุ่มเดียวกันไม่ใช่ความเร็ว แต่เป็นวินัยในการวัด ทุกขั้นต้องวัดแบบ cold ต้องให้ผลเหมือนเดิมทุกบิต และความล้มเหลวถูกบันทึกพร้อมตัวเลข ในช่วงที่พาดหัว “รันโมเดลยักษ์บนโน้ตบุ๊ก” ออกมาทุกสัปดาห์ นักพัฒนาควรใช้เกณฑ์เดียวกันนี้กับทุกโปรเจกต์ คือโมเดลที่ได้ยังเป็นโมเดลเดิมหรือไม่ วัดจาก cache เย็นหรือไม่ และวัดบนเครื่องแบบไหน ถ้าตอบสามข้อนี้ไม่ได้ ตัวเลข tok/s ก็ยังเชื่อไม่ได้

แหล่งข่าว

• colibri v1.11.0 — GitHub Releases (13 ก.ย. 2026)
• docs/deepseek-v41.md — ตารางวัด DeepSeek-V4.1-Flash, DSpark และสองวิธีที่ถอดออก
• docs/benchmarks.md — ตัวเลขที่ผู้ใช้วัดบนเครื่องจริง
• JustVugg/colibri — README (หลักการ “ไม่รับประกันความเร็ว แต่รับประกันความหมาย”)