Tối ưu suy luận thị giác trên thiết bị biên

• Camera trong thiết bị
• Chip suy luận tại chỗ
• Đám mây nằm ngoài bước xử lý

Bắt đầu bằng giới hạn của ứng dụng

Trước khi đổi mô hình, xác định câu trả lời cần dùng để làm gì. Nếu ứng dụng chỉ cần phát hiện xe trong từng ảnh, một khung hình đến muộn có thể vẫn hữu ích. Nếu cần theo dõi vật đang chuyển động, kết quả quá trễ có thể mô tả vị trí đã cũ. Ghi điểm bắt đầu khi khung hình được giao cho chương trình và điểm kết thúc khi kết quả sẵn sàng cho ứng dụng; thời gian đó là độ trễ suy luận của pipeline đã chọn, không nhất thiết là tổng thời gian từ lúc camera phơi sáng.

Chọn trước tiêu chí chất lượng: ví dụ phải phát hiện được nhóm vật nào, tỷ lệ bỏ sót nào cần giảm, và lỗi nào không chấp nhận. Không có một ngưỡng chung cho mọi nhiệm vụ. Ghi phiên bản mô hình, kích thước ảnh đầu vào, cấu hình thiết bị, cách đo và bộ ảnh kiểm thử để lần so sánh sau có cùng điều kiện.

Lập đường cơ sở rồi đổi từng yếu tố

Chạy cấu hình ban đầu trên cùng bộ ảnh hoặc video đại diện. Đo thời gian suy luận, tốc độ khung hình nếu xử lý liên tục, RAM đỉnh và năng lượng tiêu thụ trong cùng khoảng quan sát. Ghi chất lượng trên các nhãn đã biết, đặc biệt ở cảnh khó. FPS là số khung xử lý mỗi giây; nó không nói riêng một khung cần bao lâu, nên báo cáo cả thời gian theo khung và cách tính tốc độ tổng thể.

Sau đó thử các thay đổi có thể đảo ngược, mỗi lần một thay đổi:

• Giảm kích thước ảnh đầu vào. Ít điểm ảnh thường giảm phép tính, nhưng vật nhỏ mất chi tiết. Đối chiếu lại tỷ lệ nhận đúng theo nhóm kích thước, không chỉ thời gian chạy.
• Chọn mô hình gọn hơn. Mô hình nhỏ có thể cần ít bộ nhớ và tính toán hơn, nhưng có thể nhầm nhiều hơn. Chỉ chấp nhận nếu tập kiểm thử vẫn đạt yêu cầu của ứng dụng.
• Lượng tử hóa. Cách biểu diễn số gọn hơn có thể giúp giảm chi phí tính toán hoặc lưu trữ trên phần cứng hỗ trợ. Sai số số học có thể đổi đầu ra, vì vậy phải đo lại chất lượng trên đúng runtime và thiết bị.
• Tận dụng bộ tăng tốc. GPU hoặc bộ xử lý AI chỉ giúp khi mô hình và runtime dùng được chúng; sao chép dữ liệu giữa CPU và bộ tăng tốc cũng có chi phí. So sánh toàn pipeline thay vì chỉ thời gian kernel.

Hướng dẫn lượng tử hóa của LiteRT cho một trường hợp cụ thể: lượng tử hóa toàn số nguyên cần dữ liệu đại diện để hiệu chuẩn dải giá trị của các tensor thay đổi. Chuyển đổi được mô hình chưa chứng minh chất lượng đã đạt; dữ liệu hiệu chuẩn khác xa dữ liệu sử dụng có thể làm đánh giá thiếu tin cậy. Giữ một bản chưa lượng tử hóa để đối chiếu. Hướng dẫn hiệu năng còn khuyên phân tích từng phép toán để tìm chỗ tiêu tốn thời gian. Đây là các phương án cần đo, không phải bảo đảm tăng tốc trên mọi bo.

Một lượt tối ưu minh họa

Giả sử camera đưa khung hình vào một máy tính biên và ứng dụng xem các hộp phát hiện. Nhóm ghi đường cơ sở cho video cố định, rồi giảm độ phân giải đầu vào. Thời gian xử lý giảm nhưng các vật nhỏ bắt đầu biến mất; họ giữ kích thước cũ hoặc thử mô hình gọn hơn thay vì chấp nhận mất các vật ấy. Tiếp đó họ thử lượng tử hóa và chạy lại cùng video, cùng cấu hình. Nếu tốc độ tốt hơn nhưng lỗi tăng ở cảnh tối, thay đổi chưa đạt tiêu chí đã đặt.

Đây là quy trình đề xuất, không phải kết quả đo của nguồn. Tài liệu ML Kit nói ảnh được co và có thể kéo giãn để phù hợp đầu vào mô hình; điều đó nhắc rằng tiền xử lý là một phần của chất lượng. Hướng dẫn NVIDIA Jetson giới thiệu bộ phát triển cho ứng dụng AI và robot, nhưng không cung cấp một điểm số chung cho mọi mô hình.

Khi nào dừng?

Chọn cấu hình nằm trong cả ba giới hạn: chất lượng cần thiết, thời gian đáp ứng và ngân sách phần cứng. Nếu chỉ có FPS mà không có chất lượng, RAM, điện năng hoặc ranh giới đo thì chưa đủ để gọi là tối ưu. Nhiệt độ, tải đồng thời và thay đổi ánh sáng cũng nên được thử trong kịch bản dự định. Kết quả trên một bo mạch không tự áp dụng cho máy tính khác.

Tóm tắt

• Đặt ngưỡng chất lượng và ranh giới độ trễ trước khi tối ưu.
• Đo đường cơ sở; thay từng yếu tố rồi so lại chất lượng, thời gian, bộ nhớ và năng lượng.
• Ảnh nhỏ, mô hình gọn và lượng tử hóa đều có thể đổi cả tốc độ lẫn khả năng nhận diện.