Model nhỏ: đừng chỉ hỏi nó thông minh không

Model nhỏ: đừng chỉ hỏi nó thông minh không

LFM2.5-230M đáng chú ý không vì nó thay thế model lớn, mà vì nó ép team builder hỏi lại: việc nào nên chạy ngay trên thiết bị?

Có một kiểu họp AI rất quen ở team Việt Nam: vừa mở laptop ra, ai đó đã hỏi “model này so với model kia có thông minh hơn không?”. Mình nghe câu đó nhiều tới mức muốn đặt sẵn một cái chuông nhỏ trên bàn, ai hỏi là ting một cái.

Nhưng với các model cực nhỏ kiểu LFM2.5-230M của Liquid AI, câu hỏi đó hơi lệch. Nó giống như bạn cầm một chiếc nồi nhỏ rồi hỏi có nấu được tiệc cưới không. Sai bài toán. Cái đáng hỏi hơn là: nồi này có đủ nhanh, đủ gọn, đủ ổn để nấu phần việc lặp lại mỗi ngày ngay tại chỗ không?

Luận điểm của mình: model nhỏ trên thiết bị không phải bản rút gọn đáng thương của model lớn; nó là một lớp vận hành khác, dành cho những việc cần latency thấp, riêng tư, và có guardrail rõ. Nếu đọc xong bài này mà bạn vẫn chỉ so benchmark tổng quát, coi như mình đã làm cháy món.

Sơ đồ minh họa cho bài Model nhỏ: đừng chỉ hỏi nó thông minh không

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

Chuyện đang xảy ra: model nhỏ bắt đầu có chỗ đứng riêng

LFM2.5-230M là model text-only 230 triệu tham số, open-weight, có cả bản base và instruction-tuned. Điểm làm nó đáng để tech lead ngó qua không phải vì nó hứa hẹn “làm mọi thứ”, mà vì phạm vi khá hẹp: data extraction và tool use trên phone, robot, thiết bị automation.

Một vài chi tiết kỹ thuật đáng giữ trong đầu:

Ở đây có vài thuật ngữ cần neo nhanh. On-device inference là chạy model ngay trên thiết bị của người dùng hoặc máy biên, không gửi toàn bộ dữ liệu lên server. Tool use là khả năng model gọi công cụ/API theo schema, thay vì chỉ trả lời chữ. Instruction-tuned là model đã được tinh chỉnh để làm theo chỉ dẫn tốt hơn bản base.

Nói thẳng ra thì, đây không phải model để bạn giao viết module thanh toán, giải toán khó, hay brainstorming slogan. Nó giống phần bếp prep: thái, lọc, phân loại, gọi đúng dụng cụ — làm nhanh và đều, nhưng đừng bắt nó nấu nguyên mâm cỗ.

Mổ xẻ đúng chỗ: tốc độ chỉ là một nửa câu chuyện

Rất dễ nhìn con số tokens/giây rồi phấn khích. Nhưng với builder, tốc độ model chỉ có ý nghĩa khi nó gắn với workflow thật.

Ví dụ cụ thể: team bạn đang làm app bảo trì thiết bị. Kỹ thuật viên chụp ảnh tem máy, nhập vài dòng ghi chú, rồi app cần:

  1. trích xuất mã thiết bị,
  2. xác định loại lỗi từ mô tả ngắn,
  3. gọi tool tạo ticket,
  4. nếu thiếu dữ liệu thì hỏi lại đúng một câu.

Nếu việc này chạy bằng cloud model, bạn có chất lượng cao hơn, nhưng phải trả giá bằng network, latency, quyền riêng tư, và chi phí theo lượt. Nếu chạy bằng model nhỏ trên thiết bị, bạn chấp nhận phạm vi hẹp hơn để đổi lấy phản hồi nhanh và ít phụ thuộc kết nối.

Đây là chỗ nhiều team hiểu sai: model nhỏ không thắng bằng khả năng “biết nhiều”; nó thắng khi bạn cắt bài toán đủ gọn.

LFM2.5-230M cũng tự đặt ranh giới khá rõ: tốt cho extraction và tool use; không nên kỳ vọng mạnh ở math, code generation, creative writing. Với mình, đây là tín hiệu lành mạnh. Một release biết nói “tôi không làm tốt món này” thường hữu ích hơn một model cố tỏ ra cái gì cũng biết.

Framework 4 ô: việc nào được xuống edge?

Thay vì hỏi “có nên dùng LFM2.5-230M không?”, mình sẽ hỏi theo 4 ô này. Gọi vui là bảng nêm nếm edge: ít muối thì nhạt, quá tay thì mặn, nhưng có công thức thì đỡ đoán mò.

| Tiêu chí | Hợp để chạy on-device | Nên giữ ở cloud/model lớn |
|---|---|---|
| Độ phức tạp | Extraction, phân loại, gọi tool theo schema | Reasoning dài, code phức tạp, phân tích pháp lý sâu |
| Dữ liệu | Nhạy cảm, cục bộ, không muốn gửi đi | Dữ liệu đã được phép xử lý tập trung |
| Latency | Cần phản hồi gần tức thì, mạng chập chờn | Chấp nhận chờ để lấy chất lượng cao hơn |
| Failure cost | Sai có thể bắt người dùng xác nhận lại | Sai gây thiệt hại lớn hoặc khó phát hiện |

Một quyết định thực dụng: đưa bước “nhìn, lọc, gọi tool đơn giản” xuống thiết bị; giữ bước “suy luận, tổng hợp, ra quyết định quan trọng” ở backend.

Đây cũng là lý do mình thấy LFM2.5-230M nên được đọc cùng vài tín hiệu khác. DSpark của DeepSeek tập trung vào speculative decoding — kỹ thuật cho model nhỏ/draft đề xuất token để model lớn kiểm chứng, nhằm tăng tốc serving. Qdrant Edge thì kéo vector search, tức tìm kiếm bằng vector, về thiết bị. Transformers.js và Cross-Origin Storage API lại chạm vào bài toán cache model trong browser. Các mảnh này nói cùng một điều: hệ AI đang tách thành nhiều lớp nhỏ hơn, không còn mặc định mọi thứ phải chạy ở một model lớn trên cloud.

Một buổi thử nhỏ: đừng benchmark lan man

Nếu team bạn muốn đánh giá một model on-device như LFM2.5-230M, đừng bắt đầu bằng bảng leaderboard dài. Bắt đầu bằng một workflow có thể kiểm trong một buổi.

Chọn một tác vụ hẹp, ví dụ:

Đặt trước output contract, ví dụ:

{
  "device_id": "string | null",
  "error_code": "one_of: E01,E02,E03,E04,E05,E06,E07,E08,E09,E10 | null",
  "confidence": "low | medium | high",
  "next_action": "create_ticket | ask_user | escalate"
}

Rồi đo 5 thứ, không cần màu mè:

  1. Schema validity: output có parse được không?
  2. Field accuracy: các trường quan trọng đúng bao nhiêu trên tập test thủ công?
  3. Latency trên thiết bị thật: không chỉ laptop dev.
  4. Fallback rate: bao nhiêu lần phải chuyển lên model lớn hoặc hỏi lại người dùng?
  5. Operator effort: người vận hành phải sửa bao nhiêu kết quả?

Lưu ý: nếu bạn dùng con số minh họa nội bộ, hãy ghi rõ đó là giả sử. Ví dụ, giả sử team có 50 mẫu phiếu và 10 mã lỗi, mục tiêu không phải chứng minh model “thông minh”, mà xem nó có giảm thao tác lặp lại mà không tạo thêm việc kiểm lỗi hay không.

Guardrail: tiêu chí dừng quan trọng hơn tiêu chí khoe

Một prototype edge AI rất dễ trông ngon trong demo. Nhưng production thì hay hỏng ở những chỗ bé xíu: JSON thiếu field, tool call sai tham số, model tự tin với dữ liệu mờ, cache model làm app phình to, hoặc thiết bị nóng lên sau vài phút chạy liên tục.

Với model nhỏ, mình sẽ đặt guardrail trước khi scale:

Tiêu chí nên dừng cũng phải rõ. Dừng nếu model thường xuyên sinh output không parse được, fallback quá nhiều khiến tổng latency tệ hơn cloud, hoặc operator mất công sửa hơn trước. Dừng không phải thất bại; đôi khi chỉ là bạn phát hiện món này cần thêm lửa, chưa nên bưng ra bàn.

Điều đáng giữ, điều nên bỏ qua

Điều đáng giữ từ LFM2.5-230M không phải câu chuyện “model nhỏ đánh bại model lớn”. Cách đọc đó dễ kéo team vào so sánh sai. Thứ đáng giữ là một mẫu thiết kế:

Điều nên bỏ qua là ham muốn biến nó thành chatbot tổng quát. Với 230M tham số, footprint vài trăm MB và mục tiêu edge, bạn nên đối xử với nó như một worker chuyên việc, không phải cố vấn toàn năng.

Câu trả lời cho câu hỏi “sau bài này bạn nên nghĩ khác điều gì?” là: đừng chọn model theo độ ồn của release; hãy chọn theo vị trí của nó trong dây chuyền vận hành. Model nhỏ có thể rất giá trị, miễn là bạn giao đúng việc, đo đúng thứ, và biết lúc nào phải dừng.

Còn nếu bạn bắt cái nồi nhỏ nấu đại tiệc rồi chê nó không đủ sang, lỗi không nằm ở cái nồi đâu.

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

Nguồn tham khảo