HN เปิดตัว: การเชื่อมต่อ GPU เสมือนผ่าน TCP

 (thundercompute.com)
2 คะแนน โดย GN⁺ 2024-08-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GPU ยังไม่ถูกทำให้เป็นทรัพยากรที่ มีอยู่อย่างอุดมสมบูรณ์ ผ่านการทำ virtualize เหมือน CPU, สตอเรจ, ระบบเครือข่าย และหน่วยความจำ และ Thunder Compute ต้องการแก้ปัญหานี้ในระดับระบบ
  • จุดเน้นของการเพิ่มอุปทานไม่ได้อยู่แค่การผลิตชิปให้มากขึ้น แต่ยังอยู่ที่ การใช้ประโยชน์ผ่านซอฟต์แวร์ เพื่อให้ใช้ GPU ที่ติดตั้งไปแล้วได้ดียิ่งขึ้น
  • ขณะที่การปรับให้เหมาะสมแบบเดิมยังอยู่ใน ระดับ workload เช่น การ batch งาน inference หรือการจัดคิวงาน training การทำ GPU virtualization มุ่งเป้าไปยังพื้นที่ระดับระบบที่ยังได้รับความสนใจค่อนข้างน้อย
  • สามารถใช้ NVIDIA H100 ได้ตั้งแต่ $1.38 ต่อชั่วโมง ผ่าน VS Code, CLI และเบราว์เซอร์ โดยชูจุดขายว่าประหยัดกว่า AWS 80%, ไม่มีสัญญาผูกมัด, ไม่มีค่า egress และมีสตอเรจที่ขยายได้
  • ได้สร้างต้นแบบงานวิจัยในสถานะ stealth เป็นเวลา 4 ปี และต้องการเผยแพร่การปรับปรุง ความจุ GPU ของศูนย์ข้อมูลผ่านคลาวด์ของตนเองและพาร์ตเนอร์องค์กร

ปรับปรุงอัตราการใช้งานต่ำด้วย GPU virtualization

  • Thunder Compute มองว่าทรัพยากรหายากหลายอย่างในคอมพิวติ้งสุดท้ายก็กลายเป็นสิ่งที่มีอยู่อย่างอุดมสมบูรณ์ แต่ GPU ยังไม่ได้ผ่านการเปลี่ยนผ่านแบบเดียวกัน
  • วิธีทำให้ GPU มีอยู่อย่างอุดมสมบูรณ์ไม่ได้ขึ้นอยู่กับการผลิตชิปเพิ่มเท่านั้น แต่ยังขึ้นอยู่กับ ซอฟต์แวร์ ที่ช่วยให้ใช้ชิปที่ติดตั้งไปแล้วได้ดียิ่งขึ้น
  • ปัจจุบัน GPU มักถูกใช้งานไม่เต็มที่ และวิธีแก้ปัญหาเดิมส่วนใหญ่เน้นไปที่ระดับ workload
    • batch processing คำขอ inference
    • จัดคิว งาน training ในหลาย fleet ของเซิร์ฟเวอร์
  • CPU, สตอเรจ, ระบบเครือข่าย และหน่วยความจำมีการใช้ virtualization อย่างแพร่หลายแล้ว แต่ GPU ยังไม่มี virtualization ในระดับเดียวกัน
  • การจัดการช่องว่างนี้ในระดับระบบคือแนวทางหลักของ Thunder Compute

แนวทางผลิตภัณฑ์และแผนการเผยแพร่

  • Thunder Compute เป็น system lab ที่มีจุดเน้นเชิงพาณิชย์ และต้องการนำงานวิจัย GPU virtualization ล่าสุดมาใช้ในสภาพแวดล้อม production
  • บริษัทแนะนำว่าทีมประกอบด้วยผู้เชี่ยวชาญด้าน infrastructure และนักวิจัยระบบจาก Citadel Securities, Aquatic และ AWS
  • ได้สร้าง ต้นแบบงานวิจัย ในโหมด stealth เป็นเวลา 4 ปี และตอนนี้เผยแพร่ผลงานผ่านคลาวด์ของตนเองและพาร์ตเนอร์องค์กร
  • ตามคำอธิบายผลิตภัณฑ์ NVIDIA H100 ใช้งานได้ตั้งแต่ $1.38 ต่อชั่วโมง
    • เข้าถึงได้จาก VS Code, CLI และเบราว์เซอร์
    • ชูจุดขายว่าประหยัดกว่า AWS 80%
    • ไม่มีสัญญาผูกมัด, ไม่มีค่า egress และมีสตอเรจที่ขยายได้
  • เป้าหมายคือการปรับปรุงความจุ GPU ของศูนย์ข้อมูลแบบเป็นขั้นเป็นตอน

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

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

 
GN⁺ 2024-08-10
ความคิดเห็นจาก Hacker News

  • น่าสนใจทีเดียว ก่อนหน้านี้เคยมีช่วงหนึ่งที่ผมต้องการ GPU-over-IP แค่สำหรับการทรานส์โค้ดวิดีโอเท่านั้น
    เซิร์ฟเวอร์โฮมแล็บของผมมี GPU AMD ที่ประสิทธิภาพไม่สูงนัก และทุกครั้งที่พยายามเข้ารหัสวิดีโอก็มักทำให้เคอร์เนลแครช ส่วนพีซีสำหรับเล่นเกมมี NVIDIA RTX 3080 อยู่ ผมเลยทำ https://github.com/steelbrain/ffmpeg-over-ip แล้วรันเซิร์ฟเวอร์บนเครื่อง Windows และรันไคลเอนต์บนมีเดียเซิร์ฟเวอร์ (Plex, Emby, Jellyfin ฯลฯ) ผลคือทำงานได้สมบูรณ์แบบ

    • ถ้ายังไม่เคยโพสต์ใน Show HN ก็น่าลองพิจารณาดู
      https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
      https://news.ycombinator.com/showhn.html
      https://news.ycombinator.com/item?id=22336638
    • ตอนเห็นชื่อเรื่อง ผมคาดหวังอะไรประมาณนี้อยู่เหมือนกัน เลยเสียดายที่สิ่งที่ส่งมาจริง ๆ เป็น บริการคลาวด์แบบเสียเงิน ไม่ใช่เครื่องมืออเนกประสงค์ที่มีประโยชน์ และก็เหมือนเคย ของจริงอยู่ในคอมเมนต์
      ผมยังสงสัยด้วยว่านอกจากการเข้ารหัสวิดีโอแล้ว มีงานไหนที่เหมาะกับ GPU-over-network อีกไหม ถ้า latency เพิ่มขึ้น งาน machine learning หรืองานที่ใช้กราฟิกหนัก ๆ น่าจะลำบากหรือเปล่า
    • น่าสนใจ อยากรู้ว่ารองรับ การแปลงหลายไฟล์ ที่สร้างไฟล์แบ่งตามช่วงเวลาหลายไฟล์แบบ HLS ด้วยไหม

  • ถ้ามันทำงานที่ขอบเขตระหว่าง CPU/GPU ผมงงว่าจะไม่เกิด คอขวด I/O มหาศาลกับชุดข้อมูลที่ใส่ใน VRAM ไม่ได้หรือ
    ผมอาจเข้าใจวิธีทำงานผิดก็ได้ แต่ถ้ามันดัก I/O ของ GPU ก็เท่ากับว่าต้องสตรีมชุดข้อมูลทั้งหมดไปยังเครื่องระยะไกลทุก epoch ฟังดูสิ้นเปลืองมาก

    • คุณเข้าใจระบบถูกแล้ว เราได้ทำ optimization หลายอย่างเพื่อลด ต้นทุน I/O ให้ใช้งานได้จริง
      ดูประสิทธิภาพการ infer ของ BERT ได้ที่นี่: https://youtu.be/qsOBFQZtsFM?t=69
      การ train มี overhead มากกว่าการ infer และเรากำลังทำ optimization เพิ่มเติมเพื่อให้เข้าใกล้ประสิทธิภาพแบบ native

  • สำหรับคนที่สงสัยว่าจริง ๆ แล้วมันทำงานอย่างไร ดูเหมือนโครงสร้างคือฉีดไลบรารีเข้าไปในโปรเซส จากนั้น hook ฟังก์ชันเหล่านี้[1] แล้วส่งต่อไปยังบริการ
    [1] https://pastebin.com/raw/kCYmXr5A

    • อยากรู้ว่ารู้ได้อย่างไรว่าฟังก์ชันเหล่านี้ถูก hook ผมเดาว่าน่าจะมีแฟล็กของ ld/ldd ที่บอกว่าสัญลักษณ์ใดถูก bind ใหม่
      อีกอย่าง ผมเคยคิดว่าสัญลักษณ์จะถูก bind ใหม่ได้ต้องเป็น weak symbol แต่ NVIDIA คงไม่มีทาง expose weak symbol ดังนั้นสุดท้ายแล้วนี่แทบจะหมายความว่าเป็นวิธีแบบ LD_PRELOAD ใช่ไหม
    • ผมหวังว่าจะมีวิธีมหัศจรรย์ที่ส่งต่ออุปกรณ์ PCIe ทั้งตัวได้

  • น่าสนใจ แต่สิ่งที่ผมสนใจกว่าคือ self-hosting ผมมี GPU อยู่เยอะแล้ว บางตัวกำลังรันอยู่ บางตัวก็ว่างอยู่
    อยากรู้ว่ามีตัวเลือก self-hosting เพื่อให้ใช้ GPU ที่มีอยู่แล้วได้ไหม

    • ตอนนี้ยังไม่รองรับ self-hosting แต่ดูเหมือนเทคโนโลยีเดียวกันจะเหมาะกับกรณีนั้นมาก
      ข้อดีอย่างการจัดตารางงานอย่างมีประสิทธิภาพ การแชร์ GPU และความใช้ง่าย น่าจะใช้ได้กับสภาพแวดล้อม self-hosting เช่นกัน เราเปิดกว้างกับความเป็นไปได้นี้ในอนาคตมาก
    • ถ้าต้องการประสบการณ์ใช้งาน คล้าย PyTorch บน GPU ของตัวเอง ไม่ว่าจะเป็นเครื่องประจำที่หรือคลาวด์ ลองดู https://github.com/run-house/runhouse
    • ถ้าอยากใช้ GPU ของตัวเองหรือบัญชีคลาวด์ของตัวเอง แต่ยังต้องการประสบการณ์พัฒนาที่ดี ลองดู SkyPilot
    • คุณสามารถปล่อยเช่า GPU ของตัวเองบนคลาวด์ผ่านบริการอย่าง Akash Network และเช่า GPU ได้ที่ thundercompute.com ด้วย นี่ใกล้เคียงกับเส้นทางสำหรับผู้ดูแลระบบที่รันเหมือน self-hosting มาก

  • ผมไม่ค่อยเข้าใจ ในเมื่อเปิด GPU instance ที่ต้องการบน ECS เองได้อยู่แล้ว ทำไมต้องเปิด instance บน ECS เพื่อใช้ GPU ของพวกคุณจาก ECS ด้วย
    แยกอีกประเด็น ผมก็ไม่เห็นเหตุผลว่าทำไมถึงอยากใช้ Nitro ครึ่ง ๆ กลาง ๆ แทน Nitro จริง

    • ประเด็นดี มีข้อดีอยู่หลายอย่าง
      ถ้าคุณพัฒนางานที่ต้องใช้ GPU อยู่เรื่อย ๆ โดยปกติจะต้องจ่ายเงินตลอดเวลาที่ instance เปิดอยู่ทั้งหมด เมื่อใช้ Thunder คุณจ่ายเฉพาะตอนที่ใช้ GPU จริง ๆ เท่านั้น ตอนรันเฉพาะโค้ด CPU ก็ไม่มีค่าเวลา GPU ทางเลือกคือเปิดปิด instance ด้วยมือ ซึ่งอาจยุ่งยาก
      อีกอย่างคือสามารถขยายชนิดและจำนวน GPU ที่ใช้ได้ง่าย เช่น ถ้าพัฒนาอยู่บน instance T4 ราคาถูก แล้วอยากรันงาน train deep learning เต็มรูปแบบบน A100 8 ตัว ก็ไม่ต้องเปลี่ยน instance และตั้งค่าสภาพแวดล้อมใหม่ แค่รันคำสั่งเดียวแล้วก็รันบน GPU ที่แรงกว่าได้ทันที
    • จากมุมของระบบ มันดูโปร่งใสมากกว่า เช่น ถ้าคุณใช้แอป GUI ที่ต้องการการเร่งด้วย GPU (Matlab, SolidWorks, Blender) บน thin client ก็ทำได้โดยไม่ต้องตั้งค่า ECS
      คุณอาจพัฒนาโดยไม่มี GPU แล้วจู่ ๆ ต่อ GPU ตอนรัน simulation ได้ และน่าจะถูกกว่า AWS มาก โดยแก่นแล้วดูเหมือนกำลังแก้ปัญหาที่ Ray(https://www.ray.io/) แก้ แต่อยู่ในรูปแบบทั่วไปกว่า และอาจทำ การแชร์ GPU ที่ละเอียดขึ้นอย่าง GPU ครึ่งตัวได้ด้วย น่าตื่นเต้นมาก

  • เราสนใจเรื่องนี้มาก เลยตัดสินใจเปิด T4 instance ให้ใช้ฟรี อยากให้ลองใช้เองแล้วบอกความคิดเห็น

    • อยากรู้ว่าราคา A100 กับ H100 เป็นอย่างไร

  • เจ๋งดี อยากรู้ว่าทำให้ทำงานกับ MIG หรือ vGPU ได้ด้วยไหม

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

  • อยากรู้ว่าถ้าใช้งานจริงด้วย throughput ที่มีนัยสำคัญแล้วจะรู้สึกอย่างไร ใช้กับ การแคร็กแฮช ได้ไหม
    ทุกครั้งที่คิดถึง GPU เสมือนผ่านเครือข่าย ผมจะนึกถึง botnet โดยเฉพาะประโยคใน https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... ที่ว่า “Gosney ต้องโน้มน้าวศาสตราจารย์ Amnon Barak ผู้ร่วมก่อตั้ง Mosix ก่อนว่าเขา ‘ไม่ได้กำลังพยายามเปลี่ยนโลกให้เป็น botnet ขนาดยักษ์’”

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

  • วิศวกร SGI รุ่นแรก ๆ ที่พัฒนา glx ออกแบบไว้อย่างระมัดระวังมากให้ใช้กลไก X11 สำหรับการส่ง GPU ดังนั้นการส่งสตรีม GL ผ่านเครือข่ายไปเรนเดอร์บนการ์ดกราฟิกของผมจึงค่อนข้างง่าย
    ประมาณว่า “รันบนซูเปอร์คอมพิวเตอร์ท้ายทางเดิน แล้วเรนเดอร์บนเวิร์กสเตชัน” การพัฒนาไดรเวอร์ยุคหลังดูไม่ค่อยใส่ใจกับเรื่องนี้ ทำให้โดยทั่วไปตอนนี้ทำไม่ได้แล้ว ผมก็ไม่รู้ว่าจริง ๆ แล้วมันมีประโยชน์แค่ไหน เพราะโดยปกติถ้ามีการ์ดกราฟิกดี CPU ก็มักดีด้วย แต่ก็สนุกดีสำหรับเอาไว้เล่น และมีเสน่ห์แปลก ๆ ที่โปรแกรมซึ่งรันอยู่ในห้องเครื่องได้กราฟิกแบบเร่งด้วยฮาร์ดแวร์ ครั้งหนึ่งผมเคยทำให้ glquake รันด้วยวิธีนี้สำเร็จ

  • แค่ที่สิ่งนี้เป็นไปได้ก็น่าประทับใจแล้ว แต่สงสัยว่าจะเกิดอะไรขึ้นเมื่อการเชื่อมต่อเครือข่ายหลุดหรือ ไม่ได้เสถียร 100%
    จากประสบการณ์ ไดรเวอร์มักตอบสนองได้ไม่ดีนักแม้ GPU ในเครื่องจะทำงานแปลกไปเพียงเล็กน้อย