LFM3-Omni-2B กับ Ming-3.0-audio-tiny: การแทนที่สแต็กเมื่อเทียบกับผู้เชี่ยวชาญเฉพาะทาง

สองโมเดลที่ถูกวางตลาดว่าเป็นโมเดลขนาดเล็กทั้งคู่ ทั้งคู่สามารถตอบออกเสียงได้ และแทบไม่มีอะไรอื่นที่เหมือนกันเลย LFM3-Omni-2B เป็นเช็กพอยต์แบบเดนส์ขนาด 2.17 พันล้านพารามิเตอร์จาก Liquid AI ที่รับข้อความ รูปภาพ วิดีโอ และเสียง แล้วส่งคืนข้อความหรือเสียงพูด 24 kHz Ming-3.0-audio-tiny เป็นโมเดลแบบ mixture-of-experts ขนาด 9.3 พันล้านพารามิเตอร์จาก inclusionAI โดยมี 2.7 พันล้านพารามิเตอร์ที่ใช้งานในแต่ละสเต็ป และรับเสียงและข้อความแล้วส่งคืนข้อความหรือเสียงพูด 44.1 kHz ตัวหนึ่งกำลังพยายามแทนที่สแต็กผู้ช่วยทั้งหมด อีกตัวกำลังพยายามเป็นหูที่ดีที่สุดเท่าที่จะเป็นไปได้ โมเดลเฉพาะทางและโมเดลอเนกประสงค์สามารถอยู่เบื้องหลังคีย์เดียวได้ เอนด์พอยต์เดียว คำขอจะถูกจัดเส้นทางตามกฎ พร้อมการสลับไปใช้ระบบสำรองอัตโนมัติหากเส้นทางใดเส้นทางหนึ่งล้มเหลว

การตั้งชื่อทำให้เรื่องนี้ยากเกินความจำเป็น คำว่า "Tiny" ในตระกูล Ming หมายถึงตำแหน่งของมันเมื่อเทียบกับ Ming-3.0-audio-flash ไม่ใช่ขนาดสัมบูรณ์ของมัน เพราะที่ขนาดรวม 9.3B มันมีจำนวนพารามิเตอร์มากกว่าของโมเดล Liquid ถึงกว่าสี่เท่า และ LFM3-Omni-2B ไม่ใช่โมเดลเสียงที่เอาความสามารถด้านภาพมาติดเพิ่มทีหลัง — มันเป็นโมเดลมัลติโหมดทั่วไปที่มีเส้นทางเสียงอยู่ด้วย การเปรียบเทียบทีละแถวจะไม่ยุติธรรมกับทั้งคู่ การเปรียบเทียบตามงานที่พวกมันทำคือการเปรียบเทียบเดียวที่มีความหมาย

แต่ละอย่างจริงๆ แล้วคืออะไร

Ming-3.0-audio-tiny เป็นโมเดลภาษาเสียงแบบเนทีฟ ประกอบด้วยตัวเข้ารหัสเสียงและโปรเจกเตอร์ที่ป้อนเข้าสู่แกนภาษาศาสตร์ MoE แบบ sparse พร้อมขั้นตอน Talker แยกต่างหากที่สร้างเสียงพูดเมื่อคุณร้องขอ รองรับภาษาจีนและอังกฤษ รวมถึงสำเนียงและภาษาถิ่น และรองรับการโคลนเสียงจากคลิปอ้างอิงพร้อมถอดความ weights ได้รับอนุญาตแบบ MIT และมีให้ใช้งานบน Hugging Face และ ModelScope มีการควอนไทซ์จากชุมชนสำหรับ MLX และ GGUF และมีเดโม ROCm ที่ใช้งานได้จริงของผู้ช่วยเสียงแบบ latency ต่ำที่สร้างขึ้นบนโมเดลนี้ รีโปซิทอรีถูกอัปโหลดในช่วงต้นเดือนกันยายน 2026 และ model card กับ config ได้รับการรีเฟรชในช่วงกลางเดือนตุลาคม ซึ่งเป็นช่วงที่โมเดลเริ่มใช้งานได้จริง

LFM3-Omni-2B เป็นการออกแบบในทางตรงกันข้าม โดยมีโครงหลักแบบ dense เพียงโครงเดียวพร้อมตัวเข้ารหัสภาพ ตัวเข้ารหัสเสียงแบบ causal และ LiquidCodec สำหรับเอาต์พุตเสียง ถูกฝึกมาเพื่อให้ชุดน้ำหนักหนึ่งชุดรองรับอินพุตสี่รูปแบบและเอาต์พุตสองรูปแบบ เผยแพร่เมื่อวันที่ 27 ตุลาคม 2026 โดยเป็นหนึ่งในสาขาของตระกูล LFM3 หกโมเดลของ Liquid โดยไม่มีการประกาศแยกและไม่มีการประเมินผลอย่างอิสระ การ์ดโมเดลระบุว่ามีพารามิเตอร์ 2.17B บริบท 32,768 โทเคน และใช้ LFM Open License v1.0

• สถาปัตยกรรม — แบบ dense any-to-any ขนาด 2.17B เทียบกับ sparse MoE รวม 9.3B โดยมีพารามิเตอร์ที่เปิดใช้งาน 2.7B ต่อโทเค็น พร้อม Talker สำหรับเสียงพูดแยกต่างหาก

• อินพุต — ข้อความ, รูปภาพ, วิดีโอพร้อมแทร็กเสียง, เสียง 16 kHz เทียบกับเสียงและข้อความเท่านั้น

• เอาต์พุตเสียงพูด — 24 kHz ผ่าน LiquidCodec สตรีมเร็วกว่าเวลาจริง เทียบกับ 44.1 kHz โมโนผ่าน Talker พร้อมเสียงพรีเซ็ตที่มีชื่อและการโคลนเสียง

• ภาษา — ภาษาข้อความ 16 ภาษาและโลแคลเสียงพูด 19 โลแคล เมื่อเทียบกับภาษาจีนและภาษาอังกฤษ รวมถึงภาษาถิ่น

• บริบท — 32,768 โทเค็น ระบุไว้บนการ์ด เทียบกับไม่มีการระบุหน้าต่างบริบทบนการ์ด; คอนฟิกที่เผยแพร่ระบุงบตำแหน่ง 131,072 โทเค็น

• สัญญาอนุญาต — LFM Open License v1.0 โดยมีเกณฑ์รายได้เมื่อเทียบกับ MIT

• ขนาดหน่วยความจำที่ใช้ — ประมาณ 4.3 GB ใน BF16 เทียบกับประมาณ 21 GB ใน BF16 โดยการควอนไทซ์ expert แบบ int8 ทำให้เหลือประมาณ 12.5 GB

สองแถวที่ทับซ้อนกันอย่างแท้จริง

ตาราง benchmark ข้ามแล็บส่วนใหญ่เป็นแค่ฉากละคร เพราะแต่ละแล็บเลือกฮาร์เนสของตัวเอง ตรงนี้ส่วนที่ทับซ้อนกันมีน้อยพอที่จะระบุได้อย่างชัดเจน: มีชุดข้อมูลสองชุดที่ปรากฏในรายงานของผู้ขายทั้งสองราย และทั้งคู่เป็นงานด้านเสียงที่ระเบียบวิธีค่อนข้างเป็นมาตรฐาน

• อัตราข้อผิดพลาดระดับคำของ ASR ภาษาอังกฤษ — 6.36 สำหรับ LFM3-Omni-2B เทียบกับ 4.36 สำหรับ Ming-3.0-audio-tiny ยิ่งต่ำยิ่งดี และ Ming นำอยู่สองจุดสัมบูรณ์ ซึ่งมีข้อผิดพลาดน้อยลงประมาณหนึ่งในสาม

• VoiceBench — 64.73 เทียบกับ 74.29 Ming นำอยู่ 9.6 คะแนนในด้านการปฏิบัติตามคำสั่งด้วยเสียงและพฤติกรรมของผู้ช่วยเสียง

ในงานที่ทั้งสองโมเดลวัดผล โมเดลเฉพาะทางเป็นฝ่ายชนะ และนั่นคือผลลัพธ์ที่คาดไว้ Ming ใช้พารามิเตอร์ที่ทำงานอยู่ 2.7 พันล้านตัวไปกับการฟังและการพูด LFM3-Omni-2B ใช้ 2.17 พันล้านตัวไปกับการฟัง การพูด การมองเห็น และการอ่านพร้อมกันในคราวเดียว โมเดลที่ไม่ได้แบ่งความจุออกเป็นสี่ทางควรจะทำได้ดีกว่าในด้านเดียวที่มันทำงาน และมันก็เป็นเช่นนั้น

สิ่งที่ Ming รายงานแต่ LFM3-Omni-2B ไม่ได้รายงานนั้นเป็นรายการที่ยาวกว่า: อัตราความผิดพลาดระดับอักขระของ ASR ภาษาจีน 3.79, อัตราความผิดพลาดระดับอักขระของภาษาถิ่น 10.29, BigBenchAudio 99.20, MMAU 75.90, MMAU-Pro 56.42, ความแม่นยำของเสียงยาว 56.39 และ BFCL-v3 Audio 79.80 ตัวเลขเหล่านี้แข็งแกร่งสำหรับโมเดลขนาดนี้ และบ่งบอกถึงระบบที่ได้รับการประเมินโดยเฉพาะด้านการให้เหตุผลจากเสียง แทนที่จะเป็นเพียงคอลัมน์หนึ่งในตารางมัลติโมดัล ค่าที่เทียบเคียงได้ใกล้ที่สุดในบัตรข้อมูลของ Liquid คือ MMAR ด้านความเข้าใจเสียง 51.40 และคะแนนการเรียกใช้เครื่องมือ 52.20 — แต่เกณฑ์มาตรฐานการเรียกใช้เครื่องมือไม่ใช่การทดสอบเดียวกับ BFCL-v3 Audio และการนำตัวเลขสองค่านี้มาเทียบเคียงกันจะเป็นรูปแบบการเปรียบเทียบที่บล็อกนี้มีอยู่เพื่อหลีกเลี่ยง

มาตรฐานที่แมตช์นี้ไม่อาจตัดสินได้

คำถามที่น่าสนใจไม่ใช่โมเดลไหนได้ยินดีกว่า แต่คือโมเดลออมนิเพียงตัวเดียวจะสามารถทำการให้เหตุผลเชิงเสียงและภาพที่ไพป์ไลน์ทำไม่ได้หรือไม่ Ming-3.0-audio-tiny ไม่มีเส้นทางภาพเลย: มันไม่สามารถดูเฟรมหนึ่งแล้วอธิบายว่าเกิดอะไรขึ้น และไม่สามารถตอบคำถามเกี่ยวกับแทร็กเสียงของวิดีโอขณะรับชมวิดีโอได้ LFM3-Omni-2B ทำได้ทั้งสองอย่าง และ Liquid รายงานว่า Daily-Omni 70.09 และ WorldSense 47.10 สำหรับความสามารถนั้นโดยเฉพาะ

ตัวเลขเหล่านั้นไม่มีสิ่งเทียบเคียงในการ์ดข้อมูลของ Ming เพราะ Ming ไม่ได้พยายามทำงานนี้ ดังนั้นการเปรียบเทียบจึงกลายเป็นคำถามเรื่องขอบเขตความสามารถมากกว่าคำถามเรื่องคุณภาพ: หากแอปพลิเคชันของคุณเป็นอินเทอร์เฟซเสียงสำหรับสตรีมเสียง Ming คือหูที่มีความสามารถมากกว่าและใช้กำลังประมวลผลขณะทำงานน้อยกว่า หากแอปพลิเคชันของคุณประกอบด้วยกล้อง ไมโครโฟน และลำโพง LFM3-Omni-2B กำลังทำสิ่งที่ Ming ทำไม่ได้ไม่ว่าจะมีขนาดใดก็ตาม และช่องว่างด้านเสียงคือภาษีที่คุณต้องจ่ายเพื่อแลกกับกล้อง

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

ค่าใช้จ่ายหน่วยความจำเป็นตัวตัดสินการดีพลอยได้มากกว่าผลเบนช์มาร์ก

Ming-3.0-audio-tiny ต้องใช้น้ำหนักโมเดลประมาณ 21 GB ใน BF16 หรือประมาณ 12.5 GB เมื่อใช้การควอนไทซ์แบบ int8 สำหรับ expert และการติดตั้งใช้งานที่ให้เอาต์พุตเสียงแบบเต็มรูปแบบสามารถแยก Thinker กับ Talker ไปยัง GPU สองตัวได้ LFM3-Omni-2B ต้องการประมาณ 4.3 GB นั่นไม่ใช่ความแตกต่างเล็กน้อย: มันคือความแตกต่างระหว่าง GPU ระดับกลางตัวเดียวกับเครื่องที่คุณต้องวางแผนรองรับ และเป็นความแตกต่างระหว่างโทรศัพท์กับเซิร์ฟเวอร์

การเปรียบเทียบจะกลับด้านกันไปขึ้นอยู่กับว่าคุณกำลังวัดอะไร พารามิเตอร์ที่ใช้งานจริง 2.7B ของ Ming ทำให้มีต้นทุนต่อโทเคนต่ำแม้ขนาดรวมจะใหญ่ ซึ่งนั่นคือจุดประสงค์ทั้งหมดของ MoE แบบสแปร์ส LFM3-Omni-2B เป็นแบบเดนส์ ดังนั้นทุกโทเคนจึงมีต้นทุนเต็ม 2.17B — แต่โมเดลทั้งหมดใช้หน่วยความจำเพียงเศษเสี้ยว และรันบนฮาร์ดแวร์ที่ Ming แตะต้องไม่ได้

นี่คือจุดที่เศรษฐศาสตร์ของการจัดเส้นทางกลายเป็นเรื่อง konkret ขึ้นมา OrcaRouter ส่งผ่านราคาตามรายการของผู้ให้บริการโดยไม่บวกกำไรดังนั้นผู้เชี่ยวชาญที่ถูกกว่าและผู้ให้บริการทั่วไปที่แพงกว่าจึงอยู่เบื้องหลังคีย์เดียวได้โดยไม่ต้องมีสัญญาที่สอง และการเปลี่ยนแปลงราคาของผู้ขายจะสะท้อนถึงบิลของคุณภายในวันเดียวกัน ไม่ใช่รอถึงรอบต่ออายุสัญญาครั้งถัดไป ทั้ง LFM3-Omni-2B และ Ming-3.0-audio-tiny ยังไม่มีอยู่ในแคตตาล็อกของเราในวันนี้ ดังนั้นนี่จึงเป็นข้อความเกี่ยวกับวิธีที่แพลตฟอร์มกำหนดราคา ไม่ใช่การอ้างว่าคุณสามารถเรียกใช้โมเดลใดโมเดลหนึ่งผ่านเราได้ในตอนนี้ แต่รูปแบบที่สองโมเดลนี้สร้างขึ้น — ผู้เชี่ยวชาญราคาถูกสำหรับกรณีทั่วไป และผู้ให้บริการทั่วไปสำหรับกรณีที่ยาก — คือรูปแบบที่เราเตอร์ถูกออกแบบมาเพื่อสิ่งนี้พอดี

คำถามเรื่องสัญญาอนุญาต ซึ่งเป็นทางแยกที่แท้จริง

Ming-3.0-audio-tiny ใช้สัญญาอนุญาต MIT ส่วน LFM3-Omni-2B อยู่ภายใต้ LFM Open License v1.0 ซึ่งเป็นข้อตกลงเฉพาะที่มีเกณฑ์รายได้ซึ่งกำหนดว่าการใช้งานเชิงพาณิชย์จำเป็นต้องมีข้อตกลงแยกต่างหากหรือไม่ สำหรับต้นแบบงานวิจัย ความแตกต่างนี้เป็นเรื่องทางวิชาการเท่านั้น แต่สำหรับผลิตภัณฑ์ สิ่งนี้คือสิ่งแรกที่ฝ่ายกฎหมายจะถามถึง และมันสามารถมีน้ำหนักเหนือช่องว่างด้านเบนช์มาร์กไม่ว่าจะมากเพียงใด

MIT ยังอธิบายด้วยว่าทำไม Ming จึงมีพอร์ตจากชุมชนแล้ว เช่น บิลด์ MLX การควอนไทซ์ GGUF และเดโมผู้ช่วยเสียง ROCm สิ่งเหล่านี้มีอยู่เพราะสัญญาอนุญาตทำให้ทำได้ง่าย และเป็นเหตุผลที่ทำให้ Ming สามารถนำไปติดตั้งใช้งานได้ในปัจจุบันบนฮาร์ดแวร์ที่ Liquid ไม่เคยทดสอบ LFM3-Omni-2B เผยแพร่เมื่อวันที่ 27 ตุลาคม โดยมีดาวน์โหลด 83 ครั้ง และมีเส้นทางการให้บริการที่จัดทำเอกสารไว้เพียงหนึ่งเส้นทางสำหรับเอาต์พุตข้อความเท่านั้น ระบบนิเวศของมันยังไม่มีอยู่เลย

ความไม่สมดุลในทางปฏิบัติชัดเจนมาก ในด้านความแม่นยำของเสียง ประสิทธิภาพหน่วยความจำต่อพารามิเตอร์ที่แอ็กทีฟ ความครอบคลุมภาษาจีนและภาษาถิ่น การโคลนเสียงและความอิสระด้านการอนุญาต Ming-3.0-audio-tiny เป็นตัวเลือกที่ปลอดภัยกว่าในปัจจุบัน ในแง่ความครอบคลุมของโมดัลลิตี้และขนาดโมเดลดิบ LFM3-Omni-2B เป็นเพียงตัวเดียวในสองตัวที่มองห้องแล้วพูดคุยเกี่ยวกับห้องนั้นได้

ใครควรไปรับอันไหน

เลือก Ming-3.0-audio-tiny หากคุณกำลังสร้างผลิตภัณฑ์ด้านเสียง — การถอดเสียง บทสนทนาแบบพูด การโคลนเสียง การวิเคราะห์สายโทร — และคุณไม่จำเป็นต้องใช้ความสามารถด้านภาพ หรือยินดีที่จะจับคู่กับโมเดลภาพแยกต่างหาก ใบอนุญาต MIT การควอนไทซ์ที่มีอยู่ และข้อได้เปรียบของ ASR แบบสองจุด ทำให้เป็นการนำไปใช้งานที่มีความเสี่ยงต่ำกว่า และสถาปัตยกรรมแบบสแปร์สของมันช่วยลดต้นทุนต่อโทเค็น แม้จะมีขนาดรวม 9.3B

เลือก LFM3-Omni-2B หากอุปกรณ์มีกล้องและไมโครโฟน และข้อจำกัดคือหน่วยความจำ checkpoint ขนาด 4.3 GB ที่มองเห็น ได้ยิน และพูดได้จัดอยู่ในประเภทของวัตถุที่แตกต่างจากผู้เชี่ยวชาญด้านเสียงขนาด 21 GB และความแม่นยำของ ASR ไม่ว่าจะมากเพียงใดก็ไม่อาจชดเชยโมเดลที่ไม่สามารถใส่ลงได้ ยอมรับว่าคุณกำลังซื้อความกว้าง ไม่ใช่ความลึก และตัวเลขด้านเสียงทุกตัวที่แนบมากับมันเป็นข้อมูลที่ผู้ขายรายงานและยังไม่ได้ทำซ้ำ

สิ่งที่การ์ดของโมเดลทั้งสองไม่ได้บอกคุณ คือทั้งสองจะทำงานอย่างไรเมื่ออยู่ในแอปพลิเคชันเดียวกัน การทดสอบนั้น — เสียงเดียวกัน อุปกรณ์เดียวกัน งบประมาณความหน่วงเดียวกัน — ยังไม่มีใครOutsideบริษัททั้งสองดำเนินการ จนกว่าจะมีการทดสอบดังกล่าว การตัดสินใจจึงขึ้นอยู่กับขอบเขตและสิทธิ์การใช้งาน ซึ่งรู้ได้ในวันนี้ มากกว่าความแม่นยำ ซึ่งยังไม่รู้