Các bản dựng sớm của Voice Pro sử dụng ONNX Runtime với các bản xuất ONNX ASR chính thức của Qwen. Nó hoạt động, nhưng việc phát hành nó rất đau đớn. Đây là những gì chúng tôi đã gặp phải và tại sao ứng dụng hiện chạy trên llama.cpp với các mô hình được lượng tử hóa GGUF.
Vấn đề 1: kích thước cài đặt
Bản dựng Windows của Voice Pro với ONNX Runtime + nhà cung cấp DirectML + nhà cung cấp CUDA + trọng số mô hình đã được phát hành. 430 MB. Linux cũng tương tự. Đó là một yêu cầu quá lớn đối với việc bắt ai đó tải xuống một công cụ ghi chú mà họ chưa thử.
Bản dựng GGUF là 83 MB trên Windows. Tập tin nhị phân llama.cpp đã biên dịch rất nhỏ, mô hình cơ sở đã lượng tử hóa khoảng ~60 MB (so với ~200 MB ở dạng fp16 ONNX), và chúng tôi không phát hành các DLL nhà cung cấp thực thi riêng cho CPU, CUDA, DirectML và Vulkan — llama.cpp xử lý cả bốn loại chỉ với một tập tin nhị phân.
Vấn đề 2: khởi động lạnh
ONNX Runtime với DirectML trên một bản cài đặt Windows lạnh mất 3–5 giây để khởi tạo phiên suy luận. Mỗi lần người dùng nhấn phím tắt lần đầu tiên sau khi khởi động lại, họ đều gặp độ trễ đó. Điều này không thể chấp nhận được đối với một công cụ đánh máy bằng giọng nói, nơi mà mục đích chính là “nói ngay lập tức”.
llama.cpp tải mô hình GGUF trong khoảng 400 ms khi khởi động nguội trên cùng phần cứng. Trọng số được ánh xạ bộ nhớ, không có bước biên dịch đồ thị, không có gói runtime nào để khởi tạo.
Vấn đề 3: địa ngục đóng gói
ONNX Runtime được phân phối dưới dạng Python wheel, điều đó có nghĩa là Các phiên bản Python, hệ điều hành và kiến trúc CPU khác nhau sẽ có các bộ bánh xe khác nhau.. Thêm tăng tốc GPU và bạn nhân với phiên bản CUDA và phiên bản DirectML. Nuitka (công cụ đóng gói của chúng tôi) liên tục đóng gói sai biến thể. Chúng tôi có các script xây dựng với sáu nhánh điều kiện.
llama.cpp là một tệp nhị phân C++ duy nhất. Chúng tôi biên dịch nó một lần cho mỗi nền tảng (Windows x64, Linux x64) và phân phối dưới dạng tệp thực thi gốc mà Voice Pro gọi. Không có bất kỳ phụ thuộc nào vào môi trường chạy Python cho suy luận — Python chỉ là phần kết nối.
Vấn đề 4: chất lượng ở kích thước nhỏ
Mối lo với lượng tử hóa là mất độ chính xác. Trong thực tế, Qwen3-ASR 0.6B (mô hình nền tảng của chúng tôi) được lượng tử hóa Q5_K_M đo trong khoảng 0,3% WER so với phiên bản ONNX fp16 đầy đủ trên bộ đánh giá nội bộ của chúng tôi. Q4_0 kém hơn rõ rệt, vì vậy chúng tôi phát hành Q5_K_M làm mặc định. Người dùng muốn độ chính xác tối đa có thể tải cấp fp16 từ trình quản lý mô hình.
Những gì chúng tôi đã hy sinh
Hỗ trợ ASR của llama.cpp mới hơn của ONNX Runtime. Một số kiến trúc mô hình lạ chưa có bộ chuyển đổi GGUF. Hiện tại điều đó không quan trọng — Qwen3-ASR chuyển đổi sạch — nhưng nếu sau này muốn thử một mô hình ASR hoàn toàn khác, chúng ta có thể cần giữ đường ONNX làm phương án dự phòng.
Kết quả cuối cùng: bản cài đặt nhỏ hơn 5 lần, khởi động nguội nhanh hơn khoảng 10 lần, chỉ cần một tệp nhị phân để xây dựng thay vì mười hai. Lẽ ra chúng tôi nên làm điều này ngay từ ngày đầu.