3 điểm bởi GN⁺ 2025-10-25 | 1 bình luận | Chia sẻ qua WhatsApp
  • PyTorch Monarch là một framework mới được thiết kế để hỗ trợ huấn luyện và suy luận phân tán hiệu quả cho các mô hình quy mô lớn
  • Mở rộng cấu trúc mô-đun hiện có của PyTorch, cung cấp khả năng tự động phân chia và quản lý các mạng nơ-ron khổng lồ trên nhiều thiết bị và node
  • Thông qua API có thể điều khiển tích hợp song song mô hình, song song pipeline và song song dữ liệu, giúp giảm gánh nặng cấu hình phức tạp cho nhà phát triển
  • Monarch cho thấy hiệu quả cao đặc biệt trong các workload tiêu tốn nhiều bộ nhớ như mô hình ngôn ngữ lớn (LLM) và hệ thống gợi ý
  • Là một phần trong nỗ lực đạt được đồng thời khả năng mở rộng và tối ưu hiệu năng trong hệ sinh thái PyTorch, đây là thành phần cốt lõi của hạ tầng huấn luyện phân tán thế hệ tiếp theo

Tổng quan về PyTorch Monarch

  • PyTorch Monarch được giới thiệu là một thành phần mới của PyTorch nhằm đơn giản hóa huấn luyện và suy luận phân tán cho các mô hình quy mô lớn
    • Vẫn giữ được tính linh hoạt vốn có của PyTorch, đồng thời được thiết kế để triển khai hiệu quả các mô hình có hàng tỷ tham số trên nhiều GPU và node
    • Cung cấp chức năng tự động phân chia và tối ưu giao tiếp mà không cần cấu hình thủ công các chiến lược song song hóa phức tạp
  • Mục tiêu cốt lõi của Monarch là nâng cao mức độ trừu tượng của song song mô hình, để nhà phát triển có thể tập trung vào thiết kế cấu trúc mô hình
    • Có thể điều khiển nhiều kỹ thuật song song hóa khác nhau như song song dữ liệu, song song pipeline và song song tensor thông qua một giao diện hợp nhất
    • Nhờ đó, độ phức tạp của mã nguồn và overhead giao tiếp được giảm đáng kể so với các framework huấn luyện phân tán hiện có

Tính năng chính và đặc điểm kỹ thuật

  • Monarch sử dụng thuật toán phân chia tự động để đặt từng layer của mô hình lên thiết bị tối ưu
    • Chiến lược phân chia được quyết định động dựa trên dung lượng bộ nhớ GPU, băng thông giao tiếp và tải tính toán
    • Cơ chế tự động hóa này đặc biệt hiệu quả với LLM, mô hình dựa trên Transformer và hệ thống gợi ý quy mô lớn
  • Cung cấp API song song hóa hợp nhất, cho phép nhà phát triển thử nghiệm nhiều chiến lược song song hóa trên cùng một codebase
    • Ví dụ, có thể chạy cùng một mô hình với tổ hợp song song dữ liệu và song song pipeline, hoặc chuyển sang song song tensor
    • Tính linh hoạt này giúp khám phá tối ưu theo kích thước mô hình và cấu hình phần cứng dễ dàng hơn
  • Monarch tương thích với các tính năng DistributedDataParallel(DDP)Fully Sharded Data Parallel(FSDP) hiện có của PyTorch
    • Có thể chuyển sang Monarch mà không cần chỉnh sửa đáng kể codebase hiện tại
    • Cũng được tích hợp với TorchScript và TorchDynamo của PyTorch để hỗ trợ tối ưu biên dịch và thực thi

Hiệu năng và các trường hợp sử dụng

  • Theo kết quả benchmark ban đầu, Monarch đạt cải thiện 20~30% hiệu quả giao tiếpgiảm 15% mức sử dụng bộ nhớ so với huấn luyện phân tán PyTorch hiện tại
    • Đặc biệt, tốc độ huấn luyện và mức độ tận dụng GPU được cải thiện đáng kể ở các mô hình quy mô hàng tỷ tham số
    • Đã được kiểm chứng thực nghiệm trên các mô hình ngôn ngữ lớn (ví dụ: dòng GPT) và hệ thống gợi ý
  • Monarch hoạt động trong cả môi trường cloud và on-premise, đồng thời tương thích với các hạ tầng cloud lớn như AWS, Azure và GCP
    • Cũng hỗ trợ tích hợp với các framework tầng trên như PyTorch Lightning và Hugging Face Transformers

Ý nghĩa trong hệ sinh thái PyTorch

  • Monarch được đánh giá là mở rộng hạ tầng cốt lõi để PyTorch đáp ứng kỷ nguyên mô hình AI quy mô lớn
    • Vượt ra khỏi mô hình huấn luyện tập trung vào một GPU trước đây, cung cấp nền tảng để hiện thực hóa huấn luyện mô hình siêu lớn sử dụng hàng nghìn GPU
    • Đóng vai trò như một giải pháp huấn luyện phân tán tiêu chuẩn hóa giúp đảm bảo đồng thời khả năng mở rộng và hiệu quả cho cả giới nghiên cứu lẫn doanh nghiệp
  • Nhóm PyTorch đã công bố Monarch dưới dạng mã nguồn mở và có kế hoạch tiếp tục phát triển bằng cách phản ánh phản hồi từ cộng đồng
    • Trong tương lai, dự kiến sẽ bổ sung các tính năng tối ưu tự động, lập lịch động và song song hóa lai
    • Với vai trò là framework huấn luyện phân tán thế hệ tiếp theo của PyTorch, Monarch được kỳ vọng sẽ góp phần vào dân chủ hóa hạ tầng AI và cải thiện khả năng tiếp cận

1 bình luận

 
GN⁺ 2025-10-25
Ý kiến Hacker News
  • Có vẻ dự án này nhắm tới một tầng khác so với Tinker
    Theo bài giới thiệu Tinker, Tinker là dịch vụ fine-tuning được quản lý, còn Monarch có cấu trúc cung cấp các primitive hạ tầng
    Vì vậy cũng tò mò liệu có thể xây dựng một dịch vụ như Tinker trên Monarch hay không

    • Hiện tại có những thứ như TorchForge đang chạy trên đó
  • Có vẻ quá trình oxidation của PyTorch đã bắt đầu
    Monarch được chia thành frontend dựa trên Python và backend được triển khai bằng Rust
    Nhìn chung đây có vẻ là một dự án khá thú vị

    • Theo nhiều nguồn, Monarch là một framework thử nghiệm của PyTorch chứ không phải sản phẩm thay thế
      Có lẽ vẫn sẽ được tiếp tục tận hưởng đồ thị chu trình dựa trên std::shared_ptr và rò rỉ bộ nhớ
      Hơi tiếc là họ không viết lại hoàn toàn bằng ngôn ngữ hàm
    • Đây có vẻ không phải phiên bản bị oxy hóa của một dự án hiện có mà là một dự án hoàn toàn mới
  • Tôi đã từng tự làm mở rộng PyTorchmycelya-torch
    Phiên bản của tôi vẫn chưa hỗ trợ giao tiếp giữa các node, nhưng cách Monarch đạt được hiệu năng khá thú vị
    Monarch có lẽ dùng cloudpickle để chia sẻ mã tới tất cả các node, cách này chỉ tốn chi phí thiết lập ban đầu nên khá hiệu quả
    Cấu trúc fan-out thông điệp từ một bộ điều khiển duy nhất cũng rất ấn tượng
    Tuy vậy tôi vẫn tò mò về việc có hỗ trợ kernel tùy chỉnh hay không, cũng như mức độ chi tiết trong việc kiểm soát giao tiếp giữa các actor
    Nhìn chung tôi thích cách tiếp cận này hơn mô hình multi-controller

    • Nếu muốn dùng kernel tùy chỉnh thì có thể phải sửa một chút mã khởi tạo worker từ xa
      Nhưng bạn có thể tự nhúng sẵn (bake-in) các kernel hoặc mã hệ thống cần thiết
  • Cấu trúc này trông khá giống Ray

    • Ví dụ mã gần như y hệt Ray
      Actor của Monarch và lớp @ray.remote của Ray đi theo cùng một mẫu
    • Tôi tò mò vì sao lại dùng Monarch thay vì Ray — có phải vì nó tích hợp chặt hơn với PyTorch hoặc tensor abstraction không
    • Dask cũng xử lý phân tán theo cách tương tự, nhưng vốn dành cho HPC nên hỗ trợ GPU còn hạn chế
      Xem trang chính thức của Dask
    • Tôi cũng đã nghĩ như vậy. Đặc biệt là khi nhìn vào thông báo hợp tác gần đây giữa PyTorch và Ray thì lại càng thấy thế
      Blog liên quan
  • Khá thú vị, về bản chất nó gợi nhớ đến khái niệm Fortran coarray (2008)

    • Hoặc cũng có thể giống Hadoop (2006)
      Chỉ là tốt hơn nhiều vì không cần phải trực tiếp dùng MapReduce hay Fortran
  • Có câu “tránh nút thắt cổ chai của một host đơn lẻ và tận dụng toàn bộ mesh như một cụm phân tán để truyền thông điệp”,
    nếu ai có thể chỉnh sửa được thì tôi muốn họ bổ sung thêm các con số tham chiếu

  • Có vẻ là một dự án tốt
    Tôi có vài thắc mắc

    • Nó có giống openMPI không?
    • Mesh được cấu thành như thế nào? Có chỉ hoạt động trong cùng một host hay không?
  • Đây có thể trở thành một dự án quan trọng trong thế giới coarray, nhưng đã có dấu hiệu vấn đề từ sớm
    Tensor engine bị ràng buộc với CUDA và RDMA (ibverbs), lại là mã dùng GPUDirect RDMA
    Nên cuối cùng có vẻ sự phụ thuộc vào CUDA sẽ còn nặng hơn
    Có lẽ sẽ tốt hơn nếu dùng OpenUCX

  • Trông có vẻ kém chức năng hơn Jax
    Jax dùng trình biên dịch mạnh để tối ưu giao tiếp giữa các node

    • Nhưng Monarch tập trung vào mô hình bộ điều khiển đơn, trong khi Jax là kiến trúc SPMD đa bộ điều khiển
      Bộ điều khiển đơn thì dễ hiểu hơn, còn đa bộ điều khiển thì tối ưu hơn cho một số dataflow nhất định
      Cũng có những thử nghiệm thú vị pha trộn cả hai cách tiếp cận này