LFM2.5-24B-A2B có phù hợp cho agent n8n chạy dữ liệu nội bộ?
Liquid AI giới thiệu mô hình reasoning 24B tham số, chỉ kích hoạt 2B tham số mỗi token, hướng tới agent chạy cục bộ, gọi công cụ và xử lý nhiều bước. Dưới đây là cách đánh giá nó cho workflow n8n và dữ liệu nội bộ.
Một ticket hỗ trợ vừa vào: khách báo giao dịch bị treo. Nhân viên cần dò CRM, đối chiếu lịch sử trao đổi, tra quy trình nội bộ rồi soạn email phản hồi. Nếu toàn bộ dữ liệu phải gửi lên API bên ngoài, chính sách bảo mật có thể trở thành trở ngại ngay từ bước đầu.
LFM2.5-24B-A2B của Liquid AI nhắm tới bài toán agent chạy trên phần cứng do bạn kiểm soát: mô hình có thể suy luận trước khi trả lời, gọi công cụ và xử lý tác vụ nhiều bước. Với người xây workflow n8n, câu hỏi thực tế là: nó có thể đóng vai lớp AI nội bộ giữa trigger và CRM, email hoặc bảng tính hay không?
LFM2.5-24B-A2B là gì?
Liquid AI mô tả LFM2.5-24B-A2B là mô hình reasoning có 24 tỷ tham số tổng, nhưng chỉ có 2 tỷ tham số hoạt động cho mỗi token được tạo ra.
Mô hình giữ kiến trúc MoE của bản tiền nhiệm: 40 lớp, 64 expert trong mỗi khối MoE và cơ chế chọn top-4. Theo công bố, việc chỉ kích hoạt một phần tham số ở mỗi token giúp giảm lượng tính toán khi sinh câu trả lời.
Đây là điểm đáng chú ý với agent. Một tác vụ thường không dừng ở một lần trả lời: agent có thể phải đọc yêu cầu, chọn công cụ, nhận kết quả, rồi quyết định bước tiếp theo. Mô hình cũng có cửa sổ ngữ cảnh 131K token, tăng từ 32K token ở bản trước.
Kết quả benchmark: mạnh về tool use, không phải mọi bài toán
Theo bảng đánh giá do Liquid AI công bố, LFM2.5-24B-A2B đạt 48,09 điểm trên LiveClaw, so với 38,19 của Qwen3.6-35B-A3B.
Liquid AI cho biết model dẫn đầu hoặc tương đương nhóm so sánh ở 5 trong 8 benchmark về tool use và agentic workflow, gồm AutomationBench, BFCLv4, ToolSandbox, LiveClaw và τ³-Bench Banking. Trên AutomationBench, điểm số được công bố là 27,69, cao hơn mức 8,72 của Qwen3.6-35B-A3B.
Tuy vậy, chính Liquid AI cũng ghi nhận các model lớn hơn đạt kết quả tốt hơn ở một số bài kiểm tra nặng kiến thức và lập trình, như GPQA Diamond, HLE, AA-Omniscience, SWE-Bench Verified và SciCode.
Điều này gợi ý một cách dùng hợp lý cho workflow doanh nghiệp: dùng model để phân loại, chọn bước xử lý, gọi công cụ và tạo đầu ra có cấu trúc; còn câu hỏi phụ thuộc nhiều vào tri thức nội bộ nên đi kèm lớp truy xuất tài liệu hoặc tìm kiếm nội bộ.
Một kiến trúc n8n có thể áp dụng
Liquid AI cho biết model có hỗ trợ từ ngày phát hành trên llama.cpp, MLX, vLLM, SGLang và ONNX. Hướng triển khai được nêu là chạy model cục bộ phía sau backend tương thích OpenAI, sau đó kết nối agent harness tới backend đó.
Từ đó, một workflow n8n nội bộ có thể được thiết kế như sau:
Trigger: Webhook nhận ticket, Gmail nhận email hoặc Cron quét việc cần xử lý.
Lấy dữ liệu: n8n truy vấn CRM, cơ sở dữ liệu hoặc kho tài liệu nội bộ bằng credential do n8n quản lý.
Bước AI: node HTTP Request hoặc node AI gọi endpoint tương thích OpenAI của model trong mạng nội bộ.
Kiểm tra đầu ra: parse JSON, kiểm tra trường bắt buộc và chỉ chấp nhận các hành động trong danh sách cho phép.
Phê duyệt: đưa các tác vụ nhạy cảm, như sửa CRM hoặc gửi nội dung ra ngoài, cho người phụ trách duyệt.
Thực thi: chỉ sau bước kiểm tra hoặc phê duyệt, n8n mới gửi email, tạo task hoặc cập nhật hệ thống.
Theo dõi: ghi nhận ID workflow, kết quả AI, người phê duyệt và hành động cuối cùng.
Nguyên tắc hữu ích là: n8n kiểm soát luồng và quyền thực thi; model đưa ra phân tích hoặc đề xuất có cấu trúc. Không nên biến model thành một tác nhân có quyền gọi mọi API nội bộ mà không có giới hạn.
Nguồn không công bố sẵn template n8n hoặc lệnh chạy backend cụ thể. Cổng mặc định được nêu trong hướng dẫn là 8080 cho llama.cpp và MLX, 8000 cho vLLM, 30000 cho SGLang và 1234 cho LM Studio. Khi triển khai thực tế, hãy xác nhận lại cấu hình của backend bạn chọn.
Chạy thử model bằng Python
Liquid AI cung cấp ví dụ dùng transformers phiên bản 5.0.0 trở lên:
bash
pip install -U transformers
python
from transformers import AutoModelForCausalLM, AutoTokenizer, TextStreamer
modelid = "LiquidAI/LFM2.5-24B-A2B"
model = AutoModelForCausalLM.frompretrained(
modelid,
devicemap="auto",
dtype="bfloat16",
# attnimplementation="flashattention2" # GPU tương thích
)
tokenizer = AutoTokenizer.frompretrained(modelid)
streamer = TextStreamer(
tokenizer,
skipprompt=True,
skipspecialtokens=True,
)
prompt = "What is C. elegans?"
inputids = tokenizer.applychattemplate(
[{"role": "user", "content": prompt}],
addgenerationprompt=True,
returntensors="pt",
tokenize=True,
)["inputids"].to(model.device)
model.generate(
inputids,
dosample=True,
temperature=0.1,
topk=50,
repetitionpenalty=1.05,
maxnewtokens=512,
streamer=streamer,
)
Nếu dùng Hermes Agent làm agent harness, Liquid AI đưa ra cấu hình mẫu sau:
bash
hermes config set model.provider custom
hermes config set model.baseurl http://localhost:8080/v1
hermes config set model.default LFM2.5-24B-A2B
hermes config set model.contextlength 131072
hermes config set model.apimode chatcompletions
hermes config set agent.tooluseenforcement true
Đây là ví dụ cho Hermes Agent, không phải cấu hình n8n. Với n8n, ý tưởng tương tự là chỉ cho workflow đi qua những action node và API đã được xác định trước.
Buộc đầu ra JSON để workflow dễ kiểm soát
Đừng đưa yêu cầu kiểu “xử lý ticket này” rồi gửi nguyên văn câu trả lời của model cho khách. Một đầu ra có cấu trúc giúp node phía sau kiểm tra và rẽ nhánh rõ ràng hơn.
text
Bạn là trợ lý vận hành nội bộ.
Yêu cầu khách hàng:
<customerrequest>
Dữ liệu CRM đã truy xuất:
<crmrecords>
Quy định nội bộ liên quan:
<policycontext>
Hãy phân loại yêu cầu và đề xuất bước tiếp theo.
Chỉ trả về JSON hợp lệ, không có Markdown:
{
"category": "<support|billing|sales|other>",
"summary": "<tóm tắt ngắn>",
"recommendedaction": "<createtask|draftreply|needshumanreview>",
"risklevel": "<low|medium|high>",
"draftreply": "<bản nháp, để trống nếu không phù hợp>",
"reason": "<lý do ngắn dựa trên dữ liệu được cung cấp>"
}
Với một yêu cầu liên quan đến hoàn tiền hoặc giao dịch, workflow nên hướng model tới việc gắn cờ để người có thẩm quyền xử lý, thay vì tự thực hiện thao tác.
json
{
"category": "billing",
"summary": "Khách yêu cầu kiểm tra giao dịch chưa hoàn tất.",
"recommendedaction": "needshumanreview",
"risklevel": "high",
"draftreply": "",
"reason": "Yêu cầu liên quan đến giao dịch và cần người có thẩm quyền xác minh."
}
Trong n8n, node IF có thể dựa vào risklevel hoặc recommendedaction để chuyển tác vụ sang bước duyệt. Các danh sách giá trị hợp lệ nên được kiểm tra trước khi workflow thực thi bất kỳ hành động nào.
Hiệu năng và các hàng rào cần có
Liquid AI báo cáo tốc độ 184 token/giây trên Apple M5 Max, 114 token/giây trên Ryzen AI Max+ 395, và hơn 21K output token/giây ở độ đồng thời cao trên một NVIDIA B300.
Đây là số liệu do hãng công bố. Tốc độ thực tế sẽ phụ thuộc vào backend, định dạng model, bộ nhớ, độ dài context, cấu hình phần cứng và lượng yêu cầu chạy đồng thời.
Chạy local cũng không tự động đồng nghĩa với an toàn. Khi đưa model vào workflow nội bộ, nên có các hàng rào cơ bản:
Không đưa API key vào prompt, bảng tính hoặc log; dùng credential manager và biến môi trường.
Chỉ gửi vào model những trường dữ liệu cần thiết cho tác vụ.
Kiểm tra JSON đầu ra; dừng luồng nếu thiếu trường hoặc có hành động ngoài danh sách cho phép.
Không retry mù quáng các bước có tác động bên ngoài như gửi email hoặc cập nhật dữ liệu.
Ghi nhận quyết định AI, người phê duyệt và hành động đã chạy để dễ kiểm tra.
Có đường lui: nếu model cục bộ không phản hồi, chuyển tác vụ sang hàng chờ hoặc xử lý thủ công.
Kết luận
LFM2.5-24B-A2B là lựa chọn đáng xem xét cho agent cục bộ cần suy luận, gọi công cụ và làm việc theo nhiều bước. Theo số liệu Liquid AI công bố, thế mạnh của model nằm ở tool use và instruction following — các năng lực phù hợp với workflow có nhánh xử lý rõ ràng.
Cách bắt đầu an toàn là một luồng hẹp: phân loại ticket, trích xuất trường dữ liệu, tạo bản nháp và chuyển người duyệt. Khi đầu ra JSON ổn định, log đầy đủ và quyền hành động được giới hạn, bạn mới nên mở rộng sang CRM, email hoặc các hệ thống nhạy cảm hơn.