AuK เทียบกับ AuK-Flash: 32 ขั้นตอนการสุ่มตัวอย่างหรือ 4 และเหตุใดนักเรียนจึงชนะในบางครั้ง

เช็คพอยต์ทั้งสองมีขนาดเท่ากันพอดีที่ 6.122 GB ทั้งคู่แจกจ่ายภายใต้ MIT และทั้งคู่ขับเคลื่อนด้วยอินสตรักชันเอนโค้ดเดอร์ขนาด 3 พันล้านพารามิเตอร์ที่ดาวน์โหลดแยกต่างหากชุดเดียวกัน กับ VAE ขนาด 637 MB ชุดเดียวกัน AuK และ AuK-Flash แทบไม่ต่างกันเลยในสิ่งที่คุณจัดเตรียม — แต่ต่างกันในสิ่งหนึ่งที่คุณรู้สึกได้ทุกครั้งที่เรียกใช้: จำนวนครั้งที่แซมเพลอร์ทำงาน AuK โมเดลพื้นฐานโอเพนเวตขนาด 1.5B สำหรับสร้างและแก้ไขคำพูด ซึ่งทีม Hunyuan ของ Tencent และผู้ร่วมเขียนเชิงวิชาการจาก Shanghai Jiao Tong และ NTU เผยแพร่บน Hugging Face เมื่อวันที่ 9 กันยายน ใช้การประเมินฟังก์ชัน 32 ครั้ง พร้อม classifier-free guidance ที่ค่า 2.0 ส่วน AuK-Flash โมเดลนักเรียนแบบกลั่น ใช้เพียงสี่ครั้ง โดยปิด guidance โดยสิ้นเชิง เพื่อการเร่งความเร็วแบบ wall-clock ที่อ้างว่า 4.5 เท่า การตีความแบบตรงไปตรงมาคือ Flash คือที่นั่งประหยัดที่คุณเลือกเมื่อความหน่วงสำคัญกว่าคุณภาพ แต่การตีความนั้นผิด และตารางประเมินผลของผู้ให้บริการเองนั่นแหละที่ขัดแย้งกับมัน: ในแถวการเปรียบเทียบแบบตัวต่อตัวของรายงานทางเทคนิค Flash ได้คะแนนสูงสุดในเมตริก edit-ratio ของ MMAE-Speech ในคอลัมน์ paralinguistic ของ SpeechEditBench ในด้านการทำตามคำสั่งภาษาอังกฤษ ในด้านความคล้ายคลึงเสียงผู้พูดของการแก้ไขเชิงเสียง และในทั้งสี่แถวของคุณภาพการรับรู้ด้านการเพิ่มคุณภาพ มันไม่ใช่การลดระดับ แต่เป็นการแลกเปลี่ยนที่ต่างกัน และคุณจะต้องการอยู่ฝั่งไหนก็ขึ้นอยู่กับว่างานใดในสองงานที่คุณรันจริง

จริงๆ แล้วอะไรที่แตกต่างกันระหว่างพวกมัน

เมื่อตัดส่วนทางการตลาดออกไป ทางเลือกก็ลดลงเหลือเพียงไฟล์คอนฟิก รันไทม์ของ AuK เป็นทรานส์ฟอร์เมอร์แบบ hybrid rectified-flow — บล็อก MMDiT แบบ dual-stream ป้อนเข้าสู่บล็อก DiT แบบ single-stream ที่รวมกัน — ทำงานด้วยตัวแก้ปัญหา Euler แบบ bfloat16 ที่ 24 kHz, latents ขนาด 64 มิติที่ 50 Hz AuK-Flash ใช้สถาปัตยกรรมเดียวกันกับที่เพิ่มตัวสุ่มตัวอย่างแบบ distilled เข้าไป ซึ่งสร้างขึ้นโดยการ initialize แบบ consistency รวมกับ Decoupled DMD ที่มีการกำหนดเส้นทางตามงาน (task-routed) ส่วนประกอบอื่น ๆ ทั้งหมดถูกใช้ร่วมกัน

• ขั้นตอนการสุ่มตัวอย่าง — AuK: 32 การประเมินฟังก์ชัน กำหนดค่าได้ AuK-Flash: 4 คงที่

• การชี้นำแบบไร้ตัวจำแนก — AuK: สเกล 2.0, ปรับแต่งได้ AuK-Flash: ไม่มี (CFG=0).

• ขนาด checkpoint — AuK: auk_base.safetensors ที่ 6.122 GB. AuK-Flash: auk_flash.safetensors ที่ 6.122 GB. เหมือนกันจนถึงระดับเมกะไบต์.

• รันไทม์ที่ใช้ร่วมกัน — VAE ขนาด 637 MB พร้อมกับตัวเข้ารหัส Qwen/Qwen2.5-Omni-3B ซึ่งดาวน์โหลดแยกต่างหากและใช้ร่วมกันทั้งสอง

• ความเร็วที่อ้างไว้ — AuK-Flash: เร็วกว่าตัวครูสอน 32-NFE ถึง 4.5 เท่าตามเวลา wall-clock ที่ฮาร์ดแวร์ ระยะเวลา และขนาดแบตช์เท่ากัน

• สัญญาอนุญาต — MIT สำหรับทั้งสอง ซึ่งครั้งนี้มีความหมายตรงตามที่เขียนไว้จริงๆ

ขนาด checkpoint ที่เหมือนกันเป๊ะนี้คือรายละเอียดที่ทำให้การเปรียบเทียบทั้งหมดเปลี่ยนมุมมอง โมเดลกลั่น (distilled) โดยทั่วไปจะแลกความเร็วมาด้วยขนาดที่เล็กกว่า แต่ AuK-Flash ไม่ได้เล็กกว่า คุณไม่ได้ประหยัดพื้นที่ดิสก์ ไม่ได้ประหยัดเวลาโอนย้าย และ—เนื่องจาก encoder กับ VAE ถูกใช้ร่วมกัน และ DiT มีความกว้างเท่ากัน—คุณไม่ได้ประหยัด VRAM อย่างมีนัยสำคัญจากการเลือกใช้ตัวนักเรียน (student) ทรัพยากรเพียงอย่างเดียวที่ Flash คืนให้คุณคือเวลา ถึงกระนั้นก็ควรพูดถึงกับดักงบประมาณข้อหนึ่งไว้: ตัวเลข "1.5B" ในชื่อโมเดลอธิบายถึง diffusion backbone และไฟล์บนดิสก์มีขนาด 6.122 GB เตรียมพื้นที่ไว้สำหรับไฟล์นี้

จุดที่ AuK-Flash เอาชนะโมเดลเต็มได้จริง

นี่คือส่วนที่สัญชาตญาณ "distilled = worse" เข้าใจผิด และมันยังคงเป็นเช่นนั้นในหลายตระกูลงานที่ไม่เกี่ยวข้องกันในตารางของรายงาน เริ่มจากด้านการรับรู้ ในชุดการปรับปรุง DNS Challenge Flash ทำ UTMOS ได้ 4.05 เทียบกับของ AuK ที่ 3.86; ใน CHiME-4 ได้ 3.91 เทียบกับ 3.72; ใน Libri2Mix ได้ 4.03 เทียบกับ 3.87; ใน VCTKSR ได้ 4.05 เทียบกับ 3.93 Flash ยังชนะในคอลัมน์ข้อผิดพลาดการรู้จำในสองในสี่ชุดนั้น โดยมี CHiME-4 WER 7.84 เทียบกับ 7.98 และ VCTKSR WER 2.92 เทียบกับ 3.06 ความเป็นธรรมชาติที่มนุษย์ให้คะแนนเป็นแกนเดียวที่ student นำหน้าอย่างสม่ำเสมอ และรายงานกล่าวไว้อย่างชัดเจนว่า: โมเดลเต็มให้ความแม่นยำทางภาษาและความเที่ยงตรงในการแก้ไขที่สูงกว่า ขณะที่ Flash "มักให้คุณภาพการรับรู้ที่ดีกว่า"

ความได้เปรียบไม่ได้จำกัดอยู่แค่การปรับปรุงเสียง{{1}} ในเมตริกอัตราการแก้ไขของ MMAE-Speech — ว่าการแก้ไขตรงตามขนาดที่ตั้งใจไว้หรือไม่ — Flash ได้ 13.85 เทียบกับ AuK ได้ 12.44{{2}} ในคอลัมน์อวัจนภาษาของ SpeechEditBench ได้ 39.25 เทียบกับ 38.50{{3}} ในงานแปลงคำบรรยายภาษาอังกฤษเป็นเสียงพูดของ InstructTTSEval ได้ 82.40 เทียบกับ 81.60 ซึ่งเสมอกับเกณฑ์พื้นฐานที่ดีที่สุดในแถวนั้น{{4}} ในการแก้ไขเชิงเสียงในชุด Ming-Freeform มันมีความคล้ายคลึงเสียงผู้พูดสูงสุดในตระกูล โดยได้ 0.79 ในภาษาจีนและ 0.75 ในภาษาอังกฤษ เทียบกับ 0.78 และ 0.74 ของรุ่นฐาน{{5}} กล่าวอีกนัยหนึ่ง การรักษาเอกลักษณ์เสียงผู้พูดคือหนึ่งในสิ่งที่สี่ขั้นตอนมอบให้คุณ{{6}} — บทสรุปของรายงานเองก็คือ โมเดลเต็มให้ค่าความผิดพลาดในการรู้จำเฉลี่ยต่ำกว่า ในขณะที่ Flash รักษาเอกลักษณ์เสียงผู้พูดได้ดีกว่า{{7}} หากคุณทำงานด้านการแปลงเสียง การพากย์เสียง หรือการปรับปรุงเสียง ซึ่งลักษณะเสียงสำคัญกว่าความผิดพลาดของคำพูด โมเดลนักเรียนคือตัวเลือกที่ดีกว่า{{8}}

ที่ซึ่ง 32 ขั้นยังคงคุ้มค่าที่จะรักษาไว้

ข้อดีของโมเดลพื้นฐานนั้นรวมศูนย์อยู่ในจุดที่คุณคาดหวังได้จากโมเดลดิฟฟิวชันที่มีงบประมาณการสุ่มตัวอย่างสูงขึ้น นั่นคือทุกอย่างที่ผลลัพธ์ต้องมีความถูกต้องทางภาษา

ใน Seed-TTS-Eval ค่า WER เฉลี่ยของ AuK คือ 2.65 เทียบกับ 2.85 ของ Flash โดยมีความคล้ายคลึงของเสียงผู้พูดที่ 0.795 เทียบกับ 0.790 การกระจายตัวภายในค่าเฉลี่ยนั้นให้ข้อมูลมากกว่าค่าเฉลี่ยเอง ทั้งสองแทบจะเสมอกันในชุดทดสอบภาษาอังกฤษ — 1.02 และ 1.03 — และต่างกันในภาษาจีน 1.02 เทียบกับ 1.10 และอีกครั้งในชุดย่อยภาษาจีนที่ยาก 5.91 เทียบกับ 6.43 ภาษาจีนคือจุดที่ขั้นตอนพิเศษให้ผลตอบแทน

รูปแบบเดียวกันนี้ปรากฏในด้านการปฏิบัติตามคำสั่ง (instruction-following) ในงานแปลงคำอธิบายภาษาจีนเป็นเสียงพูด (Chinese description-to-speech) ของ InstructTTSEval ช่องว่างนั้นกว้างมาก: 83.37 สำหรับ AuK เทียบกับ 78.80 สำหรับ Flash และรายงานระบุว่าโมเดลฐานเป็นผู้นำในเมตริกภาษาจีนทั้งสามของชุดการประเมินนั้น ขณะที่ "ข้อได้เปรียบหลักของ Flash คือผลลัพธ์ DSD ภาษาอังกฤษที่แข็งแกร่งกว่า" ภาษา ไม่ใช่สถาปัตยกรรม คือเส้นแบ่ง

ความเที่ยงตรงในการแก้ไขคือสิ่งที่แยกพวกเขาออกจากกันได้ชัดเจนที่สุด ความแม่นยำในการแก้ไขเนื้อหาของ SpeechEditBench อยู่ที่ 91.83 สำหรับ AuK เทียบกับ 87.50 สำหรับ Flash ซึ่งเป็นช่องว่างเดี่ยวที่ใหญ่ที่สุดในการเปรียบเทียบนี้ การแก้ไขเชิงเสียงก็เกือบจะเอนเอียงไม่แพ้กัน ที่ 37.07 เทียบกับ 30.26 ในชุด Ming-Freeform AuK รายงานค่า WER ที่ต่ำกว่าเกือบทุกจุดที่สำคัญ: 3.09 เทียบกับ 3.34 ในการแก้ไขภาษาจีนแบบเต็ม และกว้างกว่ามากที่ 3.96 เทียบกับ 4.84 ในการแก้ไขภาษาอังกฤษแบบเต็ม หากผลิตภัณฑ์ของคุณเขียนคำพูดในบันทึกเสียงของใครบางคนใหม่ ไม่ว่าจะเป็นการแก้ไขเนื้อเพลง การแทนที่เนื้อหา การแทรก และการลบ โมเดล 32 ขั้นตอนคือตัวที่ทำให้ถอดเสียงถูกต้อง และความต่างของขั้นตอน 8 เท่านั้นคุ้มค่าที่จะจ่าย

โมเดลทั้งคู่ยังคงอ่อนแอในการปรับแต่งอารมณ์ ตามตัวเลขในรายงานของพวกเขาเอง: ความแม่นยำด้านอารมณ์ของ SpeechEditBench คือ 9.94 สำหรับ AuK และ 6.29 สำหรับ Flash นั่นไม่ใช่ผลพวงจากการกลั่นความรู้ มันเป็นกลุ่มงานที่ยังไม่มีใครแก้ได้ และการเลือก student จะไม่ทำให้คุณแย่ลงไปกว่าที่คุณเป็นอยู่แล้ว

4.5× เป็นตัวเลขตัวอย่าง ไม่ใช่ตัวเลขแบบ end-to-end

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

AuK-Flash ใช้ขั้นตอนการสุ่มตัวอย่าง 4 ขั้นตอน ในขณะที่ AuK ใช้ 32 ขั้นตอน คิดเป็นจำนวนขั้นตอนที่น้อยกว่า 8 เท่า ผู้จำหน่ายรายงานว่าเวลาจริง (wall clock) เร็วขึ้น 4.5 เท่า ความแตกต่างระหว่างตัวเลขทั้งสองนี้คือทุกอย่างที่อยู่รอบ ๆ วงวนการสุ่มตัวอย่าง และส่วนใหญ่ถูกครอบงำโดยตัวเข้ารหัส: โมเดลมัลติโมดัล Qwen2.5-Omni-3B ซึ่งทั้งสองเช็คพอยต์โหลด และทั้งคู่ต้องรันในทุกคำขอ ตัวเข้ารหัสดังกล่าวมีขนาดประมาณสองเท่าของ diffusion backbone และต้นทุนของมันคงที่ Flash ไม่สามารถทำให้มันเร็วขึ้นได้ เพราะ Flash ไม่ได้เป็นส่วนหนึ่งของมัน

ดังนั้นเวอร์ชันที่ตรงไปตรงมาของคำกล่าวอ้างนี้ก็คือ: 4.5× คือสิ่งที่คุณจะได้จากส่วน diffusion ภายใต้เงื่อนไขที่เทียบเท่ากัน และอัตราเร่งแบบ end-to-end ของคุณจะเท่ากับสัดส่วนของเวลาจริง (wall clock) ที่ลูปการสุ่มตัวอย่างครอบครองอยู่จริง หากคุณรันการสร้างแบบ long-form ซึ่งมี 32 สเต็ปบนเฟรมแฝงจำนวนมากเป็นหลัก คุณจะได้ตัวเลขใกล้เคียงกับตัวเลขที่เผยแพร่ หากเวิร์กโหลดของคุณเป็นคลิปสั้นที่มีการประมวลผลคำสั่งล่วงหน้าอย่างหนัก หรือคุณจัดกลุ่มคำขอเล็กๆ (batching) สัดส่วนที่ใหญ่กว่าของการเรียกแต่ละครั้งจะอยู่ในเอนโคเดอร์ที่ใช้ร่วมกัน และความเร่งจริงของคุณจะน้อยกว่า 4.5× อย่างมีนัยสำคัญ จงวัดส่วนผสมของเวิร์กโหลดของคุณเองก่อนที่จะให้งบประมาณด้านเวลาแฝงขึ้นอยู่กับมัน ยังไม่มีใครเผยแพร่ตัวเลขแบบ end-to-end นั้น — รวมถึงเวนเดอร์ ซึ่งไม่รายงานตัวเลขเวลาแฝงสัมบูรณ์หรือความต้องการ VRAM เลย

ต้นทุนของการกลั่น ในคำพูดของผู้เขียนเอง

รายงานทางเทคนิคมีความตรงไปตรงมาอย่างผิดปกติเกี่ยวกับจุดที่นักเรียนล้มเหลว และรูปแบบความล้มเหลวเหล่านั้นมีประโยชน์ต่อผู้ปรับใช้งานมากกว่าตารางเกณฑ์มาตรฐาน

ปรากฏว่าเป้าหมายการชี้แนะจากโมเดลครูคือต้นตอของปัญหา การใช้เป้าหมาย CFG ในส่วนความสม่ำเสมอ "อาจทำให้โมเดลนักเรียนแบบไม่กี่ขั้นตอนต้องเผชิญกับการคาดการณ์ที่อิ่มตัวเกินไป" ซึ่งผู้เขียนระบุว่าเป็นสาเหตุของ overshoot และการตัดยอดสัญญาณที่ได้ยินได้ ในอีกประเด็นหนึ่ง กำหนดการ Decoupled DMD แบบสม่ำเสมอ "ทำให้การแยกผู้พูดหลายคนและการแยกเสียงร้องแย่ลง" โดยผลลัพธ์จากโมเดลนักเรียนบางส่วนถดถอยกลับไปใกล้กับมิกซ์ที่ไม่ผ่านการประมวลผล — การกลั่นดังกล่าวลบล้างการแยกที่โมเดลควรจะทำ Task-routed DMD คือวิธีแก้ไขตามที่อธิบายไว้ และนี่คือเหตุผลที่รายงานระมัดระวังในการจำกัดข้อบกพร่องเฉพาะนั้นไว้ที่รูปแบบสม่ำเสมอ (uniform variant) หากการแยกเสียงพูดเป็นส่วนหลักของไปป์ไลน์ของคุณ ย่อหน้านี้คือสิ่งที่ควรทดสอบก่อนที่จะเชื่อถือ

ข้อจำกัดเพิ่มเติมอีกสองข้อเป็นเชิงปฏิบัติการมากกว่าเชิงสถิติ Prompt Enhancer ของไปป์ไลน์จะจับคู่ถ้อยคำพูดทั่วไปเกี่ยวกับความเร็ว ความดัง และระดับเสียงเข้ากับชุดค่าที่รองรับที่กำหนดไว้ และปฏิเสธสิ่งใดก็ตามที่ไม่สามารถจับคู่ได้ก่อนที่จะรันการอนุมานเชิงเสียง ดังนั้นคำขอที่ไม่รองรับจึงล้มเหลวตั้งแต่เนิ่นๆ แทนที่จะลดคุณภาพลงอย่างนุ่มนวล และ repository ยอมรับเฉพาะ Qwen/Qwen2.5-Omni-3B เป็นเส้นทางตัวเข้ารหัสเท่านั้น README ระบุว่า Qwen3-Omni ยังไม่ได้รับการสนับสนุนในขณะนี้ ดังนั้นตัวเข้ารหัสที่ใหม่กว่าจึงไม่ใช่การอัปเกรดแบบแทนที่ได้โดยตรง การผสานรวม ComfyUI มีขีดจำกัด 30 วินาทีสำหรับลำดับแหล่งบวกเป้าหมาย

การรันทั้งสองเป็นคอนฟิกูเรชันที่ตั้งใจไว้

ตัวอย่าง multi-GPU ของ repository เองวาง AuK บนอุปกรณ์หนึ่งและ AuK-Flash บนอีกอุปกรณ์หนึ่ง — cuda:0 และ cuda:1 — ซึ่งเป็นสัญญาณที่ชัดเจนว่า Tencent คาดหวังให้ทั้งสองทำงานร่วมกันมากกว่าแข่งขันกัน นอกจากนี้ยังเป็นคำตอบที่ถูกต้องสำหรับสแต็กเสียงพูดในระบบ production ส่วนใหญ่ เนื่องจากทั้งสองโมเดลมีความแข็งแกร่งในด้านที่ไม่ทับซ้อนกัน จัดเส้นทางคำขอที่เน้นการแก้ไขและภาษาจีนไปยัง AuK; จัดเส้นทางการปรับปรุงเสียง การแยกเสียง การทำตามคำสั่งภาษาอังกฤษ และสิ่งที่เป็นอินเทอร์แอกทีฟไปยัง AuK-Flash ทั้งคู่โหลด encoder และ VAE เดียวกัน ดังนั้นคุณจ่ายค่า runtime ที่ใช้ร่วมกันเพียงครั้งเดียวและสลับระหว่าง checkpoints เบื้องหลังได้

นั่นคือการตัดสินใจด้านการกำหนดเส้นทางในชั้นโมเดล และมีรูปแบบเดียวกันกับที่ OrcaRouter ใช้ในชั้น API สำหรับโมเดลที่โฮสต์ไว้ จุดที่ทั้งสองมาบรรจบกันในวันนี้คือรอยต่อในไปป์ไลน์ของ AuK เอง: Prompt Enhancer ต้องใช้chat endpoint ที่เข้ากันได้กับ OpenAIเพื่อแปลงคำสั่งคร่าวๆ ให้เป็นคำศัพท์ที่โมเดลรองรับ และ ASR fallback แบบเลือกใช้ได้ก็ต้องการเส้นทางสำหรับการถอดเสียง ชี้ไม่ว่าจะเป็นตัวใดไปที่ chat endpoint ที่เข้ากันได้กับ OpenAI แล้วคุณจะได้คีย์เดียวที่ใช้กับโมเดลกว่า 200 รายการ ราคาตามรายการของผู้ให้บริการที่ส่งผ่านโดยไม่มีส่วนเพิ่ม (0% markup) และการ failover อัตโนมัติหากแบ็กเอนด์ล่ม ซึ่งสำคัญพอดีเพราะนี่คือรีลีสที่เพิ่งออกมาได้สองวัน ยังไม่มี hosted API และไม่มีการตรวจสอบซ้ำโดยอิสระ และคุณไม่ต้องการให้ dependency ที่ยังไม่ผ่านการพิสูจน์ไปวางอยู่บน endpoint ที่เขียนตายตัว

อย่างไรก็ตาม ต้องพูดให้ชัดเจนว่าอะไรไม่พร้อมใช้งาน AuK และ AuK-Flash ไม่ได้ให้บริการโดยผู้ให้บริการโฮสต์อินเฟอเรนซ์รายใดเลย — การ์ด Hugging Face ระบุไว้ตรงนั้นโดยตรง — และทั้งคู่ก็ไม่สามารถกำหนดเส้นทางผ่าน OrcaRouter ได้ในขณะนี้ นี่คือการตัดสินใจแบบ self-hosting ตั้งแต่ต้นจนจบ

สิ่งที่ยังไม่ทราบ

เกือบทุกอย่างเกี่ยวกับรีลีสนี้เป็นข้อมูลที่รายงานโดยผู้พัฒนาระบบเอง ความเร็วที่เพิ่มขึ้น 4.5 เท่า ตัวเลข WER คอลัมน์ SpeechEditBench และแถว UTMOS ล้วนมาจากรายงานทางเทคนิคของทีม AuK เอง คือ arXiv 2609.08936 ซึ่งส่งเมื่อวันที่ 8 กันยายน — ไม่มีการทำซ้ำโดยอิสระ ไม่มีรายการในลีดเดอร์บอร์ดของบุคคลที่สาม และไม่มีผลการทดสอบจากเฟรมเวิร์กที่เป็นกลาง สัญญาณการนำไปใช้ก็บางพอๆ กัน: ณ วันที่ 10 กันยายน คลังข้อมูล Hugging Face สองแห่งแสดงการดาวน์โหลด 30 ครั้งในเดือนที่ผ่านมา และไลก์ประมาณสองโหลต่อแห่ง ในขณะที่คลังข้อมูล GitHub แสดงดาว 217 ดวง ฟอร์ก 12 ครั้ง และผู้มีส่วนร่วม 3 คน นั่นคือการปล่อยงานวิจัย ไม่ใช่กระแสหลัก

img src="4.png" alt="ภาพหน้าจอ README ของคลังที่เก็บ GitHub ของ Tencent-Hunyuan AuK ซึ่งแสดงประกาศโอเพนซอร์สวันที่ 9 กันยายน 2026 และตารางเวอร์ชัน AuK และ AuK-Flash"> p>การเปิดตัวครั้งนี้เงียบในแบบที่ควรกล่าวอย่างตรงไปตรงมา เพราะมันง่ายที่จะตีความเกินจริง ไม่มีการประกาศจาก Hunyuan ไม่มีบล็อกโพสต์ ไม่มีหน้าราคา และไม่มีงานเปิดตัว ข้อความระบุวันเพียงหนึ่งเดียวจากผู้พัฒนาคือบรรทัดเดียวใน README ของรีโพซิทอรี — [2026/09/09] เราทำให้ AuK เป็นโอเพนซอร์ส เมทาดาทาของรีโพซิทอรีบน Hugging Face แสดงว่าสเปซถูกสร้างขึ้นก่อนหน้านั้นในช่วงกลางเดือนสิงหาคม และน้ำหนักถูกอัปเดตล่าสุดเมื่อวันที่ 9 และ 10 กันยายน ดังนั้นการแพ็กจึงเกิดขึ้นก่อนการประกาศ สิ่งที่ทราบได้จากรีโพซิทอรีคือ: น้ำหนักภายใต้สัญญาอนุญาต MIT สำหรับทั้งสองเวอร์ชัน รายงานทางเทคนิค คำแนะนำการดาวน์โหลดที่ใช้งานได้สำหรับ Hugging Face และ ModelScope และรายการงานที่บันทึกไว้ สิ่งที่ยังไม่ได้รับการยืนยันคือ: ตัวเลขใด ๆ ที่รายงานไว้จะผ่านการวัดผลด้วยชุดทดสอบอิสระหรือไม่ จะมีเอนด์พอยต์ที่โฮสต์ไว้เกิดขึ้นหรือไม่ และเช็กพอยต์ Flash จะยังคงเป็นค่าเริ่มต้นที่แนะนำหรือไม่เมื่อคนอื่นได้รันมันแล้ว

เลือกอันไหนดี

หากคุณกำลังสร้างเนื้อหาหรือแก้ไขเนื้อเพลง หรือให้บริการเสียงพูดภาษาจีนในรูปแบบใดก็ตาม ให้ใช้ AuK และยอมรับ 32 ขั้นตอน ข้อดีของมันในด้านนั้นมีมากมาย สอดคล้องกันในชุดเครื่องมือแก้ไขอิสระสองชุด และเป็นความผิดพลาดด้านความถูกต้องที่ผู้ใช้สังเกตเห็นได้ทันที — คำที่ผิดในบทถอดความ

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

ถ้าคุณกำลังสร้างผลิตภัณฑ์เสียงพูดที่ครอบคลุมทั้งสองแบบ ให้รันทั้งสองแบบ ดิสก์เดียวกัน เอ็นโค้ดเดอร์เดียวกัน ไลเซนส์เดียวกัน คอนฟิกต่างกันหนึ่งจุด — และรูปแบบการดีพลอยที่ repository แสดงไว้แล้ว สิ่งเดียวที่ควรรอคือการวัด latency แบบ end-to-end ของคุณเอง: 4.5× นั้นจริง แต่มันเป็นของ sampler และ workload mix ของคุณเท่านั้นที่จะบอกว่ามันไปถึงผู้ใช้มากน้อยแค่ไหน