วิธีรัน GPT-OSS-120B บน NVIDIA GPU ให้ประมวลผลได้มากกว่า 500 โทเค็นต่อวินาที

• LLM โอเพนซอร์สของ OpenAI อย่าง GPT-OSS-120B ถูกปรับแต่งให้ทำงานในสภาพแวดล้อม NVIDIA GPU ได้ด้วยประสิทธิภาพการประมวลผล มากกว่า 500 โทเค็นต่อวินาที
• ทดสอบเฟรมเวิร์ก TensorRT-LLM, vLLM, SGLang และเฟรมเวิร์ก การอนุมาน อื่นๆ แบบขนานพร้อมกัน และรองรับสถาปัตยกรรม Hopper กับ Blackwell
• แก้ไขบั๊กความเข้ากันได้ และเพิ่มการรวมรูปแบบการตอบสนองใหม่อย่าง Harmony, KV cache-aware routing และการถอดรหัสแบบคาดการณ์บนพื้นฐาน Eagle ลงในงานปรับแต่งประสิทธิภาพ
• เปรียบเทียบ Tensor Parallelism และ Expert Parallelism แล้วพบว่าเพื่อความหน่วงต่ำให้เลือกการกระจายงานแบบเทนเซอร์ และใช้ TensorRT-LLM MoE Backend ใน Blackwell
• มีแผนปรับปรุงเพิ่มเติมต่อไป โดยรวมถึง Speculative Decoding ที่ใช้โมเดล "draft" ขนาดเล็กเพื่อเพิ่มประสิทธิภาพการทำงาน

---

ภาพรวม

• เมื่อ GPT-OSS-120B ซึ่งเป็นโมเดลภาษาขนาดใหญ่โอเพนซอร์สล่าสุดของ OpenAI ถูกเผยแพร่พร้อมกัน Baseten ก็ท้าทายเป้าหมายในการสร้างประสิทธิภาพสูงสุด
  • Baseten เป็นพันธมิตรเปิดตัวอย่างเป็นทางการของ OpenAI
• จากข้อมูลใช้งานจริงที่เผยแพร่บน OpenRouter แสดงให้เห็นประสิทธิภาพที่เหนือกว่าคู่แข่งในสภาพแวดล้อม NVIDIA GPU
• ด้วยความเชี่ยวชาญของ Flexible Inference Stack และทีมวิศวกรโมเดล ทำให้สามารถปรับปรุงแพตช์ประสิทธิภาพตามเวลาได้อย่างรวดเร็ว
• ภายในเวลาไม่กี่ชั่วโมงระหว่างการเขียนบล็อก ยังเพิ่ม throughput ได้อีก 100 โทเค็นต่อวินาทีและรักษา uptime ที่ 100%

ความพยายามในการเพิ่มประสิทธิภาพการอนุมาน

• ทำการทดสอบและ benchmark กับเฟรมเวิร์กการอนุมานหลากหลาย เช่น TensorRT-LLM, vLLM, SGLang
• ทำงานควบคู่กับการรองรับสถาปัตยกรรม GPU Hopper และ Blackwell
• ผสานเข้ากับส่วนประกอบสำคัญต่างๆ ได้แก่ Baseten Flexible Inference Stack และ NVIDIA Dynamo
• นำเทคนิคการเพิ่มประสิทธิภาพที่ผ่านการตรวจสอบมาใช้ต่อเนื่อง เช่น KV cache-aware routing และ Speculative decoding (Eagle-based)

ด้านล่างคือขั้นตอนสำคัญเพื่อให้ได้ทั้งประสิทธิภาพระดับ SOTA และรองรับ context window แบบครบถ้วนพร้อมกัน

Step 1: การรัน inference ครั้งแรก

• จุดเริ่มต้นคือการรัน baseline inference ให้เร็วที่สุดในวิธีใดก็ได้
• นักวิศวกรหลายคนทำการทดลอง vLLM, SGLang, TensorRT-LLM พร้อมๆ กันบนพื้นฐานการออกแบบจาก GPU
• ปรับระบบให้ TensorRT-LLM ซึ่งมีประสิทธิภาพดีที่สุดสามารถทำงานได้อย่างรวดเร็ว
• ได้รับการรองรับ TensorRT-LLM ทั้งบน Hopper (มี H100 GPU มากที่สุด) และ Blackwell (B200 GPU ที่มีความเร็วสูงกว่า)
• ความยืดหยุ่นของ Baseten Inference Runtime ทำให้รองรับสถาปัตยกรรมแบบใหม่และการสลับเครื่องมือในสแตกได้อย่างรวดเร็ว

Step 2: การแก้บั๊กความเข้ากันได้

• การกำเนิดสถาปัตยกรรมโมเดลใหม่มักมาพร้อมบั๊กที่เกิดจากการผสานเข้ากับเฟรมเวิร์กบ่อยครั้ง
• GPT OSS มีการเพิ่มเทคโนโลยีใหม่ เช่น รูปแบบการตอบกลับ Harmony จึงเกิดบั๊กเมื่อรวมกับเฟรมเวิร์กเดิม
• เพื่อคงความเร็วและความแม่นยำไว้พร้อมกัน มีการแก้ไขและทดสอบซ้ำอย่างต่อเนื่อง และการปรับปรุงที่มีประสิทธิผลถูกส่งกลับเป็นโอเพนซอร์ส
• ผ่านความร่วมมือของชุมชนโอเพนซอร์สทั่วโลก ทำให้เส้นทางการเพิ่มประสิทธิภาพและการแก้บั๊กที่หลากหลายเกิดขึ้นได้อย่างรวดเร็ว

Step 3: การปรับแต่งโมเดล

• แม้ OpenAI จะระบุว่า GPT OSS 120B ทำงานได้บน H100 ตัวเดียว แต่ในการปฏิบัติก็พบว่าการขนานด้วย GPU 4~8 ตัว ให้ผลการทำงานดีกว่า
• Tensor Parallelism มีข้อได้เปรียบด้าน latency ในขณะที่ Expert Parallelism มีข้อได้เปรียบด้าน throughput ของระบบ
  • เนื่องจาก Baseten ตั้งเป้าหมายที่การปรับแต่งความหน่วง จึงเลือกใช้ Tensor Parallelism
• บน Blackwell มีการใช้ TensorRT-LLM MoE Backend เพื่อยกระดับประสิทธิภาพ CUDA kernel เมื่อเทียบกับ Triton backend เดิม
• เปิดเผยการตั้งค่าสำหรับ Hopper และ Blackwell โดยแยกตามสภาพแวดล้อม และใน Model API ใช้การตั้งค่าที่อิง Blackwell

การปรับแต่งประสิทธิภาพเพิ่มเติม

• แม้ว่าการปรับแต่งรอบแรกจะทำให้ได้ throughput และ latency ระดับ SOTA แล้ว แต่ยังมีช่องว่างในการพัฒนาปรับปรุงอย่างมาก
• แผนอัปเดตสำคัญถัดไปคือการนำ Speculative Decoding มาใช้
  • วิธีนี้ใช้โมเดล "draft" ขนาดเล็กที่เร็วกว่าในการสร้างโทเค็นคาดเดา และให้โมเดลหลักทำการตรวจสอบ
  • Baseten แนะนำ Eagle 3 แต่ภายในสแตก inference มีการใช้งานอัลกอริทึมมากกว่า 10 แบบที่ปรับได้ตามสถานการณ์
• Speculative decoding ช่วยเพิ่มความเร็วอย่างมีประสิทธิภาพ โดยประมวลผลการอนุมานหลายโทเค็นในครั้งเดียว

[jjw951215]

ก็อยากมี H100 ตัวเล็ก ๆ น่ารักตัวเดียวให้ฉันสักคนมอบให้สักหน่อยนะ...

[GN⁺]

ความคิดเห็นจาก Hacker News

• widely-available H100 GPUs

  ผมเลยไปค้นลิ้นชักอะไหล่ที่บ้านดู แต่ไม่ว่าจะหายังไงก็ไม่เจอว่าทำไมจึงไม่มี GPU H100 ราคา 25,000 ดอลลาร์

  • ผมเช็กจากหน้าเว็บผลิตภัณฑ์ของ NVIDIA เองแล้วยืนยันว่า H100 ถูกจัดว่าเป็น GPU โดยตรง ตอนนี้รู้สึกว่าควรมีชื่อที่แยกความแตกต่างให้ชัดขึ้น ระหว่าง “ฮาร์ดแวร์เกรดผู้บริโภคที่เน้นเกมเป็นหลักแต่สามารถอนุมาน LLM ได้อย่างจำกัด” กับ “ฮาร์ดแวร์ระดับธุรกิจที่มีเป้าหมายหลักในการเทรน AI หรืออนุมาน LLM และเป็นฮาร์ดแวร์มืออาชีพ”
  • ผมเคยรันโมเดล 20B ด้วย Ollama บนการ์ด TitanX 8 ใบ (รุ่นปี 2015) Ollama กระจาย VRAM รวม 15GB ให้ 8 ใบอย่างค่อนข้างเท่ากัน และอัตราโทเคนออกมาก็เร็วกว่าอัตราอ่านข้อมูลอีกด้วย
  • GPU แบบนี้เช่าสามารถทำได้ง่ายมาก ถ้าไม่ได้รัน GPU ต่อเนื่อง 24/7 อยู่ตลอดเวลา การเช่าโฮสติ้งมักคุ้มกว่าการซื้อเองมาก สำหรับการใช้งานส่วนตัวแทบไม่ต้องใช้การ์ดระดับ data center ล่าสุดและในกรณีแบบนั้น Mac Studio หรือ Strix Halo ก็พอ อย่างไรก็ตามความเร็วจะช้ากว่าอยู่บ้าง
  • เพราะคอมเมนต์นี้ วันนี้ของผมเลยดีขึ้นมากจริง ๆ มันเป็นมุมมองเชิง data center ชัดเจน และฮาร์ดแวร์ที่เร็วที่สุดในลิ้นชักของผมคงเป็น iPhone 8 รุ่นเก่า
  • วลี “บ้านไม่มี GPU 25,000 ดอลลาร์” หมายความว่า “ซื้อได้” หรือ “หาจาก stock ได้” เท่านั้น ไม่ได้แปลว่าผู้ใช้มีเงินพอซื้อได้เสมอ

• ผมลองใช้ GPT-OSS-120B บน MacBook Pro (M4, 128GB RAM) ระหว่างเดินทางด้วยเครื่องบินข้ามมหาสมุทรแอตแลนติก เร็วเฉพาะเมื่อหน้าต่างบริบทเล็กและโทเคนรวมไม่มาก เมื่อเกิน 10,000 โทเคน จะมีการประมวลผลเกือบทั้งหมดที่ช้าลงและคิวยาว MCPs, การค้นเว็บ และการ patch URL กลายเป็นสิ่งสำคัญมากแล้วในการใช้งาน LLM หากไม่มีฟีเจอร์พวกนี้ utility ของ LLM ก็ลดลงมาก เครื่องมือโค้ดดิ้งแบบ CLI/TUI สำหรับสภาพแวดล้อมออฟไลน์ที่ผมตั้งไว้ล่วงหน้า (เช่น opencode) ทำงานร่วมกับโมเดลได้ไม่ค่อยน่าเชื่อถือ โมเดล OSS ยังมีไฮไลต์อื่น ๆ อีกด้วย นอกเหนือจากเรื่องที่ถูกพูดถึงเยอะในคอมเมนต์ก่อน ๆ

  • วิกิพีเดียรุ่นเก่าก็เคยถูกเก็บไว้ใช้งานบนเครื่องได้แล้ว เพราะงั้นผมคิดว่าภายหน้าจะมีการเปิดข้อมูลจำนวนมากผ่าน MCP เพื่อให้ AI ค้นหาแบบ local เหมือนกับ “เว็บเซิร์ช” โห การค้นเว็บ 99% เกิดขึ้นที่เว็บไซต์เดิม ๆ แค่ 100~1000 แห่งเท่านั้น โดยสรุปเก็บข้อมูลไม่กี่ GB ก็อาจครอบคลุมได้ จึงยังคงเหลือประเด็นลิขสิทธิ์
  • สนใจว่าในบรรดา Ollama, LMStudio และ llama.cpp ใครเป็นตัวเลือกหลักบ้าง ทวีตของ ggerganov
  • สงสัยว่าเซ็ต iogpu.wired_limit_mb อย่างไร ค่าเริ่มต้นทำให้ GPU core ใช้ RAM ได้แค่ประมาณ 70% หรือราว 90GB เท่านั้น ถ้าจะใช้เพิ่มกว่านั้นต้องปรับค่า
  • ผมทำบนโปรเซสเซอร์ M2 Max ได้โทเคนมากกว่า 60 ต่อวินาทีสำหรับการคุยสั้น ๆ แต่เมื่อบทสนทนายาวขึ้นมันตกลงมาที่ 30 ต่อวินาที ผมสงสัยว่าปัจจัยที่ทำให้ช้าลงมาจากอะไร ไม่คิดว่าเป็นปัญหาเรื่องความร้อน
  • คิดว่าเป็นความต่างระหว่าง compute-bound prefill (ช่วงที่อัตราส่วน bandwidth/คอมพิวต์ของ CPU สูง) กับ decode แม้ context จะ 10k ก็ยังไม่ถึง 0.5 วินาทีถึงโทเคนตัวแรก

• หลายวิศวกรรัน vLLM, SGLang, TensorRT-LLM ควบคู่กันไป ตอนนี้ TensorRT-LLM ได้ยินกันว่าเร็วสุด แต่โดยปกติเป็นตัวที่ตั้งค่ายากที่สุด รองรับสถาปัตยกรรมใหม่ ๆ ไม่ค่อยทัน และต้องคอมไพล์โมเดลตรงบนสแต็กฮาร์ดแวร์-ไดรเวอร์-ไลบรารีที่ตรงกับ production เลยใช้เวลามาก มัลติโมดัลช่วงหนึ่งแทบเป็นไปไม่ได้ และโมเดลมัลติโมดัลตัวอย่างของ LLaMA เองก็ยังไม่ทำงานอย่างถูกต้อง ในมุมมองคุ้มค่าหรือไม่ยังน่าสงสัย อย่างเช่นถ้ารัน GPT-OSS-120B บน H100 ด้วย vLLM มันทำงานได้ดีมากและคงที่ที่ 130~140 t/s จากชื่อดูเหมือน GPU ตัวเดียวจะได้ 500 t/s แต่จริง ๆ แล้วเป็น tensor parallel setup การมีแพ็กเกจ TensorRT-LLM แยกไว้ให้ gpt-oss ก็รู้สึกแปลก ๆ สักหน่อย และตัว TRT-LLM เองก็เป็นเครื่องมือที่ค่อนข้างหงุดหงิดมาก

  • ลองใช้ TRT-LLM จากมุมมอง DX ก็มีความท้าทายเยอะ ตอนทำมัลติโมดัลก็ยังต้องใช้ vLLM อยู่มาก แต่สำหรับทราฟฟิกปริมาณมากและ latency ต่ำแบบที่เรารัน production อยู่ ใน benchmark TRT-LLM ทำได้ดีเสมอ จึงลงทุนกับ tooling ส่วนนี้ค่อนข้างมาก

• GPT-OSS 20B ติดตั้งง่ายมาก ขอบคุณ Llama ที่ช่วยให้รันบน Mac ได้ใน 5 นาที ถ้ามี CPU พอ ก็รัน 120B ได้ไม่ยาก ที่บ้านเพียงโหลดไฟล์ GGUF ลงเซิร์ฟเวอร์ inference ของ LLM, git pull, แล้ว rebuild llama-server ก็จบ ได้ 40 t/s โดยไม่แตะตั้งค่า และ 50 t/s เมื่อจูนเล็กน้อย น่าเสียดายว่า 120B ตอนนี้มีโมเดลที่ดีกว่าออกมาแล้วหลายตัว จึงไม่จำเป็นต้องรันเสียมากนัก งานของ ggerganov และทีม llama.cpp ที่ทำให้ LLM ใช้ได้ในเครื่องคอมพิวเตอร์ส่วนบุคคลได้จริง ๆ ถือว่าทำได้ยอดเยี่ยม

  • หลายคนชอบพูดว่าตั้งค่า LLM ยุ่งยาก พอแค่ให้ LLM ช่วยเซ็ตให้ไม่ได้ล่ะ? ถ้าทำสิ่งพื้นฐานแบบนี้ไม่ไหว โมเดล LLM มีความหมายอะไรอยู่
  • ผมลองเมื่อวาน และผลทุก session ล้วนให้ข้อมูลที่ไม่ตรงความจริง ความเร็วและความสะดวกใช้ง่ายดี แต่ถ้าต้องแลกมาด้วยความแม่นยำก็ไม่คุ้มค่า
  • ถ้ามีหน่วยความจำเพียงพอ 120B ก็รันได้ง่ายมาก

• จากที่อ่านมานี้ ผมได้รู้ว่าเพื่อให้โมเดลทำงานดีจริง ๆ ต้องการการ preprocessing และ tuning ปริมาณมาก ซึ่งผมไม่เคยรู้มาก่อน คิดว่าเฉพาะดีฟอลต์ค่านั้นพอ

  • ผมคิดว่าบริษัทใหญ่ ๆ ควรร่วมมือกับนักพัฒนาของ inference engine ยอดนิยมก่อนปล่อย LLM ของตัวเองเพื่อให้โมเดลได้รับการรองรับ โดยที่ตอนนี้ทุกอย่างยังเป็น experimental อยู่ แต่พวกเขาพยายามมากมากในการช่วยให้นักพัฒนาสามารถนำ LLM ไปใช้งานบนฮาร์ดแวร์ราคาถูกได้

• ในแผน AI Action ของสหรัฐฯ ข้อ “ส่งเสริม AI แบบโอเพ่นซอร์สและ open-weight” อยู่ถัดจากข้อ “ให้ frontier AI ปกป้องเสรีภาพในการแสดงความคิดเห็นและคุณค่าของสหรัฐฯ” ทันที ทั้งที่ความสัมพันธ์ไม่ค่อยสมเหตุสมผล แต่การอ่าน OSS model ของ OpenAI ในจังหวะนี้ก็รู้สึกไม่ค่อยสบายใจเหมือนกัน อย่างไรก็ตาม ผมชอบที่ผู้พัฒนาโมเดล OSS พูดถึงเรื่องฮาร์ดแวร์ เพราะสำหรับนักพัฒนาส่วนใหญ่ ฮาร์ดแวร์คืออุปสรรคเข้าถึงที่สำคัญ การได้อ่านเรื่องนี้ทำให้ยินดี

  • ข้อ “ให้ frontier AI ปกป้องเสรีภาพและคุณค่าของสหรัฐฯ” ก็ถูกพูดถึงด้วย ช่วงนี้ผมยังกำลังจัดเรียงความคิดของตัวเองอยู่ ขอเวลาหน่อยนะ โมเดล AI ย่อมมี worldview ของตัวเอง และผมก็ยังชอบ worldview แบบตะวันตกมากกว่า ซึ่งมีหลักฐานมากมายว่าสร้างสังคมที่ดีกว่าได้ อย่างน้อยโมเดลควรมีการบันทึก worldview ของตนเองไว้อย่างชัดเจน และตั้งให้สอดคล้องกัน เพื่อไม่ให้ผู้ใช้ถูกชี้นำให้เปลี่ยนวิธีคิดแบบ social engineering แบบแอบแฝง

• มีคนรู้จักเว็บไซต์ที่บอกได้ชัด ๆ ว่า LLM ตัวไหนทำงานได้กับ OS อะไรและ GPU อะไรบ้างหรือไม่ โดยที่การคาดคำนวณ VRAM ที่น่าเชื่อถือที่สุดที่เคยเจอคือ จำนวนพารามิเตอร์ × (Precision/8) × 1.2 (อ้างอิง)

  • ผมเคยพยายามทำ calculator แบบนี้ดูบ้าง แต่ในโลกจริงตัวแปรเยอะมาก (เช่น concurrent traffic) โดยรวมแล้วสูตรนี้ก็ตั้งได้พอสมควร แต่ถ้า traffic พร้อมกันมาก ควรเผื่อคูณ 2 เท่าเพื่อความปลอดภัย
  • ใน huggingface มีการป้อนสเปกฮาร์ดแวร์/ซอฟต์แวร์ และจะมีการแสดงว่าโมเดลแต่ละอันใช้ได้หรือไม่ในหน้านั้น ๆ ตั้งค่า Hugging Face
  • อินเทอร์เน็ตผมเร็วพอ จึงดาวน์โหลดไฟล์น้ำหนักมาและรันด้วย runner ต่าง ๆ (llama.cpp, LM Studio, vLLM, SGLang ฯลฯ) โดยตรงเร็วที่สุด ตัวแปรจาก runner/implementation/hardware เยอะมากจนเครื่องคำนวณใดก็ตามไม่เคยตรงกับประสบการณ์จริงเป๊ะ ๆ เลย ต้องลองรันจริง ๆ เท่านั้น
  • ขอบคุณความเห็นของทุกคน หากการคาดคำนวณยาก ก็อาจลองทำ DB site เพื่อให้ชุมชนทดลองและแชร์ข้อมูลต่อกัน ตั้งแต่ runner, hardware, model, parameter, quantization, สถานะใช้งาน และตัวชี้วัดเช่น tokens/s เมื่อแยกตามคอมโบฮาร์ดแวร์/runner แล้วดึงมาใช้งานได้ทันที จะคุ้มค่ามาก

• ผมอยากจะบอกว่าการหาเลขที่ชัดเจนอย่างขนาด array จริงของ GPT-OSS-120B นั้นยากกว่าที่คิด ถ้าภาษาเป็น static typed ก็น่าจะมองขนาด array ได้ง่าย แต่ผมอยากรู้ว่าข้อมูลจริง (ไม่ใช่เฉพาะน้ำหนัก) ไหลผ่านอย่างไร และ output stream กว้างขนาดไหน กำลังค้นหาใน repo GitHub ของ gpt-oss เพื่อดูว่าบน gigabit Ethernet อัตราแบนด์วิธการส่งออกโทเคนสูงสุดเป็นเท่าไร แต่ไม่ค่อยพบข้อมูล

  • อยากรู้ว่ามีแอปใดที่ทำ stream logits สำหรับโทเคนต่อเนื่องทั้งหมด (พร้อมสุ่มตัวอย่างโทเคนตามข้อกำหนด) โดยนึกถึงว่าปกติต้องมีการปรับแต่ง logits และการคืนค่าโทเคนก่อน sampling เพื่อให้ไวยากรณ์ถูกต้องก่อนจึงจะนำไปใช้ inference ต่อได้
  • ดูที่ config ของ Hugging Face จะเห็นว่ามี 2,880 ค่า (เป็นผลคูณกับ dtype)

• GPT-OSS รันเร็วขึ้นบนชิป Blackwell ด้วยการรองรับ fp4 ตอนนี้ผมกำลังพัฒนา training/inference engine ด้วย Rust และเพิ่มการรองรับ fp8, fp4 ให้กับ cudarc และ candle ผ่าน PRs (cudarc PR, candle PR) เพื่อรองรับโมเดลเหล่านี้ใน engine ของ Mixlayer

  • เป็นผู้ใช้ RTX Pro 6000 และอยากรู้ว่าขณะนี้รัน inference gpt-oss-120b ได้หรือยัง ตามลิงก์ PR เหล่านี้ดูเหมือน merge แล้ว แต่ยังไม่แน่ใจว่าใช้งานได้จริงไหม