speculative decoding กับ EAGLE-3 ทำงานอย่างไร และใครได้ใช้จริง

โดย Nokka (นก-กา) | 19 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka ข้อความในเครื่องหมายคำพูดที่เป็นคำแปลเป็นคำแปลของผม ไม่ใช่สำเนาต้นฉบับ

มีเทคนิคหนึ่งที่ทำให้โมเดลเดิมตอบเร็วขึ้นได้ โดยไม่ต้องเปลี่ยนโมเดล และไม่ทำให้คุณภาพลดลง เทคนิคนั้นชื่อ speculative decoding [1]

⇒ ก่อนหน้านี้ผมเขียนวิธีเปิดมันใน LM Studio ไปแล้ว บทความนี้จะพาไปดู แนวคิดข้างใน ว่ามันทำงานอย่างไร ทำไมจึงเร็วขึ้นได้โดยไม่เสียคุณภาพ และทำไม EAGLE-3 ถึงเป็นรุ่นที่ถูกใช้ในงานจริงมากที่สุด [1][2]

ปัญหาที่ต้องเข้าใจก่อน

โมเดลภาษาให้ผลลัพธ์ทีละโทเคน โทเคนที่สองต้องรอโทเคนแรก โทเคนที่สามต้องรอโทเคนที่สอง เป็นเช่นนี้ไปเรื่อย ๆ [1]

ปัญหาคือการสร้างแบบนี้ ติดที่แบนด์วิดช์หน่วยความจำ ไม่ได้ติดที่พลังประมวลผล คือการ์ดจอยังว่าง แต่ต้องรอข้อมูลไหลผ่านหน่วยความจำ [3]

ในทางกลับกัน การประมวลผล prompt ทำได้พร้อมกันทั้งก้อน เพราะเมื่อมีข้อความครบแล้ว โมเดลคำนวณความน่าจะเป็นของทุกตำแหน่งพร้อมกันได้ [1][3]

ความต่างนี้คือจุดตั้งต้นของเทคนิคทั้งหมด ถ้าประมวลผลหลายโทเคนพร้อมกันถูกกว่าการทำทีละตัว ก็ควรหาทางยัดหลายโทเคนเข้าไปในรอบเดียว [1]

ภาพที่ 1: ความต่างที่ทำให้เกิดเทคนิคนี้

แนวคิดหลักของ speculative decoding

วิธีคือหาตัวช่วยที่ถูกและเร็ว มาเดาโทเคนข้างหน้าหลายตัวก่อน แล้วให้โมเดลใหญ่ตรวจทั้งหมดในรอบเดียว [1]

ขั้นที่หนึ่ง โมเดลร่างตัวเล็กสร้างโทเคนตัวเลือกมา k ตัว [1][3]

ขั้นที่สอง โมเดลใหญ่ประมวลผลทั้ง k ตัวพร้อมกันใน forward pass เดียว ซึ่งทำได้เพราะมีลำดับโทเคนอยู่ในมือแล้ว จึงคำนวณความน่าจะเป็นที่ทุกตำแหน่งได้พร้อมกัน [3]

ขั้นที่สาม ตรวจจากซ้ายไปขวา เก็บส่วนที่ถูกต้องไว้เท่าที่ติดกัน แล้วโมเดลใหญ่สร้างตัวถัดไปเอง [1][3]

เอกสารทางการของ llama.cpp อธิบายเหตุผลสั้น ๆ ว่าวิธีนี้ให้ผลดีเมื่อ คำทำนายของโมเดลร่างถูกบ่อย [1]

ภาพที่ 2: กลไกที่ทำให้คุณภาพไม่เสีย

ส่วนที่ผมคิดว่าสำคัญที่สุด: มันไม่เสียคุณภาพจริง

หลายคนเข้าใจว่า speculative decoding เป็นการแลกคุณภาพกับความเร็ว แต่ความจริงไม่ใช่อย่างนั้น [3]

⇒ การยอมรับโทเคนใช้วิธีที่เรียกว่า modified rejection sampling สำหรับโทเคน x ที่โมเดลร่างให้ความน่าจะเป็น q(x) และโมเดลใหญ่ให้ p(x) จะยอมรับด้วยความน่าจะเป็น min(1, p(x)/q(x)) [3]

และถ้าปฏิเสธ จะสุ่มใหม่จากการกระจายส่วนที่เหลือที่ปรับให้เป็นบรรทัดฐานแล้ว คือ (p(x) - q(x))₊ [3]

ผลลัพธ์ที่ได้จึง พิสูจน์ได้ว่ากระจายตัวเหมือนการสุ่มจากโมเดลใหญ่โดยตรง ไม่มี trade-off ไม่มีคะแนน eval ตก [3]

ผมคิดว่านี่คือจุดที่ทำให้เทคนิคนี้ต่างจากวิธีเร่งความเร็วอื่น ๆ มันไม่ใช่การประมาณ แต่เป็นการคำนวณที่ให้คำตอบชุดเดียวกัน

ตัวเลขที่กำหนดเพดานความเร็ว

ตัวเลขสำคัญที่สุดของเทคนิคนี้ไม่ใช่ความเร็วของโมเดลร่าง แต่คือ อัตราการยอมรับ หรือ α [3]

สูตรที่ใช้ดูเพดานคือ จำนวนโทเคนที่ยอมรับต่อรอบของโมเดลใหญ่ = (1 - α^(k+1)) / (1 - α) [3]

⇒ ซึ่งเป็นเส้นโค้งที่อิ่มตัว ไม่ใช่เส้นตรง ตัวอย่างที่เขาให้คือ ถ้า α = 0.7 และ k = 4 จะได้ประมาณ 2.6 โทเคนต่อรอบของโมเดลใหญ่ [3]

นั่นคือเพดาน ก่อนหักค่าใช้จ่ายของขั้นตอนร่างและการตรวจ [3]

และมีข้อจำกัดที่ต้องเข้าใจ เทคนิคนี้เป็น การลดความหน่วง ไม่ใช่การเพิ่มปริมาณงาน บนเซิร์ฟเวอร์ที่โหลดเต็มอยู่แล้ว มันอาจทำให้ช้าลงได้ [3]

เพราะประโยชน์ที่ได้มาจากช่วงที่การทำงานติดหน่วยความจำ พอ batch ใหญ่ขึ้นจนกลายเป็นงานที่ติดพลังประมวลผล ข้อได้เปรียบนั้นก็หายไป [3]

EAGLE-3 ต่างจากวิธีพื้นฐานตรงไหน

EAGLE ย่อมาจาก Extrapolation Algorithm for Greater Language-model Efficiency และเป็นวิธีที่ทำงานที่ ระดับ feature ไม่ใช่ระดับโทเคน [2][4]

วิธีดั้งเดิมใช้โมเดลร่างที่เดาโทเคน แต่ EAGLE เดา hidden state แล้วใช้ LM head ของโมเดลใหญ่ที่แช่แข็งอยู่ แปลง state นั้นเป็นโทเคน [2][4]

⇒ ทำไมถึงได้ผลกว่า เพราะ EAGLE ทำ autoregression ที่ระดับ feature โดยใช้ feature จากชั้นบนสุดของโมเดลเป้าหมายซ้ำ ซึ่งให้ผลดีกว่าการเดาโทเคนแบบพื้นฐาน [4]

EAGLE-3 เป็นรุ่นที่สาม และมีการเปลี่ยนที่สำคัญสองอย่าง [4]

หนึ่ง ทิ้งการทำนาย feature แล้วหันมาทำนายโทเคนโดยตรง [4]

สอง เลิกพึ่ง feature จากชั้นบนสุดชั้นเดียว แล้วใช้ การหลอม feature จากหลายชั้น ด้วยเทคนิคที่ทีมงานเรียกว่า training-time test [4]

ทีมงานอธิบายเหตุผลว่าการขยายข้อมูลเทรนให้ EAGLE รุ่นก่อนได้ผลจำกัด เพราะข้อจำกัดของการทำนาย feature พอเปลี่ยนวิธีแล้ว โมเดลร่างจึงได้ประโยชน์จากการขยายข้อมูลเทรนเต็มที่ [4]

ตัวเลขที่เอกสารระบุคือ เร็วขึ้นได้ถึง 6.5 เท่า และดีกว่า EAGLE-2 ประมาณ 1.4 เท่า และในเฟรมเวิร์ก SGLang ได้ปริมาณงานเพิ่ม 1.38 เท่า ที่ batch size 64 [4]

⇒ มีอีกตัวเลขที่ผมเจอในบทวิเคราะห์ด้านวิศวกรรม EAGLE-3 ดันอัตราการยอมรับ α ขึ้นไปอยู่ในช่วง 0.6 ถึง 0.8 สำหรับงานสนทนาทั่วไป ซึ่งเป็นช่วงที่ให้ผลดีจริง [5]

ภาพที่ 3: สี่แบบที่เลือกใช้ได้ตามข้อจำกัดของแต่ละคน

ทางเลือกอื่นที่ไม่ต้องมีโมเดลร่าง

เอกสารทางการของ llama.cpp ยังมีอีกหลายแบบที่ ไม่ต้องโหลดโมเดลเพิ่ม ซึ่งผมคิดว่าสำคัญสำหรับคนที่หน่วยความจำจำกัด [1]

แบบใช้สถิติ n-gram ระบบเก็บสถิติของลำดับโทเคนสั้น ๆ แล้วสร้างคำทำนายจากความน่าจะเป็นที่ได้จากสถิติเหล่านั้น โดยอ้างอิงจากโทเคนที่เคยปรากฏในบริบทก่อนหน้า ข้อดีคือไม่มีค่าใช้จ่ายเพิ่มเลย [1]

และมีแบบที่ใช้แฮช เอกสารระบุว่าเบามาก ใช้หน่วยความจำคงที่ประมาณ 16 MB และใช้พูลแฮชร่วมกันได้ทุก slot ของเซิร์ฟเวอร์ คำขอที่ต่างกันจึงได้ประโยชน์จากกันได้ [1]

⇒ แบบ n-gram เหมาะกับงานที่มีรูปแบบซ้ำ เช่น การเขียนโค้ดทับข้อความเดิม · โมเดลที่ต้องทวนความคิดซ้ำในคำตอบสุดท้าย และ งานสรุป [1]

ใครได้ใช้บ้าง

หนึ่ง · คนที่รันโมเดลในเครื่อง ถ้าเคยรู้สึกว่า local model ช้า แต่ยังมีแรมเหลือ การเพิ่มโมเดลร่างคือทางที่ตรงที่สุด ต้นทุนคือหน่วยความจำเพิ่มขึ้นเท่านั้น [1][3]

สอง · ทีมที่เสิร์ฟโมเดลให้ผู้ใช้หลายคน ต้องพิจารณาให้ดี เพราะเทคนิคนี้ช่วยลดความหน่วง แต่ไม่ได้เพิ่มปริมาณงาน และจะเสียประโยชน์เมื่อ batch ใหญ่จนติดพลังประมวลผล [3]

สาม · คนที่ทำงานกับงานที่มีรูปแบบซ้ำชัด เช่นการแก้โค้ด การสรุป แบบ n-gram ให้ประโยชน์โดยไม่ต้องโหลดโมเดลเพิ่มเลย [1]

สี่ · ทีมที่ใช้เฟรมเวิร์กสำเร็จรูป EAGLE-3 ถูกนำไปใช้ในเฟรมเวิร์กการเสิร์ฟโมเดลแล้ว ผู้ใช้จึงไม่ต้องเทรน draft model เอง [4]

และมีอีกกลุ่มที่ได้ประโยชน์คือ ผู้ให้บริการ API ที่คิดราคาตามความหน่วง แต่นี่เป็นการคาดเดาของผม ไม่ได้มาจากแหล่ง

ข้อจำกัดที่ควรรู้

ต้องใช้หน่วยความจำเพิ่ม ทั้งโมเดลร่างและ cache ของมันกินแรม ถ้าโมเดลหลักใช้เต็มเครื่องอยู่แล้ว จะแย่ลงแทนที่จะดีขึ้น [1]

ต้องมีคู่ที่เข้ากันได้ โมเดลร่างต้องใช้ tokenizer เดียวกับโมเดลหลัก และ draft model ของ EAGLE-3 ต้องเทรนมาสำหรับโมเดลเป้าหมายตัวนั้นโดยเฉพาะ เอกสารยกตัวอย่างว่า Qwen3-4B_eagle3 ใช้กับ Qwen/Qwen3-4B [1]

บางแบบยังรองรับแคบ ตัวอย่างคือ DSpark ที่เอกสารระบุว่าปัจจุบันรองรับเฉพาะ draft ที่มี backbone เป็น Qwen3 และมีแผนจะรองรับ Gemma4 ในอนาคต [1]

ต้องวัดของตัวเอง ตัวเลข 6.5 เท่าเป็นผลจากการทดลองของทีมวิจัยบนงานที่กำหนด ไม่ใช่ตัวเลขที่รับประกันได้กับทุกงาน [4]

---

ถ้าคุณอยากเริ่ม ลำดับที่ผมแนะนำคือ เริ่มจากแบบ n-gram ก่อน เพราะไม่ต้องโหลดโมเดลเพิ่มและไม่มีค่าใช้จ่ายด้านหน่วยความจำ ถ้าได้ผลก็ไม่ต้องทำอะไรต่อ [1]

⇒ ถ้ายังไม่พอ ค่อยเพิ่มโมเดลร่างแบบธรรมดา และถ้าใช้โมเดลที่มียอดนิยมอย่าง Qwen หรือ Llama อยู่แล้ว ค่อยมองหา draft model ของ EAGLE-3 ที่มีคนเทรนไว้แล้ว [1][4]

และทุกครั้ง ให้วัดด้วยคำสั่งเดิมทั้งเปิดและปิด เพราะเพดานที่แท้จริงขึ้นอยู่กับอัตราการยอมรับบนงานของคุณ ไม่ใช่บนงานของคนอื่น [3]

แหล่งอ้างอิง

[1] llama.cpp — "Speculative Decoding" (เอกสารทางการของโปรเจกต์), กันยายน 2026 — https://github.com/ggml-org/llama.cpp/blob/master/docs/speculative.md

[2] Zack Li — "Speculative Decoding Deep Dive III: EAGLE, DFlash", 4 กันยายน 2026 — https://zackli.ai/blog/speculative-decoding-3

[3] dev.to (ji_ai) — "Speculative Decoding: Why a Great Draft Model Still Caps Speedup", กันยายน 2026 — https://dev.to/ji_ai/speculative-decoding-why-a-great-draft-model-still-caps-speedup-12i1

[4] arXiv — "EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test" (Yuhui Li และคณะ), arXiv:2503.01840v3, 2025 (แก้ไขล่าสุด 23 เมษายน 2025) — https://arxiv.org/abs/2503.01840

[5] Tai Bui — "EAGLE-3 Speculative Decoding in Production", 2026 — https://taibui.dev/phases/17-infrastructure-and-production/05-eagle3-speculative-decoding