연구 체크포인트로 공개된 음성 인식 모델은 대개 PyTorch 가중치가 든 폴더 하나, 학습 스크립트 하나, 그리고 어떤 GPU로 학습했는지 적힌 메모로 이루어져 있습니다. 이는 벤치마크 점수를 재현하기에는 충분합니다. 하지만 라즈베리 파이나 휴대폰, 인터넷이 없는 노트북에 올리기에는 부족합니다. 하나에서 다른 하나로 가는 과정이 바로 변환 작업이며, 이것이 오픈 음성 모델이 실제 기기에 도달하는지를 결정짓는 대부분입니다.
우리는 이 변환 작업을 업으로 삼습니다: 오픈 ASR(자동 음성 인식, 즉 음성-텍스트 변환)과 TTS(텍스트 음성 변환) 모델을 가져다, 런타임에 Python 학습 스택이 전혀 필요 없이 일반 CPU나 온디바이스 가속기에서 오프라인으로 돌아가는 파일로 바꿉니다. 그 결과 대부분은 우리 자신의 계정이 아니라 Hugging Face의 OpenVoiceOS 조직 아래에 공개되는데, 이는 의도적인 선택입니다 — 이유는 아래에서 다룹니다.
왜 체크포인트는 배포가 아닌가
PyTorch나 NeMo 체크포인트는 특정한 Python 환경을 필요로 합니다: 정확한 라이브러리 버전, 대개는 GPU, 그리고 추론만을 위해서도 학습 프레임워크 자체가 필요합니다. 그 스택은 크고, 끊임없이 바뀌며, 작은 보드에서 부팅해야 하는 음성 비서 안에 넣고 싶은 것이 아닙니다.
모델 내보내기는 학습된 네트워크를 순전히 추론만을 위한 형식으로 변환함으로써 이를 해결합니다 — 학습 코드도, 자동 미분도, 프레임워크 종속도 없습니다. 우리는 서로 다른 배포 형태를 위해 세 가지 형식을 대상으로 삼습니다:
- ONNX(Open Neural Network Exchange)는 다양한 런타임이 CPU나 GPU에서, Linux·Windows·macOS 또는 임베디드 보드에서 실행할 수 있는 이식 가능한 그래프 형식입니다.
onnxruntime이 돌아가는 곳이라면 거의 어디서든 — 즉 거의 모든 곳에서 — 돌아가므로, 우리의 기본 대상입니다. - CoreML은 애플의 온디바이스 추론 형식입니다. CoreML 패키지는 CPU 대신 Mac이나 iPhone의 신경 엔진 또는 GPU에서 실행되며, 이는 애플 하드웨어에서의 실시간 음성 인식에 중요합니다.
- **GGUF**는
llama.cpp와 그 생태계가 사용하는 형식으로, 적은 메모리로 실행되어야 하는 양자화된 LLM 스타일 모델을 위해 만들어졌습니다. 우리는 고전적인 음향 모델보다 언어 모델에 아키텍처상 더 가까운, 더 새로운 트랜스포머 기반 음성 모델에 이를 사용합니다.
올바른 대상을 고르는 것은 겉치레가 아닙니다. 컨포머 기반 ASR 모델(대부분의 현대 음성 인식기 뒤에 있는, 합성곱과 셀프 어텐션을 결합한 아키텍처)은 ONNX나 CoreML로 깔끔하게 변환됩니다. Qwen3 기반 음성 모델은 내부적으로 언어 모델이므로, 대신 GGUF/llama.cpp 파이프라인에 자연스럽게 들어맞습니다.
양자화의 대가와 이득
양자화란 모델의 가중치를 숫자당 더 적은 비트로 저장하는 것을 의미합니다 — 학습 시 사용한 32비트 부동소수점 대신 16비트, 8비트, 혹은 4비트로. 숫자가 작아지면 파일도 작아지고, 적합한 하드웨어에서는 옮길 데이터가 적고 연산이 저렴해지므로 추론도 빨라집니다.
실제 모델 하나로 정확한 수치를 제시할 수 있습니다. nvidia/parakeet-tdt-0.6b-v3는 6억 파라미터 규모의 ASR 모델입니다. 그 CoreML 멜 인코더 구성 요소는 전체 정밀도에서 1132.5 MB이며, 4비트로 팔레타이즈하면 284.2 MB가 되어 — 세 개의 하위 구성 요소(인코더, 디코더, 결합 판정 네트워크) 전반에 걸쳐 거의 정확히 일치하는 3.99배의 축소입니다. 전체 패키지로 보면, 양자화하지 않은 CoreML 내보내기는 약 1.14 GB이고, 4비트 버전은 약 293 MB입니다. 이것이 휴대폰에 편안히 들어맞는 모델과 겨우 들어맞는 모델의 차이입니다.
그 대가는 정확도입니다: 가중치당 비트가 적을수록 정밀도가 낮아지고, 어느 지점을 넘으면 이는 더 많은 인식 오류로 나타납니다. ASR에서 이를 측정하는 표준 방법은 WER(단어 오류율 — 정답 전사와 비교했을 때 모델이 틀리는 단어의 비율)입니다. 그래서 우리는 동일한 모델의 여러 양자화 수준 — 4비트, 6비트, 8비트(int8), fp16 — 을 나란히 공개합니다. 하나만 골라서 모든 기기에 충분하기를 바라는 대신 말이죠. 휴대폰과 데스크톱은 그 곡선 위에서 서로 다른 지점을 감당할 수 있습니다.
검증 문제
조용히 더 나쁜 출력을 만들어내는 변환은 아예 변환하지 않는 것보다 더 위험합니다. 겉보기엔 아무것도 고장 나 보이지 않기 때문입니다 — 로드되고, 실행되고, 그저 음성을 조금 더 못 알아듣거나, 여러분이 직접 말하지 못해 귀로 확인할 수 없는 언어에서는 훨씬 못 알아들을 뿐입니다. 이를 잡아낼 유일한 방법은, 공개하기 전에 모든 언어와 모든 양자화 수준에 대해 실제 오디오로 내보낸 모델의 출력을 원본 참조 구현과 비교하는 것입니다.
우리가 출시하는 모든 변환에는 이것이 최소한의 조건입니다: 동일한 오디오를 원본 모델과 변환된 모델 양쪽에 통과시켜, 둘이 일치하는지 확인합니다. 화려한 단계는 아니지만, 이를 건너뛰는 것이야말로 “지원되는 언어”가 조용히 작동을 멈추는 방식입니다.
왜 모델이 우리가 아니라 OpenVoiceOS 아래에 있는가
모델 내보내기는 회사의 역량입니다: 체크포인트와 대상 기기를 주시면, 여러분의 하드웨어에 맞는 양자화 수준으로 검증된 오프라인 실행을 만들어 드립니다. 하지만 우리가 오픈된, 특정 고객의 의뢰가 아닌 체크포인트로부터 만들어내는 변환 모델들은 우리 자신의 네임스페이스가 아니라 이 모델들이 실행되도록 만들어진 오픈 음성 비서 플랫폼인 OpenVoiceOS로 갑니다.
이유는 간단합니다: OpenVoiceOS가 이 모델들이 실제로 사용되는 곳이기 때문입니다. 회사 계정에 놓인 변환 모델은 근사한 산출물일 뿐입니다. ovos-stt-plugin-onnx-asr, ovos-stt-plugin-coreml, ovos-stt-plugin-rover가 이름으로 찾을 수 있는 곳에 공개된 동일한 모델은, 실제 비서가 이제 말하거나 알아들을 수 있는 언어입니다. 플랫폼 자체의 조직 아래에 공개하는 것이야말로 변환을 연구적 호기심이 아니라 지원되는 기능으로 바꾸는 일이며, 이 작업을 한 번 하는 것이 그것을 요청한 고객뿐 아니라 모든 OpenVoiceOS 설치에 혜택을 주도록 보장하는 방법입니다.
귀속 관계를 분명히 하자면: 우리는 이 음향 모델들을 처음부터 학습시키지 않으며, 그렇다고 주장하지도 않습니다. 기반이 되는 연구 — NVIDIA의 Parakeet 및 Conformer 모델, 인도 언어를 위한 AI4Bharat의 IndicConformer 모델, 갈리시아의 Proxecto Nós나 바스크 HiTZ 센터의 Conformer 모델 같은 대학 및 공공 기관 모델, 그리고 아프리카 언어와 소수 언어를 위해 모델을 변환하는 독립적인 노력들 — 은 그것을 학습시킨 팀들에게 속합니다. 우리가 더하는 것은 변환, 양자화, 원본에 대한 정확성 검사, 그리고 비서가 이름으로 결과를 불러올 수 있게 하는 플러그인 연결입니다.
공개된 것에서 직접 헤아린 그 변환 작업의 규모는 다음과 같습니다: 크기, 언어, 양자화 수준에 걸쳐 ONNX와 CoreML로 내보낸 90개 이상의 Parakeet ASR 변형; 30개 이상의 NVIDIA Conformer 모델; 저자원 인도 언어를 다루는 22개의 AI4Bharat IndicConformer 모델; 스웨덴어, 아이슬란드어, 페로어, 핀란드어와 두 가지 노르웨이어 문어 형태를 포함한 22개의 wav2vec2 모델; 바스크어와 갈리시아어를 위한 9개의 Conformer 모델; 그리고 쇼나어, 줄루어, 코사어, 말라가시어, 아이티 크레올어, 카빌어 같은 아프리카 및 크레올 언어를 다루는 독립적으로 변환된 Whisper 및 wav2vec2 모델들. 서로 다른 언어 코드 기준으로 확인된 ASR 변환만 세어도, 오늘날 오프라인 양자화 음성 인식기를 사용할 수 있는 언어가 최소 74개입니다 — 바스크어, 아라곤어, 아스투리아스어, 갈리시아어, 옥시타니아어, 아랍어 같은 언어들을 위해 내보낸 별도의 TTS 음성 카탈로그는 세지도 않은 수치입니다.
여러분의 언어나 기기에 오늘 오프라인 옵션이 전혀 없다면
대부분의 언어는 상업적 오프라인 음성 옵션을 결코 얻지 못합니다. 그 언어 하나만을 위한 시장이 벤더가 무언가를 만들 만큼 정당화되지 않기 때문입니다. 위의 패턴 — 기존의 오픈 체크포인트를 가져와, 실제로 가진 하드웨어에서 돌아가는 형식으로 변환하고, 맞도록 양자화하고, 원본에 대해 검증하고, 플러그인에 연결하는 것 — 은 시장 규모에 좌우되지 않습니다. 그것은 출발점이 될 오픈 체크포인트가 존재하는지에 좌우되며, 이는 점점 더 일반적인 경우가 되고 있습니다.
학습용 GPU에서만 돌아가는 음성 모델을 가지고 계시거나, 현재 사용 언어로 오프라인 음성 지원이 전혀 없는 기기를 가지고 계시다면, 문의해 주시거나 저희 서비스 페이지에서 이 작업이 처음부터 끝까지 어떤 모습인지 확인해 보십시오.