LFM3-1.7B vs Granite 4.2 30B: Hai mô hình agent khiến kết luận phân hóa theo từng trục đánh giá

Đặt LFM3-1.7B và Granite 4.2 30B lên cùng một trang và các mức trung bình tổng hợp lại chỉ về những hướng ngược nhau tùy theo hàng bạn đọc. Trên Berkeley Function Calling Leaderboard V4, mô hình 1,73 tỷ tham số của Liquid AI đạt 71,39 so với 61,39 của IBM — thắng mười điểm cho một mô hình nhỏ hơn khoảng mười bảy lần. Trên SWE-bench Verified, Granite đạt 57,00 so với 43,40 của LFM3-1.7B, thắng 13,6 điểm theo hướng ngược lại. Định tuyến không cộng thêm biên lợi nhuận vào giá niêm yết của nhà cung cấp. Giá niêm yết của nhà cung cấp được chuyển qua với mức tăng giá 0%.

Cả hai mô hình đều được xây dựng cho tác nhân, đều được phát hành trong vòng hai tháng của nhau vào năm 2026, và cả hai nhà cung cấp đều công bố đủ các benchmark trùng lặp để có thể so sánh thực sự thay vì chỉ là một bức ghép. Điều đó khiến đây trở thành một cuộc đối đầu hiếm hoi mà câu hỏi thú vị không phải là mô hình nào tốt hơn, mà là khối lượng công việc của bạn thực sự nằm trên trục nào. Rất ít tác vụ cần đồng thời điểm BFCL 71 và điểm SWE-bench 57, và những tác vụ như vậy không được phục vụ tốt bởi riêng mô hình nào.

Hai con số cắt nhau

Granite 4.2 30B ra mắt ngày 25 tháng 8 năm 2026 theo giấy phép Apache 2.0, một mô hình dense khoảng 30B tham số được xây dựng trên nền tảng Granite 4.1 30B và huấn luyện trên khoảng 15 nghìn tỷ token. Cách IBM định vị mô hình là hướng tới doanh nghiệp: ba chế độ tư duy có thể cấu hình, khả năng gọi công cụ gốc theo schema của OpenAI, mười hai ngôn ngữ đã được kiểm thử, và một pipeline huấn luyện ba giai đoạn kết thúc bằng học tăng cường GRPO đa giai đoạn.

LFM3-1.7B ra mắt hai tháng sau, được công bố vào ngày 27 tháng 10 năm 2026, được huấn luyện hậu kỳ (post-trained) đặc biệt trên các harness tác tử — Liquid nêu tên Hermes Agent, PI và OpenClaw trong model card. Đây là một mô hình dense 1,73B với ngữ cảnh 256K, và được định vị rõ ràng cho các tác tử cục bộ và gọi công cụ thay vì suy luận tổng quát.

Việc vượt qua trên benchmark không phải là chuyện tình cờ nhờ một con số yếu. Toàn bộ bảng công bố của LFM3-1.7B nghiêng về agentic: 71.39 BFCL V4, 80.36 ToolSandbox, 68.01 τ³-bench, 45.60 LiveClaw, 38.42 WebArena-Verified. Bảng của Granite nghiêng về kỹ thuật: 57.00 SWE-bench Verified, 33.29 SWE-bench Pro, 41.89 SWE-bench Multilingual, 38.76 SciCode, 29.24 trên TerminalBench 2.1. Mỗi nhà cung cấp tối ưu hóa cho một định nghĩa khác nhau về "agent", và các bảng benchmark phản ánh trung thực điều đó.

τ³ ở mức 68.01 so với 68.05 mới là tiêu đề thực sự.

Ẩn dưới hai khoảng cách đầy ấn tượng là một thế hòa sát nút. Trên τ³-bench, bài đánh giá sử dụng công cụ đo lường mức độ hoàn thành nhiệm vụ đa lượt với trình mô phỏng người dùng và chính sách miền, LFM3-1.7B đạt 68,01 và Granite 4.2 30B đạt 68,05 — chênh lệch 0,04 điểm, mức không thể phân biệt với nhiễu.

Đó là một kết quả thú vị hơn cả hai khoảng cách lớn, bởi τ³ là benchmark gần nhất với những gì hầu hết các triển khai agent thực sự làm: duy trì một cuộc hội thoại, tuân theo một chính sách, gọi đúng hàm, phục hồi sau một lỗi. Nếu một mô hình 1,73B ngang bằng với một mô hình dense 30B ở đó, thì số lượng tham số đang đổi lấy thứ gì đó khác ngoài khả năng sử dụng công cụ đa lượt thành thạo.

Những gì nó mang lại thể hiện rõ ở BFCL và SWE-bench, hai bộ đánh giá đo lường những thứ khác nhau. BFCL V4 kiểm tra tính đúng đắn của lời gọi hàm một lượt theo một schema — mức 71.39 của LFM3-1.7B cho thấy việc hậu huấn luyện của Liquid trên các bộ khung agent thực tế đã đem lại kết quả trực tiếp. SWE-bench Verified kiểm tra việc sửa một issue GitHub thật từ đầu đến cuối, đòi hỏi giữ repository trong ngữ cảnh, lập kế hoạch xuyên nhiều tệp và tạo ra một bản vá vượt qua các bài kiểm thử — mức 57.00 của Granite phản ánh một mô hình có năng lực làm được điều đó và một bộ dữ liệu huấn luyện được xây dựng cho mục tiêu ấy.

Vậy là sự phân tách đã rõ ràng. Mô hình nhỏ, được huấn luyện kỹ trên lược đồ công cụ: thắng bài kiểm tra gọi hàm. Mô hình lớn, được huấn luyện về sửa mã: thắng bài kiểm tra kho mã. Hòa nhau ở vùng trung gian đa lượt, nơi cả hai đều được huấn luyện riêng.

Ngữ cảnh là nơi các thông số kỹ thuật khác biệt gay gắt nhất

• Ngữ cảnh — 262.144 token cho LFM3-1.7B; 128K gốc cho Granite 4.2 30B, có thể mở rộng lên 512K. Việc mở rộng không miễn phí và IBM thẳng thắn thừa nhận rằng đó là phần mở rộng chứ không phải cửa sổ gốc.

• Duy trì ngữ cảnh dài — 65.56 trên RULER ở 128K đối với LFM3-1.7B, so với 81.4 của Granite 4.2 30B trên cùng nhóm bài đánh giá. Mô hình lớn hơn giữ được nhiều nội dung hơn của một tài liệu dài, điều này ngược lại với những gì các con số ngữ cảnh nổi bật gợi ý.

• Mức chiếm dụng — khoảng 1 GB ở 4-bit so với khoảng 30B trọng số BF16, với các bản dựng FP8, NVFP4 và MXFP4 chính thức. Đây là mô hình chạy trên một GPU, không phải mô hình dành cho laptop.

• Ngôn ngữ — mười sáu ngôn ngữ cho LFM3-1.7B so với mười hai ngôn ngữ được thử nghiệm cho Granite, với mức trùng lặp khác. Mười hai ngôn ngữ của Granite bao gồm tiếng Séc và tiếng Hà Lan; của Liquid bao gồm tiếng Thái, tiếng Việt và tiếng Indonesia.

• Chế độ suy nghĩ — Granite 4.2 30B cung cấp các chế độ đầy đủ, nỗ lực thấp và không suy nghĩ. LFM3-1.7B không có lựa chọn tương tự, và thẻ mô hình của nó nói rằng nó vốn không dành cho suy luận phức tạp nhiều bước.

• Giấy phép — Apache 2.0 cho Granite so với LFM Open License v1.0, miễn phí dưới 10 triệu USD doanh thu hàng năm và yêu cầu giấy phép thương mại nếu vượt quá mức đó.

Một mô hình dense 30B phải tốn những gì mà 1.73B không tốn?

Granite 4.2 30B là mô hình dense, nghĩa là cả ba mươi tỷ tham số đều được xử lý cho mỗi token. Ở đây không có khoản giảm trừ nào nhờ tham số hoạt động: chi phí tính toán cho mỗi token gần gấp mười bảy lần mô hình nhỏ, còn chi phí bộ nhớ là toàn bộ tệp trọng số. IBM cung cấp các bản lượng tử hóa để việc đó khả thi, nhưng không có cấu hình nào để nó chạy trên điện thoại.

Lợi thế của LFM3-1.7B không chủ yếu nằm ở tốc độ. Mà là ở chỗ mô hình vừa vặn trong cùng ngân sách bộ nhớ như phần còn lại của ứng dụng. Một mô hình 1 GB để lại chỗ cho kho tài liệu, bộ nhớ đệm và một mô hình thứ hai trên cùng thiết bị — chính điều này khiến một tác nhân cục bộ trở nên khả thi chứ không chỉ mang tính lý thuyết là cục bộ. Liquid báo cáo tốc độ giải mã nhanh hơn 1,8 đến 2,8 lần so với các phiên bản tiền nhiệm trên phần cứng đã thử nghiệm và bộ nhớ đệm KV 1,6 GB ở 128K, cả hai đều quan trọng đối với một tác nhân trên thiết bị đang duy trì một cuộc hội thoại dài.

Yếu tố bù trừ là năng lực 30B của Granite đang thực sự phát huy tác dụng trong các con số SWE-bench. Nếu công việc của agent của bạn là thay đổi mã trên toàn bộ một kho mã, khoảng cách 13,6 điểm không phải là thứ mà một mô hình nhỏ hơn có thể bù đắp bằng prompting, và khoản tiết kiệm chi phí tính toán đổi lại là một kết quả kém hơn.

Cấp phép, ký kết và câu hỏi về mua sắm

Apache 2.0 là lý do một tổ chức lớn có thể áp dụng Granite 4.2 30B mà không cần rà soát pháp lý. Không có ngưỡng doanh thu, không có điều kiện kích hoạt thương mại, không phải đàm phán. IBM cũng đã ký số bằng mật mã cho các mô hình Granite được phát hành kể từ tháng 4 năm 2026, nghe như một chi tiết nhỏ cho đến khi bạn chính là người phải chứng minh rằng trọng số trong môi trường sản xuất đúng là trọng số đã được thẩm định.

Liquid's LFM Open License v1.0 thực sự mang tính cho phép ở quy mô khởi nghiệp — miễn phí cho mục đích thương mại khi doanh thu hằng năm dưới 10 triệu USD — nhưng vượt ngưỡng đó, nó yêu cầu giấy phép thương mại trả phí. Với một nhà phát triển cá nhân hoặc một nhóm nhỏ, đây không phải vấn đề. Với một đơn vị kinh doanh bên trong một công ty lớn hơn, đó là một cuộc trao đổi bắt đầu trước lần triển khai đầu tiên và có thể không kết thúc nhanh chóng. Sự bất đối xứng đó không được phản ánh trong bất kỳ bài đánh giá chuẩn nào và thường tự nó định đoạt vấn đề.

Chạy cả hai mà không đặt cược vào bên nào

Cách làm thực tế cho một nhóm đang đánh giá hai mô hình này không phải là chọn một cái trước. Cả hai đều là open-weight và cả hai đều chưa được các bên đánh giá độc lập kiểm chứng, nghĩa là thước đo duy nhất quan trọng là thước đo của chính bạn. Hãy định tuyến các mô hình ứng viên qua một endpoint duy nhất, chạy cùng các agent trace qua cả hai, và so sánh trên tác vụ của bạn thay vì trên BFCL hay SWE-bench.

Ở đây OrcaRouter hữu ích không phải với vai trò máy chủ mà là bề mặt điều khiển: một khóa và một hóa đơn cho hơn 200 mô hình, giá niêm yết của nhà cung cấp được chuyển nguyên với mức đánh dấu 0%, và chuyển đổi dự phòng tự động để một lượt chạy đánh giá không chết chỉ vì một nhà cung cấp gặp phải một giờ trục trặc. Cả LFM3-1.7B lẫn Granite 4.2 30B hiện đều không có trong danh mục của chúng tôi — cả hai đều là bản tải xuống trọng số mở, và tự vận hành là con đường dành cho mỗi mô hình. Định tuyến khẳng định được chỗ đứng của mình ở ngăn xếp xung quanh: mô hình tiên phong mà agent của bạn nâng cấp lên, hoặc ý kiến thứ hai mà bạn đối chiếu khi bản vá của mô hình cục bộ trượt kiểm thử.

Ai nên lấy cái nào

Hãy chọn LFM3-1.7B nếu agent chạy trên thiết bị của người dùng, nếu công việc là gọi công cụ và trích xuất có cấu trúc đối với một API, và nếu ngữ cảnh 256K với dấu chân 1 GB chính là thứ khiến sản phẩm trở nên khả thi. Hãy chấp nhận cảnh báo của chính nhà cung cấp rằng nó không dành cho lập trình agentic, và giữ một mô hình lớn hơn phía sau nó cho những trường hợp cần đến.

Chọn Granite 4.2 30B nếu tác nhân có tương tác với cơ sở mã, nếu bạn cần Apache 2.0 và trọng số đã ký cho mua sắm, nếu khối lượng công việc hưởng lợi từ nỗ lực suy luận có thể cấu hình, và nếu bạn có GPU để phục vụ nó. Hạn chế của BFCL là có thật nhưng hẹp: nó đo tính đúng đắn của lược đồ trên một lệnh gọi duy nhất, và một mô hình 30B với lược đồ công cụ được thiết kế tốt sẽ thu hẹp phần lớn khoảng cách đó trên thực tế.

Hãy chọn phương án tách nếu bạn đang xây dựng thứ mà cả hai nhà cung cấp đều nhắm tới — một tác nhân cục bộ xử lý các lệnh gọi công cụ thường lệ trong một gigabyte và chuyển công việc quy mô kho mã lên máy chủ. Kiến trúc đó sử dụng mỗi mô hình ở nơi bảng đánh giá riêng của nó cho thấy nó mạnh, và đây là cách bố trí duy nhất khiến các trục chéo không còn là vấn đề.

Câu hỏi đáng quan tâm là liệu công thức hậu huấn luyện tác tử của Liquid có chuyển được sang một checkpoint lớn hơn hay không. Nếu một mô hình LFM trong tương lai giữ được hành vi BFCL kiểu 71.39 và bổ sung năng lực cho công việc với kho mã, thì sự phân tách theo trục sẽ sụp đổ và so sánh này trở thành một quyết định đơn giản về kích cỡ. Cho đến lúc đó, hai mô hình không cạnh tranh cho cùng một công việc — chúng là hai nửa của một tổng thể.