GPU ขนาดใหญ่ไม่จำเป็นต้องใช้ PC ขนาดใหญ่

 (jeffgeerling.com)
9 คะแนน โดย GN⁺ 2025-12-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การทดลองรัน AMD, Intel, Nvidia GPU บน Raspberry Pi 5 และเปรียบเทียบกับเดสก์ท็อป PC พบว่าหลายกรณีมีการสูญเสียประสิทธิภาพเพียง 2~5% เท่านั้น
  • ทดสอบ 4 ด้าน ได้แก่ Jellyfin transcoding, GravityMark rendering, LLM/AI inference, และ การจัดชุด multi-GPU เพื่อวัดประสิทธิภาพและความคุ้มค่าต่อราคา
  • ในกรณีที่เชื่อมต่อ Nvidia RTX A5000 4 ใบ พบว่า ต่างจาก Intel server ไม่เกิน 2% โดย PCIe switch ที่ช่วยให้แชร์หน่วยความจำระหว่าง GPU มีบทบาทสำคัญ
  • ต้นทุนรวมของ ระบบ Raspberry Pi eGPU อยู่ที่ประมาณ $350~400 ขณะที่ PC อยู่ที่ $1500~2000 และการใช้พลังงานก็ต่ำกว่ามากด้วย (ขณะ idle 4~5W vs 30W)
  • เป็นกรณีพิสูจน์ว่า Raspberry Pi มีศักยภาพในฐานะแพลตฟอร์มทางเลือกแบบ พลังงานต่ำและต้นทุนต่ำ สำหรับใช้งาน GPU ขนาดใหญ่ได้อย่างมีประสิทธิภาพ

ภาพรวมการทดลอง

  • ตรวจสอบความเป็นไปได้ในการใช้งาน GPU แม้คำนึงถึงข้อจำกัดของ PCIe Gen 3 x1 bandwidth (8 GT/s) บน Raspberry Pi 5
    • เทียบกับ เดสก์ท็อป PC รุ่นใหม่ (PCIe Gen 5 x16, 512 GT/s)
  • หัวข้อทดสอบคือ media transcoding (Jellyfin), GPU rendering (GravityMark), ประสิทธิภาพ LLM/AI, และ การจัดชุด multi-GPU
  • ใช้ PCIe Gen 4 external switch และ 3-slot backplane ของ Dolphin ICS เพื่อทดลองรัน GPU 2 ใบพร้อมกัน

กรณี Raspberry Pi ที่เชื่อมต่อ GPU 4 ใบ

  • ผู้ใช้ GitHub ชื่อ mpsparrow เชื่อมต่อ Nvidia RTX A5000 GPU 4 ใบ เข้ากับ Pi เครื่องเดียว
    • ตอนรัน Llama 3 70B model มี ความต่างจาก Intel server ไม่เกิน 2% (11.83 vs 12 tokens/sec)
  • ด้วย PCIe switch จึงสามารถแชร์หน่วยความจำระหว่าง GPU ได้ และหลบข้อจำกัดด้าน bandwidth ของ Pi
  • แม้เป็นชุด GPU เดี่ยว ก็ยังพบว่าในบางงานให้ ประสิทธิภาพเทียบเท่าหรือดีกว่าเดสก์ท็อป

เปรียบเทียบต้นทุนและประสิทธิภาพ

  • ชุด Raspberry Pi eGPU: ประมาณ $350~400, ชุด Intel PC: ประมาณ $1500~2000
  • การใช้พลังงานขณะ idle: Pi 4~5W, PC 30W
  • เมื่อไม่นับราคา GPU, Pi เหนือกว่าในทั้ง ความคุ้มค่าด้านต้นทุนและประสิทธิภาพพลังงาน ภายใต้เงื่อนไขเดียวกัน

Jellyfin transcoding benchmark

  • เมื่อใช้ Nvidia 4070 Ti, PC เหนือกว่าใน raw throughput (2GB/s)
    • Pi อยู่ที่ PCIe 850MB/s, USB SSD 300MB/s
  • แต่ในการสตรีมมีเดีย H.264/H.265 นั้น Pi ก็ยังจัดการ 1080p·4K transcoding ได้อย่างลื่นไหล
    • รองรับ NVENC hardware encoding และ transcoding พร้อมกัน 2 งาน ได้อย่างเสถียร
  • AMD GPU มีปัญหาบางส่วนด้านความเสถียรในการ transcoding

การทดสอบเรนเดอร์ GravityMark

  • ทดสอบโดยเน้น AMD GPU เป็นหลัก โดย PC เร็วกว่านิดหน่อย แต่ความต่างเล็กมาก
  • เมื่อใช้ RX 460 พบว่า Pi ทำ ประสิทธิภาพต่อวัตต์ (performance/W) ได้สูงกว่า PC
  • กับ GPU รุ่นเก่าที่ใช้ bandwidth PCIe Gen 3 เท่ากัน Pi มี ข้อได้เปรียบเชิงสัมพัทธ์

เปรียบเทียบประสิทธิภาพ AI และ LLM

  • ในการทดสอบ AMD Radeon AI Pro R9700 (32GB VRAM) พบว่า ประสิทธิภาพต่ำกว่าคาด อาจมีสาเหตุจากปัญหา driver หรือการตั้งค่า BAR
  • เมื่อใช้ Nvidia RTX 3060 (12GB) กับ Llama 2 13B model พบว่า Pi เร็วกว่าพีซี
  • ผลการวัด ประสิทธิภาพเชิงพลังงาน ระบุว่า Pi มี throughput ต่อพลังงานดีกว่า PC
  • แม้แต่การทดสอบ RTX 4090 ก็ยังมี ความต่างไม่เกิน 5% สำหรับโมเดลขนาดใหญ่ (Qwen3 30B) และหลายกรณี Pi มีประสิทธิภาพดีกว่าในแง่ความคุ้มค่าพลังงาน
  • ทั้ง CUDA backend และ Vulkan backend ทำงานได้ตามปกติบน Pi

การทดลองชุด dual GPU

  • ใช้ Dolphin PCIe interconnect board และ MXH932 HBA
  • ปิด ACS เพื่อให้ GPU เข้าถึงหน่วยความจำกันโดยตรงได้
  • ในชุดที่ใช้ GPU คนละรุ่น (4070, A4000) นั้น ไม่รองรับ VRAM pooling ทำให้การเพิ่มประสิทธิภาพมีข้อจำกัด
  • หากใช้ GPU รุ่นเดียวกัน จะสามารถรันโมเดลที่ใหญ่ขึ้นได้ (Qwen3 30B เป็นต้น)
  • ชุด AMD RX 7900 XT + R9700 รันบางโมเดลไม่สำเร็จเพราะปัญหา driver
  • โดยรวม Intel PC ยังเร็วกว่า แต่ Pi ก็ยังรักษาประสิทธิภาพที่ใกล้เคียงได้ในโมเดลขนาดใหญ่

บทสรุป

  • ในด้าน ประสิทธิภาพสูงสุดและความสะดวกใช้งาน PC ยังเหนือกว่า
  • แต่สำหรับ เวิร์กโหลดที่เน้น GPU และสภาพแวดล้อมแบบ พลังงานต่ำ·ต้นทุนต่ำ นั้น Raspberry Pi เป็นทางเลือกที่ใช้งานได้จริง
  • ลดพลังงานขณะ idle ได้ 20~30W, และ SBC ที่ใช้ Rockchip·Qualcomm อาจให้ทั้งประสิทธิภาพและ I/O bandwidth สูงกว่า
  • จุดประสงค์ของการทดลองคือ เรียนรู้ข้อจำกัดของ Pi และโครงสร้างของ GPU computing และในกระบวนการนั้นก็ได้ยืนยัน ศักยภาพของระบบขนาดเล็ก

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

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

 
GN⁺ 2025-12-21
ความเห็นจาก Hacker News

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

    • ผมกำลังทำเว็บไซต์แบบคราวด์ซอร์สเพื่อรวบรวม ชุดฮาร์ดแวร์ที่เหมาะที่สุด สำหรับ LLM แบบโลคัล
      เว็บคือ inferbench.com, ซอร์สโค้ดอยู่ใน ที่เก็บ GitHub
    • ตอนนี้ยังยากที่จะได้ประสิทธิภาพที่มีนัยสำคัญจากอุปกรณ์ PCIe เดี่ยวตัวเดียว
      ผมมองว่า GPU ควรมี RAM อย่างน้อย 128GB
      ประสิทธิภาพ CPU ไม่จำเป็นต้องสูงมาก แต่ต้องรองรับ PCIe lanes หลายเลน ดังนั้น CPU เซิร์ฟเวอร์สเปกไม่สูงอย่าง AMD EPYC จึงเหมาะ
    • ไม่ได้คิดจะใช้ Apple Silicon อย่าง M4 Max หรือ M3 Ultra บ้างหรือ?
      มันค่อนข้างเหมาะกับ LLM ขนาดกลาง
    • ระบบที่คุณพูดถึงนั้น ในทางปฏิบัติ DGX Spark ก็ทำหน้าที่นั้นอยู่แล้ว

  • ผมไม่เข้าใจว่าทำไมถึงบอกว่าส่วนของมัลติ GPU น่าประหลาดใจ
    เฟรมเวิร์ก LLM ส่วนใหญ่ (เช่น llama.cpp) แบ่งโมเดลตามเลเยอร์ ทำให้เกิดการพึ่งพากันแบบลำดับ ดังนั้นถึงจะใช้หลาย GPU ก็ไม่ได้ทำงานแบบขนานจริง
    GPU บางตัวอาจเร็วกว่าในงานประมวลผลพรอมป์ต์ ขณะที่อีกบางตัวเร็วกว่าในงานสร้างโทเคน ดังนั้นการผสม Radeon กับ NVIDIA บางทีก็ได้ผล
    การเพิ่มประสิทธิภาพจริง ๆ ทำได้ในแบ็กเอนด์แบบ tensor parallel
    วิธีนี้คือการแบ่งโครงข่ายประสาทตามทิศทางการไหลของข้อมูล จึงต้องอาศัยการเชื่อมต่อระหว่าง GPU ที่ดี (PCIe x16, NVlink, Infinity Fabric ฯลฯ)
    ถ้าไม่มี สิ่งที่เห็นอาจเป็นการใช้ GPU ที่ขึ้น ๆ ลง ๆ ไม่สม่ำเสมอ
    วิธีแบ่ง LLM เพื่อให้รันหลายงานพร้อมกันได้ เช่น แยกบทบาทเป็น “ผู้จัดการ” และ “วิศวกร” ในรูปแบบ สถาปัตยกรรมเอเจนต์ น่าสนใจดี

    • ใช่ นั่นแหละคือแนวคิดของ ระบบเอเจนต์
      โมเดลผู้จัดการจะสร้างพรอมป์ต์ แล้วโมเดลลูกจะทำงานแบบขนานก่อนส่งผลลัพธ์กลับมา
    • ที่บอกว่าขนาดการส่งข้อมูลระหว่างเลเยอร์อยู่ในระดับ กิโลไบต์ นั้นเกินจริง
      ในความเป็นจริงมันขยายไปถึงระดับ เมกะไบต์ ตามความยาวซีเควนซ์
      เช่น ถ้า hidden state ของ Qwen3 30B มีขนาด 5120 ก็จะเท่ากับ 5120 ไบต์ต่อโทเคนเมื่อควอนไทซ์ 8 บิต
      แค่เกิน 200 โทเคนก็เป็นระดับ MB แล้ว
      แม้แบนด์วิดท์ PCIe x1 (ประมาณ 2GB/s) จะเพียงพอ แต่ latency อาจเป็นปัญหาใหญ่กว่า

  • ดีใจมากที่มีคนช่วยลองการทดลองแบบนี้
    ผมเองก็เคยใช้ eGPU กับโน้ตบุ๊กเครื่องสำรอง แล้วคิดว่า “แบบนี้ใช้กับ Raspberry Pi ได้ไหมนะ?”

  • น่าจะดู ประสิทธิภาพการเล่นเกม ด้วย
    แต่ก็หายากที่จะหาเกม AAA ที่รองรับ ARM และการบังคับใช้ FEX เพื่ออีมูเลต x86 ก็คงไม่ยุติธรรม

    • ประเด็นน่าจะอยู่ที่การหาเกมที่ไม่ติดคอขวดที่ CPU

  • ตอนใช้ constrained decoding (อิงตาม JSON schema) การใช้ CPU ขึ้นไปถึง 100%
    ผมก็เห็นอาการเดียวกันในอินสแตนซ์ vLLM ของตัวเอง

  • PCIe 3.0 ให้ความเร็วประมาณ 1GB/s ต่อ 1 เลน ซึ่งเทียบได้กับ 10Gb Ethernet
    อนาคตอาจมีวันที่ GPU ทำงานได้อย่างอิสระโดยไม่ต้องมีโฮสต์ซิสเต็มก็ได้
    ก่อนหน้านี้ก็มีตัวอย่างอย่าง Radeon Pro SSG ที่ติด SSD เข้ากับ GPU
    และอาจใช้แค่ชิป RISC-V ขนาดเล็กหรือคอนโทรลเลอร์ระดับ Raspberry Pi ก็พอ
    บทความที่เกี่ยวข้อง: TechPowerUp
    โครงสร้างที่ GPU เชื่อมต่อเข้ากับ network switch โดยตรงและสื่อสารผ่าน 400Gbe หรือ CXL-based communication นั้นดูเป็นไปได้จริง
    อีกทั้งเทคโนโลยีแฟลชยุคถัดไปอย่าง High Bandwidth Flash ก็อาจมีโอกาสแทนที่ DRAM ได้
    บทความที่เกี่ยวข้อง: ServeTheHome, Tom’s Hardware

  • ข้อมูลพวกนี้ทำให้ผมกลับมาคิดใหม่เรื่อง สเปกพีซีหลัก ของตัวเอง
    ดูเหมือนมินิพีซีราคา 300 ดอลลาร์ที่กินไฟไม่เกิน 20W ก็น่าจะพอแล้ว
    ใช้ท่องเว็บ ดูวิดีโอ เล่นเกมเบา ๆ ได้สบาย
    งานหนักก็รีโมตเข้าเวิร์กสเตชันเอา

    • ผมกำลังทดลองชุด Proxmox VM + eGPU อยู่
      แค่ 1 vCPU กับ 4GB RAM ก็พอสำหรับท่องเว็บและโปรเจกต์งานอดิเรกแล้ว
      ดูเหมือนผู้ผลิตฮาร์ดแวร์จะ โฆษณาเกินจริง ว่า “มืออาชีพต้องใช้โน้ตบุ๊กแรง ๆ”
    • พอเปลี่ยนจาก Ryzen mini PC 8 คอร์ไปเป็นเดสก์ท็อป 8 คอร์ ก็รู้สึกว่า ความเร็วในการรัน unit test ดีขึ้นมาก
      ความต่างของ TDP ส่งผลต่อประสิทธิภาพอย่างชัดเจน
    • ผมก็ใช้ Beelink mini PC เหมือนกัน โต๊ะทำงานดูเรียบร้อยขึ้นมาก
      และพอเอาเครื่องแรง ๆ ไปไว้ในพื้นที่เก็บเสียง ก็สบายขึ้นเยอะ

  • ผมสงสัยว่าทำไมสถาปัตยกรรม PCI/CPU แบบนี้ยังจำเป็นอยู่
    แนวทางที่ถูกน่าจะเป็นแบบ Apple และ NVIDIA ที่เอา CPU กับ MPP มาไว้ในแพ็กเกจเดียวกัน

    • วิธีนั้นได้เปรียบสำหรับ งานที่ไวต่อ latency แต่
      สำหรับงานคำนวณขนาดใหญ่อย่าง AI หรือ HPC อาจไม่ได้ต่างกันมากนัก