เปิดเผยกฎเหล็กทางฟิสิกส์ของ AI ในการอนุมานและการฝึกฝน: จากขนาดแบตช์ไปจนถึงโครงสร้าง MoE ปรับเปลี่ยนความเข้าใจของคุณเกี่ยวกับต้นทุนของโมเดลขนาดใหญ่

๑. ขนาดแบตช์: กลไกหลักของต้นทุนและความหน่วงในการอนุมาน AI

เมื่อเราพูดถึง AI เรามักจะมุ่งเน้นไปที่ความสามารถของโมเดล ขนาดพารามิเตอร์ และสถานการณ์การใช้งาน แต่แทบจะไม่เคยตั้งคำถามถึงข้อจำกัดทางกายภาพพื้นฐานที่กำหนดธรรมชาติของ AI เลย:

• ทำไมโหมดเร็วของ Claude ถึงแพงกว่า 6 เท่า แต่เร็วกว่าเพียง 2.5 เท่า?
• ทำไมหลังจากเปิดตัว GPT-4 การเติบโตของขนาดโมเดลถึงหยุดชะงัก?
• ทำไมราคา API สำหรับบริบทยาวถึงเพิ่มขึ้นเป็นสองเท่า?
• ทำไม Ilya Sutskever ถึงพูดตรงๆ ว่า “การทำ Pipeline Parallelism ไม่ฉลาด”?

เพื่อตอบคำถามเหล่านี้อย่างลึกซึ้ง เราได้เชิญ Reiner Pope อดีตสถาปนิก TPU ของ Google และปัจจุบันเป็น CEO ของ MatX สตาร์ทอัพด้านชิป AI เขาได้บรรยายบนกระดานดำนานกว่าสองชั่วโมง เพื่อแยกแยะแก่นแท้ของโมเดล Transformer ในด้านการคำนวณ หน่วยความจำ และการสื่อสารจากหลักการพื้นฐาน การบรรยายนี้ไม่มีสไลด์สวยงาม มีเพียงสูตร แผนภาพ และการพิสูจน์ที่เข้มข้น แต่เผยให้เห็นความลับทางธุรกิจและเทคโนโลยีที่สำคัญที่สุดของอุตสาหกรรม AI

• Reiner Pope – The math behind how LLMs are trained and served
• http://dwarkesh.com/p/reiner-pope
• 8000 คำ อ่าน 40 นาที พอดแคสต์ 26 นาที

จากการวิเคราะห์ของ Reiner คุณจะพบว่า: การพัฒนา AI ไม่ได้ถูกขับเคลื่อนด้วยอัลกอริทึมและข้อมูลเท่านั้น แต่ยังถูกจำกัดด้วยกฎเหล็กของโลกทางกายภาพอีกด้วย จากแบนด์วิดท์หน่วยความจำของ GPU ไปจนถึงความหนาแน่นของสายเคเบิลในแร็ค จากเศรษฐศาสตร์ของขนาดแบตช์ไปจนถึงวิวัฒนาการมาบรรจบกับวิทยาการเข้ารหัสลับ ปัจจัยที่ดูเหมือนไม่เกี่ยวข้องเหล่านี้ร่วมกันหล่อหลอมโฉมหน้าของ AI ในปัจจุบัน และกำหนดทิศทางในอนาคตของมัน

สารบัญ

• ๑. ขนาดแบตช์: กลไกหลักของต้นทุนและความหน่วงในการอนุมาน AI
  • 1.1 ทำไมถึงมี “โหมดเร็ว” และ “โหมดช้า”?
  • 1.2 โมเดลเส้นหลังคา: การต่อสู้ชั่วนิรันดร์ระหว่างการคำนวณและหน่วยความจำ
  • 1.3 ความลับของเส้นต้นทุน: ยิ่งแบตช์ใหญ่ยิ่งถูก
  • 1.4 การหาขนาดแบตช์ที่เหมาะสมที่สุด: กฎความเบาบาง 300 เท่า
• ๒. เค้าโครงทางกายภาพของโมเดล MoE: หนึ่งแร็คคือหนึ่งเลเยอร์ผู้เชี่ยวชาญ
  • 2.1 Expert Parallelism: การกระจายผู้เชี่ยวชาญต่างกันไปยัง GPU ต่างกัน
  • 2.2 การสื่อสารแบบ All-to-All: จุดหวานและคอขวดของ MoE
  • 2.3 ทำไมหนึ่งแร็คถึงเป็นขอบเขตตามธรรมชาติของ MoE?
  • 2.4 ความหนาแน่นของสายเคเบิล: ขนาดของ AI ที่ถูกจำกัดโดยโลกทางกายภาพ
• ๓. Pipeline Parallelism: ทำไม Ilya ถึงบอกว่า “มันไม่ฉลาด”?
  • 3.1 หลักการพื้นฐานของ Pipeline Parallelism: การวางเลเยอร์ไว้ในแร็คต่างกัน
  • 3.2 การฝึก vs การอนุมาน: ชะตากรรมที่แตกต่างของ Pipeline
  • 3.3 กับดักร้ายแรง: KV Cache ไม่สามารถถูก分摊โดย Pipeline
  • 3.4 ความจริงของขนาด: แบนด์วิดท์สำคัญกว่าความจุ
• ๔. การพลิกโฉมของ RL: โมเดลอาจถูกฝึกมากเกินไป 100 เท่า
  • 4.1 ข้อจำกัดของกฎการปรับขนาด Chinchilla
  • 4.2 การลดต้นทุนรวม: การแบ่งส่วนของการฝึก, RL และการอนุมาน
  • 4.3 การ推导จากหลักการพื้นฐาน: ที่มาของการฝึกมากเกินไป 100 เท่า
  • 4.4 สิ่งนี้หมายความว่าอย่างไรต่ออนาคตของ AI?
• ๕. การย้อนกลับจากราคา API: ต้นทุนที่แท้จริงของบริบทยาว
  • 5.1 ความลับที่รั่วไหลจากการกำหนดราคา Gemini: 200K คือจุดเปลี่ยนต้นทุน
  • 5.2 Prefill vs Decode: ทำไม Output ถึงแพงกว่า Input 5 เท่า?
  • 5.3 เศรษฐศาสตร์ของ Context Cache: HBM, DDR หรือ ฮาร์ดดิสก์?
  • 5.4 อุปสรรคที่แท้จริงของบริบทระดับล้าน: กำแพงหน่วยความจำ
• ๖. วิวัฒนาการมาบรรจบ: ความคล้ายคลึงที่น่าทึ่งระหว่างโครงข่ายประสาทเทียมและวิทยาการเข้ารหัสลับ
  • 6.1 เป้าหมายหลักเดียวกัน: การผสมผสานข้อมูลอย่างสมบูรณ์
  • 6.2 รูปแบบสถาปัตยกรรมเดียวกัน: การซ้อนซ้ำของเชิงเส้น+ไม่เชิงเส้น
  • 6.3 เป้าหมายการเพิ่มประสิทธิภาพที่ตรงกันข้าม: การสกัดโครงสร้าง vs การสุ่ม
  • 6.4 แรงบันดาลใจข้ามสาขา: จากรหัส Feistel สู่โครงข่ายประสาทแบบย้อนกลับได้
• บทสรุป
• 📌 ประเด็นสำคัญ

1.1 ทำไมถึงมี “โหมดเร็ว” และ “โหมดช้า”?

ผู้ให้บริการ AI รายใหญ่ทุกรายมีตัวเลือกบริการที่ความเร็วต่างกัน:
* Fast Mode ของ Claude แพงกว่าโหมดปกติ 6 เท่า แต่เร็วกว่า 2.5 เท่า;
* Turbo Mode ของ Cursor มีราคาสูงกว่าและตอบสนองเร็วกว่า

หลายคนคิดว่านี่เป็นเพียงกลยุทธ์การกำหนดราคาของผู้ให้บริการ แต่ Reiner ชี้ให้เห็นว่าเบื้องหลังนี้คือกฎทางกายภาพพื้นฐานที่สุดของการอนุมาน AI: ขนาดแบตช์กำหนดการแลกเปลี่ยนระหว่างต้นทุนและความหน่วง

“ถ้าคุณไม่ทำการประมวลผลคำขอของผู้ใช้เป็นแบตช์ ต้นทุนจะสูงกว่าการทำเป็นแบตช์ถึง 1,000 เท่า” Reiner เขียนสูตรแรกบนกระดานดำ “นี่คือสาเหตุที่คุณสามารถจ่ายเงินเพื่อซื้อความเร็ว หรือใช้เวลาเพื่อประหยัดเงิน”

เพื่ออธิบายสิ่งนี้ Reiner ได้แนะนำเครื่องมือวิเคราะห์หลักสองอย่าง: โมเดลเส้นหลังคา และสององค์ประกอบเวลาของการอนุมาน Transformer ได้แก่ เวลาการทำงานของน้ำหนัก และเวลาการทำงานของบริบท

1.2 โมเดลเส้นหลังคา: การต่อสู้ชั่วนิรันดร์ระหว่างการคำนวณและหน่วยความจำ

โมเดลเส้นหลังคาเป็นวิธีการคลาสสิกในการวิเคราะห์ประสิทธิภาพของระบบคอมพิวเตอร์ โดยพิจารณาทรัพยากรหลักสองอย่าง: ความสามารถในการคำนวณ (FLOPS) และแบนด์วิดท์หน่วยความจำ (จำนวนไบต์ที่อ่านจากหน่วยความจำต่อวินาที) ประสิทธิภาพของโปรแกรมใดๆ จะไม่เกินคอขวดของทรัพยากรทั้งสองนี้

สำหรับการอนุมาน Transformer เวลาส่วนใหญ่ประกอบด้วยสองส่วน:

• เวลาในการคำนวณ: เวลาในการคูณเมทริกซ์น้ำหนัก ซึ่งเป็นสัดส่วนกับขนาดแบตช์
• เวลาหน่วยความจำ: เวลาในการอ่านน้ำหนักและ KV Cache จากหน่วยความจำ ซึ่งประกอบด้วยเวลาอ่านน้ำหนักคงที่และเวลาอ่าน KV Cache ที่เป็นสัดส่วนกับขนาดแบตช์

เวลาในการคำนวณ = (ขนาดแบตช์ × จำนวนพารามิเตอร์ที่ใช้งาน) / ปริมาณงานคำนวณของฮาร์ดแวร์
เวลาหน่วยความจำ = (จำนวนพารามิเตอร์ทั้งหมด / แบนด์วิดท์หน่วยความจำ) + (ขนาดแบตช์ × ความยาวบริบท × จำนวนไบต์ต่อ token / แบนด์วิดท์หน่วยความจำ)
เวลาทั้งหมด = max(เวลาในการคำนวณ, เวลาหน่วยความจำ)

Reiner อธิบายแนวคิดของ KV Cache โดยเฉพาะ: ในการอนุมานแบบ Autoregressive ทุกครั้งที่โมเดลสร้าง token ใหม่ จะต้อง关注การแสดงผลภายในของ token ก่อนหน้าทั้งหมด เพื่อหลีกเลี่ยงการคำนวณซ้ำ การแสดงผลเหล่านี้จะถูกแคชไว้ เรียกว่า KV Cache ขนาดของ KV Cache เป็นสัดส่วนกับขนาดแบตช์และความยาวบริบท และเป็นค่าใช้จ่ายหน่วยความจำหลักในการอนุมานบริบทยาว

1.3 ความลับของเส้นต้นทุน: ยิ่งแบตช์ใหญ่ยิ่งถูก

ถ้าเราหารเวลาด้วยขนาดแบตช์ จะได้ต้นทุนต่อ token และจะเห็นเส้นโค้งที่น่าสนใจมาก:
* เมื่อแบตช์มีขนาดเล็ก เวลาอ่านน้ำหนักจะครอบงำ ต้นทุนต่อ token สูงมาก แทบจะแปรผกผันกับขนาดแบตช์
* เมื่อแบตช์มีขนาดใหญ่ขึ้นถึงระดับหนึ่ง เวลาอ่านน้ำหนักจะถูก分摊 เวลาอ่าน KV Cache และเวลาในการคำนวณเริ่มครอบงำ
* เมื่อแบตช์มีขนาดใหญ่พอ เวลาในการคำนวณจะกลายเป็นคอขวด ต้นทุนต่อ token จะคงที่ ถึงค่าต่ำสุดทางทฤษฎี

“นี่คือสาเหตุที่การทำแบตช์มีความสำคัญมาก” Reiner ชี้ไปที่จุดต่ำสุดของเส้นโค้งอธิบาย “เมื่อขนาดแบตช์เป็น 1 แต่ละ token จะต้องรับภาระค่าใช้จ่ายในการอ่านน้ำหนักทั้งหมดของโมเดล แต่เมื่อขนาดแบตช์เพิ่มขึ้นเป็น 2000 ค่าใช้จ่ายนี้จะถูก分摊โดย token 2000 ตัว จนแทบจะ忽略ไม่ได้”

นี่ยังเผยให้เห็นว่าเหตุใด “โหมดช้า” จึงลดราคาลงได้ยาก: KV Cache เป็นทรัพยากรเฉพาะของผู้ใช้แต่ละคน ไม่สามารถ分摊ต้นทุนผ่านการดำเนินการแบบแบตช์ได้เหมือนน้ำหนักโมเดล แม้ว่าผู้ใช้จะยอมรับเวลารอที่นานขึ้น ค่าใช้จ่ายของ KV Cache ก็ยากที่จะลดลงอย่างมีนัยสำคัญ

1.4 การหาขนาดแบตช์ที่เหมาะสมที่สุด: กฎความเบาบาง 300 เท่า

แล้วขนาดแบตช์เท่าไหร่ถึงจะได้ประสิทธิภาพสูงสุด? Reiner ให้สูตรที่简洁อย่างน่าทึ่ง:

ขนาดแบตช์ที่เหมาะสมที่สุด = ความเบาบาง × 300

โดยที่ ความเบาบาง หมายถึงอัตราส่วนของจำนวนพารามิเตอร์ทั้งหมดของโมเดลต่อจำนวนพารามิเตอร์ที่ใช้งาน ยกตัวอย่าง DeepSeek V3 มีพารามิเตอร์ทั้งหมด 700 พันล้าน พารามิเตอร์ที่ใช้งาน 37 พันล้าน ความเบาบางประมาณ 19 ดังนั้นขนาดแบตช์ที่เหมาะสมที่สุดคือประมาณ 5700

“เลข 300 นี้เป็นค่าคงที่ของฮาร์ดแวร์” Reiner อธิบาย “มันแสดงถึงอัตราส่วนของปริมาณงานคำนวณของ GPU ต่อแบนด์วิดท์หน่วยความจำ หน่วยเป็น FLOPs ต่อไบต์ จาก A100 ถึง H100 ไปจนถึง B100 อัตราส่วนนี้คงที่ประมาณ 300 เสมอ ซึ่งคงที่มาก”

นั่นหมายความว่า สำหรับโมเดลใดๆ ฮาร์ดแวร์ใดๆ ขนาดแบตช์ที่เหมาะสมที่สุดขึ้นอยู่กับความเบาบางเท่านั้น ไม่เกี่ยวข้องกับขนาดของโมเดลเอง นี่เป็นข้อสรุปที่มีอิทธิพลอย่างมาก ซึ่งอธิบายว่าแม้แต่โมเดลที่ใหญ่ที่สุด ขนาดแบตช์ที่เหมาะสมที่สุดก็ยังคงอยู่ในระดับหลักพันเท่านั้น

ในการ部署จริง ผู้ให้บริการมักจะเลือกขนาดแบตช์ที่ใหญ่กว่าค่าที่เหมาะสมที่สุด 2 ถึง 3 เท่า เพื่อสำรองไว้ ซึ่งหมายความว่า โมเดล前沿ทั่วไปจะประมวลผลหนึ่งแบตช์ทุกๆ ประมาณ 20 มิลลิวินาที แต่ละแบตช์มีประมาณ 2000 ซีเควนซ์

“คุณสามารถจินตนาการว่านี่เป็นรถไฟที่ออกทุกๆ 20 นาที” Reiner อุปมา “ไม่ว่าตู้จะเต็มหรือไม่ รถไฟก็จะออกตรงเวลา ถ้าคำขอของคุณมาถึงพอดีหลังจากรถไฟออกไป คุณก็ต้องรอขบวนถัดไป นี่คือที่มาของความหน่วงในการ排队”

unsetunset๒. เค้าโครงทางกายภาพของโมเดล MoE: หนึ่งแร็คคือหนึ่งเลเยอร์ผู้เชี่ยวชาญunsetunset

2.1 Expert Parallelism: การกระจายผู้เชี่ยวชาญต่างกันไปยัง GPU ต่างกัน

ด้วยการเพิ่มขึ้นของโมเดล Mixture of Experts (MoE) การ部署อย่างมีประสิทธิภาพบนคลัสเตอร์ GPU จึงกลายเป็นปัญหาสำคัญ โมเดล MoE ประกอบด้วยผู้เชี่ยวชาญหลายคน แต่ละ token จะถูกส่งต่อไปยังผู้เชี่ยวชาญเพียงไม่กี่คนเท่านั้นเพื่อประมวลผล

Reiner วาดโครงสร้างเลเยอร์ MoE ทั่วไปบนกระดานดำ: token อินพุตผ่านเราเตอร์ ถูกกระจายไปยังผู้เชี่ยวชาญต่างๆ แต่ละคนเป็น MLP อิสระ หลังจากประมวลผลเสร็จแล้วจึงรวบรวมผลลัพธ์

“วิธีที่ดีที่สุดในการ部署 MoE คือ Expert Parallelism” Reiner ชี้ “นั่นคือการกระจายผู้เชี่ยวชาญต่างๆ ไปยัง GPU ต่างๆ”

ตัวอย่างเช่น DeepSeek V3 มีผู้เชี่ยวชาญ 256 คน หาก部署บนแร็ค Blackwell ที่มี 72 GPU เราสามารถใช้ 64 GPU โดยวางผู้เชี่ยวชาญ 4 คนต่อ GPU 1 ตัว ดังนั้นเมื่อ token ถูกส่งไปยังผู้เชี่ยวชาญคนใด ก็只需สื่อสารกับ GPU ที่เกี่ยวข้อง

2.2 การสื่อสารแบบ All-to-All: จุดหวานและคอขวดของ MoE

รูปแบบการสื่อสารของ Expert Parallelism คือการสื่อสารแบบ All-to-All: GPU แต่ละตัวอาจส่งหรือรับ token ไปยัง GPU อื่นๆ ในคลัสเตอร์

“นี่เป็นรูปแบบการสื่อสารที่พิเศษมาก” Reiner เน้นย้ำ “มันต้องการให้ GPU ทั้งหมดมีความสามารถในการเชื่อมต่อที่รวดเร็วและเท่าเทียมกัน”

โชคดีที่การออกแบบแร็ค GPU สมัยใหม่ตอบสนองความต้องการนี้ได้พอดี ในแร็ค Blackwell ของ Nvidia GPU ทั้ง 72 ตัวเชื่อมต่อกันผ่าน NVSwitch การสื่อสารระหว่าง GPU สองตัวใดๆ ใช้เพียงสอง hops และมีแบนด์วิดท์เท่ากัน

“แร็ค Blackwell หนึ่งตัวถูกออกแบบมาสำหรับ MoE โดยเฉพาะ” Reiner กล่าว “แบนด์วิดท์การสื่อสารแบบ All-to-All ของมัน匹配ความต้องการของ MoE ได้อย่างสมบูรณ์”

อย่างไรก็ตาม เมื่อเราพยายามขยายเลเยอร์ MoE ไปยังหลายแร็ค ปัญหาก็ตามมา แบนด์วิดท์การสื่อสารระหว่างแร็คมักจะต่ำกว่าภายในแร็คประมาณ 8 เท่า หากเลเยอร์ MoE กระจายอยู่บนสองแร็ค โดยเฉลี่ยแล้วครึ่งหนึ่งของ token จะต้องสื่อสารข้ามแร็ค ซึ่งจะกลายเป็นคอขวดด้านประสิทธิภาพที่ร้ายแรง

2.3 ทำไมหนึ่งแร็คถึงเป็นขอบเขตตามธรรมชาติของ MoE?

“นี่คือสาเหตุที่หนึ่งแร็คเป็นขอบเขตตามธรรมชาติของเลเยอร์ MoE” Reiner สรุป “คุณแทบจะไม่เห็นเลเยอร์ MoE ใดๆ ถูก部署บนหลายแร็ค”

ข้อสรุปนี้มีผลกระทบอย่างลึกซึ้งต่อขนาดของโมเดล AI จำนวนพารามิเตอร์ทั้งหมดของเลเยอร์ MoE ต้องไม่เกินความจุหน่วยความจำของแร็คเดียว สำหรับแร็ค Blackwell ความจุนี้ประมาณ 20TB ซึ่งสอดคล้องกับพารามิเตอร์ประมาณ 10 ล้านล้าน (สมมติว่าใช้ความแม่นยำ FP4)

นี่ยังอธิบายว่าเหตุใดโมเดล Gemini ของ Google จึงเป็นผู้นำในช่วงแรก: คลัสเตอร์ TPU ของ Google มี scale-up domain (จำนวนชิปภายในโดเมนการสื่อสารเดียว) ที่มีขนาดใหญ่มากตั้งแต่แรกเริ่ม จึงสามารถรองรับเลเยอร์ MoE ที่ใหญ่ขึ้นได้

2.4 ความหนาแน่นของสายเคเบิล: ข้อจำกัดทางกายภาพต่อขนาดของ AI

แล้วทำไมเราไม่ใส่ GPU มากขึ้นในแร็คเดียว หรือสร้าง scale-up domain ที่ใหญ่ขึ้นล่ะ? Reiner ให้คำตอบที่น่าประหลาดใจ: พื้นที่ทางกายภาพและความหนาแน่นของสายเคเบิล

“แร็คสมัยใหม่ถูกผลักดันไปถึงขีดจำกัดทางกายภาพแล้ว” Reiner อธิบาย “คุณต้องใส่ GPU, แหล่งจ่ายไฟ, ระบบทำความเย็น และสายเคเบิลให้มากที่สุดเท่าที่จะทำได้ในพื้นที่จำกัด และความหนาแน่นของสายเคเบิลเป็นหนึ่งในคอขวดที่ใหญ่ที่สุด”

GPU แต่ละตัวต้องการสายเคเบิลความเร็วสูงจำนวนมากเพื่อเชื่อมต่อกับสวิตช์ เมื่อจำนวน GPU เพิ่มขึ้น จำนวนสายเคเบิลจะเพิ่มขึ้นแบบยกกำลังสอง สายเคเบิลเหล่านี้ไม่เพียงแต่กินพื้นที่ แต่ยังมีข้อกำหนดรัศมีการโค้งงอขั้นต่ำ ไม่สามารถดัดงอได้ตามอำเภอใจ

“การพัฒนาจาก Hopper ที่มี 8 GPU ไปเป็น Blackwell ที่มี 72 GPU ส่วนใหญ่เป็นการเปลี่ยนแปลงรูปแบบผลิตภัณฑ์ จากแบบถาดเป็นแบบแร็ค” Reiner กล่าว “และสถาปัตยกรรม Rubin ที่กำลังจะมาถึง จะขยาย scale-up domain ไปเป็น GPU มากกว่า 500 ตัว ซึ่งต้องมีความก้าวหน้าครั้งสำคัญในการออกแบบแร็ค เพื่อแก้ปัญหาความหนาแน่นของสายเคเบิล การจ่ายไฟ และการทำความเย็น”

unsetunset๓. Pipeline Parallelism: ทำไม Ilya ถึงบอกว่า “มันไม่ฉลาด”?unsetunset

3.1 หลักการพื้นฐานของ Pipeline Parallelism: การวางเลเยอร์ไว้ในแร็คต่างกัน

เนื่องจากเลเยอร์ MoE ไม่สามารถข้ามแร็คได้ แล้วเราจะ部署โมเดลที่ใหญ่กว่าหน่วยความจำของแร็คเดียวได้อย่างไร? คำตอบคือ Pipeline Parallelism

แนวคิดของ Pipeline Parallelism ตรงไปตรงมามาก: วางเลเยอร์ต่างๆ ของโมเดลไว้บนแร็คต่างๆ ตัวอย่างเช่น โมเดลที่มี 100 เลเยอร์ สามารถวาง 25 เลเยอร์แรกในแร็คแรก 25 เลเยอร์ถัดไปในแร็คที่สอง และต่อไปเรื่อยๆ

เมื่อคำขอเข้าสู่ระบบ มันจะประมวลผล 25 เลเยอร์แรกในแร็คแรกก่อน จากนั้นส่งผลลัพธ์ไปยังแร็คที่สองเพื่อประมวลผล 25 เลเยอร์ถัดไป และทำเช่นนี้ไปเรื่อยๆ จนถึงแร็คสุดท้ายที่สร้างเอาต์พุตสุดท้าย

“นี่ดูตรงไปตรงมามาก” Reiner กล่าว “แต่มันมีข้อบกพร่องร้ายแรง: ฟองอากาศใน Pipeline”

3.2 การฝึก vs การอนุมาน: ชะตากรรมที่แตกต่างของ Pipeline

ในการฝึก Pipeline Parallelism จะสร้างฟองอากาศที่ชัดเจน เพื่อหลีกเลี่ยงฟองอากาศ คุณต้องแบ่งแบตช์ออกเป็น micro-batches หลายๆ ตัว เพื่อให้ Pipeline ทำงานเต็มกำลัง แต่สิ่งนี้จะเพิ่มความซับซ้อนในการฝึก และอาจส่งผลต่อความเร็วในการลู่เข้า

อย่างไรก็ตาม ในสถานการณ์การอนุมาน ฟองอากาศใน Pipeline แทบจะไม่มีอยู่ “ในการอนุมาน คุณสามารถส่งคำขออย่างต่อเนื่อง” Reiner อธิบาย “ตราบใดที่มีคำขอเพียงพอ Pipeline ก็จะทำงานเต็มกำลังตลอดเวลา โดยไม่มีฟองอากาศ”

ที่สำคัญกว่านั้น Pipeline Parallelism แทบไม่มีผลกระทบต่อความหน่วงและต้นทุนในการอนุมาน “ถ้าคุณวางโมเดล 100 เลเยอร์ในแร็คเดียว หรือกระจายไปยัง 4 แร็ค แต่ละแร็คมี 25 เลเยอร์ ความหน่วงรวมจะเท่ากัน” Reiner กล่าว “เพราะคุณแค่ย้ายงานจากชิปหนึ่งไปยังอีกชิปหนึ่ง ปริมาณงานทั้งหมดไม่ได้เปลี่ยนแปลง”

3.3 กับดักร้ายแรง: KV Cache ไม่สามารถถูก分摊โดย Pipeline

ถ้า Pipeline Parallelism ดีขนาดนี้ ทำไม Ilya Sutskever ถึงบอกว่า “การทำ Pipeline Parallelism ไม่ฉลาด”? Reiner เผยให้เห็นประเด็นสำคัญ: Pipeline Parallelism ไม่สามารถ分摊ต้นทุนหน่วยความจำของ KV Cache ได้

ลองคำนวณง่ายๆ: สมมติว่าเรามี Pipeline 4 สเตจ แต่ละสเตจมี P GPU เพื่อให้ Pipeline ทำงานเต็มกำลัง เราต้องมี micro-batches 4 ตัวทำงานพร้อมกัน

นั่นหมายความว่า จำนวนซีเควนซ์ที่อยู่ในระบบพร้อมกันคือ 4 เท่าของสเตจเดียว และ KV Cache เป็นเอกสิทธิ์ของแต่ละซีเควนซ์ ดังนั้นความต้องการหน่วยความจำ KV Cache ทั้งหมดจึงกลายเป็น 4 เท่าเช่นกัน

“เมื่อคุณเพิ่มจำนวนสเตจ Pipeline ความต้องการหน่วยความจำสำหรับน้ำหนักจะลดลงเป็นเส้นตรง แต่ความต้องการหน่วยความจำสำหรับ KV Cache ยังคงเท่าเดิม” Reiner เขียนสูตรบนกระดานดำ “ในที่สุด KV Cache จะกลายเป็นค่าใช้จ่ายหน่วยความจำที่ครอบงำ การประหยัดหน่วยความจำน้ำหนักจาก Pipeline Parallelism จะกลายเป็นเรื่องเล็กน้อย”

นี่คือแก่นของมุมมองของ Ilya: ในปัจจุบันที่ KV Cache ครอบงำค่าใช้จ่ายหน่วยความจำ ผลประโยชน์จาก Pipeline Parallelism มีจำกัดมาก แต่กลับนำมาซึ่งความซับซ้อนของระบบและค่าใช้จ่ายด้านความหน่วง (ความหน่วงของการสื่อสารข้ามแร็ค) อย่างมหาศาล

3.4 ความจริงของขนาด: แบนด์วิดท์สำคัญกว่าความจุ

หลายคนเข้าใจผิดว่าการขยาย scale-up domain มีเป้าหมายเพื่อเพิ่มความจุหน่วยความจำ “Reiner ชี้ให้เห็นว่า ข้อได้เปรียบหลักที่แท้จริงคือการเพิ่มแบนด์วิดท์หน่วยความจำ”

เมื่อโมเดลถูก部署ใน scale-up domain ที่ใหญ่ขึ้น คุณสามารถอ่านน้ำหนักจาก GPU มากขึ้นพร้อมกัน ลดเวลาในการโหลดน้ำหนักลงอย่างมาก ตัวอย่างเช่น แร็ค Blackwell ที่มี 72 GPU มีแบนด์วิดท์หน่วยความจำรวมเป็น 72 เท่าของ GPU เดียว ซึ่งหมายความว่าเวลาในการอ่านน้ำหนักจะลดลงเหลือ 1/72

“นี่คือคุณค่าที่แท้จริงของ scale-up domain ที่ใหญ่ขึ้น” Reiner เน้นย้ำ “มันช่วยให้คุณรันโมเดลที่ใหญ่ขึ้นและเบาบางขึ้นด้วยความหน่วงที่ต่ำลง และ Pipeline Parallelism ไม่สามารถให้อัตราขยายแบนด์วิดท์นี้ได้ เพราะแต่ละสเตจสามารถใช้แบนด์วิดท์ของ GPU ภายในสเตจนั้นเท่านั้น”

๔. การพลิกโฉมของ RL: โมเดลอาจถูกฝึกมากเกินไป 100 เท่า

4.1 ข้อจำกัดของกฎการปรับขนาด Chinchilla

ในปี 2022 DeepMind เสนอกฎการปรับขนาด Chinchilla ที่มีชื่อเสียง ซึ่งระบุว่าสำหรับงบประมาณการคำนวณที่กำหนด ขนาดโมเดลที่เหมาะสมที่สุดและจำนวน token การฝึกควรเป็นไปตามความสัมพันธ์ต่อไปนี้:

จำนวนพารามิเตอร์โมเดล ≈ จำนวน token การฝึก / 20

นั่นหมายความว่า โมเดลที่มี 100B พารามิเตอร์ ควรได้รับการฝึกบน 2T token ตามทฤษฎี เพื่อให้ได้การคำนวณที่เหมาะสมที่สุด

อย่างไรก็ตาม Reiner ชี้ให้เห็นว่ากฎ Chinchilla พิจารณาเฉพาะต้นทุนการคำนวณของการฝึกก่อน (Pre-training) เท่านั้น โดยละเลยต้นทุนการปรับแต่ง RL และการอนุมานในภายหลังโดยสิ้นเชิง ในกระบวนการพัฒนา AI ในปัจจุบัน การปรับแต่ง RL เป็นขั้นตอนที่ขาดไม่ได้ และต้นทุนการอนุมานเป็นค่าใช้จ่ายหลักหลังจากโมเดล上线

“เมื่อคุณรวมต้นทุน RL และการอนุมานเข้าไปด้วย กลยุทธ์การฝึกที่เหมาะสมที่สุดจะเปลี่ยนแปลงไปอย่างสิ้นเชิง” Reiner กล่าว

4.2 การลดต้นทุนรวม: การแบ่งส่วนของการฝึก, RL และการอนุมาน

Reiner เสนอหลักการ启发ที่เรียบง่ายแต่ลึกซึ้ง: เมื่อคุณต้องการลดผลรวมของต้นทุนสองอย่างให้เหลือน้อยที่สุด คำตอบที่ดีที่สุดมักจะอยู่ที่จุดที่ทั้งสองเท่ากัน

สำหรับโมเดล AI ต้นทุนทั้งหมดประกอบด้วยสามส่วน: ต้นทุนการฝึกก่อน, ต้นทุนการปรับแต่ง RL และต้นทุนการอนุมาน

• ต้นทุนการฝึกก่อน ≈ 6 × จำนวนพารามิเตอร์ที่ใช้งาน × จำนวน token การฝึกก่อน
• ต้นทุนการปรับแต่ง RL ≈ (2~6) × จำนวนพารามิเตอร์ที่ใช้งาน × จำนวน token RL
• ต้นทุนการอนุมาน ≈ 2 × จำนวนพารามิเตอร์ที่ใช้งาน × จำนวน token การอนุมาน

“ถ้าเราต้องการลดต้นทุนรวมให้เหลือน้อยที่สุด ทั้งสามส่วนนี้ควรจะเท่าๆ กัน” Reiner คาดการณ์ “แต่ละส่วนควรมีสัดส่วนประมาณหนึ่งในสามของต้นทุนทั้งหมด”

สมมติฐานนี้ถึงแม้จะกล้าได้กล้าเสีย แต่ก็ได้รับการสนับสนุนจากข้อมูลจริง Reiner ประมาณการโดยใช้ GPT-4 เป็นตัวอย่าง:

• สมมติว่า GPT-4 มีพารามิเตอร์ที่ใช้งานประมาณ 100B
• สมมติว่า GPT-4 ประมวลผล token การอนุมานทั้งหมดประมาณ 200T ระหว่างการ部署
• ดังนั้น การฝึกก่อนและการปรับแต่ง RL ก็น่าจะใช้ token อย่างละประมาณ 200T เช่นกัน

4.3 การ推导จากหลักการพื้นฐาน: ที่มาของการฝึกมากเกินไป 100 เท่า

ตามกฎ Chinchilla โมเดลที่มี 100B พารามิเตอร์ต้องการเพียง 2T token เพื่อให้ได้การคำนวณที่เหมาะสมที่สุด แต่จากการประมาณการข้างต้น GPT-4 ฝึกจริงประมาณ 200T token ซึ่งมากกว่าค่าที่เหมาะสมที่สุดของ Chinchilla ถึง 100 เท่า

“นี่คือสิ่งที่ฉันเรียกว่าการฝึกมากเกินไป 100 เท่า” Reiner อธิบาย “นี่ไม่ใช่การสิ้นเปลือง แต่เป็นการเลือกที่สมเหตุสมผลเพื่อลดต้นทุนรวมให้เหลือน้อยที่สุด”

ทำไมถึงเป็นเช่นนั้น? เพราะการฝึกมากเกินไปทำให้โมเดลมีคุณภาพสูงขึ้นด้วยจำนวนพารามิเตอร์เท่าเดิม หรือใช้โมเดลที่เล็กลงในขณะที่คุณภาพเท่าเดิม และโมเดลที่เล็กลงหมายถึงต้นทุน RL และการอนุมานที่ต่ำลง

“ถ้าโมเดลของคุณได้รับความนิยมอย่างมาก มีผู้ใช้หลายพันล้านคน การใช้จ่ายเพิ่มขึ้น 10 เท่าในการฝึกก่อน เพื่อทำให้โมเดลเล็กลงครึ่งหนึ่ง ซึ่งจะช่วยประหยัดต้นทุนการอนุมานครึ่งหนึ่ง ถือว่าคุ้มค่ามาก” Reiner วิเคราะห์

การนำ RL เข้ามายิ่งขยายผลกระทบนี้ การปรับแต่ง RL ต้องการการอนุมานจำนวนมากเพื่อสร้าง trajectory และโมเดลที่เล็กลงสามารถลดต้นทุน RL ได้อย่างมีนัยสำคัญ

4.4 สิ่งนี้หมายความว่าอย่างไรต่ออนาคตของ AI?

ข้อสรุปการฝึกมากเกินไป 100 เท่า มีผลกระทบอย่างลึกซึ้งต่ออนาคตของ AI:

• การเติบโตของขนาดโมเดลอาจชะลอตัวลง ในขณะที่จำนวน token การฝึกจะเติบโตอย่างรวดเร็วต่อไป
• ความสำคัญของข้อมูลจะเพิ่มขึ้นอีก ข้อมูลคุณภาพสูงจะกลายเป็นทรัพยากรที่หายากที่สุด
• ประสิทธิภาพการอนุมานจะกลายเป็นข้อพิจารณาหลักในการออกแบบโมเดล โมเดลแบบเบาบางและสถาปัตยกรรมที่มีประสิทธิภาพจะได้รับความนิยมมากขึ้น
• วงจรการอัปเดตโมเดลจะสั้นลง เนื่องจากโมเดลที่ฝึกมากเกินไปสามารถ迭代ได้เร็วขึ้น

“เรากำลังเปลี่ยนจากการ ‘แข่งขันขนาดโมเดล’ ไปสู่ ‘การแข่งขันประสิทธิภาพการฝึกและประสิทธิภาพการอนุมาน'” Reiner สรุป “ผู้ชนะในอนาคตไม่จำเป็นต้องเป็นบริษัทที่มีโมเดลใหญ่ที่สุด แต่เป็นบริษัทที่สามารถฝึกและ部署โมเดลคุณภาพสูงด้วยต้นทุนต่ำที่สุด”

๕. การย้อนกลับจากราคา API: ต้นทุนที่แท้จริงของบริบทยาว

5.1 ความลับที่รั่วไหลจากการกำหนดราคา Gemini: 200K คือจุดเปลี่ยนต้นทุน

ราคา API ของผู้ให้บริการ AI ดูเหมือนจะตั้งขึ้นตามอำเภอใจ แต่จริงๆ แล้วสะท้อนต้นทุนที่แท้จริงอย่างเคร่งครัด Reiner วิเคราะห์โดยใช้ราคาของ Gemini 2.5 Pro เป็นตัวอย่าง:

• ราคาอินพุต: ≤200K token, $2.50/ล้าน token
• ราคาเอาต์พุต: ≤200K token, $15.00/ล้าน token

“ทำไม 200K ถึงเป็นจุดเปลี่ยนราคา?” Reiner ถาม “เพราะนี่คือจุดสมดุลระหว่างการคำนวณและแบนด์วิดท์หน่วยความจำ”

เมื่อความยาวบริบทน้อยกว่า 200K เวลาในการคำนวณจะครอบงำ ต้นทุนค่อนข้างคงที่ เมื่อความยาวบริบทเกิน 200K เวลาในการอ่านหน่วยความจำของ KV Cache จะเกินเวลาในการคำนวณ กลายเป็นคอขวดใหม่ ต้นทุนเริ่มเพิ่มขึ้นเป็นเส้นตรง

ผ่านการ推导ทางพีชคณิตอย่างง่าย Reiner ย้อนกลับจากจุดเปลี่ยนราคานี้เพื่อหาขนาด KV Cache ต่อ token ของโมเดล Gemini ซึ่งอยู่ที่ประมาณ 2KB “ซึ่งสอดคล้องกับความเข้าใจของเราเกี่ยวกับโมเดล Transformer สมัยใหม่” Reiner กล่าว “มันอาจใช้ KV head 8 ตัว แต่ละ head มีมิติ 128 พอดีที่ 2KB ต่อ token”

5.2 Prefill vs Decode: ทำไม Output ถึงแพงกว่า Input 5 เท่า?

ปรากฏการณ์ราคาที่น่าสนใจอีกอย่างคือ ราคาของ token เอาต์พุตมักจะแพงกว่า token อินพุต 3-5 เท่า เนื่องจากรูปแบบการคำนวณของการประมวลผลอินพุต (Prefill) และการสร้างเอาต์พุต (Decode) แตกต่างกันโดยสิ้นเชิง

• Prefill: ประมวลผล token อินพุตทั้งหมดในครั้งเดียว ใช้ประโยชน์จากความสามารถในการคำนวณแบบขนานของ GPU ได้อย่างเต็มที่ ประสิทธิภาพการคำนวณสูงมาก
• Decode: สร้าง token เอาต์พุตทีละตัว แต่ละ token ต้องอ่านน้ำหนักทั้งหมดของโมเดล แบนด์วิดท์หน่วยความจำกลายเป็นคอขวด ประสิทธิภาพการคำนวณต่ำมาก

“ในขั้นตอน Decode การใช้งานการคำนวณของ GPU มักจะอยู่ที่ประมาณ 1/5 ของขั้นตอน Prefill เท่านั้น” Reiner อธิบาย “นี่

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK