Liquid AI d1 vs Liquid AI d1-omni-600M: Mô hình Quyết định Mở có thể nghe thấy bạn

Tìm tên Liquid AI d1 và bạn sẽ thấy một mô hình ba tỷ tham số đọc được văn bản và hình ảnh. Checkpoint mở còn lại trong cùng dòng họ chỉ có kích thước bằng một phần năm, xử lý tối đa ba mươi giây âm thanh, và là mô hình duy nhất trong hai mô hình có thể đưa ra bất kỳ quyết định nào về giọng nói. Nó được gọi là Liquid AI d1-omni-600M, và nếu bạn biết đến dòng họ này qua một thư viện runtime cục bộ thay vì qua tài liệu của chính nhà cung cấp, thì khá có khả năng bạn chưa từng thấy tên nó. Đó chính là tình huống mà bài so sánh này nhằm khắc phục, bởi vì hai mô hình không phải là những câu trả lời cạnh tranh cho cùng một câu hỏi. Chúng là câu trả lời cho hai câu hỏi khác nhau, và chỉ một trong hai có liên quan đến việc lắng nghe.

Mọi số liệu dưới đây đều đến từ tài liệu của chính Liquid AI: thẻ mô hình LiquidAI/d1-omni-600M, kho lưu trữ d1-omni-600M-GGUF đi kèm, và bài đăng phát hành ngày 7 tháng 10 đã công bố cả hai checkpoint mở cùng một lúc. Các hàng hiệu năng được nhà cung cấp chấm điểm trên một chỉ số do họ duy trì, chứ không phải được gửi đi để xếp hạng công khai, và bài đăng nói thẳng rằng các benchmark chuyên biệt cho việc ra quyết định âm thanh vẫn là một vấn đề mở. Chưa có nội dung nào ở đây được bất kỳ ai ngoài phòng thí nghiệm tái lập.

587 triệu tham số được tạo nên từ gì

Con số trên tiêu đề che giấu một sự phân tách bất thường. Tổng số tham số là 587M, và chúng không phải một khối duy nhất: một trục chính dùng chung 381M với đầu quyết định gắn kèm, một bộ mã hóa thị giác 94M, và một bộ mã hóa âm thanh 112M. Mọi phương thức đều chạy qua cùng trọng số trục chính, và đây là quyết định thiết kế giữ cho toàn bộ hệ thống nhỏ gọn — mô hình không phải là ba mô hình khoác chung một chiếc áo măng tô, mà là một trục quyết định duy nhất với hai cách để nạp dữ liệu vào nó.

Các thành phần này đến từ những vị trí khác nhau trong danh mục của Liquid. Phần thân bắt nguồn từ LFM2.5-Encoder-350M, một bộ mã hóa hai chiều, chứ không phải từ dòng chỉ có bộ giải mã mà phiên bản anh em lớn hơn của nó đến từ. Tháp thị giác là một SigLIP2 được lấy từ LFM2.5-VL-450M với một adapter và các cập nhật LoRA được áp dụng cho backbone. Nhánh âm thanh là một bộ mã hóa FastConformer 17 lớp với adapter riêng, được tinh chỉnh dựa trên một backbone văn bản đóng băng. Thẻ mô hình báo cáo ngữ cảnh 16.384 token được chia sẻ chung cho các vị trí văn bản, hình ảnh và âm thanh, với văn bản được cắt gọn còn 896 token khi có hình ảnh, và bộ từ vựng 65.536 token — bằng một nửa so với 128.000 của phiên bản anh em lớn hơn. Con số cuối cùng đó đáng để lưu ý nếu bạn làm việc với một ngôn ngữ mà dòng mô hình này chỉ bao phủ một phần.

Bidirectional so với decoder-only là lý do hai mô hình này tạo cảm giác khác nhau đối với bất kỳ ai đã chạy thử cả hai. Phần thân mang hình dạng encoder đọc toàn bộ trạng thái cùng một lúc, theo cả hai chiều, trước khi tạo ra bất cứ thứ gì. Mô hình mang hình dạng decoder đọc tiến về phía trước theo cách một mô hình ngôn ngữ vẫn làm. Cả hai đều được huấn luyện để đưa ra câu trả lời từ một phân phối mà không có token đầu ra nào, nên không mô hình nào viết văn bản — nhưng cỗ máy bên dưới là một lớp mô hình khác, và khoảng cách độ chính xác được thảo luận bên dưới chính là cái giá hữu hình của thiết kế nhỏ hơn, mang hình dạng encoder.

Ba mươi giây phát biểu, và chẳng có gì để đánh giá nó

Âm thanh là lý do checkpoint này tồn tại. Nó nhận một clip duy nhất dài tối đa 30 giây, mono 16 kHz, trong cùng lượt truyền xuôi tạo ra câu trả lời, và đây là thành viên open-weight duy nhất trong dòng mô hình có thể làm được điều đó. Đối với công việc trên thiết bị, đó không phải là một tính năng phụ. Một camera phát hiện lỗi trên dây chuyền sản xuất là bài toán thị giác mà mô hình anh em lớn hơn đã xử lý; còn một thiết bị định tuyến yêu cầu bằng giọng nói, phân loại một phát ngôn, hoặc quyết định liệu người gọi có đang yêu cầu hoàn tiền hay không là bài toán chỉ mô hình này mới có thể đảm nhiệm.

Hai ràng buộc nằm đè lên trên năng lực đó và cả hai đều đã được ghi lại thành tài liệu, nghĩa là không có lý do gì để vấp phải chúng trong môi trường production. Thứ nhất, một yêu cầu chỉ mang hình ảnh hoặc âm thanh, không bao giờ cả hai — truyền cả hai sẽ làm phát sinh ValueError thay vì âm thầm bỏ đi một cái, nên lỗi sẽ hiện ra rõ ràng và rẻ công tìm trong khâu kiểm thử. Thứ hai, nhánh âm thanh được huấn luyện trên các đoạn trao đổi giữa một người nói tiếng Anh và một trợ lý, với các clip bị cắt ở mốc 30 giây. Đó là một dạng hình học người nói, một cấu trúc lượt thoại, và một phân bố giọng điệu. Đem nó áp vào các bản ghi âm tổng đài hay âm thanh thực địa là đang đòi hỏi những hành vi mà tấm thẻ không hề tuyên bố, và đó đúng là kiểu khoảng trống mà một bộ đánh giá sẽ phơi ra nếu có một bộ như vậy.

Không có cái nào tồn tại. Bài đăng phát hành gọi các benchmark chuyên biệt cho việc ra quyết định về âm thanh là "hiện vẫn là một vấn đề mở" và mời cộng đồng xây dựng một bộ như vậy, đó là một điều thẳng thắn để một phòng thí nghiệm viết ra và cũng là một hạn chế thực sự đối với bất kỳ ai đang đánh giá mô hình. Liquid AI d1-omni-600M đang bị yêu cầu chứng minh giá trị của mình dựa trên sức mạnh của một năng lực mà chưa ai có thể đo lường được. Nhà cung cấp cũng đã giữ kín hoàn toàn các số liệu suy luận, với lý do được nêu rõ rằng mô hình là một bản phát hành nghiên cứu sớm đang được phát triển tích cực. Vì vậy, không hề có con số độ trễ nào cho 600M cả — không cho văn bản, không cho thị giác, và không cho nhánh âm thanh vốn là toàn bộ mục đích.

Điều có thể nói mà không cần bịa ra bất cứ thứ gì là phép tính trên số tham số đã công bố: ở độ chính xác float16 mà thẻ mô hình khuyến nghị cho GPU, 587M tham số vào khoảng 1,2 GB trọng số trước khi tính activations, so với khoảng 6,2 GB đối với mô hình anh em 3,12B ở cùng độ chính xác. Thẻ mô hình cũng mang một cảnh báo về độ chính xác rất dễ bị đọc lướt qua và không nên đọc lướt: mô hình được huấn luyện ở float32, float16 được khuyến nghị trên GPU, và bfloat16 đã thay đổi câu trả lời đứng đầu ở một số hàng trong quá trình kiểm thử. Nếu stack phục vụ của bạn mặc định dùng bfloat16, thì đây là mô hình mà mặc định đó không an toàn.

Vì sao nửa nhỏ hơn của gia đình lại dễ bị bỏ sót

Lý do khiến một người đọc đi đến chỗ 3B rồi dừng lại mang tính cấu trúc chứ không phải ngẫu nhiên. Chỉ mục tài liệu của Liquid AI liệt kê ba hàng trong mục mô hình quyết định và chúng không đọc giống nhau: d1-3B và d1-omni-600M mang các liên kết Hugging Face và GGUF với chữ "No" trong cột có thể huấn luyện, trong khi d1 nằm ở hàng riêng của nó với đúng hai chữ "API" ở nơi lẽ ra là các liên kết tải xuống của mọi mô hình khác. Bài đăng phát hành gọi d1 là tên của một họ mô hình và không bao giờ phân biệt endpoint được phục vụ với checkpoint mở. Các thư viện runtime cục bộ sau đó chọn lấy 3B, bởi vì đó là mô hình có kích thước và số lượng modality khớp với mục mà chúng muốn công bố, còn 600M thì hoàn toàn không xuất hiện trong cùng danh sách đó.

Kết quả là một họ mô hình mà câu chuyện truy cập được công bố của nó, nếu đọc lướt qua, trông giống như một mô hình và một hàng API. Điều thực sự được cung cấp là hai checkpoint mở với các trunk khác nhau, các phương thức khác nhau và khoảng cách 32 điểm giữa điểm số của chúng trên chỉ số của chính nhà cung cấp, cộng thêm một endpoint được host mà nhà cung cấp chưa bao giờ xác nhận mối quan hệ của nó với bất kỳ checkpoint nào trong hai checkpoint đó. Bản 600M không hề bị giấu sau bất cứ thứ gì. Nó đơn giản là không có cái tên nào mà một tìm kiếm cho d1 sẽ làm hiện ra, và nó là cái duy nhất trong hai cái có thể nghe.

Những điểm số hiện có, và cột duy nhất đáng đọc

Trên Decision Index 0.2.1, nhà cung cấp báo cáo 15.95 cho Liquid AI d1-omni-600Mso với 48.57 cho mô hình anh em lớn hơn của nó — khoảng cách đủ lớn đến mức tổng số gần như vô dụng làm cơ sở để lựa chọn. Các điểm số thành phần cung cấp nhiều thông tin hơn tổng số, và một trong số đó thực sự đáng ngạc nhiên.

• Kiến thức — 8.3 so với 23.8

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

• Truy xuất — 35.0 so với 52.8

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

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

Retrieval là nơi mô hình nhỏ trụ vững, khi chỉ mất dưới một phần ba điểm số của mô hình lớn hơn, trong khi ở bốn cột còn lại, nó mất từ 60 đến 80 phần trăm. Kiểu kết quả đó khớp với điều mà một encoder đã qua huấn luyện đáng lẽ phải giỏi: đối chiếu một trạng thái với nội dung gần với mục đích mà phần thân được tạo ra để làm, và nó ít phụ thuộc hơn nhiều vào năng lực ngôn ngữ phân tầng mà mô hình anh em có dạng decoder thừa hưởng từ lượng tiền huấn luyện nhiều hơn hẳn. Cột Công cụ là câu chuyện ngược lại, và khoảng cách 59 điểm ở đó là con số đáng để bạn nhìn chằm chằm nếu khối lượng công việc của bạn là định tuyến một yêu cầu đến đúng hàm.

Trên bảy benchmark văn bản công khai, bức tranh dịu đi. Nhà cung cấp báo cáo mức trung bình 78,4 cho 600M so với 82,9 cho 3B, trong đó mô hình nhỏ 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 giải của chính Liquid là 600M đánh bại mức trung bình 77,1 của một mô hình quyết định 2B dù chỉ với một phần tư số tham số. Hai bộ benchmark đưa ra hai phán quyết bề ngoài khác nhau, cả hai đều do tự báo cáo, và cách hiểu trung thực là không bộ nào giải quyết được điều gì về audio path, vì audio path không nằm trong bộ nào.

Nơi cả hai thực sự gặp nhau

Bất chấp mọi khác biệt, mô hình lập trình là giống hệt nhau, và đó chính là điều khiến chúng có thể hoán đổi cho nhau theo một nghĩa cụ thể. Cả hai đều trả lời các câu hỏi noul, lựa chọn và điểm số trên một trạng thái, cả hai đều trả về câu trả lời được chọn cùng với bản đồ xác suất và giá trị độ tin cậy nằm trong khoảng từ 0 đến 1, và cả hai đều báo cáo output_tokens: 0. Trường độ tin cậy là trường mà mọi người hiểu sai: nó đo mức độ mà các xác suất nghiêng về một câu trả lời mạnh đến đâu, chứ không phải khả năng câu trả lời đó đúng. Một 0.96 cho một câu hỏi được đặt vấn đề tồi là một câu trả lời sai đầy tự tin, và trường này sẽ không cảnh báo bạn.

Điểm gặp nhau trên thực tế của chúng là một cơ chế cascade. Sàng lọc bằng Liquid AI d1-omni-600M — một cách rẻ, cục bộ, và bao gồm cả các trường hợp âm thanh mà bộ chấm điểm chỉ dùng văn bản không thể chạm tới — sau đó đẩy các mục mà nó xếp gần giữa thang điểm của mình lên checkpoint lớn hơn để có phán quyết sắc bén hơn. Các quy tắc leo thang chính 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, và trên một khối lượng công việc với đa số lớn là các mục dễ, phần lớn lưu lượng không bao giờ tới tầng thứ hai. Sự kết hợp đó hoạt động được vì cả hai mô hình đều trả về cùng một loại đối tượng. Hai mô hình tùy ý sẽ không như vậy.

Nếu chuỗi xếp tầng đó có lúc đóng vai trò cổng cho một lệnh gọi tới mô hình sinh mà bạn thuê thay vì tự vận hành, thì lớp bên dưới chính là nơi phần kết nối trở nên thú vị, và cũng là nơi chúng tôi góp mặt. Định tuyến một quyết định qua một chuỗi mô hình đúng là dạng bài toán mà một quy tắc định tuyến được tạo ra để xử lý: OrcaRouter kết hợp nhiều mô hình phía sau một endpoint tương thích OpenAI, mỗi mô hình ở mức giá niêm yết của nhà cung cấp được chuyển nguyên với 0% markup, với khả năng tự động chuyển đổi dự phòng giữa các nhà cung cấp để một bước leo thang thất bại ở lớp nhà cung cấp sẽ thử lại trên một phương án dự phòng thay vì làm yêu cầu thất bại. Chúng tôi không lưu trữ bất kỳ mô hình Liquid AI nào — chúng tôi đã kiểm tra trước khi viết điều này — nên không có gì ở trên là tuyên bố về việc gọi các trọng số này thông qua chúng tôi. Vấn đề là mô hình ra quyết định là phần rẻ của pipeline, còn mô hình vay mượn ở phía bên kia mới là phần bị sập.

Tệp đến từ đâu, nếu bạn muốn chạy nó ngay hôm nay

Đối với triển khai cục bộ, kho GGUF của chính nhà cung cấp dành cho 600M cung cấp Q8_0 ở 407 MB cùng F16 và BF16 ở 764 MB mỗi loại, mà không liệt kê bản dựng 4-bit nào — vì vậy bản tải chính thức nhỏ nhất nhỏ hơn khoảng bảy lần so với bản dựng tương ứng của mô hình lớn hơn và có kích thước xấp xỉ một bức ảnh độ phân giải trung bình. Ví dụ của chính thẻ mô hình này khởi động một máy chủ llama.cpp với cờ batch là 4096 và gợi ý nâng chúng lên 16384 cho các trạng thái dài hơn, sau đó truy vấn cùng endpoint /v1/systemone mà mô hình anh em lớn hơn sử dụng.

Điều duy nhất mà hướng cục bộ không mang lại cho bạn là các con số của nhánh âm thanh, bởi vì chúng không tồn tại. Nếu bạn định cho chạy giọng nói qua thứ này trước mặt người dùng thật, thì phần đánh giá là do bạn tự xây dựng: một tập clip đã được gán nhãn, đúng ba loại câu hỏi đó, và tỷ lệ trả lời được đo lường theo từng lớp. Đó không phải là sự phủ nhận mô hình — một checkpoint 587M đưa ra quyết định trên một clip giọng nói chỉ trong một lượt là một công cụ thực sự khác biệt so với một bộ phân loại văn bản được gắn thêm vào một bước phiên âm, và nó xứng đáng có một bài kiểm tra thực sự thay vì một bài kiểm tra dựa trên cảm tính.

Nếu chuỗi xử lý đó có lúc nào chặn một lời gọi tới mô hình tạo sinh mà bạn thuê thay vì tự vận hành, OrcaRouter kết hợp nhiều mô hình phía sau một điểm cuối tương thích OpenAI , mỗi mô hình ở mức giá niêm yết của nhà cung cấp và được chuyển tiếp nguyên vẹn với mức chênh lệch 0%.

Việc chọn một checkpoint omni thay vì loại chỉ văn bản cũng là thời điểm tốt để xem xét những gì đã sai trong lớp này: các sự cố AI và lỗi agent đã được ghi nhận liên quan đến các mô hình đa phương thức nhỏ được thu thập trong OrcaRouter AI Incident Archive, trong đó mỗi mục đều có nguồn, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp riêng.