- 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) và 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ếp và giả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
Ý 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
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ị
Có lẽ vẫn sẽ được tiếp tục tận hưởng đồ thị chu trình dựa trên
std::shared_ptrvà 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
Tôi đã từng tự làm mở rộng PyTorch — mycelya-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
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
Actorcủa Monarch và lớp@ray.remotecủa Ray đi theo cùng một mẫuXem trang chính thức của Dask
Blog liên quan
Khá thú vị, về bản chất nó gợi nhớ đến khái niệm Fortran coarray (2008)
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
Đâ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
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