- Đây là API gốc của trình duyệt dùng để gửi yêu cầu ngôn ngữ tự nhiên tới mô hình Gemini Nano được tích hợp trong Chrome, cho phép suy luận AI ngay trên thiết bị mà không cần trao đổi qua lại với máy chủ
- Có thể ứng dụng vào nhiều trường hợp như tìm kiếm dựa trên AI, nguồn cấp dữ liệu cá nhân hóa thông qua phân loại tin tức, lọc nội dung, tạo lịch trên calendar, trích xuất liên hệ, v.v.
- Có thể chọn phản hồi một lần bằng
prompt() hoặc phản hồi dạng streaming dựa trên ReadableStream bằng promptStreaming()
- Cung cấp các tính năng điều khiển phiên chi tiết như quản lý ngữ cảnh theo phiên, phản hồi streaming, sao chép phiên
- Vì suy luận AI diễn ra ngay trong trình duyệt mà không cần trao đổi với máy chủ, nên có lợi thế về bảo vệ quyền riêng tư và giảm thiểu độ trễ phản hồi
- Tích hợp sẵn khả năng đa phương thức hỗ trợ đầu vào hình ảnh và âm thanh ngoài văn bản
- Âm thanh:
AudioBuffer, ArrayBuffer, Blob v.v.
- Hình ảnh:
HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob v.v.
- Có thể truyền JSON schema vào trường
responseConstraint để giới hạn định dạng đầu ra của mô hình thành boolean, hoặc một cấu trúc JSON cụ thể, v.v.
- Với
initialPrompts, có thể chèn system prompt và ngữ cảnh hội thoại trước đó; với append(), vẫn có thể gửi trước ngữ cảnh bổ sung ngay cả sau khi tạo phiên
- Nếu thêm
prefix: true vào thông điệp assistant đi sau, có thể định hướng để mô hình bắt đầu phản hồi theo một định dạng cụ thể
- Hỗ trợ quản lý cửa sổ ngữ cảnh theo từng phiên: có thể kiểm tra mức sử dụng token bằng
contextUsage/contextWindow, và khi tràn sẽ tự động xóa các hội thoại ban đầu (system prompt vẫn được giữ nguyên)
- Có thể fork phiên bằng
clone(), giải phóng tài nguyên bằng destroy(), và hủy giữa chừng phiên cũng như prompt bằng AbortSignal
- Có thể thiết lập định dạng và ngôn ngữ đầu vào/đầu ra bằng
expectedInputs/expectedOutputs (hiện hỗ trợ en, ja, es)
- Yêu cầu phần cứng: Windows 10+/macOS 13+/Linux/ChromeOS, ít nhất 22GB dung lượng lưu trữ, GPU VRAM trên 4GB hoặc CPU RAM từ 16GB trở lên + ít nhất 4 lõi
- Với iframe khác Origin, có thể ủy quyền truy cập bằng thuộc tính
allow="language-model"; hiện chưa hỗ trợ trong web worker
- Được cung cấp dưới dạng origin trial từ Chrome 138
1 bình luận
Ý kiến trên Hacker News
API này có vẻ cực kỳ hợp với ý tưởng de-snarkifier mà tôi đã nghĩ đến từ lâu
Mạng xã hội có thể kích thích trí tuệ và cũng có thứ để học, nhưng rất dễ bị cuốn vào cãi vã ý thức hệ và flame war dù mình không muốn. Việc hao tổn cảm xúc để cãi nhau với người lạ trên internet gần như là một sự lãng phí vốn con người
Nếu có API như thế này, có lẽ có thể làm một tiện ích mở rộng trình duyệt để trước khi hiển thị bài viết, nó chỉ làm dịu những cách diễn đạt công kích hoặc mỉa mai, còn thông tin thực tế thì vẫn giữ nguyên. Thậm chí còn có thể đi xa hơn, biến giọng điệu càng hung hăng thì lại càng nghe lố bịch hoặc kém năng lực
Như vậy người đọc sẽ được bảo vệ khỏi những lời công kích cá nhân từ người lạ, còn người viết cũng không còn động lực cư xử thô lỗ. Nếu ai cũng dùng bộ lọc như vậy thì cũng chẳng còn lý do để ganh đua xem ai cay độc hơn
Vẫn đủ dinh dưỡng, nhưng cảm giác là chẳng có gì đặc biệt ngon miệng
Điều tôi muốn là loại sạch tiêu đề câu click và quảng cáo, chỉ hiện các tiêu đề khô khan mang tính sự thật
Với bất kỳ chủ đề nào, chỉ cần một bài cốt lõi và vài bình luận thực sự có giá trị là đủ, còn lại phần lớn chỉ là nhiễu mà tôi không muốn xem
Tình trạng mạng xã hội bây giờ tệ đến mức tôi gần như không dùng nữa, và HN từng là ngoại lệ duy nhất, nhưng giờ ở đây cũng có vẻ đang đi theo hướng tương tự vì AI bão hòa. Dù vậy, cứ cách vài tuần tôi vẫn lãng phí vài tiếng ở đây, và tôi muốn cắt hẳn cả điều đó
Lý tưởng nhất là lọc hoặc tóm tắt để loại bỏ 98% nội dung, và theo thời gian internet chỉ còn là thứ tôi dùng khi chủ động đi tìm kiếm. Về cơ bản tôi muốn loại bỏ phần lớn tính giải trí của internet để dồn thời gian và năng lượng về cho đời thực và các nguồn chất lượng cao như sách
Tiện ích này là một công cụ crowdsourcing nhằm giảm bớt tính giật gân, nhưng tôi có cảm giác một số người đóng góp hàng đầu có thể là bot LLM
Tuy vậy, những thứ như thế này khi va vào thực tế thì rất khó lường, và kể cả có thành công thì cũng có khả năng vận hành khá khác với cách người ta tưởng tượng ban đầu
Tôi không nhịn được nên đã vội làm một nguyên mẫu Snarknada, đồng thời xem xét cả mô hình độ trễ thấp lẫn khả năng về độ chính xác
Đây chính xác là lý do tôi cho rằng on-device là phù hợp cho kiểu use case này. Nếu làm dịu cả một feed cuộn vô tận bằng API đám mây thì chi phí token sẽ lớn đến mức nhà phát triển khó mà gánh nổi. Chưa kể việc người dùng không muốn gửi feed cá nhân hay DM của họ lên máy chủ bên thứ ba chỉ để chỉnh lại tông giọng cũng là điều hoàn toàn dễ hiểu
Nếu đưa việc này vào trong thiết bị, Semantic Mutation tần suất cao có thể lần đầu trở nên khả thi cả về chi phí lẫn kỹ thuật. Nếu ai đó làm thứ này nghiêm túc hơn cái nguyên mẫu PM mang tính đồ chơi của tôi và gặp phải những điểm ma sát cụ thể, tôi rất muốn được nghe. Điều đó sẽ giúp ích cho việc ưu tiên roadmap
[1]: Nếu bạn dùng coding agent (Cursor, Claude Code, v.v.) thì tôi khuyên nên trỏ đến https://www.npmjs.com/package/built-in-ai-skills-md-agent-md. Nhiều model hiện vẫn được huấn luyện trên namespace window.ai đã lỗi thời, nên file skill này giúp chúng dùng đúng API hiện tại
Tôi là người dẫn dắt công việc thiết kế API này, và trước khi nghỉ hưu tôi cũng đã viết một bài tổng hợp các cân nhắc thiết kế liên quan
https://domenic.me/builtin-ai-api-design/
Ngoài ra tôi cũng muốn biết liệu khi làm những thứ như thế này, các trình duyệt có đang phối hợp với nhau theo kiểu thực tế công việc, chứ không chỉ ở cấp độ W3C, để căn chỉnh những điểm chung hay không. Suy cho cùng thì ngành này cũng khá nhỏ
Cái này thực sự chạy được, và tôi đã phát hành nó để dùng cho local inference rồi
Với các tác vụ LLM nhẹ như tìm kiếm, nó dùng được như một kiểu ollama nhà nghèo. Ưu điểm lớn nhất là miễn phí, giữ được quyền riêng tư, và gần như không đòi hỏi người dùng làm gì cả, nên rất phù hợp để mang suy luận cục bộ đến cho người dùng không chuyên kỹ thuật
Tuy nhiên trải nghiệm người dùng thực tế lại không tốt. Kích thước tải model lớn hơn bản thân trình duyệt vài bậc độ lớn, và phải hoàn tất quá trình đó trước khi nhận được token đầu tiên
Việc này có vẻ khó được giải quyết cho đến khi hệ điều hành có thể cung cấp ổn định các model được nhúng sẵn từ trước, và các API kiểu này có thể gắn vào đó
Vấn đề lớn hơn là trên phần lớn PC phổ thông, model vừa quá nhỏ vừa quá chậm. Tôi đã thử thay đổi câu chữ của một game phiêu lưu văn bản infocom theo thời gian thực, nhưng hiện tại trên nhiều PC nó chậm đến mức không thực tế
Nó hơi giống cách bittorrent nhận các mảnh tệp từ nhiều host khác nhau. Các layer dùng chung vẫn phải tải, nhưng thời gian đến token đầu tiên có thể tỷ lệ theo kích thước đang hoạt động chứ không phải toàn bộ kích thước
Dĩ nhiên như vậy sẽ không còn là suy luận offline hoàn toàn nữa, nhưng với một tính năng web trong trình duyệt thì có lẽ đó không phải yếu tố cốt lõi
Tuy nhiên, nếu model lớn hơn trình duyệt rất nhiều và phải tải xuống trước token đầu tiên, tôi muốn hỏi liệu điều đó có nghĩa là lazy download hay không. Nếu người dùng ở lần gọi đầu tiên phải chờ đến khi tải xong thì trải nghiệm có vẻ khá kinh khủng
Tôi cũng tò mò liệu Chrome có hiện kiểu hộp thoại trạng thái tải xuống để bớt gây rối hay không, và dung lượng đĩa thực tế là bao nhiêu
Nhìn bề ngoài thì có vẻ thứ này dùng Gemini Nano, nhưng Gemma 4 E2B/E4B mới nhất trông tốt hơn nhiều, nên trước mắt có thể phát hành bản lượng tử hóa qua tiện ích mở rộng sẽ hợp lý hơn
Nguồn:
Nếu Gemma 4 hoặc Gemini Nano tương ứng vẫn chưa có trong Chrome thì tôi đoán là sắp có rồi
Và bài này được cập nhật lần cuối vào 2025-09-21, khi đó đã là Gemini Nano 3 rồi
Có ghi rằng Prompt API hoạt động bằng cách gửi yêu cầu ngôn ngữ tự nhiên đến Gemini Nano trong trình duyệt
Trên Edge thì có lẽ sẽ là Phi4
Nhìn theo một khía cạnh khác thì đây có vẻ là cách hay để các script JS độc hại đẩy việc sinh token sang cho những khách truy cập không hề hay biết
Cũng sẽ thú vị nếu xem liệu có thể phân tán xử lý bằng mô hình subagent hay cấu trúc kiểu RLM hay không: chia nhỏ prompt lớn thành nhiều phần, gửi tới nhiều trình duyệt, mỗi bên xử lý một mảnh nhỏ rồi ghép thành kết quả hữu ích
Hạ tầng kỹ thuật lẫn kinh doanh cũng sẽ trở nên cực kỳ phức tạp, nên nếu đã muốn đẩy prompt sang trình duyệt người dùng thì có lẽ cứ dùng Chrome API cho đúng cách còn hơn. Tôi cũng nghi ngờ việc offload prompt phía máy chủ sang các model yếu như vậy thực sự sẽ có ý nghĩa trong bao nhiêu trường hợp
Mà nếu thực sự muốn làm thế thì WebGPU cũng đã có từ rất lâu rồi
Đây có vẻ là một bước tiến tới Model API đúng nghĩa, nhưng hiện tại vẫn chỉ là một bước nhỏ
Nó cũng làm tôi nghĩ đến Foundation Models của Apple
Nhiều tích hợp AI tập trung vào giao tiếp văn bản hoặc kiểu chat, nhưng thực tế có không ít phần mềm hưởng lợi ở giao diện phi văn bản
Cuối cùng thì tôi nghĩ OS và trình duyệt nên cung cấp API quản lý model, để ứng dụng có thể truy cập cả model on-device lẫn model từ xa qua một giao diện đơn giản
Nếu điều này được chuẩn hóa đa nền tảng thì sẽ rất tuyệt, và vì còn phải bao gồm cả di động nên về thực tế, phía có thể đẩy mạnh chuyện này nhiều nhất có lẽ vẫn là Apple và Google. Meta có thể đi theo sau, hoặc ngược lại là đi trước cũng không chừng
Điểm cốt lõi là nó không được là thứ chỉ dành cho một model đang được quảng bá cụ thể
Ứng dụng phải có thể truy vấn rồi chọn model phù hợp để dùng
(1) https://developer.apple.com/documentation/foundationmodels
Dĩ nhiên đây vẫn còn là giai đoạn đầu
https://github.com/mozilla/standards-positions/issues/1067
Chúng tôi đang dùng nó để tóm tắt hồi tưởng hackday
https://remotehack.space/previous-hacks/
Chỉ là một script nhỏ đọc RSS feed rồi tạo tóm tắt thành bài viết, nhưng nó khá hợp với website tĩnh. Sau này tôi muốn mở rộng để đặt thêm nhiều câu hỏi khác nhau cho cùng một nội dung
LLM cục bộ mà trình duyệt truy cập được thì tốt cho quyền riêng tư, nhưng nếu mỗi trình duyệt lại gắn API này với một model khác nhau thì cơn ác mộng kiểm thử có lẽ còn tệ hơn bây giờ
Cuối cùng rất có thể phần lớn implementation sẽ căn theo Gemini Nano, nên tôi cũng tự hỏi liệu chuyện này có càng kéo người dùng về phía Chrome hay không
Trên thực tế prompt không hề bất khả tri với model, nên một prompt được tinh chỉnh kỹ cho Gemini Nano 3 v2025 có thể âm thầm giảm hiệu năng trên model phía Gecko. Nhưng API lại thậm chí không cung cấp khả năng dò tìm năng lực để phân nhánh xử lý
Như vậy còn tệ hơn cả WebGL, vốn ít nhất còn cho phép truy vấn hỗ trợ extension. Phát hành tính năng phụ thuộc vào chất lượng prompt của một model bị giấu tên và phiên bản sau trình duyệt cũng giống như phát hành phần mềm mà tính năng bị quyết định bởi cuốn từ điển người dùng đã cài
Tôi nghĩ Gemini Nano không phải open weights như Gemma thì phải
Không biết đã có ai làm chưa, nhưng tôi muốn thử dump trọng số model