KVarN กับ EAGLE ทำให้ LLM ในเครื่องตัวเองจุ context มากขึ้น 3-5 เท่า และพ่นโทเคนเร็วขึ้นเกือบเท่าตัว โดยไม่ต้องเปลี่ยนการ์ด
KVarN บีบ KV-cache ใน vLLM ให้รับ context ได้มากขึ้นหลายเท่าด้วย flag เดียว ส่วน EAGLE คือ speculative decoding ที่เพิ่ง merge เข้า llama.cpp เพื่อเร่งความเร็วโทเคน ทั้งคู่ทำงานบนการ์ดใบเดิม ไม่ต้องลงทุนเพิ่ม
KVarN และ EAGLE คือสองเทคนิคใหม่ที่ช่วยให้ LLM ที่รันบนเครื่องตัวเอง (local LLM) จุบทสนทนาได้ยาวขึ้นหลายเท่า และพ่นคำตอบได้เร็วขึ้นบนการ์ดจอใบเดิม KVarN บีบความจำของโมเดลให้รับ context ได้มากขึ้น 3-5 เท่า ส่วน EAGLE เร่งการพิมพ์ตอบด้วยการให้การ์ดทำงานล่วงหน้า ทั้งคู่เพิ่งออกมาช่วงนี้ และเปิดใช้ได้ด้วยคำสั่งไม่กี่บรรทัด
ทั้งสองตัวแก้ปัญหาคนละด้าน เพราะการรัน LLM ในเครื่องตัวเองมักชนข้อจำกัดเดิม คือใส่ context ได้ไม่ยาวพอ และโทเคนออกมาช้า ต้นเหตุร่วมคือ VRAM บนการ์ดจอมีจำกัด พอเปิดบทสนทนายาว ๆ หรือป้อนเอกสารทั้งไฟล์ ส่วนที่เรียกว่า KV-cache (ความจำชั่วคราวที่โมเดลใช้จำสิ่งที่อ่านไปแล้วระหว่างพิมพ์ตอบ) ก็พองจนเต็มการ์ด สุดท้ายจึงต้องตัด context ให้สั้นลง หรือยอมรับว่าความเร็วตกลงเรื่อย ๆ
กำแพงแรกคือความจำ ไม่ใช่ความเร็ว
ทุกครั้งที่โมเดลพิมพ์ตอบ มันต้องจำสิ่งที่อ่านมาทั้งหมดไว้ใน KV-cache เพื่อไม่ต้องคิดซ้ำตั้งแต่ต้น ยิ่ง context ยาว cache ก็ยิ่งโต และมันกิน VRAM ตรง ๆ พอ cache เต็ม การ์ดก็หมดที่ ต่อให้ตัวโมเดลเองยังพอมีแรงเหลือ
KVarN แก้ตรงจุดนี้ด้วยการ quantize KV-cache คือเก็บค่าด้วยจำนวนบิตที่น้อยลง แทนที่จะเก็บแบบเต็มความละเอียด (FP16) preset ที่ปล่อยออกมาใช้ 4 บิตกับ key และ 2 บิตกับ value เมื่อแต่ละค่าเล็กลง ที่ว่างเท่าเดิมจึงรับ context ได้มากขึ้นหลายเท่า ในการทดสอบบนโมเดล Qwen3-32B ที่ context 16K KVarN จุ KV ได้ราว 4 เท่าของ FP16 โดยความแม่นยำบนชุดโจทย์คณิตศาสตร์ AIME25 เท่ากับ FP16 และ throughput (จำนวนงานที่ทำได้ต่อวินาที) ยังเท่าหรือดีกว่าเดิม
จุดที่ทำให้ KVarN ต่างจากวิธี quantize อื่นคือ ปกติการบีบ cache มักแลกมาด้วยความเร็วที่หายไป อย่าง TurboQuant เพิ่ม context ได้ 2.3-3.7 เท่า แต่ throughput หายไป 40-52% ส่วน KVarN ได้ context หลายเท่าโดย throughput ไม่ต่ำกว่า FP16 และที่ความจุเท่ากันยังเร็วกว่า TurboQuant ราว 2.4 เท่า
กำแพงที่สองคือความเร็ว และวิธีที่การ์ด "เดาล่วงหน้า"
อีกด้านหนึ่งคือความเร็วในการพ่นโทเคน ปัญหาคือการ์ดจอคำนวณเลขได้เร็วกว่าที่มันดึงข้อมูลจากหน่วยความจำมาก เวลารันโมเดลทีละโทเคน การ์ดจึงนั่งรอข้อมูลอยู่บ่อย ๆ ทั้งที่ตัวมันเองว่างพอจะทำงานได้มากกว่านั้น
speculative decoding คือวิธีดึงเวลาที่การ์ดนั่งว่างกลับมาใช้ หลักการคือให้โมเดลเล็กตัวหนึ่งช่วย "เดา" โทเคนถัดไปล่วงหน้าหลายตัว แล้วให้โมเดลใหญ่ตรวจทีเดียวว่าเดาถูกไหม ถ้าเดาถูก ก็ได้หลายโทเคนในรอบเดียวแทนที่จะได้ทีละตัว ถ้าเดาผิด ก็แทบไม่เสียอะไร เพราะการ์ดว่างอยู่แล้ว นี่คือเหตุผลที่พอ EAGLE ซึ่งเป็น speculative decoding แบบหนึ่ง เพิ่งเข้าไปอยู่ใน llama.cpp (โปรแกรมยอดนิยมสำหรับรัน LLM ในเครื่อง) ผู้ใช้จึงรู้สึกว่าความเร็วเพิ่มขึ้นได้จริง โดยไม่ต้องแตะ weight ของโมเดลเลย
EAGLE ไม่ใช่ตัวเลือกเดียวใน llama.cpp เพราะยังมีอีกหลายแบบที่เหมาะกับงานคนละอย่าง เลือกตามนี้ได้
- EAGLE หรือ MTP สำหรับงานพิมพ์ตอบทั่วไป MTP คือโมเดลตัวเดาเล็ก ๆ ที่ฝังอยู่ในโมเดลหลักอยู่แล้ว กิน VRAM เพิ่มแค่ราว 500MB และเดาได้ครั้งละ 2-3 โทเคน
- ngram สำหรับงานเขียนโค้ดโดยเฉพาะ มันเดาจากคำที่เคยโผล่ในบทสนทนาแล้วน่าจะซ้ำ จุดเด่นคือไม่กิน VRAM เพิ่มเลย
- DFlash สำหรับ context สั้น ๆ ที่อยากได้ความเร็วสูงสุด มันเดาโทเคนทีละมาก ๆ พร้อมกัน แต่ความเร็วจะตกเมื่อ context ยาว
ควรเลือกตัวไหนตอนไหน ถ้ายังไม่แน่ใจให้เริ่มที่ MTP เพราะกิน VRAM น้อยและเหมาะกับงานทั่วไป ถ้าเขียนโค้ดเป็นหลัก ค่อยเพิ่ม ngram เข้าไปคู่กัน เพราะ ngram ไม่กิน VRAM เพิ่ม จึงซ้อนกับ MTP ได้โดยไม่เปลืองการ์ด
เริ่มใช้จริงด้วยคำสั่งไม่กี่บรรทัด
ข้อดีที่สุดของทั้งสองตัวคือไม่ต้องแปลงโมเดลใหม่ ไม่ต้องปรับจูนค่าล่วงหน้า และไม่ต้องเปลี่ยนการ์ด เริ่มจาก KVarN ซึ่งทำงานบน vLLM (เอนจินสำหรับรัน LLM อีกตัวที่นิยมฝั่งเซิร์ฟเวอร์) ก่อน
- ติดตั้ง KVarN ลงใน vLLM แบบสำเร็จรูปด้วยคำสั่ง
VLLM_USE_PRECOMPILED=1 pip install -e . - ตอนสั่งรันโมเดล ให้เพิ่มสองค่านี้เข้าไป
--kv-cache-dtype kvarn_k4v2_g128 --block-size 128
แค่เพิ่มค่าบรรทัดที่สองก็ได้ context เพิ่มหลายเท่าแล้ว ไม่ต้องแตะอย่างอื่น ถ้าการ์ดใบเดียวและ VRAM ตึงมาก ค่อยเสริมค่า VLLM_MEMORY_PROFILER_ESTIMATE_CUDAGRAPHS=0 เพื่อดึงความจุคืนมาเต็มที่
ฝั่ง llama.cpp การเปิด speculative decoding ก็ใช้ flag เดียวเช่นกัน คือ --spec-type และถ้าอยากใช้หลายแบบพร้อมกันก็ใส่ซ้อนได้ เช่น --spec-type draft-mtp,ngram-mod เพื่อให้ MTP กับ ngram ช่วยกันเดา
ของฟรีที่ยังต้องอ่านฉลาก
ทั้งหมดนี้ไม่ได้มีแต่ข้อดีแบบไม่มีต้นทุน ฝั่ง KVarN เมื่อใช้กับโมเดลโครงสร้างพิเศษอย่าง GLM-4.7-Flash จะได้ context มากขึ้น 2.77 เท่า (จาก 313K เป็น 865K โทเคน) โดยความแม่นยำเท่าเดิม แต่ throughput ลดลงเล็กน้อยเหลือราว 0.94 เท่า นี่เป็นข้อแลกเปลี่ยนที่ค่อนข้างคุ้ม เพราะได้ที่ว่างเพิ่มเกือบสามเท่าโดยเสียความเร็วแค่นิดเดียว
ฝั่ง speculative decoding ก็มีต้นทุนเหมือนกัน MTP กิน VRAM เพิ่มและในบางกรณีทำให้การเรียกใช้เครื่องมือ (tool calling) พลาดบ่อยขึ้น หรือกระทบงานที่มีรูปภาพ จุดสำคัญคือไม่มีตัวไหนดีที่สุดสำหรับทุกงาน ความเร็วที่เพิ่มขึ้นจริงขึ้นกับโมเดลและรูปแบบงานที่ใช้ ทางที่ดีคือวัดความเร็วก่อนและหลังเปิด แล้วดูด้วยตาตัวเองว่าคุ้มกับงานของตัวเองไหม
และมีอีกบทเรียนหนึ่งที่ควรติดตัวไว้ เทคนิคบีบ cache บางตัวที่ยังใหม่และยังไม่เข้าสู่โปรแกรมหลัก มักโชว์ตัวเลขสวยจากการทดสอบรอบเดียว แต่สิ่งที่บอกผลจริงคือการดึงข้อมูลจาก context ยาว ๆ ซ้ำ ๆ หลายรอบ เพราะ error ที่ค่อย ๆ สะสมมักไม่โผล่ในการทดสอบครั้งเดียว เลือกตัวที่ผ่านการทดสอบอย่างเป็นระบบไว้ก่อน จะปลอดภัยกว่าวิ่งตามตัวเลขที่ดูดีที่สุด
เพราะสุดท้ายแล้ว การ์ดที่เร็วขึ้นไม่ได้มาจากการ์ดใบใหม่เสมอไป บ่อยครั้งมันมาจากการเข้าใจว่าการ์ดใบเดิมเสียเวลาไปกับอะไร แล้วคืนเวลานั้นกลับมา
