Voice Pro의 초기 버전들은 공식적으로 제공되는 Qwen ASR ONNX 형식을 사용하여 ONNX Runtime을 활용했습니다. 이 방식도 작동은 했지만, 실제 배포하는 데에는 많은 어려움이 있었습니다. 우리가 직면했던 문제들과, 이제 앱이 어떻게 작동하게 되었는지는 다음과 같습니다. llama.cpp GGUF 양자화 모델을 사용하여.
문제 1: 설치 크기
ONNX Runtime + DirectML 제공자 + CUDA 제공자 + 모델 가중치를 포함한 Voice Pro의 Windows 빌드가 출시되었습니다. 430 MB. Linux도 비슷했습니다. 아직 사용해 보지도 않은 받아쓰기 도구를 위해 그렇게 많은 것을 다운로드하라고 요구하는 것은 과한 요구입니다.
GGUF 빌드는 Windows 기준 83 MB. 컴파일된 llama.cpp 바이너리는 매우 작으며, 양자화된 기본 모델은 약 60MB입니다(fp16 ONNX 기준 약 200MB). 또한 CPU, CUDA, DirectML, Vulkan용 별도의 실행 공급자 DLL을 배포하지 않습니다 — llama.cpp는 하나의 바이너리로 이 네 가지를 모두 처리합니다.
문제 2: 콜드 스타트
새로 설치된 Windows에서 DirectML을 사용하는 ONNX Runtime은 추론 세션을 초기화하는 데 3~5초가 걸렸습니다. 재부팅 후 사용자가 단축키를 처음 누를 때마다 이 지연이 발생했습니다. '즉시 말하기'가 핵심인 받아쓰기 도구로서는 용납할 수 없는 지연입니다.
동일한 하드웨어에서 llama.cpp는 약 400ms 만에 GGUF 모델을 콜드 스타트로 로드합니다. 메모리 매핑된 가중치, 그래프 컴파일 단계 없음, 초기화할 런타임 휠도 없습니다.
문제 3: 패키지화 문제
ONNX Runtime은 Python wheel로 제공되며, 이는 다음을 의미합니다. Python 버전, OS, CPU 아키텍처에 따라 다른 wheel 제공. GPU 가속을 추가하면 CUDA 버전과 DirectML 버전이 곱해집니다. Nuitka(당사의 패키징 도구)는 잘못된 변형을 계속 번들링했습니다. 저희는 6개의 조건 분기를 가진 빌드 스크립트를 사용했습니다.
llama.cpp는 단일 C++ 바이너리입니다. 우리는 플랫폼(Windows x64, Linux x64)별로 한 번 컴파일하여 Voice Pro가 호출하는 네이티브 실행 파일로 제공합니다. 추론에는 Python 런타임 의존성이 전혀 없습니다. Python은 단지 접착제 역할만 합니다.
문제 4: 소형 모델에서의 품질
양자화의 문제점은 정확도 저하입니다. 실제로, 당사의 기본 모델인 Qwen3-ASR 0.6B를 Q5_K_M으로 양자화한 경우, 내부 평가 세트에서 전체 fp16 ONNX 버전에 비해 WER이 0.3% 이내로 나타났습니다. Q4_0의 경우는 현저히 성능이 떨어지므로, 기본값으로는 Q5_K_M을 제공합니다. 최고의 정확도를 원하는 사용자들은 모델 관리자에서 fp16 버전을 다운로드할 수 있습니다.
우리가 포기한 것
llama.cpp의 ASR 지원은 ONNX Runtime보다 최신입니다. 일부 이색적인 모델 아키텍처에는 아직 GGUF 변환기가 없습니다. 당분간은 문제가 되지 않습니다 — Qwen3-ASR은 깨끗하게 변환됩니다 — 하지만 향후 완전히 다른 ASR 모델을 시도하려면 ONNX 경로를 폴백으로 유지해야 할 수도 있습니다.
최종 결과: 설치 크기가 5배 작아지고, 콜드 스타트가 약 10배 빨라지며, 12개가 아닌 하나의 바이너리로 빌드합니다. 처음부터 이렇게 했어야 했습니다.