Edge AI: khi nào chạy inference tại thiết bị, khi nào gửi lên cloud
Chi tiêu hạ tầng AI toàn cầu tăng gấp đôi trong một năm, và inference — không phải training — đang chiếm phần lớn khối chi tiêu đó. Nhưng câu hỏi quan trọng hơn với hệ thống IoT không phải 'chạy AI ở đâu rẻ nhất', mà là bốn yếu tố quyết định cụ thể: độ trễ, băng thông, chi phí, và dữ liệu nhạy cảm.
Theo IDC, chi tiêu hạ tầng AI toàn cầu đã tăng hơn gấp đôi từ năm 2024 sang 2025 và dự kiến tiếp tục tăng mạnh trong những năm tới. Một dịch chuyển quan trọng đi kèm: theo nhiều phân tích ngành trong năm 2026, inference — không phải training — hiện chiếm phần lớn khối chi tiêu compute AI của các hyperscaler, phản ánh việc doanh nghiệp đã chuyển từ giai đoạn thử nghiệm sang triển khai AI ở quy mô sản xuất thật. Với hệ thống IoT, dịch chuyển này đặt ra một câu hỏi kiến trúc cụ thể: khi model đã sẵn sàng, nó nên chạy tại thiết bị (edge) hay gửi dữ liệu lên cloud để suy luận? Câu trả lời không phải một quy tắc chung, mà phụ thuộc vào bốn yếu tố cụ thể của từng bài toán.
Bốn yếu tố quyết định
- **Độ trễ** — hệ thống có cần phản hồi trong vài chục mili-giây (dừng khẩn cấp, điều khiển robot, phanh tự động) hay có thể chấp nhận vài giây đến vài phút (báo cáo, phân tích xu hướng)?
- **Băng thông** — dữ liệu đầu vào là gì và khối lượng bao nhiêu? Video độ phân giải cao hay dữ liệu rung động lấy mẫu hàng nghìn Hz tạo ra lưu lượng lớn hơn nhiều so với vài giá trị cảm biến mỗi giây
- **Chi phí** — chi phí truyền toàn bộ dữ liệu thô lên cloud liên tục so với chi phí đầu tư phần cứng biên một lần — phép tính này phụ thuộc vào số lượng thiết bị và thời gian vận hành
- **Dữ liệu nhạy cảm** — dữ liệu có bị ràng buộc bởi quy định hoặc hợp đồng không được rời khỏi site hay không (hình ảnh giám sát, dữ liệu sản xuất mật, thông tin cá nhân)
Khi nào edge thắng
Edge AI phù hợp nhất khi ít nhất một trong các điều kiện sau xuất hiện: cần phản hồi thời gian thực dưới 100ms mà một round-trip lên cloud không thể đáp ứng; kết nối mạng không ổn định hoặc không có ở địa điểm triển khai; dữ liệu quá lớn để truyền liên tục (video, audio, rung động tần số cao) khiến chi phí băng thông vượt xa chi phí phần cứng biên; hoặc dữ liệu bị ràng buộc không được rời khỏi site. Trong hệ thống predictive maintenance cho 4 nhà máy thép mà chúng tôi đã triển khai, mô hình dự báo failure từ dữ liệu rung động và camera nhiệt chạy ngay tại edge — không phải vì cloud không đủ mạnh, mà vì độ trễ round-trip không đáp ứng được yêu cầu phát hiện sự cố trước khi nó xảy ra, và vì truyền toàn bộ dữ liệu rung động tần số cao từ 3.200 cảm biến lên cloud liên tục là bài toán băng thông không thực tế.
Khi nào cloud vẫn thắng
Cloud vẫn là lựa chọn đúng khi: model cần độ chính xác cao hơn những gì một model đã quantize xuống vừa phần cứng biên có thể đạt được — như đã phân tích trong bài VRAM và HBM quan trọng thế nào trong hạ tầng AI, một model 70B quantize xuống vừa một thiết bị biên nhỏ đánh đổi đáng kể độ chính xác so với chạy đầy đủ trên GPU cloud; khối lượng inference thấp hoặc không liên tục, khiến chi phí duy trì phần cứng biên nhàn rỗi phần lớn thời gian cao hơn chi phí gọi API theo request; hoặc model cần cập nhật thường xuyên và việc đồng bộ phiên bản mới ra hàng nghìn thiết bị biên phức tạp hơn nhiều so với cập nhật một endpoint trung tâm.
Kiến trúc hybrid: edge tiền xử lý, cloud xử lý sâu
Trong thực tế, phần lớn hệ thống IoT trưởng thành không chọn một trong hai — mà dùng edge cho một lớp lọc/tiền xử lý nhẹ (phát hiện bất thường đơn giản, nén dữ liệu, quyết định khi nào cần gửi lên cloud), và dành các phân tích sâu hơn, ít nhạy cảm về độ trễ cho cloud. Việc chọn kích thước và mức quantization phù hợp cho model chạy tại edge — một chủ đề chúng tôi phân tích sâu hơn trong bài về triển khai Qwen3-VL cho computer vision — quyết định trực tiếp việc model có vừa được với phần cứng biên như Jetson, Coral TPU, hay vi điều khiển chạy TFLite Micro/ONNX Runtime hay không. Cùng nguyên tắc hot path/cold path mà chúng tôi áp dụng khi thiết kế database cho IoT time-series — dữ liệu gần nhất xử lý nhanh ở một lớp, dữ liệu lịch sử phân tích sâu ở lớp khác — cũng áp dụng cho việc chia inference giữa edge và cloud.
Một lưu ý quan trọng: model quantize cho edge không tự động 'đủ tốt'
Một model đã quantize để vừa phần cứng biên không nhất thiết giữ nguyên năng lực trên mọi loại input — đúng nguyên tắc jagged frontier mà chúng tôi đã phân tích: một model hoạt động tốt trên tập test không tự động đảm bảo hoạt động tốt trên mọi input thực tế, và quantization có thể làm giảm độ chính xác không đồng đều giữa các loại input khác nhau. Trước khi triển khai một model quantize ra hàng loạt thiết bị biên, cần test riêng trên chính loại dữ liệu thực tế của bài toán — không suy luận từ benchmark chung của model gốc.
Kết luận
Quyết định edge hay cloud cho AI inference không nên bắt đầu từ câu hỏi 'cái nào rẻ hơn' mà từ bốn yếu tố cụ thể: độ trễ yêu cầu, băng thông dữ liệu đầu vào, cấu trúc chi phí theo quy mô, và ràng buộc dữ liệu nhạy cảm. Phần lớn hệ thống IoT trưởng thành không chọn một cực mà thiết kế kiến trúc hybrid — đúng cách chúng tôi tiếp cận lớp IoT & Sensors trong mỗi Pilot Build. Liên hệ nếu hệ thống của bạn đang cần đánh giá lại nơi AI nên chạy.
Bài viết liên quan
AI + IoT trong vườn rau sạch thông minh — cảm biến, mô hình và vòng lặp tự động
Một vườn rau sạch đạt chuẩn VietGAP không còn đồng nghĩa với người nông dân phải thức đêm theo dõi độ ẩm hay tưới theo cảm tính. Kiến trúc kết hợp cảm biến IoT đa thông số, mô hình AI phát hiện sâu bệnh qua camera, và vòng lặp điều khiển tự động chạy ngay tại edge — cùng cách traceability VietGAP trở thành sản phẩm phụ tự nhiên của logging đầy đủ.
LoRaWAN, MQTT hay NB-IoT: chọn giao thức kết nối cho hệ thống IoT công nghiệp
Ba tên hay xuất hiện cùng nhau khi thiết kế hệ thống IoT — nhưng chúng không phải ba lựa chọn thay thế nhau. LoRaWAN và NB-IoT là wireless radio protocols quyết định range và battery life; MQTT là messaging protocol chạy bên trên. Hiểu đúng vai trò từng lớp giúp tránh được một số lỗi kiến trúc tốn kém.
Đọc một phần file point cloud khổng lồ: classification, octree và COPC cho dữ liệu LAS/LAZ/PTS
Một file LiDAR LAS/LAZ quét một nhà máy hay một tuyến đường có thể nặng vài chục GB và chứa hàng tỷ điểm. Phần lớn tác vụ thực tế — chỉ lấy điểm mặt đất, chỉ lấy một công trình trong một khu vực, hoặc chỉ tải bản xem trước độ phân giải thấp — không cần đọc toàn bộ file. Cách LAS/LAZ/PTS tổ chức classification, bounding box và octree, và cách PDAL, Entwine, COPC khai thác chúng để chỉ tải đúng phần điểm cần — giảm tải hệ thống và tăng tốc xử lý dữ liệu 3D quy mô lớn.