PyTorch Monarch diperkenalkan

 (pytorch.org)
3 poin oleh GN⁺ 2025-10-25 | 1 komentar | Bagikan ke WhatsApp
  • PyTorch Monarch adalah framework baru yang dirancang untuk mendukung pelatihan dan inferensi terdistribusi yang efisien untuk model berskala besar
  • Dengan memperluas struktur modular PyTorch yang sudah ada, framework ini menyediakan kemampuan untuk secara otomatis membagi dan mengelola jaringan saraf raksasa di banyak perangkat dan node
  • Melalui API yang dapat mengendalikan secara terpadu model parallelism, pipeline parallelism, dan data parallelism, framework ini mengurangi beban pengaturan kompleks bagi pengembang
  • Monarch menunjukkan efisiensi tinggi terutama pada workload yang intensif memori seperti large language model (LLM) dan sistem rekomendasi
  • Sebagai bagian dari upaya untuk sekaligus mencapai skalabilitas dan optimasi performa di dalam ekosistem PyTorch, Monarch menjadi komponen kunci bagi infrastruktur pelatihan terdistribusi generasi berikutnya

Gambaran umum PyTorch Monarch

  • PyTorch Monarch diperkenalkan sebagai komponen baru PyTorch untuk menyederhanakan pelatihan dan inferensi terdistribusi untuk model berskala besar
    • Tetap mempertahankan fleksibilitas PyTorch yang ada, sambil dirancang agar model dengan miliaran parameter dapat ditempatkan secara efisien di banyak GPU dan node
    • Menyediakan fungsi pembagian otomatis dan optimasi komunikasi tanpa perlu menyusun strategi paralelisasi yang rumit secara manual
  • Tujuan utama Monarch adalah meningkatkan tingkat abstraksi model parallelism, sehingga pengembang dapat fokus pada perancangan struktur model
    • Berbagai teknik paralelisasi seperti data parallelism, pipeline parallelism, dan tensor parallelism dapat dikendalikan melalui satu antarmuka terpadu
    • Dengan ini, kompleksitas kode dan overhead komunikasi dapat dikurangi secara signifikan dibanding framework pelatihan terdistribusi yang ada

Fitur utama dan karakteristik teknis

  • Monarch menempatkan setiap layer model ke perangkat yang optimal melalui algoritme pembagian otomatis
    • Strategi pembagian ditentukan secara dinamis dengan mempertimbangkan kapasitas memori GPU, bandwidth komunikasi, dan beban komputasi
    • Otomatisasi ini sangat efisien terutama pada LLM, model berbasis Transformer, dan sistem rekomendasi skala besar
  • Menyediakan API paralelisasi terpadu, sehingga pengembang dapat bereksperimen dengan berbagai strategi paralelisasi menggunakan satu codebase
    • Misalnya, model yang sama dapat dijalankan dengan kombinasi data parallelism dan pipeline parallelism, atau dialihkan ke tensor parallelism
    • Fleksibilitas ini mempermudah eksplorasi optimasi berdasarkan ukuran model dan konfigurasi hardware
  • Monarch kompatibel dengan fitur DistributedDataParallel(DDP) dan Fully Sharded Data Parallel(FSDP) yang sudah ada di PyTorch
    • Codebase yang ada dapat dipindahkan ke Monarch tanpa banyak perubahan besar
    • Juga terintegrasi dengan TorchScript dan TorchDynamo milik PyTorch, sehingga mendukung optimasi kompilasi dan eksekusi

Performa dan contoh penggunaan

  • Berdasarkan hasil benchmark awal, Monarch mencapai peningkatan efisiensi komunikasi sebesar 20~30% dan pengurangan penggunaan memori sebesar 15% dibanding pelatihan terdistribusi PyTorch yang ada
    • Khususnya pada model dengan skala miliaran parameter, kecepatan pelatihan dan tingkat pemanfaatan GPU meningkat secara signifikan
    • Sudah diverifikasi secara eksperimental pada large language model (misalnya seri GPT) dan sistem rekomendasi
  • Monarch berjalan baik di lingkungan cloud maupun on-premises dan kompatibel dengan infrastruktur cloud utama seperti AWS, Azure, dan GCP
    • Juga mendukung integrasi dengan framework tingkat atas seperti PyTorch Lightning dan Hugging Face Transformers

Makna dalam ekosistem PyTorch

  • Monarch dinilai sebagai perluasan infrastruktur inti PyTorch untuk menghadapi era model AI berskala besar
    • Keluar dari paradigma pelatihan yang berpusat pada satu GPU, Monarch menyediakan fondasi untuk pelatihan model ultra-besar dengan memanfaatkan ribuan GPU
    • Bagi peneliti maupun perusahaan, Monarch berperan sebagai solusi pelatihan terdistribusi terstandarisasi yang dapat sekaligus menjamin skalabilitas dan efisiensi
  • Tim PyTorch berencana merilis Monarch sebagai open source, terus mengembangkannya sambil mencerminkan umpan balik komunitas
    • Ke depannya, fitur optimasi otomatis, penjadwalan dinamis, dan hybrid parallelism akan ditambahkan
    • Sebagai framework pelatihan terdistribusi generasi berikutnya dari PyTorch, Monarch diharapkan berkontribusi pada demokratisasi infrastruktur AI dan peningkatan aksesibilitas

Bacaan terkait

1 komentar

 
GN⁺ 2025-10-25
Komentar Hacker News

  • Proyek ini tampaknya menyasar lapisan yang berbeda dari Tinker
    Jika melihat artikel pengenalan Tinker, Tinker adalah layanan fine-tuning terkelola, sedangkan Monarch berstruktur sebagai penyedia primitive infrastruktur
    Jadi saya penasaran apakah layanan seperti Tinker juga bisa dibangun di atas Monarch

    • Saat ini hal seperti TorchForge berjalan di atasnya

  • Sepertinya oksidasi PyTorch telah dimulai
    Monarch terbagi menjadi frontend berbasis Python dan backend yang diimplementasikan dengan Rust
    Secara keseluruhan ini tampak seperti proyek yang cukup menarik

    • Menurut beberapa sumber, Monarch adalah framework eksperimental PyTorch, bukan pengganti
      Jadi tampaknya kita masih bisa menikmati graf siklik berbasis std::shared_ptr dan kebocoran memori
      Agak disayangkan karena tidak ditulis ulang sepenuhnya dengan bahasa fungsional
    • Ini tampaknya bukan versi teroksidasi dari proyek yang sudah ada, melainkan proyek yang sepenuhnya baru

  • Saya pernah membuat ekstensi PyTorch sendiri — mycelya-torch
    Versi saya belum mendukung komunikasi antar-node, tetapi menarik melihat bagaimana Monarch mendapatkan performanya
    Monarch kemungkinan memakai cloudpickle untuk membagikan kode ke semua node, yang hanya menimbulkan biaya setup awal dan efisien
    Struktur yang melakukan fan-out pesan dari satu controller juga cukup mengesankan
    Namun saya penasaran apakah mendukung custom kernel dan seberapa rinci kontrol komunikasi antaraktor yang tersedia
    Secara keseluruhan saya lebih menyukai pendekatan ini dibanding multi-controller

    • Untuk memakai custom kernel, Anda mungkin perlu sedikit memodifikasi kode inisialisasi worker jarak jauh
      Tetapi kernel atau kode sistem yang dibutuhkan bisa langsung di-embed (bake-in)

  • Ini terlihat mirip dengan struktur Ray

    • Contoh kodenya hampir identik dengan Ray
      Actor di Monarch dan kelas @ray.remote di Ray mengikuti pola yang sama
    • Saya penasaran apa alasan memakai Monarch alih-alih Ray — mungkin karena integrasinya yang lebih erat dengan PyTorch atau abstraksi tensor
    • Dask juga melakukan pemrosesan terdistribusi serupa, tetapi awalnya untuk HPC sehingga dukungan GPU-nya terbatas
      Lihat situs resmi Dask
    • Saya juga memikirkan hal yang sama. Terutama jika melihat pengumuman kolaborasi terbaru antara PyTorch dan Ray, rasanya makin begitu
      Blog terkait

  • Menarik, ini pada dasarnya mengingatkan saya pada konsep Fortran coarray (2008)

    • Atau mungkin juga seperti Hadoop (2006)
      Hanya saja menurut saya ini jauh lebih baik karena tidak perlu langsung memakai MapReduce atau Fortran

  • Ada kalimat “menghindari bottleneck host tunggal dan memanfaatkan seluruh mesh sebagai klaster terdistribusi untuk pengiriman pesan”,
    kalau ada yang bisa mengubahnya, saya ingin angka rujukan ditambahkan

  • Ini tampak seperti proyek yang bagus
    Saya punya beberapa pertanyaan

    • Apakah ini mirip dengan openMPI?
    • Bagaimana mesh-nya dibentuk? Apakah hanya bisa di dalam host yang sama?

  • Ini bisa menjadi proyek penting di dunia coarray, tetapi tanda-tanda masalahnya sudah terlihat
    Mesin tensor-nya terikat pada CUDA dan RDMA (ibverbs), dan karena kodenya memakai GPUDirect RDMA
    pada akhirnya ketergantungan pada CUDA tampaknya akan makin parah
    Seandainya memakai OpenUCX, rasanya akan lebih baik

  • Ini tampak kurang kuat secara fungsional dibanding Jax
    Jax mengoptimalkan komunikasi antarnode dengan kompiler yang kuat

    • Tetapi Monarch berfokus pada paradigma single-controller, sedangkan Jax memakai struktur multi-controller SPMD
      Single-controller lebih mudah dipahami, sedangkan multi-controller lebih optimal untuk dataflow tertentu
      Ada juga beberapa upaya menarik yang mencampurkan kedua pendekatan ini