Cuộc cạnh tranh hiệu suất trong xử lý dữ liệu AI đa phương thức: Tại sao Daft đang định nghĩa lại quy trình dữ liệu

Các công cụ dữ liệu truyền thống (Spark, Ray) bắt đầu gặp vấn đề khi xử lý các dữ liệu đa phương thức như hình ảnh, video, âm thanh. Vấn đề nằm ở đâu? Bộ nhớ quá tải, tỷ lệ sử dụng GPU thấp, máy đơn không thể chịu đựng được.

Tại sao dữ liệu đa mô thức lại khó nhằn như vậy

Một bức ảnh JPEG nén, khi được giải mã sẽ phình to gấp 20 lần. Một tệp video có thể tạo ra hàng ngàn khung hình, mỗi khung hình đều có dung lượng vài megabyte. Đồng thời, CPU và GPU phải làm việc cùng nhau - loại tải tính toán hỗn hợp này khiến cho các động cơ truyền thống hoàn toàn bối rối.

Daft vs Ray Data: Sự khác biệt về hiệu suất lớn đến mức nào

Chạy tải công việc thực tế trên cùng một cụm GPU (8 g6.xlarge + NVIDIA L4), kết quả rất rõ ràng:

• Chuyển đổi âm thanh (113.000 tệp): Daft 6 phút 22 giây so với Ray Data 29 phút 20 giây (chênh lệch 4.6 lần)
• Nhúng tài liệu (10.000 PDF): Daft 1 phút 54 giây so với Ray Data 14 phút 32 giây (chênh lệch 7.6 lần)
• Phân loại hình ảnh (800.000 bức): Daft 4 phút 23 giây vs Ray Data 23 phút 30 giây (5,4 lần chênh lệch)
• Kiểm tra video (1000 video): Daft 11 phút 46 giây so với Spark 3 giờ 36 phút (chênh lệch 18.4 lần)

Tại sao khoảng cách lại lớn như vậy

1. Tối ưu hóa gốc vs Tự viết mã

Daft đã tích hợp các thao tác gốc như giải mã hình ảnh, nhúng văn bản, gọi LLM, và được tối ưu hóa cao. Ray Data phụ thuộc vào việc bạn tự viết các hàm Python bằng các thư viện như Pillow, HuggingFace - mỗi thư viện có định dạng dữ liệu riêng của nó, việc chuyển đổi qua lại chính là hố đen hiệu suất.

2. Xử lý theo luồng vs Tích lũy bộ nhớ

Daft sử dụng động cơ thực thi dòng (Swordfish) để giữ cho dữ liệu luôn lưu chuyển: hình ảnh thứ 1000 đang được suy diễn trên GPU, từ hình ảnh thứ 1001 đến 2000 vẫn đang tải xuống và giải mã. Toàn bộ phân vùng sẽ không bao giờ được tải hoàn toàn vào bộ nhớ.

Ray Data có xu hướng gộp các thao tác vào một nhiệm vụ, dễ dẫn đến việc tăng vọt bộ nhớ. Bạn có thể sử dụng lớp để tránh điều này, nhưng điều đó sẽ làm cho kết quả trung gian được vật lý hóa vào bộ nhớ đối tượng, lại tăng thêm chi phí tuần tự hóa. Hơn nữa, bộ nhớ đối tượng mặc định của Ray chỉ chiếm 30% bộ nhớ máy, có nguy cơ đầy bộ nhớ lớn.

3. Phối hợp tài nguyên

Daft cho phép CPU, GPU và mạng hoạt động ở mức tối đa đồng thời. Ray Data mặc định giữ lại một lõi CPU cho các thao tác I/O, dễ dẫn đến việc công việc xử lý của CPU bị kẹt, cần phải điều chỉnh tham số thủ công để tối ưu hóa.

Cách nói về các trường hợp thực tiễn

Đội ngũ Essential AI: Sử dụng Daft để xử lý 236 tỷ tài liệu web từ Common Crawl (24 triệu tỷ token), mở rộng đến 32.000 yêu cầu/giây/VM, đánh giá của họ là - “Nếu sử dụng Spark, chỉ việc cài đặt JVM và điều chỉnh tham số đã mất rất nhiều công sức. Daft chạy nhanh hơn rất nhiều từ máy địa phương, mở rộng ra nhiều máy cũng rất thuận lợi.”

CloudKitchens: Quyết định chuyển toàn bộ cơ sở hạ tầng ML thành “DREAM Stack” (Daft + Ray + Poetry + Argo + Metaflow), vì họ phát hiện ra rằng hiệu suất và chức năng của Ray Data không đủ, Daft đã lấp đầy khoảng trống này.

Kỹ sư ByteDance: Chạy nhiệm vụ phân loại trên 1,3 triệu hình ảnh ImageNet, Daft nhanh hơn Ray Data 20% và còn tiết kiệm tài nguyên hơn.

Khi nào sử dụng Daft, khi nào sử dụng Ray

Chọn Daft: Xử lý dữ liệu đa phương thức, ETL phức tạp, coi trọng độ tin cậy và hiệu suất, thích phong cách DataFrame/SQL

Chọn Ray Data: Muốn tích hợp chặt chẽ Ray Train/Ray Serve, cần cấu hình CPU/GPU chi tiết.

Số liệu quan trọng: Daft nhanh hơn 2-7 lần trong xử lý đa phương thức, nhanh hơn 4-18 lần so với Spark, và ổn định đáng tin cậy. Nếu khối lượng công việc của bạn liên quan đến xử lý phương tiện quy mô lớn, đây không phải là lựa chọn, mà là yêu cầu bắt buộc.