บทความ benchmark โมเดล local ส่วนใหญ่ชอบเริ่มจากตารางคะแนนเลย แต่รอบนี้ถ้าเราทำแบบนั้นก็คงพลาดเรื่องสำคัญไป

เรากำลังทดสอบโมเดล Qwen3.6 แบบ GGUF บน DGX ผ่าน LM Studio แล้วใช้ lm-evaluation-harness ครอบอีกชั้น ตอนแรกตัวเลขออกมาดูน่ากังวลมาก มีรอบหนึ่งที่ GSM8K ได้ประมาณ 10 เปอร์เซ็นต์ exact match สำหรับโมเดล reasoning ระดับ 35B ซึ่งเป็นตัวเลขที่ควรทำให้สงสัยทันที แต่สิ่งที่ควรสงสัยก่อนอาจไม่ใช่ตัวโมเดลเสมอไป บางครั้ง benchmark path กำลังบอกเราว่า setup ยังหลอกเราอยู่

และนั่นคือสิ่งที่เกิดขึ้นจริง

หลังจากไล่ดู pipeline ทั้งเส้น เราพบว่าคะแนนที่แย่ส่วนใหญ่เกิดจาก evaluation path ไม่ใช่ตัวโมเดลเอง LM Studio ส่ง reasoning ออกมาแยกจาก final answer content และ token budget ที่เราให้ไว้ก็น้อยเกินไปสำหรับ Qwen3.6 สาย reasoning พูดง่าย ๆ คือโมเดลใช้ budget ไปกับการคิด แล้วถูกตัดก่อนที่จะพ่นคำตอบสุดท้ายออกมาใน field ที่ตัว scorer ใช้อ่าน

พอเราแก้ adapter และเพิ่ม output budget ให้ GSM8K มากพอ ตัวเลขจาก stack เดิมก็เริ่มกลับมาสมเหตุสมผล

บทความนี้สรุปว่าเราแก้อะไรไปแล้ว ตอนนี้เราเชื่อ metric อะไรได้บ้าง และยังมีอะไรที่ไม่ควรเชื่ออยู่

เราทำ benchmark โมเดล Qwen3.6 แบบ local บน DGX ด้วย stack นี้

• Runtime: LM Studio

• รูปแบบโมเดล: GGUF

• API path: OpenAI-compatible endpoint ของ LM Studio

• Evaluation harness: lm-evaluation-harness

• Normalization layer: local proxy ตัวเล็กที่ตัด reasoning_content ออกจาก scored output path และเก็บไว้เฉพาะ final assistant text สำหรับ scoring

โมเดลหลักที่ใช้ในรอบนี้มีดังนี้

• qwen3.6-27b-mtp-pi-reasoning

• qwopus3.6-27b-coder-mtp

• qwopus3.6-27b-coder-compat-mtp

• qwen3.6-35b-a3b-mtp ใช้เป็นตัวอ้างอิงฝั่ง MoE ที่เร็วกว่า

นี่คือผลจากรอบทดสอบเต็มบน DGX สำหรับ task ที่เราเชื่อได้ใน stack ปัจจุบัน

นี่ไม่ได้แปลว่า reasoning variant ใช้งานไม่ได้ แต่แปลว่าใน benchmark path นี้ มันยังมีปัญหาในการปล่อย final answer ที่ scorer เอาไปคิดคะแนนได้อย่างเสถียร ในขณะที่ coder สองตัวนิ่งกว่าชัดเจน

ตรงนี้แหละที่ทำให้เรื่อง benchmark method สำคัญมาก ถ้าเราไม่แก้ stack ให้ถูกก่อน เราอาจเล่าเรื่องผิดเกี่ยวกับทั้งสามโมเดลได้ง่ายมาก

ผล GSM8K แย่รอบแรกดูเหมือนโมเดลพัง แต่จริง ๆ ไม่ใช่

สิ่งที่เกิดขึ้นคือ

1. LM Studio ส่ง reasoning แยกจาก final answer content

2. lm-eval ให้คะแนนจาก final answer text ที่มันมองเห็นใน field ที่คาดไว้เท่านั้น

3. ตอนใช้ max_tokens=1024 บางรันของ Qwen3.6 ใช้ budget หมดไปก่อนที่ final answer text จะถูกส่งออกมา

4. scorer เห็น output ว่าง เลยมองว่า invalid แล้วคะแนนพังลงทันที

นี่ไม่ใช่การทดสอบโมเดลอย่างยุติธรรม แต่มันคือการทดสอบว่า adapter กับ token budget ของคุณตั้งถูกหรือยัง

พอเราเปลี่ยนไปใช้ normalized proxy และเพิ่ม GSM8K เป็น max_tokens=4096 ผล benchmark ก็หยุดพังแบบผิดธรรมชาติ

ตอนนี้เราใช้ LM Studio proxy ตัวเล็กวางไว้หน้า lm-eval

หน้าที่ของมันตรงไปตรงมา

• ส่ง request ต่อไปที่ LM Studio /v1/chat/completions

• เก็บไว้เฉพาะ final assistant content ใน response path ที่ใช้ให้คะแนน

• เก็บ reasoning ไว้ใน side field สำหรับ debug

• ทำ response shape ให้สะอาดและเข้ากับ OpenAI-style interface ที่ harness คาดไว้

วิธีนี้ทำให้เราได้ chat-style evaluation path ที่นิ่งขึ้น โดยไม่ต้องรอ upstream support สำหรับ Qwen3.6 GGUF architecture ชุดนี้ใน runtime อื่น

อีกจุดที่สำคัญมากพอ ๆ กันคือการเพิ่ม output budget ของ GSM8K

สำหรับ Qwen3.6 สาย reasoning ค่า 1024 ไม่พอ 3072 ดีขึ้นมาก และ 4096 คือค่าชุดแรกที่ดูน่าเชื่อถือสม่ำเสมอใน smoke test ของเรา

อันนี้ตรงไปตรงมาและมีประโยชน์ทันที

จาก direct LM Studio runs ก่อนหน้า ภาพรวมออกมาประมาณนี้

สิ่งที่น่าสนใจคือ 35B A3B MoE เร็วกว่ากลุ่ม 27B dense ชัดเจน แม้จะกิน VRAM มากกว่าเยอะ ถ้าเครื่องมี memory budget พอ ตัวนี้ดูเป็นผู้ชนะด้านความเร็วจากการทดสอบช่วงแรก

ตอนนี้ path นี้ใช้งานได้จริงแล้ว

กติกาง่าย ๆ คือ

• ใช้ full chat endpoint URL

• normalize response ของ LM Studio ผ่าน proxy

• ตั้ง max_tokens=4096 สำหรับ GSM8K กับ reasoning models พวกนี้

• เปิด log samples เพื่อไล่ดู failed outputs ภายหลังได้

ถ้าทำครบนี้ คะแนนที่ออกมาจะเริ่มใช้เปรียบเทียบได้จริง

IFEval ก็ใช้ normalized chat-completions path เดียวกันได้

เราจะเก็บ task นี้ไว้ใน benchmark stack เพราะมันให้สัญญาณอีกแบบหนึ่งนอกจากโจทย์คณิตศาสตร์ GSM8K บอกว่าโมเดลไปถึงคำตอบที่ถูกไหม ส่วน IFEval บอกว่าโมเดลทำตาม instruction ได้สะอาดแค่ไหน

สองอย่างนี้รวมกันมีประโยชน์กับการเลือก local model มากกว่าการดูแค่กราฟความเร็วอย่างเดียว

อันนี้สำคัญมาก เพราะหลายโพสต์ benchmark ชอบข้ามประเด็นนี้ไป

ตอนนี้เรายัง ไม่เชื่อ task เหล่านี้บน LM Studio backend

• ARC Easy

• HellaSwag

ทำไมถึงยังไม่เชื่อ

เพราะ lm-eval ให้คะแนน task พวกนี้ผ่าน loglikelihood ซึ่งแปลว่า backend ต้องส่ง token logprobs ที่ใช้ได้จริงออกมา แต่ OpenAI-compatible completions path ของ LM Studio ตอนนี้ยังไม่ให้ logprobs ที่เชื่อถือได้สำหรับ workflow นี้ ในทางปฏิบัติคือคุณอาจรัน benchmark ได้ แต่ไม่ควรเชื่อ score ที่ออกมา

ดังนั้นเราควรพัฒนา benchmark ให้รวม ARC Easy และ HellaSwag ไหม

ควร แต่ไม่ใช่ด้วยการแกล้งทำเป็นว่า path ปัจจุบันดีพอแล้ว

ทางเลือกที่ถูกมีอยู่ 3 แบบ

1. รอให้ runtime ส่ง usable logprobs สำหรับ task พวกนี้ได้จริง

2. ย้าย task เหล่านี้ไปใช้ backend ที่รองรับ trustworthy loglikelihood scoring

3. ใช้ GSM8K และ IFEval เป็น production benchmark path สำหรับ LM Studio GGUF ไปก่อนในตอนนี้

คำแนะนำของเราตอนนี้คือข้อ 3 เพราะมันตรงไปตรงมาและซื่อสัตย์ที่สุด

เรื่องนี้ใหญ่กว่าการเทสต์ Qwen รอบเดียวมาก

ตอนนี้หลายทีมกำลังจะใช้ local benchmark stacks ที่ยัง verify ไม่ครบ ไปตัดสินใจทั้งเรื่อง content เรื่องการซื้อเครื่อง และเรื่อง deployment ถ้า setup ผิด โมเดลที่ดีอาจดูแย่ โมเดลที่แย่อาจดูพอใช้ได้ และกราฟสวย ๆ อาจมีความหมายน้อยกว่าการเปิด sample log ที่ผิดขึ้นมาดูสักหนึ่งตัวอย่าง

เพราะแบบนั้น เราเลยมอง local benchmarking เป็น 3 ชั้น

• โมเดลโหลดได้เสถียรไหม

• กิน VRAM เท่าไร

• ตอบช้าเร็วแค่ไหน

• adapter เก็บ final scored answer ไว้ถูกไหม

• token budget พอหรือยัง

• failed samples เปิดดูย้อนหลังได้ไหม

• มันแก้โจทย์ได้ไหม

• มันทำตาม instruction ได้ไหม

• มันดีพอสำหรับ workflow จริงที่เราสนใจหรือเปล่า

ถ้าข้ามสองชั้นแรกไป ชั้นสามก็แทบกลายเป็นการแสดงมากกว่าการวัดจริง

สำหรับ Qwen3.6 GGUF บน DGX benchmark path ใหม่ของเราจะเป็นแบบนี้

• LM Studio ใช้เป็น inference runtime

• local proxy ใช้ normalize response

• lm-evaluation-harness รันอยู่บน proxy อีกที

• GSM8K ใช้ max_tokens=4096

• IFEval ใช้ generation budget ที่เล็กกว่าแต่ยังปลอดภัย

• วัด latency, load time และ VRAM ควบคู่กับ eval scores

• เปิด sample logging เสมอสำหรับ debug runs

ชุดนี้ทำให้เราได้ benchmark system ที่ใช้งานจริง ทำซ้ำได้ และซื่อสัตย์กับข้อจำกัดของมันในตอนนี้

ข้อสรุปที่มีประโยชน์ที่สุดตอนนี้ยังไม่ใช่ว่า 27B ตัวไหนชนะ

แต่คือ benchmark setup สามารถกำหนด benchmark outcome ได้มากกว่าที่หลายคนคิด

ถ้าคุณรัน local reasoning-heavy model ผ่าน stack ที่ทำ final answer หล่นหาย benchmark ก็ไม่ได้กำลังวัดโมเดล แต่มันวัด plumbing ของคุณอยู่

พอเราแก้ path แล้ว ตัวเลขถึงเริ่มสมเหตุสมผล และนั่นแหละคือจุดที่การเปรียบเทียบโมเดลเริ่มมีความหมาย

ตอนนี้เราได้ benchmark workflow ที่ใช้ได้จริงสำหรับ Qwen3.6 แบบ local แล้ว แค่นี้ก็เป็น content ที่มีประโยชน์ เพราะมันตอบคำถามที่หลายคนกำลังติดอยู่เงียบ ๆ ว่า

จะ benchmark local GGUF reasoning models ยังไงโดยไม่หลอกตัวเอง

โพสต์ถัดไปควรเป็นโพสต์แบบ scoreboard ล้วน

• เทียบ Qwen3.6 27B ทั้งสามตัว

• เทียบ GSM8K

• เทียบ IFEval

• เอา latency กับ VRAM มาเทียบคู่กัน

• ปิดท้ายด้วยคำแนะนำเชิงปฏิบัติว่า ตัวไหนเหมาะกับ reasoning, coding และ speed-per-VRAM มากที่สุด

หลายคนอาจคิดว่าโพสต์แบบนั้นควรออกก่อน แต่สำหรับกรณีนี้มันควรออกทีหลัง

เพราะเรื่องแรกที่ต้องเล่าคือ เราทำให้ benchmark พูดความจริงได้ก่อน