เหตุใด DeepSeek จึงราคาถูกเมื่อให้บริการในสเกลใหญ่ แต่กลับแพงเมื่อรันแบบโลคัล

 (seangoedecke.com)
5 คะแนน โดย GN⁺ 2025-06-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • AI บางโมเดล เช่น DeepSeek-V3 มีต้นทุนต่ำและทำงานได้เร็วเมื่อให้บริการในสเกลใหญ่ แต่จะช้าและมีต้นทุนสูงเมื่อ รันแบบโลคัล
  • สาเหตุอยู่ที่ trade-off พื้นฐานระหว่าง throughput (ปริมาณงาน) และ latency (เวลาแฝง) ซึ่งเกี่ยวข้องกับ ประสิทธิภาพการใช้งาน GPU
  • เมื่อเพิ่ม ขนาดแบตช์ GPU จะทำงานได้มีประสิทธิภาพขึ้น แต่ผู้ใช้ต้องรอให้โทเค็นถูกรวมก่อน จึงเกิด เวลาแฝงที่เพิ่มขึ้น
  • โมเดลที่มี โครงสร้าง Mixture-of-Experts และ pipeline แบบลึก ต้องอาศัยแบตช์ขนาดใหญ่และเวลาแฝงที่สูง
  • ในสภาพแวดล้อมโลคัลที่มีผู้ใช้เพียงคนเดียว การสร้าง แบตช์ที่ใหญ่พอ ทำได้ยาก จึงเกิดปัญหาประสิทธิภาพลดลงและต้นทุนเพิ่มขึ้น
  • OpenAI, Anthropic และรายอื่น ๆ สร้างการตอบสนองที่รวดเร็วได้ด้วยการปรับปรุงประสิทธิภาพของสถาปัตยกรรมเอง กลยุทธ์การทำแบตช์ขั้นสูง หรือการทุ่ม GPU จำนวนมากเกินความจำเป็น

การอนุมานแบบแบตช์และประสิทธิภาพของ GPU

  • GPU คือฮาร์ดแวร์ที่ถูกปรับให้เหมาะกับ การคูณเมทริกซ์ขนาดใหญ่ (GEMM)
  • เมื่อนำโทเค็นจากผู้ใช้หลายคนมารวมกันและรันเป็นเมทริกซ์ขนาดใหญ่ในครั้งเดียว throughput จะเพิ่มขึ้นอย่างมาก เนื่องจากมี overhead ของการไป-กลับต่ำและใช้หน่วยความจำได้มีประสิทธิภาพ
  • เซิร์ฟเวอร์อนุมานจะนำโทเค็นจากหลายคำขอมาเข้าคิว แล้วเลือกแบตช์ที่มีขนาดเหมาะสมเพื่อทำการคำนวณ GEMM ขนาดใหญ่
  • ในกระบวนการนี้ เซิร์ฟเวอร์ต้องเลือกระหว่าง trade-off ของ ขนาดแบตช์ (throughput เพิ่มขึ้น) กับ เวลารอ (latency เพิ่มขึ้น)

เหตุใดบางโมเดลจึงถูกปรับให้เหมาะกับแบตช์ขนาดใหญ่

Mixture of Experts (MoE) และแบตช์

  • โครงสร้าง MoE (คาดว่าใช้ใน DeepSeek-V3 และ GPT-4) เป็นสาเหตุหลักที่ทำให้ประสิทธิภาพ GPU ต่ำ
  • บล็อก "ผู้เชี่ยวชาญ" หลายร้อยบล็อกต่างต้องใช้การคูณเมทริกซ์แยกกัน ดังนั้นเมื่อเป็นแบตช์ขนาดเล็ก ผู้เชี่ยวชาญแต่ละตัวจะมีงานน้อยและทำงานได้ไม่คุ้ม
  • ต้องมีคำขอพร้อมกันจำนวนมาก จึงจะใช้ผู้เชี่ยวชาญทั้งหมดได้อย่างเต็มที่ ดังนั้นในระดับบริการจริง แบตช์ขนาดใหญ่จึงเป็นสิ่งจำเป็น
  • หาก เวลารอสั้น (หน้าต่าง 5ms) ผู้เชี่ยวชาญจะว่างงานบ่อย แต่หาก เวลารอยาว (หน้าต่าง 200ms) จะดันประสิทธิภาพได้สูงสุด

ปัญหาแบตช์ของโมเดล pipeline แบบลึก

  • ทรานส์ฟอร์เมอร์ขนาดใหญ่ที่มีหลายร้อยชั้น จะรันโดยแบ่งเลเยอร์ไปยัง GPU หลายตัวตามแบบ pipeline
  • หากจำนวนโทเค็นในหนึ่งแบตช์น้อยกว่าจำนวนขั้นของ pipeline จะเกิดปรากฏการณ์ pipeline bubble ซึ่งทำให้ throughput ลดลง
  • เพื่อหลีกเลี่ยงปัญหานี้ จำเป็นต้องใช้แบตช์ขนาดใหญ่ (และต้องรอนานขึ้น) ส่งผลให้ เวลาในการตอบสนองของโมเดลยาวขึ้น

เหตุใดจึงไม่สามารถเติมคิวให้เต็มได้ตลอดเวลา

  • ในทางทฤษฎี หากมีทราฟฟิกพร้อมกันจำนวนมากจนเติมคิวได้ตลอด ก็อาจหลีกเลี่ยง bubble ได้
  • แต่ในทางปฏิบัติ ขั้น Attention ของทรานส์ฟอร์เมอร์ต้องใช้เมทริกซ์ที่มีขนาด (ความยาว) เท่ากันจึงจะทำแบตช์ร่วมกันได้ ทำให้การใช้คิวเดียวให้สมบูรณ์แบบเป็นเรื่องยาก
  • นอกจากนี้ หากแยกขั้น FFN กับ attention ออกจากกัน ก็จะเกิดปัญหา memory overhead พุ่งสูงและการเคลื่อนย้ายข้อมูลไม่มีประสิทธิภาพ

สรุปและข้อสรุป

  • การประมวลผลแบบแบตช์ขนาดใหญ่ จำเป็นต่อการลดต้นทุน GPU และเพิ่ม throughput แต่ผู้ใช้จะต้องแลกด้วยเวลารอที่ยาวขึ้น
  • โมเดลที่มี Mixture-of-Experts และโครงสร้าง pipeline ขนาดใหญ่ โดยธรรมชาติแล้วเหมาะกับสภาพแวดล้อมที่ใช้การรอเพื่อสร้างแบตช์ประสิทธิภาพสูง
  • ใน สภาพแวดล้อมที่ทราฟฟิกต่ำอย่างโลคัล ไม่สามารถจัดแบตช์ขนาดใหญ่ที่เหมาะสมได้ จึงทำให้ประสิทธิภาพ GPU ลดลงอย่างมากและต้นทุนการรันสูงขึ้น
  • เหตุที่ OpenAI, Anthropic และรายอื่น ๆ ตอบสนองได้รวดเร็ว อาจเป็นเพราะ
    • (1) อาจใช้โครงสร้างที่มีประสิทธิภาพกว่าซึ่งไม่ใช่ MoE
    • (2) ใช้การปรับแต่งแบตช์/pipeline และเทคนิคอนุมานขั้นสูง
    • (3) อาจเป็นโครงสร้างที่ซื้อความเร็วด้วยการทุ่ม GPU มากกว่าที่จำเป็น

เพิ่มเติม: ความต่างระหว่าง prefill batch กับแบตช์ในเนื้อหา

  • ทรานส์ฟอร์เมอร์สามารถทำแบตช์ในช่วง prefill (อินพุตยาว) ของพรอมป์ต์จากผู้ใช้คนเดียว เพื่อเร่งการอนุมานช่วงแรกได้
  • แต่แบตช์ที่กล่าวถึงในบทความนี้คือแบตช์ใน ช่วงสร้างโทเค็นจริง ของคำขอจากผู้ใช้หลายคน ซึ่งเป็นจุดที่เกิด trade-off ระหว่าง throughput กับ latency
  • prefill batch ไม่ได้เกี่ยวข้องโดยตรงกับแบตช์พร้อมกันขนาดใหญ่ที่กล่าวถึงในเนื้อหา

หมายเหตุ

  • ระบบอนุมานจริงมักใช้แนวทาง continuous batching ควบคู่กัน โดยจะรันทันทีเมื่อแบตช์เต็ม
  • แต่โครงสร้าง trade-off ระหว่าง throughput-latency พื้นฐานยังคงเหมือนเดิม

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

1 ความคิดเห็น

 
GN⁺ 2025-06-02
ความเห็นจาก Hacker News
  • ฉันรัน Deepseek V3 เองที่บ้านอยู่ และรู้สึกว่าภาระด้านราคาไม่มาก แถมความเร็วกับประสิทธิภาพก็น่าพอใจ หลายคนคิดว่าโมเดลใหญ่รันไม่ได้ถ้าไม่มี GPU แต่จากประสบการณ์ของฉัน กลับมองว่าเซิร์ฟเวอร์ CPU ใช้ไฟน้อยกว่าและใช้งานได้จริงมากกว่า เซิร์ฟเวอร์ที่บ้านใช้บอร์ด Supermicro พร้อม EPYC 9004 ซีรีส์ระดับกลางและ RAM 384GB ต้นทุนรวมประมาณ 4,000 ดอลลาร์ ถ้าไม่มี GPU แต่มี RAM เยอะพอ บางครั้งกินไฟน้อยกว่าเกมมิงเดสก์ท็อปด้วยซ้ำ ใช้โมเดล Unsloth Dynamic GGUF โดยกิน RAM ราว 270GB และใช้งานงานหลากหลายได้ด้วยคุณภาพที่แทบไม่ต่างจากต้นฉบับ ปกติรันที่คอนเท็กซ์ 16k และถ้าจำเป็นก็ขยายไป 24k ความเร็วสร้างโทเคนอยู่ที่ 9~10 ต่อวินาที ถ้าคอนเท็กซ์ใหญ่ก็ลดลงมาเหลือ 7 มีกรณีที่ใช้ 2CPU แล้วรันทั้งโมเดลได้เร็วกว่านี้ด้วย
    • สงสัยว่า Unsloth Dynamic GGUF ให้ประสิทธิภาพใกล้เคียงต้นฉบับจริงแค่ไหน จากประสบการณ์ของฉัน งานง่าย ๆ แทบไม่ต่าง แต่กับงานซับซ้อนหรือคอนเท็กซ์ยาว ความต่างจะเห็นได้ชัด Unsloth ทำงานได้ยอดเยี่ยมจริง แต่ก็น่าเสียดายที่ยังขาดข้อมูลประเมินเทียบตรงกับโมเดลต้นฉบับที่ไม่ถูก quantize และในความเป็นจริง คนหรือบริษัทจำนวนมากก็ไม่มีศักยภาพพอจะรันโมเดลต้นฉบับเอง
    • สงสัยว่าด้วยเครื่องมืออย่าง Ollama จะสามารถรัน Deepseek เพื่อใช้สร้างโค้ดบน CPU 40 คอร์และ RAM 256GB ได้หรือไม่ โดยคิดจะจัดสรรหน่วยความจำให้โมเดลราว 200GB
    • มีการบอกว่าเว็บไซต์ส่วนตัวเข้าไม่ได้ พร้อมแนะนำตัวว่าตนคือ Jeff Carr ผู้ร่วมก่อตั้ง DigitalOcean และหวังว่าจะติดต่อกันได้
    • เคยคิดว่าจำเป็นต้องมี GPU ที่มีหน่วยความจำความเร็วสูง แต่ถามว่าจริง ๆ แล้วจะทำ inference ได้โดยไม่มี GPU และใช้แค่หน่วยความจำขนาดใหญ่ได้จริงหรือไม่ สงสัยว่าทำได้อย่างไรถ้าเป็นหน่วยความจำแบบไม่รวมศูนย์
    • เห็นด้วยว่า Deepseek V3 ใช้งานได้จริงมากในบรรดาโมเดล open-weight หลายงานไม่ได้ต้องใช้ reasoning token ระดับสูงอย่างที่คิด และข้อดีคือไม่ต้องรอนาน ถ้าจำเป็นก็ยังเลือกตัวเลือก reasoning ที่สูงขึ้นได้เสมอ ถ้าไม่ได้รันเอง ก็ยังมีผู้ให้บริการบางรายที่ให้ full context (16k) กับ 80tps และรับปากว่าจะไม่ใช้ข้อมูล ตัวอย่างโฮมเซิร์ฟเวอร์ 9004 นี้ถือว่าจัดได้สวยมาก
  • มองว่าเนื้อหาในบล็อกโพสต์นี้น่าประทับใจ เห็นด้วยกับข้อสรุปว่า “ต้องมี batching” แต่คิดว่าการอภิปรายเรื่อง inference ของโมเดล MoE ควรมีหลายมิติกว่านี้ เหตุผลที่แบตช์ใหญ่สำคัญคือคอขวดของ LLM inference ไม่ใช่การขาดปริมาณการคำนวณ แต่เป็นการโหลดเวททั้งหมดจาก VRAM เมื่อเทียบ TFLOPS กับแบนด์วิดท์หน่วยความจำของ H100 จะคำนวณได้ว่ามีช่องให้ประมวลผลถึง 300 FLOP ต่อ 1 ไบต์ ยิ่งแบตช์ใหญ่ ก็ยิ่งคำนวณได้มากขึ้นต่อพารามิเตอร์ที่โหลดมาแล้ว จึงต้องพยายามทำให้ batch size ใหญ่ที่สุด คำที่ใช้เรียกเรื่องนี้คือ “roofline model” พอโมเดลใหญ่ขึ้นจนทั้งโมเดลใส่ใน VRAM ไม่ได้ ก็จำเป็นต้องกระจายไปหลาย GPU หรือหลายโหนด ซึ่งแม้ใช้ NVLink หรือ Infiniband ก็ยังไม่เร็วเท่าการโหลดจาก VRAM โดยตรงจึงเกิดคอขวด จุดแข็งของ MoE คือ expert parallelism หรือการเก็บ expert คนละตัวไว้บนคนละโหนดแล้วลดการสื่อสารระหว่างโหนดให้เหลือน้อยที่สุด แต่จะทำได้ก็ต่อเมื่อมีโหนดมากพอให้ expert ทั้งหมดอยู่ใน VRAM และยังรองรับโอเวอร์เฮดอย่าง KV cache ได้ สุดท้าย batch size จึงแทบเลี่ยงไม่ได้ที่จะต้องใหญ่ขึ้น และต้องทำแบบนั้น GPU แต่ละตัวจึงจะทำงานได้อย่างมีประสิทธิภาพ
    • มีข้อเสนอให้แจกจ่าย "expert" ต่าง ๆ ไปยังโหนดเดียวกันแบบ round-robin แล้วค่อยจับรวมเป็นแบตช์แบบฉวยโอกาสเฉพาะตอนที่หลายคำขอใช้ expert เดียวกัน เท่ากับใช้คิวแทนแบตช์ ทำให้ latency เพิ่มขึ้น แต่ในสภาพแวดล้อมอย่างเวิร์กโฟลว์วิจัยเชิงลึกก็น่าจะรับได้
    • มีตัวอย่างการใช้งานจริงว่าเมื่อโมเดลใส่ใน GPU เดียวไม่ได้ ก็ยังทำ inference ได้ด้วยการแบ่งตามเลเยอร์ แล้วส่งเวกเตอร์ขนาดเล็กไปยัง GPU ที่รับผิดชอบเลเยอร์ถัดไปเพื่อคำนวณต่อ Cerebras ใช้วิธีนี้กับ Llama 4 Maverick และสร้างโทเคนได้ 2500 ล้านล้านต่อวินาที การส่งเวกเตอร์ผ่าน fabric เร็วมากจนแทบไม่มี idle time
    • จินตนาการถึงความเป็นไปได้ว่าถ้าเอาทุกโหนดและเวทไปวางไว้บนวงจรแอนะล็อกทั้งหมด อาจทำงานได้เร็วขึ้นมาก
    • หนึ่งในเหตุผลที่ลงทุนใน AMD คือทั้งโมเดลสามารถอยู่ในแชสซีเดียวได้ ทำให้ได้ข้อดีแบบ map/reduce และลดต้นทุนอุปกรณ์เครือข่าย หากมีความเห็นแย้งก็อยากได้ insight
  • สรุปหนึ่งบรรทัดสำหรับคนที่อยากประหยัดเวลา: คำตอบคือ batch inference เป็นวิธีเอาพรอมป์ต์จากหลายคนใส่เข้าไปในอินสแตนซ์ของโมเดลพร้อมกัน ซึ่งมีประสิทธิภาพกว่าการสลับเวลาใช้งานอย่างละเอียดเพียงอย่างเดียวมาก ด้วยเหตุนี้แม้จะล็อกค่า temperature และ seed ไว้เท่ากัน คำตอบของบริการก็อาจต่างกันทุกครั้ง เพราะคุณควบคุมไม่ได้ว่าพรอมป์ต์ของคุณจะถูกจับเข้ากลุ่มกับอะไร และยังนึกภาพได้ว่าปรากฏการณ์นี้อาจเป็นช่องทางโจมตีเพื่อขโมยข้อมูลได้ด้วย
    • ข้อดีอย่างหนึ่งของแบตช์คือเวลาจะประเมินเนื้อหาเดิมซ้ำ ๆ เพื่อดูว่ามี "hallucination" จริงไหม ก็สามารถโยนเข้าไปพร้อมกันได้ตาม batch-size สาระสำคัญคือแนวคิดเรื่องแบตช์มีอยู่กับ LLM มาตั้งแต่แรก แต่คนมักจะค่อย ๆ เห็นคุณค่าของมันเมื่อเวลาผ่านไป
    • ฉันเคยเดาแบบง่าย ๆ ว่าผู้ให้บริการน่าจะใช้ batching กับทุกโมเดลตลอดเวลา แต่อยากรู้ว่าจริง ๆ แล้วใช้เฉพาะบางตระกูลโมเดลหรือไม่
    • สงสัยว่าทำไมการถูกจับแบตช์รวมกับพรอมป์ต์อื่นถึงทำให้คำตอบของโมเดลเปลี่ยนได้
    • ถ้าพรอมป์ต์ถูกจับรวมกับของคนอื่นได้จริง ก็เป็นช่องทางโจมตีที่มีประสิทธิภาพมากและน่ากังวล
  • ถ้าจะสรุปให้กระชับ:<br>- โมเดลที่มี sparsity สูง ต้องใช้แบตช์ขนาดใหญ่หรือจำนวนคำขอพร้อมกันมาก เพื่อทำให้การคูณเมทริกซ์หนึ่งครั้งมีความหนาแน่นด้านการคำนวณเพียงพอ<br>- หากจะรองรับแบตช์ใหญ่ระดับนั้น ต้องมี GPU ราว 8~16 ตัวเพื่อให้เวทของโมเดลและ MLA/KV cache อยู่ใน HBM ได้ แต่แค่ GPU 8~16 ตัวกลับยังให้ throughput รวมต่ำ ทำให้ความเร็วตอบสนองต่อผู้ใช้แต่ละคนช้ามาก ถ้าอยากได้ประสบการณ์ใช้งานที่ดีจริง ๆ อาจต้องมีถึงราว 256 GPU
    • ฉันให้บริการ Deepseek อยู่บนสภาพแวดล้อม H100 16 ตัว (2 โหนด) ได้ 50~80 โทเคนต่อวินาทีต่อคำขอ และรักษา throughput ได้เสถียรถึงระดับหลายพันโทเคนโดยรวม เวลาโทเคนแรกก็เสถียร และประสบการณ์โดยรวมเร็วกว่าบริการคลาวด์ไหนก็ตามที่เราใช้งานได้
    • มีคนบอกว่า sparsity สูง = ต้องใช้แบตช์ใหญ่ แต่ฉันยังไม่ค่อยเข้าใจความเชื่อมโยงนั้น และออกแนวประชดว่า sparse matmul ก็เหมือน matmul ที่มีเลข 0 เยอะ ๆ ไม่ใช่หรือ
  • รู้สึกว่าเป็นคำอธิบายที่ยอดเยี่ยมจากมุมมองของ LLM คาดว่าบริษัท LLM ระดับ hyperscale น่าจะวิเคราะห์ trace การคำนวณจริงอย่างละเอียดเพื่อหาคอขวด แล้วจริงจังกับการปรับโหลดงานด้วย load balancer, pipeline architecture, scheduler ฯลฯ แต่ “เงื่อนไขต้องมี batching ก่อน” เพื่อให้ได้ประสิทธิภาพ อาจเสียเปรียบในแอปพลิเคชันที่ต้องการความปลอดภัยสูง เพราะต้นทุนของการแยก query ออกจากกันจะแพงมาก vGPU virtualization ของ nVidia แบ่งเวลาหน่วยความจำ GPU แต่ดูน่าสงสัยว่าต้อง unload/reload ทุกครั้งที่ context switch และไม่มีการ dedupe ส่วน MIG ก็แบ่งหน่วยความจำแบบตายตัวตามผู้ใช้ ถ้าจะปรับใหม่ต้องรีบูต GPU จึงเข้าใจความรู้สึกที่ไม่อยากเอา GPU 96GB มาแบ่งเป็น 4x24GB มีการจินตนาการด้วยว่าถ้าเพิ่มหน่วยความจำชั้นสอง (DRAM) บนบอร์ด GPU อาจย้ายข้อมูลเมทริกซ์หลากหลายชนิดขึ้นมาได้เร็วกว่าผ่าน PCIe โดยใช้ HBM เป็นแคช<br>คู่มือภาคสนามเพื่อเอาตัวรอดใน Software Engineering ก็ได้รับคำชมว่าเขียนอย่างตรงไปตรงมา
  • มีความเห็นว่ายังมีพื้นที่ให้ปรับแต่งซอฟต์แวร์สำหรับ Deepseek อีกมาก ทุกวันนี้การปรับให้เข้าถึงง่ายมักเน้นอยู่แค่สองแบบ คือระบบที่ใช้ GPU เล็กกับ RAM ใหญ่ (ktransformers) หรือระบบที่มี VRAM มหาศาล แต่โครงสร้างแบบ 192GB VRAM + หน่วยความจำปกติที่เหลืออยู่ (DGX station, 2xRTX Pro 6000 เป็นต้น) น่าจะรัน Deepseek 4bit ได้เร็วพอสมควรด้วยพลังของ MoE ถ้าไม่ได้ใช้พรอมป์ต์ภาษาจีนกับ Deepseek expert ส่วนใหญ่จะไม่ถูกเปิดใช้งาน จึงอาจ prune ได้ง่ายขึ้นด้วย ในอนาคตทิศทางของระบบสาย enthusiast ก็น่าจะเข้ากับการปรับแต่งเชิงซอฟต์แวร์แนวนี้ ใน Reddit ยังมีตัวอย่างเครื่อง 16x3090 (Pcie 3.0 x4) ที่รัน llama.cpp ได้ราว 7 โทเคนต่อวินาที และแม้แต่ 3090 ตัวเดียวก็สามารถสแกน VRAM ทั้งหมดได้ 39 ครั้งต่อวินาที จึงน่าจะมีคอขวดด้านประสิทธิภาพอื่นอยู่
    • ระบบ 16x3090 กินไฟถึง 5KW ขนาดนี้ถ้าคิดค่าไฟแล้วใช้ API ยังถูกกว่า และเมื่อ expert จำนวนมากใน Deepseek ไม่ถูกเปิดใช้งานหากไม่ได้ใช้พรอมป์ต์ภาษาจีน ก็ชวนให้นึกถึงการทำโมเดลให้เบาลงและ route โทเคนไปยัง expert ที่ใกล้ที่สุดมากขึ้น
    • MI300x หนึ่งตัวให้ VRAM ได้ 192GB
  • ฉันไม่ใช่นักวิจัย ML หรือวิศวกร จึงอยากให้เผื่อใจไว้ก่อน แต่ Deepseek V3/R1 ใหญ่มากเมื่อเทียบกับโมเดลโลคัลยุคก่อน จึงเป็นเรื่องจริงที่การรันแบบโลคัลมีต้นทุนสูง แม้จำนวนพารามิเตอร์ที่ active จะน้อยกว่าขนาดรวม แต่สิ่งนี้ลดแค่ความต้องการคำนวณ ไม่ได้ลดความต้องการหน่วยความจำ ดังนั้นถ้าไม่มี GPU ใหญ่มากก็แทบใช้งานจริงไม่ได้เลย และก็เทียบตรงกับโมเดล frontier หลัก ๆ ที่เป็น proprietary ไม่ได้ด้วย เพราะไม่ได้เปิดเผยข้อมูลอย่างขนาดโมเดลไว้ครบถ้วน ไม่มีเหตุผลชัดเจนด้วยว่าโมเดลเหล่านั้นจะรันในเครื่องได้ถูกกว่า ตรงกันข้าม MoE อาจเป็น trade-off ที่เหมาะกับสภาพแวดล้อมโลคัลหรือผู้ใช้เดี่ยวมากกว่า เพราะความไม่มีประสิทธิภาพจาก batching ไม่ได้รุนแรงเท่าในระบบหลายผู้ใช้ เมื่อเพิ่มแบตช์ เวลารอของแต่ละโทเคนอาจขึ้นไปถึง 200ms แต่ feed-forward computation (GEMM) จะใหญ่ขึ้นและคำนวณได้มีประสิทธิภาพกว่า สงสัยว่าเมื่อแบตช์ใหญ่ขึ้น เมทริกซ์เองใหญ่ขึ้นด้วยหรือไม่ โมเดลในหัวของฉันคือ เป้าหมายของแบตช์ไม่ใช่ “เพิ่มขนาดเมทริกซ์อินพุต” แต่คือ “ย้ายคอขวดจากแบนด์วิดท์หน่วยความจำไปเป็นข้อจำกัดด้านการคำนวณ” เวทถูกแบ่งเป็นชิ้นตามเลเยอร์แล้วโหลดจาก HBM → SRAM อยู่แล้ว จากนั้นคูณเมทริกซ์ทีละชิ้นและค่อยรวมผลตอนท้าย ข้อดีของ batching คือใช้เวทชุดเดิมทำหลายการคำนวณพร้อมกัน จึงรีด FLOPS ได้มีประสิทธิภาพสูงสุด ส่วนเรื่องที่ OpenAI, Anthropic ฯลฯ ตอบเร็วมากจริงหรือไม่ ฉันมองว่าบล็อกโพสต์นี้ยังให้หลักฐานอ่อน เพราะไม่มีตัวเลข time to first token ของแต่ละราย
    • ฉันคือผู้เขียนต้นฉบับ ไม่ใช่นักวิจัย ML แต่เป็นวิศวกรที่สนใจมาก ในสถานการณ์โลคัลแบบผู้ใช้เดี่ยวของ MoE ประเด็นคือไม่มีข้อได้เปรียบจากการ batch หลายผู้ใช้ จึงทำให้ throughput ต่อ GPU ตกลงอย่างมาก เว้นแต่จะมีคำขอ inference แบบขนานจำนวนมหาศาล เมื่อเพิ่มขนาดเมทริกซ์อินพุตผ่าน batching ถ้า batch เป็น 1 การคำนวณคือเมทริกซ์ขนาด 1xdim แต่ถ้า batch เพิ่มก็กลายเป็น batch-size x dim ทำให้อัตราการใช้งาน GPU พุ่งขึ้น หรือก็คือเปลี่ยนไปติดคอขวดด้านการคำนวณ สุดท้ายถ้าใช้งานจริงเยอะพอ ก็จะรู้สึกได้ว่า Deepseek ช้ากว่าโมเดลอื่นจริง
  • mixture of experts ต้องการแบตช์สูง แต่ถ้าใช้ Apple Silicon ก็พอใช้งานได้แม้ batch size จะเป็น 1 เพราะมี unified memory จึงรันโมเดลใหญ่แบบโลคัลได้ แม้แบนด์วิดท์และ FLOPS ต่ำกว่าจึงทำงานค่อนข้างช้า จุดเด่นของ MoE คือจำนวนพารามิเตอร์ที่ต้องประมวลผลในแต่ละครั้งน้อยกว่า จึงมีภาระการคำนวณต่ำกว่า มีประสบการณ์จากหลายคนที่รัน Deepseek บน Mac แบบ single-batch inference ได้ในความเร็วที่ใช้งานได้จริง แน่นอนว่าถ้าจะใส่หน่วยความจำให้พอก็ยังมีต้นทุนซื้อที่สูงอยู่ดี แต่ถ้าในอนาคตมีเครื่องแบบ Mac หรือโครงสร้างคล้ายกันออกมาเพิ่ม ก็ถือว่าเข้ากันกับโมเดล MoE อย่างมาก ตรงกันข้าม การรัน dense model บน Mac ที่อัปเกรด RAM เยอะ ๆ นั้นทรมานกว่ามาก
  • หลังคุยกับเพื่อนร่วมงาน เราสรุปกันว่าเวลานำ LLM มาใช้ช่วยเขียนโปรแกรม โมเดลกลับพัฒนาไปในทิศทางที่ห่างจากการปรับแต่งที่เป็นแก่นแท้มากขึ้นเรื่อย ๆ ด้วยข้อจำกัดภายใน ฉันจึงแทบทุกงานต้องเปรียบเทียบระหว่างโมเดลโลคัล 4~30B กับ GPT หลายซีรีส์ โดยเฉพาะ GPT-4o ที่โดยเฉลี่ยให้ผลลัพธ์ดีมาก แต่ก็มีแนวโน้ม “แต่งบางส่วนของคำตอบขึ้นมา” จนต้องเสียเวลาตรวจสอบและวนซ้ำมากพอสมควร สุดท้ายจึงรู้สึกว่า “ความต่างเมื่อเทียบกับโมเดลโลคัลพารามิเตอร์ต่ำ อาจไม่ได้มากอย่างที่คิดเมื่อเทียบกับแรงที่ต้องลง” ปัญหาคือทั้งสองฝั่งช้ามากจนทำงานวนซ้ำอย่างรวดเร็วไม่ได้ ฉันกลับชอบโมเดลคอนเท็กซ์ใหญ่ที่ถึงคุณภาพจะต่ำกว่า แต่ตอบไวแบบแทบจะทันทีมากกว่า ความเร็วในการวนซ้ำที่รู้สึกได้สำคัญไม่แพ้ตัวเลขประเมินคุณภาพที่ดีขึ้น
  • ไม่เห็นด้วยกับคำกล่าวที่ว่า “ช้าและแพง” มีตัวอย่างว่าแม้เป็นเวิร์กสเตชันเก่าที่ใช้หน่วยความจำ DDR4 ถ้ารันผ่าน llama.cpp ก็ยังดึงได้ 3 โทเคนต่อวินาทีบนระบบราคาประมาณ 1,000 ดอลลาร์
    • มีคนทักว่าคุณอาจกำลังสับสนระหว่างโมเดล Deepseek ตัวจริงกับเวอร์ชัน distill เพราะถ้าไม่มี RAM 192GB ขึ้นไปก็รันโมเดลจริงไม่ได้