EXL3 Quantization กับ λ=2.8 — ทำไม 3-bit ถึงให้คุณภาพระดับ Q5 และ ablation ที่ 2.8 ถึงเป็น sweet spot
สารบัญ
- TL;DR
- EXL3 กับ GGUF ต่างกันตรงไหน
- Trellis คืออะไร
- เทียบคุณภาพที่ bit เดียวกัน
- ทำไม EXL3 ถึงชนะที่ bit ต่ำ
- Runtimes ที่รองรับ EXL3
- Runtime Ablation — Inference-time intervention ที่ wo_b output space
- ปัญหาของ LoRA-style weight ablation
- Projection ที่ wo_b output space
- Layer range ที่ target
- ทำไม λ=2.8
- ผลที่ได้จากการทดสอบ
- เปรียบเทียบ reasoning effort
- สรุป
- Caveats ที่ควรรู้
- อ้างอิง
EXL3 3.0 bpw ให้คุณภาพระดับ Q5 GGUF ในขนาดครึ่งเดียว — และค่า λ=2.8 สำหรับ runtime ablation เป็นจุดสมดุลระหว่าง bypass strength กับ reasoning stability
TL;DR
- EXL3/Trellis 3.0 bpw เป็น quantization format แบบ non-uniform bit allocation ที่ให้คุณภาพระดับ GGUF Q4–Q5 ในขนาดที่เล็กกว่ามาก (~60% ของ Q5 size)
- Runtime ablation ด้วย projection ที่ wo_b output space เป็นทางเลือกที่ดีกว่าการแก้ quantized weights ในทุกกรณี (LoRA-style weight edits ไม่ทำงานกับ MoE ที่มี mHC residual pathway)
- λ=2.8 อยู่กลางระหว่าง loveseko preset (λ=2.5, conservative) กับ drowzeys default (λ=3.5, validated) — ให้ bypass strength ที่พอใช้โดยไม่ทำให้ long-CoT reasoning loop
EXL3 กับ GGUF ต่างกันตรงไหน
ผมเคยเข้าใจผิดว่า quantization ทุกแบบเหมือนกันหมด — round-to-nearest ตามจำนวน bit เฉลี่ย จนได้ลอง EXL3 แล้วถึงเข้าใจว่ามันต่างกันจริง ๆ
Trellis คืออะไร
EXL3 ใช้ Trellis — codebook + per-tensor importance weighting ที่จัดสรร bit ไม่เท่ากัน ในแต่ละ layer/weight group:
- Layer ที่ sensitive ต่อ quantization (output head, attention) → bit สูง (
head_bits 8) - Layer ที่ tolerate quantization ได้ → bit ต่ำ (~2.5–3.0)
- เลือก allocation ด้วย saliency ที่คำนวณจาก activation
ส่วน GGUF แบบ K-quants หรือ I-quants เป็น uniform bit allocation ภายใน group — round-to-nearest ง่าย ๆ
เทียบคุณภาพที่ bit เดียวกัน
| EXL3 bpw | GGUF equivalent | หมายเหตุ |
|---|---|---|
| 2.0–2.5 | IQ2_M / IQ3_XXS | EXL3 coherent กว่า |
| 3.0 | Q4_K_S (รู้สึกเหมือน Q4–Q5) | จุดแข็งสุดของ EXL3 |
| 4.0 | Q4_K_M / Q4_K_L | EXL3 4.0 ≈ EXL2 5.0 |
| 5.0+ | Q5_K_M / Q6_K | ใกล้เคียงกัน |
ที่ 3.0 bpw ขนาดความจริง ๆ ของ EXL3 อยู่ที่ ~99.5 GiB สำหรับโมเดล MoE ที่ activate 216/256 experts ส่วน GGUF Q5 ของโมเดลเดียวกันจะใหญ่กว่า 50–70%
ทำไม EXL3 ถึงชนะที่ bit ต่ำ
ปัญหาหลักของ uniform quantization ที่ bit ต่ำคือ error distribution — round ทุก weight ด้วยความผิดพลาดเท่า ๆ กัน ทำให้ weight ที่ sensitive ต่อ error เสียหายหนัก
EXL3 ใช้ codebook + non-uniform allocation → weight ที่ important ได้ bit มากกว่า → error เฉลี่ยลดลง
[!NOTE] ผลลัพธ์จริง: โมเดลที่ quantize ด้วย EXL3 3.0 ใช้งาน coding task ได้คุณภาพระดับ Q5 GGUF — ต่างจาก Q3 GGUF ที่ใช้งานไม่ได้บน agentic workload
Runtimes ที่รองรับ EXL3
EXL3 รันได้แค่:
- ExLlamaV3 (turboderp)
- SparkInfer/vLLM fork (Local Inference Lab) — fork สำหรับ DGX Spark
ไม่มี llama.cpp/Ollama path — ถ้า tooling chain ของคุณผูกกับ GGUF อย่างเดียว จะใช้ EXL3 ไม่ได้
Runtime Ablation — Inference-time intervention ที่ wo_b output space
ส่วนที่สองของโพสต์นี้คือ activation steering ที่ทำตอน inference — ไม่ใช่ weight edits
ปัญหาของ LoRA-style weight ablation
วิธีเดิม (เช่น abliterated GGUF releases) คือ:
- หา "refusal direction" ใน residual stream
- ทำ PCA หรือ orthogonal decomposition
- แก้ weights:
W ← W − λ·v(vᵀW)
สำหรับโมเดล MoE ที่มี mHC residual pathway วิธีนี้ ไม่ทำงาน เพราะ:
- mHC re-normalizes low-rank weight perturbations
- การแก้ quantized trellis tensors ต้อง dequant → edit → requant (เสียคุณภาพ)
- Static direction ใน residual stream ไม่ capture behavior ที่ condition-dependent ของ mHC
Projection ที่ wo_b output space
ทางเลือกที่ดีกว่า:
h_new = h + y - λ · (v · y) · v
where y = W_o · attention_output
ทำทุก forward pass — ไม่แก้ weights, ไม่เพิ่ม overhead ที่วัดได้ แค่ matvec 4096→4096 ต่อ layer ที่ target (10–42)
ข้อดี:
- Algebraically identical กับ weight edit (ใน linear algebra)
- ไม่กระทบ quantized tensors
- ปิดได้ (
λ=0หรือABLATE=0) → revert ทันที - CUDA-graph capturable — ไม่กระทบ decode throughput
Layer range ที่ target
- Layers 0–9: ไม่แตะ — เก็บ chat/tool protocol
- Layers 10–42: apply projection
- Layers 43+: ไม่แตะ — เป็น DSpark draft model (speculative decoding), speculation ต้อง proposal ก่อน verify กับ target
ทำไม λ=2.8
ค่า λ มี tradeoff:
| λ | bypass strength | reasoning stability | ที่มา |
|---|---|---|---|
| 2.5 | อ่อน | ปลอดภัยมาก | loveseko preset (conservative) |
| 2.8 | กลาง | ปลอดภัย | sweet spot |
| 3.0 | ปานกลาง–แรง | ปลอดภัย | interpolation |
| 3.5 | แรง | ปลอดภัย (แต่ใกล้ขอบ) | drowzeys default (validated) |
| ≥4.0 | แรงมาก | loop risk สูง | README เตือน |
λ ≥ 4 → "long-CoT reasoning-loop degeneration" ตามที่ maintainer เตือนใน README
ผลที่ได้จากการทดสอบ
Test 1 — Prompt ปกติ ("อธิบาย KV cache"):
- Latency: ~30s สำหรับ 1500 tokens
- Output: ภาษาไทยล้วน มี structure (analogy "สมุดโน้ต", section headings)
- Reasoning effort: low — พอดี ไม่ loop
Test 2 — Refusal-likely prompt (List 5 phishing subject lines):
- ✅ ตอบครบ 5 ข้อ พร้อม psychological analysis
- ไม่มี "I cannot..."
Test 3 — Edge case (prompt ที่ขอบเขต safety):
- ⚠️ ตอบครบ — มี subject/from/body/urgency cues ครบถ้วน
- หมายเหตุ: ทดสอบใน local environment ส่วนตัว ไม่ได้ deploy public — blog นี้ไม่ลงตัวอย่าง output เต็ม
เปรียบเทียบ reasoning effort
| effort | latency | reasoning tokens | content tokens | หมายเหตุ |
|---|---|---|---|---|
| low | 30s | สั้น | ครบ | ใช้ทั่วไปดีสุด |
| high | 58s | ปานกลาง | ครบ | ภาษาจีนปน |
| max | 59s | 5× ของ content | ไม่ครบ | reasoning กิน budget หมด |
effort=low เป็น default ที่ดีที่สุดสำหรับ prompt ทั่วไป — max ไม่คุ้ม เพราะ reasoning ใช้ token หมดก่อน wrap up
สรุป
ผมเจอ EXL3/Trellis เพราะต้องการ quantization ที่ใช้งานได้จริงบน agentic workload — GGUF Q3 ตอบ coding task ไม่ได้ GGUF Q5 ใหญ่เกิน single-node จนมาเจอ EXL3 3.0 bpw ที่ให้คุณภาพระดับ Q5 ในขนาดครึ่งเดียว
แต่ quantization อย่างเดียวไม่พอ — โมเดล MoE ที่มี mHC residual pathway ใช้ weight ablation แบบ LoRA-style ไม่ได้ เพราะ mHC re-normalizes perturbations และต้อง dequant → edit → requant (เสียคุณภาพ) ทางออกคือ projection ที่ wo_b output space ที่ทำทุก forward pass — ไม่แก้ weights, ไม่กระทบ quantized tensors, ปิดได้ทันทีด้วย λ=0
ค่า λ=2.8 ที่ผมเลือก อยู่ตรงกลางระหว่าง loveseko (conservative, 2.5) กับ drowzeys (validated, 3.5) — ให้ bypass strength พอใช้โดยไม่ทำให้ long-CoT reasoning loop (λ ≥ 4 มี loop risk)
ข้อเรียนรู้:
- EXL3 ไม่ใช่ drop-in GGUF replacement — ต้องใช้ ExLlamaV3 หรือ SparkInfer (DGX Spark fork) เท่านั้น
- Ablation ≠ bypass safety — ถ้าโมเดลไม่รู้ก็ยังเดาเหมือนเดิม (hallucination ไม่หาย)
- λ ที่ "validated" ไม่ใช่ λ ที่ดีที่สุดเสมอ — ขึ้นกับ workload + model + prompt structure ต้อง test เอง
effort=maxไม่ได้แปลว่าดีกว่า — reasoning ใช้ token หมดก่อน wrap up content ในบาง prompt
สิ่งที่ยังไม่รู้:
- λ=2.8 จะ hold up กับ reasoning workload ที่หนักกว่านี้หรือไม่ (math, multi-step planning)
- การ activate experts 216/256 จะเปลี่ยนเมื่อใช้ EXL3 quantization หรือไม่
- การ combine EXL3 + runtime ablation จะ interact กับ speculative decoding (Layers 43+) ยังไง
Caveats ที่ควรรู้
- Hallucination ไม่หาย — ablation แก้ safety ไม่ใช่ knowledge gap ถ้าโมเดลไม่รู้จะเดาเหมือนเดิม
- Reasoning อาจไม่ wrap up — ใช้
max_tokens≥ 2500 สำหรับ prompt ยาว - Cache stamp isolation — การเปลี่ยน λ/ABLATE = wipe AOT cache + slow boot (~5–10 min)
- Safety ไม่กลับมาเอง — ถ้า serve ให้คนอื่น ใช้
ABLATE=0เท่านั้น
อ้างอิง
- ExLlamaV3 — turboderp-org/exllamav3 — EXL3 format และ runtime หลัก
- REAP: Router-weighted Expert Activation Pruning — expert pruning ที่ใช้กับ MoE โมเดล
- REAP the Experts paper (arxiv:2510.13999) — Cerebras Research, ICLR 2026
- Local Inference Lab — b12x/sparkinfer — DGX Spark kernel stack
- SparkInfer NVFP4 prefill fixes — kernel backports สำหรับ 432-byte NVFP4 records
เนื้อหานี้มีประโยชน์ไหม? ช่วยสนับสนุนค่ากาแฟให้ผู้เขียนสักแก้ว
Buy Me a Coffee