การตั้งค่าโครงสร้างพื้นฐานและสคริปต์โอเพนซอร์สสำหรับฝึกโมเดล 70B บน bare metal

 (imbue.com)
1 คะแนน โดย GN⁺ 2024-06-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Imbue ฝึก โมเดลพารามิเตอร์ 70B ตั้งแต่ต้นบนโครงสร้างพื้นฐาน bare metal ของตนเองด้วยทีมขนาดเล็ก และเผยแพร่ขั้นตอนการปฏิบัติงานกับสคริปต์ตั้งแต่การสร้างคลัสเตอร์ไปจนถึงการกู้คืนเมื่อเกิดความขัดข้อง
  • คลัสเตอร์ประกอบด้วย H100 GPU 4,088 ตัว และเซิร์ฟเวอร์ GPU 511 เครื่อง โดยแต่ละเซิร์ฟเวอร์มี GPU 8 ตัวเข้าร่วมการฝึกแบบ synchronous ขนาดใหญ่ผ่าน InfiniBand
  • การสร้างจริงเป็นกระบวนการทำซ้ำระหว่างการ provision เครื่องแต่ละเครื่อง, การปรับปรุง InfiniBand fabric, การตรวจสุขภาพโฮสต์, การวินิจฉัยข้อผิดพลาดในการฝึก และการปรับปรุง automation โดยต้องจัดการกับเครื่องที่บูตไม่สำเร็จราว 10% และคำเตือนพอร์ตจำนวนมาก
  • เครื่องมือที่เผยแพร่ประกอบด้วยการตรวจสุขภาพโฮสต์, แพตช์ logging ของ NCCL, การทดสอบ stress ของ GPU, การทดสอบเครือข่าย NVLink·InfiniBand, parser สำหรับ event log ของ UFM และสคริปต์สร้าง workload burn-in สำหรับ InfiniBand
  • ในการฝึก LLM ขนาดใหญ่ โฮสต์หรือลิงก์ที่ไม่เสถียรเพียงรายการเดียวอาจทำให้การรันทั้งหมดช้าลงได้ ดังนั้น การตรวจสุขภาพอัตโนมัติ·การแยกความขัดข้อง·การรีสตาร์ต·การปิดใช้งานพอร์ต จึงเป็นหัวใจของการปฏิบัติการอย่างต่อเนื่อง

การสร้างคลัสเตอร์เพื่อฝึกโมเดล 70B ของตนเอง

  • Imbue ฝึก โมเดลพารามิเตอร์ 70B ตั้งแต่ต้นบนโครงสร้างพื้นฐานของตนเองเป็นเวลาหลายเดือน และโมเดลนี้ทำคะแนนเหนือกว่า zero-shot GPT-4o ในงานที่เกี่ยวข้องกับการ reasoning
  • ขอบเขตที่เผยแพร่คือ ขั้นตอนโครงสร้างพื้นฐานแบบ end-to-end ตั้งแต่การบูตคลัสเตอร์ครั้งแรก การติดตั้ง OS ไปจนถึงการกู้คืนข้อผิดพลาดระหว่างการฝึกโดยอัตโนมัติ
  • เครื่องมือโครงสร้างพื้นฐานที่เผยแพร่พร้อมกันมีดังนี้
    • Host-level health checks: สคริปต์สำหรับตรวจว่าโฮสต์พร้อมนำไปใช้ฝึกได้โดยไม่มีข้อผิดพลาดที่ทราบหรือไม่
    • แพตช์ NCCL: ปรับปรุงให้บันทึก log มากขึ้นเมื่อเกิดข้อผิดพลาดและสถานการณ์ค้าง
    • GPU stress test: ตรวจสอบว่า GPU สามารถจัดสรร tensor ขนาดใหญ่และทำการดำเนินการมาตรฐานได้หรือไม่
    • Networking tests: ตรวจสอบการสื่อสาร NVLink ระหว่าง GPU ในเครื่องเดียวกัน และการสื่อสาร InfiniBand ระหว่าง GPU ต่างเครื่อง
    • UFM event log parser: parse event log ของ Unified Fabric Manager เพื่อตัดสินใจว่าจะปิดใช้งานพอร์ตเครือข่ายใด
    • InfiniBand burn-in workload generator: สร้าง workload burn-in ของ InfiniBand ที่ stress ลิงก์ทั้งหมดที่ใช้งานได้

โครงสร้างคลัสเตอร์และเครือข่าย

  • คลัสเตอร์หลักแบ่ง H100 GPU 4,088 ตัว ไว้ในเซิร์ฟเวอร์ GPU 511 เครื่อง โดยแต่ละเซิร์ฟเวอร์ติดตั้ง GPU 8 ตัว
  • เหตุผลที่มีเซิร์ฟเวอร์ GPU 511 เครื่องคือจำเป็นต้องสำรองการเชื่อมต่อบางส่วนไว้ให้โหนด Unified Fabric Manager(UFM) สำหรับจัดการเครือข่าย InfiniBand
  • GPU แต่ละตัวเชื่อมต่อโดยตรงกับการ์ด ConnectX-7 และสามารถรับส่งข้อมูลพร้อมกันที่ 400Gbps กับ GPU อื่นในเครือข่าย InfiniBand ผ่านการ์ด ConnectX-7 ของตัวเองได้
  • topology ของ InfiniBand เป็นโครงสร้างแบบ fully non-blocking ที่ทำให้ตามทฤษฎีแล้ว GPU ทุกตัวสามารถสื่อสารกับ GPU อื่นได้พร้อมกันด้วยความเร็วสูงสุด
    • สถาปัตยกรรมสวิตช์ InfiniBand 3 ระดับให้ throughput ของเครือข่ายทั้งหมด
    • การสื่อสารสำหรับการฝึกทำบน InfiniBand ไม่ใช่ Ethernet
  • Ethernet ใช้สำหรับ dataset, checkpoint และการถ่ายโอนข้อมูลอื่น ๆ
    • หากส่งการสื่อสารสำหรับการฝึกผ่าน Ethernet ข้อมูลต้องย้ายจาก GPU ไปยัง CPU แล้วออกผ่านการ์ด Ethernet 100Gbps จึงช้ากว่ามาก
    • การฝึกผ่าน Ethernet ด้วย RoCE ก็ทำได้ แต่ต้องมีงานเพิ่มเติมจำนวนมากทั้งฝั่งฮาร์ดแวร์และซอฟต์แวร์ และโดยทั่วไปมีความน่าเชื่อถือต่ำกว่า InfiniBand
  • เครือข่าย Ethernet สำหรับการจัดการแยกต่างหากใช้สำหรับเข้าถึง BIOS, power supply และคอนโทรลเลอร์อินเทอร์เฟซเครื่องระดับล่าง
    • หากไม่มีเครือข่ายจัดการนี้ จะต้องตั้งค่าเครื่องหลายร้อยเครื่องด้วยตนเองโดยใช้ USB drive, keyboard และ monitor
  • ในการฝึกสมรรถนะสูงขนาดใหญ่ InfiniBand, Ethernet, GPU และโหนดต้องทำงานเกือบสมบูรณ์แบบ
    • เพียงการเชื่อมต่อเดียวจากมากกว่า 12,000 รายการที่ไม่เสถียร ก็อาจทำให้การรันการฝึกทั้งหมดช้าลงได้

การ provision เครื่องแต่ละเครื่อง

  • หลังจากสร้างการเชื่อมต่อ Ethernet เข้ากับคลัสเตอร์ด้วยเครือข่ายจัดการเริ่มต้นแล้ว จึงได้ข้อมูลรับรองสำหรับเข้าถึง BMC(Baseboard Management Controller)
    • BMC คือ service processor ที่ใช้ monitor โฮสต์จากระยะไกล
    • ให้ API สำหรับสถานะฮาร์ดแวร์ การตั้งค่า BIOS และการจัดการพลังงาน
  • เซิร์ฟเวอร์เครื่องแรกติดตั้ง Ubuntu 22.04 แบบ manual ผ่าน iDRAC ซึ่งเป็น BMC ของ Dell
    • สามารถ mount ISO image จากคอมพิวเตอร์ local เพื่อบูตได้ และมีคอนโซลเสมือนผ่านเบราว์เซอร์
    • เป้าหมายคือทำให้การติดตั้งแบบ manual นี้เป็นการติดตั้งแบบ manual เพียงครั้งเดียวตลอดทั้งกระบวนการ

  • MAAS และการบูต PXE

    • หลังเตรียมเครื่องแรกแล้ว ได้ติดตั้ง Ubuntu MAAS(Metal-as-a-Service) เพื่อ provision เซิร์ฟเวอร์ที่เหลือ
    • ใช้การบูต PXE และเครื่องมือ iDRAC แบบอัตโนมัติสั่งให้แต่ละเครื่องบูตจากเครือข่าย
    • เซิร์ฟเวอร์รับ IP จาก MAAS ผ่าน DHCP ดาวน์โหลด kernel เริ่มต้น แล้วติดตั้ง OS แบบถาวรโดยอัตโนมัติแม้ local drive จะว่างอยู่ก็ตาม
    • ในทางปฏิบัติ การเชื่อม MAAS กับ BMC ไม่เสถียร จึงรวบรวม MAC address ของทุกเครื่องไว้ล่วงหน้าผ่าน iDRAC API
    • โดยรวมแล้ว MAAS เชื่อถือได้ตลอดกระบวนการฝึก แต่ช่วงแรกมีปัญหาเฉพาะด้านการตั้งค่า
      • ความต่างของ clock มากเกินไป ทำให้การตรวจสอบใบรับรอง HTTPS ล้มเหลวและ apt ติดตั้งไม่ได้
      • เซิร์ฟเวอร์ MAAS ทำหน้าที่พร้อมกันทั้ง DHCP, DNS, HTTP proxy, NTP, การจัดการการตั้งค่า cloud-init และฐานข้อมูลอ้างอิงสำหรับ MAC·IP·hostname·metadata ทำให้ติดตามสาเหตุได้ยาก

  • ความล้มเหลวในการบูตและ observability พื้นฐาน

    • เช่นเดียวกับการตั้งค่าคลัสเตอร์ GPU ขนาดใหญ่ทั่วไป เครื่องประมาณ 10% บูตไม่สำเร็จ โดยสาเหตุหลักคือปัญหาทางกายภาพของเซิร์ฟเวอร์
      • สาย Ethernet ไม่ได้เชื่อมต่อหรือเดินสายผิด
      • ปัญหาฮาร์ดแวร์ iDRAC
      • power supply เสีย
      • ไดรฟ์ NVMe เสีย
      • การเดินสายภายในขาดหาย
      • ตรวจไม่พบการ์ดเครือข่ายหรือ GPU
    • Imbue ทำ automation สำหรับตรวจปัญหาเหล่านี้ ส่งเครื่องบางส่วนให้ Dell ตรวจซ้ำ และเปิด ticket ที่จำเป็นให้เจ้าหน้าที่ data center
    • ด้วยการตั้งค่าโครงสร้างพื้นฐานด้วยตนเอง จึงสามารถใช้เครื่องที่ปกติได้ทันทีแม้ระหว่างรอการซ่อมแซม
    • เซิร์ฟเวอร์ทุกเครื่องติดตั้ง Docker, ไดรเวอร์ GPU ของ data center, Prometheus node exporter, NVIDIA DCGM exporter และ RAIDZ ZFS pool บนไดรฟ์ทั้งหมดที่ไม่ใช่ OS
    • ZFS ทำให้เครื่องยังคงทำงานได้แม้ไดรฟ์หนึ่งตัวหยุดทำงาน และด้วย transparent compression ช่วยลดพื้นที่จัดเก็บสำหรับ dataset ข้อความทั่วไปและ log ซ้ำ ๆ ได้อย่างมาก
    • เมื่อ install package ซอฟต์แวร์แบบขนานบน 400 โหนด เกิด คอขวดด้าน bandwidth
    • เริ่มมีการแจ้งเตือนอุณหภูมิสูงจากหลายองค์ประกอบในการติดตั้งที่ data center และปัญหาความร้อนช่วงแรกส่วนใหญ่บรรเทาลงได้ด้วยการอัปเดต firmware

  • ตรวจสอบการฝึก GPU แบบโหนดเดียว

    • ตรวจสอบว่าแต่ละเครื่องสามารถจัดการ workload GPU จริงได้อย่างอิสระหรือไม่
    • หลายเครื่องล้มเหลวในการฝึก GPU แบบโหนดเดียวด้วยปัญหาต่อไปนี้
      • ข้อผิดพลาดเกี่ยวกับ GPU ส่วนใหญ่แก้ได้ด้วยการถอดการ์ดออกแล้วเสียบกลับเข้า slot ใหม่
      • ใน log ของเซิร์ฟเวอร์ Ubuntu การเชื่อมต่อ PCIe แสดงเป็น limited width: x4 < x16
      • แม้หลังอัปเดต firmware ของ PCIe switch bus แล้ว ยังต้องเสียบสาย PCIe ภายในใหม่ในโฮสต์ประมาณหนึ่งในสี่ของคลัสเตอร์
      • มีไดรฟ์ NVMe ที่ไม่ได้ถูกระบุว่าเสีย แต่เมื่อเข้าถึงแล้วทำให้ทั้งเครื่อง lock
      • ลำดับ hard disk ใน Linux แสดงแบบสุ่ม ทำให้ MAAS ติดตั้ง OS ลงผิดไดรฟ์
      • การอ่านค่าอุณหภูมิผิดพลาดทำให้พัดลมหมุนที่ 100% ตลอดเวลา
      • CPU dynamic frequency scaling จำกัดคอร์ที่ active ไว้ที่ 2GHz
      • การใช้ GDR หรือ GPUDirect RDMA Peer Memory Client ล้มเหลว

การโปรวิชัน InfiniBand

  • InfiniBand มีหน่วยควบคุมเดียวสำหรับทั้งเครือข่ายด้วยการออกแบบแบบรวมศูนย์ และสามารถจัดการ network switch 320 ตัวเป็น fabric เดียวได้
  • งานแรกคือการระบุว่า switch ใดเชื่อมต่อกับเครื่องใด แล้วเทียบกับแผนผังสายเพื่อเปลี่ยนชื่อ switch ตามตำแหน่งทางกายภาพ

  • การออกแบบ fabric ที่ผิดพลาดและการเดินสายใหม่

    • ในช่วงแรก UFM ตรวจไม่พบ network switch ทั้ง 320 ตัว และไม่พบ host ที่ควรอยู่ใน fabric
    • เมื่อตรวจสอบกับพาร์ตเนอร์ดาต้าเซ็นเตอร์ พบว่า switch เปิดอยู่และมีการเดินสายแล้ว แต่ไม่ถูกตรวจพบ
    • เมื่อตรวจสอบรายการเดินสายเครือข่าย พบว่า upper fabric ไม่ได้เป็น fabric รวมหนึ่งเดียว แต่ประกอบด้วย เครือข่ายที่แยกจากกัน 8 เครือข่าย ซึ่งไม่มีเส้นทาง routing ร่วมกัน
    • หลังจากเดินสายใหม่ ได้เพิ่มการตรวจสอบเพื่อยืนยันว่าการเชื่อมต่อทางกายภาพทั้งหมดตรงกับการออกแบบใหม่

  • คำเตือนอุณหภูมิและข้อผิดพลาดของพอร์ต

    • หลังแก้ปัญหาการเดินสายทางกายภาพแล้ว UFM เชื่อมต่อกับ InfiniBand switch ทั้งหมดได้ แต่พอร์ตของ switch แทบทั้งหมดรายงานอุณหภูมิสูงเกินไป
    • แม้ก่อนมีการส่งข้อมูลจริง พอร์ตบางพอร์ตก็มีอุณหภูมิเกิน 70 องศาเซลเซียสแล้ว สาเหตุคือโครงสร้างที่ทำให้อากาศร้อนหมุนเวียนกลับไปด้านหน้าผ่านช่องว่างระหว่าง switch ใน networking rack
    • พอร์ตจำนวนมากมีอัตราข้อผิดพลาดสูง หรือเกิด link flapping คือสถานะสลับไปมาระหว่างปกติและเสีย ปัญหานี้จะปรากฏเฉพาะเมื่อมีการใช้งานพอร์ตจริง ทำให้ตรวจพบล่วงหน้าได้ยาก
    • แม้ fabric ทั้งหมดจะมีลิงก์ 10,000 รายการและมี redundancy สูง แต่เมื่อราว 10% ของ fabric เริ่มมีปัญหา ฟีเจอร์อย่าง adaptive routing ก็ไม่สามารถหลบเลี่ยงลิงก์ที่ขาด ๆ หาย ๆ อย่างไม่สม่ำเสมอได้เพียงพอ
    • พาร์ตเนอร์ดาต้าเซ็นเตอร์ทำความสะอาดและติดตั้งพอร์ตที่มีคำเตือนใหม่ ส่วน warning transceiver ที่เหลือซึ่งรอการเปลี่ยนถูกปิดใช้งาน
    • ในช่วงนี้ได้ทำ multi-node training ด้วยเครื่อง 100~200 เครื่อง เพื่อหาชุดย่อยของ InfiniBand ที่เสถียร

  • การ burn-in InfiniBand และ GPUDirect RDMA

    • เพื่อวินิจฉัยปัญหา InfiniBand ให้มีประสิทธิภาพมากขึ้น จึงสร้าง workload เฉพาะที่อัดข้อมูลให้มากที่สุดเท่าที่ทำได้พร้อมกันเข้าไปยังทุกพอร์ตของทั้ง fabric
    • วิธีนี้ต่างจากการรัน all-reduce ขนาดใหญ่หนึ่งงานทั่วทั้งคลัสเตอร์
      • เพราะ NCCL ปรับแต่งการสื่อสารภายในโหนดเดียวให้เหมาะกับเส้นทาง NVLink และ SXM socket
    • UFM ส่งการแจ้งเตือนว่ามีการส่งข้อมูลเกิน 97% ของความจุตามทฤษฎีในพอร์ตส่วนใหญ่ และ switch บางตัว crash ชั่วคราว
    • พอร์ตที่ยังรอดอยู่จนถึงสิ้นวันถือว่าแข็งแรงเพียงพอ ส่วนที่เหลือถูกปิดใช้งานหรือส่งต่อเป็นรายการซ่อมในภายหลัง
    • เปิดใช้งาน GPUDirect RDMA เพื่อให้ GPU สื่อสารได้โดยไม่มี overhead จาก CPU

  • ชุดเครื่องที่เสถียรและการบำรุงรักษา

    • จากประสบการณ์กับคลัสเตอร์ GPU ฮาร์ดแวร์รุ่นใหม่ ควรคาดว่าเครื่องประมาณ 3% จะเสีย ในแต่ละสัปดาห์
    • ไม่ใช่ว่าทุกเครื่องมีโอกาสเสีย 3% เท่ากัน แต่เครื่องบางตัวที่มีปัญหามากจะเสียซ้ำ ๆ ในหลายรูปแบบ
    • เมื่อมีเครื่องจำนวนมากอยู่ใน fabric เดียวกัน แทนที่จะคอยไล่ตามปัญหาเครื่องแบบสุ่มอยู่เรื่อย ๆ จะสามารถขยายชุดเครื่อง golden ที่ทราบว่าเสถียรได้
    • การบำรุงรักษา InfiniBand ส่วนใหญ่ประกอบด้วยการตอบสนองต่อคำเตือนจาก UFM, การเปลี่ยนสายเคเบิลและ transceiver, และการวินิจฉัย switch ที่มีข้อบกพร่อง
    • regression ขนาดใหญ่มักเกิดจากสองปัจจัย
      • การอัปเกรด firmware ที่ใช้กับเพียงครึ่งหนึ่งของคลัสเตอร์ทำให้สถานะ UFM เสียหาย จนต้อง restart UFM บน InfiniBand switch ทั้งหมด
      • เมื่อ restart GPU box จำนวนมากพร้อมกัน การอัปเดตสถานะ UFM จะถาโถมจนต้อง restart บริการ UFM

ระบบตรวจสุขภาพ host

  • Imbue พบความขัดข้องของเครื่องเดี่ยวหลากหลายแบบที่ทำให้การรัน training ล้มเหลวหรือช้าลง และเขียน health check เพื่อพิจารณาว่า host ใดมีสุขภาพดีพอสำหรับ training
  • โค้ดเผยแพร่ไว้ที่ cluster-health
  • check จำนวนมากเฉพาะเจาะจงกับ runtime environment ของ Imbue แต่เป้าหมายคือการมี entry point เดียวที่คืนค่า yes/no ว่าพร้อมสำหรับ training หรือไม่

  • health check แบบรวดเร็ว

    • GPU Health Check: ตรวจสอบจำนวน GPU, การเปิดใช้งาน ECC, ข้อผิดพลาด ECC, topology และข้อผิดพลาดของ NVLink
    • Disk Space Health Check: ตรวจสอบว่าอัตราการใช้ดิสก์ของ host ไม่เกิน 95%
    • Docker Health Check: ตรวจสอบว่ามีการรัน container ที่เชื่อมต่อ GPU หรือไม่ และตรวจสอบสิทธิ์ของ container สำหรับ monitoring และ profiling
    • Dmesg Health Check: ค้นหาข้อผิดพลาด Xid·SXid ของ NVIDIA GPU หรือ NVIDIA switch และตรวจสอบว่า line ใน dmesg log ถูกจัดประเภทอยู่ในรายการ log ที่คาดการณ์ได้หรือไม่
    • iDRAC Health Check: ตรวจสอบข้อผิดพลาด iDRAC ของเครื่อง Dell และเพิกเฉยต่อข้อความผิดพลาดที่ไม่ร้ายแรง
      • check นี้ไม่ใช่ส่วนที่จะเปิดเผยเป็นโอเพนซอร์ส
    • Disk Health Check: ตรวจสอบ zpool mount, การเชื่อมต่อ Docker, และดูว่า CPU ค้างเมื่อเข้าถึงดิสก์หรือไม่
    • InfiniBand Health Check: ตรวจสอบอัตราข้อผิดพลาด InfiniBand ที่เพิ่มขึ้นและ driver firmware ที่ล้าสมัย
    • Nvlink Health Check: ตรวจสอบข้อผิดพลาด NVLink ของเครื่อง
      • จากประสบการณ์ ไม่ได้ทำให้ training ล้มเหลว แต่อาจทำให้ช้าลงได้
    • GDR Health Check: ตรวจสอบว่า GDR ถูกเปิดใช้งานบนเครื่องหรือไม่
    • VBIOS Health Check: ตรวจสอบว่าเวอร์ชัน GPU VBIOS และ firmware ของ H100 baseboard เป็นเวอร์ชันล่าสุดหรือไม่
    • Flint Health Check: ใช้ flint และ hca_self_test ตรวจสอบเวอร์ชัน Mellanox OFED driver, card firmware, transceiver firmware และสถานะการคอมไพล์ของ NVIDIA driver
    • PSB Health Check: query อุปกรณ์ PCIe เพื่อตรวจสอบว่า connection speed และ width ระหว่าง GPU, PSB และ network card ตรงตามที่คาดไว้หรือไม่
      • เป็นสคริปต์ที่ Dell พัฒนา จึงยังไม่สามารถแชร์ได้ในตอนนี้

  • health check ที่ใช้เวลานานกว่า

    • initialize การคำนวณ matrix ด้วย PyTorch เพื่อวัด แบนด์วิดท์ NVLink, ความเร็วการคำนวณของ GPU และหน่วยความจำ
    • ตั้งค่า flag ของ GDR เพื่อทดสอบทั้ง InfiniBand และ NVLink
    • ใช้ ib_write_bw และ --use_cuda ส่งข้อมูลไปยัง IB card เพื่อวัดแบนด์วิดท์ของ PCIe และ InfiniBand card
    • รันประมาณ 15 นาทีเพื่อจับ InfiniBand link ที่ flapping
    • ตรวจสอบความเป็นไปได้ในการ initialize NCCL และดูว่ามีการค้างแบบสุ่มหรือไม่ด้วยการรันการวินิจฉัยแบบ multi-node
      • หากค้าง โค้ด NCCL ที่ fork ไว้จะทิ้ง log เพิ่มเติม
    • เนื่องจากการตรวจพบปัญหาอาจใช้เวลา 12~24 ชั่วโมง จึงมักรันกับ node ใหม่หรือเมื่อมีสถานการณ์ที่น่าสงสัย
    • ตรวจสอบเหตุการณ์ GPU clock throttling จาก DCGM exports แต่ยกเว้น gpu_idle และ power_cap ที่คาดไว้
    • multi-node training ที่ใช้ GPU, InfiniBand card, CPU และดิสก์ทั้งหมดพร้อมกันจะเผยให้เห็น power event ได้ดีที่สุด

การวินิจฉัยข้อผิดพลาดทั่วไประหว่างการฝึก

  • แครชทันทีหลังเริ่ม

    • การแครชทันทีหลังเริ่มเป็นข้อผิดพลาดที่รับมือได้ง่ายกว่า เพราะทำซ้ำและวนทดสอบได้ค่อนข้างง่าย
    • ขั้นแรกตรวจสอบว่าเวอร์ชันโค้ด การตั้งค่า และตัวแปรสภาพแวดล้อมถูกต้องหรือไม่
    • ชั้น abstraction ระหว่างกลาง เช่น การแคช Docker image หรือการตั้งค่า secrets ที่ไม่โปร่งใส อาจทำให้การหาสาเหตุไม่ชัดเจน
    • ตรวจสอบด้วยว่าเครื่องทั้งหมดออนไลน์อยู่หรือไม่ และสามารถรวบรวม·ตรวจสอบ stack trace กับ log ได้ง่ายหรือไม่
      • Imbue ใช้สแต็ก Loki, Prometheus, Grafana
    • ในการรันแบบกระจายที่ซิงโครนัส ข้อผิดพลาดแรกมักก่อให้เกิดข้อผิดพลาดลูกโซ่ที่ไม่เกี่ยวข้องกัน
    • เมื่อสร้างระบบรันซ้ำอัตโนมัติ การรวบรวม log·ข้อผิดพลาดยิ่งสำคัญขึ้น เพื่อไม่ให้ log และข้อผิดพลาดจากการรันซ้ำคนละครั้งปะปนกัน
    • ข้อผิดพลาดที่พบบ่อยมีดังนี้
      • Forward order differs across ranks...: เป็นลักษณะของ implementation PyTorch FSDP และแก้ได้ด้วยการรันซ้ำ
      • CUDA out of memory...: แก้โดยตรวจสอบการตั้งค่าและโค้ด รวมถึง rollback การเปลี่ยนแปลงโค้ดล่าสุด
      • CPU/RAM OOM: ควรตรวจจับจากการเรียก OOM Killer ใน log dmesg ของโฮสต์นอกคอนเทนเนอร์

  • แครชกลางการฝึก

    • หลังจากฮาร์ดแวร์เริ่มทำงานแล้ว สิ่งที่จำเป็นก่อนคือระบบที่รัน diagnostic health check ทั้งหมดอีกครั้ง และรีสตาร์ตอัตโนมัติโดยตัดโฮสต์ที่ไม่ healthy ออก
    • ข้อผิดพลาดฮาร์ดแวร์แบบสุ่ม เช่น Xid·SXid อาจทำให้การรันแครชโดยไม่มี Python stack trace ที่มีความหมาย
    • บางกรณีอย่าง row remapping สามารถกู้คืนได้ด้วยการรีสตาร์ต แต่ uncorrectable ECC error มักต้องบำรุงรักษาฮาร์ดแวร์หรือเปลี่ยนชิ้นส่วน
    • ข้อมูลฝึกที่มีรูปแบบแย่มากก็ทำให้แครชได้เช่นกัน
      • เอกสารเดี่ยวขนาดใหญ่มากใน corpus อาจทำให้ GPU หรือ CPU OOM
      • ใช้ data loader ที่ deterministic อย่างสมบูรณ์ เพื่อเชื่อมโยงเลข epoch หรือ step กับการแครชได้ง่าย
      • หากต้องการยืนยันว่าข้อมูลเป็นสาเหตุหรือไม่ ให้ปิดการโหลดข้อมูลหรือแทนที่ด้วยข้อมูลปลอมที่เป็นศูนย์ทั้งหมด
    • การหลุดชั่วคราวของอีเทอร์เน็ตหรือพื้นที่ดิสก์ไม่พอ อาจไม่แสดงเป็นข้อความข้อผิดพลาดที่มีประโยชน์ จึงบันทึกตัวชี้วัดสถานะเครือข่ายและโหนดเพื่อตรวจสอบความสัมพันธ์

  • ค้างโดยไม่มี stack trace

    • ข้อผิดพลาดที่ค้างหรือ timeout โดยไม่มี stack trace ดีบักได้ยากเป็นพิเศษ เพราะมีข้อมูลน้อยและทำซ้ำได้ไม่เสถียร
    • ข้อความตัวอย่างมักอยู่ในรูป Watchdog caught collective operation timeout...
    • หากโฮสต์หนึ่งหรือมากกว่านั้นทำงาน NCCL ไม่เสร็จ หรือหลุดออกจากการเชื่อมต่อ NCCL·InfiniBand โฮสต์อื่นทั้งหมดจะถูกบล็อกแบบซิงโครนัสที่การคำนวณ tensor นั้นจนถึง NCCL_TIMEOUT
    • ด้วยลักษณะของไลบรารี NCCL จึงหายากว่าโฮสต์ใดเป็นต้นเหตุ
    • Imbue เพิ่มการเปลี่ยนแปลงด้าน logging ใน NCCL fork เพื่อให้มองเห็นข้อความหรือ operation ที่กำลัง in-flight ตอนแครชได้ดีขึ้น และระบุโฮสต์หรือ GPU ที่มีปัญหา
    • เพื่อหาโฮสต์ที่ทำงานผิดปกติ มักต้องตรวจสอบว่าโฮสต์ใด ไม่ได้สร้าง ข้อความ log เฉพาะนั้น
    • ใช้ Py-Spy และ GDB เพื่อดีบักโปรเซสที่หยุดนิ่งแบบเรียลไทม์ และแยกแยะว่าเป็น NCCL ค้าง, ไดรเวอร์ค้าง หรือ race condition·deadlock ในโค้ด Python

การชะลอตัวของการฝึกเมื่อดูจาก MFU

  • การชะลอตัวทั่วไปหรือ MFU(Model FLOPs Utilization) ที่ต่ำกว่าระดับที่เคยสังเกตได้ อาจเกิดจากหลายสาเหตุ
  • การตรวจสอบการตั้งค่า โค้ด และตัวแปรสภาพแวดล้อมอีกครั้งก่อนจะช่วยได้
    • โมเดลผิด
    • ขนาด batch ผิด
    • การตั้งค่า UFM หรือ NCCL ผิด
    • CUDA_DEVICE_MAX_CONNECTIONS ผิด
  • การวัด MFU ทันทีแบบราย batch มีประโยชน์ต่อการวินิจฉัยประเภทปัญหามากกว่าค่าเฉลี่ยที่ผ่านการ smoothing

  • สาเหตุตามรูปแบบ MFU

    • หากทันทีหลังเริ่มการฝึก MFU คงที่ต่ำกว่า 1/10 ของค่าที่คาดไว้ มักเป็นปัญหาฮาร์ดแวร์ InfiniBand เช่น สวิตช์เสียในเลเยอร์ T2 หรือ T3
      • ปัญหาฮาร์ดแวร์ระหว่าง GPU กับ NIC ก็อาจเป็นสาเหตุได้ และจะปรากฏใน dmesg เป็น PCIe x16 lanes limited by ...
    • หากทันทีหลังเริ่มคงที่ที่ 30% MFU ของค่าที่คาดไว้ อาจเป็นเพราะการตั้งค่า GDR หรือ environment variable ของ GDR บนโฮสต์หนึ่งผิด
    • หากทันทีหลังเริ่มคงที่ที่ 60~80% MFU ของค่าที่คาดไว้ มักมีสาเหตุจากลิงก์ InfiniBand ที่เสื่อมหรือมีข้อบกพร่อง
      • หาก InfiniBand NIC ที่เชื่อมต่อกับ GPU เฉพาะตัวมีปัญหา NCCL จะพยายามใช้ NIC ของ GPU อื่นในโฮสต์เดียวกันผ่าน local NVLink
      • CPU throttling ก็อาจเป็นสาเหตุได้ จึงต้องปรับการตั้งค่า BIOS ของโฮสต์บางเครื่อง
    • หากเกิด การตกลง 10 เท่า ใน batch เดียวเป็นประจำ มักเกี่ยวข้องกับ checkpointing หรือ evaluation และตรวจสอบได้โดยเทียบกับจำนวน epoch·step
      • หากตั้งแจ้งเตือนอัตโนมัติจากความผิดปกติของ MFU อย่างเดียว จะเกิด false positive จำนวนมาก
    • หากการตกลง 10 เท่าใน batch เดียวเกิดขึ้นไม่บ่อยและสุ่ม แล้วฟื้นตัวทันที มักเป็นกรณีที่มี workload ที่ใช้ CPU หนักถูก schedule บนหนึ่งในโฮสต์ที่กำลังรันอยู่
      • ปัญหาเครือข่ายเป็นครั้งคราวหรือคอขวดของ data loader ก็อาจเป็นสาเหตุได้
    • หากกราฟ MFU ค่อยๆ ลดลงเมื่อการรันดำเนินไป และกลับเป็น 100% เมื่อรีสตาร์ต ได้ตรวจสอบด้วย Python และ NVIDIA profiler แล้วว่าสาเหตุคือ automatic garbage collection
      • เมื่อปิด automatic garbage collection และให้ทุกโฮสต์ทำ garbage collection ตามช่วงเวลาที่กำหนด การลดลงของ throughput ก็หายไป
    • หากประสิทธิภาพช่วงแรกดี แต่หลังจากนั้นมักตกลงเหลือ 70% ของค่าที่คาดไว้ พบว่ามีความสัมพันธ์กับ NVIDIA GPU clock throttle reasons
      • สาเหตุคืออุณหภูมิ GPU, พัดลมระบายความร้อนของโฮสต์เสีย·เสื่อม หรือ power supply ล้มเหลว
    • หากประสิทธิภาพดี แต่มีสัญญาณรบกวนความถี่สูงมากในช่วง 90~100% ของ MFU ที่คาดไว้ มักเป็นปัญหาฮาร์ดแวร์ InfiniBand เช่น การเสื่อมระดับปานกลางในเลเยอร์บนของเครือข่าย หรือ flapping link

  • คำถามสำหรับตรวจสอบ throughput regression

    • ตรวจสอบว่าเคยทำงานปกติมาก่อนหรือไม่
    • ตรวจสอบว่ามีสิ่งที่เปลี่ยนแปลงหรือไม่ เช่น การ merge โค้ดล่าสุดหรือการอัปเดตไดรเวอร์
    • ตรวจสอบว่ากำลังรันบนโฮสต์ที่ healthy หรือไม่ และบริการที่พึ่งพา เช่น Docker Hub·GitHub ทำงานอยู่หรือไม่
    • ตรวจสอบว่ารันด้วยโค้ด สภาพแวดล้อม การตั้งค่า เวอร์ชัน รายชื่อโฮสต์ ลำดับ rank และ random seed เดียวกับการรันปกติครั้งก่อนหน้าหรือไม่
    • ตรวจสอบว่าสามารถทำซ้ำได้หรือไม่
    • ตรวจสอบว่ามีความสัมพันธ์กับโปรเซสอื่น, crontab รายวัน, ตัวชี้วัดของโฮสต์·DCGM·UFM หรือไม่
    • ตรวจสอบว่าเครื่องมือวัดตัวชี้วัดถูกต้องหรือไม่
    • ตรวจสอบว่าปัญหาเกิดขึ้นในโค้ดที่ลดขนาดลงหรือไม่ เช่น โมเดลที่เล็กกว่า, ข้อมูลปลอม, การตัดการบันทึก·โหลด checkpoint ออก

เครื่องมืออัตโนมัติและการปรับปรุงการปฏิบัติการ

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

  • แยกเครื่องที่มีข้อบกพร่องออกโดยอัตโนมัติ

    • พัฒนาระบบที่รีสตาร์ตการรันที่แครชจาก checkpoint ล่าสุดโดยอัตโนมัติ
    • กระบวนการรีสตาร์ตจะรัน health check บนเครื่องที่ใช้งานได้ทั้งหมด และจัดประเภทสถานะสุขภาพของเครื่องตามเช็กที่ผ่าน
    • จากนั้นรันงานฝึกอีกครั้งบนเครื่องที่มีสุขภาพดีที่สุด

  • รับมือองค์ประกอบเครือข่ายโดยอัตโนมัติ

    • ความล้มเหลวขององค์ประกอบเครือข่ายที่สังเกตพบทั้งหมดถูก UFM ตรวจจับและบันทึกไว้ใน event log ของ UFM
    • อีเวนต์ที่เป็นปัญหาจริงมีเพียงบางส่วนจากหลายสิบประเภท และส่วนใหญ่เกี่ยวข้องกับลิงก์ down หรือ symbol error count สูง
    • สคริปต์จะ parse event log ของ UFM เพื่อปิดใช้งานลิงก์และพอร์ตที่เกี่ยวข้องกับอีเวนต์ล่าสุด สร้าง ticket บำรุงรักษา และเปิดใช้งานอีกครั้งหลังซ่อมเสร็จ

  • มิเรอร์ระบบไฟล์ภายใน

    • ความเร็ว Ethernet ภายในและภายนอกคลัสเตอร์อาจกลายเป็นคอขวดของการฝึกแบบกระจายขนาดใหญ่ได้
    • การเชื่อมต่อ Ethernet แบบแชร์ประมาณ 10Gbit/s จะอิ่มตัวอย่างรวดเร็วเมื่อ worker หลายร้อยตัวดาวน์โหลด dataset และ model checkpoint พร้อมกัน
    • Imbue สร้างระบบไฟล์ภายในที่ mirror cloud storage ภายในคลัสเตอร์ เพื่อลดจำนวนไฟล์ที่ต้องดึงจาก S3
    • ทำสำเนาแต่ละไฟล์ 3 ชุดเพื่อรับมือกับ churn ที่เครื่องถูกปิดใช้งานหรือเปลี่ยนบ่อย
    • ใช้ consistent hashing เพื่อกระจายโหลดให้สม่ำเสมอและลดการย้ายไฟล์ระหว่างเกิด churn
    • เนื่องจากพื้นที่ดิสก์มีจำกัด จึงพัฒนาเครื่องมือติดตามวงจรชีวิตไฟล์และลบไฟล์ที่ไม่จำเป็นด้วย

  • Docker registry แบบกระจายภายใน

    • ใช้ Kraken สำหรับการส่ง Docker image
    • Kraken เป็นซอฟต์แวร์โอเพนซอร์สที่ทำให้ส่ง Docker image แบบ peer-to-peer ได้ และ Imbue ระบุว่าแทบไม่มีปัญหา

  • การมอนิเตอร์ประสิทธิภาพและการระบุโฮสต์ที่มีข้อบกพร่อง

    • ตั้งค่า Torch profiler และ NVIDIA Nsight Systems
    • Nsight Systems มีประโยชน์ในการทำความเข้าใจว่า forward/backward pass และการสื่อสารของ NCCL ใช้เวลานานเท่าไร
    • ช่วยตัดสินว่าเป็นคอขวดด้านการสื่อสารหรือคอขวดด้านการคำนวณ โดยอิงจากขนาดโมเดลและจำนวน worker
    • ใช้งานค่อนข้างยากเพราะต้องใช้ Docker privileged mode, ปิดใช้งาน security check ที่เกี่ยวข้องกับ performance monitoring event และต้องหยุดการฝึกเพื่อบันทึก profile
    • ยังเขียนเครื่องมือสำหรับตรวจจับ batch การฝึกที่ช้าและหาสาเหตุด้วย
      • เครื่องมือที่มีประโยชน์ที่สุดคือเฝ้าดูเวลาของแต่ละ batch แล้ว dump stack trace ของ worker ทั้งหมดเมื่อพบ batch ที่ช้าผิดปกติ
      • ทำให้ระบุโฮสต์เฉพาะที่มีปัญหาฮาร์ดแวร์หรือซอฟต์แวร์แบบละเอียดอ่อนได้ง่ายขึ้น
    • ก่อนที่ health check จะพัฒนาจนเพียงพอ หากการฝึกล้มเหลวบนชุดเครื่องบางชุด ก็ยังไม่ชัดเจนว่าเครื่องใดเป็นสาเหตุ
      • ตัวอย่างเช่น หากกลุ่มเครื่อง 48 เครื่องล้มเหลว จะเปิดการรันขนาดเล็กเป็น 6 กลุ่ม กลุ่มละ 8 เครื่อง และ 8 กลุ่ม กลุ่มละ 6 เครื่อง
      • เครื่องที่อยู่ในกลุ่มที่ล้มเหลวทั้งสองขั้นจะถูกตัดสินด้วยความมั่นใจสูงว่าเป็นเครื่องที่มีปัญหา

หลักปฏิบัติการที่ได้จากกระบวนการสร้าง

  • หากมีเครื่องมากกว่าที่จำเป็นสำหรับการรันการฝึกเฉพาะ 10~20% จะช่วยให้รันใหม่ได้ง่ายเมื่อเครื่องล้มเหลว
  • หากออกแบบเครือข่ายคลัสเตอร์ให้ทุกเครื่องเชื่อมต่อกันอย่างใกล้ชิด จะสามารถใช้ subset ใด ๆ ที่ยังทำงานอยู่ได้
  • ความล้มเหลวของฮาร์ดแวร์หรือซอฟต์แวร์ที่พบระหว่างการฝึกจะเกิดขึ้นอีก ดังนั้นจึงคุ้มค่าที่จะเขียน test และโซลูชันอัตโนมัติสำหรับความล้มเหลวแต่ละประเภท
  • การสร้างเครื่องมือที่ตีความได้มากขึ้นสำหรับข้อความผิดพลาดที่คลุมเครือแต่ละรายการมีประโยชน์
  • เพื่อความสามารถในการทำซ้ำ เลือกใช้กฎที่ว่าแม้แต่การเปลี่ยนแปลงที่ง่ายที่สุดก็ให้เปลี่ยนทีละอย่างเท่านั้น
  • เมื่อนำเครื่องมือภายนอกมาใช้หรือมีคนใหม่เข้าร่วมกระบวนการ ให้ตรวจสอบข้ออ้างอีกครั้ง โดยเฉพาะเมื่อขั้นตอนถัดไปต้องพึ่งพาผลลัพธ์นั้น
  • กระบวนการทั้งหมดต้องอาศัยการกำกับดูแลและการทำซ้ำจำนวนมาก แต่สิ่งที่เป็นปัจจัยชี้ขาดคือการควบคุมโครงสร้างพื้นฐานได้อย่างสมบูรณ์และสามารถดีบักปัญหาได้ในทุกชั้นของ abstraction

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

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

 
GN⁺ 2024-06-29
ความคิดเห็นจาก Hacker News
  • ตลอดหลายเดือนที่ผ่านมา ทีมวิจัยและวิศวกรรมขนาดเล็กได้ฝึก โมเดล 70 พันล้านพารามิเตอร์ ตั้งแต่ต้นบนโครงสร้างพื้นฐานของตนเอง และทำผลงานเหนือกว่า zero-shot GPT-4o ในงานด้านการอนุมาน
    หากจะใช้คลัสเตอร์ของตัวเองสำหรับการฝึกประสิทธิภาพสูง ส่วนประกอบทุกอย่างตั้งแต่ InfiniBand, Ethernet, GPU ไปจนถึงโหนดต้องทำงานได้สมบูรณ์ และหากมีการเชื่อมต่อที่ไม่เสถียรเพียงจุดเดียวจากมากกว่า 12,000 จุด การฝึกทั้งหมดก็อาจช้าลงได้
    พวกเขาได้เผยแพร่สคริปต์โอเพนซอร์สและคู่มือแบบ end-to-end สำหรับการตั้งค่าโครงสร้างพื้นฐาน ซึ่งเป็นหนึ่งในชุดเครื่องมือไตรภาคสำหรับการฝึกโมเดล 70 พันล้าน โดยสามารถดูเครื่องมือประเมินผลและปรับแต่งไฮเปอร์พารามิเตอร์ CARBS ได้ที่นี่: https://imbue.com/research/70b-intro/
    • รายละเอียดดีมาก และนี่เป็นครั้งแรกที่ได้เห็นบทความที่เปิดเผย งานวิศวกรรม เบื้องหลังโมเดลลักษณะนี้อย่างละเอียดจากภายในองค์กร
      มีสองเรื่องที่สงสัย อย่างแรกคือ ถ้าจะฝึก โมเดล 4 แสนล้านพารามิเตอร์ จะมีอะไรแตกต่างออกไปบ้าง แม้ดูเหมือนว่าเมื่อรวมทั้งคลัสเตอร์แล้ววิดีโอเมมโมรีจะเพียงพอ แต่ก็อยากรู้การประเมินจริง
      อย่างที่สองคือ สถาปัตยกรรมแบบนี้ถือเป็นรูปแบบสุดท้ายของการฝึกโมเดลหรือไม่ มันดูเปราะบางมาก จึงอยากรู้ว่ามีกลไกการฝึกร่วมกันหรือสถาปัตยกรรมที่ดีกว่า รวมถึงโครงสร้างคลัสเตอร์ที่ดีกว่านี้หรือไม่
    • สงสัยว่า โลก 3D คล้าย Minecraft ที่ทีมกำลังสร้างนั้นเป็นอย่างไรต่อไป เปลี่ยนทิศทางแล้วหรือ?
    • ส่วนที่บอกว่า “เหนือกว่า zero-shot GPT-4o” น่าสนใจมาก อยากรู้ว่าโมเดลนี้ทำ RLHF มาด้วยหรือยัง หรือเป็นเพียงการพรีเทรนเท่านั้น
      ถ้าเป็นอย่างหลัง ก็อยากรู้ว่าชนะ GPT-4 ได้อย่างไร
    • ประโยคที่ว่าการเชื่อมต่อมากกว่า 12,000 จุด ถ้าไม่เสถียรเพียงจุดเดียวก็อาจทำให้การฝึกทั้งหมดช้าลงนั้นค่อนข้างสะดุดตา จนรู้สึกว่า “เหมือนเคยเห็นประโยคนี้มาก่อน”
      พอดูจริง ๆ แล้วทั้งประโยคนี้และเนื้อหาส่วนใหญ่ในบทความดูเหมือนถูกโพสต์ลง Twitter, LinkedIn, Reddit แบบแทบจะคำต่อคำเลย แบบนี้ถือเป็นสแปมหรือเปล่า?
      https://x.com/imbue_ai/status/1805629547473518695
      https://reddit.com/r/learnmachinelearning/comments/1dobgbs/t...
      https://www.linkedin.com/posts/mattboulos_training-a-70b-mod...
  • ถ้าบอกว่า “มี H100 GPU 4,092 ตัว บนคอมพิวเตอร์ 511 เครื่อง เครื่องละ 8 ตัว” หมายความว่าเฉพาะ GPU อย่างเดียวก็เกิน 100 ล้านดอลลาร์แล้วใช่ไหม?
    อยากรู้ว่าส่วนไหนของสิ่งนี้จะลงมาอยู่ในขอบเขตที่นักพัฒนาสายงานอดิเรกซึ่งมีงบระดับพีซีเกมมิงจะเข้าถึงได้ และเมื่อไหร่
    • น่าสนใจที่พอทุ่ม 100 ล้านดอลลาร์ไปกับ GPU แล้ว ก็ยังต้องมานั่งจัดการกับ เครื่อง Dell ที่พอร์ต Ethernet มีปัญหา
      ฟังปัญหาที่เจอแล้วสนุกดี
    • ดูเหมือนจะใช่ พวกเขาระดมทุนจาก NVIDIA ได้ 200 ล้านดอลลาร์ และน่าจะมาในรูปแบบของ GPU ล้วน ๆ: https://news.crunchbase.com/ai-robotics/new-ai-unicorn-imbue...
    • ถ้าเฉพาะ GPU ก็เกิน 100 ล้านดอลลาร์แล้ว ผู้อ่านอิสระส่วนใหญ่ที่ไม่มีเงินทุนระดับนั้นก็คงต้องเลื่อนไปอ่านโพสต์ HN ถัดไป
  • เจ๋งมาก Cisco เพิ่งร่วมมือกับ NVIDIA และออกอุปกรณ์ที่ให้ 800G ต่อพอร์ตได้ แต่จำไม่ได้ว่าเป็น RoCE หรือไม่
    ที่นี่ดูเหมือน GPU จะเข้าถึง InfiniBand ได้โดยตรง ซึ่งสวยงามมาก นี่เป็นหนึ่งในบทความที่มีประโยชน์ในทางปฏิบัติจริง
  • เมื่อไม่กี่วันก่อน พอดแคสต์ Latent Space ก็พูดถึงเรื่องนี้เช่นกัน: https://www.latent.space/p/llm-training-2024
    เป็นตอนที่ดี และคุ้มค่าที่จะฟังเหตุผลเบื้องหลังว่าทำไมจึงตัดสินใจแบบนี้
    • ฉันไม่คุ้นกับการสัมภาษณ์แนวนี้ เลยรู้สึกว่าเกินความถนัดไปหน่อย ถ้ามีคำถามที่ควรถามแต่หลุดไป ก็อยากให้ช่วยแนะนำ
  • อยากรู้เรื่อง การใช้พลังงานรวมทั้งหมด ที่ใช้ในการสร้างโมเดลนี้ ว่ามีตัวเลขรวมทั้งไฟฟ้าและการระบายความร้อนหรือไม่
    Zuckerberg พูดในพอดแคสต์ว่ากำลังวางแผนโมเดล 1GW ตัวถัดไป ซึ่งแทบจะหมายถึงดาต้าเซ็นเตอร์ที่มีโรงไฟฟ้าขนาดกลางติดมาด้วย เลยยิ่งอยากรู้
  • เป็นบทความที่มีคุณค่ามากและได้เรียนรู้เยอะจากการอ่าน โค้ดโอเพนซอร์ส ที่เผยแพร่ออกมาก็ยอดเยี่ยม
    มีคำถามอยู่บ้าง เช่น ทำไมถึงเลือกสร้างคลัสเตอร์เอง ประสบการณ์กับพาร์ตเนอร์คลาวด์ในการจัดการอุปกรณ์หรือสวิตช์ที่มีปัญหาเป็นอย่างไร
    อีกทั้งนอกจากการสื่อสารแบบ all-to-all แล้ว ตอนเลือกสถาปัตยกรรมคลัสเตอร์ให้ความสำคัญกับอะไรที่สุด และในทางปฏิบัติอะไรมีคุณค่ามากที่สุด โครงสร้างพื้นฐานด้านล็อกเป็นอย่างไรนอกเหนือจากการใช้ Loki ทำไมจึงต้องมี local Docker registry และนอกจาก nvidia-container-runtime แล้วใช้ image อื่นด้วยหรือไม่
  • ขอถามตรง ๆ ว่าทำไมที่นี่ถึงยังมี ฮาร์ดแวร์พีซี ปะปนอยู่มากขนาดนี้?
    ทำไมไม่ต่อ GPU เข้ากับแบ็กเอนด์ PCI และ InfiniBand แล้วมีเพียงคอนโทรลเลอร์ ARM ขนาดเล็กไว้ประสานงานกัน? ไม่แน่ใจว่านี่เป็นเพราะแรงเฉื่อยจากการออกแบบเดิม หรือเพราะตลาดคอนโทรลเลอร์ GPU เฉพาะทางยังไม่พอ
    • ถ้ากำลังถามว่าทำไมยังต้องจ่ายเพิ่มให้ CPU และ RAM ก็เพราะไม่ใช่ทุกงานจะทำบน GPU ได้ เช่น การคลายบีบอัด .png
      ถ้าวิเคราะห์โค้ดฝึกอย่างจริงจังและทำ preprocessing ข้อมูลให้มากพอ อาจใช้ทรัพยากร CPU/RAM ที่เบามากได้ แต่เพราะ GPU แพง ดังนั้น CPU/RAM จึงเป็นสัดส่วนต้นทุนที่เล็กของทั้งระบบ จึงอาจไม่จำเป็นต้องใช้เวลาในการพัฒนาเพื่อปรับแต่งระดับนั้นเสมอไป

ผู้ให้บริการคลาวด์รายใหญ่มากก็น่าจะไล่ตามประสิทธิภาพด้านต้นทุนระดับ 0.x% แบบนั้นเช่นกัน ตัวอย่างเช่น อาจอยากพรีโปรเซส .png เป็น .webp (lossless แบบหลายเธรด) หรือ .jpeg (lossy) แต่การเปลี่ยนไปเป็นฟอร์แมตที่ GPU ถอดรหัสได้ แม้จะช่วยลดต้นทุนฝั่ง CPU ระหว่างเทรน ก็อาจทำให้ต้นทุนสตอเรจและการส่งข้อมูลสูงขึ้นจนไม่คุ้ม
พูดให้แม่นยำกว่านั้นคือ ถ้างานฝั่ง CPU เป็นคอขวดของการเทรน ก็ควรปรับทั้งการพรีโปรเซสข้อมูลและสคริปต์เทรนให้เหมาะที่สุด ประเด็นที่พูดถึงตรงนี้คือช่องว่างระหว่าง “เร็วพอแล้ว” กับ “เร็วกว่า”: CPU เร็วไม่พอสำหรับการเทรน < CPU เร็วพอดีสำหรับการเทรน < CPU เร็วเกินกว่าที่การเทรนต้องการ

  • ถ้าแต่ละเครื่องใส่ GPU มูลค่า 250,000 ดอลลาร์ การมานั่งกังวลเพื่อประหยัดเงินไม่กี่พันดอลลาร์จากฮาร์ดแวร์ควบคุมถือว่าไม่ฉลาดนัก ความเสี่ยงจากการใช้ การจัดฮาร์ดแวร์แบบใหม่ สูงเกินไป
    อีกปัญหาหนึ่งคือฮาร์ดแวร์ที่เกี่ยวกับ GPU ไดรเวอร์ และประสบการณ์ในการปฏิบัติการ ล้วนอยู่ฝั่ง PC กันหมด ถ้าจะไปรันบน ARM ก็แทบต้องเริ่มใหม่เกือบทั้งหมด และยังต้องมีงานเพิ่มอีกมากเพื่อให้เสถียร สุดท้ายก็เหมือนยอมจ่ายต้นทุนก้อนใหญ่เพื่อประหยัดค่าโปรเซสเซอร์เพียงเล็กน้อย
  • การป้อนข้อมูลให้ GPU อย่างต่อเนื่องเป็นงานที่ค่อนข้างยากในงานเทรนดีปเลิร์นนิง
    แม้จะไม่มีประสบการณ์ด้าน LLM/NLP แต่ในเวิร์กโหลดด้านภาพและเสียง บางครั้ง CPU ทั่วไป 4~8 คอร์ก็ยังทำให้ RTX 2/3/4xxx GPU ถูกใช้งานได้ไม่เต็มที่ได้ การที่ CPU หรือ I/O กลายเป็นคอขวดนั้นเกิดขึ้นได้ไม่ยาก
  • H100 GPU 4,092 ตัว นี่ถือว่าใหญ่มาก
    พวกเขาบอกว่ากำลังทำ “self-coding” อยู่ เลยสงสัยว่ามันใกล้เคียงกับโซลูชันแบบ no-code หรือ low-code หรือไม่
    บนเว็บไซต์ก็มีบทความที่น่าสนใจอยู่พอสมควร: https://imbue.com/our-work/
  • สงสัยว่าต้นทุนรวมเท่าไรกันแน่ ถ้านับตั้งแต่ไม่มีอะไรเลยไปจนได้ไฟล์โมเดลที่พร้อมใช้งาน รวมทั้ง ต้นทุนฮาร์ดแวร์ เวลาในการพัฒนา ค่าไฟ และค่าระบายความร้อนแล้ว จะอยู่ที่ประมาณเท่าไร?
  • สงสัยว่านักพัฒนางานอดิเรกจำนวนมากจะร่วมกันเทรนโมเดลแบบกระจายศูนย์ได้ไหม คล้าย seti@home หรือ folding@home
    โปรเจกต์พวกนั้นมีลักษณะเด่นคือสามารถแบ่งงานออกเป็นแพ็กเกจย่อยที่ค่อนข้างอิสระต่อกันได้ แต่ยังไม่แน่ใจว่าการเทรนโมเดลจะแบ่งแบบนั้นได้หรือไม่
    • มีโอกาสสูงว่าจะทำไม่ได้ดีนัก ในหมู่นักพัฒนางานอดิเรก แทบไม่มีหรืออาจไม่มีเลยที่สามารถมี แบนด์วิดท์เครือข่าย 400Gbps ระหว่าง GPU ของกันและกันได้