llama.cpp กับ SGLang รองรับ decision model แล้ว: llama.cpp เพิ่ม /v1/systemone พร้อม 5 โมเดลตั้งแต่ 144M ถึง 27B (ตามด้วย Nimble และ Clef) ส่วน SGLang 0.5.21 ใช้ /v1/decisions เปลี่ยน chat model ตัวไหนก็ได้ให้เป็นตัวจำแนก

ตอนนี้ runner แบบ self-host ที่นักพัฒนาใช้มากที่สุดรองรับ “โมเดลตัดสินใจ” ครบแล้ว เมื่อ 2 ต.ค. 2026 เวลา 09:56 UTC llama.cpp merge PR #29818 ที่เพิ่ม endpoint /v1/systemone ให้ llama-server และในวันเดียวกัน Xuan-Son Nguyen กับ Victor Mustar ก็เขียนบทความ New in llama.cpp: Decision Models ลงบล็อก Hugging Face ส่วน SGLang v0.5.21 ออกเมื่อ 2 ต.ค. 01:09 UTC และมี Decisions API (/v1/decisions) อยู่ในรายการ key features

ทั้งสองโปรเจกต์ใช้รูปแบบ System One ที่มาจาก Jev ของ TypeSafe เหมือนที่ Ollama 0.35 ทำไปเมื่อ 28 ก.ย. คือส่ง state กับคำถามที่ระบุชนิดไว้ แล้วได้ความน่าจะเป็นของทุกตัวเลือกกลับมา ไม่ต้องสร้างข้อความและไม่ต้อง parse JSON บล็อกของ ggml-org บอกว่า client เดิม “only need a new base URL” ผลคือโค้ดที่เขียนไว้เรียก Jev ตอนนี้ย้ายมารันบน GPU ของเราเองได้ทั้งบน llama.cpp, Ollama และ SGLang

llama.cpp: 5 โมเดลพร้อม GGUF ตั้งแต่วันแรก

ตารางจากบล็อก (ความเร็วคือ median เวลาตอบคำถามหนึ่งข้อบน NVIDIA RTX PRO 6000 หนึ่งใบ)

โมเดล	ขนาด	ต่อยอดจาก	ภาษา	ภาพ	License	ความเร็ว
Julia-1	144M	mmBERT-small	50+	ไม่	Apache 2.0	3 ms
Laya	421M	ModernBERT-large	อังกฤษ	ไม่	Apache 2.0	5 ms
Kev-4B	4B	Qwen3.5-4B-Base	อังกฤษ	ไม่	Apache 2.0	12 ms
lev	4B	Qwen3.5-4B	อังกฤษ	ไม่	Apache 2.0	36 ms
OpenJev	27B	Qwen3.8-27B	en, de, fr, hi, zh, ja	ได้	CC BY-NC 4.0	43 ms

ในคำอธิบาย PR ผู้เขียนบอกว่า decision model “are just fancy wrappers around traditional embedding models” การแก้ใน libllama จึงมีไม่มาก ส่วนหลักอยู่ที่ server_decision_context ซึ่งเลือกวิธีจัดการ input และ output ตาม metadata {arch}.decision.type ใน GGUF PR ยังมีตารางเทียบผลกับ implementation ต้นฉบับด้วย ค่าความน่าจะเป็นที่ต่างกันมากที่สุดอยู่ระหว่าง 1.8e-4 (OpenJev) ถึง 2.2e-2 (Julia-1)

หลังจากนั้นมีโมเดลตามมาอีกสองตระกูล

• Nimble 9B ของ Bespoke Labs (PR #29844) merge เมื่อ 2 ต.ค. 12:56 UTC
• Clef และ Clef-flash ของ Cloudflare (PR #29831) merge เมื่อ 3 ต.ค. 00:50 UTC ผู้เขียน PR บอกว่า Clef “significantly more complicated” เพราะเฉลี่ยค่าบนช่วง token ของคำถามและตัวเลือกแต่ละตัว จึงต้องเพิ่ม API ใหม่ llama_batch_ext_set_decision_order ข้อจำกัดตอนนี้คือยังรับเฉพาะข้อความ (ภาพต้องรอ PR #29622) และทำได้หนึ่ง sequence ต่อ batch ส่วนเอกสาร server ระบุว่า server ที่รัน Clef จะให้บริการได้แค่ endpoint นี้ สร้างข้อความไม่ได้

ข้อควรรู้เรื่องเวอร์ชัน release ล่าสุดตอนที่เขียนคือ b11368 (ออก 3 ต.ค. 02:35 UTC) ซึ่ง build จาก commit ของวันที่ 2 ต.ค. 14:52 UTC จึงมี /v1/systemone กับ Nimble อยู่แล้ว แต่ยังไม่มี Clef ถ้าต้องการ Clef วันนี้ต้อง build จาก master เอง

เรียกใช้อย่างไร

ตัวอย่างจากบล็อกของ ggml-org

llama serve -hf ggml-org/Kev-4B-GGUF

curl http://localhost:8080/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Customer message: I was charged twice for my order last week and nobody has replied.",
    "questions": {
      "route":   { "type": "choice", "instructions": "Which team should handle this?",
                   "criteria": { "billing": "payments, charges, refunds, invoices",
                                 "shipping": "delivery, tracking, lost or late parcels",
                                 "technical": "bugs, errors, login problems" } },
      "angry":   { "type": "noul",  "instructions": "Is the customer angry?" },
      "urgency": { "type": "score", "instructions": "How urgent is this?",
                   "criteria": ["can wait", "this week", "today", "right now"] }
    }
  }'

คำตอบที่บล็อกแสดงไว้คือ route ได้ billing ที่ 0.9049, angry (noul) ได้ 0.8208 และ urgency ได้ score 2.2821 ส่วน usage รายงาน output_tokens: 0 เสมอ เพราะโมเดลไม่ได้สร้าง token เลย

รายละเอียดที่ควรรู้ก่อนใช้งานจริง

• ภาพ ตอนนี้มีแค่ OpenJev ที่รับภาพได้ ใส่เป็น data URL ในฟิลด์ images หรือใส่เป็น image_url ใน state ที่เป็นรายการ chat messages ก็ได้ ตัว projector ดาวน์โหลดให้อัตโนมัติ
• router mode สั่ง llama serve โดยไม่ระบุโมเดล แล้วเลือกโมเดลผ่านฟิลด์ model ในแต่ละคำขอ เช่น ggml-org/Julia-1-GGUF:Q8_0
• จำนวนตัวเลือกขึ้นกับโมเดล เอกสาร server ระบุว่า OpenJev รับได้ 52 ตัวเลือก ส่วน Laya กับ Clef รับได้ 255 คำถามชนิด score รับ 2–10 ระดับ และยังไม่รองรับ streaming
• ต้องเขียนคำอธิบายตัวเลือก บล็อกยกตัวอย่างว่า Julia-1 ส่ง “I was charged twice” ไปที่ shipping เมื่อตัวเลือกมีแค่ชื่อ แต่เมื่อเพิ่มคำอธิบายให้ทุกตัวเลือก มันเลือก billing ที่ 0.99
• เกณฑ์ confidence ต้องตั้งแยกตามโมเดล ticket คลุมเครือข้อเดียวกันได้ 0.25 จาก Julia-1 แต่ได้ 0.80 จาก Kev-4B เอกสารเขียนไว้ตรง ๆ ว่าความน่าจะเป็น “are not guaranteed to be calibrated for your data”

SGLang 0.5.21: ใช้ chat model ตัวไหนก็ได้

SGLang ใช้แนวทางที่ต่างออกไป /v1/decisions ไม่ต้องใช้ checkpoint เฉพาะ เอกสารอธิบายว่ามัน “turns a chat model into a decision model” โดยอ่านความน่าจะเป็นของ label คำตอบ (A–Z, 0–9 หรือ yes/no) จาก next-token logits ณ ตำแหน่งที่โมเดลจะตอบ ทุกคำถามถูกให้คะแนนใน score_prompts ครั้งเดียว และ server เดิมยังให้บริการ /v1/chat/completions ต่อได้ตามปกติ โมเดลที่ทีมทดสอบแล้วคือ Qwen3.8-27B และ Qwen3.5-35B-A3B แบบ BF16 บน H200 หนึ่งใบ ถ้าเป็นโมเดลอื่น server จะตรวจทีละคำขอ และตอบ 400 พร้อมบอกเหตุผลถ้าใช้ไม่ได้ เช่น label ไม่ใช่ token เดียว หรือ template ทำให้คำตอบไปอยู่ในบล็อก reasoning

PR #41208 ที่ใส่ฟีเจอร์นี้ยังเพิ่ม route /v1/systemone ที่ SDK ทางการของ System One ทั้ง Python และ JS เรียกได้โดยเปลี่ยนแค่ base URL ผู้เขียน PR รายงานว่าเครื่องมือ jevcompat (ไม่ใช่ของทางการ) ตรวจผ่านครบ 32 ข้อ MUST และบอกข้อจำกัดไว้ตรงไปตรงมา

• confidence เป็นค่าที่ ยังไม่ calibrate เกณฑ์ที่จูนไว้กับผู้ให้บริการอื่นอาจใช้ไม่ได้
• คำตอบเปลี่ยนได้ตามองค์ประกอบของ batch และ prefix cache บน Qwen แบบ hybrid attention ความน่าจะเป็นขยับได้ถึงประมาณ 0.07
• SDK มี timeout 10 วินาทีแล้ว retry การทดสอบที่ส่ง 62 คำถามบน state ยาว 31k token ใช้เวลาราว 9.5 วินาที ถ้าคำขอใหญ่ควรตั้ง timeout ให้ยาวขึ้น

ใน release เดียวกันยังมี

• /v1/score ที่ให้คะแนนผู้สมัครทั้งชุดในคำขอเดียว
• prefix cache ที่รันบน core ภาษา Rust เป็นค่าเริ่มต้น ถ้าการตั้งค่าใดที่ Rust ยังไม่รองรับจะถอยไปใช้ Python เอง และบังคับใช้ Python ได้ด้วย SGLANG_UNIFIED_RADIX_TREE_CORE_BACKEND=python
• DeepSeek-V4.1 ได้ first token เร็วขึ้น 22% สำหรับ prompt ยาว
• Kimi K3 ได้ prefill throughput เพิ่ม 20.6% เมื่อใช้ PD disaggregation (ตัวเลขใน PR คือ 9,667 → 11,654 input tok/s ที่ 8k/C16 เทียบ TP8 PP1 กับ TP4 PP2)

มีอีกจุดที่อาจทำให้ระบบเดิมพัง คือ chat_template ที่ส่งมากับคำขอผ่าน chat_template_kwargs จะถูกปฏิเสธ ยกเว้นเปิด --trust-request-chat-template ไว้

แถม: llama.cpp รองรับ MTP ของ Qwen3.8-Flash-Next

PR #29761 merge เมื่อ 1 ต.ค. เพิ่ม multi-token prediction ให้ Qwen3.8-Flash-Next ผลวัดบน DGX Spark ด้วยไฟล์ iq4_xs (--spec-type draft-mtp --spec-draft-n-max 3) บน speed-bench บางส่วน 24 prompt ได้ decode เฉลี่ยจาก 28.36 เป็น 43.88 tok/s (1.55x) และ acceptance 0.640 หมวด multilingual ได้มากที่สุด (1.67x, acceptance 0.778) ส่วน roleplay ได้น้อยที่สุด (1.45x)

ชื่อ PR “Qwen4Exp” อาจทำให้เข้าใจผิด ชื่อนี้มาจากสถาปัตยกรรมใน config.json ของ Qwen3.8-Flash-Next เอง (Qwen4ExpForConditionalGeneration) ไม่ได้แปลว่า Qwen 4 ออกแล้ว

มุมมอง AI Curator

เมื่อหนึ่งเดือนก่อน System One เป็นแค่ API ของสตาร์ทอัปที่ยังเปิดแบบ waitlist ตอนนี้ runner หลักทั้งสามตัว (Ollama, llama.cpp, SGLang) ใช้ endpoint นี้แล้ว นี่คือตัวอย่างการเกิดมาตรฐานโดยพฤตินัยที่เร็วที่สุดตั้งแต่ /v1/chat/completions สิ่งที่ทีมพัฒนาได้คือความสามารถในการย้ายผู้ให้บริการ เริ่มทดลองกับ API ที่โฮสต์ไว้ได้ แล้วย้ายมารันในเครื่องโดยไม่ต้องแก้โค้ด

ที่น่าสนใจกว่าคือสองโปรเจกต์มองโจทย์นี้ต่างกัน llama.cpp มองว่าเป็นโมเดลเฉพาะทาง (มี head แยก เร็วระดับมิลลิวินาที) ส่วน SGLang มองว่าเป็นวิธีอ่านค่าจาก chat model ที่มีอยู่แล้ว ถ้าทีมของคุณรัน Qwen3.8-27B บน vLLM หรือ SGLang อยู่แล้ว การอัปเกรดเป็น 0.5.21 ก็ได้ตัวจำแนกมาโดยไม่ต้องจองหน่วยความจำ GPU เพิ่ม แต่ข้อจำกัดเรื่องค่าที่ไม่ deterministic เมื่อใช้ prefix cache ต้องคิดให้ดี ถ้าจะใช้ผลลัพธ์ไปตัดสินอะไรที่ต้องตรวจสอบย้อนหลังได้

สำหรับทีมไทย ตารางของ llama.cpp ยังบอกข้อเท็จจริงที่ไม่ค่อยดีนัก ในห้าโมเดลมีแค่ Julia-1 ที่อ้างว่ารองรับ 50+ ภาษา ซึ่งน่าจะรวมภาษาไทยด้วย แต่เป็นโมเดลเล็กที่สุดในตาราง (144M) ส่วน OpenJev ที่เก่งที่สุดไม่มีภาษาไทยในรายการและใช้ license CC BY-NC 4.0 ห้ามใช้เชิงพาณิชย์ ไฟล์ NOTICE ระบุว่า Apache-2.0 ครอบคลุมแค่โค้ดใน helper/ กับ serve/ ไม่รวมน้ำหนัก ตัวเลือกที่ใช้เชิงพาณิชย์ได้และน่าจะทนภาษาไทยได้ดีกว่าจึงเป็น Clef ที่ต่อยอดจาก Qwen3.8 หรือ pplx-decider-v1-27b ของ Perplexity (Apache-2.0) หรือใช้ /v1/decisions ของ SGLang กับ Qwen ตัวที่ใช้อยู่แล้ว ไม่ว่าจะเลือกทางไหน ควรเตรียมชุด ticket ภาษาไทยที่ติดป้ายไว้แล้วมาวัดเอง เพราะทุกโปรเจกต์ย้ำตรงกันว่าค่าความน่าจะเป็น “ยังไม่ calibrate กับข้อมูลของคุณ”

แหล่งข่าว

• New in llama.cpp: Decision Models — Hugging Face Blog (ggml-org, 2 ต.ค. 2026)
• llama.cpp PR #29818: add /v1/systemone API (merge 2 ต.ค. 2026) และ PR #29831: Clef support (merge 3 ต.ค. 2026)
• SGLang v0.5.21 release notes — GitHub (2 ต.ค. 2026) และ เอกสาร Decision models ของ SGLang
• llama.cpp PR #29761: Qwen4Exp MTP (merge 1 ต.ค. 2026)