เวอร์ชันแรกๆ ของ Voice Pro ใช้ ONNX Runtime ร่วมกับไฟล์สัญญาณเสียงที่ถูกส่งออกในรูปแบบ ONNX จาก Qwen ASR อย่างเป็นทางการ มันทำงานได้ แต่การนำไปใช้งานจริงนั้นค่อนข้างยากลำบาก นี่คือปัญหาที่เราเจอ และเหตุผลที่ตอนนี้แอปสามารถทำงานได้ llama.cpp ด้วยโมเดลที่ผ่านการควอนไทซ์ในรูปแบบ GGUF
ปัญหาที่ 1: ขนาดการติดตั้ง
เวอร์ชันสำหรับ Windows ของ Voice Pro ที่มี ONNX Runtime รวมกับผู้ให้บริการ DirectML และผู้ให้บริการ CUDA รวมถึงน้ำหนักโมเดล มีขนาดเท่ากับ 430 MB. Linux ก็คล้ายกัน นั่นเป็นสิ่งที่มากเกินไปที่จะขอให้ใครสักคนดาวน์โหลดสำหรับเครื่องมือบันทึกเสียงที่พวกเขายังไม่เคยลองใช้
บิลด์แบบ GGUF คือ 83 MB บน Windows. ไฟล์ไบนารีของ llama.cpp หลังการคอมไพล์แล้วมีขนาดเล็กมาก โมเดลฐานที่ถูกควอนไทซ์มีขนาดประมาณ 60 MB (เทียบกับประมาณ 200 MB สำหรับรูปแบบ ONNX แบบ fp16) และเราไม่ได้แจกจ่ายไฟล์ DLL สำหรับบริการการทำงานแยกกันสำหรับ CPU, CUDA, DirectML และ Vulkan — llama.cpp สามารถจัดการทั้งสี่รูปแบบนี้ด้วยไฟล์ไบนารีเดียว
ปัญหาที่ 2: การเริ่มต้นใช้งานครั้งแรก (cold-start)
ONNX Runtime ร่วมกับ DirectML บน Windows ที่ติดตั้งใหม่ใช้เวลาประมาณ 3–5 วินาทีในการเริ่มต้นเซสชันการอนุมาน ทุกครั้งที่ผู้ใช้กดปุ่มลัดเป็นครั้งแรกหลังจากรีบูตระบบ จะพบความล่าช้านี้ ซึ่งถือว่าไม่สามารถยอมรับได้สำหรับเครื่องมือบันทึกเสียงพูด ที่จุดประสงค์หลักคือ “การพูดทันที”
llama.cpp โหลดโมเดล GGUF ได้ภายในเวลาประมาณ 400 มิลลิวินาทีบนฮาร์ดแวร์รุ่นเดียวกัน โดยใช้เทคนิค memory-mapped weights ไม่มีขั้นตอนการคอมไพล์กราฟ และไม่ต้องโหลดไฟล์ runtime เพิ่มเติมเพื่อเริ่มต้นใช้งาน
ปัญหาที่ 3: ความยุ่งยากเรื่องการแพ็กเกจ
ONNX Runtime จัดส่งในรูปแบบ Python wheel ซึ่งหมายความว่า มีล้อที่แตกต่างกันไปตามเวอร์ชันของ Python ระบบปฏิบัติการ และสถาปัตยกรรมของ CPU. หากเพิ่มการเร่งความเร็วด้วย GPU ก็จะต้องนำเวอร์ชันของ CUDA และเวอร์ชันของ DirectML มาคูณกัน โปรแกรม Nuitka (เครื่องมือบรรจุไฟล์ของเรา) ยังคงบรรจุเวอร์ชันที่ผิดอยู่เรื่อยๆ เรามีสคริปต์สร้างไฟล์ที่มีเงื่อนไขถึงหกชุด
llama.cpp เป็นไฟล์ไบนารีในภาษา C++ ตัวเดียว เราจะคอมไพล์มันสำหรับแต่ละแพลตฟอร์ม (Windows x64, Linux x64) แล้วส่งมอบในรูปแบบไฟล์ที่สามารถรันได้โดยตรง ซึ่ง Voice Pro จะใช้งานมัน ไม่มีความต้องการต้องใช้ไลบรารี Python ในการประมวลผลเลย — Python เป็นเพียงเครื่องมือช่วยเชื่อมต่อนั้นเอง
ปัญหาที่ 4: คุณภาพเมื่อมีขนาดเล็ก
ความกังวลเกี่ยวกับการควอนไทซ์คือการสูญเสียความแม่นยำ ในทางปฏิบัติ Q5_K_M ที่ควอนไทซ์ Qwen3-ASR 0.6B (โมเดลฐานของเรา) มีค่า WER อยู่ประมาณ 0.3% เมื่อเทียบกับเวอร์ชัน ONNX แบบ fp16 เต็มรูปแบบในชุดข้อมูลประเมินภายในของเรา Q4_0 แย่กว่าอย่างเห็นได้ชัด ดังนั้นเราจึงกำหนดให้ Q5_K_M เป็นค่าเริ่มต้น สำหรับผู้ใช้ที่ต้องการความแม่นยำสูงสุดสามารถดาวน์โหลดเวอร์ชัน fp16 จากตัวจัดการโมเดลได้
สิ่งที่เราตัดสินใจละทิ้ง
การรองรับ ASR ของ llama.cpp มีความทันสมัยกว่าของ ONNX Runtime โครงสร้างโมเดลบางประเภทยังไม่มีตัวแปลงเป็น GGUF ในปัจจุบันยังไม่เป็นปัญหาเพราะ Qwen3-ASR สามารถแปลงได้อย่างราบรื่น แต่หากในอนาคตเราต้องการลองใช้โมเดล ASR ที่แตกต่างไปอย่างสิ้นเชิง เราอาจจำเป็นต้องคงเส้นทาง ONNX ไว้เป็นทางเลือกสำรอง
ผลลัพธ์โดยรวม: ขนาดการติดตั้งเล็กลง 5 เท่า, การเริ่มต้นแบบเย็นเร็วขึ้นประมาณ 10 เท่า, ไฟล์บิตแมปเดียวที่ต้องสร้างแทนที่จะเป็นสิบสองไฟล์ เราควรทำแบบนี้มาตั้งแต่แรก