16.9MB 음성 인식 모델 Whistle

AI 요약

Whistle은 모바일, 웨어러블, 로봇, 스마트홈, 자동차, 마이크로컨트롤러를 겨냥한 음성 인식 모델입니다. 모델 파일은 16.9MB이며, CPU에서 별도 의존성 없이 실행됩니다. Cactus Compute의 Needle과 같은 C++ 엔진, 컨테이너, 양자화 방식을 사용합니다. 모든 처리는 기기 안에서 이뤄집니다.

전사와 음성 임베딩

Whistle은 16kHz 모노 오디오를 한 번에 최대 30초 처리합니다. 영어, 독일어, 프랑스어, 스페인어, 이탈리아어, 네덜란드어, 폴란드어를 지원하며, 언어를 지정하지 않으면 자동으로 감지합니다. 전사 결과뿐 아니라 단어마다 시작·종료 시각과 확률을 반환합니다. 디코딩 없이 음성 임베딩만 추출하는 기능도 제공합니다. 임베딩은 80ms마다 한 행씩 출력합니다.

오디오는 25ms 창과 10ms 간격으로 나누고, 80개 로그 멜 필터뱅크(log-mel bins)를 적용합니다. 주파수 대역은 250~3500Hz로 제한하고 채널마다 정규화합니다. 30초 입력은 3,000개 프레임으로 바뀝니다. 128채널, 커널 크기 9인 합성곱 단계가 프레임 수를 세 차례 절반으로 줄여 375개가 남습니다. 이후 단계는 이 속도로 동작합니다.

인코더와 디코더

인코더는 Simple Attention 블록 8개로 구성합니다. 각 블록에는 4개 mHC 잔차 경로와 피드포워드 네트워크를 대신하는 Monarch Hadamard MLP가 들어갑니다. 인코더 어텐션은 비인과적(non-causal)이므로 3초 지점 프레임도 12초 지점 프레임을 참조합니다.

디코더에는 Laddered Simple Attention 블록 8개를 둡니다. 폭은 512이며, 쿼리 헤드 8개와 키·값 헤드 2개를 사용합니다. 쿼리와 키 차원은 48, 값 차원은 64입니다. Q, K, V에 3탭 인과 합성곱을 적용하고, 3층과 7층에서 18,432개 슬롯을 대상으로 engram 조회를 수행합니다. 이 구조는 Needle의 블록 구성에서 층 수를 바꾼 형태입니다.

음성 인식에 필요한 추가 요소는 각 디코더 층의 게이트형 교차 어텐션입니다. 디코더가 인코더 출력을 읽을 때 층마다 학습한 게이트를 곱합니다. 오디오가 들어올 때 375개 프레임을 8개 층에 투영해 캐시에 저장하고, 디코딩 동안 재사용합니다. 따라서 빔 5개를 탐색해도 오디오를 다섯 번 다시 처리하는 대신 짧은 전사 캐시 다섯 개를 사용합니다.

디코딩과 실행 방식

Whistle은 길이를 정규화한 로그 확률로 점수를 매기는 빔 5개를 사용합니다. 지정한 키워드는 Aho-Corasick 자동자와 빔 탐색을 함께 진행하며, 자동자가 문구를 따라가면 해당 문구의 로그 확률을 높입니다. 전사는 최대 320토큰으로 제한합니다. 어휘는 텍스트 조각 8,192개와 언어 토큰 7개로 이뤄집니다. 감지한 언어도 별도 필드가 아니라 토큰으로 출력합니다.

디코더는 2층 이상 각 깊이를 독립 모델처럼 학습했습니다. 실행 시 --audio-depth로 깊이를 고를 수 있지만, 인코더는 줄이지 않고 항상 8개 블록을 모두 실행합니다. 디코딩 전에 입력 음량 범위를 확인해 무음 임계값보다 낮으면 빈 전사와 빈 언어를 반환하고 빔 탐색을 시작하지 않습니다.

벤치마크와 배포

Whistle은 LibriSpeech test-clean과 test-other, SPGISpeech, Earnings-22, FLEURS 평균에서 앞섰습니다. 반면 TED-LIUM, AMI, MLS 평균에서는 Whisper base가 앞섰습니다. Whisper base의 크기는 145.3MB입니다. Whistle의 첫 토큰까지 걸리는 시간은 입력 길이에 따라 달라져 5초 오디오에서 5.9ms, 10초에서 11.1ms, 30초에서 36.3ms입니다. Whisper는 입력을 30초 길이로 채우므로 첫 토큰 시간은 오디오 길이에 따라 달라지지 않습니다.

단어 오류율(WER)은 Whisper 정규화 방식을 따랐습니다. Whistle 점수는 발화 86,174개를 대상으로 측정했고, Whisper와 Moonshine 점수는 각 프로젝트가 공개한 다국어 체크포인트 결과를 사용했습니다. 테스트 오디오는 체크섬과 화자 ID를 대조해 학습·검증 데이터에 들어가지 않았는지 확인했다고 설명합니다. 다만 Whistle이 모든 데이터셋에서 더 정확하다는 뜻은 아닙니다.

Whistle은 macOS, Linux, Android, iOS, watchOS, Windows on ARM, RISC-V, MIPS, 브라우저, WASI 컴포넌트 등 17개 타깃용 사전 빌드 파일을 제공합니다. 각 폴더에는 needle 실행 파일, libneedle.a, needle.h가 포함됩니다. 16kHz WAV나 원시 샘플은 기본 설치만으로 처리하며, 다른 샘플링 레이트와 마이크 입력에는 [mic] 추가 기능이 필요합니다. C API는 needle_load, needle_transcribe, needle_embed로 구성합니다. 가중치는 Hugging Face에, 엔진과 플랫폼별 파일 및 소스 코드는 GitHub 저장소에 공개했습니다.

Reddit 반응

• @u/ttkciar — 누군가 스팸으로 신고했지만, 그렇게 보이지는 않습니다. Cactus Compute가 API 서비스도 제공하지만 Apache-2.0 오픈소스 구현은 완전히 로컬에서 작동하는 것 같고, API에 접근할 수 없어도 계속 사용할 수 있습니다. 이 게시물은 남겨두겠습니다.
• @u/DarkVoid42 — 나쁘지 않습니다. 제 형편없는 마이크에서는 단어를 몇 개 놓치고 잘못 인식하기도 하지만, 잘 작동합니다. 큰 오류 없이 85~90% 정도 성공하는 것 같습니다. 이 정도면 기대할 만한 수준입니다.
  • @u/iKy1e — 꽤 전부터 생각하던 아이디어가 떠오릅니다. 음성 명령을 TTS로 만들고 이런 작은 STT에 넣어 일부러 부정확한 전사를 생성하는 방식입니다. 오류는 소리가 비슷한 단어로 바뀌는 경우가 많습니다. 텍스트의 발음 유사도를 임베딩으로 묶거나, 모델을 미세조정해 이런 오류에도 올바르게 응답하게 하면 작고 빠르지만 완벽하지 않은 전사 모델의 활용처가 늘 것 같습니다. 원시 오디오를 LLM에 넣는 방식과 비슷한 중간 지점입니다. 현재 모델들이 오타를 잘 처리하듯, 부정확한 전사도 학습하게 하는 셈입니다.
• @u/seamonn — 사람들은 STT에서 지연 시간과 품질 중 무엇을 더 선호하나요? 대부분의 경우 어느 쪽이 더 중요한가요?
  • @u/Downtown-Elevator369 — 나중에 볼 강의를 저장하는 상황인지, 회의 내용을 실시간으로 요약하는 상황인지에 따라 다릅니다.
  • @u/lloyd08 — 받아쓰기를 한다면 지연 시간이고, 녹음을 전사한다면 품질입니다.
  • @u/FullstackSensei — 이런 모델을 Cactus의 Needle 모델과 결합하면 초경량 음성-도구 호출이 가능할 것 같습니다. Kokoro 82M 같은 TTS를 더하면 스마트워치나 인터넷 연결 없이도 쓸 수 있는 개인 비서처럼 만들 수 있습니다.
• @u/sterby92 — 오래된 Pixel 휴대전화에서 커스텀 Android 앱으로 실시간에 가깝게 실행합니다. 메시지나 할 일 목록을 받아쓰는 데는 품질이 괜찮습니다.
• @u/Karmjeet_Khoushaba — 16.9MB라니 놀랍습니다. 잡음이 있는 오디오에서는 더 큰 모델과 비교해 정확도가 어떤가요? 작은 모델은 보통 그런 환경에서 약해집니다.
• @u/Elouakili_Flexy — 16.9MB면 오디오를 디코딩하는 칩에서 함께 실행할 수 있을 것 같습니다. 그게 정말 대단한 점입니다.

원문: Cactus Compute / 번역·요약: Trawling