DSpark: เร่งความเร็วการอนุมาน LLM ด้วย speculative decoding [pdf]

 (github.com/deepseek-ai)
1 คะแนน โดย GN⁺ 7 시간 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • DSpark: เฟรมเวิร์ก speculative decoding ที่ผสานการสร้างแบบกึ่งอัตถดถอย (semi-autoregressive) เข้ากับการจัดตารางตามความเชื่อมั่น
  • parallel drafter เสนอบล็อกโทเค็นยาวได้ด้วย forward pass ครั้งเดียว แต่เกิดปัญหา acceptance decay ในช่วงท้ายอย่างรวดเร็วจากการไม่มี dependency ระหว่างโทเค็น ซึ่งแก้พร้อมกันด้วย โครงสร้างกึ่งอัตถดถอย และ การตรวจสอบที่รับรู้โหลด
  • ผสาน parallel backbone ขนาดหนักกับ โมดูล sequential น้ำหนักเบาเพื่อใส่ dependency ภายในบล็อก รักษาความเร็วในการ draft พร้อมบรรเทา suffix decay
  • confidence head ประเมินความน่าจะเป็นที่ prefix จะรอดในแต่ละตำแหน่ง และ scheduler ที่รับรู้ฮาร์ดแวร์ ปรับ ความยาวการตรวจสอบ แบบไดนามิกในแต่ละคำขอให้สอดคล้องกับเส้นโค้ง throughput ของเอนจิน
  • ใน benchmark แบบออฟไลน์ เพิ่ม accepted length ได้อย่างสม่ำเสมอเมื่อเทียบกับ baseline แบบอัตถดถอย (Eagle3) และ baseline แบบขนาน (DFlash) และเมื่อ deploy บนบริการจริง DeepSeek-V4 ก็ลดการตรวจสอบที่สูญเปล่า
  • เมื่อเทียบกับ MTP-1 ซึ่งเป็น production baseline เดิม เร่งความเร็วการสร้างต่อผู้ใช้ที่ throughput เท่ากันได้ 60–85% และเปิดช่วงประสิทธิภาพที่เดิมไปไม่ถึงภายใต้ข้อจำกัดด้าน interactivity ที่เข้มงวด ช่วย ขยาย Pareto frontier

นิยามปัญหา — คอขวดสองประการของ parallel drafter

  • LLM สร้างโทเค็นแบบอัตถดถอย โดยแต่ละโทเค็นต้องใช้ forward pass ที่ condition บนโทเค็นก่อนหน้าทั้งหมด ทำให้ latency ของการอนุมานแปรผันตามความยาว output และการใช้ GPU ต่ำกับเวลารอสูงกลายเป็นคอขวดหลักของ production serving
  • Speculative decoding ให้โมเดล draft น้ำหนักเบาเสนอบล็อก candidate แล้วให้โมเดล target ตรวจสอบด้วย forward pass ครั้งเดียว จากนั้นใช้ rejection sampling เพื่อยอมรับ prefix ที่ยาวที่สุดซึ่งสอดคล้องกับ distribution ของ target จึงเร่งได้ โดยไม่สูญเสียคุณภาพ

  • ข้อจำกัดของ drafter แบบอัตถดถอย

    • มีความสามารถในการ modeling สูงเพราะแต่ละตำแหน่ง condition บนโทเค็นก่อนหน้า แต่ต้นทุน drafting แปรผันเชิงเส้นกับขนาดบล็อก (𝑇draft ∝ 𝛾) จึงถูกจำกัดให้ใช้ บล็อกขนาดเล็ก และ โครงสร้างตื้น

  • ข้อจำกัดของ parallel drafter

    • สร้างทุกตำแหน่งพร้อมกัน ทำให้ latency ของ draft แทบไม่ขึ้นกับขนาดบล็อก และใช้บล็อกใหญ่ได้ (เช่น 𝛾=16)
    • ทำนายแต่ละตำแหน่งแบบอิสระ จึง modeling dependency ระหว่างโทเค็นไม่ได้ ทำให้เกิด multi-modal collision และ acceptance rate ลดลงอย่างรวดเร็วในช่วงท้าย
    • หากตรวจสอบบล็อกยาวทั้งหมดโดยไม่เลือก จะทำให้ throughput ลดลง โดยเฉพาะในสภาพแวดล้อมที่มี concurrency สูง ซึ่งโทเค็นที่มีความเสี่ยงถูกปฏิเสธสูงจะกิน batch capacity
    • ความยาวการตรวจสอบที่เหมาะสมเปลี่ยนแปลงตามสองแกน — ด้านข้อมูล (คำขอเชิงโครงสร้าง เช่น โค้ด มี acceptance rate สูง ส่วนแชตปลายเปิดต่ำ) และด้านระบบ (เมื่อโหลดต่ำ การตรวจสอบเพิ่มแทบฟรี แต่เมื่อโหลดสูงจะเบียด capacity ของคำขอ active อื่น)

สถาปัตยกรรม — องค์ประกอบสองส่วนที่เสริมกัน

  • latency ต่อโทเค็นคือ 𝐿 = (𝑇draft + 𝑇verify)/𝜏 และการเร่งความเร็วลดรูปเป็นสามคันโยก: ลด 𝑇draft, เพิ่ม 𝜏, และลด 𝑇verify ที่มีผลจริง

  • รอบการ decode: จากพรอมป์ ABC โมเดล target สร้างโทเค็นถัดไป D (ทำหน้าที่เป็น anchor) → parallel backbone และ sequential head สร้าง draft EFGH พร้อมคะแนนความเชื่อมั่น c1–c4 → scheduler เก็บ prefix EFG และตัดโทเค็นความเชื่อมั่นต่ำ H → โมเดล target ตรวจสอบแบบขนาน ยอมรับ E·F และเมื่อปฏิเสธ G ก็สร้างโทเค็นแก้ไข G*

  • การสร้างแบบกึ่งอัตถดถอย (Semi-Autoregressive Generation)

    • Parallel drafter อาจสร้างการผสมที่ไม่สอดคล้องอย่าง “of problem” จากความเป็นไปได้ต่อเนื่องหลายแบบเช่น “of course”/“no problem” เพราะแต่ละตำแหน่ง marginalize เหนือโทเค็นก่อนหน้าที่เป็นไปได้ทั้งหมด ไม่ใช่โทเค็นก่อนหน้าที่ถูก sample จริง
    • Parallel stage: parallel backbone (ใช้ DFlash) ทำ forward pass ครั้งเดียวกับทั้งบล็อก สร้าง hidden state และ logits พื้นฐาน โดยปฏิบัติต่อ anchor เองเป็นตำแหน่งทำนายแรก ใช้ input 𝛾 ตัวเพื่อสร้าง logits 𝛾 ชุด ลดงาน draft
    • Sequential stage: เพิ่ม transition bias 𝐵𝑘 ที่ขึ้นกับ prefix ลงใน logits พื้นฐาน เพื่อให้แต่ละตำแหน่ง condition บนโทเค็นที่ sample ก่อนหน้าในบล็อก นำไปสู่ causal block distribution ผ่านการแยกแบบอัตถดถอย และเนื่องจากเป็นการประมวลผล sequential จึงต้องเบาพอเมื่อเทียบกับ parallel stage (𝑇sequential ≪ 𝑇parallel)
      • Markov head: ทำให้ง่ายเป็น first-order transition ที่ขึ้นกับโทเค็นก่อนหน้าทันทีเท่านั้น ประมาณเมทริกซ์เต็ม 𝑉×𝑉 ด้วย low-rank factorization 𝐵 = 𝑊1𝑊2 (ค่าเริ่มต้น 𝑟=256) เพื่อลดพื้นที่เก็บและงานต่อขั้น เมื่อ sample “of” แล้วจะเสริม “course” และกด “problem” ลดการชนข้ามโหมด
      • RNN head: สะสมประวัติ prefix ทั้งหมดในบล็อกด้วย recurrent state 𝑠𝑘 และเข้าถึงข้อมูลก่อนหน้าโทเค็นล่าสุดผ่าน gated update แต่มีความซับซ้อนในการ implement สูงและคุณลักษณะด้าน deployment เสียเปรียบ

  • การตรวจสอบแบบจัดตารางตามความเชื่อมั่น (Confidence-Scheduled Verification)

    • Acceptance rate ของ draft แปรผันตามโดเมน (โค้ดสูง แชตปลายเปิดต่ำ) และต้นทุนการตรวจสอบโทเค็นเพิ่มเติมเปลี่ยนไปตามโหลดของเอนจิน จึงต้องมีกลไกรวมที่ route งานของ target เฉพาะโทเค็นที่มี expected gain เป็นบวก
    • Confidence Head: ส่งออกค่าประมาณสเกลาร์ 𝑐𝑘 ∈ (0,1) ในแต่ละตำแหน่ง 𝑘 โดย modeling ความน่าจะเป็นแบบมีเงื่อนไขที่โทเค็นตำแหน่ง 𝑘 จะผ่านการตรวจสอบภายใต้เงื่อนไขว่าโทเค็นก่อนหน้าทั้งหมดถูกยอมรับ ใช้โครงสร้าง linear projection น้ำหนักเบา + sigmoid
      • ฝึกแบบ supervised ด้วยอัตรายอมรับรายขั้นเชิงวิเคราะห์ 𝑐*𝑘 = 1 − ½‖𝑝𝑑𝑘 − 𝑝𝑡𝑘‖1 (total variation distance ระหว่าง distribution ของ draft และ target)
    • การปรับเทียบภายหลัง — Sequential Temperature Scaling (STS): การจัดตารางที่รับรู้ฮาร์ดแวร์ต้องใช้ค่าสัมบูรณ์ของความน่าจะเป็นยอมรับสะสม แต่ confidence จาก neural network มักมีแนวโน้มมั่นใจเกินไป (overconfident) เนื่องจาก 𝑐𝑖 แต่ละตัวเป็นความน่าจะเป็นแบบมีเงื่อนไข จึง factorize ด้วยผลคูณสะสมของ prefix และทำ 1D grid search จากซ้ายไปขวาบน held-out validation set เพื่อลด ECE ให้ต่ำที่สุด เป็นการแปลงที่รักษาลำดับจึงไม่เปลี่ยน ranking ของโทเค็น
    • Hardware-Aware Prefix Scheduler: กำหนดปัญหาการเลือกความยาวการตรวจสอบเป็นการเพิ่ม throughput โดยรวมสูงสุด ใช้ SPS(𝐵) (ตารางต้นทุนที่ profile หนึ่งครั้งตอนเริ่มเอนจิน) สำหรับคำขอ active 𝑅 รายการ และ maximize 𝛩 = 𝜏·SPS(𝐵)
      • เนื่องจากความน่าจะเป็นการอยู่รอด 𝑎𝑟,𝑗 ไม่เพิ่มขึ้นตาม 𝑗 การ sort ทั่วโลกและเลือกแบบ greedy จึงเคารพ dependency ของ prefix ภายในบล็อกโดยธรรมชาติ และทำ incremental admit ด้วยการ lookup ตารางต้นทุน 𝑂(1)
      • Speculative decoding แบบ lossless ต้องการคุณสมบัติ non-anticipating แต่ feature แบบ Markov ขึ้นกับโทเค็นที่ sample ก่อนหน้า ทำให้การค้นหาทั่วโลกภายหลังรั่วข้อมูล 𝑥𝑟,𝑘 และก่อให้เกิด selection bias
      • ใช้กลไก early-stopping ให้หยุดทันทีเมื่อ throughput ลดลง บังคับ causal โดยให้การตัดสินใจ admit ขึ้นกับเฉพาะ prefix ที่ประมวลผลถึงขั้นนั้น และรับประกัน global maximum เฉพาะเมื่อวัตถุประสงค์ 𝛩 เป็น unimodal

การฝึก (Training)

  • สุ่ม sample anchor หลายตำแหน่งจาก target sequence เพื่อสร้างบล็อก 𝛾 โทเค็นเป็นข้อมูลฝึก
  • ตรึงโมเดล target ตลอดกระบวนการ, โมเดล draft แชร์และตรึง embedding layer กับ LM head และอัปเดตเฉพาะ backbone drafter, sequential block และ confidence head
  • วัตถุประสงค์การฝึกเป็นผลรวมถ่วงน้ำหนักของสามพจน์ — cross-entropy loss Lce, distribution matching loss Ltv, confidence loss Lconf
    • ทุกพจน์ถ่วงด้วยน้ำหนักตำแหน่ง 𝑤𝑘 = exp(−(𝑘−1)/𝛾) เพื่อเน้นตำแหน่งต้น ๆ ซึ่งมีส่วนต่อ expected accepted length มากกว่าในการตรวจสอบแบบ prefix
    • Ltv ลงโทษ total variation distance และเพราะอัตรายอมรับรายขั้นเท่ากับ 1 − ½‖𝑝𝑑 − 𝑝𝑡‖1 การ minimize Ltv จึงเท่ากับการ maximize expected acceptance rate
    • น้ำหนักเริ่มต้น 𝛼ce = 0.1, 𝛼tv = 0.9, 𝛼conf = 1.0

การทดลอง — benchmark ออฟไลน์

  • การตั้งค่า

    • โมเดล target: Qwen3-{4B, 8B, 14B}, Gemma4-12B / drafter สำหรับเปรียบเทียบ: DFlash ซึ่งเป็น parallel drafter ระดับ SOTA, Eagle3 ซึ่งเป็น drafter แบบอัตถดถอย
    • ฝึกใหม่ทั้งหมดด้วยเฟรมเวิร์กและข้อมูลเดียวกัน จัด horizon TTT (7) ของ Eagle3 ให้ตรงกับขนาดบล็อก (7) ของ DFlash·DSpark โดย Eagle3 ใช้จำนวนชั้น draft 1 ชั้น ส่วน DSpark และ DFlash ใช้ 5 ชั้น
    • ข้อมูลฝึก: Open-PerfectBlend 1.3 ล้าน sample (chat 17.6%, math 39.4%, code 38.9%, instruction-following 4.1%) ใช้เฉพาะพรอมป์ และให้โมเดล target แต่ละตัวสร้างคำตอบใหม่ ฝึก 10 epoch
    • โดเมนประเมิน: คณิตศาสตร์ (GSM8K, MATH500, AIME25), โค้ด (MBPP, HumanEval, LiveCodeBench), แชตทั่วไป (MT-Bench, Alpaca, Arena-Hard), sampling temperature 1.0 และรายงาน accepted length 𝜏 ต่อรอบ

  • ผลลัพธ์หลัก

    • การประเมินออฟไลน์ปิดใช้ confidence scheduler เพื่อแยกคุณภาพ draft ล้วน ๆ ด้วยบล็อกคงที่
    • บน Qwen3-4B·8B·14B เพิ่ม macro average accepted length เมื่อเทียบกับ Eagle3 ได้ 30.9%·26.7%·30.0% และเมื่อเทียบกับ DFlash ได้ 16.3%·18.4%·18.3%; บน Gemma4-12B ก็ได้ประโยชน์สม่ำเสมอ ยืนยันการ generalize ข้าม model family
    • Accepted length ของงานเชิงโครงสร้างสูงกว่าแชตปลายเปิด (สำหรับ Qwen3-4B: คณิตศาสตร์ 5.57·โค้ด 5.12 เทียบกับแชต 3.49) ความแปรปรวนของความคาดเดาได้ของข้อมูลทำให้ความยาวการตรวจสอบแบบคงที่สูญเปล่า และเป็นแรงจูงใจของ confidence scheduling

วิเคราะห์การทดลอง

  • ทำไมการสร้างแบบขนานจึงเหนือกว่าอัตถดถอย

    • มีข้อสังเกตที่ขัด intuition ว่า drafter แบบขนานและกึ่งอัตถดถอยให้ accepted length ยาวกว่า Eagle3 ที่เป็นอัตถดถอยเต็มรูปแบบ วิเคราะห์ด้วย conditional acceptance rate รายตำแหน่ง (นับในตัวหารเฉพาะกรณีที่ตำแหน่งก่อนหน้าทั้งหมดถูกยอมรับแล้ว)
    • ความได้เปรียบด้าน capacity ที่ตำแหน่ง 1: ตำแหน่งแรกขึ้นกับบริบทของ target เท่านั้น Eagle3 ถูกจำกัดให้ใช้ network ตื้นเพราะ latency 𝑂(𝛾) แต่ drafter แบบขนาน 𝑂(1) ใช้ network ลึกได้ DFlash จึงเริ่มสูงกว่า Eagle3 (คณิตศาสตร์ 0.88 เทียบกับ 0.81, แชต 0.72 เทียบกับ 0.53) และเพราะการปฏิเสธโทเค็นแรกทำให้ทั้งบล็อกเป็นโมฆะ ความได้เปรียบเริ่มต้นจึงมีผลมากต่อ accepted length สุดท้าย
    • ข้อจำกัดด้าน independence ในตำแหน่งท้าย: ในตำแหน่ง 2–7 Eagle3 ใช้ conditional certainty จึงรักษาหรือเพิ่มระดับได้ (แชต 0.53→0.74) ส่วน DFlash ลดลงรวดเร็ว (โค้ด 0.87→0.78, แชต 0.72→0.63) เกิด suffix ที่ไม่สอดคล้องจาก multi-modal collision
    • การบรรเทา suffix collapse ของกึ่งอัตถดถอย: DSpark สืบทอด acceptance สูงช่วงต้นจาก parallel backbone ลึก (คณิตศาสตร์เริ่ม 0.93) พร้อมกดการยุบช่วงท้ายด้วย sequential head น้ำหนักเบา ทำให้ conditional acceptance rate สูงและเสถียรตลอดทั้งบล็อก

  • อัตถดถอยเพียงเล็กน้อยก็ให้ผลมาก

    • ความลึกของ drafter: เมื่อตรึงขนาดบล็อกที่ 7 การเพิ่มจำนวนชั้น DSpark จาก 1→5 ทำให้ประสิทธิภาพเพิ่มขึ้นแบบ monotonic โดย marginal gain สูงสุดที่ 1→2 ชั้น และ DSpark 2 ชั้นเหนือกว่า DFlash 5 ชั้นในทุกโดเมน พิสูจน์ประสิทธิภาพเชิงพารามิเตอร์ของ sequential head
    • ความยาวที่เสนอ: เมื่อตรึงความลึกที่ 5 และขยายความยาว draft เป็น {4,8,12,16} DSpark เหนือกว่า DFlash ในทุกความยาว และช่องว่างกว้างขึ้นเมื่อ 𝛾 เพิ่มขึ้น (ที่ 𝛾=7: คณิตศาสตร์ 16%·โค้ด 15%·แชต 18%, ที่ 𝛾=15: 30%·26%·22%) RNN head ให้ประโยชน์เพิ่มเล็กน้อยในความยาวมาก จึงเลือก Markov head เป็นค่าเริ่มต้น
    • latency overhead: โดยเฉลี่ยจาก batch 128 และ context length {512,1024,2048,4096} latency ของ sequential block น้อยจนละเลยได้ เมื่อขยายความยาว draft จาก 4→16 เพิ่ม latency รวมต่อรอบเพียง 0.2–1.3% แต่เพิ่ม accepted length ได้ถึง 30%

  • บทบาทของ confidence head — ไม่ใช่ตรวจสอบให้ยาวขึ้น แต่ให้ฉลาดขึ้น

    • วินิจฉัยด้วยการ sweep threshold แบบคงที่บน Qwen3-4B เมื่อเพิ่ม threshold อัตรายอมรับเพิ่มขึ้นจากการกรองโทเค็นที่จะถูกปฏิเสธ โดยเห็นผลมากที่สุดในแชต (45.7%→95.7%) ส่วนคณิตศาสตร์ (76.9%→92.5%) และโค้ด (67.6%→92.0%) เพิ่มอย่างค่อยเป็นค่อยไป
    • threshold คงที่มองข้ามโหลดระบบ จึงไม่เหมาะใน dynamic serving แม้ confidence model มี discriminative power สูง (ROC-AUC 0.81–0.90) แต่มั่นใจเกินไป (ECE 3–8%) หลังใช้ STS ลด ECE เฉลี่ยเหลือราว 1% ทำให้ได้การประมาณการอยู่รอดที่น่าเชื่อถือ

การ deploy บริการจริง

  • การฝึกที่ขยายได้

    • deploy ร่วมกับ DeepSeek-V4-Flash·Pro preview โดย parallel backbone ประกอบด้วย MoE 3 ชั้นที่ใช้ mHC และ sliding window attention 128, ขนาดบล็อกสูงสุด 𝛾=5, ใช้ Markov head และ confidence head ฝึก end-to-end แล้วปรับเทียบด้วย STS
    • Hidden state communication: แทนที่จะส่ง logits ของ vocabulary ทั้งหมด (𝑉≈10⁵) จะสื่อสารเฉพาะ hidden state ก่อน LM head และรัน LM head แบบ local บน draft worker เฉพาะตำแหน่ง sample ลดความซับซ้อนของการสื่อสารต่อโทเค็นเป็น 𝑂(𝑑)
    • Anchor-bounded sequence packing: sample draft anchor จำนวนคงที่และ pack บล็อกทำนายที่แยกจากกันเป็น dense batch รักษา causal masking ระหว่างหลาย sequence อิสระด้วย token-level attention index พร้อมหลีกเลี่ยง padding overhead

  • การใช้ scheduler ในภาคปฏิบัติ

    • ความขัดแย้งสองประการ — algorithm สมมติว่าเส้นโค้ง capacity เรียบและ unimodal แต่ SPS(𝐵) จริงลดลงแบบ discrete และเป็นขั้นบันได อีกทั้ง dynamic token scheduling รายขั้นขัดกับ CUDA graph replay ต่อเนื่องและ Zero-Overhead Scheduling (ZOS)
    • ปรับด้วย asynchronous scheduling เนื่องจาก ZOS ต้องการขนาด batch ถัดไปก่อนขั้นปัจจุบันเสร็จ จึงประมาณ capacity การตรวจสอบด้วย output ความเชื่อมั่นเมื่อสองขั้นก่อน จัดเรียง candidate ขั้นปัจจุบันด้วยความเชื่อมั่นสะสมล่าสุด และใช้การทำนายในอดีตเฉพาะเพื่อตัดสินความยาวตัดแบบไดนามิก (𝐾) โดย cast เป็น dynamic top-𝐾 selection
    • เอา early stopping ออกเพื่อเปิดใช้ global search แบบไร้ข้อจำกัด เพราะประเมินเฉพาะประวัติเมื่อสองขั้นก่อน จึงแยกจากการเกิดขึ้นจริงของโทเค็นปัจจุบัน 𝑥𝑟,𝑘 และสร้าง causal barrier ทำให้ maximize physical throughput ข้าม hardware cliff ได้พร้อมรักษา distribution ของ target อย่างถูกต้อง

  • การอนุมาน throughput สูงและ latency ต่ำ

    • Production serving optimize ทั้ง latency ต่อคำขอและ throughput รวมพร้อมกัน ใน deployment นี้ ด้วยข้อจำกัด KV-cache capacity และทราฟฟิกผู้ใช้ ทำให้ effective batch size อยู่ต่ำกว่า threshold ที่ทำให้ GPU อิ่มตัว สองเป้าหมายจึงกลายเป็นความสัมพันธ์สูงแทนที่จะเป็นการแข่งขันกัน
    • ความท้าทายคือรองรับ query ความยาวแปรผัน หากประมวลผลตรง ๆ บน decode kernel ความยาวคงที่จะเกิด padding และโหลดไม่สม่ำเสมอ ทำให้ใช้ GPU ต่ำ จึง flatten โทเค็นคำขอทั้งหมดเป็น element อิสระและส่ง dependency ภายใน sequence ผ่าน marker tensor ของ sparse attention โดยใน DeepSeek-V4 แก้เฉพาะ index-attention และ compress kernel เพื่อรองรับ variable-length routing

  • ประสิทธิภาพบนทราฟฟิกผู้ใช้จริง

    • เปรียบเทียบ DSpark-5 (𝛾=5) กับ baseline MTP-1 บน production engine ของ V4-Flash·Pro โดย MTP-1 เป็นการตั้งค่าโทเค็นเดี่ยวที่คงไว้ เพราะ static multi-token drafter (MTP-3/5) ลด throughput ในภาวะ concurrency สูง และถูกแทนที่ด้วย DSpark สองสัปดาห์หลังเปิดตัว DeepSeek-V4-preview
    • V4-Flash: ที่ SLA 80 tok/s/user throughput เพิ่ม 51%, ที่ 120 tok/s/user MTP-1 เข้าใกล้ขีดจำกัดการดำเนินงาน ทำให้ DSpark เหนือกว่าเชิงนาม 661% (ควรตีความเป็นหลักฐานของการขยาย interaction frontier ไม่ใช่อัตราคูณสัมบูรณ์), ที่ throughput เท่ากัน การสร้างต่อผู้ใช้เร็วขึ้น 60–85%
    • V4-Pro: ที่ 35 tok/s/user เพิ่ม 52%, ที่ 50 tok/s/user เหนือกว่าเชิงนาม 406%, ที่ capacity เท่ากันเร็วขึ้น 57–78%, โดยรวมเลื่อน throughput–interactivity frontier ออกไปด้านนอก
    • พฤติกรรมปรับตามโหลด: ที่ concurrency ระดับกลาง (V4-Flash ต่ำกว่า 200 คำขอ·V4-Pro ต่ำกว่า 150 คำขอ) scheduler ขยาย MTP-1 แบบ static 2 โทเค็นเป็นราว 4–6 โทเค็นต่อคำขอ เพิ่มโทเค็นที่ยอมรับต่อ forward pass และเมื่อ concurrency อิ่มตัว ก็ลดความยาวการตรวจสอบอย่างนุ่มนวล เพื่อตัดโทเค็นความเชื่อมั่นต่ำก่อนกิน batch capacity

  • ข้อจำกัด

    • Prefix scheduler ลดการตรวจสอบ target ที่สูญเปล่าให้ต่ำที่สุด แต่ยังมีต้นทุน draft คงที่ในการสร้างบล็อก 𝛾 โทเค็นเริ่มต้นของ parallel backbone สำหรับ query ซับซ้อนที่มี acceptance rate ต่ำโดยธรรมชาติ งานล่วงหน้านี้กู้คืนไม่ได้
    • ในอนาคตอาจปรับปรุงด้วย difficulty-aware early exiting ภายในโมเดล draft เพื่อให้คำขอดังกล่าวข้ามการสร้างทั้งบล็อกได้

สรุป

  • ในเชิงโครงสร้าง ใช้พาราไดม์กึ่งอัตถดถอยที่ผสาน parallel backbone ขนาดหนักกับ sequential head น้ำหนักเบา เพื่อลดการยุบของ suffix อย่างรวดเร็วใน drafter แบบขนานอิสระ
  • ในเชิงระบบ กำหนดการเลือกความยาวการตรวจสอบเป็นปัญหา maximize throughput โดยรวม และปรับงบการตรวจสอบแบบไดนามิกด้วย hardware-aware prefix scheduler ที่อิงความน่าจะเป็นการอยู่รอดที่ปรับเทียบแล้วและโหลดเอนจินแบบเรียลไทม์
  • การประเมินออฟไลน์กว้างขวางเหนือกว่า baseline แบบอัตถดถอยและแบบขนานระดับ SOTA และในการ deploy จริงบน DeepSeek-V4 พิสูจน์คุณค่าใช้งานจริงผ่านการรักษา concurrency ภายใต้โหลดสูง การเร่งการสร้างต่อผู้ใช้ และการขยาย Pareto frontier ของ LLM serving

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น