Mở đầu — vì sao bài này quan trọng
Cho đến thời điểm này của khóa học, gần như mọi thứ chúng ta nói về AI đều mặc định một điều: model sống trên cloud. Người dùng gõ câu hỏi, request bay lên server của OpenAI hoặc một con GPU thuê ở đâu đó, model trả lời, response bay về. Mô hình này mạnh, linh hoạt, nhưng nó có một giả định ngầm — luôn có internet, luôn sẵn sàng trả tiền cho mỗi token, và người dùng chấp nhận dữ liệu của họ rời khỏi thiết bị.
Có một lớp sản phẩm mà cả ba giả định đó đều sai. Một ứng dụng phiên dịch giọng nói cho hướng dẫn viên du lịch ở vùng cao Hà Giang, nơi sóng 4G chập chờn. Một bàn phím thông minh gợi ý từ tiếng Việt mà người dùng không muốn từng chữ mình gõ bị gửi lên server. Một camera an ninh nhận diện chuyển động lạ, cần phản ứng trong 50 mili-giây chứ không thể chờ round-trip lên cloud. Với những sản phẩm này, câu trả lời nằm ở On-Device AI — chạy model trực tiếp trên điện thoại, laptop, camera, hoặc thiết bị IoT của người dùng, thay vì trên server.
Là AI PM, bạn cần hiểu rõ khi nào on-device là lựa chọn đúng, nó đánh đổi những gì, và nó thay đổi cách bạn thiết kế sản phẩm ra sao. Đây không phải kiến thức phụ — năm 2026, Apple, Google, Samsung đều đẩy mạnh AI chạy ngay trên thiết bị, và đó là xu hướng sẽ định hình một nửa các sản phẩm AI tiêu dùng. Bài này giúp bạn ra quyết định đó một cách tỉnh táo.
Khái niệm cốt lõi
On-device AI là gì
On-device AI (hay edge AI, edge deployment) nghĩa là toàn bộ quá trình inference — tức việc model nhận input và sinh output — diễn ra ngay trên thiết bị của người dùng, không cần gọi tới server bên ngoài. "Edge" ở đây là rìa của mạng: thiết bị cuối cùng nơi dữ liệu được sinh ra và tiêu thụ, đối lập với "cloud" là trung tâm dữ liệu tập trung.
Cần phân biệt rõ với cách triển khai cloud quen thuộc. Trong kiến trúc cloud, thiết bị chỉ là một cái màn hình mỏng (thin client): nó thu input, gửi đi, hiển thị kết quả. Trong kiến trúc on-device, thiết bị tự gánh việc tính toán. Model — thường là một phiên bản nhỏ và được nén — nằm sẵn trong bộ nhớ máy.
Bốn lý do chọn on-device
Có bốn động lực chính khiến một sản phẩm chọn chạy AI trên thiết bị, và bạn nên thuộc lòng chúng vì đây là khung lập luận khi bảo vệ quyết định với team.
Privacy — dữ liệu không rời thiết bị. Đây thường là lý do mạnh nhất. Khi model chạy on-device, dữ liệu nhạy cảm — tin nhắn, hình ảnh y tế, giọng nói, lịch sử gõ phím — không bao giờ phải gửi lên server của bạn hay của bên thứ ba. Điều này giải quyết phần lớn rủi ro tuân thủ (như GDPR ở châu Âu, hay Nghị định 13/2023 về bảo vệ dữ liệu cá nhân ở Việt Nam) ngay từ gốc, vì bạn không thu thập thứ mình không đụng tới.
Latency — không có độ trễ mạng. Một request lên cloud thường mất 100–500 mili-giây chỉ riêng cho việc đi và về, chưa tính thời gian model suy nghĩ. Với on-device, độ trễ mạng bằng không. Những trải nghiệm đòi hỏi phản hồi tức thời — gợi ý gõ phím từng ký tự, làm mờ phông nền video call theo thời gian thực, dịch chữ trên camera khi bạn di chuyển ống kính — chỉ khả thi khi chạy cục bộ.
Offline — hoạt động không cần internet. Sản phẩm chạy được cả khi mất mạng, trên máy bay, trong hầm, ở vùng sóng yếu. Với thị trường Đông Nam Á, nơi vùng nông thôn còn nhiều điểm trắng sóng, đây là lợi thế cạnh tranh thật sự chứ không phải tính năng phụ.
Cost — chi phí biên gần bằng không. Đây là điểm nhiều PM bỏ qua. Mỗi request lên cloud tốn tiền token (nhớ lại Bài 40 về Token Economics). On-device thì người dùng tự gánh chi phí tính toán bằng pin và CPU của họ. Sau khi đã trả chi phí phát triển và tối ưu model, mỗi lần inference thêm gần như miễn phí với bạn. Với sản phẩm có hàng triệu request mỗi ngày, khoản tiết kiệm này khổng lồ.
Cái giá phải trả
Không có bữa trưa miễn phí. On-device đánh đổi bằng những thứ rất cụ thể:
- Năng lực model bị giới hạn. Điện thoại không thể chứa một model 400 tỷ tham số. Bạn buộc phải dùng model nhỏ (small language model — SLM), thường 1–8 tỷ tham số, và chấp nhận chất lượng thấp hơn GPT-4 hay Claude.
- Phân mảnh phần cứng. Mỗi dòng máy có chip, RAM, bộ tăng tốc AI (NPU) khác nhau. Một model chạy mượt trên iPhone 16 Pro có thể giật lag trên một máy Android tầm trung 3 triệu đồng.
- Phân phối và cập nhật khó. Model trên cloud, bạn cập nhật một lần là tất cả người dùng được hưởng. Model on-device phải đẩy qua app update, nặng vài trăm MB, và không phải ai cũng cập nhật.
- Tiêu hao pin và nhiệt. Inference liên tục làm nóng máy và ngốn pin nhanh.
Các kỹ thuật để model "nhỏ lại"
Để nhồi một model vào thiết bị, ta dùng vài kỹ thuật nén. Bạn không cần code chúng, nhưng phải hiểu để nói chuyện với kỹ sư:
Quantization (lượng tử hóa) là kỹ thuật quan trọng nhất. Trọng số model gốc thường lưu ở dạng số thực 16 hoặc 32 bit. Quantization rút gọn xuống 8 bit, 4 bit, thậm chí thấp hơn. Một model 7 tỷ tham số ở 16 bit chiếm khoảng 14GB; xuống 4 bit chỉ còn khoảng 3.5GB — vừa đủ chạy trên điện thoại cao cấp. Đổi lại, độ chính xác giảm nhẹ.
Distillation (chưng cất) là dùng một model lớn (teacher) để dạy một model nhỏ (student) bắt chước hành vi của nó. Model nhỏ giữ được phần lớn năng lực ở kích thước chỉ bằng một phần.
Pruning (cắt tỉa) loại bỏ những trọng số ít quan trọng, làm model thưa hơn và nhẹ hơn.
Về mặt công cụ triển khai, bạn sẽ nghe đến Core ML (Apple), TensorFlow Lite / LiteRT và MediaPipe (Google), ONNX Runtime, llama.cpp với định dạng GGUF cho LLM nhỏ, và MLC LLM. Đây là các runtime giúp model chạy hiệu quả trên NPU và GPU của thiết bị.
Tình huống thực tế
Ví dụ 1 — Apple Intelligence và mô hình hybrid
Năm 2024–2026, Apple triển khai Apple Intelligence với một quyết định kiến trúc rất đáng học. Họ chạy một model on-device khoảng 3 tỷ tham số (đã quantize xuống dưới 4 bit trung bình) ngay trên iPhone để xử lý các tác vụ thường gặp: tóm tắt thông báo, viết lại văn bản, phân loại email. Chỉ khi tác vụ vượt quá năng lực của model nhỏ, hệ thống mới chuyển lên một tầng cloud riêng gọi là Private Cloud Compute.
Diễn giải: Apple không chọn "tất cả on-device" hay "tất cả cloud", mà chọn hybrid. Model nhỏ trên máy giải quyết 80% trường hợp với độ trễ bằng không và privacy tuyệt đối; phần phức tạp còn lại được đẩy lên cloud nhưng vẫn được thiết kế để không lưu dữ liệu. Họ cũng cứng rắn về phần cứng: Apple Intelligence chỉ chạy trên iPhone 15 Pro trở lên vì cần 8GB RAM và NPU đủ mạnh.
Bài học rút ra: Với hầu hết sản phẩm AI tiêu dùng nghiêm túc, câu hỏi không phải "on-device hay cloud" mà là "phần nào on-device, phần nào cloud". Và sẵn sàng chấp nhận thu hẹp tập thiết bị được hỗ trợ để giữ chất lượng — đừng cố nhồi model vào máy yếu rồi để trải nghiệm tệ.
Ví dụ 2 — App phiên dịch cho du lịch vùng cao (bối cảnh Việt Nam)
Hãy hình dung một startup Việt làm app phiên dịch giọng nói cho khách quốc tế đi du lịch Sapa, Hà Giang. Phiên bản đầu họ làm hoàn toàn trên cloud, gọi API speech-to-text và dịch. Kết quả: ở những đoạn đường mất sóng giữa các bản, app đứng hình, và mỗi giây trễ khiến cuộc trò chuyện trực tiếp giữa khách và người bán hàng trở nên gượng gạo.
Họ chuyển sang chạy on-device: một model nhận diện giọng nói nén bằng TensorFlow Lite và một model dịch máy nhỏ cho cặp Anh–Việt, tổng cộng khoảng 200MB tải về khi cài app. Độ chính xác dịch giảm chừng 8% so với bản cloud, nhưng app chạy mượt offline, phản hồi dưới 300ms, và không tốn phí API cho mỗi câu dịch.
Bài học rút ra: Khi yếu tố quyết định thành bại là offline và latency chứ không phải độ chính xác tuyệt đối, on-device thắng rõ ràng. Mức giảm 8% chất lượng là cái giá hoàn toàn chấp nhận được để đổi lấy một sản phẩm dùng được ở nơi nó cần dùng nhất. Là PM, bạn phải biết metric nào là sống còn với người dùng của mình.
Ví dụ 3 — Bàn phím gõ tiếng Việt và quyết định privacy
Một nhóm làm bàn phím thông minh hỗ trợ gõ tiếng Việt thông minh (tự thêm dấu, gợi ý từ tiếp theo). Ban đầu họ định gửi ngữ cảnh gõ lên server để gợi ý tốt hơn. Nhưng khi phỏng vấn người dùng, họ phát hiện rào cản cài đặt lớn nhất chính là nỗi lo: "Bàn phím này có gửi mọi thứ tôi gõ — kể cả mật khẩu, tin nhắn riêng — lên server không?"
Họ quyết định chạy toàn bộ model gợi ý on-device, một model ngôn ngữ nhỏ chuyên cho tiếng Việt được quantize xuống còn vài chục MB. Họ biến chính điều này thành thông điệp marketing: "Mọi thứ bạn gõ ở lại trên máy bạn."
Bài học rút ra: On-device không chỉ là quyết định kỹ thuật — nó là quyết định về lòng tin (liên hệ Bài 37). Với những loại dữ liệu mà người dùng đặc biệt nhạy cảm, việc dữ liệu không rời thiết bị vừa giải quyết rủi ro pháp lý vừa trở thành lợi thế cạnh tranh và điểm bán hàng.
Hướng dẫn từng bước
Đây là quy trình để bạn, với vai trò PM, đánh giá và đưa ra quyết định on-device cho một tính năng AI.
Bước 1 — Xác định ràng buộc cứng của use case. Trả lời thật rõ: Sản phẩm có cần chạy offline không? Có yêu cầu phản hồi dưới 200ms không? Dữ liệu có nhạy cảm tới mức không nên rời thiết bị không? Khối lượng request có lớn tới mức chi phí cloud trở thành gánh nặng không? Nếu câu trả lời cho ít nhất một câu là "có và bắt buộc", on-device đáng cân nhắc nghiêm túc.
Bước 2 — Đánh giá độ phức tạp tác vụ. Tác vụ này có thể giải bằng một model nhỏ 1–8 tỷ tham số không, hay buộc phải có năng lực của model lớn? Phân loại, tóm tắt ngắn, gợi ý từ, nhận diện ảnh đơn giản thường chạy tốt on-device. Suy luận nhiều bước phức tạp thì chưa.
Bước 3 — Khảo sát phần cứng mục tiêu. Người dùng của bạn dùng máy gì? Hãy lấy dữ liệu thật về phân bố thiết bị. Nếu phần lớn dùng máy tầm trung 3–5 triệu đồng, bạn cần model rất nhẹ hoặc một chiến lược fallback lên cloud cho máy yếu.
Bước 4 — Quyết định kiến trúc: thuần on-device hay hybrid. Hiếm khi nên thuần on-device. Thiết kế hybrid: model nhỏ xử lý phần lớn, tự động chuyển lên cloud khi tác vụ vượt năng lực hoặc khi máy đủ mạnh và có mạng. Định nghĩa rõ ngưỡng chuyển.
Bước 5 — Làm việc với kỹ sư về nén và runtime. Chọn kỹ thuật (quantization, distillation) và runtime (Core ML, TensorFlow Lite, ONNX, llama.cpp). Đo kích thước model sau nén, mức tiêu pin, và độ trễ trên thiết bị thật — không phải máy ảo.
Bước 6 — Thiết kế trải nghiệm tải và cập nhật model. Quyết định: model đóng gói sẵn trong app (app nặng hơn) hay tải về lần đầu chạy (cài nhanh nhưng cần mạng lần đầu)? Lên kế hoạch cập nhật model định kỳ.
Bước 7 — Đo lường trên thực địa. Theo dõi độ trễ thực tế, tỷ lệ tác vụ phải fallback lên cloud, mức ảnh hưởng pin, và chất lượng output trên từng nhóm thiết bị.
Lỗi thường gặp & mẹo
Lỗi: Đo benchmark trên máy flagship rồi tưởng cả thị trường chạy được như thế. Kỹ sư test trên iPhone Pro hoặc Pixel mới nhất, thấy mượt, rồi ship. Người dùng thật trên máy tầm trung gặp giật lag và nóng máy. Luôn benchmark trên phổ thiết bị đại diện cho người dùng thật của bạn, gồm cả máy yếu.
Lỗi: Bỏ quên ngân sách pin và nhiệt. Một model chạy mượt về tốc độ nhưng ngốn pin có thể khiến người dùng gỡ app. Hãy coi mức tiêu pin là một metric sản phẩm, không phải chuyện kỹ thuật phụ.
Lỗi: Phóng đại độ chính xác và để người dùng vỡ mộng. Model on-device yếu hơn cloud. Đừng quảng cáo nó ngang GPT-4. Đặt kỳ vọng đúng và thiết kế UX để xử lý nhẹ nhàng khi model sai.
Mẹo: Coi quantization 4-bit là điểm khởi đầu mặc định cho LLM nhỏ. Đây là điểm cân bằng tốt giữa kích thước và chất lượng cho phần lớn use case hiện nay.
Mẹo: Thiết kế fallback graceful, không phải báo lỗi. Khi model on-device không tự tin với output (liên hệ confidence ở Bài 36), hãy âm thầm chuyển lên cloud nếu có mạng, thay vì hiện lỗi cho người dùng.
Mẹo: Biến privacy on-device thành thông điệp, đừng giấu nó. Nếu dữ liệu không rời máy, hãy nói thẳng với người dùng — đó là lợi thế cạnh tranh đáng tiền.
Bài tập thực hành
- Phân loại use case. Lấy 5 tính năng AI bất kỳ bạn đang dùng hằng ngày (gợi ý gõ phím, làm mờ phông video call, chatbot, dịch ảnh, gợi ý nhạc). Với mỗi cái, đánh dấu trong bốn động lực (privacy, latency, offline, cost) cái nào là lý do khiến nó nên hoặc không nên chạy on-device, và đoán xem thực tế nó đang chạy ở đâu.
- Ra quyết định kiến trúc. Bạn là PM của một app ghi chú giọng nói cho bác sĩ tại bệnh viện ở TP.HCM, tự động chuyển giọng nói thành văn bản hồ sơ bệnh án. Viết một đoạn nửa trang lập luận: nên on-device, cloud, hay hybrid? Nêu rõ ràng buộc cứng nào dẫn dắt quyết định và bạn đánh đổi điều gì.
- Lập bảng đánh đổi. Tạo một bảng so sánh cùng một tính năng tóm tắt văn bản khi chạy on-device (model 3B quantize 4-bit) so với cloud (model lớn), trên bốn trục: chất lượng, độ trễ, chi phí biên, privacy. Điền ước lượng định tính và rút ra khuyến nghị.
Tóm tắt
On-device AI là việc chạy model trực tiếp trên thiết bị người dùng thay vì trên cloud, và nó được chọn vì bốn lý do cốt lõi: privacy (dữ liệu không rời máy), latency (không có độ trễ mạng), offline (chạy không cần internet), và cost (chi phí biên gần bằng không). Cái giá phải trả là model yếu hơn, phần cứng phân mảnh, cập nhật khó, và tiêu hao pin. Để khả thi, model được nén bằng quantization, distillation, pruning và chạy qua các runtime như Core ML, TensorFlow Lite, ONNX hay llama.cpp.
Bài học lớn nhất từ ba tình huống — Apple Intelligence, app phiên dịch vùng cao, bàn phím tiếng Việt — là hầu như không bao giờ nên chọn thuần on-device hay thuần cloud, mà nên thiết kế hybrid: model nhỏ trên máy lo phần lớn việc, tự động chuyển lên cloud khi cần. Là AI PM, vai trò của bạn là xác định ràng buộc cứng nào sống còn với người dùng, biết khi nào sự đánh đổi chất lượng là chấp nhận được, và đo lường trên thiết bị thật chứ không phải máy flagship trong phòng họp.