음성 인식은 오랫동안 클라우드의 영역이었다. 마이크로 들어온 소리를 서버로 올려 변환하고 다시 받아오는 구조는 지연과 네트워크 비용, 그리고 프라이버시 문제를 늘 함께 가져왔다. Cactus Compute가 공개한 Whistle은 이 전제를 뒤집는다. 전체 모델이 16.9MB짜리 파일 하나이며, CPU에서 외부 의존성 없이 돌아가고, 텍스트 모델 Needle과 동일한 C++ 엔진·컨테이너·양자화 위에 올라간다. 대상 기기로 스마트폰과 웨어러블은 물론 로봇, 스마트홈, 차량, 심지어 마이크로컨트롤러까지 꼽는 점에서, 이 모델이 겨냥하는 지점이 '서버 없이 기기 안에서 끝나는 음성 처리'임이 분명하다.
세 단계가 모두 기기 안에서
Whistle의 처리 과정은 프런트엔드, 인코더, 디코더 세 부분으로 나뉘며 전부 온디바이스에서 수행된다. 프런트엔드는 16kHz 모노 오디오를 25ms 창과 10ms 홉으로 잘라 250~3500Hz 대역의 80개 로그-멜 빈으로 바꾼다. 30초 분량이면 3,000프레임이 되는데, 128채널·커널 9의 합성곱 스템이 이 수를 세 번 절반으로 줄여 80ms당 한 프레임, 즉 375프레임만 남긴다. 이후 모든 연산이 이 낮은 프레임률에서 돌아가기 때문에 연산량이 크게 줄어든다.
인코더는 Needle이 쓰는 것과 같은 8개의 Simple Attention 블록으로 구성되며, 피드포워드 대신 Monarch Hadamard MLP를 둔다. 어텐션이 인과적(causal)이지 않아 3초 지점의 프레임이 12초 지점을 참조할 수 있다. 디코더는 폭 512의 Laddered Simple Attention 블록 8개로, 쿼리 헤드 8개에 KV 헤드 2개, 3~7번째 층의 engram 조회 같은 구성을 갖는다. 결국 Whistle은 Needle의 블록 구성을 음성용으로 재배치한 모델에 가깝다.
음성 전용 부분은 '한 줄'뿐
텍스트 모델과 다른 음성 고유의 추가 요소는 층마다 들어간 게이트형 교차 어텐션 하나다. 각 디코더 층이 인코더 출력을 읽어오되, 층별로 학습된 게이트로 그 반영 정도를 조절한다. 핵심은 이 투영 연산이 클립이 들어온 시점에 375프레임에 대해 단 한 번만 수행되고 디코딩 내내 재사용된다는 점이다. 덕분에 5개의 빔(beam)을 쓰더라도 오디오를 다섯 번 훑는 게 아니라, 짧은 전사 캐시 다섯 개만 유지하면 된다. 디코딩은 길이 정규화 로그확률로 점수를 매기는 5-빔 방식이며, Aho-Corasick 오토마톤을 활용한 키워드 바이어싱으로 지정한 단어의 확률을 끌어올릴 수 있다. 어휘는 8,192개 텍스트 조각에 언어 토큰 7개가 더해져, 감지된 언어가 별도 값이 아니라 토큰으로 바로 출력된다.
디코더에만 적용된 '사다리(ladder)' 구조도 실무적으로 흥미롭다. 2개 층부터 각 깊이가 독립된 모델로 학습되어 있어, 로드 시점에 --audio-depth 플래그로 원하는 깊이를 고르면 성능과 비용을 바꿀 수 있다. 다만 인코더는 절대 잘라내지 않고 어느 깊이에서든 8개 블록이 모두 돈다. 또한 엔진은 디코더를 돌리기 전에 클립의 음량 범위를 측정해, 기준 이하이면 빔 서치에 들어가지도 않고 빈 전사와 빈 언어 값을 돌려준다. 무음 구간에서 불필요한 연산을 아예 하지 않는 설계다.
지연과 정확도, 그리고 한계
성능 비교에서 Whistle은 LibriSpeech test-clean·test-other, SPGISpeech, Earnings-22, FLEURS 평균에서 앞섰다고 밝혔다. 반대로 Whisper base는 TED-LIUM과 AMI, MLS 평균에서 앞서는데, 용량이 145.3MB로 Whistle의 16.9MB와 큰 차이가 난다. 지연 측면의 대비가 특히 분명하다. Whisper는 모든 입력을 30초로 패딩하기 때문에 첫 토큰까지 걸리는 시간이 클립 길이와 무관하게 일정한 반면, Whistle은 클립 길이에 비례해 5초에 5.9ms, 10초에 11.1ms, 30초에 36.3ms를 기록한다. 짧은 발화를 빠르게 받아내야 하는 음성 명령 시나리오에서 유리한 특성이다. 단어오류율은 Whisper 노멀라이저로 측정했고, Whistle 수치는 86,174개 발화 기준이며, 테스트 오디오가 학습·검증 데이터에 섞이지 않았음을 체크섬과 화자 ID로 검증했다고 설명한다.
통합 측면에서 가장 눈에 띄는 것은 같은 바이너리가 음성과 텍스트를 모두 처리한다는 점이다. needle_load는 .cact 파일이 담고 있는 모델이 무엇이든 읽어들이며, needle_complete에 클립을 직접 넘기면 엔진이 전사하고 그 결과를 사용자가 정의한 도구에 대고 응답한 뒤, 도구 호출과 음성 필드(앞에 audio_가 붙는다)를 담은 JSON 객체 하나를 반환한다. 전사 텍스트를 호출 측에서 따로 다룰 필요가 없어, 음성 한 조각을 곧바로 도구 호출로 바꾸는 파이프라인이 성립한다. 16kHz WAV나 원시 샘플은 기본 설치만으로 되고, 다른 샘플레이트나 마이크 캡처는 soxr·sounddevice를 더하는 [mic] 옵션이 필요하다. 각 호출은 텍스트와 언어, 첫 토큰까지의 밀리초, 이후 초당 토큰 수를 돌려주며, word_timestamps로 단어별 시간·확률을, language 인자로 언어 강제를 지정할 수 있다.
실무자 입장에서 Whistle의 의미는 '작고 빠른 음성 모델' 그 이상이다. 엔진이 환경 변수를 전혀 읽지 않고 모든 동작이 컴파일된 기본값이거나 명시적 플래그로만 결정된다는 점은, 임베디드 환경에서 재현 가능하고 예측 가능한 배포를 중시하는 팀에 분명한 장점이다. 엔진이 macOS·리눅스부터 안드로이드, iOS, watchOS, ARM 윈도우, RISC-V, MIPS, 브라우저, WASI 컴포넌트까지 17개 타깃용으로 미리 빌드되어 제공되는 것도 같은 맥락이다. 다만 TED-LIUM·AMI 같은 특정 벤치마크에서는 여전히 더 큰 Whisper가 앞서고, 지원 언어가 7개에 한정되며, 전사가 320토큰에서 잘린다는 점은 긴 회의 녹취나 다국어 폭을 요구하는 용도에선 제약이 될 수 있다. 가중치는 Hugging Face에, 엔진과 플랫폼 폴더는 Cactus-Compute/needle3에, 소스는 GitHub에 공개되어 있어 직접 검증해 볼 여지는 열려 있다.