Liquid AI d1-omni-600M so với Liquid AI d1-3B: Bạn thực sự cần nửa nào của dòng d1?

Liquid AI d1-omni-600M và Liquid AI d1-3B được tải lên Hugging Face cách nhau trong vòng tám giờ vào ngày 5 tháng 10 năm 2026 và được phát hành cùng nhau trong cùng một thông báo ngày 7 tháng 10, khiến câu hỏi quen thuộc — cái nào mới hơn, cái nào tốt hơn — trở thành câu hỏi sai. Chúng là hai đầu của một sự đánh đổi có chủ đích. Liquid AI d1-3B là sản phẩm hoàn chỉnh: 3,12B tham số, 48,57 trên Decision Index 0.2.1 do nhà cung cấp chấm điểm, các bảng benchmark, độ trễ được đo xuống tận Jetson Orin Nano, và một vị trí được mô tả trong bài công bố là chất lượng quyết định cao nhất ở kích thước của nó. Liquid AI d1-omni-600M là thử nghiệm: 587M tham số, 15,95 trên cùng chỉ số đó, đầu vào âm thanh mà bản 3B không có, và một thẻ mô hình nói thẳng rằng đây là bản phát hành nghiên cứu sơ khai không có số liệu suy luận vì nó vẫn đang được phát triển tích cực. Lựa chọn giữa chúng không phải là một quyết định về chất lượng. Đó là quyết định về việc bạn cần thêm các phương thức ở phía dưới cùng của dòng mô hình hay độ chính xác cao hơn ở phía trên cùng, và các con số đều ủng hộ sự phân tách đó chứ không làm mờ nó đi.

Tất cả nội dung dưới đây đến từ hai thẻ mô hình và bài đăng phát hành ngày 7 tháng 10, đồng thời tuân theo cách ghi nhãn của chính bài đăng phát hành: các hàng d1 trên Decision Index được Liquid AI chấm điểm bằng trình chấm điểm chính thức thay vì được gửi lên bảng xếp hạng công khai, và không có nội dung nào ở đây đã được tái lập độc lập.

Hai xương sống vốn dĩ không bao giờ hội tụ

Dòng d1 không thu nhỏ một công thức duy nhất nào. Hai checkpoint xuất phát từ hai đầu đối lập trong danh mục mô hình của Liquid và gặp nhau ở chính giữa.

Liquid AI d1-3B được xây dựng dựa trên LFM2.5-VL-3B, mô hình ngôn ngữ-thị giác chỉ-giải mã của nhà cung cấp từ tháng 8 năm 2026. Nền tảng của nó được tạo ra bằng cách lấy trung bình trọng số của LFM2.5-2.6B với xương sống văn bản của LFM2.5-VL-3B, sau đó tinh chỉnh các checkpoint dưới các hạt giống ngẫu nhiên và hỗn hợp dữ liệu khác nhau trước khi hợp nhất chúng lần nữa. Nó mang một bộ mã hóa thị giác SigLIP2 NaFlex 400M được tối ưu hóa hình dạng, ngữ cảnh 32.768 token, từ vựng 128.000 token và mười sáu ngôn ngữ được ghi nhận.

Liquid AI d1-omni-600M đến từ hướng ngược lại. Phần thân chính của nó là LFM2.5-Encoder-350M, một bộ mã hóa hai chiều, được tinh chỉnh trên các tác vụ ra quyết định trước rồi sau đó được mở rộng theo từng giai đoạn — một bộ mã hóa FastConformer 17 lớp cùng adapter cho âm thanh, với bộ mã hóa âm thanh về sau được tinh chỉnh dựa trên một xương sống văn bản đóng băng, rồi một tháp SigLIP2 được lấy từ LFM2.5-VL-450M với một adapter và các cập nhật LoRA cho xương sống đối với thị giác. Mô hình cuối cùng được hợp nhất từ các cập nhật LoRA và lấy trung bình với checkpoint trước đó. Nó kết thúc ở mức tổng cộng 587M tham số: một phần thân chính dùng chung 381M và đầu quyết định, một bộ mã hóa thị giác 94M và một bộ mã hóa âm thanh 112M.

Decoder-only so với hai chiều là điểm cần nắm chắc. 3B đọc một trạng thái và đưa ra quyết định theo cách một mô hình ngôn ngữ tạo ra chuỗi token, mỗi lần một hướng. 600M đọc toàn bộ trạng thái trong một lần rồi quyết định, đúng như điều bạn sẽ kỳ vọng từ một encoder vốn chưa từng được xây dựng để sinh. Cả hai đều được huấn luyện để báo cáo câu trả lời dựa trên phân phối của mô hình mà không sinh ra token đầu ra nào, nhưng bộ máy bên dưới không thuộc cùng một lớp mô hình, và khoảng cách độ chính xác ở dưới là cái giá hữu hình của thiết kế nhỏ hơn, mang hình dáng encoder.

Độ phân tán của Decision Index khá lớn, và các điểm số thành phần thì thú vị hơn tổng số.

Trên Decision Index 0.2.1, Liquid báo cáo 48,57 cho Liquid AI d1-3B và 15,95 cho Liquid AI d1-omni-600M, so với 50,02 cho Winnow-12B. Đó là khoảng cách 32 điểm giữa hai checkpoint được phát hành cùng ngày bởi cùng một phòng thí nghiệm, và đọc năm điểm thành phần sẽ giải thích được điều đó đến từ đâu.

• Kiến thức — 23,8 cho Liquid AI d1-3B so với 8,3 cho Liquid AI d1-omni-600M

• Ngôn ngữ — 56,4 so với 12,9

• Truy xuất — 52,8 so với 35,0

• Công cụ — 74,5 so với 15,1

• Nghệ thuật — 36,3 so với 6,8

Truy xuất là một chỗ mà mô hình nhỏ vẫn giữ vững thế trận, chỉ mất chưa đến một phần ba điểm của 3B, trong khi ở bốn hạng mục còn lại nó mất 60 đến 80 phần trăm. Kiểu kết quả đó nhất quán với bản chất của 600M: một encoder đã được huấn luyện, có năng lực biểu diễn thực sự để so khớp một trạng thái với nội dung, và có ít hơn nhiều năng lực phân tầng mà 3B thừa hưởng từ một decoder đã được tiền huấn luyện trên lượng ngôn ngữ nhiều hơn hẳn. Nếu khối lượng công việc của bạn là một quyết định mang dạng truy xuất — đoạn văn này có trả lời câu hỏi này không, tài liệu nào trong số này là liên quan — thì hồ sơ của 600M không tệ đến mức mà tổng điểm của nó gợi ý. Nếu khối lượng công việc của bạn là một quyết định định tuyến công cụ, khoảng cách 51 điểm trong cột đó chính là con số bạn cần nhìn thẳng vào.

Bảng đánh giá chuẩn văn bản kể một câu chuyện nhẹ nhàng hơn chỉ số, điều này đáng biết trước khi một trong hai con số được dùng để lập luận. Trên bảy bộ đánh giá chuẩn công khai, 3B dẫn đầu với trung bình 82,9 và 600M đạt 78,4. 600M thực ra thua sát nút trên SQuAD 2.0 (74,0 so với 85,3), PubMedQA (61,3 so với 66,0), BoolQ (77,7 so với 86,7) và XNLI (74,7 so với 85,0), nhưng thắng trên phát hiện độc hại Civil Comments (95,8 so với 93,0) và nhận diện diễn giải PAWS-X (79,5 so với 76,9). Cách diễn đạt của chính Liquid là 600M đánh bại mức trung bình 77,1 của Decider 2B với chỉ một phần tư số tham số. Hai bộ đánh giá chuẩn, hai phán quyết bề ngoài khác nhau, cả hai đều do nhà cung cấp báo cáo — đó là những gì bằng chứng ủng hộ và không hơn thế.

Những gì 600M có mà 3B không có

Lý do để chấp nhận một khoảng cách chỉ số 32 điểm là Liquid AI d1-omni-600M làm được một điều mà Liquid AI d1-3B không thể, và đó không phải là khác biệt về độ trung thực.

• Âm thanh — Liquid AI d1-omni-600M xử lý tối đa 30 giây giọng nói mỗi yêu cầu thông qua bộ mã hóa FastConformer của nó; Liquid AI d1-3B không xử lý giây nào

• Trộn phương thức — 600M chấp nhận văn bản với hình ảnh hoặc văn bản với âm thanh, và báo lỗi ValueError nếu cả hai cùng đến; 3B thì nhận văn bản và hình ảnh

• Cửa sổ ngữ cảnh — 16.384 token trên các vị trí văn bản, hình ảnh và âm thanh đối với 600M, với văn bản được cắt bớt còn 896 token khi có hình ảnh; 32.768 token cho 3B

• Từ vựng — 65.536 cho mô hình 600M, 128.000 cho mô hình 3B

• Độ chính xác — thẻ 600M khuyến nghị dùng float16 trên GPU và cảnh báo rằng bfloat16 đã làm thay đổi câu trả lời hàng đầu ở một số dòng; mô hình 3B cung cấp 15 phiên bản lượng tử hóa, bao gồm cả bản dựng w8a8

• Ngôn ngữ — 600M liệt kê 16 ngôn ngữ trong một bộ khác với 16 ngôn ngữ của 3B, và âm thanh của nó được mô tả là được huấn luyện trên các cuộc trao đổi giữa một người nói tiếng Anh và một trợ lý, vốn chỉ là một lát cắt hẹp của những gì một nguồn âm thanh sản xuất chứa đựng

Ghi chú huấn luyện âm thanh rất dễ bị đọc lướt qua và không nên như vậy. Một mô hình được huấn luyện trên các cuộc trao đổi giữa người nói tiếng Anh và trợ lý chỉ từng thấy một dạng hình học người nói, một cấu trúc lượt nói và một phân bố giọng. Triển khai nó trên âm thanh tổng đài hoặc bản ghi thực địa là đòi hỏi một hành vi mà thẻ không hề tuyên bố, và bài đăng phát hành thẳng thắn rằng không tồn tại chuẩn đánh giá quyết định âm thanh nào để đối chiếu với nó — Liquid gọi đó là "một vấn đề còn bỏ ngỏ hiện nay" và mời cộng đồng xây dựng một chuẩn như vậy.

Độ trễ: một người anh chị em có các bảng, người kia chỉ có một chú thích

Đối với các mô hình quyết định, con số đáng quan tâm là độ trễ đầu-cuối, vì không có bước giải mã để tính thời gian. Liquid công bố đầy đủ cho 3B và không công bố gì cho 600M.

• Một câu hỏi — 8 ms trên RTX 4090, 9 ms trên MI325X, 16 ms trên Jetson AGX Thor, 26 ms trên Jetson AGX Orin 64 GB, 50 ms trên Orin Nano, 30 ms trên Apple M5 Pro

• Ba câu hỏi trên một trạng thái — 21 ms trên RTX 4090 và 20 ms trên AGX Thor, chi phí chỉ khoảng 1,3 lần so với một câu hỏi duy nhất thay vì 3 lần

• Một trạng thái 3,4K token — 102 ms trên 4090, 220 ms trên Thor, 1.640 ms trên Orin Nano

• Thông lượng đóng gói — 475 quyết định mỗi giây trên RTX 4090, 1.106 quyết định mỗi giây trên MI325X

• Ảnh 384px — 17 ms trên 4090, 18 ms trên MI325X

Những con số đó chỉ mô tả Liquid AI d1-3B. Còn với Liquid AI d1-omni-600M, thẻ mô hình nêu rõ rằng các con số suy luận không được báo cáo vì đây là bản phát hành nghiên cứu sớm đang trong quá trình phát triển tích cực. Không phải mô hình nhỏ chạy chậm hơn — điều ngược lại gần như chắc chắn, vì một phần năm số tham số thì không thể chậm hơn ở cùng độ chính xác — mà là không có con số nào tồn tại, và việc trích dẫn số mili-giây của bản 3B để gán cho bản 600M sẽ là một sự bịa đặt được khoác lên một hình hài nghe có vẻ hợp lý. Điều có thể nói mà không cần bịa ra bất cứ thứ gì là ở độ chính xác float16 mà thẻ mô hình khuyến nghị, 587M tham số tương đương khoảng 1,2 GB trọng số trước khi tính đến các activation, đó là phép tính số học trên một số lượng tham số đã công bố chứ không phải một phép đo.

Cascade chính là câu trả lời thực sự cho hầu hết các khối lượng công việc

Vì cả hai checkpoint được phát hành cùng nhau và trả về cùng một loại đối tượng — một xác suất, một nhãn kèm độ tin cậy, hoặc một điểm số có thứ tự — nên chúng kết hợp với nhau theo cách mà hai mô hình tùy ý không làm được. Mô hình 600M có thể sàng lọc và mô hình 3B có thể phân xử. Chấm điểm các mục đến bằng Liquid AI d1-omni-600M, và chuyển những mục mà nó đặt gần giữa thang đo của mình sang Liquid AI d1-3B để có phán quyết sắc nét hơn. Các quy tắc chuyển cấp là độ tin cậy và phân phối mà 600M đã trả về, nên logic định tuyến không cần thêm mô hình nào. Trên một khối lượng công việc có đa số áp đảo là các mục dễ, phần lớn lưu lượng không bao giờ chạm tới 3B và phần lớn chi phí không bao giờ bị tiêu tốn.

Mô hình đó cũng là lý do hai mô hình này đáng để chạy phía sau một router. Thông qua OrcaRouter, cả hai sẽ nằm sau một API key với giá niêm yết của từng nhà cung cấp được chuyển nguyên với 0% phụ giá, nên chuỗi xếp tầng chỉ là một quy tắc định tuyến thay vì một tích hợp thứ hai, và một lần chuyển cấp thất bại ở tầng nhà cung cấp sẽ được thử lại trên phương án dự phòng thay vì làm yêu cầu thất bại. Tự động chuyển đổi dự phòng ở đây quan trọng hơn so với một mô hình đã ổn định, bởi vì một nửa của cặp này là một checkpoint mà chính nhà cung cấp mô tả hành vi của nó là đang được phát triển tích cực.

Không điều nào trong số đó là một tuyên bố về tính khả dụng, và sự phân biệt này đáng được nói thẳng ra: các checkpoint d1 mở không nằm trong danh mục của chúng tôi. Con đường của nhà cung cấp là tải trọng số về và chạy chúng cục bộ — hỗ trợ llama.cpp đã có ngay từ ngày đầu trên phần cứng Apple, AMD, Qualcomm và NVIDIA — hoặc truy cập chúng thông qua API riêng của nhà cung cấp và các nền tảng bên thứ ba.

Chọn, trong một lượt

Nếu bạn cần văn bản và hình ảnh, và câu trả lời phải chính xác, hãy chọn Liquid AI d1-3B. Nó có các benchmark, bảng độ trễ, ngữ cảnh rộng hơn, vốn từ lớn hơn và các bản lượng tử hóa, và đây là thành viên trong cặp mà Liquid định vị là dẫn đầu về chất lượng ở kích thước của nó.

Nếu bạn cần giọng nói trong đường ra quyết định, hãy chọn Liquid AI d1-omni-600M, vì đây là tùy chọn trọng số mở duy nhất trong họ này có chấp nhận âm thanh, và hãy chấp nhận rằng bạn đang chọn nó dựa trên cảm tính và một bản demo cho đến khi ai đó công bố một benchmark ra quyết định bằng âm thanh hoặc phần tách thị giác bị giữ kín.

Nếu bạn chưa biết cái nào trong số đó mô tả khối lượng công việc của mình, hãy bắt đầu với 3B và đo lường độ tin cậy mà nó trả về. Các điểm phụ chính là manh mối: một tác vụ nằm trong cột Tools hoặc Language sẽ bị 600M phục vụ kém, trong khi một thứ mang dạng truy hồi lại là trường hợp duy nhất mà checkpoint nhỏ tiệm cận gần hơn mức tổng thể của nó ngụ ý. Dòng mô hình này tồn tại để bạn có thể đánh đổi độ chính xác lấy dấu chân tài nguyên, và việc đánh đổi chỉ an toàn nếu bạn biết tác vụ của mình đang nằm ở cột nào.

Thông qua OrcaRouter, cả hai mô hình đều nằm sau một khóa API chỉ với một quy tắc định tuyến thay vì một tích hợp thứ hai và một yêu cầu chuyển cấp khi thất bại ở tầng nhà cung cấp sẽ được thử lại trên phương án dự phòng thay vì làm yêu cầu thất bại.