โมเดลที่ไม่เขียนข้อความ: d3-turbo 27B กำลังเปลี่ยนกติกา AI หรือแค่สงครามตัวเลข?
โมเดลที่ไม่เขียนข้อความ: d3-turbo 27B กำลังเปลี่ยนกติกา AI หรือแค่สงครามตัวเลข? โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI และระบบเปิด | ตรวจสอบข้อมูล ณ 20 ต.ค. 2026 บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์

โดย Nokka (นก-กา) | นักเขียนอิสระสาย AI และระบบเปิด | ตรวจสอบข้อมูล ณ 20 ต.ค. 2026
บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)
วันที่ 19 ตุลาคม 2026 ทีม vLLM Semantic Router ปล่อยโมเดลชื่อ d3-turbo บน Hugging Face
โมเดลนี้มี 26,090 ล้านพารามิเตอร์ รวมตัวเข้ารหัสภาพอีก 460 ล้าน และใช้สัญญาอนุญาต Apache 2.0
ถ้าคุณโหลดมันขึ้นมาแล้วพิมพ์คำถาม จะไม่มีข้อความตอบกลับมา
คำตอบที่ได้มีเพียง ความน่าจะเป็น ของตัวเลือกที่คุณกำหนดไว้ล่วงหน้า
ยกตัวอย่าง ถ้าส่งข้อความลูกค้าว่า "ยอดใบแจ้งหนี้ผิดหลังเปลี่ยนแพ็กเกจ" แล้วถามสองคำถามพร้อมกันว่าเรื่องนี้ควรไปทีมไหน และลูกค้าเร่งด่วนไหม
คำตอบที่ได้มีเพียงชุดความน่าจะเป็นสำหรับแต่ละตัวเลือก ไม่ใช่ประโยคอธิบาย
ผมคิดว่านี่คือจุดที่น่าสนใจของวงการตอนนี้ เพราะมันคือการยอมรับว่างานจำนวนมากในระบบเอเจนต์ไม่ต้องการการเขียนข้อความเลย
ชื่อ vllm-sr ย่อจาก vLLM Semantic Router ซึ่งเป็นโปรเจกต์ของชุมชน vLLM บน GitHub
repo vllm-project/semantic-router มีดาว 6,224 ดวง ถูก fork 1,060 ครั้ง เขียนด้วยภาษา Go และเปิดตัวครั้งแรกเมื่อ 26 ส.ค. 2025
หน้าที่ของ router คือตัดสินใจว่าคำขอหนึ่งควรไปโมเดลไหน หรือควรถูกจัดการแบบไหน
งานแบบนี้เดิมทำด้วยการเรียก LLM ตัวใหญ่แล้วอ่านคำตอบ
แต่การเรียก LLM เพื่อตอบคำถามใช่หรือไม่ใช่หนึ่งครั้ง เปลืองทั้งเวลาและเงินเกินความจำเป็น
d3-turbo จึงย้ายงานตัดสินใจออกมาเป็นโมเดลแยก ที่ให้คำตอบแบบมีโครงสร้างและมีความน่าจะเป็นกำกับ
จุดขายของ d3-turbo ไม่ใช่ความแม่น แต่เป็นจำนวนครั้งที่มันอ่านข้อมูลเข้า
โมเดลอ่านภาพหนึ่งครั้ง แล้วตอบทุกคำถามจากภาพนั้น
คู่แข่งในตระกูลเดียวกันคือ d3-flash ซึ่งอ่านภาพใหม่ทุกคำถาม
ผลวัดบนการ์ด AMD Instinct MI325X หนึ่งใบ ด้วย AutoModel ตัวเลขทั้งชุดเป็นค่ากลาง (p50)
จุดตัดอยู่ที่คำถามที่สี่ ตั้งแต่ข้อสี่เป็นต้นไปตัวใหญ่กว่าชนะ และที่ 255 คำถามมันเร็วกว่า 15.5 เท่า
เหตุผลเชิงคณิตศาสตร์ตรงไปตรงมา การอ่านภาพจ่ายครั้งเดียว ส่วนการตอบเพิ่มขึ้นตามจำนวนคำถาม
ถ้าให้ผมเดา คนส่วนใหญ่จะจำแค่ตัวเลข 15.5 เท่า แล้วเหมารวมว่ารุ่นใหญ่คุ้มกว่าในทุกกรณี
แต่บรรทัดที่สำคัญกว่าคือบรรทัดแรก ที่บอกว่าถ้าถามคำถามเดียว d3-flash เร็วกว่าเท่าตัว
ผู้อ่านที่คิดว่ามันคือ classifier ธรรมดา ควรดูรายการนี้ก่อน
สองประเภทหลังทำให้มันไม่ใช่ classifier ข้อความอีกต่อไป แต่อ่านภาพและวิดีโอได้ด้วย
บริบทสูงสุดอยู่ที่ 131,072 โทเคนต่อหนึ่งคำถาม เมื่อเปิดโหมด long_context=True และค่าเริ่มต้นอยู่ที่ 32,768
จุดที่ผมชอบในเอกสารคือประโยคที่บอกว่า ถ้าคำถามยาวเกินขีดจำกัด ระบบจะตอบกลับด้วยข้อผิดพลาด max_length_exceeded และไม่ตัดข้อความทิ้ง
การไม่ตัดข้อความเงียบ ๆ คือพฤติกรรมที่ระบบ production ควรมี และหลายบริการขนาดใหญ่ยังทำผิดข้อนี้
หน้าโมเดลมีโค้ดตัวอย่างสั้น ๆ ที่แสดงวิธีถามหลายคำถามจากการอ่านครั้งเดียว
result = model. system_one ( state = " ผู้ใช้แจ้งว่ายอดใบแจ้งหนี้ผิดหลังเปลี่ยนแพ็กเกจ ", questions = { " route ": { " type ": " choice ", " instructions ": " ทีมไหนควรรับเรื่องนี้ ", " criteria ": { " billing ": " การเงิน ", " tech ": " เทคนิค " }}, " urgent ": { " type ": " noul ", " instructions ": " ลูกค้าเร่งด่วนหรือไม่ " }, }, ) Enter fullscreen mode Exit fullscreen mode ผลลัพธ์ที่ได้คือความน่าจะเป็นของแต่ละตัวเลือก ไม่ใช่ประโยคอธิบาย
หมายเหตุ: noul คือชื่อชนิดคำถามแบบใช่หรือไม่ใช่ในสคีมาของโมเดล เดียวกับหัวข้อ Yes / No ด้านบน
ดัชนีนี้ชื่อ Jev Decision Index จัดอันดับงานก็อปแบบเปิดของโมเดล Jev และคณะผู้จัดทำเปิดวิธีคำนวณไว้ให้ตรวจได้ทั้งหมด
เหตุผลที่ให้ชุดปิดทักษะเดียวกันหนักถึงครึ่งหนึ่งคือ ไม่มีใครเทรนบนชุดปิดได้
และอีกเกือบหนึ่งในสามให้กับโจทย์โดเมนใหม่ เพื่อดูว่าทักษะของโมเดลลากไปใช้ที่อื่นได้จริง หรือแค่เก่งในกระดานที่รู้กัน
กฎอีกข้อที่ผมชอบคือ กลุ่มที่คะแนนห่างกันไม่เกิน 0.9 คะแนนจะได้อันดับเท่ากัน
ตัวเลข 0.9 นี้มาจากการคำนวณว่า ถ้าสุ่มคำถามประเภทเดียวกันมาอีกชุด ความต่างที่เกิดจากความบังเอิญจะอยู่ราวเท่านี้ 95% ของเวลา
กฎนี้กันการอวดว่า "ชนะ 0.1 คะแนน" ซึ่งเป็นปัญหาใหญ่ของวงการ benchmark
หน้ากระดานของดัชนีเปิดข้อมูลดิบให้ดาวน์โหลด ผมดึงไฟล์ index.json มาคำนวณเองเมื่อ 20 ต.ค. 2026
ไฟล์นั้นสร้างเมื่อ 16 ต.ค. 2026 มี 173 รายการที่ได้คะแนน และกระดานรุ่น 0.3.2 มี 174 แถว เมื่อนับแถวอ้างอิง Jev 1.14
อันดับตามคะแนนเต็ม ซึ่งเป็นตัวเลขพาดหัวของกระดาน มีหน้าตาแบบนี้
จุดที่น่าสนใจอยู่ที่ clef ไม่ได้แย่ทุกด้าน คะแนนชุดสาธารณะของมันบนสเกลเดียวกับคะแนนเต็มคือ 61.71 ส่วน d3 ได้ 65.45 ซึ่งห่างกันไม่มาก
แต่พอเติมชุดปิดเข้าไป คะแนนรวมของ clef ตกลงเหลือ 53.08 หายไป 8.63 คะแนน
ทางฝั่ง d3 กลับขยับขึ้นจาก 65.45 เป็น 66.26 คือได้เพิ่ม 0.81 คะแนน
ตัวเลขสองชุดนี้ต้องเทียบกันบนสเกลเดียวกันเสมอ ไม่ใช่เทียบคะแนนดิบกับคะแนนที่แปลงสเกลแล้ว
ช่องว่างนี้คือสิ่งที่ดัชนีออกแบบมาให้จับได้ตรง ๆ โมเดลที่เก่งในข้อสอบที่คนเห็น แต่ตกลงเมื่อเจอข้อสอบที่ไม่มีใครเห็น
บล็อกของ Cloudflare วันที่ 1 ต.ค. 2026 เขียนถ้อยว่า Clef is currently the leader when evaluated against the Jev Decision Index
ผมต้องพูดให้เป็นธรรมกับ Cloudflare ด้วย บล็อกนั้นเก่ากว่าข้อมูลกระดานชุดนี้ 15 วัน
เราไม่มีภาพกระดาน ณ วันที่ 1 ต.ค. จึงบอกไม่ได้ว่าตอนนั้น clef นำจริงหรือไม่
แต่ข้อที่ยืนยันได้คือ คำว่า "ผู้นำ" มีวันหมดอายุ และผมคิดว่าคนอ่านมักจำประโยคนั้นไปใช้ต่ออีกหลายเดือน
ประเด็นที่ผมอยากให้จำคือ d3-turbo ไม่มีอยู่ในกระดานชุดนี้เลย
หน้าโมเดลของมันเขียนว่าได้ 70.2 คะแนน และในวงเล็บของตารางเขียนสั้น ๆ ว่า (our estimate) ส่วนอีกประโยคหนึ่งในหัวข้อ Highlights เขียนเต็มว่า Our estimate, not an official board result.
ถ้าตัวเลข 70.2 ผ่านการวัดจริง มันจะอยู่อันดับ 1 เหนือ StartLux ที่ 69.12
แต่วันนี้ยังไม่มีใครยืนยันตัวเลขนั้นนอกจากทีมที่สร้างมันเอง
ฝั่งภาพมีอีกตัวเลขที่ควรพูดถึงตั้งแต่ต้น คือดัชนีฝั่งภาพ (vision board) ซึ่ง 72.9 เป็นการประมาณของทีมผู้พัฒนาเอง ไม่ได้อยู่บนกระดาน ส่วนผลบนกระดานภาพทางการคือ 71.3 ซึ่งเป็นคะแนนของ d3 รุ่นก่อน
ผมไม่ได้บอกว่าตัวเลขเหล่านี้ไม่จริง ผมบอกว่ามันยังคนละสถานะกับตัวเลขที่คณะกรรมการวัด
คำถามที่ไม่ได้ถูกถามบ่อยพอคือ ทำไมงานตัดสินใจง่าย ๆ ต้องใช้โมเดล 26,000 ล้านพารามิเตอร์
ทีมเดียวกันมีโมเดลเล็กกว่าอยู่ในตระกูล d3 ด้วย
ตัวอย่างที่ตรวจได้คือ vllm-sr/d3-edge ซึ่งมี 594,321,600 พารามิเตอร์ หรือราว 0.6 พันล้าน เปิดตัว 10 ต.ค. 2026
โมเดลนี้อยู่บนกระดานจริง ได้คะแนนเต็ม 20.24 และคะแนนสาธารณะหลังหักโอกาสเดา 28.82
ตัวเลขนั้นต่ำกว่า d3-turbo มาก แต่ก็ย้ำคำถามเดิม คือถ้าคุณต้องการแค่จัดหมวดหมู่ข้อความลูกค้า คุณไม่จำเป็นต้องใช้โมเดล 27B
ขนาด 27B ใน d3-turbo มีเหตุผลรองรับ คือมันต้องอ่านภาพและวิดีโอ และต้องตอบหลายคำถามจากการอ่านครั้งเดียว
แต่สำหรับทีมที่อยากได้แค่ router ข้อความ การรัน 27B คือการเผา GPU ทั้งใบเพื่อทำงานที่โมเดลเล็กกว่าทำได้
ผมยังไม่เห็นตัวเลขต้นทุนต่อคำขอในหน้าโมเดล มีแต่ตัวเลขเวลา
และยังไม่เห็นการเปรียบเทียบกับทางเลือกที่ง่ายที่สุด คือเรียก LLM ตัวเล็กผ่าน prompt แล้วบังคับให้ตอบเป็น JSON
ทางเลือกนั้นมีข้อเสียเรื่องความไม่แน่นอนของรูปแบบคำตอบ ซึ่งเป็นเหตุผลจริงที่คนหันมาหา decision model
ในหน้าโมเดลของ d3-turbo ไม่มีตัวเลขต้นทุนต่อคำขอ และในบล็อกของ Cloudflare ก็มีแต่ตัวเลขเวลากับตัวอย่างลูกค้า ไม่มีต้นทุนต่อการตัดสินใจหนึ่งครั้ง
ผมไม่ได้ติดตั้งโมเดลนี้และไม่ได้รันบนเครื่องตัวเอง
ผมอ่านหน้าโมเดล วิธีคำนวณของดัชนี บล็อกของ Cloudflare ข้อมูล repo จาก GitHub และไฟล์คะแนนดิบของกระดาน
ผมตรวจเองได้เฉพาะขนาดพารามิเตอร์ จำนวนไฟล์ สัญญาอนุญาต จำนวนดาวของ repo โครงสร้างวิธีคำนวณของดัชนี และอันดับบนกระดานซึ่งผมคำนวณจากไฟล์ดิบ
ส่วนที่ผมตรวจไม่ได้คือตัวเลขเวลาทั้งหกแถว ซึ่งวัดโดยผู้พัฒนาเองบนฮาร์ดแวร์ของเขา และตัวเลข 70.2 กับ 72.9 ของ d3-turbo ซึ่งยังไม่ปรากฏบนกระดาน
ถ้าคุณจะใช้ตัวเลขเหล่านี้ตัดสินใจซื้อการ์ด ผมแนะนำให้รอผลกระดานทางการก่อน
เรื่องที่น่าสนใจกว่าตัวเลขทั้งหมดคือการยอมรับของวงการว่า เอเจนต์ไม่จำเป็นต้องพูด
เอเจนต์ที่ดีอาจต้องรู้จักแยกงานที่ต้องใช้ภาษา ออกจากงานที่ต้องการแค่คำตัดสินใจหนึ่งครั้ง
และถ้าแยกได้ งานครึ่งหนึ่งของระบบจะเร็วขึ้นและถูกลงโดยไม่ต้องรอโมเดลรุ่นใหม่
แต่บทเรียนที่สำคัญกว่านั้นมาจากกระดานคะแนน
เพราะสิ่งที่ผมเห็นในไฟล์ index.json คือสนามที่ทุกคนแย่งกันประกาศชัยชนะบนชุดข้อสอบที่คนเห็น และมีเพียงส่วนน้อยที่กล้าเปิดผลชุดที่คนไม่เห็น
ถ้าคุณกำลังเลือกโมเดลสำหรับงานจริง ให้ดูช่องว่างระหว่างสองตัวเลขนั้น ไม่ใช่ดูอันดับ
vLLM Semantic Router Team, "d3-turbo: A Multimodal Decision Model that Reads Once", Hugging Face, 19 ต.ค. 2026. https://huggingface.co/vllm-sr/d3-turbo
vLLM Project, repo semantic-router, GitHub, เปิด 26 ส.ค. 2025 (เข้าถึง 20 ต.ค. 2026). https://github.com/vllm-project/semantic-router
"Methodology · Index 0.3.2", Jev Decision Index, ฉบับ 2026. https://multimodalart-jev-decision-index.static.hf.space/methodology.html
Michelle Chen, Alex Reneau และ Kevin Flansburg, "Introducing Clef: our open-source decision models, and new RL fine-tuning platform", Cloudflare Blog, 1 ต.ค. 2026. https://blog.cloudflare.com/clef-decision-models
Jev Decision Index, ไฟล์คะแนนดิบ index.json (สร้าง 16 ต.ค. 2026, 173 รายการที่มีคะแนน, กระดาน 0.3.2 มี 174 แถว), ดึงและคำนวณอันดับเองเมื่อ 20 ต.ค. 2026. https://multimodalart-jev-decision-index.static.hf.space/data/index.json
vLLM Semantic Router Team, "d3-edge", Hugging Face, 10 ต.ค. 2026. https://huggingface.co/vllm-sr/d3-edge
Jev Decision Index, ไฟล์กระดานภาพ vision.json (สร้าง 16 ต.ค. 2026, 41 รายการ ไม่มีรายการ d3-turbo, vLLM-SR d3 (27B) คะแนนเต็ม 71.26), ดึงเมื่อ 20 ต.ค. 2026. https://multimodalart-jev-decision-index.static.hf.space/data/vision.json