Ask HN: ในเมื่อ ChatGPT ให้บริการผู้ใช้ได้ 700 ล้านคน แล้วทำไมฉันถึงรัน GPT-4 แค่ตัวเดียวบนเครื่องตัวเองไม่ได้?

 (news.ycombinator.com)
13 คะแนน โดย GN⁺ 2025-08-09 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Sam Altman ประกาศว่า ChatGPT รองรับผู้ใช้ราว 700 ล้านคนต่อสัปดาห์
  • แต่เมื่อรันโมเดลระดับ GPT-4 บนเครื่องตัวเอง ปัญหา VRAM ไม่พอและความเร็วตก กลับรุนแรงมาก จึงสงสัยว่า OpenAI จัดการปริมาณการใช้งานระดับมหาศาลแบบนี้ด้วย latency ต่ำและประสิทธิภาพสูง ได้อย่างไร
  • อยากรู้เทคนิคด้าน การปรับแต่งโมเดล การประมวลผลแบบกระจาย ฮาร์ดแวร์เฉพาะทาง และการทำ load balancing ที่มากกว่าแค่ GPU cluster ทั่วไป

สรุปคอมเมนต์สำคัญ

1. โครงสร้างการทำ inference แบบกระจายขนาดมหึมา

  • Model Sharding
    • กระจายเก็บพารามิเตอร์ไว้บน GPU หลายตัว
    • เมื่อมีคำขอเข้ามา แต่ละ GPU จะคำนวณในส่วนพารามิเตอร์ของตัวเองแล้วรวมผลลัพธ์เข้าด้วยกัน
  • Tensor Parallelism
    • ให้ GPU หลายตัวประมวลผลงานภายในเลเยอร์เดียวกันแบบขนาน
  • Pipeline Parallelism
    • แบ่งเลเยอร์ออกเป็นหลายขั้น แล้วประมวลผลแบบต่อท่อ ทั้งตามลำดับและพร้อมกัน
  • ใช้ การประมวลผลแบบขนานผสมผสาน เพื่อปรับสมดุลหน่วยความจำ GPU และภาระการคำนวณให้เหมาะสม

2. การเพิ่มประสิทธิภาพด้านหน่วยความจำและความเร็ว

  • Quantization: แปลงพารามิเตอร์ให้ใช้ความละเอียดบิตต่ำลงเพื่อลดการใช้ VRAM
  • Offloading เลเยอร์: ย้ายบางเลเยอร์ไปยังหน่วยความจำ CPU เมื่อต้องการ
  • LoRA / Adapter Layers: ปรับจูนเฉพาะงาน (fine-tuning) โดยไม่ต้องโหลดโมเดลทั้งก้อนใหม่ทั้งหมด
  • KV Caching: นำ context กลับมาใช้ซ้ำเพื่อตัดการคำนวณที่ซ้ำซ้อน

3. ฮาร์ดแวร์เฉพาะทางและเครือข่าย

  • ใช้งาน NVIDIA H100, A100 และ TPU บางส่วนในสเกลใหญ่
  • ใช้ NVLink และ NVSwitch ระหว่าง GPU รวมถึง Infiniband ระหว่างคลัสเตอร์ เพื่อส่งข้อมูลความเร็วสูงมาก
  • สร้าง backbone network ระดับโลกเชื่อมระหว่างดาต้าเซ็นเตอร์เพื่อลด latency ให้ต่ำที่สุด

4. การกระจายเชิงภูมิศาสตร์และ load balancing

  • วาง GPU farm ไว้ในหลายรีเจียนทั่วโลก
  • ใช้ GeoDNS เชื่อมคำขอของผู้ใช้ไปยังรีเจียนที่ใกล้ที่สุด
  • ขยาย/ลดขนาด GPU cluster แบบไดนามิก ตามรูปแบบทราฟฟิก
  • หากมีโหลดกระจุกในบางรีเจียน ก็จะกระจายทราฟฟิกใหม่ในระดับโลก

5. การเพิ่มประสิทธิภาพในการจัดการคำขอ

  • Batch Inference: รวมคำขอจากผู้ใช้หลายคนแล้วทำ inference พร้อมกันในครั้งเดียว
  • ประมวลผลเบื้องต้นด้วยโมเดลเล็ก: คำของ่ายใช้โมเดลขนาดเล็ก ส่วนคำขอซับซ้อนค่อยเรียกโมเดลใหญ่
  • Result Caching: แคชผลลัพธ์ของ prompt เดิมหรือคำขอที่คล้ายกันแล้วตอบกลับได้ทันที
  • ใช้ Prompt Engineering เพื่อลดการสิ้นเปลืองโทเค็นที่ไม่จำเป็น

6. การปฏิบัติการและการคุมต้นทุน

  • ลดทรัพยากรว่างให้ต่ำที่สุดด้วย การมอนิเตอร์และจัดตารางการใช้ GPU
  • เพิ่มประสิทธิภาพพลังงานของดาต้าเซ็นเตอร์และนำระบบ ระบายความร้อนด้วยของเหลว มาใช้
  • เพิ่มความเร็ว inference ด้วย compiler และ runtime ที่ปรับแต่งเอง
  • เดินระบบ pipeline อัตโนมัติสำหรับการอัปเดตและดีพลอยโมเดล

ตัวอย่างลำดับการทำงานของสถาปัตยกรรมโดยรวม

  1. รับคำขอจากผู้ใช้ → route ไปยังรีเจียนที่ใกล้ที่สุดด้วย GeoDNS
  2. Preprocessing → คำของ่ายส่งให้โมเดลเล็ก คำขอซับซ้อนค่อยส่งต่อไปยังโมเดลใหญ่
  3. ประมวลผล inference แบบกระจาย
    • ใช้ Model Sharding + Tensor Parallelism + Pipeline Parallelism
    • แลกเปลี่ยนผลลัพธ์ระหว่างทางผ่านเครือข่ายความเร็วสูงระหว่าง GPU
  4. Post-processing และ Result Caching → เก็บแคชไว้รองรับคำขอเดิมหรือใกล้เคียง
  5. ส่งคำตอบกลับ → ให้ผลลัพธ์ภายใน 1~2 วินาที

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

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

 
popkins 2025-08-11

สำหรับ OpenAI นั้น ไม่ได้ใช้แค่ฮาร์ดแวร์ของ NVIDIA เท่านั้น แต่ยังใช้ AMD MI300X สำหรับงานอนุมานด้วย ส่วนงานฝึกยังคงใช้ NVIDIA เท่านั้น
สำหรับงานอนุมาน พวกเขาพยายามอย่างหนักเพื่อให้ได้ VRAM มากที่สุดเมื่อเทียบกับต้นทุนการลงทุน
ในกรณีของ Microsoft ก็เหมือนกัน โดยสำหรับงานอนุมานนั้นใช้ทั้ง NVIDIA และ AMD ร่วมกัน
 
popkins 2025-08-11

โดยเฉพาะใน Azure region ฝั่งเอเชีย สัดส่วน AMD ที่ OpenAI ใช้อยู่ประมาณ
NVIDIA 8 / AMD 2
 
GN⁺ 2025-08-09
ความเห็นจาก Hacker News

  • ผมทำงานกับระบบพวกนี้โดยตรงที่ Google (เป็นความเห็นส่วนตัว) และยืนยันได้ว่าคนเก่ง ๆ กำลังคิดเรื่องทุกแง่มุมของปัญหานี้อย่างจริงจัง ผมบอกรายละเอียดมากกว่านี้ไม่ได้ แต่อยากแชร์เอกสารที่เพื่อนร่วมงานเขียนไว้ มีคำอธิบายที่ยอดเยี่ยมเกี่ยวกับสถาปัตยกรรมตัวเร่งความเร็วและวิธีการปรับแต่งให้ได้ความเร็วสูง ดูได้ใน scaling book โดยเฉพาะถ้าสนใจเรื่อง inference ก็แนะนำ บท inference เพิ่มเติมขอแนะนำไกด์ของ unsloth ด้วย เพราะลงลึกกับโมเดลหลากหลายตัวเพื่อหาแนวทาง optimize แล้วสรุปไว้ดีมาก นอกจาก คู่มือ Gemma 3n ก็ยังมีไกด์อื่น ๆ อีกหลายอัน

    • ถ้าจะอธิบายแบบไม่ให้ดูลึกลับนัก inference นั้น (ส่วนใหญ่) เป็นงานแบบไร้สถานะ ดังนั้นจึงไม่ต้องกังวลเรื่อง memory consistency ระหว่างเครื่องหลายแสนเครื่องหรือปัญหาเครื่องล่มแบบตอนฝึกโมเดล แค่ต้องส่งข้อมูลปริมาณเล็กน้อยเข้าไปยังเครื่องขนาดใหญ่มาก ๆ ให้ดีพอ เครื่องวิจัยที่ผมเคยใช้งานเป็นเครื่องสมรรถนะสูงมากที่มี GPU 8 ตัว และตราบใดที่โมเดลยังใส่รวมกันอยู่ใน VRAM ได้ ก็จัดการงานอะไรก็ได้อย่างเหมาะสม เคล็ดลับลับของการขยายสเกลขนาดใหญ่คือ "เงินทุนมหาศาล" NVIDIA เคยส่งเครื่อง DGX แบบหรูหราให้เราด้วย ซึ่งมันไม่ได้หนาแน่นมากและราคาแพงมาก บริษัทใหญ่ส่วนมากมีระบบ RPC และ orchestration ที่เสถียรอยู่แล้ว ดังนั้นส่วนที่ยากจริง ๆ ไม่ใช่การส่งข้อความ แต่เป็นการทำให้โมเดลลงตัวกับฮาร์ดแวร์ที่มีอยู่ (ซึ่งไม่ใช่สายเชี่ยวชาญของผม)

    • แร็ก inference ขนาดใหญ่สมัยใหม่ เทคนิค RDMA และเครือข่าย latency ต่ำที่เป็นที่รู้จักกันดี รวมถึง MLA และการ optimize cache ที่ทรงพลัง ไม่จำเป็นต้องถูกเล่าว่าเป็นเทคโนโลยีลึกลับ สิ่งเหล่านี้เป็นเรื่องที่เปิดเผยและเข้าใจกันดีอยู่แล้ว ตรงกันข้าม ถ้าบริษัทดังแห่งหนึ่งทำอะไรแบบ custom มากเกินไป ก็มักกลายเป็นภาระเพราะปัญหาความเข้ากันได้ย้อนหลัง สิ่งที่สำคัญจริง ๆ คือการมีระบบและกระบวนการที่ดีพอสำหรับเดินเครื่องระบบขนาดใหญ่ ซึ่งครอบคลุมตั้งแต่การจัดหาอุปกรณ์ การฝึก SRE ไปจนถึง RTL สำหรับ TPU รุ่นใหม่ ถ้าใครนำหน้าไป 10 เท่า คนอื่นจะรู้ได้ทันที (เป็นคนที่มีประสบการณ์ inference ขนาดใหญ่ในบริษัท TOP-5 มา 10 ปี)

    • สำหรับประโยคที่ว่า "เราเป็นคนฉลาดที่คิดทุกปัญหาอย่างจริงจังมาก" ความจริงคือจะมองว่าเป็นระบบ time-sharing แบบเมนเฟรมสไตล์ยุค 1970 ก็ได้

    • ผมสงสัยว่า Google น่าจะทำกำไรจากการรัน inference ของโมเดลตัวเองได้สูงกว่าการเช่าการ์ด NVIDIA มากเพราะมี TPU ส่วน OpenAI เท่าที่รู้ก็ได้ GPU มาเป็นหลักผ่านพาร์ตเนอร์กับ Microsoft ทั้งลิงก์และหนังสือน่าสนใจมาก

    • ประโยคที่ว่า "ทุกวันนี้แม้แต่โมเดล 'เล็ก' ก็ทำงานชนขีดจำกัดของฮาร์ดแวร์" สะดุดใจมาก ฟังดูคล้ายกับคำพูดในยุค 60s, 70s ที่ว่า "แม้แต่โปรแกรมเล็ก ๆ ก็ทำงานพอดีกับขีดจำกัดของฮาร์ดแวร์" ถึงการ optimize และประสิทธิภาพใน software engineering จะดูเลือนหายไป แต่ในโลกการพัฒนา LLM มันยังมีชีวิตอยู่มาก

  • H100 หนึ่งตัวราคา 20,000 ดอลลาร์และมี VRAM 80GB ลองนึกภาพเซิร์ฟเวอร์แร็ก 2U ที่ใส่การ์ดแบบนี้มูลค่า 100,000 ดอลลาร์เข้าไป ทั้งแร็กเมื่อรวม CPU, RAM และระบบระบายความร้อนแล้วก็อยู่ระดับล้านดอลลาร์ต่อแร็ก (ยังไม่รวมค่าใช้จ่ายในการดำเนินงานและค่าทีมดูแลรักษา) ต่อให้เป็นอุปกรณ์ "ราคาถูก" หน่วยการคำนวณก็ยังใหญ่มาก ผมหวังว่าเมื่อฟองสบู่ AI แตก เราน่าจะรัน local model ดี ๆ ได้อย่างสมเหตุสมผล อีก 10 ปีข้างหน้า เซิร์ฟเวอร์ราคา 100,000 ดอลลาร์พวกนี้อาจไปขายบน eBay เหลือ 3,000 ดอลลาร์ และอาจมีช่างไฟถูกขอให้มาติดตั้งไฟ 240V ในโรงรถหรือห้องเซิร์ฟเวอร์ชั่วคราวก็ได้

    • ไม่ต้องรอ 10 ปีก็ซื้อ DGX-1 บน eBay ได้ในราคาต่ำกว่า 10,000 ดอลลาร์แล้ว มี VRAM 256GB (HBM2), NVLink, RAM 512GB, CPU 40 คอร์, SSD 8TB และ HBA 100Gbit ของที่ไม่ใช่แบรนด์ NVIDIA ยังเจอได้แถว 6,000 ดอลลาร์ด้วย แต่หนักมาก เสียงดังเกินคาด และหนึ่งเครื่องก็กินวงจรไฟ 240V 16A เกือบเต็ม แถมปล่อยความร้อน 13,000 BTU ต่อชั่วโมงด้วย

    • ต่อให้ฟองสบู่ AI ไม่แตก เซิร์ฟเวอร์พวกนี้ก็น่าจะหลุดมาอยู่บน eBay ในอีก 10 ปีอยู่ดี เพราะดาต้าเซ็นเตอร์จะอัปเกรดฮาร์ดแวร์และขายของมือสองต่อให้บุคคลที่สาม

    • โดยส่วนตัวผมสงสัยว่าโมเดลเปิดที่มีอยู่ใช้การคำนวณน้อยกว่าที่เราคิดมาก ในโมเดล Mixture of Experts รุ่นใหม่ ด้วยโครงสร้างแบบ top-k sampling ที่เปิดใช้งานเฉพาะผู้เชี่ยวชาญบางส่วน (พารามิเตอร์บางส่วน) เพื่อประเมินผล ทำให้แม้จะเป็นโมเดลระดับ SOTA ก็ไม่ได้ต้องใช้การคำนวณมากกว่าโมเดล non-MoE ขนาด 70-80B มากนัก

    • สำหรับการเสิร์ฟ AI ระดับองค์กร คำถามจริงไม่ใช่ "จะให้บริการผู้ใช้อย่างไร" แต่คือเหล่านักลงทุนคาดหวัง ROI ในสักวันหนึ่งต่างหาก ถ้ามีเงินลงทุนเข้ามา จะสร้างโครงสร้างพื้นฐานเท่าที่ต้องการก็ได้ ต่อให้ไม่มี optimization ก็ยังสร้างโกดังและแร็กเพิ่มตามต้องการเพื่อให้บริการได้

    • ผมไม่ใช่คนอเมริกัน เลยขำกับเรื่อง 240V มาก

  • คุณมีเงินหลักพันดอลลาร์ แต่พวกเขามีเงินหลักหมื่นล้านดอลลาร์ ต่างกันระดับ 1,000 vs 10,000,000,000 ประสิทธิภาพที่เขามีก็ดีกว่าในเชิงสเกลอีกประมาณหนึ่งถึงสองหลักด้วย นอกจากนี้ บน MacBook (RAM 24GB) ตอนนี้ก็สามารถรัน local model ที่ให้ผลพอ ๆ กับ GPT-4 ช่วงเปิดตัวแรก ๆ ได้แล้ว ลิงก์เปรียบเทียบประสิทธิภาพ

    • ถ้ากระจายผู้ใช้ 700 ล้านคนออกไปทั้งวันหรือทั้งสัปดาห์ จริง ๆ แล้วอาจมีเพียงราว 10 ล้านเซสชันที่ active พร้อมกัน ผู้ใช้แต่ละคนไม่สามารถสะสมทรัพยากรคอมพิวต์ทั้งสัปดาห์ไว้ใช้รวดเดียวได้ แต่ผู้ให้บริการสามารถขยายแนวนอนเพื่อรองรับเฉพาะช่วงพีคได้ ดังนั้นที่ความต้องการประสิทธิภาพเท่ากัน สภาพแวดล้อม local จึงต้องใช้ฮาร์ดแวร์มากกว่ามาก

  • แค่ GPU node เดียวก็ให้ทั้ง FLOPs และ memory bandwidth สูงมากแล้ว เวลาจัดการคำขอเพียงไม่กี่รายการ GPU มักใช้เวลารอ stream ข้อมูล weight จาก RAM ไปยังหน่วยคำนวณเป็นหลัก แต่ถ้ารวมคำขอเป็น batch ก็อ่าน weight ชุดเดียวแล้วประมวลผลหลายคำขอแบบขนานได้ ทำให้ประสิทธิภาพสูงสุด นอกจากนี้ยังบีบอัดโมเดลเป็น 8-bit หรือต่ำกว่านั้นเพื่อลดปริมาณข้อมูลที่ต้อง stream ได้ และ GPU รุ่นใหม่ก็รองรับการคำนวณ 8-bit/4-bit โมเดล Mixture of Experts ใช้พารามิเตอร์เพียงบางส่วนต่อแต่ละโทเค็น จึงต้องดึง weight น้อยลง เทคนิค speculative decoding ใช้โมเดลเล็กเพื่อทำนายหลายโทเค็นล่วงหน้า จากนั้นโมเดลหลักจะรับเฉพาะที่ตรงกัน การ optimize ทั้งหมดนี้รวมกันแล้วให้ประสิทธิภาพที่ยอดเยี่ยม (อิงจากประสบการณ์ในตำแหน่ง Director ของทีม inference ที่ Databricks)

  • หนึ่งในซอสลับของ OpenAI คือการขาดทุนระดับหลายพันล้านดอลลาร์ ปี 2024 ขาดทุนไป 5 พันล้านดอลลาร์ บทความที่เกี่ยวข้อง

    • ทุกวันนี้แนวทาง agentic เข้ามาเปลี่ยนสถานการณ์ไปมาก เมื่อก่อนคือ 1 คำขอ ต่อ 1 การประมวลผล แต่ตอนนี้หนึ่งงานอาจมีการประมวลผลหลายร้อยครั้งพร้อมกัน ความสามารถในการทำงานขนานแบบนี้ทำให้ OAI/Azure ได้เปรียบกว่า local model

    • ถ้าตัด R&D ออกแล้วให้บริการเฉพาะโมเดลที่มีอยู่ ผมคิดว่าน่าจะทำให้ถึงจุดคุ้มทุนได้

    • จับประเด็นสำคัญได้ดี เงินลงทุนจาก Microsoft สูงสุด 10 พันล้านดอลลาร์ครอบคลุมทั้ง pretraining, R&D และต้นทุน inference แต่ก็ยังขาดทุนหลายพันล้านดอลลาร์อยู่ดี เป็นโครงสร้างทุนนิยมแบบ VC ที่เน้นการเติบโต

  • ใน inference ขนาดใหญ่ การรวมคำขอเป็น batch แล้วประมวลผลพร้อมกันมีประสิทธิภาพกว่าวิธีจัดสรร GPU ต่อผู้ใช้แต่ละราย (สภาพแวดล้อมส่วนบุคคล) มาก ถ้าอยากรู้กลเม็ดวิศวกรรมระดับกลาง ๆ ลองดูบทความที่ทีมเราลงในบล็อก Fin AI ได้ (OpenAI และรายอื่น ๆ น่าจะใช้เทคนิคปิดที่ไม่มีในนี้ด้วย) โพสต์ที่เกี่ยวข้อง

    • นี่แหละคือคำตอบสำคัญจริง ๆ มากกว่าเรื่องอื่น ๆ ที่ถกกันข้างบน batching ต่างหากที่ทำให้ต้นทุนลดฮวบ สมมติว่าการประมวลผลคำขอหนึ่งครั้งมีค่าใช้จ่าย 50,000 ดอลลาร์ ด้วย batching คุณอาจใช้เงิน 50,000 ดอลลาร์เท่าเดิมประมวลผลได้ 100 คำขอพร้อมกันโดยแทบไม่เสียอะไรเพิ่ม จริง ๆ แล้วฮาร์ดแวร์หนึ่งชุดรองรับผู้ใช้ได้กี่คนผมไม่แน่ใจ แต่คิดว่าน่าจะระดับหลายร้อยคน นั่นหมายความว่าต้นทุนอาจลดจาก 50,000 ดอลลาร์เหลือ 500 ดอลลาร์ได้อย่างมีประสิทธิภาพ (ถ้ามีผู้ใช้มากพอ) คอขวดของการประมวลผล LLM ส่วนใหญ่คือเวลาที่ใช้โหลด weight เข้า GPU ดังนั้นแทนที่จะประมวลผลแต่ละคำขอแยกกัน ก็เอางานของหลายคำขอมาคิดร่วมกันเพื่อดึงประสิทธิภาพสูงสุด ตัวอย่างเช่น ถ้ามีชุด weight 3 ชุด (A, B, C) อยู่ใน GPU cache และมีคำขอ 2 รายการ (1, 2) วิธีทั่วไปคือโหลด weight สำหรับแต่ละคำขอแยกกันแล้วค่อยใช้ แต่แนวทาง batching คือโหลด weight หนึ่งครั้งแล้วคำนวณให้หลายคำขอพร้อมกัน ถ้าเทียบเวลาโหลด weight กับเวลาคำนวณ จะเห็นความต่างของความเร็วก่อนและหลัง batching ชัดมาก ในโลกจริงการโหลด weight ช้ากว่าการคำนวณมาก ดังนั้นยิ่งมีผู้ใช้มาก ความต่างยิ่งชัด แน่นอนว่าในทางปฏิบัติก็ยังต้องมีหน่วยความจำสำหรับสถานะ activation เพื่อรองรับผู้ใช้มากขึ้น จึงต้องบาลานซ์ว่าจะให้ GPU cluster หนึ่งชุดรองรับกี่คน สรุปคือฮาร์ดแวร์สำหรับเสิร์ฟ LLM แพงมาก แต่ถ้ามีอยู่แล้ว ก็ให้บริการผู้ใช้พร้อมกันได้หลักร้อยโดยที่ประสิทธิภาพแทบไม่ตก

  • การมีผู้ใช้ 700 ล้านคนต่อสัปดาห์ไม่ได้บอกเรื่องโหลดจริงมากนัก ต่อให้ผู้ใช้ ChatGPT ส่วนใหญ่ใช้วันละหนึ่งชั่วโมงตลอดทั้งสัปดาห์ เวลาที่เหลือ 96% ก็ยัง idle อยู่ หลายคนยังใช้เพียงโมเดลที่ซับซ้อนน้อยกว่า การที่ต้องพูดถึง "ผู้ใช้รายสัปดาห์" เองก็สื่อว่าในกลุ่มผู้ใช้รายวันยังมีส่วนน้อยที่ไม่ได้ใช้แม้แต่วันละครั้งด้วยซ้ำ โจทย์หลักคือ 1) สร้างเซิร์ฟเวอร์ที่บรรจุโมเดลในหน่วยความจำได้และประมวลผลโทเค็นได้เร็วพอ 2) มีเซิร์ฟเวอร์เพียงพอต่อปริมาณโทเค็นสูงสุดช่วงพีค 3) กระจายทุกคำขอไปยังเซิร์ฟเวอร์อย่างมีประสิทธิภาพ รายละเอียดมีอีกมาก แต่จริง ๆ แล้วโจทย์ข้อสุดท้ายก็ให้ความรู้สึกคล้ายการรันเสิร์ชเอนจิน เพราะสถานะทั้งหมดอยู่ในประวัติแชต จึงไม่จำเป็นต้องให้แชตเดิมไปอยู่ที่เซิร์ฟเวอร์เดิมเสมอไป ตอนที่เห็นข้อความ "Thinking..." นั้นจริง ๆ โมเดลกำลังคำนวณอยู่หรือกำลังรอคิวเซิร์ฟเวอร์ก็ไม่ได้ถูกเปิดเผย

  • หนึ่งในเคล็ดลับสำคัญที่สุดที่ทำให้ LLM รันในสเกลใหญ่ได้ดีคือ "batch size" ปัจจุบัน LLM ส่วนใหญ่ใช้สถาปัตยกรรม "Mixture of Experts" ซึ่งเปิดใช้งานเพียงบางส่วนของพารามิเตอร์ทั้งหมดในช่วงเวลาสั้น ๆ ทำให้การประมวลผล batch ขนาดใหญ่มีประสิทธิภาพมากขึ้นมาก ถ้าคุณจะรัน GPT-4 ที่บ้าน คุณต้องใส่โมเดลทั้งตัวลงใน VRAM ได้ ซึ่งแปลว่าต้องใช้ GPU หลายใบอย่าง H100 (ใบละประมาณ 40,000 ดอลลาร์) แต่การใช้งานส่วนบุคคลก็ใช้การ์ดแบบนั้นได้ไม่คุ้ม คล้ายกับถามว่า "ทำไม Apple ถึงผลิต iPhone ให้คนเป็นพันล้านได้ แต่ผมกลับทำเองในโรงรถไม่ได้แม้แต่เครื่องเดียว?"

    • สรุปคือ โหลดของ inference ถูกกระจายไปยังผู้ใช้จำนวนมากได้ดี จึงทำงานได้อย่างมีประสิทธิภาพ

    • ถ้าอย่างนั้นก็สงสัยว่าโครงสร้างที่เก็บส่วนที่ใช้น้อยไว้ใน main memory และเก็บส่วนที่ใช้บ่อยไว้ใน VRAM จะเป็นไปได้ไหม

    • อุปมานี้เหมาะมาก

  • ทริกอย่างหนึ่งที่ทำที่บ้านได้และเป็นส่วนสำคัญของประสิทธิภาพของ Cerebras คือ speculative decoding วิธีนี้ใช้โมเดลร่างที่เล็กกว่ามากเพื่อทำนายโทเค็นด้วยการคำนวณและหน่วยความจำน้อยกว่ามาก แล้วให้โมเดลหลักรับเฉพาะโทเค็นที่มันน่าจะเลือกเหมือนกัน ในระบบที่เซ็ตมาดีอาจเร่งความเร็วได้ถึง 3 เท่า อีกอย่างสำหรับ structured output ก็ใช้ "fast forwarding" เพื่อข้ามโทเค็นที่คาดเดาได้ โดยกรอกโครงเริ่มต้นของ JSON เป็นต้นไว้ล่วงหน้า จึงเพิ่มความเร็วได้สูงสุดราว 3 เท่าเช่นกัน

    • ใน LM Studio สามารถจับคู่ gpt-oss-120b กับ gpt-oss-20b เพื่อทำ speculative drafting ได้ แต่รู้สึกว่าประสิทธิภาพที่สัมผัสได้ไม่ได้เพิ่มขึ้นมากนัก

  • แก่นของ LLM inference คือการคูณเมทริกซ์-เวกเตอร์ เมื่อมีหลาย query ต้องประมวลผลพร้อมกัน ก็สามารถรวมเวกเตอร์ของแต่ละ query เป็นเมทริกซ์ แล้วคำนวณพร้อมกันผ่านการคูณเมทริกซ์-เมทริกซ์ได้ จากมุมมองของฮาร์ดแวร์ การคูณเมทริกซ์-เมทริกซ์หนึ่งครั้งมีประสิทธิภาพกว่าการทำเมทริกซ์-เวกเตอร์ซ้ำ ๆ หลายรอบมาก นี่แหละคือ batching ทริกที่สองคือ speculative decoding ใน inference มีสองช่วงคือการประมวลผลพรอมป์ต์และการสร้างโทเค็น ซึ่งจริง ๆ แล้วทั้งคู่มีโครงสร้างเดียวกันคือ "forward pass" การประมวลผลพรอมป์ต์ทำแบบขนานด้วยการคูณเมทริกซ์-เมทริกซ์ได้ และใช้แค่ผลลัพธ์สุดท้ายเพื่อเริ่มการสร้างโทเค็น แต่เพราะเราไม่รู้โทเค็นในอนาคตล่วงหน้า จึงมักทำขนานไม่ได้ ดังนั้นจึงใช้โมเดลร่างที่เร็วกว่าเพื่อทำนายโทเค็นล่วงหน้า N ตัว แล้วใส่มันเข้าไปในพรอมป์ต์อินพุต จากนั้นรัน forward pass แบบขนานด้วยโมเดลหลัก ถ้าในโทเค็นที่ได้ N ตัวนั้นมีช่วงต้นที่ตรงกัน ก็สามารถยอมรับทุกโทเค็นจนถึงตัวแรกที่ตรงกันเป็นโทเค็นที่ถูกต้องได้ทันที ในทางทฤษฎีคาดว่าจะเพิ่มความเร็ว inference ได้ 2-4 เท่า ผมไม่ได้ทำสิ่งนี้เองโดยตรงในงาน แต่เดาว่าน่าจะมีการใช้การจัดกลุ่มแบบขนานตามความยาวของ query หรือ real-time load balancing เพิ่มเติมด้วยเช่นกัน (เพราะคำขอทุกอันยาวเท่ากันไม่ได้ จึงต้องมีเพื่อกันความไม่สมดุลของทรัพยากร)