Edge AI ở nhà máy và cửa hàng: chọn TensorRT, LiteRT hay ExecuTorch

Bạn tới nhà máy với một model phát hiện lỗi đã đạt độ chính xác đẹp trên cloud. Quản đốc dẫn bạn ra dây chuyền và chỉ vào chiếc camera treo trên băng chuyền. Ở đó Wi-Fi chập chờn, tủ điện nóng ran, và anh ấy hỏi đúng một câu: “Chạy được ngay ở đây không?”

Gặp câu hỏi này, nhiều kỹ sư giỏi vẫn lúng túng, vì từ trước tới giờ họ chỉ deploy lên server. Mang model ra hiện trường là một kỹ năng riêng. Bạn phải nắm được ràng buộc vật lý của nơi đặt máy, chọn đúng runtime và lường trước chuyện sẽ có hàng chục địa điểm, mỗi nơi một kiểu phần cứng.

Đây cũng là chỗ FDE tạo ra giá trị mà nhóm làm model ở văn phòng không thay được. Họ giao cho bạn một file checkpoint. Phần việc của bạn là biến nó thành một hệ thống chạy được ở khu vực khách đang sản xuất hoặc bán hàng.

Edge AI giải quyết bài toán gì?

NVIDIA định nghĩa edge AI là triển khai ứng dụng AI trên những thiết bị đặt ngoài đời thực, thay vì trong trung tâm dữ liệu đám mây. IBM nói cụ thể hơn: thuật toán và model chạy thẳng trên thiết bị biên tại chỗ. Định nghĩa thì đơn giản. Cái khó là biết khi nào khách thật sự cần đến nó.

Thường có ba lý do. Lý do đầu là tốc độ: theo IBM, khi toàn bộ việc xử lý diễn ra trên thiết bị, người dùng nhận phản hồi nhanh hơn. Hai lý do còn lại là băng thông và quyền riêng tư, vì NVIDIA mô tả mô hình chỉ đẩy kết quả phân tích lên cloud, còn dữ liệu thô nằm lại tại chỗ.

Hai ví dụ NVIDIA đưa ra rất gần với những gì FDE hay gặp. Ở nhà máy, cảm biến gắn trên thiết bị dò lỗi và báo cho quản lý khi máy cần sửa. Ở cửa hàng bán lẻ, doanh nghiệp muốn cho khách đặt hàng bằng giọng nói để cải thiện trải nghiệm.

Tính thử ngân sách trước khi chọn phần cứng

Thử hình dung một dây chuyền kiểm tra chất lượng có 4 camera. Giả sử mỗi ảnh nặng 200 KB và mỗi camera chụp 10 ảnh/giây. Đẩy toàn bộ ảnh lên cloud nghĩa là 4 × 200 KB × 10 = 8 MB/giây, tức khoảng 64 Mbit/s upload chạy liên tục suốt ca.

Đường truyền của một xưởng sản xuất hiếm khi gánh nổi mức đó một cách ổn định. Nếu chạy model ngay cạnh camera, mỗi lần suy luận chỉ cần gửi lên một bản ghi JSON vài trăm byte, kiểu “camera 2, lỗi trầy, độ tin cậy 0,91”.

Với 40 lần suy luận mỗi giây, đường truyền chỉ còn phải chở cỡ vài chục KB/giây thay vì 8 MB/giây, và ảnh sản phẩm của khách không phải rời khỏi nhà máy.

Đến đây mới tới lượt phần cứng. Theo NVIDIA, Jetson Orin Nano đạt tới 67 TOPS trong form-factor nhỏ nhất của dòng Jetson, với các mức công suất từ 7 W đến 25 W. Dải công suất đó ảnh hưởng trực tiếp tới thiết kế: bạn phải hỏi tủ điện cấp được bao nhiêu và vỏ máy có tản nhiệt được ở mức 25 W hay không.

Tách phần cứng khỏi runtime trước khi chọn

Chỗ hay bị nhầm nhất là đặt Jetson ngang hàng với LiteRT hay ExecuTorch. Jetson là module phần cứng, và phần tối ưu suy luận trên đó thường do TensorRT đảm nhận vì TensorRT nằm sẵn trong bộ phần mềm của NVIDIA.

LiteRT và ExecuTorch là các framework on-device khác; một đời Jetson cụ thể có chạy tốt chúng hay không là điều bạn phải tự kiểm tra trước khi hứa với khách.

Nghĩ theo hai tầng như vậy, bạn sẽ chọn thiết bị theo ràng buộc hiện trường rồi mới chọn runtime theo model và đội của khách.

Runtime thứ nhất là TensorRT, đi cùng phần cứng Jetson. Jetson là module dạng SoM, phải cắm lên carrier board mới chạy được. NVIDIA cung cấp JetPack SDK, bộ phần mềm trọn gói để phát triển và triển khai ứng dụng AI ở edge, trong đó có TensorRT để tối ưu suy luận. Kiểm tra chất lượng trên dây chuyền là một use case điển hình của tổ hợp này.

Runtime thứ hai là LiteRT, tên mới của TensorFlow Lite. Google mô tả LiteRT là framework on-device xây trên nền TFLite, và các trang hướng dẫn TFLite cũ giờ đã chuyển hướng sang đó. Quy trình gồm hai bước: convert model PyTorch, JAX hoặc TensorFlow sang .tflite, rồi lượng tử hóa sau huấn luyện.

LiteRT không chỉ chạy trên điện thoại mà còn đưa được các model nhẹ như phát hiện bất thường hay sensor fusion xuống vi điều khiển và thiết bị nhúng.

Runtime thứ ba dành cho đội đã quen PyTorch. ExecuTorch là phương án thay thế PyTorch Mobile. Nó không dựa vào TorchScript mà dùng compiler và cơ chế export của PyTorch 2. Theo tài liệu PyTorch, ExecuTorch dùng ít bộ nhớ hơn hẳn PyTorch Mobile, và mức bộ nhớ sử dụng có thể thay đổi linh hoạt.

Bảng so sánh đi kèm bài gói lại cách chọn: dây chuyền nhiều camera và có tủ điện thì nghiêng về Jetson với TensorRT, cảm biến rung hay nhiệt trên thiết bị rất nhỏ thì nghiêng về LiteRT trên vi điều khiển, còn app tablet ở quầy do team PyTorch viết thì nghiêng về ExecuTorch. Mỗi lựa chọn đi kèm một câu bạn phải hỏi khách trước khi cam kết.

Quy trình từ checkpoint đến thiết bị

Bước một là viết ra một “ngân sách hiện trường” trước khi động vào code. Trang đó ghi thời gian phản hồi tối đa (chẳng hạn sản phẩm chỉ nằm trong khung hình nửa giây), băng thông upload thực đo, công suất điện và số địa điểm sẽ triển khai. Bạn sẽ dùng chính trang này để thống nhất với khách xem thế nào là “chạy được”.

Bước hai là chọn runtime theo bảng so sánh đi kèm bài, rồi convert. Với LiteRT, đó là xuất ra .tflite và lượng tử hóa. Với ExecuTorch, đó là export bằng công cụ của PyTorch 2. Với TensorRT trên Jetson, đó là tối ưu bằng TensorRT. Dù chọn đường nào, bạn vẫn giữ lại bản model gốc để có cái mà so sánh.

Bước ba là đo lại độ chính xác của bản đã nén trên ảnh thật chụp tại nhà máy khách, đừng chỉ đo trên tập test ở văn phòng. Bước bốn là thiết kế luồng dữ liệu sao cho chỉ kết quả đi lên cloud.

Bước năm là lên kế hoạch cho toàn bộ thiết bị ở các địa điểm: IBM cảnh báo rằng khi mở rộng AI phân tán ra nhiều nơi sẽ gặp các vấn đề data gravity, phần cứng không đồng nhất, quy mô và giới hạn tài nguyên.

Những lỗi đắt giá nhất thường nằm ngoài model

Lỗi phổ biến nhất là chạy benchmark trên bàn làm việc có quạt mát, rồi mang ra tủ điện kín giữa mùa hè. Thiết bị có dải công suất từ 7 W đến 25 W sẽ cho kết quả rất khác nhau tùy chế độ nguồn, nên phải đo đúng ở chế độ sẽ dùng ngoài hiện trường.

Lỗi thứ hai là lượng tử hóa xong không đo lại, đến khi khách thấy tỷ lệ báo lỗi sai tăng lên mới biết.

Lỗi thứ ba là lên kế hoạch như thể mọi thứ còn ở bước demo. Mua module Jetson mà quên carrier board, hay viết tài liệu bàn giao vẫn dùng PyTorch Mobile trong khi đã có ExecuTorch, đều khiến đội vận hành của khách mất thời gian.

Lỗi thứ tư là coi 30 cửa hàng giống hệt nhau, trong khi thực tế mỗi nơi có thể dùng một đời tablet khác.

Với developer Việt Nam muốn chuyển sang FDE, kỹ năng này dễ chứng minh hơn bạn nghĩ. Trong CV, đừng chỉ ghi “biết TensorRT”. Hãy viết một dòng có số liệu: “giảm upload từ 64 Mbit/s xuống vài chục KB/s bằng cách suy luận trên thiết bị, độ chính xác sau lượng tử hóa giảm X điểm”.

Khi đọc job description, hãy để ý các cụm như “on-prem”, “edge” hay “customer site”, vì đó là những vị trí cần đúng kỹ năng này.

Lần tới quản đốc hỏi “chạy được ngay ở đây không?”, câu trả lời tốt nhất là một trang ngân sách hiện trường đã điền đủ số liệu, kèm một con số độ chính xác đo trên chính sản phẩm của họ.