Người được uỷ quyền LiteRT

Uỷ quyền cho phép tăng tốc phần cứng của các mô hình LiteRT bằng cách tận dụng các trình tăng tốc trên thiết bị, chẳng hạn như GPU và Bộ xử lý tín hiệu số (DSP).

Theo mặc định, LiteRT sử dụng các nhân CPU được tối ưu hoá cho tập lệnh ARM Neon. Tuy nhiên, CPU là một bộ xử lý đa năng không nhất thiết phải được tối ưu hoá cho số học phức tạp thường thấy trong các mô hình Học máy (ví dụ: phép toán ma trận liên quan đến các lớp tích chập và dày đặc).

Mặt khác, hầu hết điện thoại di động hiện đại đều có các chip xử lý tốt hơn trong việc xử lý các thao tác nặng này. Việc sử dụng các thiết bị này cho các hoạt động của mạng nơ-ron mang lại nhiều lợi ích về độ trễ và hiệu suất sử dụng năng lượng. Ví dụ: GPU có thể tăng tốc độ lên đến 5 lần về độ trễ.

Mỗi trình tăng tốc này đều có các API liên kết cho phép hoạt động tính toán tuỳ chỉnh, chẳng hạn như OpenCL hoặc OpenGL ES cho GPU di động. Thông thường, bạn sẽ phải viết nhiều mã tuỳ chỉnh để chạy một mạng nơ-ron thông qua các giao diện này. Mọi thứ trở nên phức tạp hơn khi bạn xem xét rằng mỗi trình tăng tốc đều có ưu và nhược điểm riêng và không thể thực hiện mọi thao tác trong mạng nơ-ron. Delegate API của TensorFlow Lite giải quyết vấn đề này bằng cách đóng vai trò là cầu nối giữa thời gian chạy TFLite và các API cấp thấp này.

thời gian chạy có các uỷ quyền

Chọn người uỷ quyền

LiteRT hỗ trợ nhiều đại biểu, mỗi đại biểu được tối ưu hoá cho(các) nền tảng nhất định và các loại mô hình cụ thể. Thông thường, sẽ có nhiều đại biểu áp dụng cho trường hợp sử dụng của bạn, tuỳ thuộc vào 2 tiêu chí chính: Nền tảng (Android hay iOS?) mà bạn nhắm đến và Loại mô hình (dấu phẩy động hay định lượng?) mà bạn đang cố gắng tăng tốc.

Số người được uỷ quyền theo nền tảng

Nhiều nền tảng (Android và iOS)

  • Uỷ quyền GPU – Bạn có thể sử dụng uỷ quyền GPU trên cả Android và iOS. Thư viện này được tối ưu hoá để chạy các mô hình dựa trên số thực 32 bit và 16 bit khi có GPU. Thư viện này cũng hỗ trợ các mô hình được lượng tử hoá 8 bit và cung cấp hiệu suất GPU tương đương với các phiên bản số thực. Để biết thông tin chi tiết về uỷ quyền GPU, hãy xem phần LiteRT trên GPU.

iOS

  • Uỷ quyền Core ML cho iPhone và iPad mới – Đối với iPhone và iPad mới có Neural Engine, bạn có thể dùng uỷ quyền Core ML để tăng tốc suy luận cho các mô hình dấu phẩy động 32 bit hoặc 16 bit. Neural Engine có trên các thiết bị di động của Apple có SoC A12 trở lên. Để biết thông tin tổng quan về uỷ quyền Core ML và hướng dẫn từng bước, hãy xem Uỷ quyền Core ML LiteRT.

Uỷ quyền theo loại mô hình

Mỗi bộ tăng tốc được thiết kế với một độ rộng bit nhất định của dữ liệu. Nếu bạn cung cấp một mô hình dấu phẩy động cho một đại biểu chỉ hỗ trợ các thao tác được lượng tử hoá 8 bit, thì mô hình đó sẽ từ chối tất cả các thao tác và mô hình sẽ chạy hoàn toàn trên CPU. Để tránh những bất ngờ như vậy, bảng dưới đây cung cấp thông tin tổng quan về khả năng hỗ trợ uỷ quyền dựa trên loại mô hình:

Loại mô hình GPU CoreML
Dấu phẩy động (32 bit)
Lượng tử hoá float16 sau huấn luyện
Lượng tử hoá dải tương phản động sau huấn luyện Không
Lượng tử hoá số nguyên sau huấn luyện Không
Huấn luyện có tính đến việc lượng tử hoá Không

Xác thực hiệu suất

Thông tin trong phần này đóng vai trò là hướng dẫn sơ bộ để chọn ra những đại biểu có thể cải thiện ứng dụng của bạn. Tuy nhiên, bạn cần lưu ý rằng mỗi đại biểu có một tập hợp các thao tác được xác định trước mà đại biểu đó hỗ trợ và có thể thực hiện theo cách khác nhau tuỳ thuộc vào mô hình và thiết bị. Do đó, bạn nên thực hiện một số hoạt động đo điểm chuẩn để đánh giá mức độ hữu ích của một uỷ quyền đối với nhu cầu của mình. Điều này cũng giúp biện minh cho việc tăng kích thước nhị phân liên quan đến việc đính kèm một uỷ quyền vào thời gian chạy LiteRT.

LiteRT có nhiều công cụ đánh giá hiệu suất và độ chính xác có thể giúp nhà phát triển tự tin khi sử dụng các uỷ quyền trong ứng dụng của họ. Các công cụ này sẽ được thảo luận trong phần tiếp theo.

Công cụ đánh giá

Độ trễ và mức sử dụng bộ nhớ

Bạn có thể sử dụng công cụ đo điểm chuẩn của LiteRT với các thông số phù hợp để ước tính hiệu suất mô hình, bao gồm độ trễ suy luận trung bình, chi phí khởi tạo, mức sử dụng bộ nhớ, v.v. Công cụ này hỗ trợ nhiều cờ để tìm ra cấu hình uỷ quyền tốt nhất cho mô hình của bạn. Ví dụ: bạn có thể chỉ định --gpu_backend=gl bằng --use_gpu để đo lường quá trình thực thi GPU bằng OpenGL. Danh sách đầy đủ các tham số uỷ quyền được hỗ trợ được xác định trong tài liệu chi tiết.

Sau đây là ví dụ về một lần chạy cho mô hình được lượng tử hoá bằng GPU thông qua adb:

adb shell /data/local/tmp/benchmark_model \
  --graph=/data/local/tmp/mobilenet_v1_224_quant.tflite \
  --use_gpu=true

Bạn có thể tải phiên bản dựng sẵn của công cụ này cho Android, kiến trúc ARM 64 bit tại đây (xem thêm thông tin chi tiết).

Độ chính xác và tính chính xác

Các đại biểu thường thực hiện các phép tính với độ chính xác khác với các đối tượng CPU tương ứng. Do đó, có một sự đánh đổi về độ chính xác (thường là không đáng kể) liên quan đến việc sử dụng một uỷ quyền để tăng tốc phần cứng. Xin lưu ý rằng điều này không phải lúc nào cũng đúng; ví dụ: vì GPU sử dụng độ chính xác dấu phẩy động để chạy các mô hình được lượng tử hoá, nên có thể có một chút cải thiện về độ chính xác (ví dụ: Cải thiện dưới 1% trong 5 kết quả hàng đầu về phân loại hình ảnh ILSVRC).

LiteRT có 2 loại công cụ để đo lường mức độ chính xác của một đại biểu đối với một mô hình nhất định: Dựa trên tác vụKhông phụ thuộc vào tác vụ. Tất cả các công cụ được mô tả trong phần này đều hỗ trợ các tham số uỷ quyền nâng cao mà công cụ đo điểm chuẩn trong phần trước sử dụng. Xin lưu ý rằng các mục phụ bên dưới tập trung vào đánh giá uỷ quyền (Liệu đại biểu có thực hiện giống như CPU không?) thay vì đánh giá mô hình (Bản thân mô hình có phù hợp với nhiệm vụ không?).

Đánh giá dựa trên nhiệm vụ

LiteRT có các công cụ để đánh giá độ chính xác của hai nhiệm vụ dựa trên hình ảnh:

Bạn có thể tìm thấy các tệp nhị phân được tạo sẵn của những công cụ này (Android, kiến trúc ARM 64 bit) cùng với tài liệu tại đây:

Ví dụ dưới đây minh hoạ đánh giá phân loại hình ảnh bằng GPU trên Pixel 4:

adb shell /data/local/tmp/run_eval \
  --model_file=/data/local/tmp/mobilenet_quant_v1_224.tflite \
  --ground_truth_images_path=/data/local/tmp/ilsvrc_images \
  --ground_truth_labels=/data/local/tmp/ilsvrc_validation_labels.txt \
  --model_output_labels=/data/local/tmp/model_output_labels.txt \
  --output_file_path=/data/local/tmp/accuracy_output.txt \
  --num_images=0 # Run on all images. \
  --use_gpu=true

Kết quả đầu ra dự kiến là danh sách K chỉ số hàng đầu từ 1 đến 10:

Top-1 Accuracy: 0.733333
Top-2 Accuracy: 0.826667
Top-3 Accuracy: 0.856667
Top-4 Accuracy: 0.87
Top-5 Accuracy: 0.89
Top-6 Accuracy: 0.903333
Top-7 Accuracy: 0.906667
Top-8 Accuracy: 0.913333
Top-9 Accuracy: 0.92
Top-10 Accuracy: 0.923333

Đánh giá độc lập với nhiệm vụ

Đối với những tác vụ chưa có công cụ đánh giá trên thiết bị hoặc nếu bạn đang thử nghiệm các mô hình tuỳ chỉnh, thì LiteRT có công cụ Inference Diff (So sánh suy luận). (Android, tệp nhị phân kiến trúc nhị phân ARM 64 bit tại đây)

Inference Diff so sánh việc thực thi LiteRT (về độ trễ và độ lệch giá trị đầu ra) trong hai chế độ cài đặt:

  • Suy luận CPU đơn luồng
  • Suy luận do người dùng xác định – do các tham số này xác định

Để làm như vậy, công cụ này sẽ tạo dữ liệu Gaussian ngẫu nhiên và truyền dữ liệu đó qua hai Trình thông dịch TFLite – một trình thông dịch chạy các nhân CPU đơn luồng và trình thông dịch còn lại được tham số hoá theo các đối số của người dùng.

Nó đo độ trễ của cả hai, cũng như độ chênh tuyệt đối giữa các tensor đầu ra của mỗi Trình thông dịch, trên cơ sở từng phần tử.

Đối với một mô hình có một tensor đầu ra, đầu ra có thể có dạng như sau:

Num evaluation runs: 50
Reference run latency: avg=84364.2(us), std_dev=12525(us)
Test run latency: avg=7281.64(us), std_dev=2089(us)
OutputDiff[0]: avg_error=1.96277e-05, std_dev=6.95767e-06

Điều này có nghĩa là đối với tensor đầu ra tại chỉ mục 0, các phần tử từ đầu ra CPU khác với đầu ra uỷ quyền trung bình là 1.96e-05.

Xin lưu ý rằng việc diễn giải những con số này đòi hỏi kiến thức sâu hơn về mô hình và ý nghĩa của từng tensor đầu ra. Nếu đó là một hồi quy đơn giản xác định một loại điểm số hoặc việc nhúng nào đó, thì sự khác biệt phải thấp (nếu không, đó là lỗi với uỷ quyền). Tuy nhiên, các đầu ra như "lớp phát hiện" của mô hình SSD sẽ khó diễn giải hơn một chút. Ví dụ: công cụ này có thể cho thấy sự khác biệt, nhưng điều đó không có nghĩa là uỷ quyền có vấn đề thực sự: hãy xem xét 2 lớp (giả): "TV (ID: 10)", "Màn hình (ID: 20)" – Nếu một uỷ quyền hơi khác so với sự thật và cho thấy màn hình thay vì TV, thì sự khác biệt về đầu ra cho tensor này có thể cao đến mức 20 – 10 = 10.