paint-brush
Tổng quan về bối cảnh trình tải dữ liệu: Thiết lập thử nghiệmtừ tác giả@serialization
155 lượt đọc

Tổng quan về bối cảnh trình tải dữ liệu: Thiết lập thử nghiệm

từ tác giả The Serialization Publication6m2024/06/04
Read on Terminal Reader

dài quá đọc không nổi

Trong bài viết này, các nhà nghiên cứu nhấn mạnh trình tải dữ liệu là chìa khóa để cải thiện hoạt động đào tạo ML, so sánh các thư viện về chức năng, khả năng sử dụng và hiệu suất.
featured image - Tổng quan về bối cảnh trình tải dữ liệu: Thiết lập thử nghiệm
The Serialization Publication HackerNoon profile picture
0-item

tác giả:

(1) Iason Ofeidis, Khoa Kỹ thuật Điện và Viện Khoa học Mạng Yale, Đại học Yale, New Haven {Đóng góp ngang bằng};

(2) Diego Kiedanski, Khoa Kỹ thuật Điện và Viện Khoa học Mạng Yale, Đại học Yale, New Haven {Đóng góp ngang bằng};

(3) Leandros TassiulasLevon Ghukasyan, Activeloop, Mountain View, CA, USA, Khoa Kỹ thuật Điện và Viện Khoa học Mạng Yale, Đại học Yale, New Haven.

Bảng liên kết

3. THIẾT LẬP THỬ NGHIỆM

Một số thư viện và bộ dữ liệu đã được chọn để so sánh các tính năng và hiệu suất của chúng. Mặc dù đã nỗ lực để trở nên dễ hiểu nhất có thể nhưng lĩnh vực tải dữ liệu vẫn không ngừng phát triển và các thư viện cũng như bản phát hành mới được thêm vào mỗi ngày. Về vấn đề này, chúng tôi hy vọng danh sách sau đây sẽ cung cấp cái nhìn tổng quan tốt về khả năng hiện tại của trình tải dữ liệu mà không nhất thiết phải yêu cầu hoặc tìm ra giải pháp tổng thể tốt nhất (có thể sẽ thay đổi từ thời điểm viết bài đến thời điểm xuất bản). Chúng tôi cung cấp tất cả mã nguồn của các thử nghiệm cho công chúng và mong đợi kết quả có thể được tái tạo đầy đủ.


Chúng tôi đã chọn bảy thư viện để thực hiện các thử nghiệm của mình: PyTorch (Paszke và cộng sự, 2019), Torchdata (TorchData, 2021), Hub (Team, 2022a), FFCV (Leclerc et al., 2022), Webdatasets (Webdataset, 2013), Sóc (Nhóm, 2022b) và Hồ sâu (Hambardzumyan và cộng sự, 2022). Một điều thú vị mà chúng tôi phát hiện ra là không phải tất cả thư viện đều hỗ trợ các tính năng giống nhau. Ví dụ: chúng tôi không thể chạy FCV với tập dữ liệu được lưu trữ trong nhóm S3 để thực hiện các thử nghiệm từ xa của mình. Như chúng tôi đã đề cập trong Phần 1, chúng tôi chạy tất cả thử nghiệm của mình trong PyTorch. Chúng tôi đã cân nhắc việc tái tạo các thử nghiệm trong các khung học máy phổ biến khác nhưng chúng tôi đã quyết định phản đối ý tưởng này vì ứng cử viên thứ hai sẽ là Tensorflow, nhưng có tin đồn rằng Google đang rời bỏ nó để chuyển sang JAX. Hình 1 mô tả mức độ phổ biến của các khung ML khác nhau trong 12 tháng qua.

3.1 Bộ dữ liệu

Về bộ dữ liệu, ban đầu chúng tôi đã chọn hai bộ dữ liệu cổ điển để hỗ trợ hai nhiệm vụ học tập khác nhau: CIFAR-10 (Krizhevsky và cộng sự, 2009) để phân loại hình ảnh và CoCo (Lin và cộng sự, 2014) để phát hiện đối tượng. Trong khi thực hiện một số thử nghiệm, chúng tôi đã quan sát thấy hành vi kỳ lạ (thư viện hoạt động tốt hơn mong đợi) có thể được giải thích bằng


Hình 1. Mức độ phổ biến của các khung ML khác nhau trong 12 tháng qua


CIFAR-10 lắp vào bộ nhớ [2]. Vì lý do này, chúng tôi đã xây dựng tập dữ liệu thứ ba có tên RANDOM, bao gồm các hình ảnh màu được tạo ngẫu nhiên có kích thước 256 x 256 pixel và một lớp ngẫu nhiên trong số 20. Tập dữ liệu thứ ba này chứa 45000 hình ảnh để đào tạo, 5000 hình ảnh để xác thực và 500 hình ảnh để kiểm tra, và nó lớn hơn đáng kể so với CIFAR-10.


Chúng tôi đã sử dụng các phép biến đổi giống nhau cho tất cả các thư viện để làm cho các điểm chuẩn có thể so sánh được. Ngoại lệ duy nhất là FCV, có cách triển khai riêng các phép biến đổi khác nhau. Để phân loại hình ảnh, ngăn xếp chuyển đổi bao gồm các bước sau: Lật ngang ngẫu nhiên, Chuẩn hóa, Cắt bỏ, Chuyển đổi thành Tensor.


Để phát hiện đối tượng, chúng tôi chủ yếu dựa vào việc triển khai các phép biến đổi của Albumentations (Buslaev và cộng sự, 2020). Ngăn xếp trông như sau: Cắt kích thước ngẫu nhiên, Lật ngang ngẫu nhiên, Chuẩn hóa, Chuyển đổi thành Tensor. Những phép biến đổi này áp dụng cho cả hình ảnh và hộp giới hạn.

3.2 Các biến thể thí nghiệm

Khi có thể, chúng tôi đã lưu trữ tập dữ liệu cục bộ và trong bộ chứa tương đương S3. Điều này cho phép chúng tôi đánh giá sự chậm lại do quá trình đào tạo từ luồng dữ liệu qua mạng. Chúng tôi sẽ cung cấp mô tả chi tiết về môi trường đào tạo trong Phần 4.


Vì công việc đào tạo chuyên sâu nhất liên quan đến việc sử dụng nhiều GPU nên bất cứ khi nào có thể, chúng tôi cũng chạy các thử nghiệm tương tự trong môi trường có nhiều đơn vị GPU. Vì tại thời điểm chạy thử nghiệm, không phải tất cả thư viện đều hỗ trợ đầy đủ PyTorch Lightning nên chúng tôi đã quyết định triển khai đa GPU bằng thư viện Song song dữ liệu phân tán (DDP) (Li et al., 2020) từ PyTorch.


Đối với một số dự án học máy, chúng tôi có thể chỉ cần quyền truy cập vào một tập hợp con của tập dữ liệu lớn hơn. Đối với những trường hợp đó, khả năng lọc nhanh các điểm dữ liệu cần thiết mà không cần phải lặp lại toàn bộ tập dữ liệu có thể giảm đáng kể tổng thời gian đào tạo. Một số thư viện cho phép lọc dựa trên một số tính năng nhất định, chẳng hạn như lớp (đối với tác vụ phân loại hình ảnh). Chúng tôi đã khám phá mức tăng (hoặc giảm) về tốc độ khi sử dụng phương pháp lọc do thư viện cung cấp (trong trường hợp thư viện cung cấp phương pháp này) so với hoàn toàn không lọc. Bất cứ khi nào thư viện không cung cấp phương pháp lọc, chúng tôi sẽ triển khai chúng một cách ngây thơ, tức là quét toàn bộ tập dữ liệu và chỉ giữ lại những phần tử phù hợp với điều kiện đã chỉ định. Việc thực hiện lọc nhanh không nhất thiết phải đơn giản vì nó yêu cầu duy trì một cấu trúc bổ sung giống như chỉ mục để tránh lặp lại trên tất cả các mẫu.


Cuối cùng, Bảng 1 chỉ rõ khả năng tương thích của các thư viện khác nhau với các thử nghiệm và bộ dữ liệu khác nhau mà chúng tôi đã khám phá trong bài viết này.

3.3 Số liệu

Ưu tiên chính của chúng tôi khi xây dựng thử nghiệm là tìm ra thước đo khách quan cho phép chúng tôi so sánh tất cả các thư viện khác nhau theo cách hợp lý.


Số liệu lý tưởng sẽ là tổng thời gian thực hiện công việc đào tạo vì đây là khoảng thời gian chúng tôi phải chờ đợi và chi trả. Thật không may, điều đó sẽ hạn chế rất nhiều số lượng thí nghiệm chúng tôi có thể thực hiện. Sau khi cân nhắc cẩn thận, chúng tôi đã chọn số lượng điểm dữ liệu (hình ảnh) được xử lý mỗi giây, kết quả được hỗ trợ bởi các thử nghiệm số học của chúng tôi. Chúng tôi xem xét hai biến thể của số liệu này: một trong đó chúng tôi sử dụng mô hình ML để huấn luyện và thực hiện lan truyền ngược và một trong đó chúng tôi không sử dụng mô hình ML và chỉ lặp lại các mẫu, sao chép chúng vào GPU. Sự khác biệt giữa hai số liệu có thể được đánh giá cao từ mã giả của vòng huấn luyện trong Thuật toán 1, trong đó m biểu thị biến tốc độ. Chúng tôi cũng đã thu thập tổng thời gian chạy[3] và thời gian cần thiết để khởi tạo trình tải dữ liệu. Điều thứ hai được thúc đẩy bởi thực tế là một số thư viện có thể thực hiện trước các phép tính tốn kém để tăng tốc độ trong khi đào tạo. Cuối cùng, chúng tôi cũng đã thực hiện khởi động để tính toán tốc độ. Điều này sẽ được thảo luận thêm trong Tiểu mục 3.5.


3.4 Mối tương quan giữa tốc độ và thời gian chạy


Bảng 1. So sánh các thư viện khác nhau và sự hỗ trợ của chúng đối với các chức năng được thử nghiệm. (Y)es, được hỗ trợ và thực hiện. (Không được hỗ trợ. (X) không được thực hiện. Đã tìm thấy (W)orkaround, không được hỗ trợ theo mặc định.


Hình 2. Mối tương quan giữa tốc độ trung bình và tổng thời gian tập luyện,

3.5 Xem xét kỹ hơn về thời gian chạy

Để nâng cao hiểu biết của chúng tôi về các cơ chế bên trong trong mỗi thư viện, chúng tôi đã quyết định kiểm tra trong một lần chạy xem mất bao lâu để thực thi mỗi lô cũng như khởi tạo trình tải dữ liệu. Hình 3 mô tả một tổ hợp các tham số [4], thời gian mà mỗi thư viện thực hiện trong các bước được mô tả bởi Thuật toán 1. Tất cả các thử nghiệm này đều có điểm dừng sau 10 đợt.


Điều thú vị là đợt đầu tiên mất nhiều thời gian hơn những đợt khác. Điều này có thể được giải thích như sau: vì hầu hết các trình tải dữ liệu đều dựa vào việc tải từng phần dữ liệu vào thời điểm này, nên các lệnh gọi trong tương lai sẽ được hưởng lợi từ việc tìm nạp trước, dữ liệu đã có trong bộ nhớ và tính năng song song hóa (thực hiện mọi việc trong khi GPU đang bận tính toán).


Kích thước của các dải từ 1 đến 9 cung cấp dấu hiệu tốt nhất về mức độ mở rộng của mỗi thư viện kể từ thời gian thực hiện trên một thư viện.


Hình 3. Kiểm tra thời gian của mỗi thư viện cho một lần mô phỏng.


tập dữ liệu lớn phát triển tuyến tính với chiều rộng đó. Chúng ta có thể quan sát thấy hầu hết các thư viện đều có chiều rộng đồng đều, trong đó Deep Lake là thư viện ngắn nhất (nhanh nhất). Mặt khác, thư viện duy nhất hiển thị chiều rộng không đồng nhất là FFCV, trong đó các dải từ 1 đến 3 mỏng đến mức không thể nhìn thấy chúng trong ảnh.


Giai đoạn tổng kết mất khoảng thời gian như nhau đối với tất cả các thư viện ngoại trừ FCV và Deep Lake, mất nhiều thời gian hơn. Thời gian hoàn thành phần lớn phụ thuộc vào mô hình và không nhất thiết biểu thị quy mô của mỗi thư viện.


Dựa trên hình này, chúng tôi quyết định thực hiện khởi động khi tính toán tốc độ. Điều này có nghĩa là bỏ qua thời gian thực hiện của mẻ đầu tiên trong tất cả các phép tính tốc độ.


Hình 4. Tốc độ là một hàm của kích thước lô cho CIFAR10 trên một GPU.


Bài viết này có sẵn trên arxiv theo giấy phép CC 4.0.


[2] Đây thường là điều được mong đợi và mong đợi trong một số tài liệu đánh giá, nhưng chúng tôi nhận thấy nó không đúng trong một số ứng dụng thực tế liên quan đến các nhóm nhỏ và máy trạm nội bộ.


[3] Đây là khoảng thời gian từ khi bắt đầu mô phỏng cho đến khi kết thúc, trong thực tế thường chỉ có 10 đợt.


[4] Tập dữ liệu RANDOM, GPU đơn, 0 công nhân, kích thước lô 64

L O A D I N G
. . . comments & more!

About Author

The Serialization Publication HackerNoon profile picture
The Serialization Publication@serialization
We cover the most cutting edge academic research and expert blog posts on serialization. Also big fans of the Serial pod

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...