ทำไมโมเดลที่รันเองถึง "โง่กว่า" ที่เขาโฆษณา — การทดลองวัด logit ทีละตัวชี้ว่าแค่เปลี่ยน attention backend คำตอบก็เปลี่ยน

ทุกคนที่เคยรันโมเดลเองน่าจะเคยผ่านโมเมนต์นี้ — เห็นคนในฟอรัมชมโมเดลตัวหนึ่งจนฟ้าถล่ม โหลดมารัน (ซึ่งส่วนใหญ่คือโหลด quant มา) แล้วรู้สึกว่า “เอ๊ะ มันก็ไม่ได้เก่งขนาดนั้นนี่”

โพสต์ทดลองชุดใหญ่บนฟอรัม Level1Techs โดยผู้ใช้ thr3e ซึ่งขึ้นหน้าแรก Hacker News เมื่อ 22 ส.ค. 2026 พยายามตอบคำถามนี้ด้วยข้อมูลแทนความรู้สึก และคำตอบที่ได้น่าตกใจกว่าที่คิด: คุณไม่ได้รันโมเดลตัวเดียวกับที่แล็บวัด benchmark แม้จะโหลด weight ชุดเดียวกันมาก็ตาม

ตั้งต้นจากคำถามที่วัดได้: logit ตรงกันไหม

วิธีวัดของผู้เขียนตรงไปตรงมาแต่แพงมาก — แทนที่จะรัน benchmark แล้วดูคะแนนรวม เขา เก็บ logit เต็ม vocabulary ทุก ๆ 32 โทเคนของ prompt แล้วเอามาเทียบทีหลังใน FP64

ชุดทดลองหลัก:

• โมเดล Qwen3.6-27B checkpoint BF16 อย่างเป็นทางการ
• GPU RTX PRO 6000 Blackwell, tensor parallelism 1
• KV cache BF16, ไม่ quantize weight/activation
• vLLM nightly ที่ pin เวอร์ชันไว้, eager execution, ปิด CUDA graphs / prefix caching / MTP, chunked prefill 2k
• prompt ทดสอบคือ workstream จริงยาวราว 100k โทเคน ที่มี tool call จริงและผลงานจริงอยู่ข้างใน

จุดที่ฉลาดที่สุดของการออกแบบคือ prompt นี้ ไม่ปรากฏใน benchmark หรือ dataset ใด ๆ ในโลก ผู้เขียนย้ำเองว่า “ไม่มีใคร benchmax หรือ calibrate quant ให้เข้ากับมันได้” — ต่างจากการเทสต์ด้วย MMLU หรือ needle-in-a-haystack ที่ quant ยุคนี้ถูกจูนมาเพื่อผ่านโดยเฉพาะ

ก่อนเข้าผลการทดลอง มีคำเตือนหนึ่งข้อที่ควรแปะไว้ข้างจอ: อย่าเชื่อตัวเลข KL Divergence ต่ำ ๆ บน model card ของ quant ผู้เขียนชี้ว่าตัวเลข KLD ตีความไม่ได้เลยถ้าคนโพสต์ไม่เปิดเผย reference checkpoint, runtime ทั้งกอง, ข้อความที่ใช้วัด, calibration data, ความยาว context, ตำแหน่งที่สุ่ม, ทิศทางของ KL, การตัด vocabulary และวิธีรวมค่า — “วิธีวัดสำคัญพอ ๆ กับตัวเลข และหลายคนทำผิด”

Test 1: เปลี่ยนแค่ attention backend คำตอบก็เปลี่ยน

การทดลองแรกเปลี่ยน ตัวแปรเดียว คือ attention backend ที่ vLLM เลือกใช้ตอน prefill โดยมีสามตัวเลือก: FlashAttention 2, Flash Inference และ Triton Attention ที่เหลือทั้ง hardware และ software เหมือนกันทุกประการ

(รายละเอียดสถาปัตยกรรมที่ควรรู้: Qwen3.6-27B เป็นโมเดล dense แต่เป็น hybrid — 64 เลเยอร์วนรูปแบบ Gated DeltaNet/linear-attention สามชั้น สลับ full-attention หนึ่งชั้น มีแค่ 16 เลเยอร์ full-attention เท่านั้นที่ใช้ backend ที่สลับได้ในการทดลองนี้)

ผลลัพธ์:

• ในช่วงหลายพันโทเคนแรก ทุก backend เห็นตรงกันหมด ว่าโทเคนถัดไปคืออะไร
• พอเข้าช่วงหลังของ prompt เริ่มเห็นไม่ตรงกัน โดยความไม่ตรงกันมาเป็น กระจุก และแปรตามเนื้อหาของ prompt มากกว่าจะเพิ่มขึ้นเรียบ ๆ ตามความยาว
• การรัน backend เดิมซ้ำหลายครั้งให้ logit ตรงกันบิตต่อบิต ที่ทุก hidden state

ข้อสุดท้ายคือหมัดน็อกของการทดลองนี้ เพราะมันตัดความเป็นไปได้เรื่อง random noise ออกไปหมด ความต่างที่เห็นมาจากลำดับการคูณและบวกเมทริกซ์ในเคอร์เนลของแต่ละ backend ล้วน ๆ — คณิตศาสตร์บนกระดาษเหมือนกัน แต่คณิตศาสตร์บนซิลิคอนไม่เหมือนกัน

ผู้เขียนยังอธิบายว่าทำไมถึงเป็นแบบนี้ได้: container vLLM nightly ที่เขาใช้มี 734 แพ็กเกจ (เป็น Python 252 ตัว) เส้นทางที่การรันของคุณวิ่งผ่านโค้ดกองนั้นย่อมไม่เหมือนของใคร

Test 2: quant แค่ KV cache ก็ทำ tool call พังได้จริง

การทดลองที่สองปล่อย weight และ activation ไว้ที่ BF16 ทั้งหมด แล้ว quantize เฉพาะ KV cache ผลคือได้ความล้มเหลวที่ทำซ้ำได้เป็นรูปธรรม:

• BF16 — ทำ tool call ได้ถูกต้อง
• int8 KV cache — โทเคนหลุดไปบ้าง แต่ ในที่สุดก็กู้กลับมาได้
• int4 KV cache — กู้ไม่กลับ

นี่คือความแตกต่างสำคัญจากการวัดแบบเดิม ๆ ที่ดูแค่ perplexity ขยับนิดหน่อยแล้วสรุปว่า “ยอมรับได้” ในงาน agent จริง โทเคนที่พลิกไปตัวเดียวกลางการเขียน tool call ไม่ได้ทำให้คำตอบ “แย่ลงเล็กน้อย” แต่ทำให้ คำสั่งที่ยิงออกไปผิดตัว

Test 3: ศึกห้าเส้า และผลที่ NVIDIA คงไม่ชอบ

การทดลองสุดท้ายตรึง KV cache ไว้ที่ BF16 แล้วเทียบ weight quant ห้าแบบ ซึ่งแต่ละแบบวิ่งผ่าน CUDA kernel / GEMM คนละตัวกันจริง ๆ:

checkpoint	รูปแบบ	GEMM kernel
Qwen/Qwen3.6-27B	BF16 (อ้างอิง)	torch.nn.functional.linear
Qwen/Qwen3.6-27B-FP8	FP8 E4M3 บล็อก 128×128, W8A8	CUTLASS FP8 block-scaled
TheHouseOfTheDude/Qwen3.6-27B-INT8	INT8 W8A16 channel-wise	Marlin
nvidia/Qwen3.6-27B-NVFP4	ผสม FP8 W8A8 + NVFP4 W4A16 group 16	FlashInfer FP8 + Marlin NVFP4
cyankiwi/Qwen3.6-27B-AWQ-BF16-INT4	AWQ INT4 W4A16 group 32	Marlin

ผลการจัดอันดับตาม % ของโทเคนที่พลิก:

• INT8 W8A16 ชนะขาด — ดีกว่า FP8 อย่างเป็นทางการของ Qwen เองด้วยซ้ำ ผู้เขียนอธิบายว่าไม่ได้มหัศจรรย์อะไร เพราะ W8A16 ไม่แตะ activation และ GDN projection ก็ไม่ถูก quantize
• NVFP4 ของ NVIDIA รั้งท้าย แตะราว 50% token flip เมื่อถึง context 88k
• ทั้ง NVFP4 และ AWQ W4A16 ปิด tool call ไม่ลง และสั่งคำสั่ง Cisco ผิด — คำสั่งที่ถูกคือ show arp แต่มันสั่ง show run
• FP8 และ INT8 ทำ tool call ได้ครบถูกต้อง

ข้อควรระวังเรื่องความเป็นธรรม ที่ผู้เขียนระบุเองและเราต้องยกมาด้วย: รอบนี้ ไม่ได้รันเลขคณิต FP4 แบบ native vLLM มองว่าเส้นทาง GPU ที่ใช้ไม่รองรับ FP4 โดยตรง จึงเลือกบีบอัด weight-only FP4 ผ่าน Marlin แทน ดังนั้นตัวเลขนี้จึงเป็นภาพของ “NVFP4 ในสภาพที่ผู้ใช้ทั่วไปน่าจะเจอบน stack วันนี้” มากกว่าจะเป็นเพดานความสามารถของฟอร์แมต — ซึ่งก็เป็นประเด็นของทั้งโพสต์อยู่ดี

อีกจุดที่น่าสนใจคือเรื่อง calibration: checkpoint FP8 อย่างเป็นทางการ ไม่ระบุ dataset ที่ใช้ calibrate ในไฟล์ที่เผยแพร่ ส่วน AWQ ของ community กลับเปิดเผยว่าใช้ชุด “STEM and Agentic” — ความโปร่งใสในเรื่องนี้ไม่ได้ขึ้นกับว่าเป็นเจ้าของโมเดลหรือไม่

มุมมอง AI Curator

โพสต์นี้ไม่ใช่เปเปอร์ผ่าน peer review และผู้เขียนก็บอกเองว่าตั้งใจข้ามรายละเอียดทางทฤษฎีเพื่อให้อ่านง่าย แต่สิ่งที่มันทำได้ดีกว่าเปเปอร์หลายชิ้นคือ การเลือกวัดในสิ่งที่ตรงกับงานจริง — prompt 100k ที่มี tool call จริง แทนที่จะเป็นชุดคำถามปรนัยที่ทุก quant ถูกจูนมาให้ผ่าน

สำหรับทีมไทยที่รันโมเดลเองด้วยเหตุผลด้าน PDPA, ต้นทุน หรือ latency ผมคิดว่ามีสามข้อที่ใช้ได้ทันที

ข้อแรก — หยุดเลือก quant จากขนาดไฟล์อย่างเดียว สัญชาตญาณของคนส่วนใหญ่คือ “GPU มี VRAM เท่านี้ เลือกตัวที่ใหญ่ที่สุดที่ใส่ได้” ซึ่งมักจบที่ 4-bit แต่ผลการทดลองนี้ชี้ว่าถ้างานของคุณคือ agent ที่เรียกเครื่องมือบน context ยาว ระยะห่างระหว่าง 8-bit กับ 4-bit ไม่ใช่ “คุณภาพลดนิดหน่อย” แต่คือ “คำสั่งผิด” ถ้า VRAM ไม่พอสำหรับ 8-bit จริง ๆ ทางเลือกที่ดีกว่าอาจเป็น ใช้โมเดลเล็กลงแต่ quant น้อยลง แทนที่จะเป็นโมเดลใหญ่ที่ถูกบีบจนเสียรูป

ข้อสอง — KV cache quantization คือปุ่มที่ควรแตะเป็นอันดับสุดท้าย มันเป็นปุ่มที่ล่อใจที่สุดเพราะประหยัด VRAM ได้เยอะที่สุดต่อการตั้งค่าหนึ่งบรรทัด และเป็นปุ่มที่ dashboard ของคุณจะไม่มีวันบอกว่ามันพัง เพราะโมเดลยังตอบคล่องเหมือนเดิม แค่ตอบผิด ทีมที่รัน RAG แล้วรู้สึกว่า “คุณภาพตกหลัง context ยาว ๆ” ควรลองปิด KV quant ก่อนไปโทษ retriever

ข้อสาม และเป็นข้อที่กว้างที่สุด — benchmark ของแล็บเป็นเพดาน ไม่ใช่ค่าที่คุณจะได้ ทุกครั้งที่เห็นตัวเลข SWE-bench หรือ Terminal Bench ของโมเดล open-weight ตัวใหม่ ให้จำไว้ว่าตัวเลขนั้นมาจาก reference checkpoint บน stack ของแล็บ ส่วนคุณกำลังจะรัน quant ของคนอื่น บน GPU คนละรุ่น ผ่าน kernel คนละตัว ช่องว่างตรงนี้วัดได้ และมันไม่เล็ก ทีมที่จริงจังควรมี prompt ชุดของตัวเองที่ไม่เคยเผยแพร่ที่ไหน เอาไว้วัดทุกครั้งที่เปลี่ยน quant, เปลี่ยนเวอร์ชัน vLLM หรือเปลี่ยน GPU — เหมือนที่ผู้เขียนทำกับ “Prompt 2” ของเขา

มีนัยเชิงระบบนิเวศที่ควรพูดด้วย: ทุกวันนี้การเลือก quant จาก Hugging Face คือการเชื่อใจคนแปลกหน้าที่โพสต์ตัวเลข KLD โดยไม่บอกวิธีวัด ถ้า community จะโตต่อไปอย่างมีวุฒิภาวะ ต้องมีมาตรฐานการรายงานร่วมกัน ว่า quant หนึ่งตัวถูกวัดยังไง ด้วย prompt แบบไหน ที่ context เท่าไหร่ ตอนนี้เรายังอยู่ในยุคที่ผู้เผยแพร่ community บางคนโปร่งใสกว่าเจ้าของโมเดลเอง — ซึ่งเป็นทั้งเรื่องน่าชื่นชมและเรื่องน่ากังวลในเวลาเดียวกัน

แหล่งข่าว

• Why your local LLM feels dumber than it is — Level1Techs Forums, โพสต์โดย thr3e (Part 1)
• Qwen/Qwen3.6-27B — checkpoint BF16 ที่ใช้เป็นตัวอ้างอิง
• nvidia/Qwen3.6-27B-NVFP4 — checkpoint NVFP4 ที่ถูกทดสอบ
• vLLM — inference engine ที่ใช้ในการทดลองทั้งหมด