Liquid LFM3 đặt câu hỏi thiết thực hơn cho AI cục bộ: mô hình nhỏ nào làm đúng việc?

Trợ lý cục bộ đọc hóa đơn chưa chắc cần cùng mô hình với trợ lý trả lời câu hỏi bằng giọng nói. Chương trình chọn giữa ba hành động được phép lại có công việc khác. Coi chúng là một nhiệm vụ có thể khiến ứng dụng nhỏ phức tạp không cần thiết.

Liquid AI công bố LFM3 vào ngày 27 tháng 10 năm 2026: sáu mô hình thuộc nhóm khoảng 2B, phân nhánh từ nền tảng chung 1.7B, bao gồm văn bản, thị giác, âm thanh, omni và hai biến thể quyết định. Công ty cung cấp trọng số mở, Playground và truy cập API. Thông báo LFM3.

Quyết định đáng chú ý là vai trò nào phù hợp với ứng dụng. Bài viết giải thích họ mô hình qua lựa chọn thực tế, phân biệt tệp trọng số gọn với ngân sách bộ nhớ khi chạy và đề xuất lần đánh giá đầu để biết mô hình chuyên biệt có hữu ích trên phần cứng của bạn không.

Phần cứng Raspberry Pi 5, minh họa bối cảnh điện toán biên; không phải thử nghiệm LFM3 của chúng tôi. Ảnh: RetroEditor, CC BY 4.0; đã đổi kích thước và thêm lề. Nguồn ảnh · Giấy phép và ghi chú hình ảnh. Tài liệu sản phẩm chính thức.

Chọn mô hình chuyên biệt từ đầu ra cần có

Cách nhanh nhất để chọn sai là bắt đầu từ danh sách loại đầu vào dài nhất. Hãy bắt đầu từ đầu ra ứng dụng phải tạo. Một đoạn văn, bản chép lời, trường có cấu trúc và lựa chọn giữa các hành động được phép là những hợp đồng khác nhau, dù cùng tài liệu nguồn có thể giúp tạo cả bốn.

Thông báo ngày 27 tháng 10 của Liquid xác định bốn nhánh phương thức và hai nhánh quyết định: LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B, d1-2B và d1-Omni-2B. Bảng dưới chuyển các vai trò ấy thành câu hỏi lựa chọn cho ứng dụng. Đây là hướng dẫn mức độ phù hợp, không phải xếp hạng chất lượng độc lập. Mô tả họ mô hình.

Theo chúng tôi, đơn vị hữu ích của AI cục bộ là công việc hoàn chỉnh nhỏ nhất. Mô hình cần đủ khả năng đáp ứng hợp đồng ứng dụng rõ ràng, cùng cách xử lý sự không chắc chắn. Mọi thứ vượt quá đều có chi phí chạy, kiểm thử và tích hợp cần được chứng minh là xứng đáng.

Hãy hình dung họ mô hình như một bộ dụng cụ. Mang mọi dụng cụ hợp lý với một số việc; với thao tác lặp lại, chọn đúng dụng cụ có thể đơn giản hơn. So sánh này nói về thiết kế ứng dụng, không khẳng định một mô hình luôn thắng mô hình khác.

Sơ đồ giải thích do tác giả xây dựng về các vai trò nêu trong thông báo LFM3 của Liquid AI. Sơ đồ nhóm các lựa chọn ứng dụng và lược bỏ chi tiết triển khai nội bộ.

Trọng số mở đem lại lựa chọn triển khai, nhưng cần đọc giấy phép

Tải trọng số cho nhà phát triển một thứ cụ thể để đóng gói, đánh giá và điều chỉnh. Nó có thể hỗ trợ triển khai cục bộ, giữ đường đi dữ liệu ứng dụng dưới quyền kiểm soát của nhà phát triển. Điều đó hữu ích, nhưng có tệp tải được chưa quyết định các điều khoản thương mại.

Danh mục mô hình của Liquid, kiểm tra ngày 2 tháng 11, mô tả quyền sử dụng thương mại miễn phí cho đến khi doanh nghiệp vượt 10 triệu USD doanh thu hằng năm. Thẻ mô hình LFM3-1.7B xác định giấy phép LFM Open License v1.0. Hãy đọc giấy phép gắn với đúng checkpoint và trang cấp phép hiện hành theo tình huống triển khai, phân phối và doanh thu dự kiến.

Đây là bước mua sắm thực tế. Nguyên mẫu nội bộ nhỏ, ứng dụng tiêu dùng tải về và dịch vụ cung cấp cho doanh nghiệp khác có thể đặt ra câu hỏi phân phối và nghĩa vụ khác nhau. Ghi mã mô hình, bản sửa đổi và giấy phép cùng ứng dụng để quyết định vẫn truy nguyên được khi dự án lớn lên.

Phần mềm thực thi và trọng số mô hình cũng có phiên bản riêng. Mô hình có thể đã có nhưng môi trường chạy trên thiết bị vẫn chưa hỗ trợ tương thích. Kiểm tra tổ hợp được tài liệu hướng dẫn thay vì cho rằng mọi ứng dụng tải được họ trước đều tải đúng họ mới.

Với nhóm, hồ sơ này nên gồm câu lệnh hoặc mẫu đầu vào checkpoint yêu cầu. Bộ tải tương thích vẫn có thể cho hành vi kém nếu đầu vào sai định dạng. Khả năng tái lập bắt đầu bằng việc biết thứ gì thực sự được tải và ứng dụng đã giao tiếp với nó thế nào.

Khoảng 1 GB trọng số mới là điểm đầu của ngân sách bộ nhớ

Liquid mô tả dung lượng 4-bit của mô hình văn bản khoảng 1 GB trong tài liệu ra mắt ngày 27 tháng 10. Thẻ mô hình văn bản ghi 1,73 tỷ tham số và ngữ cảnh 256K token gồm cả đầu vào lẫn đầu ra. Đó là thông số mô hình; bộ nhớ đỉnh của ứng dụng còn phụ thuộc khối lượng việc và môi trường chạy.

Tệp trọng số chỉ là một phần của tiến trình đang chạy. Môi trường thực thi cần bộ nhớ làm việc; xử lý ngữ cảnh cần trạng thái; đầu vào đa phương tiện có thể cần thêm bộ đệm và bộ mã hóa. Chương trình khác trên thiết bị cạnh tranh cùng tài nguyên. Con số trọng số nổi bật không cho biết toàn bộ ứng dụng có còn vận hành thoải mái dưới tải không.

Vì vậy ngân sách minh họa nên bắt đầu từ dung lượng tiến trình đo được. Ghi trạng thái nhàn rỗi của ứng dụng, đỉnh khi xử lý yêu cầu đại diện và trạng thái sau nhiều yêu cầu. Thử độ dài ngữ cảnh và kích thước đầu vào người dùng thực sự cung cấp, thay vì câu lệnh rất nhỏ chỉ vì dễ vừa bộ nhớ.

Kỷ luật tương tự áp dụng cho thời gian. Khởi động, xử lý câu lệnh và tạo phản hồi là những khoảng chờ riêng. Mô hình tạo token nhanh sau thời gian chờ dài có thể gây cảm giác chậm trong ứng dụng tương tác; tác vụ theo lô có thể quan tâm số mục hoàn thành mỗi giờ hơn. Chọn phép đo khớp với cách tương tác.

Với tính năng âm thanh, tính toàn bộ đường từ đầu vào đến kết quả dùng được. Với ảnh, tính cả xử lý ảnh. Với quyết định, tính cả xác thực và bàn giao hành động. Đây là yêu cầu đánh giá bạn định nghĩa, không phải số liệu hiệu năng do bản phát hành cung cấp.

Sơ đồ ngân sách bộ nhớ do tác giả xây dựng. Độ rộng các phần chỉ để minh họa, không thể hiện tỷ lệ đã đo; con số khoảng 1 GB chỉ dung lượng mô hình văn bản 4-bit Liquid công bố, không phải tổng bộ nhớ ứng dụng. Nguồn.

Ba ứng dụng minh họa bộc lộ những đánh đổi khác nhau

Trợ lý tài liệu tách việc đọc khỏi việc quyết định

Hãy hình dung ứng dụng doanh nghiệp nhỏ nhận ảnh hóa đơn. Một việc là đọc tên người bán, ngày và số tiền nhìn thấy. Việc khác là quyết định tài liệu có đủ đầy để con người xem xét không. Hai đầu ra cần được xác thực riêng dù một mô hình góp phần vào cả hai.

Nhánh thị giác-ngôn ngữ có thể hỗ trợ câu hỏi về ảnh; nhánh quyết định có thể được đánh giá cho phép kiểm tra tính đầy đủ giới hạn. Ứng dụng nên giữ ảnh nguồn và phân biệt trường trích xuất với dữ liệu kế toán đã chấp nhận. Ngày bị thiếu phải tiếp tục là thiếu cho đến khi ai đó giải quyết.

Xây dựng bộ đánh giá minh họa gồm ảnh rõ, ảnh mờ, bố cục lạ và hóa đơn bằng ngôn ngữ làm việc thực tế. Đo lỗi theo từng trường và khối lượng kiểm tra. Tỷ lệ thành công chung cao có thể che lỗi lặp lại ở trường quan trọng nhất với doanh nghiệp.

Kết quả sản phẩm hữu ích là hàng chờ kiểm tra ngắn và rõ hơn. Mô hình có giải thích thanh lịch không kém quan trọng hơn việc người kiểm tra có xem được nguồn và sửa trường không. Ưu tiên này giúp chọn giữa đầu ra ngôn ngữ mở và giao diện quyết định hạn chế hơn.

Giao diện giọng nói bắt đầu bằng tập hành động được phép nhỏ

Xét trợ lý rảnh tay minh họa cho ứng dụng cục bộ. Người dùng có thể yêu cầu tìm mục, đọc trạng thái hoặc chuẩn bị bản nháp hành động. Khả năng âm thanh hữu ích khi nói dễ hơn gõ, nhưng ứng dụng vẫn cần biết yêu cầu được phép thay đổi gì.

Bắt đầu với tập hành động nhỏ và đường xác nhận hiển thị rõ. Ví dụ, yêu cầu tìm hồ sơ có thể chạy ngay trong dữ liệu đã được phép, còn yêu cầu sửa hồ sơ có thể trình bày hành động đề xuất để kiểm tra. Chính sách thuộc về ứng dụng, không phụ thuộc vào câu chữ mô hình tình cờ tạo.

Thử trong điều kiện âm học thực tế. Hội thoại nền, phát ngôn ngắn và tên tương tự có thể tạo kiểu lỗi khác câu thu sạch. Bao gồm tình huống mà kết quả đúng là hỏi lại người dùng. Câu trả lời nói trôi chảy kém hữu ích hơn tương tác đúng và có thể khôi phục.

Ứng viên omni trở nên liên quan khi yêu cầu phụ thuộc cả điều nhìn thấy lẫn điều được nói. Nếu mọi nhiệm vụ chỉ dùng lời nói, thêm xử lý thị giác cần lý do. Đây là nơi cách tổ chức theo họ có thể giúp tính năng tương xứng với công việc.

Công cụ hỗ trợ cục bộ định tuyến công việc và giữ lối chuyển tiếp

Ứng dụng hỗ trợ minh họa có thể chọn một trong ba hàng chờ dựa trên phiếu yêu cầu và ảnh chụp màn hình đính kèm. Đầu ra quyết định giới hạn có thể phù hợp trực tiếp hơn câu trả lời dài mà ứng dụng phải diễn giải. Câu hỏi hữu ích là tuyến được chọn có đủ tin cậy với tỷ lệ kiểm tra chấp nhận được không.

Giữ kết quả “cần xem xét” rõ ràng. Thử phiếu không khớp hàng chờ được phép nào, ảnh mâu thuẫn và tình huống thiếu ngữ cảnh. Ứng dụng không nên ép mô hình bịa tuyến hợp lệ chỉ vì lược đồ đòi một tuyến.

So sánh mô hình với mốc cơ bản đơn giản như quy tắc hiện có và định tuyến thủ công. Nếu mốc ấy đã xử lý một nhóm ổn định, mô hình phải cải thiện phần khác của quy trình. Tính mới lạ không phải tiêu chí nghiệm thu.

Với mỗi lỗi, giữ đủ ngữ cảnh được phép để hiểu nguyên nhân. Phân biệt vấn đề đầu vào, nhóm phân loại mơ hồ và lỗi mô hình. Sự phân biệt cho biết nên cải thiện mô hình, đổi định nghĩa hàng chờ hay yêu cầu tài liệu nguồn tốt hơn.

Bảng benchmark là điểm khởi đầu cho khối lượng việc của bạn

Thẻ mô hình LFM3-1.7B chính thức, kiểm tra ngày 2 tháng 11, khuyến nghị truy xuất hoặc tìm kiếm cho công việc nặng kiến thức và lưu ý không phù hợp với lập trình tác tử hay suy luận nhiều bước phức tạp ở quy mô này. Đó là chỉ dẫn hữu ích để đặt mô hình trong hệ thống lớn hơn, ngay cả khi bảng benchmark của nhà cung cấp thể hiện tiến bộ.

Kết quả benchmark trả lời câu hỏi cụ thể trong cấu hình nhất định. Ứng dụng bổ sung dữ liệu, công cụ, phân bố ngôn ngữ và chi phí lỗi riêng. Mô hình có thể tiến bộ ở số tổng hợp công khai mà vẫn cần làm cẩn thận với vài nhóm người dùng gặp hằng ngày.

Tách ba phép so sánh trong thử nghiệm. Thứ nhất, so chất lượng nhiệm vụ với quy trình hiện tại. Thứ hai, so toàn bộ chi phí tài nguyên trên thiết bị đích. Thứ ba, so công sức khôi phục khi thất bại. Các phép so sánh ấy có thể đưa ra bên thắng khác nhau.

Ví dụ, mô hình đa năng trên đám mây có thể hữu ích làm đường chuyển cấp khi mô hình chuyên biệt cục bộ từ chối. Cấu hình đó cần chính sách dữ liệu và trải nghiệm người dùng rõ ràng. Vận hành cục bộ là lựa chọn triển khai phải xác minh trên toàn ứng dụng, kể cả ghi log và yêu cầu dự phòng.

Tinh chỉnh nên theo sau khoảng trống đã chứng minh. Nếu lỗi đến từ thiếu tài liệu nguồn hoặc định nghĩa đầu ra mơ hồ, huấn luyện thêm có thể củng cố sai nhiệm vụ. Định nghĩa hợp đồng và xem lỗi trước khi quyết định tùy biến là bước hữu ích tiếp theo.

Thử nghiệm đầu tiên nên vừa trong một trang quyết định

Thẻ mô hình văn bản chính thức liên kết các định dạng checkpoint và hướng dẫn môi trường chạy. Bắt đầu ở đó để chọn đúng tổ hợp mô hình/môi trường; dùng Playground chính thức để kiểm tra tương tác ban đầu nếu phù hợp chính sách dữ liệu. Không đường nào thay cho kiểm thử bản triển khai bạn định phát hành.

1. Viết hợp đồng đầu vào và đầu ra. Nêu tài liệu được phép, kết quả mong đợi và kết quả chuyển kiểm tra rõ ràng. Chọn một nhiệm vụ thay vì tính cách trợ lý tổng quát.
2. Chọn ứng viên và bản sửa đổi. Khớp phương thức và vai trò đầu ra, rồi ghi checkpoint, giấy phép và môi trường chạy tương thích. Đọc giới hạn riêng của mô hình.
3. Tạo bộ đánh giá đại diện. Gồm ca bình thường, ca khó, yêu cầu không hỗ trợ và ví dụ bằng ngôn ngữ người dùng thực tế. Giữ tài liệu kiểm tra độc lập tách khỏi dữ liệu tùy biến.
4. Chạy hướng dẫn khởi động nhanh trong môi trường cách ly. Theo hướng dẫn phụ thuộc và định dạng hiện hành trong thẻ mô hình. Xác nhận danh tính mô hình trả về trước khi so đầu ra.
5. Đo toàn bộ đường đi ứng dụng. Ghi tính đúng đắn, tỷ lệ kiểm tra, độ trễ và bộ nhớ đỉnh với kích thước đầu vào thực tế. Ghi phần cứng và thiết lập môi trường cùng số liệu.
6. Thử đường xử lý bất định. Xác nhận thiếu thông tin, đầu ra không hợp lệ và lỗi môi trường dẫn đến trạng thái kiểm tra hoặc thử lại dễ hiểu.
7. Quyết định phần chuyên biệt hóa tiếp theo. Dùng nhóm lỗi lặp lại để chọn giữa đầu vào tốt hơn, quy tắc rõ hơn, truy xuất, tinh chỉnh hoặc mô hình khác.

Ở lượt đầu, quyết định bằng văn bản có thể đơn giản: ứng viên này hữu ích cho nhiệm vụ này trên thiết bị này, với những điều kiện kiểm tra này. Kết luận hẹp, tái lập được giá trị hơn tuyên bố chung rằng AI cục bộ đã sẵn sàng cho mọi việc.

Mô hình nhỏ xứng đáng khi hoàn thành công việc xác định

LFM3 mở rộng lựa chọn cho nhà phát triển muốn văn bản, thị giác, âm thanh hoặc quyết định có giới hạn ở gần ứng dụng. Ý nghĩa thực tế nằm ở khả năng chọn giữa các vai trò và đánh giá chúng như thành phần của sản phẩm.

Bước tiếp theo là làm một công việc đủ cụ thể để đo được chất lượng, bộ nhớ và khả năng khôi phục. Mô hình chuyên biệt hữu ích khi toàn ứng dụng có thể dựa vào hợp đồng của nó và biết phải làm gì khi nó không thể trả lời.

Nguồn

• Liquid AI: Giới thiệu LFM3, ngày 27 tháng 10 năm 2026; kiểm tra ngày 2 tháng 11 năm 2026.
• Danh mục mô hình Liquid AI và giá và cấp phép, kiểm tra ngày 2 tháng 11 năm 2026.
• Thẻ mô hình LFM3-1.7B chính thức, kiểm tra ngày 2 tháng 11 năm 2026.
• Thẻ mô hình d1-2B chính thức, kiểm tra ngày 2 tháng 11 năm 2026.

Lưu giữ tài liệu làm cơ sở cho quyết định

Telli.sh là một lựa chọn để lưu tài liệu nguồn được phép sử dụng bên cạnh những ghi chú bạn đã xem lại. Tạo không gian ghi chú.