AI agent đang rời khỏi màn hình trò chuyện để thực hiện công việc nhiều bước: đọc dữ liệu, gọi công cụ, theo dõi trạng thái và đưa ra quyết định trong giới hạn được cấp. Nhưng một câu hỏi khó vẫn còn nguyên: có nhất thiết phải gửi mọi thao tác lên đám mây hay không? Ngày 13/10/2026, Liquid AI công bố LFM2.5-24B-A2B, một mô hình trọng số mở được thiết kế cho agent chạy nhanh và riêng tư trên thiết bị. Đây là một tin đáng chú ý với đội ngũ muốn thử nghiệm AI cục bộ mà không bắt đầu bằng một hệ thống máy chủ quá phức tạp.
Bài viết này tách rõ hai phần. Thứ nhất là những gì Liquid AI xác nhận trong bài công bố chính thức. Thứ hai là phân tích thực tế dành cho lập trình viên và doanh nghiệp: mô hình mới có thể phù hợp ở đâu, cần kiểm thử gì, và vì sao “chạy được trên thiết bị” không đồng nghĩa với việc có thể đưa thẳng vào sản xuất.
LFM2.5-24B-A2B là gì?
Theo bài viết chính thức của Liquid AI, LFM2.5-24B-A2B là mô hình reasoning dạng open-weight với tổng quy mô 24 tỷ tham số nhưng chỉ kích hoạt 2 tỷ tham số trong mỗi bước xử lý. Cách thiết kế này thuộc nhóm mixture-of-experts: toàn bộ mô hình có nhiều năng lực chuyên biệt, còn bộ định tuyến chỉ chọn phần cần thiết cho một đầu vào cụ thể. Con số “2B active parameters” không nên bị hiểu thành mô hình chỉ có 2 tỷ tham số; đó là lượng tham số được dùng tại thời điểm suy luận.
Liquid AI giới thiệu mô hình cho các agent nhanh, riêng tư và chạy trên thiết bị. Trang công bố cũng nêu kết quả so sánh với Qwen3.6-35B-A3B trên LiveClaw. Đây là tuyên bố của nhà phát triển về một bộ đánh giá cụ thể, không phải bằng chứng rằng mô hình sẽ thắng mọi bài toán, mọi phần cứng hay mọi ngôn ngữ. Khi đọc benchmark, đội ngũ kỹ thuật vẫn cần kiểm tra tập dữ liệu, cách chấm điểm, độ dài ngữ cảnh và điều kiện phần cứng.
Điểm đáng quan tâm nằm ở hướng đi chứ không chỉ ở tên mô hình. Một agent chạy cục bộ có thể xử lý dữ liệu nhạy cảm mà không phải gửi nguyên văn lên API bên ngoài. Nó cũng có thể phản hồi khi mạng chập chờn, giảm độ trễ cho một số thao tác và giúp doanh nghiệp kiểm soát chi phí theo kiểu khác. Đổi lại, đội ngũ phải tự lo phần cứng, cập nhật mô hình, quan sát chất lượng và bảo vệ thiết bị.
Điều nguồn chính thức xác nhận
Nguồn được xác minh cho bài viết này là bài “LFM2.5-24B-A2B: Built for Fast On-Device Agents” trên Liquid AI, đăng ngày 13/10/2026. Từ nguồn đó, có thể ghi nhận các điểm sau:
- LFM2.5-24B-A2B là mô hình open-weight theo mô tả của Liquid AI.
- Mô hình có tổng quy mô 24B và 2B tham số được kích hoạt trong mỗi lượt xử lý.
- Định hướng sử dụng là các agent nhanh, riêng tư và chạy trên thiết bị.
- Liquid AI công bố một so sánh với Qwen3.6-35B-A3B trên LiveClaw.
- Bài công bố có ngày xuất bản rõ ràng và là nguồn gốc phù hợp để kiểm tra thông tin kỹ thuật ban đầu.
Những điều trên không đủ để kết luận mô hình phù hợp với mọi laptop, điện thoại hay máy chủ biên. Nguồn cũng không tự động chứng minh rằng mọi agent xây trên mô hình sẽ an toàn, không ảo giác hoặc rẻ hơn API đám mây. Đây là ranh giới cần giữ khi viết về mô hình mới: số liệu và tính năng cần dẫn về nguồn, còn khuyến nghị triển khai phải được trình bày như phân tích và giả thuyết cần kiểm thử.
Vì sao AI agent chạy trên thiết bị đáng chú ý?
Riêng tư hơn, nhưng không phải riêng tư tuyệt đối
Với dữ liệu nội bộ, mô hình cục bộ có thể giảm việc truyền nội dung ra ngoài hệ thống. Một trợ lý đọc nhật ký ứng dụng, tài liệu kỹ thuật hoặc yêu cầu hỗ trợ khách hàng có thể xử lý bản nháp ngay tại máy chủ của doanh nghiệp. Điều này hỗ trợ các nguyên tắc giảm thiểu dữ liệu và phân vùng thông tin. Tuy vậy, dữ liệu vẫn có thể bị lộ qua log, bộ nhớ đệm, công cụ mà agent gọi hoặc người dùng tải kết quả ra ngoài. “Local” là một lớp kiểm soát, không phải giấy miễn trừ cho mọi rủi ro.
Độ trễ và khả năng hoạt động khi mất mạng
Agent phải thường xuyên gọi mô hình trong một chuỗi hành động. Nếu mỗi lượt đều đi qua mạng, độ trễ tích lũy có thể làm trải nghiệm chậm và khó dự đoán. Mô hình chạy trên thiết bị cho phép đội ngũ thiết kế các bước phản hồi nhanh, đặc biệt với phân loại, trích xuất, tóm tắt ngắn hoặc quyết định có phạm vi hẹp. Nhưng tốc độ thực tế phụ thuộc vào CPU, GPU, bộ nhớ, định dạng trọng số, độ dài prompt và số lượt gọi. Không nên lấy tốc độ trong một ví dụ mẫu để hứa hẹn cho sản phẩm.
Chi phí chuyển từ phí API sang chi phí vận hành
Chạy local không có nghĩa là miễn phí. Doanh nghiệp phải tính chi phí thiết bị, điện năng, khấu hao, cập nhật, giám sát và nhân sự. Nếu lượng truy cập thấp, API đám mây có thể vẫn kinh tế hơn. Nếu dữ liệu nhạy cảm hoặc lưu lượng ổn định, một mô hình cục bộ có thể tạo ra lợi ích lớn hơn. Cách đúng là so sánh tổng chi phí sở hữu theo một tác vụ cụ thể, thay vì so giá mỗi token với giá phần cứng một cách tách rời.
Thiết kế Website chuẩn SEO & tối ưu doanh số
Ftechx thiết kế trọn gói từ giao diện, hosting đến hệ thống thanh toán tự động.
Cách đánh giá LFM2.5-24B-A2B trước khi dùng
Đừng bắt đầu bằng việc giao cho agent quyền đọc toàn bộ ổ đĩa. Hãy bắt đầu bằng một bài toán hẹp, có dữ liệu kiểm thử và tiêu chí thất bại rõ ràng. Một quy trình thực tế có thể gồm các bước sau:
- Chọn một workflow nhỏ: ví dụ phân loại ticket, tóm tắt nhật ký hoặc tạo bản nháp truy vấn. Workflow nên có đầu vào và đầu ra đo được.
- Tạo bộ kiểm thử đại diện: bao gồm dữ liệu bình thường, câu hỏi mơ hồ, dữ liệu thiếu, ngôn ngữ tiếng Việt và các trường hợp có thông tin nhạy cảm.
- Đo cả chất lượng lẫn hệ thống: ghi nhận độ chính xác, tỷ lệ từ chối đúng, thời gian phản hồi, bộ nhớ sử dụng và mức tiêu thụ điện nếu có thể.
- Giới hạn công cụ: chỉ cho agent gọi API giả lập hoặc thư mục thử nghiệm. Mỗi công cụ phải có schema, xác thực tham số và nhật ký.
- So sánh với phương án khác: chạy cùng bộ kiểm thử trên mô hình API hiện tại hoặc mô hình cục bộ đang dùng. Kết quả phải được lưu để tránh đánh giá theo cảm giác.
- Kiểm thử khi nâng phiên bản: model mới có thể thay đổi cách dùng công cụ hoặc giọng điệu. Mọi bản cập nhật cần chạy lại bộ hồi quy.
Bộ chỉ số tối thiểu
| Nhóm | Câu hỏi cần trả lời |
|---|---|
| Chất lượng | Agent có trả lời đúng, đủ và biết nói “không biết” không? |
| Độ trễ | Thời gian đến token đầu tiên và thời gian hoàn tất có đáp ứng workflow không? |
| Tài nguyên | Thiết bị cần bao nhiêu bộ nhớ và còn đủ tài nguyên cho ứng dụng chính không? |
| An toàn | Agent có bị prompt injection, rò rỉ dữ liệu hoặc gọi công cụ ngoài ý muốn không? |
| Vận hành | Đội ngũ có phát hiện lỗi, rollback và cập nhật mô hình được không? |
Thiết kế agent an toàn khi chạy local
Quyền truy cập là phần quan trọng hơn bản thân mô hình. Một mô hình nhỏ chạy trên máy chủ nội bộ vẫn có thể gây hậu quả lớn nếu được cấp quyền xóa dữ liệu, gửi email hoặc chạy lệnh tùy ý. Hãy coi mô hình là thành phần có thể mắc lỗi, không phải một nhân viên đáng tin cậy.
- Cấp quyền tối thiểu theo từng workflow, không dùng tài khoản quản trị chung.
- Đặt allowlist cho công cụ và tham số; từ chối lệnh ngoài schema.
- Tách môi trường thử nghiệm khỏi dữ liệu sản xuất.
- Yêu cầu phê duyệt người dùng trước hành động không thể hoàn tác.
- Ẩn hoặc băm dữ liệu nhạy cảm trong log; đặt thời hạn lưu log.
- Có nút dừng, giới hạn số lượt gọi và ngân sách tài nguyên cho mỗi phiên.
- Kiểm tra prompt injection trong tài liệu, email và trang web mà agent đọc.
Với tác vụ có rủi ro cao, mô hình chỉ nên tạo đề xuất. Một dịch vụ xác thực độc lập mới là nơi quyết định hành động có được phép hay không. Đây là nguyên tắc defense in depth: nếu mô hình hiểu sai, lớp chính sách vẫn có cơ hội ngăn lỗi.
Những giới hạn cần lưu ý
Thứ nhất, open-weight không đồng nghĩa với dễ vận hành. Đội ngũ cần hiểu giấy phép, định dạng, công cụ suy luận và yêu cầu phần cứng trước khi tích hợp. Thứ hai, benchmark của nhà phát triển có thể không đại diện cho tiếng Việt, dữ liệu nội bộ hoặc tác vụ nhiều công cụ của doanh nghiệp. Thứ ba, mô hình chạy nhanh nhưng trả lời sai vẫn là một hệ thống chậm theo nghĩa kinh doanh vì con người phải sửa lại.
Thứ tư, bảo mật thiết bị trở nên quan trọng hơn. Nếu máy chạy model bị chiếm quyền, kẻ tấn công có thể đọc prompt, lấy dữ liệu trong bộ nhớ hoặc lợi dụng công cụ mà agent được phép gọi. Cần cập nhật hệ điều hành, giới hạn tài khoản dịch vụ, mã hóa ổ đĩa và theo dõi hành vi bất thường. Cuối cùng, hãy chuẩn bị phương án quay về mô hình hoặc workflow cũ khi chất lượng giảm.
Checklist triển khai thử trong 14 ngày
- Ngày 1–2: chốt workflow, dữ liệu mẫu và tiêu chí đạt.
- Ngày 3–4: dựng môi trường cô lập, cài model và đo tài nguyên.
- Ngày 5–7: chạy bộ kiểm thử, so sánh với phương án hiện tại.
- Ngày 8–9: thử prompt injection, dữ liệu lỗi và hành động ngoài quyền.
- Ngày 10–11: thêm logging, cảnh báo, phê duyệt và rollback.
- Ngày 12–13: cho một nhóm nhỏ dùng thử với dữ liệu đã kiểm soát.
- Ngày 14: quyết định tiếp tục, điều chỉnh phạm vi hoặc dừng thử nghiệm dựa trên số liệu.
Kết luận
LFM2.5-24B-A2B cho thấy hướng phát triển đáng theo dõi của AI agent: mô hình open-weight, suy luận hiệu quả hơn và ưu tiên chạy trên thiết bị. Nguồn Liquid AI đã xác nhận định hướng, quy mô 24B với 2B tham số kích hoạt và so sánh trên LiveClaw. Phần còn lại là câu hỏi triển khai của từng đội ngũ: chất lượng trên dữ liệu thật, tài nguyên phần cứng, chi phí vận hành và cơ chế kiểm soát quyền.
AI agent chạy trên thiết bị có thể tạo lợi thế về riêng tư và độ trễ, nhưng chỉ khi được đặt trong một hệ thống có giới hạn rõ ràng. Nếu bạn đang xây workflow AI cục bộ, hãy bắt đầu nhỏ, đo bằng bộ kiểm thử của chính mình và không trao quyền rộng hơn mức cần thiết. FTECHX sẽ tiếp tục cập nhật các mô hình, công cụ và cách triển khai thực tế để bạn biến công nghệ mới thành kết quả an toàn, đo được.
Nguồn xác minh: Liquid AI, “LFM2.5-24B-A2B: Built for Fast On-Device Agents”, đăng ngày 13/10/2026: liquid.ai/blog/lfm2-5-24b-a2b .
