Inco Splash — engine รันโมเดลบน Mac ที่ "สร้างรอบโมเดล" รองรับแค่ 2 ตัว แต่ decode Qwen3.8-27B ได้ 74 tok/s เร็วกว่า oMLX 2 เท่า และตอบรอบถัดไปของ agent เร็วกว่า 7 เท่า (Apache-2.0)
engine รันโมเดลบนเครื่องส่วนใหญ่ เช่น llama.cpp, Ollama, oMLX และ LM Studio ออกแบบให้ รันได้ทุกโมเดล Splash ของ Inco AI กลับทางกัน คือ สร้าง engine รอบโมเดลตัวเดียว แต่ละโมเดลที่รองรับได้ Metal kernel ที่เขียนเฉพาะขนาด tensor ของมัน ได้ draft model สำหรับ speculative decoding ที่เทรนมาเฉพาะ และได้แผนหน่วยความจำที่คำนวณไว้ล่วงหน้า ผลคือตอนนี้รองรับแค่ สองโมเดล (Qwen3.8-27B และ Qwen3.6-35B-A3B) แต่เร็วกว่าทุก engine ที่ Inco นำมาเทียบ
Splash เปิดตัวเมื่อ 17 ก.ย. 2026 พร้อม 1.0 ใน repo เมื่อ 18 ก.ย. และมี 1.0.1 (20 ก.ย.) กับ 1.0.2 (21 ก.ย.) ตามมา โพสต์นี้เป็นการตามข่าว เราเพิ่งรายงานเรื่อง ผู้สร้าง oMLX เข้า Hugging Face เมื่อเช้า ซึ่ง oMLX คือคู่เทียบหลักใน benchmark ของ Splash ทั้งสองเรื่องจึงควรอ่านคู่กัน โค้ดเป็น Apache-2.0 ใน repo มี .metal kernel จริง 25 ไฟล์ ไม่ใช่ binary ปิด
ตัวเลขที่ Inco วัด (M5 Pro 48GB, งานเขียนโค้ดจาก SPEED-Bench)
Decode (request เดียว, tokens/s):
| โมเดล | Splash | oMLX | Ollama |
|---|---|---|---|
| Qwen3.8-27B (prompt สั้น) | 74 | 38 | 24 |
| Qwen3.8-27B (32K) | 54 | 28 | 19 |
| Qwen3.6-35B-A3B (prompt สั้น) | 210 | 126 | 75 |
| Qwen3.6-35B-A3B (32K) | 143 | 83 | 57 |
- Prefill แบบ cold (32K): เวลาถึง token แรกของ 27B ลดจาก 317 วินาที (oMLX) เหลือ 96 วินาที Inco ยอมรับเองว่าการอ่าน repo ใหญ่ครั้งแรกยังแพงสำหรับทุก engine รวมถึงของตัวเอง
- ใช้ cache ซ้ำ (32K): ได้ token แรกใน 282 ms บน 27B เทียบกับ 2,049 ms ของ oMLX (เร็วกว่า 7.3 เท่า) ตัวเลขนี้สำคัญที่สุดสำหรับ coding agent เพราะเกือบทุกรอบคือการส่งบริบทเดิมที่ต่อท้ายเพิ่มมาเล็กน้อย
- 4 request พร้อมกัน: throughput รวมบน 27B ได้ 170 tok/s เทียบกับ 43 ของ oMLX (3.9 เท่า) และรับ request 32K พร้อมกันได้ 16 ตัว ขณะที่ engine ทั่วไปรับรอบแรกได้ 9 ตัว
ตัวเลขที่ Inco โพสต์บน X (144 tok/s บน M5 Max) มาจากเครื่องที่แรงกว่า ตัวเลขในบล็อกทั้งหมดวัดบน M5 Pro
ทำไมถึงเร็ว
- DFlash 2 draft คือเส้นทาง decode หลัก ไม่ใช่ตัวเลือกเสริม ทุกโมเดลมี draft ที่เทรนมาเฉพาะ (ของ 27B หนัก 1.2 GiB บวกน้ำหนักหลัก 15 GiB) ขั้น draft, verify, accept และอัปเดต state ถูกส่งไป GPU เป็นก้อนเดียว speculation ยังทำงานร่วมกับ batching ได้
- Paged KV cache แบบ index ด้วย prefix และสำหรับโมเดล hybrid จะ snapshot state ของ Gated DeltaNet ที่ขอบ prefix ไว้ ทำให้ใช้ cache ซ้ำได้ทั้งในชั้น recurrent ด้วย
- Kernel เขียนเฉพาะรูปทรง ซึ่ง Inco บอกว่าให้ “kernel agents” ภายในบริษัทเขียน kernel แยกสำหรับ prefill และ verify อ่าน KV cache 8-bit ได้ตรง ๆ และทุกอย่าง precompile มากับ Homebrew
ติดตั้งและข้อจำกัด
brew install incoai/tap/splash
splash serve --model incoai/Qwen3.8-27B-Splash
splash claude # หรือ splash codex / splash opencode / splash hermes
Splash รองรับ API ของ OpenAI Chat Completions และ Responses รวมถึง Anthropic Messages ทั้ง streaming, tool call, JSON Schema, รูปภาพ และ PDF และมีให้ใช้ใน LM Studio Bionic เป็น runtime ตั้งแต่วันแรก ข้อจำกัดคือ:
- ต้องใช้ M3 ขึ้นไป (Apple GPU family 9), macOS 26.4+ และแรมอย่างน้อย 36GB (แนะนำ 48GB) Mac รุ่น M1/M2 ใช้ไม่ได้เลย
- รองรับแค่สองโมเดล และตั้งใจไม่มี fallback ไปใช้โมเดลอื่น ถ้าอยากใช้โมเดลอื่นต้องรอ Inco ทำแพ็กเกจให้
- benchmark ทั้งหมดวัดโดย Inco และแต่ละ engine รันด้วยค่าที่ตัวเองแนะนำ Inco บอกเองว่านี่คือการเทียบผลรวมแบบ end-to-end ไม่ใช่การแยกผลของแต่ละเทคนิค
1.0.2 เพิ่มความเร็ว decode แบบ batch 2–4 บน M3 Max อีก 53–74% สำหรับ 27B เพิ่ม --default-reasoning-effort และเพิ่ม API ใหม่ /v1/judgments สำหรับให้คะแนนอย่างเดียว
มุมมอง AI Curator
Splash คือหลักฐานว่า การเลิกพยายามรองรับทุกโมเดล ให้ผลที่วัดได้จริง ช่องว่าง 2–7 เท่าไม่ได้มาจากเทคนิคลับ มาจากการยอมทำงานเฉพาะทาง: เทรน draft ต่อโมเดล เขียน kernel ต่อรูปทรง และคำนวณหน่วยความจำต่อเครื่อง Inco ทำได้เพราะใช้ agent เขียน kernel ต้นทุนการ “ทำใหม่ทุกโมเดล” จึงต่ำพอ ถ้าแนวทางนี้ได้ผล engine ทั่วไปอย่าง oMLX หรือ llama.cpp จะเจอแรงกดดันให้มีเส้นทางเฉพาะสำหรับโมเดลยอดนิยม ส่วน engine เฉพาะทางต้องตามโมเดลใหม่ให้ทัน ซึ่งเป็นคำถามว่า Inco ซึ่งมีธุรกิจหลักเป็น inference บน GPU ศูนย์ข้อมูล จะดูแลโปรเจกต์ฟรีนี้ต่อเนื่องแค่ไหน
สำหรับนักพัฒนาไทยที่ใช้ MacBook ทำงาน ตัวเลขที่ควรดูคือ 282 ms ต่อรอบเมื่อใช้ cache ไม่ใช่ tok/s ตัวนี้คือสิ่งที่ทำให้ coding agent แบบ local ใช้งานได้จริงเมื่อบริบทยาวถึงหลักหมื่น token ข้อควรระวังคือต้องมี M3 และแรม 48GB ซึ่งยังเป็นเครื่องราคาสูง ทางที่ดีคือลองกับ repo จริงของตัวเองแล้ววัดเทียบกับ engine ที่ใช้อยู่ ก่อนเชื่อตัวเลขในบล็อก
แหล่งข่าว
อ่านเพิ่มในหมวด เครื่องมือนักพัฒนา
Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ
Betelgeuse ฟอร์ก llama.cpp ที่เปิดเมื่อ 31 ต.ค. ดึง expert จาก NVMe เข้า VRAM ตามต้องการ อ้าง 22 tok/s แบบไม่ทิ้ง expert แต่ README เตือนเองว่ายังทดลองและตัวเลขมาจากคนละรอบ วันเดียวกันผู้พัฒนา Basalt เผยผลวัดว่าแฟล็กเร่งความเร็วทำคุณภาพ Q8 ตกไปใกล้ Q2
กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง
ต่อจากที่เราพบกฎนี้ในไบนารี Claude Code ผู้ใช้เริ่มรายงานว่างานเชิงพาณิชย์ถูกปฏิเสธ และ Tom's Hardware กับ Mashable หยิบไปรายงาน แต่เมื่อไล่ issue ที่อ้างถึง พบว่าหลายรายการเกิดก่อนกฎจะมา จึงน่าจะเป็นตัวกรองด้านไซเบอร์ ส่วน Anthropic ยังไม่ชี้แจง
Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้
รายงานอิสระพบว่าฟีเจอร์ agent_summary ของ Claude Code ส่ง transcript เต็มของ background agent ไปถามสถานะทุก ~30 วินาที คิดเป็น 16.4% ของค่าใช้จ่ายในระบบของผู้วัด Issue เปิดมาตั้งแต่ ส.ค. ยังไม่มีสวิตช์ปิดที่รองรับ เราตรวจพบโค้ดนี้ใน 2.1.314 และพบกฎใหม่เรื่องเกมที่ไม่อยู่ใน changelog