Magnitude — inference engine ในเครื่องที่จูน kernel บนฮาร์ดแวร์ของคุณเอง อ้างถอดรหัสเร็วกว่า llama.cpp 92% บน Mac แต่ตัวเลขมาจากโมเดลเดียว และฝั่งตัวเองบีบ KV cache เหลือ 8/4 บิต ขณะที่ llama.cpp ใช้ 16 บิต

30 ก.ย. 2026 Anders และ Tom ผู้ก่อตั้ง Magnitude (Y Combinator รุ่น S25) โพสต์ Launch HN เปิดตัว “inference engine for agents that optimizes itself for your exact hardware” เป็น engine สำหรับรันโมเดลเปิดในเครื่อง สัญญาอนุญาต Apache-2.0 แจกเป็นแอปเดสก์ท็อปพร้อม CLI สำหรับ macOS, Windows และ Linux และพาดหัวว่า เร็วกว่า llama.cpp ได้ถึง 2 เท่า ถึงเช้า 1 ต.ค. repo (สร้างไว้ตั้งแต่ มิ.ย.) มีดาวราว 5,800 ดวง และทีมออก @magnitudedev/cli 0.2.1–0.2.3 ติดกันสามรุ่นภายใน 12 ชั่วโมง

ที่ต่างจาก llama.cpp, Ollama หรือ LM Studio คือ engine เหล่านั้นแจก kernel ที่คอมไพล์ไว้แล้วสำหรับฮาร์ดแวร์กว้าง ๆ ส่วน Magnitude เขียน kernel ที่มีพารามิเตอร์ปรับได้ แล้วจูนบนเครื่องจริงของผู้ใช้ก่อนรันโมเดล ผู้ก่อตั้งตอบในเธรดว่าการจูน “takes around ~1 minute whenever you download a new model” และทำครั้งเดียวต่อโมเดล

ตัวเลขที่อ้าง และเงื่อนไขที่ต้องอ่านประกอบ

กราฟใน README เทียบกับ llama.cpp บน Qwen 3.6 35B-A3B แบบ 4-bit, context 64k, ไม่มี speculative decoding:

ฮาร์ดแวร์	Prefill (tok/s)	Decode (tok/s)
Mac M4 Pro 48 GB (Metal)	466 → 507 (+9%)	30 → 57 (+92%)
DGX Spark (CUDA)	2,033 → 2,507 (+23%)	49 → 58 (+19%)

โพสต์บน HN ยังระบุว่าใช้หน่วยความจำต่อเซสชันเอเจนต์น้อยลง 28% บน Mac และ 27% บน DGX Spark

เมื่อมีคนในเธรดถามถึงวิธีวัด ผู้ก่อตั้งอธิบายว่าเป็นงานง่าย ๆ คือใส่เนื้อหา Moby Dick จนเต็ม 64k แล้วสั่งให้ทวนส่วนท้าย ฝั่ง llama.cpp เปิด flash attention และใช้ batch size ค่าเริ่มต้น แต่มีรายละเอียดสำคัญที่ไม่ได้อยู่ในกราฟ คือ Magnitude บีบ KV cache เหลือ key 8 บิตและ value 4 บิต (ได้แรงบันดาลใจจาก TurboQuant) ส่วน llama.cpp ใช้ KV 16 บิต เพราะทีมบอกว่าเมื่อลอง quantize KV แบบเดียวกันใน llama.cpp แล้ว decode ช้าลงมาก ที่ context 64k ซึ่ง decode ถูกจำกัดด้วยแบนด์วิดท์หน่วยความจำ ส่วนต่าง 92% บน Mac จึงน่าจะมาจาก KV ที่เล็กลงมากพอสมควร ไม่ได้มาจากการจูน kernel อย่างเดียว ผู้ก่อตั้งอ้างว่าทดสอบด้วยชุด retrieval ที่อิง RULER แล้วไม่เห็นผลเสียต่อคุณภาพบริบทยาว แต่ยังไม่มีตัวเลขจากคนนอก

ส่วนการเทียบกับ MLX ทีมตอบเพียงว่า “we’ve done some rough benchmarking and we are outperforming any of the MLX-based engines” และจะเผยแพร่ผลละเอียดภายหลัง ซึ่งยังไม่มีตัวเลขให้ตรวจ

สิ่งที่ได้ และข้อจำกัดตอนนี้

• แคตตาล็อกจำกัด ตอนนี้ magnitude.dev/models มี 15 โมเดล เช่น Qwen3.8 27B, Gemma 4 (31B, 26B-A4B, 12B, E4B), Qwen3.6 35B-A3B, Muse Glimmer 30B, Nemotron 3.5 Lightning 30B-A3B, MiniCPM5 และ LFM2.5 เพราะทีมเลือกเขียน kernel เฉพาะสถาปัตยกรรมยอดนิยม ไม่ได้พยายามรองรับ GGUF ทุกไฟล์แบบ llama.cpp ผู้ก่อตั้งบอกว่า Qwen3.8-Flash-Next จะตามมา “very soon”
• Speculative decoding ในการใช้งานจริง แต่ละโมเดลในแคตตาล็อกมี drafter กำหนดไว้แล้ว (DFlash, DFlash2 หรือ DSpark) ความเร็วในการใช้งานจริงจึงต่างจากตัวเลขเบนช์มาร์กซึ่งปิดส่วนนี้ไว้
• หน่วยความจำยืดหดได้ จองไว้แค่น้ำหนักโมเดล แล้วขยาย KV heap ตามเซสชันที่ยาวขึ้น และคืนหน่วยความจำเมื่อเอเจนต์หยุด หลายเซสชันใช้ prefix cache ร่วมกันได้ (แนวคิดแบบ radix attention ของ SGLang)
• เชื่อมต่อเอเจนต์ แบบคลิกเดียวกับ Pi, OpenCode, Hermes, OpenClaw, Codex, Claude Code, Oh My Pi และ Cline เครื่องมืออื่นใช้ API แบบ OpenAI-compatible ได้ และโมเดลจะเปิดเมื่อเอเจนต์เรียก แล้วปิดเองเมื่อไม่มีการใช้งาน
• ยังไม่รองรับ หลาย GPU (อยู่ใน roadmap ระยะใกล้) ฝั่ง AMD และ Strix Halo ใช้ Vulkan ยังไม่มี ROCm มีผู้ใช้รายงานว่าขั้นตอนประเมินฮาร์ดแวร์ค้าง (issue #142) และผู้ก่อตั้งยอมรับว่าบน M5 อาจยังใช้ matmul hardware ของ Metal 4 ได้ไม่เต็มที่
• รูปแบบธุรกิจ เมื่อถูกถามตรง ๆ ผู้ก่อตั้งตอบว่าในอนาคตจะทำ inference cloud คิดเงินต่อโทเคน สำหรับงานแบบ hybrid ที่สลับระหว่างโมเดลในเครื่องกับบนคลาวด์ได้โดยไม่ทำให้ prefix cache พัง

มุมมอง AI Curator

ไอเดียหลักของ Magnitude คือจูน kernel บนเครื่องผู้ใช้แทนการแจก binary สำเร็จรูป ซึ่งเป็นแนวทางที่ถูกต้อง และเป็นวิธีเดียวกับที่ TVM และ autotuner ของ Triton ใช้ในฝั่งดาต้าเซ็นเตอร์มานาน แต่พาดหัว “2 เท่าของ llama.cpp” ยังไม่ควรเชื่อทั้งหมด เพราะทดสอบกับโมเดลเดียว ใช้งานเดียว และสองฝั่งใช้ KV cache ต่างความละเอียดกัน ตัวเลขที่ยุติธรรมกว่าคือรัน llama.cpp แบบ -ctk q8_0 -ctv q4_0 บนงานเดียวกัน แล้วรายงานว่าช้าลงเท่าไรจริง ๆ ข่าวดีคือโค้ดเบนช์มาร์กเปิดอยู่ใน repo ใครก็ตรวจสอบเองได้ ซึ่งดีกว่า engine ปิดหลายตัวที่เคยอ้างตัวเลขทำนองเดียวกัน

สำหรับนักพัฒนาในไทยที่รันเอเจนต์บน MacBook หรือมินิพีซีที่หน่วยความจำจำกัด จุดที่น่าลองมากกว่าความเร็วคือ KV cache ที่เล็กลงเกินครึ่ง และหน่วยความจำที่คืนเมื่อเอเจนต์หยุด เพราะ context ยาวของงาน coding agent มักทำให้เครื่อง 32–48 GB ใช้งานอย่างอื่นไม่ได้ ข้อแนะนำคือลองกับโมเดลที่อยู่ในแคตตาล็อก (Qwen3.8 27B หรือ Gemma 4) แล้วเทียบกับ llama.cpp หรือ oMLX บนงานจริงของทีม ไม่ใช่ prompt ทวน Moby Dick และควรจำไว้ว่าเป้าหมายระยะยาวของบริษัทคือคลาวด์แบบจ่ายต่อโทเคน ตัว engine ในเครื่องเป็น Apache-2.0 ก็จริง แต่ทิศทางของผลิตภัณฑ์อาจเปลี่ยนตามรายได้ได้

แหล่งข่าว

• magnitudedev/magnitude — GitHub (README และกราฟเบนช์มาร์ก)
• Launch HN: Magnitude (YC S25) – Self-optimizing inference engine for agents
• Magnitude model catalog