Một mô hình phổ biến mà chúng tôi đã quan sát thấy là việc xây dựng và triển khai mô hình ML cho mục đích sản xuất được thực hiện bởi các nhóm khác nhau, điển hình là nhóm thuật toán ML và nhóm vận hành thiết bị. Nhóm ML xử lý đào tạo và đánh giá mô hình, trong khi nhóm thiết bị chịu trách nhiệm di chuyển mô hình sang môi trường sản xuất.

Sự tách biệt như vậy một phần là do đào tạo và suy luận đã khác nhau, liên quan đến cả nền tảng phần cứng và ngăn xếp phần mềm. Trước đây, chúng tôi sử dụng Caffe trên máy chủ GPU cho cả đào tạo và phục vụ. Ngày nay, mọi người sử dụng các công cụ và máy chủ mạnh mẽ để đào tạo, sau đó triển khai các mô hình cho thời gian chạy được tối ưu hóa cao và các thiết bị đa dạng. Các sự cố triển khai thường gặp phải do độ phức tạp của mô hình và các hạn chế về phần cứng và nhóm ML thường cần dựa vào phản hồi của nhóm vận hành thiết bị để giải quyết các sự cố này.

Do đó, các kỹ sư Máy học (MLE) thường thiếu những hiểu biết rất cơ bản về khả năng triển khai của các mô hình của riêng họ. Việc triển khai mô hình ngày nay thường là một quy trình xây dựng nội bộ bao gồm nhiều tập lệnh Bash/Python trải dài trên các máy và môi trường khác nhau. Nó cũng liên quan đến nhiều thư viện nguồn mở hoặc bộ công cụ dành riêng cho nhà cung cấp để chuyển đổi mô hình, lượng tử hóa, điều chỉnh hiệu suất và xác minh độ chính xác. Đó không phải là một trải nghiệm thú vị so với việc phát triển mô hình trong môi trường Python dựa trên đám mây.

Ngoài sự phức tạp của công cụ, việc thiếu khả năng diễn giải hiệu suất là một vấn đề khác. Lập hồ sơ báo cáo từ các chuỗi công cụ xuôi dòng thường yêu cầu kiến ​​thức về miền để hiểu và chuyển đổi thành thông tin chuyên sâu về mô hình có thể hành động, như trong ví dụ về TensorRT sau đây. Cùng với quy trình chuyển đổi mô hình dài, các nhà phát triển ML rất khó xác định các điểm tắc nghẽn hiệu suất thực tế của các mô hình của riêng họ và thực hiện các thay đổi phù hợp.

Bất chấp những hạn chế này, việc tách biệt thiết kế và triển khai mô hình vẫn là tiêu chuẩn trong ngành, vì chúng thường yêu cầu các bộ kỹ năng hoàn toàn khác nhau. “Việc thuê một chuyên gia ML hoặc một chuyên gia về thiết bị đã khó, huống hồ là chuyên gia của cả hai”, đó là điều chúng tôi luôn lắng nghe khách hàng của mình. Nhưng điều đó không có nghĩa là chúng ta nên tiếp tục chấp nhận quy trình ML hiện tại.

Trong Phần mềm 1.0, thật khó để tưởng tượng rằng một chương trình được viết bởi một kỹ sư và được biên dịch bởi một kỹ sư khác. Các lập trình viên có thể tự biên dịch mã mà không cần biết hoặc có rất ít kiến ​​thức về các giai đoạn cơ bản như lắp ráp và liên kết, trong khi vẫn có thể thu được thông tin chi tiết có ý nghĩa để sửa mã của họ. Nếu không có những hiểu biết sâu sắc như vậy, quá trình gỡ lỗi có thể trở thành một cuộc trao đổi qua lại vô tận giữa hai kỹ sư không nói được ngôn ngữ của nhau.

Cho đến nay, các sự cố phổ biến nhất mà chúng tôi nhận thấy làm trì hoãn việc triển khai các mô hình ML là:

1. Độ trễ/thông lượng không thể chấp nhận được
2. Toán tử không được hỗ trợ
3. độ chính xác không phù hợp

Một quy trình làm việc đơn giản và dễ hiểu để triển khai và chẩn đoán mô hình là giải pháp. Một giao diện mà các kỹ sư ML có thể tự sử dụng và hiểu sẽ cải thiện đáng kể năng suất.

Xây dựng trình biên dịch ML siêu mạnh chỉ là một phần của giải pháp, bởi vì có một số khác biệt cơ bản giữa Phần mềm 2.0 và Phần mềm 1.0: thứ nhất, các toán tử mới liên tục được giới thiệu từ giới hàn lâm và nhiều toán tử trong số chúng không thể bao gồm các toán tử hiện có; thứ hai, các mô hình ML có thể chấp nhận việc thay thế toán tử không bảo toàn chức năng mà vẫn giữ được độ chính xác tương tự, điều này mang lại sự linh hoạt tùy chỉnh hơn cho các nhà phát triển ML. Tuy nhiên, chúng tôi sẽ không đi sâu vào chi tiết vì có lẽ đáng để dành một blog riêng để nói về tùy chỉnh mô hình để triển khai.

Tại OmniML , chúng tôi đã bắt đầu bằng cách xây dựng một công cụ nội bộ để các kỹ sư của mình triển khai và lập hồ sơ các mô hình ML của họ mà không gặp rắc rối khi nghiên cứu phần cứng và chuỗi công cụ ML của nó. Chúng tôi sớm nhận ra khả năng tăng hiệu suất của một công cụ như vậy. Ngoài ra, giao diện thống nhất, giàu thông tin này cho phép cả con người và thuật toán khai thác các cơ hội tối ưu hóa mô hình tuyệt vời. Do đó, các tính năng đó hiện đã chính thức có sẵn trong các sản phẩm của OmniML: Omnimizer và Omnimizer Enterprise .

Omnimizer — một nền tảng triển khai và tối ưu hóa mô hình hợp nhất

Omnimizer được thiết kế chủ yếu cho các kỹ sư ML, những người thiết kế và đào tạo các mô hình PyTorch. Nó giúp họ xác định các lỗi thiết kế và cắt giảm thời gian sản xuất.

Omnimizer cung cấp giao diện dựa trên nền tảng đám mây và dựa trên PyTorch để nhanh chóng kiểm tra một mô hình trên phần cứng mục tiêu. Người dùng chỉ cần chỉ định cấu hình triển khai cấp cao, sau đó gửi yêu cầu đến đám mây thiết bị được lưu trữ trên OmniML. Thông tin triển khai chính, bao gồm độ trễ tổng thể, độ trễ theo từng lớp và lỗi triển khai (nếu có), sẽ được báo cáo lại theo cách đơn giản nhất mà chuyên gia không chuyên về phần cứng có thể hiểu được.

Omnimizer cho phép người dùng so sánh độ chính xác trên thiết bị với mô hình ban đầu một cách dễ dàng. Nó loại bỏ những rắc rối khi chuyển mô hình và dữ liệu sang một thiết bị khác, làm quen với các hệ điều hành và chuỗi công cụ khác nhau, đồng thời duy trì một loạt các tập lệnh vô tổ chức và đầy lỗi. Trong ví dụ sau, người dùng có thể nhận đầu ra mô hình trong giao diện giống PyTorch, trong khi suy luận thực tế diễn ra trên thiết bị từ xa, ví dụ: GPU cấp máy chủ hoặc điện thoại thông minh.

Omnimizer không chỉ là thư viện phần mềm mà còn là nền tảng MLOps cung cấp giao diện thân thiện với người dùng để điều hướng chi tiết hiệu suất, chia sẻ thông tin chi tiết về mô hình và tái tạo môi trường triển khai. Người dùng có thể xem các bước triển khai, lấy độ trễ được đo điểm chuẩn và hiểu rõ hơn về mô hình của họ trên phần cứng.

Omnimizer Enterprise — Giải phóng toàn bộ tiềm năng của phần cứng AI

So với phiên bản cộng đồng hỗ trợ triển khai và tối ưu hóa mô hình, phiên bản doanh nghiệp cung cấp khả năng tối ưu hóa mô hình tự động dựa trên nhiều năm nghiên cứu về Tìm kiếm kiến ​​trúc thần kinh (NAS) và tùy chỉnh mở rộng cho nhu cầu của doanh nghiệp.

NAS luôn được coi là một quy trình tốn kém, đòi hỏi chuyên môn sâu về không gian tìm kiếm và thiết kế tác vụ proxy. Với Omnimizer, mọi người dùng có thể áp dụng NAS để tùy chỉnh mô hình của họ cho phần cứng mục tiêu. Quá trình này chỉ yêu cầu một vài dòng thay đổi mã, chi phí đào tạo thấp và quan trọng nhất là không yêu cầu phải là chuyên gia về thiết kế mô hình và hiệu suất phần cứng.

Omnimizer có thể dễ dàng tích hợp với các kho lưu trữ nguồn mở và tăng tốc các mô hình có sẵn mà không cần tối ưu hóa thủ công. Cho đến nay, OmniML và các khách hàng của nó đã chứng minh tốc độ tăng từ 1,2–6,8 lần trên nền tảng NVIDIA và Qualcomm. Các kho lưu trữ này sẽ được mở cho người dùng doanh nghiệp làm ví dụ:

• YOLO-X (phát hiện đối tượng)
• EfficientDet (phát hiện đối tượng)
• YOLO-P (mô hình đa nhiệm dành cho lái xe tự động)
• DDRNet (phân đoạn ngữ nghĩa)
• ResNet (phân loại hình ảnh)
• DD3D (phát hiện đối tượng 3D)
• RAFT (dòng quang)
• DitilBERT (máy dịch)

Hãy thử Omnimizer!

Omnimizer Beta vừa được phát hành. Đăng ký ngay tại trang web của OmniML và bắt đầu tối ưu hóa quy trình làm việc của bạn!

Di Wu, Song Han, Lucas Liebenwein, Riyad Islam, Keval Morabia, 
Asma K.T. Beevi, Henry Guo and Shengliang Xu also contributed to this article.