เปิดตัว PyTorch Monarch

 (pytorch.org)
3 คะแนน โดย GN⁺ 2025-10-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • PyTorch Monarch เป็นเฟรมเวิร์กใหม่ที่ออกแบบมาเพื่อรองรับ การฝึกและการอนุมานแบบกระจายที่มีประสิทธิภาพ สำหรับโมเดลขนาดใหญ่
  • ขยาย โครงสร้างแบบโมดูลาร์ เดิมของ PyTorch เพื่อมอบความสามารถในการแบ่งและจัดการโครงข่ายประสาทขนาดมหึมาไปยังหลายอุปกรณ์และหลายโหนดโดยอัตโนมัติ
  • ลดภาระการตั้งค่าที่ซับซ้อนของนักพัฒนาด้วย API ที่สามารถควบคุม model parallelism, pipeline parallelism และ data parallelism ได้แบบบูรณาการ
  • Monarch แสดงประสิทธิภาพสูงเป็นพิเศษในเวิร์กโหลดที่ใช้หน่วยความจำเข้มข้น เช่น large language models (LLM) และระบบแนะนำ
  • เป็นส่วนหนึ่งของความพยายามในการบรรลุทั้ง ความสามารถในการขยายระบบและการปรับแต่งประสิทธิภาพ ภายในระบบนิเวศของ PyTorch พร้อมเป็นองค์ประกอบสำคัญของโครงสร้างพื้นฐานการฝึกแบบกระจายยุคถัดไป

ภาพรวมของ PyTorch Monarch

  • PyTorch Monarch ถูกแนะนำในฐานะองค์ประกอบใหม่ของ PyTorch เพื่อ ทำให้การฝึกและการอนุมานแบบกระจายสำหรับโมเดลขนาดใหญ่ง่ายขึ้น
    • ออกแบบมาให้ยังคงความยืดหยุ่นของ PyTorch เดิมไว้ พร้อมทำให้สามารถวางโมเดลที่มีพารามิเตอร์ระดับหลายพันล้านตัวลงบน GPU และโหนดหลายตัวได้อย่างมีประสิทธิภาพ
    • มอบ ความสามารถด้านการแบ่งส่วนและการเพิ่มประสิทธิภาพการสื่อสารแบบอัตโนมัติ โดยไม่จำเป็นต้องกำหนดกลยุทธ์การขนานที่ซับซ้อนด้วยตนเอง
  • เป้าหมายหลักของ Monarch คือ ยกระดับการนามธรรมของ model parallelism เพื่อให้นักพัฒนาสามารถโฟกัสกับการออกแบบโครงสร้างโมเดลได้
    • สามารถควบคุมเทคนิคการขนานที่หลากหลาย เช่น data parallelism, pipeline parallelism และ tensor parallelism ได้ผ่านอินเทอร์เฟซแบบรวมศูนย์เดียว
    • ช่วยลด ความซับซ้อนของโค้ดและ communication overhead ได้อย่างมากเมื่อเทียบกับเฟรมเวิร์กการฝึกแบบกระจายเดิม

ฟีเจอร์หลักและลักษณะทางเทคนิค

  • Monarch ใช้ อัลกอริทึมการแบ่งส่วนอัตโนมัติ เพื่อจัดวางแต่ละเลเยอร์ของโมเดลไปยังอุปกรณ์ที่เหมาะสมที่สุด
    • กำหนดกลยุทธ์การแบ่งส่วนแบบไดนามิกโดยพิจารณาจากความจุหน่วยความจำ GPU, แบนด์วิดท์การสื่อสาร และภาระการประมวลผล
    • ระบบอัตโนมัตินี้ให้ประสิทธิภาพสูงเป็นพิเศษใน LLM, โมเดลที่อิง Transformer และระบบแนะนำขนาดใหญ่
  • มี API สำหรับการขนานแบบรวมศูนย์ ที่ช่วยให้นักพัฒนาทดลองกลยุทธ์การขนานได้หลากหลายด้วยโค้ดเบสเดียว
    • ตัวอย่างเช่น สามารถรันโมเดลเดียวกันด้วยการผสาน data parallelism กับ pipeline parallelism หรือสลับไปใช้ tensor parallelism ได้
    • ความยืดหยุ่นนี้ช่วยให้ การค้นหาการปรับแต่งที่เหมาะสมตามขนาดโมเดลและการจัดวางฮาร์ดแวร์ ทำได้ง่ายขึ้น
  • Monarch เข้ากันได้กับความสามารถ DistributedDataParallel(DDP) และ Fully Sharded Data Parallel(FSDP) ที่มีอยู่เดิมของ PyTorch
    • สามารถย้ายมาใช้ Monarch ได้โดยไม่ต้องแก้ไขโค้ดเบสเดิมมากนัก
    • ยังรวมเข้ากับ TorchScript และ TorchDynamo ของ PyTorch เพื่อรองรับการคอมไพล์และการเพิ่มประสิทธิภาพการรัน

ประสิทธิภาพและกรณีการใช้งาน

  • จากผลเบนช์มาร์กเบื้องต้น Monarch ทำได้ดีกว่าการฝึกแบบกระจายของ PyTorch เดิม โดย ประสิทธิภาพการสื่อสารดีขึ้น 20~30% และ ลดการใช้หน่วยความจำลง 15%
    • โดยเฉพาะในโมเดลขนาดหลายพันล้านพารามิเตอร์ ความเร็วในการฝึกและอัตราการใช้ GPU ดีขึ้นอย่างชัดเจน
    • ได้รับการยืนยันเชิงทดลองใน large language models (เช่น ตระกูล GPT) และระบบแนะนำ
  • Monarch ทำงานได้ทั้งใน สภาพแวดล้อมคลาวด์และออนพรีมิส และเข้ากันได้กับโครงสร้างพื้นฐานคลาวด์หลักอย่าง AWS, Azure และ GCP
    • รองรับการผสานกับเฟรมเวิร์กระดับบนอย่าง PyTorch Lightning และ Hugging Face Transformers ด้วย

ความหมายต่อระบบนิเวศของ PyTorch

  • Monarch ถูกมองว่าเป็น การขยายโครงสร้างพื้นฐานหลักเพื่อรองรับยุคของโมเดล AI ขนาดใหญ่ ของ PyTorch
    • เป็นรากฐานที่ช่วยให้ก้าวพ้นจากกระบวนทัศน์การฝึกที่ยึด GPU เดี่ยวเป็นศูนย์กลาง ไปสู่ การฝึกโมเดลขนาดมหึมาด้วย GPU หลายพันตัว
    • ทำหน้าที่เป็น โซลูชันการฝึกแบบกระจายที่เป็นมาตรฐาน ซึ่งให้ทั้งความสามารถในการขยายและประสิทธิภาพ สำหรับทั้งนักวิจัยและองค์กร
  • ทีม PyTorch มีแผนเผยแพร่ Monarch แบบโอเพนซอร์ส และพัฒนาต่อเนื่องโดยสะท้อนฟีดแบ็กจากชุมชน
    • ในอนาคตมีแผนเพิ่มฟีเจอร์ การปรับแต่งอัตโนมัติ, การจัดตารางแบบไดนามิก และ hybrid parallelism
    • ในฐานะเฟรมเวิร์กการฝึกแบบกระจายยุคถัดไปของ PyTorch คาดว่าจะช่วยผลักดัน การทำให้โครงสร้างพื้นฐาน AI เข้าถึงได้กว้างขึ้นและเพิ่มการเข้าถึง

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

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

 
GN⁺ 2025-10-25
ความคิดเห็นบน Hacker News

  • ดูเหมือนว่าโปรเจ็กต์นี้จะเล็งคนละชั้นกับ Tinker
    จากบทความแนะนำ Tinker จะเห็นว่า Tinker เป็นบริการ fine-tuning แบบ managed ส่วน Monarch มีโครงสร้างที่ให้ primitive ระดับอินฟราสตรักเจอร์
    เลยสงสัยว่าอาจสร้างบริการแบบ Tinker บน Monarch ได้หรือไม่

    • ตอนนี้มีสิ่งอย่าง TorchForge ที่ทำงานอยู่บนมัน

  • ดูเหมือนว่า oxidation ของ PyTorch จะเริ่มขึ้นแล้ว
    Monarch แบ่งเป็นฟรอนต์เอนด์ที่ใช้ Python และแบ็กเอนด์ที่พัฒนาด้วย Rust
    โดยรวมแล้วดูเป็นโปรเจ็กต์ที่น่าสนใจมาก

    • ตามหลายแหล่งข้อมูล Monarch เป็น เฟรมเวิร์กเชิงทดลอง ของ PyTorch ไม่ใช่ตัวมาแทน
      ดังนั้นก็น่าจะยังได้เพลิดเพลินกับกราฟแบบวนซ้ำและ memory leak ที่อิง std::shared_ptr ต่อไป
      น่าเสียดายที่ไม่ได้เขียนใหม่ทั้งหมดด้วยภาษาเชิงฟังก์ชัน
    • นี่ดูไม่ใช่เวอร์ชันที่ถูกออกซิไดซ์ของโปรเจ็กต์เดิม แต่เป็น โปรเจ็กต์ใหม่ ทั้งหมด

  • ฉันเคยสร้าง ส่วนขยาย PyTorch เอง — mycelya-torch
    เวอร์ชันของฉันยังไม่รองรับการสื่อสารระหว่างโหนด แต่ฉันสนใจวิธีที่ Monarch ใช้เพื่อรีดประสิทธิภาพ
    Monarch น่าจะใช้ cloudpickle เพื่อแชร์โค้ดไปยังทุกโหนด ซึ่งมีต้นทุนแค่ตอนตั้งค่าเริ่มต้นและมีประสิทธิภาพดี
    โครงสร้างที่ให้คอนโทรลเลอร์เดียวทำ fan-out ข้อความก็ชวนประทับใจ
    แต่อยากรู้ว่ารองรับ custom kernel หรือไม่ และควบคุมการสื่อสารระหว่าง actor ได้ละเอียดแค่ไหน
    โดยรวมแล้วฉันชอบแนวทางนี้มากกว่าหลายคอนโทรลเลอร์

    • ถ้าจะใช้ custom kernel อาจต้องแก้โค้ดเริ่มต้นของ remote worker เล็กน้อย
      แต่ก็สามารถ ฝังไว้ล่วงหน้า (bake-in) ทั้ง kernel ที่ต้องใช้หรือโค้ดระบบได้โดยตรง

  • โครงสร้างนี้ดูคล้าย Ray

    • ตัวอย่างโค้ด แทบจะเหมือนกัน กับ Ray
      Actor ของ Monarch และคลาส @ray.remote ของ Ray ตามแพตเทิร์นเดียวกัน
    • เลยสงสัยว่าทำไมต้องใช้ Monarch แทน Ray — หรือเป็นเพราะมันผสานกับ PyTorch และ tensor abstraction ได้แน่นแฟ้นกว่าหรือเปล่า
    • Dask ก็ทำงานกระจายแบบคล้ายกัน แต่เดิมออกแบบมาสำหรับ HPC จึงรองรับ GPU ได้จำกัด
      ดู เว็บไซต์ทางการของ Dask
    • ฉันก็คิดแบบนั้นเหมือนกัน โดยเฉพาะเมื่อดู ประกาศความร่วมมือ ล่าสุดระหว่าง PyTorch กับ Ray แล้วก็ยิ่งรู้สึกเช่นนั้น
      บล็อกที่เกี่ยวข้อง

  • น่าสนใจดี โดยแก่นแล้วทำให้นึกถึงแนวคิด Fortran coarray (2008)

    • หรืออาจจะคล้าย Hadoop (2006) ก็ได้
      เพียงแต่ดีกว่ามากเพราะไม่ต้องไปใช้ MapReduce หรือ Fortran โดยตรง

  • มีข้อความว่า “หลีกเลี่ยงคอขวดของโฮสต์เดียวและใช้เมชทั้งหมดผ่านคลัสเตอร์แบบกระจายสำหรับการส่งข้อความ”
    ถ้าใครที่แก้ไขได้ผ่านมาเห็น อยากให้เพิ่ม ตัวเลขอ้างอิง มาด้วย

  • ดูเป็นโปรเจ็กต์ที่ดี
    มีเรื่องที่สงสัย

    • นี่คล้าย openMPI ไหม?
    • เมชถูกจัดโครงสร้างอย่างไร? ใช้ได้เฉพาะภายในโฮสต์เดียวกันหรือเปล่า?

  • นี่อาจกลายเป็นโปรเจ็กต์สำคัญใน โลกของ coarray ได้ แต่ก็เริ่มเห็นสัญญาณของปัญหาแล้ว
    tensor engine ถูกผูกกับ CUDA และ RDMA (ibverbs) และยังเป็นโค้ดที่ใช้ GPUDirect RDMA
    สุดท้ายแล้วก็น่าจะยิ่งพึ่งพา CUDA มากขึ้น
    ถ้าใช้ OpenUCX น่าจะดีกว่า

  • เมื่อเทียบกับ Jax แล้วดูเหมือนว่า ด้อยกว่าในเชิงฟังก์ชัน
    Jax มีคอมไพเลอร์ทรงพลังที่ช่วยปรับการสื่อสารระหว่างโหนดให้เหมาะสม

    • แต่ Monarch โฟกัสที่ พาราไดม์คอนโทรลเลอร์เดี่ยว ขณะที่ Jax ใช้โครงสร้าง SPMD แบบหลายคอนโทรลเลอร์
      คอนโทรลเลอร์เดี่ยวเข้าใจง่ายกว่า ส่วนหลายคอนโทรลเลอร์เหมาะกับ dataflow บางแบบมากกว่า
      และก็มีความพยายามที่น่าสนใจในการผสมสองแนวทางนี้เข้าด้วยกัน