LiteRT.js và cú xoay về AI tại chỗ

LiteRT.js và cú xoay về AI tại chỗ

LiteRT.js không chỉ là runtime mới cho browser. Nó là tín hiệu rằng AI đang dịch chuyển từ cloud-first sang runtime-first.

Có một cảnh mình thấy khá quen ở team làm sản phẩm AI: demo chạy trên laptop của dev thì mượt, lên production thì hóa đơn API bắt đầu gõ cửa như chủ nợ, latency nhảy múa, còn PM hỏi “sao cái nút này bấm 2 giây mới phản hồi?”.

Rồi một release như LiteRT.js xuất hiện. Nếu nhìn hời hợt, bạn sẽ bảo: “À, thêm một cách chạy model trong browser.” Nhưng nếu đọc kỹ hơn, đây là tín hiệu thị trường khá đáng chú ý: AI client-side đang được đóng khung lại như một lớp runtime nghiêm túc, không còn là món demo vui vui trong tab Chrome.

Điểm đáng bàn không phải là LiteRT.js có “xịn nhất” hay không. Điểm đáng bàn là Google đang đưa cùng artifact .tflite vốn dùng trên Android và iOS lên web thông qua JavaScript binding, WebAssembly, WebGPU và thử nghiệm WebNN. Nói cách khác, browser bắt đầu được đối xử như một thiết bị inference thật, không chỉ là mặt tiền gọi API.

Sơ đồ minh họa cho bài LiteRT.js và cú xoay về AI tại chỗ

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu lạ: web không còn chỉ là lớp giao diện

Trước đây, nhiều team web AI có một phản xạ rất tự nhiên: UI ở browser, inference ở server. Browser nhận input, gửi về backend, backend gọi model, trả kết quả. Cách này dễ kiểm soát, dễ logging, dễ billing theo request. Nhưng nó cũng kéo theo ba cục gỗ thô cần bào phẳng: độ trễ, chi phí, và dữ liệu người dùng phải rời thiết bị.

LiteRT.js đi theo hướng khác: chạy trực tiếp model .tflite trong browser. .tflite là định dạng model tối ưu cho on-device inference, tức chạy model ngay trên thiết bị người dùng thay vì gửi mọi thứ lên server. Với LiteRT.js, cùng một artifact có thể phục vụ mobile và web, ít nhất về mặt định hướng runtime.

Đây là chỗ market signal bắt đầu hiện ra. Google không tạo thêm một format model mới để ép hệ sinh thái đi theo. Họ mang runtime native đã có sang web. Với builder, khác biệt này quan trọng: bạn không chỉ chọn “model nào”, bạn đang chọn chuỗi cung ứng inference nào.

Nếu team bạn đã có pipeline export sang .tflite cho mobile, LiteRT.js khiến web trở thành một bề mặt triển khai mới. Không phải mọi thứ tự động chạy ngon, nhưng chi phí tích hợp có thể thấp hơn so với việc duy trì một nhánh web AI riêng.

Mổ lớp runtime: thứ đáng xem nằm ở chỗ fallback

LiteRT.js hỗ trợ ba hướng chạy chính:

Nghe qua thì hấp dẫn, nhưng phần builder cần khoanh đỏ là: LiteRT.js không hỗ trợ partial delegation. Delegation ở đây là việc giao toàn bộ hoặc một phần graph model cho accelerator như GPU hoặc NPU. Với LiteRT.js, nếu model không thể được giao trọn cho backend đã chọn, nó fallback về WebAssembly CPU path.

Dịch sang tiếng người: bạn không thể kỳ vọng “layer nào GPU chạy được thì chạy GPU, layer nào không được thì CPU đỡ”. Nó giống như làm mộng gỗ: khớp thì ăn chắc, lệch một chút là phải bào lại cả mối nối, chứ không phải nhét tạm rồi cầu may.

Vì vậy, khi đọc con số “nhanh hơn” trong release, đừng chỉ hỏi nhanh hơn bao nhiêu. Hãy hỏi:

  1. Model của mình có operator coverage phù hợp không?
  2. Backend mục tiêu là CPU, GPU hay NPU?
  3. Nếu fallback về CPU thì UX còn chấp nhận được không?
  4. Browser/device phổ biến của user có hỗ trợ đường chạy đó không?

Nguồn nói LiteRT.js có thể nhanh hơn đến 3 lần so với một số web runtime khác trên CPU/GPU cho các model computer vision và audio cổ điển; GPU hoặc NPU có thể nhanh hơn 5–60 lần so với CPU trong các tác vụ realtime nặng. Những con số này hữu ích để định hướng, nhưng không thay cho benchmark trên tập thiết bị thật của bạn.

Ai hưởng lợi, ai bị ép đổi cách làm?

Nhóm hưởng lợi đầu tiên là team có bài toán local-first AI: xử lý camera, audio, gesture, segmentation nhẹ, OCR nhỏ, hoặc pre-processing ngay trên máy người dùng. Nếu dữ liệu nhạy cảm, việc không gửi raw input lên server là một lợi thế thực dụng.

Ví dụ cụ thể: một app học phát âm muốn phân tích audio ngắn để đưa feedback tức thì. Nếu gửi từng đoạn âm thanh lên server, bạn phải lo latency, privacy, quota, retry, và cả chuyện user mạng yếu. Nếu một phần nhận diện đặc trưng âm thanh chạy local, server chỉ cần xử lý những bước cần reasoning sâu hơn. UX có thể bớt khựng.

Nhóm bị ép đổi cách nghĩ là team backend quen kiểm soát mọi inference ở server. Khi inference dịch xuống browser, bạn mất một số thứ:

Đổi lại, bạn có thể giảm server cost, giảm round-trip latency, và giữ dữ liệu nhạy cảm ở thiết bị. Đây không phải câu chuyện “client thắng server”. Đây là câu chuyện phân vai lại.

Ba release khác đang chỉ cùng một hướng

LiteRT.js không đứng một mình. Nhìn sang các release gần đây, có một đường chỉ khá rõ: thị trường đang tách AI thành nhiều lớp runtime chuyên dụng hơn.

OpenAI đẩy GPT-Live và GPT-Realtime theo hướng voice realtime. Full-duplex nghĩa là model có thể nghe và nói cùng lúc, gần hơn với hội thoại tự nhiên thay vì chờ hết lượt. Một số bản còn delegate reasoning sâu sang model mạnh hơn phía sau. Tín hiệu ở đây: voice agent không còn chỉ là STT cộng LLM cộng TTS xếp hàng nối đuôi; nó đang thành runtime hội thoại riêng.

Liquid AI với Antidoom lại đánh vào failure mode rất cụ thể của reasoning model: doom loop, tức model lặp một đoạn cho đến khi cạn context window. FTPO, hay Final Token Preference Optimization, tối ưu đúng token khởi đầu vòng lặp thay vì chỉnh toàn bộ hành vi model. Tín hiệu ở đây: thị trường không chỉ đua model lớn hơn, mà bắt đầu trả tiền công cho những miếng đục chạm nhỏ nhưng sửa đúng lỗi đau.

Kyutai với MuScriptor cho thấy một hướng khác: model chuyên biệt, open-weight, nhắm vào transcription nhạc đa nhạc cụ sang MIDI. Không phải chatbot, không phải agent tổng quát, mà là một công cụ có miền hẹp và dữ liệu sâu.

Gom lại, ta thấy một thay đổi vị thế: foundation model vẫn quan trọng, nhưng runtime, failure-mode fix, và domain artifact đang giành thêm quyền quyết định. Builder không còn chỉ hỏi “dùng model nào?”, mà phải hỏi “đặt khả năng này ở lớp nào của sản phẩm?”.

Khung quyết định cho team builder

Nếu đang cân nhắc LiteRT.js hoặc một hướng AI tại chỗ tương tự, mình sẽ không bắt đầu bằng benchmark marketing. Mình sẽ dùng khung bốn câu hỏi này.

1. Tác vụ có cần phản hồi tức thì không?
Nếu user đang vẽ, nói, quay camera, gõ nhịp, hoặc tương tác liên tục, local inference đáng xem. Nếu tác vụ là tổng hợp báo cáo dài, server vẫn hợp lý hơn.

2. Dữ liệu đầu vào có nhạy cảm không?
Camera, giọng nói, tài liệu cá nhân, dữ liệu trẻ em, dữ liệu nội bộ doanh nghiệp — đây là nơi local-first có giá trị. Không gửi dữ liệu đi vẫn là một feature, không chỉ là kiến trúc.

3. Model có đủ nhỏ và ổn định để ship xuống client không?
Browser không phải cụm GPU của bạn. Quantization, tức giảm độ chính xác số để model nhẹ hơn, sẽ thành bước bắt buộc trong nhiều trường hợp. Nhưng quantize xong phải đo lại chất lượng, vì model nhẹ hơn không tự nhiên đồng nghĩa với đủ tốt.

4. Fallback có được thiết kế như đường chính không?
Đừng xem fallback là ngoại lệ hiếm. Với web, fallback là chuyện thường ngày: browser khác nhau, GPU driver khác nhau, policy khác nhau. Nếu CPU path tệ đến mức UX hỏng, bạn chưa có production plan.

Một cách thực dụng: chia inference thành ba lớp.

| Lớp | Nên chạy ở đâu | Ví dụ |
|---|---|---|
| Phản hồi tức thì | Browser/device | audio feature, camera filter, gesture |
| Suy luận vừa phải | Browser hoặc edge | phân loại nhỏ, ranking nhẹ |
| Reasoning sâu | Server/API | lập kế hoạch, gọi tool, tổng hợp nhiều nguồn |

Hình dung thế này: bạn đang làm app kiểm tra chất lượng ảnh giấy tờ. Browser có thể chạy model nhỏ để phát hiện ảnh mờ, lệch, thiếu sáng ngay khi user chụp. Server chỉ nhận ảnh đã đạt ngưỡng để OCR hoặc đối soát sâu hơn. Bạn giảm request rác, user được feedback nhanh, backend đỡ gồng.

Điều nên bỏ qua trong cơn ồn ào

Bỏ qua ý nghĩ rằng LiteRT.js sẽ thay thế toàn bộ TensorFlow.js hoặc mọi cloud inference. Nó không giải quyết hết các bài toán model lớn, tool calling, reasoning nhiều bước, hay workflow cần dữ liệu server-side.

Cũng bỏ qua ảo tưởng “chạy local là miễn phí”. Bạn vẫn trả bằng kích thước bundle, thời gian tải model, battery drain, memory pressure, QA matrix, và công test thiết bị. Chi phí chỉ đổi hình dạng.

Điều đáng giữ là tư duy runtime-first: trước khi chọn model, hãy quyết định năng lực AI nên nằm ở client, server, hay chia đôi. Đây là điểm mình nghĩ nhiều team sẽ thay đổi sau khi đọc release này. Không phải vì LiteRT.js là lựa chọn mặc định, mà vì nó làm browser trở thành một mặt bàn đủ chắc để đặt vài công đoạn inference nghiêm túc lên đó.

Nếu là mình, mình sẽ thử LiteRT.js trước với một tác vụ nhỏ, realtime, có privacy hoặc latency pressure rõ ràng. Đừng bắt nó gánh chatbot tổng quát. Hãy giao cho nó một miếng gỗ vừa tay, đo đường cắt, rồi mới quyết định có đóng cả bộ khung hay không.

AI tại chỗ không làm sản phẩm tự nhiên thông minh hơn; nó chỉ khiến bạn hết cớ đổ mọi độ trễ lên mạng.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo