Liquid AI d1 vs Liquid AI d1-omni-600M: โมเดลการตัดสินใจแบบเปิดที่ฟังคุณได้

ค้นหาชื่อ Liquid AI d1 แล้วคุณจะเจอโมเดลขนาดสามพันล้านพารามิเตอร์ที่อ่านได้ทั้งข้อความและรูปภาพ เช็กพอยต์โอเพนซอร์สอีกตัวในตระกูลเดียวกันมีขนาดเล็กกว่าถึงห้าเท่า พิจารณาเสียงพูดได้นานสูงสุดสามสิบวินาที และเป็นเพียงหนึ่งในสองตัวนี้ที่ตัดสินใจอะไรเกี่ยวกับเสียงได้ มันมีชื่อว่า Liquid AI d1-omni-600M และถ้าคุณรู้จักตระกูลนี้ผ่านไลบรารีรันไทม์ในเครื่องมากกว่าผ่านเอกสารของผู้ผลิตเอง มีโอกาสไม่น้อยที่คุณจะไม่เคยเห็นชื่อของมันเลย นั่นคือสถานการณ์ที่การเปรียบเทียบนี้ถูกเขียนขึ้นมาเพื่อแก้ เพราะสองโมเดลนี้ไม่ใช่คำตอบที่แข่งกันตอบคำถามเดียวกัน แต่เป็นคำตอบของคำถามที่ต่างกันสองข้อ และมีเพียงข้อเดียวเท่านั้นที่เกี่ยวข้องกับการฟัง

ตัวเลขทุกตัวด้านล่างมาจากเนื้อหาของ Liquid AI เอง: การ์ดโมเดล LiquidAI/d1-omni-600M, รีโพซิทอรีคู่กันอย่าง d1-omni-600M-GGUF และโพสต์เปิดตัวเมื่อวันที่ 7 ตุลาคมที่ประกาศเช็กพอยต์แบบเปิดทั้งสองพร้อมกัน แถวผลประสิทธิภาพถูกให้คะแนนโดยผู้จำหน่ายบนดัชนีที่ตนดูแลเอง แทนที่จะส่งเข้าจัดอันดับสาธารณะ และโพสต์ดังกล่าวระบุตรง ๆ ว่าเกณฑ์มาตรฐานสำหรับการตัดสินใจด้านเสียงโดยเฉพาะยังเป็นปัญหาที่เปิดอยู่ ไม่มีสิ่งใดที่นี่ถูกทำซ้ำโดยผู้ใดจากภายนอกห้องแล็บ

587 ล้านพารามิเตอร์ประกอบด้วยอะไร

ตัวเลขบนพาดหัวซ่อนการแบ่งที่ไม่ธรรมดาไว้ พารามิเตอร์ทั้งหมดรวมเป็น 587M และไม่ใช่สแต็กเดียว: แกนร่วมขนาด 381M ที่มีเฮดตัดสินใจต่ออยู่ ตัวเข้ารหัสภาพขนาด 94M และตัวเข้ารหัสเสียงขนาด 112M ทุกโมดัลลิตีทำงานผ่านน้ำหนักแกนเดียวกัน ซึ่งเป็นการตัดสินใจเชิงออกแบบที่ทำให้ทั้งหมดมีขนาดเล็ก — โมเดลนี้ไม่ใช่โมเดลสามตัวที่สวมเสื้อโค้ทคลุมรวมกัน แต่เป็นแกนตัดสินใจหนึ่งเดียวที่มีสองวิธีป้อนข้อมูลให้มัน

ส่วนประกอบต่างๆ มาจากตำแหน่งที่แตกต่างกันในแค็ตตาล็อกของ Liquid แกนหลักสืบทอดมาจาก LFM2.5-Encoder-350M ซึ่งเป็นเอนโคเดอร์แบบสองทิศทาง แทนที่จะมาจากสายแบบ decoder-only ที่รุ่นพี่ที่ใหญ่กว่ามาจาก ส่วน vision tower คือ SigLIP2 ที่ยกมาจาก LFM2.5-VL-450M พร้อมอะแดปเตอร์และการอัปเดต LoRA ที่นำไปใช้กับแบ็กโบน เส้นทางเสียงเป็นเอนโคเดอร์ FastConformer 17 ชั้นที่มีอะแดปเตอร์ของตัวเอง ซึ่งถูกไฟน์จูนกับแบ็กโบนข้อความที่ถูกตรึงไว้ การ์ดระบุบริบทขนาด 16,384 โทเคนที่ใช้ร่วมกันทั้งตำแหน่งข้อความ รูปภาพ และเสียง โดยข้อความถูกตัดให้เหลือ 896 โทเคนเมื่อมีรูปภาพอยู่ และมีคลังคำศัพท์ 65,536 โทเคน — ครึ่งหนึ่งของ 128,000 ของรุ่นพี่ที่ใหญ่กว่า ตัวเลขสุดท้ายนี้น่าสังเกตหากคุณทำงานในภาษาที่ตระกูลนี้รองรับเพียงบางส่วน

ความเป็นแบบสองทิศทางเทียบกับแบบ decoder-only คือเหตุผลที่ทั้งสองโมเดลให้ความรู้สึกแตกต่างกันสำหรับใครก็ตามที่เคยรันทั้งคู่ แกนหลักรูปเอนโคเดอร์อ่านสถานะทั้งหมดในคราวเดียวทั้งสองทิศทางก่อนจะสร้างสิ่งใดออกมา ส่วนแบบรูปดีโคเดอร์อ่านไปข้างหน้าเหมือนที่โมเดลภาษาทำ ทั้งคู่ได้รับการฝึกให้รายงานคำตอบจากการแจกแจงโดยมีโทเคนเอาต์พุตเป็นศูนย์ ดังนั้นจึงไม่มีตัวใดเขียนข้อความ — แต่กลไกที่อยู่เบื้องหลังเป็นโมเดลอีกประเภทหนึ่ง และช่องว่างความแม่นยำที่กล่าวถึงด้านล่างคือต้นทุนที่มองเห็นได้ของดีไซน์รูปเอนโคเดอร์ที่เล็กกว่า

คำพูดสามสิบวินาที และไม่มีอะไรให้ใช้ให้คะแนนเลย

เสียงคือเหตุผลที่เช็คพอยต์นี้มีอยู่ มันรับคลิปเดียวความยาวไม่เกิน 30 วินาที, 16 kHz โมโน, ใน forward pass เดียวกันที่สร้างคำตอบ, และเป็นสมาชิก open-weight เพียงตัวเดียวในตระกูลที่ทำเช่นนั้นได้ สำหรับงานบนอุปกรณ์ นี่ไม่ใช่ฟีเจอร์เล็กน้อย กล้องที่แจ้งข้อบกพร่องบนสายการผลิตเป็นปัญหาด้านวิชันที่พี่ใหญ่จัดการอยู่แล้ว; อุปกรณ์ที่จัดเส้นทางคำขอด้วยเสียง จำแนกคำพูด หรือตัดสินว่าผู้โทรกำลังขอเงินคืนหรือไม่ เป็นปัญหาที่มีเพียงตัวนี้เท่านั้นที่สามารถชี้ไปที่ได้

มีข้อจำกัดสองประการวางอยู่บนความสามารถนั้น และทั้งสองข้อมีเอกสารกำกับ ซึ่งหมายความว่าไม่มีข้อแก้ตัวใด ๆ ที่จะสะดุดกับสิ่งเหล่านี้ในโปรดักชัน ประการแรก คำขอหนึ่งรายการมีภาพ หรือเสียง ไม่ใช่ทั้งสองอย่าง — การส่งทั้งสองอย่างจะทำให้เกิด ValueError แทนที่จะทิ้งอย่างใดอย่างหนึ่งไปอย่างเงียบ ๆ ดังนั้นความล้มเหลวจึงชัดเจนและหาสาเหตุได้ง่ายในการทดสอบ ประการที่สอง เส้นทางเสียงได้รับการฝึกบนการสนทนาแลกเปลี่ยนระหว่างผู้พูดภาษาอังกฤษกับผู้ช่วย โดยตัดคลิปไว้ที่ 30 วินาที นั่นคือลักษณะผู้พูดแบบเดียว โครงสร้างการผลัดกันพูดแบบเดียว และการกระจายสำเนียงแบบเดียว การนำไปใช้กับบันทึกเสียงคอลเซ็นเตอร์หรือเสียงภาคสนามคือการเรียกร้องพฤติกรรมที่การ์ดไม่ได้อ้างไว้ และนี่คือช่องว่างแบบเดียวกับที่เบนช์มาร์กจะเผยให้เห็นหากมีสิ่งนั้นอยู่

ยังไม่มีสิ่งใดเช่นนี้อยู่ โพสต์เปิดตัวเรียกแบบทดสอบวัดประสิทธิภาพการตัดสินใจด้านเสียงโดยเฉพาะว่าเป็น "ปัญหาที่ยังเปิดอยู่" และเชิญชวนให้ชุมชนสร้างมันขึ้นมา ซึ่งเป็นสิ่งที่ตรงไปตรงมาที่ห้องแล็บแห่งหนึ่งจะเขียน และเป็นข้อจำกัดจริงสำหรับใครก็ตามที่ประเมินโมเดลนี้ Liquid AI d1-omni-600M กำลังถูกเรียกให้แสดงความชอบธรรมของตนเองด้วยจุดแข็งของความสามารถที่ยังไม่มีใครวัดได้ ตอนนี้ผู้ขายยังไม่เปิดเผยตัวเลขการประมวลผลเลยด้วยซ้ำ โดยให้เหตุผลว่าโมเดลนี้เป็นการเปิดตัวเพื่อการวิจัยระยะเริ่มต้นที่ยังอยู่ระหว่างการพัฒนาอย่างต่อเนื่อง ดังนั้นจึงไม่มีตัวเลขความหน่วงสำหรับรุ่น 600M เลย ไม่ว่าจะเป็นข้อความ ภาพ หรือเส้นทางเสียงซึ่งเป็นประเด็นสำคัญทั้งหมด

สิ่งที่พูดได้โดยไม่ต้องแต่งเติมอะไรขึ้นมาคือการคำนวณทางคณิตศาสตร์จากจำนวนพารามิเตอร์ที่ประกาศไว้: ที่ความแม่นยำ float16 ซึ่งการ์ดแนะนำสำหรับ GPU พารามิเตอร์ 587M อยู่ในระดับประมาณ 1.2 GB ของน้ำหนักก่อนแอ็กติเวชัน เทียบกับประมาณ 6.2 GB สำหรับรุ่นพี่น้อง 3.12B ที่ความแม่นยำเดียวกัน การ์ดยังมีคำเตือนเรื่องความแม่นยำที่มองข้ามได้ง่ายและไม่ควรมองข้าม: โมเดลนี้ฝึกด้วย float32, แนะนำให้ใช้ float16 บน GPU, และ bfloat16 เปลี่ยนคำตอบอันดับต้นในบางแถวระหว่างการทดสอบ หากสแตกการให้บริการของคุณตั้งค่าเริ่มต้นเป็น bfloat16 นี่คือโมเดลที่ค่าดีฟอลต์นั้นไม่ปลอดภัย

ทำไมครึ่งที่เล็กกว่าของครอบครัวจึงถูกมองข้ามได้ง่าย

เหตุผลที่ผู้อ่านมาถึง 3B แล้วหยุดนั้นเป็นเชิงโครงสร้างมากกว่าเป็นเรื่องบังเอิญ ดัชนีเอกสารของ Liquid AI แสดงสามแถวภายใต้โมเดลการตัดสินใจ และพวกมันอ่านไม่เหมือนกัน: d1-3B และ d1-omni-600M มีลิงก์ Hugging Face และ GGUF โดยมีคำว่า "No" ในคอลัมน์ trainable ในขณะที่ d1 อยู่ในแถวของตัวเองโดยมีตัวอักษร "API" เปล่าๆ ในตำแหน่งที่ลิงก์ดาวน์โหลดของโมเดลอื่นๆ ควรจะอยู่ โพสต์เปิดตัวเรียก d1 ว่าเป็นชื่อตระกูล และไม่เคยแยกความแตกต่างระหว่าง endpoint ที่ให้บริการกับ checkpoint ที่เปิดเผย ไลบรารีรันไทม์ในเครื่องจึงเลือก 3B เพราะเป็นตัวที่มีขนาดและจำนวน modality ตรงกับรายการที่พวกเขาต้องการเผยแพร่ และ 600M ไม่ปรากฏในรายการเดียวกันเลย

ผลลัพธ์คือตระกูลหนึ่งซึ่งเรื่องราวการเข้าถึงที่เผยแพร่ เมื่ออ่านอย่างเร็ว ๆ ดูเหมือนโมเดลหนึ่งตัวและแถว API แถวเดียว สิ่งที่มีให้จริงคือเช็กพอยต์แบบเปิดสองตัวที่มีทรังก์ต่างกัน มอดาลิตีต่างกัน และช่องว่าง 32 จุดระหว่างคะแนนของทั้งสองบนดัชนีของผู้ขายเอง บวกกับเอนด์พอยต์แบบโฮสต์ที่ผู้ขายไม่เคยยืนยันความสัมพันธ์กับเช็กพอยต์ตัวใดเลย 600M ไม่ได้ถูกซ่อนอยู่หลังสิ่งใด มันเพียงไม่มีชื่อที่การค้นหา d1จะทำให้ปรากฏ และมันเป็นตัวเดียวในสองตัวที่ได้ยิน

สกอร์ที่มีอยู่ กับคอลัมน์เดียวที่คุ้มอ่าน

บน Decision Index 0.2.1 ผู้ขายรายงานค่า 15.95 สำหรับ Liquid AI d1-omni-600M เทียบกับ 48.57 สำหรับรุ่นพี่ที่ใหญ่กว่า — ช่องว่างกว้างพอที่ผลรวมจะแทบไร้ประโยชน์ในการใช้เป็นเกณฑ์เลือก คะแนนย่อยให้ข้อมูลมากกว่าผลรวม และหนึ่งในนั้นน่าประหลาดใจจริง ๆ

• ความรู้ — 8.3 เทียบกับ 23.8

• ภาษา — 12.9 เทียบกับ 56.4

• การดึงข้อมูล — 35.0 เทียบกับ 52.8

• เครื่องมือ — 15.1 เทียบกับ 74.5

• ศิลปะ — 6.8 เทียบกับ 36.3

Retrieval คือจุดที่โมเดลขนาดเล็กยังยืนหยัดได้ โดยสูญเสียคะแนนไปไม่ถึงหนึ่งในสามของคะแนนที่โมเดลใหญ่ทำได้ ขณะที่อีกสี่คอลัมน์มันสูญเสียไป 60 ถึง 80 เปอร์เซ็นต์ รูปแบบนี้สอดคล้องกับสิ่งที่เอนโคเดอร์ที่ผ่านการฝึกควรทำได้ดี: การจับคู่สถานะกับเนื้อหาใกล้เคียงกับสิ่งที่ trunk ถูกสร้างมาเพื่อทำ และมันพึ่งพาความสามารถทางภาษาแบบเป็นชั้น ๆ ที่โมเดลพี่น้องรูปทรงดีโคเดอร์สืบทอดมาจากการพรีเทรนที่มากกว่ามากนั้นน้อยกว่าอย่างชัดเจน คอลัมน์ Tools เป็นเรื่องตรงกันข้าม และช่องว่าง 59 จุดตรงนั้นคือตัวเลขที่ต้องจ้องไว้ หากภาระงานของคุณคือการกำหนดเส้นทางคำขอไปยังฟังก์ชันที่ถูกต้อง

บนเกณฑ์มาตรฐานข้อความสาธารณะเจ็ดชุด ภาพรวมเริ่มคลุมเครือน้อยลง ผู้ขายรายงานค่าเฉลี่ย 78.4 สำหรับรุ่น 600M เทียบกับ 82.9 สำหรับรุ่น 3B โดยโมเดลขนาดเล็กแพ้อย่างหวุดหวิดบน SQuAD 2.0 (74.0 เทียบกับ 85.3), PubMedQA (61.3 เทียบกับ 66.0), BoolQ (77.7 เทียบกับ 86.7) และ XNLI (74.7 เทียบกับ 85.0) ขณะที่ชนะบนการตรวจจับความเป็นพิษของ Civil Comments (95.8 เทียบกับ 93.0) และการระบุถอดความของ PAWS-X (79.5 เทียบกับ 76.9) กรอบที่ Liquid เองใช้นำเสนอคือ 600M เอาชนะค่าเฉลี่ย 77.1 ของโมเดลตัดสินใจขนาด 2B ได้ด้วยพารามิเตอร์เพียงหนึ่งในสี่ ชุดเกณฑ์มาตรฐานสองชุดให้คำตัดสินที่ดูแตกต่างกันสองแบบ โดยทั้งคู่เป็นผลที่รายงานเอง และการตีความอย่างซื่อตรงคือไม่มีชุดใดสรุปอะไรเกี่ยวกับเส้นทางเสียงได้ เพราะเส้นทางเสียงไม่ได้อยู่ในชุดใดเลย

จุดที่ทั้งสองมาบรรจบกันจริง ๆ

แม้จะมีความแตกต่างกันมากเพียงใด โมเดลการเขียนโปรแกรมก็เหมือนกัน และนั่นคือสิ่งที่ทำให้มันใช้แทนกันได้ในความหมายหนึ่งที่เฉพาะเจาะจง ทั้งคู่ตอบคำถามแบบ noul, choice และ score บนสถานะ ทั้งคู่คืนคำตอบที่เลือกพร้อมแผนที่ความน่าจะเป็นและค่าความมั่นใจระหว่าง 0 กับ 1 และทั้งคู่รายงาน output_tokens: 0 ฟิลด์ confidence คือสิ่งที่ผู้คนอ่านผิด มันวัดว่าความน่าจะเป็นสนับสนุนคำตอบหนึ่ง ๆ แรงเพียงใด ไม่ใช่โอกาสที่คำตอบนั้นจะถูกต้อง ค่า 0.96 บนคำถามที่ตั้งไว้แย่ ๆ คือคำตอบผิดที่มั่นใจ และฟิลด์นี้จะไม่เตือนคุณ

จุดที่ทั้งสองมาบรรจบกันในทางปฏิบัติคือแคสเคด โดยเริ่มคัดกรองด้วย Liquid AI d1-omni-600M — อย่างประหยัด ในเครื่อง และรวมถึงกรณีเสียงที่เครื่องให้คะแนนแบบข้อความล้วนแตะต้องไม่ได้ — จากนั้นยกระดับรายการที่มันจัดไว้ใกล้กึ่งกลางสเกลของมันไปยังเช็กพอยต์ที่ใหญ่กว่าเพื่อการตัดสินใจที่คมชัดขึ้น กฎการยกระดับคือค่าความเชื่อมั่นและการกระจายตัวที่ 600M ส่งกลับอยู่แล้ว ตรรกะการจัดเส้นทางจึงไม่ต้องใช้โมเดลเพิ่มเติม และบนเวิร์กโหลดที่มีรายการง่ายเป็นเสียงข้างมากอย่างชัดเจน ทราฟฟิกส่วนใหญ่จะไม่ไปถึงขั้นที่สอง การประกอบกันเช่นนั้นได้ผลเพราะทั้งสองโมเดลส่งคืนออบเจ็กต์ชนิดเดียวกัน โมเดลสองตัวใด ๆ ที่เลือกมาก็ทำไม่ได้

หากแคสเคดนั้นเป็นตัวกั้นการเรียกไปยังโมเดลแบบเจนเนอเรทีฟที่คุณเช่าใช้แทนที่จะรันเอง ชั้นที่อยู่ข้างใต้คือจุดที่ระบบเชื่อมต่อน่าสนใจ และก็เป็นจุดที่เราเข้ามาเกี่ยวข้องด้วย การกำหนดเส้นทางให้การตัดสินใจหนึ่งครั้งผ่านเชนของโมเดลหลายตัวเป็นรูปแบบปัญหาที่กฎการกำหนดเส้นทางถูกสร้างขึ้นมาเพื่อจัดการพอดี: OrcaRouter ประกอบโมเดลหลายตัวไว้เบื้องหลังเอนด์พอยต์เดียวที่เข้ากันได้กับ OpenAI โดยแต่ละตัวคิดในราคาตามรายการของผู้ให้บริการที่ส่งผ่านโดยบวกกำไร 0%พร้อมกับ การสลับไปใช้ระบบสำรองอัตโนมัติข้ามผู้ให้บริการ ดังนั้นการเอสคาเลชันที่ล้มเหลวในชั้นผู้ให้บริการจะลองใหม่บนระบบสำรองแทนที่จะทำให้คำขอล้มเหลว เราไม่ได้โฮสต์โมเดล Liquid AI ใด ๆ — เราตรวจสอบก่อนเขียนข้อความนี้แล้ว — ดังนั้นไม่มีสิ่งใดข้างต้นเป็นการอ้างเกี่ยวกับการเรียกเวตเหล่านี้ผ่านเรา ประเด็นคือโมเดลที่ใช้ตัดสินใจเป็นส่วนที่ราคาถูกของไปป์ไลน์ และโมเดลที่ยืมมาใช้อีกฝั่งคือส่วนที่ล่ม

แหล่งที่มาของไฟล์ หากคุณต้องการรันมันในวันนี้

สำหรับการปรับใช้ภายในเครื่อง ที่เก็บ GGUF ของผู้จำหน่ายเองสำหรับรุ่น 600M มี Q8_0 ที่ 407 MB และ F16 กับ BF16 อย่างละ 764 MB โดยไม่มีการระบุบิลด์ 4-bit — ดังนั้นดาวน์โหลดอย่างเป็นทางการที่เล็กที่สุดจึงเล็กกว่าบิลด์ที่เทียบเท่าของโมเดลที่ใหญ่กว่าประมาณเจ็ดเท่า และมีขนาดใกล้เคียงกับภาพถ่ายความละเอียดปานกลาง ตัวอย่างใน model card เองเริ่มเซิร์ฟเวอร์ llama.cpp ด้วยแฟล็กแบตช์ที่ 4096 และแนะนำให้เพิ่มเป็น 16384 สำหรับสถานะที่ยาวขึ้น จากนั้นคิวรีไปยัง endpoint /v1/systemone เดียวกันกับที่รุ่นพี่ที่ใหญ่กว่าใช้

สิ่งที่เส้นทางในเครื่องไม่ได้ให้คุณคือตัวเลขของเส้นทางเสียง เพราะมันไม่มีอยู่ หากคุณตั้งใจจะรันเสียงพูดผ่านสิ่งนี้ต่อหน้าผู้ใช้จริง การประเมินเป็นหน้าที่ของคุณที่จะสร้างขึ้นมา: ชุดคลิปที่มีป้ายกำกับ ประเภทคำถามสามประเภทเดียวกัน และอัตราการตอบที่วัดได้ต่อคลาส นั่นไม่ใช่การปฏิเสธโมเดล — เช็คพอยต์ 587M ที่ตัดสินใจจากคลิปเสียงในรอบเดียวเป็นเครื่องมือที่แตกต่างอย่างแท้จริงจากตัวจำแนกข้อความที่ต่อกับขั้นตอนถอดเสียง และมันสมควรได้รับการทดสอบจริงมากกว่าการทดสอบที่อิงความรู้สึก

หากแคสเคดนั้นกลายเป็นตัวควบคุมการเรียกไปยังโมเดลแบบเจนเนอเรทีฟที่คุณเช่าใช้แทนที่จะรันเอง OrcaRouter จะรวมโมเดลหลายตัวไว้เบื้องหลังเอนด์พอยต์เดียวที่เข้ากันได้กับ OpenAI โดยแต่ละตัวใช้ราคาตามรายการของผู้ให้บริการ ส่งผ่านโดยบวกเพิ่ม 0%

การเลือกใช้เช็กพอยต์แบบ omni แทนแบบข้อความล้วนก็เป็นจังหวะที่ดีที่จะดูว่าอะไรที่เคยผิดพลาดไปแล้วในคลาสนี้: เหตุการณ์ AI และความล้มเหลวของเอเจนต์ที่เกี่ยวข้องกับโมเดลมัลติโมดัลขนาดเล็กซึ่งมีการบันทึกไว้ ถูกเก็บรวบรวมไว้ใน the OrcaRouter AI Incident Archive โดยแต่ละรายการมีแหล่งที่มา ระดับความรุนแรง เกรดความเชื่อมั่น และธงข้อโต้แย้งของตัวเอง