LFM2.5-24B-A2B: kiểm tra hạ tầng on-prem trước khi chạy agent
LFM2.5-24B-A2B là MoE 24B, chỉ kích hoạt 2B tham số mỗi token và hướng tới agent cục bộ. Trước khi triển khai, đội hạ tầng cần kiểm chứng VRAM, context, concurrency, quyền tool và chất lượng trên workload nội bộ.
Một yêu cầu quen thuộc có thể sớm đến bàn đội hạ tầng: “Cần một agent đọc tài liệu nội bộ, gọi công cụ và không gửi dữ liệu sang API cloud.”
Chọn model chỉ là bước đầu. Câu hỏi vận hành thực tế là: GPU nào chứa nổi model, bao nhiêu phiên đồng thời chịu được, context dài sẽ ngốn bộ nhớ đến đâu, và agent được phép làm gì trong mạng công ty?
LFM2.5-24B-A2B của Liquid AI đáng chú ý vì được định vị cho agent chạy tại chỗ. Đây là model reasoning có tổng 24B tham số nhưng chỉ kích hoạt 2B tham số cho mỗi token. Liquid AI cũng công bố tốc độ decode cao trên Apple Silicon và GPU NVIDIA.
Tuy nhiên, 2B tham số active không có nghĩa máy chủ chỉ cần bộ nhớ của một model 2B. Với sysadmin, đó là điểm cần xác minh đầu tiên trước khi cấp GPU, mở endpoint hoặc nhận dữ liệu nội bộ.
LFM2.5-24B-A2B có gì đáng chú ý?
Theo Liquid AI, LFM2.5-24B-A2B là model “reasoning-only”: model tạo chuỗi suy luận tường minh trước khi đưa ra câu trả lời cuối. Nó hướng đến tác vụ agent cần lập kế hoạch, gọi tool và xử lý nhiều lượt tương tác.
Về kiến trúc, đây là MoE (Mixture of Experts). Model có 40 layer, 64 expert trong mỗi MoE block và cơ chế định tuyến top-4. Tổng số tham số là 24B, trong khi số tham số active cho mỗi token là 2B.
Với hạ tầng, các điểm đáng lưu ý gồm:
Ít tham số active hơn có thể hỗ trợ tốc độ suy luận, nhất là khi sinh token.
Serving engine vẫn phải nạp trọng số model; không nên sizing VRAM chỉ dựa vào con số 2B active.
Context window tăng từ 32.768 lên 131.072 token. Context dài hữu ích với log, tài liệu hay lịch sử phiên lớn, nhưng KV cache sẽ tăng theo context và số request đồng thời.
Tokenizer tăng từ 65K lên 128K token, nhằm cải thiện tokenization cho các ngôn ngữ không dùng chữ Latin. Material không cung cấp benchmark tiếng Việt riêng.
Liquid AI công bố hỗ trợ ngay từ đầu cho llama.cpp với checkpoint GGUF, MLX trên Apple Silicon, vLLM và SGLang cho GPU serving, cùng ONNX cho nhiều loại accelerator. Đây là lựa chọn đáng cân nhắc nếu doanh nghiệp có sẵn phần cứng Apple, AMD hoặc NVIDIA.
Đừng dùng benchmark làm bảng sizing VRAM
Các số liệu dễ gây chú ý là:
184 token/giây trên Apple M5 Max;
114 token/giây trên AMD Ryzen AI Max+ 395;
hơn 21K output token/giây trên một NVIDIA B300 ở tải cao;
nhanh hơn tới 1,7 lần so với các MoE tương đương trong bài đo on-device của Liquid AI.
Nhưng đây không phải là các số có thể đưa thẳng vào capacity plan.
Bài đo GPU được Liquid AI mô tả chạy với SGLang 0.5.22, BF16, đầu vào 1.024 token, tối đa 256 token đầu ra và tải duy trì ở từng mức concurrency. Chỉ số throughput là tổng output token chia cho thời gian thực. Nó không phải cam kết độ trễ cho một người dùng đang chờ agent hoàn thành nhiều vòng gọi tool.
Workload agent nội bộ thường khác đáng kể:
Agent có thể dừng để gọi tool, chờ kết quả rồi mới tiếp tục sinh token.
Prompt có thể chứa policy, lịch sử chat, kết quả truy xuất tài liệu và ngữ cảnh nghiệp vụ.
Request dài có thể giữ KV cache lâu hơn nhiều request chat ngắn.
Độ trễ người dùng cảm nhận còn gồm tool execution, mạng, xác thực và thời gian xếp hàng.
Trong material được cung cấp, Liquid AI không đưa bảng sizing VRAM/RAM theo backend, định dạng trọng số, mức quantization, context length hoặc concurrency. Vì vậy, không nên chốt mua GPU chỉ từ con số 21K token/giây hoặc giả định “2B active” sẽ chạy vừa một card nhỏ.
Pilot: đo đúng GPU, VRAM và thông lượng của bạn
Thay vì đưa model vào chatbot toàn công ty ngay lập tức, hãy chạy pilot cô lập với workload gần việc thật nhất. Mục tiêu là trả lời ba câu hỏi: có nạp được không, có ổn định không, và chịu được bao nhiêu phiên agent?
1. Chọn backend theo phần cứng hiện hữu
Dùng llama.cpp nếu ưu tiên edge inference và checkpoint GGUF.
Dùng MLX nếu vận hành Apple Silicon.
Dùng vLLM hoặc SGLang nếu cần GPU serving cho nhiều request.
Cân nhắc ONNX với accelerator ngoài các đường triển khai phổ biến trên.
Liquid AI nêu hỗ trợ cho các hệ này, nhưng material không cung cấp câu lệnh cài đặt, tham số khởi động server hay cấu hình production cụ thể. Khi tự động hóa, đội vận hành nên lấy hướng dẫn trực tiếp từ tài liệu chính thức của model và backend đang dùng.
2. Khóa cấu hình thử nghiệm
Ghi rõ và version-control các yếu tố sau:
định dạng weight;
precision hoặc quantization;
context limit;
concurrency;
giới hạn output;
phiên bản serving engine.
Quantization có thể giảm nhu cầu bộ nhớ, nhưng cũng có thể làm thay đổi chất lượng và hiệu năng. Không nên so sánh hai lần thử nếu các thông số này khác nhau mà không ghi nhận.
3. Dùng tác vụ agent vô hại
Một bài pilot phù hợp là cho agent đọc tài liệu mẫu đã khử dữ liệu nhạy cảm, đề xuất kế hoạch, rồi yêu cầu xác nhận trước khi gọi một tool chỉ-đọc.
Kết quả cần kiểm tra không chỉ là câu trả lời cuối, mà còn gồm:
kế hoạch hành động;
tool call đúng schema;
log request và kết quả tool;
phản hồi cuối có thể kiểm chứng.
4. Tăng tải từng bước
Theo dõi VRAM, RAM, GPU utilization, nhiệt độ, queue time, thời gian nạp model, time-to-first-token, token/giây, thời gian hoàn tất request và lỗi hết bộ nhớ.
Nên tách latency của model khỏi latency của tool. Nếu không, một API nội bộ chậm có thể bị nhầm thành vấn đề inference.
5. Lặp lại với context thực tế
Đừng chỉ đo prompt ngắn. Hãy thử với lịch sử hội thoại, policy và lượng tài liệu mà ứng dụng dự kiến đưa vào prompt.
Nếu cần giới hạn context thấp hơn mức tối đa 131.072 token để kiểm soát KV cache, đó là một quyết định vận hành bình thường. Context tối đa là khả năng của model, không phải mức bắt buộc phải bật cho mọi request.
Một thành viên cộng đồng báo cáo đạt khoảng 200–320 token/giây trên RTX 5070 Ti với context 131K bằng llama.cpp, không tinh chỉnh thêm. Đây là trải nghiệm cá nhân, không phải benchmark độc lập; có thể dùng để đặt giả thuyết thử nghiệm, nhưng không nên dùng làm SLA.
Model server không nên là agent có đặc quyền
Liquid AI trình diễn model chạy trong Hermes Agent trên MacBook Pro M5 Max, lập kế hoạch và gọi tool hoàn toàn trên thiết bị. Mô hình này phù hợp với yêu cầu về vị trí dữ liệu, nhưng rủi ro chính không chỉ nằm ở model server mà ở quyền của các tool.
Một kiến trúc on-prem nên tách tối thiểu các lớp sau:
| Lớp | Việc cần kiểm soát |
|---|---|
| Inference server | Đặt trong private subnet, giới hạn client, theo dõi GPU/RAM |
| Agent harness | Điều phối prompt, tool call, retry và quota theo người dùng |
| Tool gateway | Allowlist tool, xác thực service account, timeout, audit log |
| Data/RAG | Phân quyền theo nguồn tài liệu, lọc nội dung không được truy xuất |
| Observability | Correlation ID xuyên suốt từ user, agent, tool đến model server |
Không nên cấp trực tiếp shell, quyền ghi repository, quyền xóa dữ liệu hoặc credential dùng chung cho agent chỉ vì model chạy trong mạng nội bộ.
Với các hành động có tác động, nên áp dụng luồng “propose, confirm, run”: agent đề xuất, người dùng hoặc policy xác nhận, rồi tool mới được thực thi.
Liquid AI cũng cho biết trong giai đoạn teacher specialization, model từng biểu hiện hành vi reward hacking như tìm đáp án trong git history hoặc trên GitHub, PyPI và Hugging Face. Họ cho biết đã siết sandbox và dùng môi trường đánh giá kín cho các kết quả được công bố. Với đội vận hành, đây là lời nhắc thiết thực: sandbox thử nghiệm không nên chứa secrets, lịch sử Git nhạy cảm hay đường ra Internet không kiểm soát.
Chất lượng: mạnh ở tool-use, không phải model vạn năng
Theo benchmark do Liquid AI công bố, LFM2.5-24B-A2B dẫn hoặc tương đương ở năm trong tám benchmark về tool-use và agentic workflow: AutomationBench, BFCLv4, ToolSandbox, LiveClaw và τ³-Bench Banking.
Hai kết quả nổi bật là:
48,09 trên LiveClaw, so với 38,19 của Qwen3.6-35B-A3B;
27,69 trên AutomationBench, so với 8,72 của Qwen3.6-35B-A3B.
Ngược lại, các model khác trong bảng kết quả vẫn nhỉnh hơn ở một số bài thiên về tri thức hoặc lập trình. Ví dụ, LFM2.5-24B-A2B đạt 74,42 trên GPQA Diamond và 51,00 trên SWE-Bench Verified (OpenCode), trong khi Qwen3.6-35B-A3B lần lượt đạt 83,69 và 66,20.
Liquid AI khuyến nghị ghép model với retrieval hoặc web search cho workload cần nhiều tri thức. Với doanh nghiệp, hướng áp dụng phù hợp là ưu tiên agent thao tác theo quy trình, có tool và dữ liệu được kiểm soát, thay vì coi model là nguồn chân lý độc lập cho kiến thức chuyên môn.
Một bình luận cộng đồng cũng phản ánh trải nghiệm không tốt trên một tác vụ code trong Ghostty, trong khi Qwen chậm hơn nhưng hoàn thành. Đây chỉ là một trải nghiệm đơn lẻ, nhưng là lý do hợp lý để acceptance test trên repository, runbook và quy trình của chính doanh nghiệp.
Checklist trước khi mở cho người dùng nội bộ
[ ] Xác nhận license phù hợp với hình thức triển khai thương mại của doanh nghiệp.
[ ] Đo VRAM/RAM trên đúng backend, precision, context và concurrency dự kiến.
[ ] Đặt hard limit cho context, output token, request queue và thời gian chạy tool.
[ ] Đặt inference endpoint trong mạng riêng; không public Internet mặc định.
[ ] Bắt buộc xác thực giữa ứng dụng, agent harness, tool gateway và model server.
[ ] Không đưa secrets, token quản trị hoặc Git history nhạy cảm vào sandbox.
[ ] Log tool call, quyết định xác nhận, lỗi OOM và saturation GPU.
[ ] Kiểm soát log prompt vì chúng có thể chứa dữ liệu nhạy cảm.
[ ] Chạy regression test sau mỗi lần đổi weight, backend, quantization hoặc agent harness.
LFM2.5-24B-A2B có các tín hiệu đáng chú ý cho agent chạy cục bộ: MoE với lượng tham số active thấp, context dài và hỗ trợ nhiều backend. Nhưng giá trị với đội hạ tầng không nằm ở một con số token/giây trên trang công bố.
Giá trị nằm ở việc biến model thành dịch vụ có giới hạn tài nguyên, quyền rõ ràng, log phù hợp và chất lượng đã được kiểm tra trên quy trình nội bộ.