LFM3-Audio-2B บน Ollama: เสียงพูดดีขึ้น ด้วยหูแบบเดิม

ของ Liquid AILFM3-Audio-2B กลายเป็นสิ่งที่ดาวน์โหลดได้ด้วยคำสั่งเดียวเมื่อเช้านี้ ollama run lfm3-audio ดึงข้อมูล 2.1 GB และเริ่มต้นโมเดลขนาด 2B พารามิเตอร์ที่รับข้อความหรือเสียงและตอบกลับเป็นข้อความ เสียงพูด 24 kHz หรือทั้งสองอย่าง ตัวโมเดลเพิ่งมีอายุได้หนึ่งวัน — เปิดตัวเมื่อวันที่ 27 ตุลาคม 2026 ภายในตระกูล LFM3 ที่มีหกโมเดล สิ่งใหม่ในวันที่ 28 ตุลาคมคือการจัดส่ง และสิ่งแรกที่ควรรู้อยู่ในตาราง benchmark ของ Liquid เอง: เมื่อเทียบกับ LFM2.5-Audio-1.5B ที่มันมาแทน คุณภาพเสียงพูดเพิ่มขึ้นอย่างชัดเจน ความเข้าใจเสียงเกือบเพิ่มเป็นสองเท่า และการรู้จำเสียงพูดภาษาอังกฤษไม่ดีขึ้นเลย

ส่วนที่เหลือของบทความนี้แยกสิ่งที่ตรวจสอบได้ในตอนนี้ออกจากสิ่งที่ยังตรวจสอบไม่ได้ สาขาเสียงได้รับเพียงหนึ่งย่อหน้าจากโพสต์บล็อกของตระกูลโมเดลและโมเดลการ์ด — ไม่มีประกาศ "Introducing LFM3-Audio" ของตัวเอง — และเราไม่พบการรันเบนช์มาร์กแบบอิสระของโมเดลนี้ที่ใดเลย ตัวเลขทุกตัวด้านล่างเป็นของ Liquid เว้นแต่ประโยคจะระบุไว้เป็นอย่างอื่น

มีอะไรเปิดตัวไปแล้วบ้าง และประกาศนั้นมีเนื้อหาน้อยเพียงใด

โพสต์ของ Liquid วันที่ 27 ตุลาคม "เปิดตัว LFM3: ทุกโมดัลลิตีสำหรับความฉลาดเฉพาะทาง" ประกาศเปิดตัวโมเดลขนาด 2B จำนวนหกโมเดลที่ฝึกจาก LFM3-1.7B-Base ได้แก่ โมเดลข้อความ วิชัน เสียง โอมนิ และโมเดลตัดสินใจอีกสองโมเดลที่แยกเฉพาะทางมาจากสาขาวิชันและโอมนิ เสียงเป็นหนึ่งในสี่สาขาโมดัลลิตีและได้รับเพียงหนึ่งย่อหน้า — การปรับปรุง UTMOSv2 ตัวเลข 50 ms time-to-first-token และโคเดกแบบเรียลไทม์ 87× ไม่มีโพสต์เฉพาะด้านเสียง ไม่มีบล็อกเกณฑ์มาตรฐานด้านเสียง และไม่มีรายการราคาสำหรับโมเดล LFM3 ใด ๆ บนหน้าราคาของ Liquid

สัปดาห์นี้มีชิ้นงานสามชิ้นที่นำแบบจำลองมาให้ผู้อ่านได้เห็นโดยตรง:

• น้ำหนักโมเดล — LiquidAI/LFM3-Audio-2B บน Hugging Face ภายใต้ LFM Open License v1.0 พร้อมการ์ดโมเดลที่มีตารางเปรียบเทียบฉบับเต็ม

• llama.cpp — PR #31257 ซึ่งรวมเมื่อวันที่ 27 ตุลาคม เพิ่ม LFM3-Audio-2B และ LFM3-Omni-2B โดยคงคอนโวลูชันของตัวเข้ารหัสเสียงและโคเดกไว้โดยไม่ควอนไทซ์ เปิดให้ใช้เสียงผู้ชายหรือผู้หญิงผ่านแฟล็ก TTS และระบุว่า live ASR เป็น PR ติดตามผล plutôt แทนที่จะเป็นส่วนหนึ่งของการรวม

• Ollama — lfm3-audio, 2.1 GB, แท็ก latest และ 2b แสดง 19 ดาวน์โหลด และ "อัปเดตเมื่อหนึ่งชั่วโมงที่แล้ว" ณ เวลาที่บันทึกภาพ ส่วนหัวของหน้าระบุว่ามีห้าโมเดล; มีสองแถวที่เผยแพร่แล้ว

รายการบน Ollama คือรายการที่สำคัญที่สุด เพราะเป็นเส้นทางเดียวที่ไม่เริ่มต้นด้วยการอ่านการ์ดโมเดล และมันยังปรากฏขึ้นโดยไม่มีประกาศใด ๆ เลย — ไม่มีโพสต์ ไม่มีบันทึกการเปลี่ยนแปลง ไม่มีสิ่งใดบนการ์ดของโมเดลเองที่ชี้มาที่มัน

แผ่นข้อมูลจำเพาะ รวมถึงตัวเลขที่เกือบทุกคนคัดลอกผิด

• พารามิเตอร์ — รวมทั้งหมด 2B บนแกนหลัก LFM3 พร้อมตัวเข้ารหัสเสียงเชิงสาเหตุที่พัฒนาเองภายในองค์กร และโทเค็นไนเซอร์ LiquidCodec

• อินพุต — ข้อความ หรือเสียงที่สุ่มตัวอย่างที่ 16 kHz

• เอาต์พุต — ข้อความ เสียงพูด 24 kHz หรือข้อความและเสียงพูดแบบสลับกัน

• บริบท — 32K โทเค็น ครอบคลุมทั้งอินพุตและเอาต์พุต นี่ไม่ใช่ตัวเลข 256K ที่ถูกกล่าวถึงซ้ำในสื่อเปิดตัว: ตัวเลขนั้นเป็นของ LFM3-1.7B ซึ่งเป็นโมเดลข้อความ หน้าของสาขาเสียงเองระบุว่า 32K

• ภาษา — 18 ภาษา แต่แสดงเป็น 19 โลแคล เนื่องจากภาษาอังกฤษปรากฏสองครั้งในฐานะตัวแปรบริติชและอเมริกัน Live ASR รองรับเฉพาะภาษาอังกฤษเท่านั้น การแปลจะแม่นยำที่สุดเมื่อแปลไปหรือมาจากภาษาอังกฤษ

• สัญญาอนุญาต — LFM Open License v1.0 ใช้งานเชิงพาณิชย์ได้ฟรีเมื่อมีรายได้ต่อปีต่ำกว่า $10M และต้องมีสัญญาอนุญาตเชิงพาณิชย์แบบมีค่าใช้จ่ายเมื่อเกินเกณฑ์ดังกล่าว

• พื้นที่จัดเก็บ — 2.1 GB เมื่อเป็นบิลด์ Ollama

สองแถวในนั้นควรค่าแก่การหยุดคิดสักหน่อย ตัวเลข context คือสิ่งที่บทสรุปจะเข้าใจผิดไปอีกหลายเดือน เพราะโพสต์ของครอบครัวโมเดลขึ้นต้นด้วย 256K ขณะที่การ์ดเสียงบอกแบบเงียบ ๆ ว่า 32K และจำนวนภาษาก็แท้จริงแล้วคือจำนวน locale ที่ปลอมตัวมา: สิบเก้ารายการ สิบแปดภาษา โดยมีสองตัวแปรของภาษาอังกฤษที่แบกงานส่วนเกินไว้ ไม่มีอันไหนเป็นเรื่องอื้อฉาว และทั้งสองอย่างล้วนเปลี่ยนสิ่งที่คุณจะสัญญากับผู้ใช้

คำสั่งเดียว และฟิลด์ที่ขัดแย้งกับการ์ด

`ollama run lfm3-audio` คือการตั้งค่าทั้งหมดจริง ๆ หน้านั้นติดแท็กโมเดลว่า tools, audio และ 2b และ readme ที่อยู่เหนือตารางโมเดลโดยตรงบอกว่ารองรับข้อความหรือเสียง และตอบกลับเป็นข้อความ เสียงพูด หรือทั้งสองอย่าง ตารางโมเดลขัดแย้งกัน: ทั้งสองแท็กระบุอินพุตเป็น "Text" และ context เป็นขีด (-)

เรื่องนี้ควรค่าแก่การจริงจังมากกว่าจะมองข้ามว่าเป็นเพียงความผิดปกติของการเรนเดอร์ Ollama รองรับอินพุตเสียงตั้งแต่ v0.20 ในเดือนเมษายน 2026 เมื่อ Gemma 4 นำความสามารถด้านเสียง คำสั่ง ollama transcribe และส่วน input_audio แบบ OpenAI มาให้ กลไกนี้มีอยู่ สิ่งที่ยังไม่ได้รับการยืนยันคือมันถูกเชื่อมต่อสำหรับเช็กพอยต์นี้หรือไม่ แท็กเสียงเป็นการอ้างถึงความสามารถ ไม่ใช่ผลการทดสอบ หากแผนของคุณเริ่มต้นด้วย "ส่งไฟล์ WAV เข้า Ollama" จงตรวจสอบด้วยไฟล์เดียวเสียก่อนก่อนจะออกแบบสิ่งต่างๆ โดยอิงกับมัน

เอาต์พุตเสียงมีลักษณะเดียวกันเมื่อมองจากอีกด้าน การ merge ของ llama.cpp เปิดให้ใช้แฟล็กเสียง TTS ส่วนหน้าเว็บของ Ollama ไม่ได้ระบุสิ่งที่เทียบเท่ากัน และ readme อธิบายเอาต์พุตเสียงว่าเป็นคุณสมบัติของโมเดลมากกว่าจะเป็นฟีเจอร์ของ CLI หากพลิกทุกประโยคกลับด้าน ข้อสรุปก็ยังคงเดิม: เส้นทางเทอร์มินัลในปัจจุบันคือครึ่งที่เป็นข้อความของโมเดลเสียง การแชตด้วยเสียงแบบฟูลดูเพล็กซ์ต้องใช้เส้นทาง Python หรือ llama.cpp

สกอร์บอร์ดที่ Liquid เผยแพร่

ตัวเลขหกตัว ซึ่งสี่ตัวมีค่าของรุ่นก่อนหน้า ทั้งหมดมาจากการ์ดโมเดลของ Liquid โดยไม่มีชุดทดสอบที่ระบุชื่อ ไม่มีฮาร์เนส และไม่มีความแปรปรวน

• ASR ภาษาอังกฤษ อัตราความผิดพลาดระดับคำ ↓ — 6.23 สำหรับ LFM3-Audio-2B เทียบกับ 6.13 สำหรับ LFM2.5-Audio-1.5B คงที่ และเป็นแถวเดียวที่ไม่มีการเปลี่ยนแปลง

• ASR หลายภาษา, WER/CER ↓ — 6.03 ไม่มีการเผยแพร่ตัวเลขของรุ่นก่อนหน้า

• TTS ภาษาอังกฤษ, UTMOSv2 ↑ — 3.83 เทียบกับ 3.22 ถือว่าขยับขึ้นมาก โดยทั่วไป 4.0 มักถูกมองว่าเป็นเส้นแบ่งที่ใกล้ระดับมนุษย์

• VoiceBench ↑ — 73.13 เทียบกับ 55.17

• การเข้าใจเสียง, MMAR ↑ — 50.60 เทียบกับ 25.85 เกือบสองเท่า

• การเรียกใช้เครื่องมือจากเสียง, การประเมินภายใน ↑ — 58.50 ไม่มีตัวเลขจากรุ่นก่อนหน้า

เมื่อเทียบกับตัวเลือกอื่นๆ ในตารางเดียวกัน มันเป็นโมเดลเล็กที่ดี แต่ไม่ใช่ผู้นำ Voxtral Mini 3B ทำได้ 5.51 WER และ NVIDIA Audex 2B ทำได้ 5.99 โดยทั้งคู่ดีกว่า 6.23 Qwen2.5-Omni 3B ทำคะแนนความเข้าใจเสียงได้ 54.41 เทียบกับ 50.60 Gemma 4 E4B ทำคะแนนการเรียกใช้เครื่องมือได้ 72.40 เทียบกับ 58.50 และแถวพารามิเตอร์ของ Liquid เองระบุว่า Gemma นั้นอยู่ที่ 8B เทียบกับ 2B ของโมเดลนี้ — ชื่อ "E4B" นับเฉพาะพารามิเตอร์ที่ทำงานอยู่ ไม่ได้นับพารามิเตอร์ทั้งหมด สรุปตามจริงคือ ASR ที่แข่งขันได้ เอาต์พุตเสียงที่ดีขึ้นอย่างชัดเจน และการให้เหตุผลด้านเสียงที่มั่นคงสำหรับขนาด 2B — ไม่ใช่ผู้ครองสถิติในคอลัมน์ใดเลย

ช่องว่าง 6.23 เทียบกับ 6.13 อยู่ในวิสัยที่สัญญาณรบกวนจากการสุ่ม (sampling noise) สามารถก่อให้เกิดขึ้นได้ และไม่ควรตีความเป็นว่าถดถอย ช่องว่าง 3.83 เทียบกับ 3.22 ไม่ใช่เช่นนั้น — การขยับ UTMOS 0.6 คะแนนอยู่ไกลเกินช่วงนั้นมาก ข้อสรุปที่ป้องกันได้คือ Liquid ใช้เจนเนอเรชันนี้ไปกับการเจนเนอเรต: เสียงดีขึ้น การให้เหตุผลด้านเสียงดีขึ้น และส่วนหน้าของ ASR ที่ยืนหยัดได้ในขณะที่ตัวเข้ารหัส (encoders) เปลี่ยนไปข้างใต้ เราไม่พบการทำซ้ำผลโดยบุคคลที่สามของแถวใด ๆ เลย ดังนั้นให้ถือว่าการจัดลำดับนี้เป็นสมมติฐานจนกว่าจะมีใครเผยแพร่สักรายการหนึ่ง

ทำไม codec จึงอยู่ได้นานกว่าโมเดล

LiquidCodec เป็นส่วนของรีลีสนี้ที่น่าจับตามองนอกเหนือจากเช็กพอยต์ โดยบีบอัดเสียงพูด 80 ms ให้เหลือโทเคนแบบไม่ต่อเนื่อง 12 โทเคน ถอดรหัสกลับเป็น 24 kHz พร้อมรองรับสตรีมมิ่ง และ Liquid วัดได้ที่ประมาณ 87 เท่าของเวลาจริงบน CPU เธรดเดียวของ M4 Max เอนโคเดอร์แบบ causal คือสิ่งที่ทำให้สามารถ prefill ระหว่างการพูดได้แทนที่จะทำหลังพูด ซึ่งเป็นที่มาของตัวเลข time-to-first-token ที่ "ต่ำถึง 50 ms"

ตัวเลขสองตัวนั้นเป็นสิ่งที่ถูกอ้างถึงมากที่สุดและทำซ้ำได้น้อยที่สุดในการเปิดตัว ทั้งคู่เป็นการวัดของผู้จำหน่ายบนฮาร์ดแวร์ Apple ที่ระบุรุ่นชัดเจน โดยไม่มีฮาร์เนสทดสอบ ไม่มีชุดข้อมูลเสียง และไม่มีเปอร์เซ็นไทล์ พวกมันอธิบายกรณีที่ดีที่สุด โทรศัพท์ Raspberry Pi หรือ VM x86 ที่ใช้ร่วมกันจะทำไม่ได้ตามตัวเลขนั้น และไม่มีอะไรในเอกสารเปิดตัวที่บอกว่าจริง ๆ แล้วจะทำได้เท่าไรแทน

การรองรับรันไทม์กว้างอย่างผิดปกติสำหรับโมเดลที่เพิ่งเปิดตัวได้หนึ่งวัน: Transformers 5.20.2 หรือใหม่กว่าพร้อม trust_remote_code, vLLM และ SGLang สำหรับเช็กพอยต์ BF16, llama.cpp สำหรับ GGUF, MLX 4-bit บน Apple silicon, ONNX Runtime สำหรับความสามารถในการพอร์ต และการปรับแต่งละเอียดบน GPU เดียว ข้อกำหนดเกี่ยวกับโค้ดกำหนดเองคือสิ่งที่ต้องปักหมุดเวอร์ชันไว้ LFM3-Audio โหลดจากโมดูลของตัวเองและอ่านน้ำหนักโคเดกจากไดเรกทอรี audio_tokenizer แยกต่างหาก ดังนั้นสภาพแวดล้อมที่ไม่ได้ปักหมุดเวอร์ชันจึงเป็นตั๋วสนับสนุนที่รอเกิดขึ้น

การรู้จำเสียงในเครื่องเทียบกับเอนด์พอยต์ที่โฮสต์

เหตุผลที่โมเดลเสียง 2B ขนาด 2.1 GB น่าสนใจก็คือ ทางเลือกอื่นเรียกเก็บเงินจากคุณตามทุกวินาทีของเสียง การโฮสต์เองมีต้นทุนคงที่ — เครื่องที่คุณมีอยู่แล้ว การดาวน์โหลด และไม่มีการคิดเงินรายนาที ส่วนเอนด์พอยต์แบบโฮสต์มีต้นทุนส่วนเพิ่มต่อโทเคนและไม่มีภาระด้านปฏิบัติการเลย

ต้องชัดเจนว่าแต่ละด้านครอบคลุมอะไรบ้าง ระบบแปลงข้อความเป็นเสียงแบบโฮสต์ — ประเภทที่เราเลือกส่งงานไป เช่น gpt-4o-mini-tts ที่ราคาอินพุต $0.60 และเอาต์พุต $12.00 ต่อล้านโทเค็น หรือ gemini-2.5-flash-preview-tts ที่ $0.50 และ $10.00 — ทำหน้าที่แปลงข้อความเป็นเสียงเท่านั้น ไม่ทำอย่างอื่น ส่วน LFM3-Audio-2B ยังฟัง ถอดเสียง และแปลได้ด้วย และทำงานได้แม้ไม่ได้ต่อเครือข่าย ทั้งสองอย่างแก้ปัญหาคนละครึ่งของ voice agent ตัวเดียวกัน

LFM3-Audio-2B ไม่มีอยู่บน OrcaRouter โมเดลเสียงที่เราให้บริการเป็นปลายทางเสียงแบบโฮสต์ ดังนั้นการแบ่งที่ตรงไปตรงมาสำหรับผลิตภัณฑ์เสียงในเดือนนี้ คือเสียงเข้าและออกในเครื่องด้วยโมเดล Liquid และทุกอย่างฝั่งข้อความอยู่เบื้องหลัง ปลายทางเดียวสำหรับโมเดล 200+ รุ่น — มาร์กอัป 0% จากราคาตามรายการของผู้ให้บริการ โดยมีการสลับไปใช้ระบบสำรองอัตโนมัติเมื่อผู้ให้บริการเกิดปัญหาขัดข้อง และมี DSL สำหรับกำหนดเส้นทางหากคุณต้องการประกอบหลายโมเดลไว้ในการเรียกครั้งเดียว นั่นคือสิ่งที่ทำให้การตั้งค่าแบบสองรันไทม์อยู่รอดได้: สัญญาหนึ่งฉบับสำหรับครึ่งที่โฮสต์ และดาวน์โหลดหนึ่งครั้งสำหรับครึ่งที่อยู่ในเครื่อง

สำหรับฝั่งโลคอล ต้นทุนไม่ได้เป็นศูนย์: เวต 2.1 GB กระบวนการที่ต้องดูแลให้ทำงานอยู่ และไม่มี SLA หากเสียงไม่เคยออกจากอาคาร การแลกเปลี่ยนนั้นก็ง่าย หากออกไป ราคาแบบโฮสต์ก็ต่ำพอที่ภาระด้านปฏิบัติการมักเป็นตัวตัดสินคำถามนี้

ใครควรเป็นคนรันมันในสัปดาห์นี้ และใครควรจะรอก่อน

ลองรันดูถ้าคุณต้องการลูปเสียงในเครื่องบนแล็ปท็อป และตอนนี้พอรับได้กับการแสดงข้อความออกทางเทอร์มินัล ลองรันดูถ้าคุณต้องการเอาต์พุตเสียงพูดในภาษาที่เสียงโฮสต์ที่คุณมีนั้นอ่อนหรือแพง — สิบแปดภาษาถือว่าครอบคลุมมากกว่าโมเดล TTS ขนาดเล็กส่วนใหญ่ที่มี ลองรันดูถ้าคุณมีไฟล์บันทึกที่ไม่สามารถออกจากเครื่องได้ และต้องการถอดเสียงพร้อมสรุปจากโมเดลเดียว ลองรันดูถ้าคุณกำลังสร้างต้นแบบการเรียกเครื่องมือด้วยเสียง และต้องการให้โมเดลอยู่บนเครื่องเดียวกับเครื่องมือ

หยุดคิดก่อนหากความแม่นยำของ ASR คือตัวผลิตภัณฑ์ อัตราความผิดพลาดระดับคำที่ 6.23 ถือว่าน่ายอมรับได้ และยังเป็นรองสามโมเดลในตารางของ Liquid เอง หยุดคิดก่อนหากคุณต้องการถอดเสียงแบบสตรีมมิ่งในวันนี้ — ASR แบบไลฟ์เป็น PR ต่อยอดของ llama.cpp และเมื่อออกมาแล้วจะรองรับเฉพาะภาษาอังกฤษ หยุดคิดก่อนหากคุณต้องการให้โมเดลรู้เรื่องต่างๆ: การ์ดโมเดลแนะนำให้ใช้ retrieval และระบุชัดเจนว่าไม่แนะนำ agentic coding หรือการให้เหตุผลหลายขั้นที่ขนาดนี้ และหยุดคิดก่อนหากคุณต้องการ SLA จากผู้ขาย เพราะหน้าราคาของ Liquid ระบุถึง d1, d1-ultra และ LFM2.5-24B-A2B และไม่มี audio endpoint ของ LFM3 เลย

สามคำถามที่การเปิดตัวไม่ได้ตอบ

LFM3-Audio-2B เป็นโมเดลเดียวกับ LFM3-Omni-2B หรือไม่

ไม่ใช่ครับ ทั้งสองใช้แกนหลัก LFM3 ร่วมกัน และปรากฏใน pull request ของ llama.cpp เดียวกัน แต่ Omni เพิ่มความสามารถด้านภาพเข้าไปบนเสียง และเป็นการลงทุนที่ใหญ่กว่าของทั้งสอง ถ้างานคือการโทรศัพท์ การบันทึกการประชุม หรือคำสั่งเสียง Audio คือโมเดลที่เล็กกว่าซึ่งทำงานที่เล็กกว่า ถ้างานเกี่ยวข้องกับการดูอะไรบางอย่างไปพร้อมกับฟังสิ่งนั้น นั่นคือ omni branch

มันสามารถถอดเสียงไลฟ์สตรีมได้ไหม

ยังไม่ผ่าน llama.cpp ในตอนนี้ การ merge ระบุว่า live ASR เป็นงานติดตามผล และ model card ระบุชัดเจนว่า live ASR รองรับเฉพาะภาษาอังกฤษเท่านั้น แม้ในอนาคตจะมีให้ใช้แล้วก็ตาม การถอดเสียงแบบแบตช์จากไฟล์บันทึกเสียงคือเส้นทางที่รองรับในปัจจุบัน ด้วย context ขนาด 32K tokens ซึ่งเป็นขีดจำกัดความยาวคร่าว ๆ ที่ควรวางแผนเผื่อไว้สำหรับไฟล์ยาว เนื่องจาก audio tokens และ text tokens ใช้โควตานี้ร่วมกัน

ต้องใช้ GPU ไหม

ไม่ และนั่นคือจุดสำคัญของการบิลด์ {{1}}GGUF{{/1}} อาร์ติแฟกต์ {{2}}Ollama{{/2}} ขนาด 2.1 GB รันบน CPU ตัวเลข 87× เท่าเรียลไทม์ที่วัดได้นั้นวัดตัวโคเดก ไม่ใช่โมเดลภาษา ดังนั้นอย่าตีความว่าเป็นความเร็วแบบ end-to-end บนฮาร์ดแวร์ของคุณ {{3}}Apple silicon{{/3}} มีเส้นทางที่ราบรื่นที่สุดผ่าน {{4}}MLX{{/4}} หรือการรองรับ {{5}}llama.cpp{{/5}} ที่รวมเข้ามาแล้ว บน x86 ให้คาดว่าการถอดรหัสด้วย CPU จะเป็นคอขวด และวัดก่อนที่คุณจะสัญญาตัวเลขเลเทนซีใด ๆ กับใคร

อะไรจะทำให้คำตัดสินนี้เปลี่ยนไปได้

สัญญาณสามประการ เรียงตามระดับที่มันจะมีความสำคัญ ประการแรก การติดตามผล ASR แบบเรียลไทม์ที่ลงใน llama.cpp — สิ่งนี้เปลี่ยนตัวถอดเสียงแบบแบตช์ให้เป็นสิ่งที่คุณวางไว้หลังไมโครโฟนได้ ซึ่งเป็นกรณีการใช้งานที่คนส่วนใหญ่ต้องการจริง ๆ ประการที่สอง การรัน WER แบบอิสระบนชุดมาตรฐาน; ตราบใดที่ยังไม่มีสิ่งนี้ สิ่งเดียวที่ทำให้ ASR ของโมเดลนี้น่าเชื่อถือคือตารางของผู้ขายที่เปรียบเทียบกับโมเดลก่อนหน้าของผู้ขายรายเดียวกัน ประการที่สาม ราคา API ที่เผยแพร่สำหรับสาขาเสียง ซึ่งจะบอกเราว่า Liquid ตั้งใจจะขายการฟังเป็นบริการ หรือคงไว้เป็นกลยุทธ์ด้านเวตของโมเดล

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