요약
캑터스 컴퓨트가 CPU에서 바로 돌아가는 16.9MB짜리 음성 인식 모델 Whistle을 공개했습니다.
휴대폰, 웨어러블, 로봇, 스마트홈 기기처럼 작은 기기를 겨냥한 모델입니다. 같은 회사의 도구 호출 모델 Needle과 같은 C++ 엔진에서 돌아가므로, 녹음한 말을 곧바로 함수 호출로 바꿀 수 있다고 소개했습니다.
왜 중요한가
- 의존성 없는 파일 하나로 CPU에서 돌아가서, 음성을 서버로 보내지 않고 기기 안에서 처리하기가 쉬워집니다.
- Whisper base의 9분의 1 크기로 여러 영어 시험에서 앞서, 메모리가 작은 기기에도 음성 인식을 넣을 여지가 생깁니다.
- 받아쓰기와 도구 호출을 바이너리 하나로 묶어, 음성 명령 기능을 만드는 과정이 단순해집니다.
핵심 내용
- 영어, 독일어, 프랑스어, 스페인어, 이탈리아어, 네덜란드어, 폴란드어 7개 언어를 자동으로 가려 받아 적습니다.
- Apple M4 Pro CPU에서 10초 음성의 첫 토큰까지 11.1ms가 걸려, Whisper base(73.2ms)보다 빨랐습니다.
- 디코딩 속도는 초당 1,319토큰으로, Whisper base의 266토큰보다 5배 가까이 빠릅니다.
- LibriSpeech, Earnings-22 등에서는 Whisper base보다 오류율이 낮았지만 TED-LIUM, AMI, MLS에서는 뒤졌습니다.
- 단어별 타임스탬프와 키워드 부스팅(지정한 단어를 더 잘 알아듣게 하는 기능)을 지원하고, 한 번에 30초까지 처리합니다.
HN 반응
- 아마존 Echo Show를 개조한 이용자는 자유 받아쓰기는 부정확했지만 정해진 문장 틀로 좁히자 크게 나아졌다고 전했고, 구조가 있는 편이 낫다는 공감이 이어졌습니다.
- 용량보다 억양이나 발음 장애를 알아듣는 일이 더 큰 과제라는 지적에, 작은 모델의 가치는 개인정보와 지연을 지키는 기기 안 처리에 있다는 반론이 나왔습니다.
이게 여기 올라와 있다니 흥미롭네요. 저는 whistle(과 다른 여러 가지)을 써서 제 Echo Show를 완전히 제 소유로 만들었습니다. 이제는 Amazon에 전혀 연결하지 않고, 모든 처리를 기기 자체 CPU로 로컬에서 하면서 제 Home Assistant와 연결해 스마트홈을 제어합니다. 처음에는 RTX 5080에서 돌리는 Qwen ASR(1.7b 모델)로 구성했습니다. 그에 비하면 whistle은 정말 형편없었습니다(메시지 170개 중 Qwen은 168개를 맞게 인식했고 whistle은 70개). 그래서 whistle을 jev처럼 동작하도록 고쳤습니다. 자유 형식으로 받아 적는 대신 정해진 템플릿 집합 중에서만 인식하게 한 겁니다(생성한 발화 1만 개로 아주 작은 네트워크를 학습시켜, whistle의 최종 상태를 템플릿별 확률로 바꾸게 했습니다). 정확도가 164/170까지 올라서 Qwen과 거의 비슷해졌습니다. 참고로 저는 억양이 아주 심합니다.
또 CMU의 Sphinx4(Java)가 쓰이던 옛날로 돌아가는 기분이네요. 10년도 더 된 물건인데 기대보다 훨씬 잘 동작했습니다. 사용자가 유효한 단어의 문법과 다양한 흐름을 표준 형식(Java Speech API Grammar Format)으로 정의해 줘야 했죠. MCP가 정신적으로는 WSDL과 비슷한 역할을 하는 것처럼, 이런 모델들에도 그 방식이 다시 돌아올지 궁금합니다. whistle이 그렇게 잘 동작한다니 대단하네요!
제 문장들로 방금 테스트를 몇 가지 돌려 봤습니다.
아래는 아직 Echo Show에서는 테스트하지 않았고, 일단 제 PC에서 돌린 결과입니다.
Vosk small, 문장 문법 사용: 184/208
Speech-to-Phrase 1.4.3 (Kaldi): 118/208
추천해 주신 Sphinx: 63/208, 일부 예시는 i7 14700k PC에서 13초나 걸렸습니다.
제 용도에는 제가 손본 whistle이 이런 대안들보다 낫다고 봅니다. 그래도 테스트를 더 해서 나쁠 건 없겠죠.
원글 작성자는 아니지만, 연결 고리는 "정해진 템플릿 집합"보다는 문법이 아닐까 싶습니다. 기반 기술이 뭐든 구조가 있는 쪽이 구조가 없는 쪽을 이긴다는 얘기고, 어차피 구조가 전혀 없는 상호작용은 대개 우리가 원하는 것도 아니니까요.
WSDL이라니, 정말 오랜만에 듣는 이름이네요!
XML 웹 서비스는 대단했지만, SOAP와 XML(원래라면 기본값을 갖춰서 제공했어야 할 어려운 부분들)이 극복하기엔 너무 무거운 닻이었다고 봅니다.
그러다 루비/레일즈 물결이 오면서 'REST' JSON이 실리콘밸리의 연인이 됐고, WSDL은 어제 내다 버린 쓰레기처럼 밀려났죠.
지금도 현업에서 쓰냐고요? 씁니다! 제가 다니던 회사는 아마(아마도) 지금쯤 벗어났겠지만, 2023년까지도 은행 쪽 연동에는 SOAP RPC .asmx 엔드포인트 서버를 쓰는 강력한 곳들이 있었습니다.
저는 hypermedia.systems와 htmx/datastar/alpine.js를 따라가고 있는데, 모든 걸 자바스크립트 클라이언트 쪽 우회책에 욱여넣는 대신 그 강력했던 웹 기술의 발전을 되찾고 싶어서입니다. Typescript는 훌륭합니다. 가난한 사람의 F#이라 할 만하고 ES3보다는 한참 앞서 있죠(제가 ES3를 만지작거리기도 하고, 오래된 레트로 컴퓨터도 웹 작업을 할 수 있게 LLM을 괴롭히기도 합니다). 하지만 오래된 기기에는 더 가볍게 만들 수 있었을 짐을 여전히 너무 많이 끌고 다니고, 원래 웹이 약속했던 기술 유토피아와도 맞지 않습니다(제가 컴퓨터를 갖고 노는 이유의 절반이 그것입니다).
폴란드는 WSDL, SOAP, XML Schema, XSLT, XML Forms, 그러니까 전부 다 써서 돌아갑니다.
법에 따르면 제출할 수 있는 모든 정부 서식은 중앙 등록부에 XML Schema가 마련되어 있어야 합니다. 다만 실제로는 이 규정이 널리 무시되고 있고, 특히 지방 정부와 지자체가 그렇습니다.
예전에는 이게 더 중요했습니다. 그런 서식이면 EPUAP 서식 카탈로그에 자동 또는 반자동으로 항목이 생기고 전자 방식으로 작성할 수 있게 되었기 때문입니다(EPUAP는 지금은 폐기된, 정부 행정을 위한 중앙 포털입니다). 제가 이해하기로 그 방식은 XSLT와 XML Forms를 통해 돌아갔습니다. 문서마다 작성용 화면과 미리 보기가 따로 있다는 점이 좀 이상했는데, XML Forms는 어떤 식으로든 XHTML 서식을 만드는 데 쓰였고, XSLT 스타일시트는 작성이 끝난 완성본의 XHTML 미리 보기만 만들 수 있었던 것으로 알고 있습니다. 자동 입력을 위한 맞춤 주석도 있었는데, 이는 대부분의 문서가 "사람", "주소", "회사" 같은 개체에 표준화된 스키마를 쓰는 덕분에 부분적으로 가능했습니다.
E-Deliveries로 옮겨 가면서 이런 서식을 모아 둘 중앙 장소가 없어졌기 때문에, 제가 아는 한 중요성이나 사용 빈도는 다소 줄었습니다. 하지만 내부적으로는 여전히 전부 XML입니다. 신분증 갱신 신청서 같은 걸 더 새롭고 사용자 친화적인 프런트엔드로 제출하더라도, 그 밑바닥은 그냥 XML입니다. podpis.gov.pl(정부 문서용 표준 전자서명 솔루션)에서 무언가에 서명하면, 그 밑에 깔린 문서를 서명한 것과 서명하지 않은 것 모두 내려받아서 그 XML이 어떤 모습인지 볼 수도 있습니다. 그 사이트가 만들어 주는 서명 전 문서 미리 보기도 아마 XSLT에서 나오는 걸로 압니다. 서명 자체도 당연하다는 듯이 XML 서명 규격으로 합니다.
덧붙이면, 유럽의 E-Delivery 시스템 자체도 XML, WSDL, SOAP에 상당히 크게 의존합니다. 잘 모르거나 유럽에 살지 않는 분을 위해 설명하면, 기본적으로 "정부를 위한 이메일"입니다. 실물 우편과 똑같은 보증과 법적 의무가 있고, 암호학적으로 증명되는 수신 확인, 제대로 된 신원 확인과 보증, 제공자 간 주소 이동성을 갖췄습니다. 많은 EU 국가에서 크든 작든 도입되어 있고 실물 우편을 대체할 예정입니다.
저는 parakeet이 아주 좋고 꽤나 빠르다고 느꼈습니다. 20~50ms 정도에, 테스트를 돌릴 때마다 정확도는 10개 중 9개쯤이었어요. 실제로 쓸 때는 오류율이 별 문제가 안 되는데, 출력을 GLM 5.3에 넘기기 때문에 "weather" 대신 "heather"가 들어와도 알아서 눈치껏 처리하거든요.
다만 훨씬 큽니다. 풀 프리시전으로 받은 것 같은데 2GB쯤 됩니다.
이 대목에서 웃음이 나왔어요. 글 쓰는 스타일 때문에 댓글을 읽는 내내 제 머릿속 목소리도 억양이 있었거든요.
죄송합니다, 호기심 많은 비원어민입니다. 어떤 억양이었나요? 그리고 어떤 특징 때문에 그런 생각이 드셨나요?
질문 받으신 분은 아니지만, "I trained tiny network" 같은 문장을 보면 저는 러시아어 억양이 떠올라요. 관사 "a"가 빠져 있어서요. "I'm speaking with heavy accent"도 마찬가지고요.
저는 원어민이 아닌데, 제 머릿속 목소리도 금방 러시아어 억양으로 바뀌었어요!
영어에서 관사가 빠져 있으면 보통 러시아어 같은 슬라브어가 모국어인 사람이라는 티가 납니다.
저는 헝가리어가 모국어인데, 저희는 정반대로 티가 납니다. 있어야 할 것보다 정관사가 더 많이 들어가거든요. 헝가리어에서는 영어보다 훨씬 자주 쓰는데, 그걸 영어에서 정말 못 다룹니다.
죄송한데요, 좀 더 천천히 써 주실 수 있나요? 못 알아듣겠어요.
영화 "어 퓨 굿 맨" 끝부분에 나오는 제셉 대령의 연설을 넣어 봤는데, 이런 결과가 나왔습니다.
좀 섬뜩합니다. "can't handle"이 "can handle"로 나온 건 제 발음 탓일 수도 있지만, "guns" 대신 "cannons"가 나온 건 순수한 환각이고 "those walls"가 "all those walls"가 된 것도 마찬가지입니다. 그러니 발언 내용을 충실히 받아 적은 기록이 필요할 때는 이걸 믿고 쓰지 않는 편이 좋겠습니다.
(참고로 원문은 이렇습니다. "You can't handle the truth. We live in a world that has walls, and those walls have to be guarded by men with guns." 즉 "당신들은 진실을 감당하지 못한다. 우리는 벽이 있는 세상에 살고, 그 벽은 총을 든 사람들이 지켜야 한다.")
음성 인식의 난관이 바이너리 크기였다고는 생각하지 않습니다. 제 경험상 어려운 건 뇌졸중 이후 입이 처지신 84세 크로아티아인 아버지가 자서전을 쓰려고 하실 때 그 말을 알아듣는 일입니다.
지난주에 아버지께 윈도 음성 인식을 설정해 드렸는데, 키보드로 며칠 걸릴 분량을 10분 만에 한 페이지 가득 쓰시는 걸 보니 정말 좋습니다.
다만 입으로 내시는 소리가 하나도 빠짐없이 전부 페이지에 찍혀 나옵니다.
아버님 일은 안타깝습니다. 필요한 건 범용 음성 인식 모델이 아니라 받아쓰기(dictation) 모델입니다. 그런 모델은 "음", "어" 같은 군말을 무시하고, "원숭이가 아니라 코끼리가, 아니 원숭이가 나무에 올라갔다" 같은 말도 "원숭이가 나무에 올라갔다"로 고쳐 주고, 때로는 구두점을 소리 내어 말하는 것도 지원합니다.
Gemini 팀이 얼마 전 이런 용도에 강하다는 Gemini 3.5 Transcribe를 내놨습니다. API로 쓸 수 있습니다. https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5-transcribe/
사실상 무한하고 빠른 받아쓰기가 필요할 때는 Parakeet 스트리밍에 https://github.com/cjpais/Handy 를 씁니다(cohere가 훨씬 낫지만 더 느리고 토큰 출력 제한이 있어서 몇 분씩 길게 떠들 수는 없습니다). 그런 다음 값싼 LLM으로 정리 작업을 한 번 돌립니다. 제 경험상 음성 명령으로 문장을 고치거나 단어를 바꾸려는 것보다 훨씬 낫습니다. 저는 지시 사항을 글 중간중간에 그냥 엮어 넣습니다. 기술 지식이 필요하다는 건 압니다. 하지만 그런 지식이 있는 분께는 손을 쓰지 않고 긴 글을 쓸 수 있는 방법 중 제가 찾은 최고의 해법입니다.
저는 오늘 마침 이 두 가지를 한 패키지로 해 주는 받아쓰기 앱의 v0.1을 올렸습니다. 값싼 LLM 어느 쪽과도 연결할 수 있지만, 기본 설정은 Qwen3.5 9b를 쓰게 해 뒀습니다. 무료로 일을 잘 해내고 모든 게 로컬에 남으며 텔레메트리도 없습니다. Claude/OpenAI/로컬 제공자도 쓸 수 있습니다. https://github.com/lnenad/lipwise
모양새가 마음에 들긴 하는데, 계속 쓰려면 제가 포팅을 해야 할 것 같습니다. 안드로이드에서 주로 Python으로 만드는 프로젝트가 있는데 STT가 있으면 좋겠거든요.
voice ink와는 뭐가 다른가요?
오픈 소스고, 여러 플랫폼에서 돌아갑니다.
4~5년 된 RAM 8GB 노트북에서도 AI 처리가 빠르게 돌아가나요, 아니면 자원을 적게 먹나요?
사양이 낮은 기기에서는 클라우드 모델을 쓰는 편이 훨씬 낫습니다. 그래도 Qwen3.5 4B라면 일을 해낼 수 있고, 오래된 기기에서도 충분히 빠릅니다.
저도 Handy를 한 번 더 추천하고, 멋진 기능 하나를 공유하고 싶습니다.
"눌러서 말하기" 모드(무전기처럼)를 설정해 두면, 말을 마치고 버튼에서 손을 떼는 순간 어떤 텍스트 입력란에든 글을 붙여 넣어 줍니다.
심지어 Handy를 음성 입력으로 쓰고 (확장 이름은 까먹었는데) OpenCode에 음성 인식 모델을 켜서 ChatGPT 음성 대화 모드를 그대로 재현할 수도 있습니다. 웹사이트 스타일을 다듬는 것 같은 작업에는 놀랄 만큼 편안한 흐름입니다.
Handy 정말 좋아합니다. 이제는 제가 컴퓨터를 쓰는 방식의 핵심이 됐어요.
혹시 쓰시는 분께 도움이 될까 해서 덧붙이면, 처음엔 좀 느리게 느껴졌습니다. 말을 끝내고 나서 눈에 띄게 멈칫하다가 한꺼번에 빠르게 타이핑되는 식이었거든요. 입력 방식을 direct에서 clipboard로 바꿨더니 훨씬 빨라져서 거의 즉각적입니다.
저는 Gemini Desktop App을 오로지 받아쓰기용으로 쓰고 있어요. 기적이에요! 평생 처음으로 제 (심한 억양의) 말을 이렇게 잘 알아듣는 데 감탄했습니다. 다만 "창에 말하기 -> 추론" 옵션은 꼭 꺼서 순수한 받아쓰기로만 쓰세요. 그래야 이메일을 통째로 대신 써 주는 걸 막을 수 있습니다.
이런 작은 모델의 쓸모는 온디바이스 STT/TTS를 더 쉽게 쓸 수 있게 하는 데 있습니다. 프라이버시나 지연 시간에 민감한 용도라면 중요한 일이지만, 그 대가로 품질을 내줘야 합니다.
제 경험상 이런 작은 TTS 모델은 오디오가 학습 분포 안에 있으면(서구권 억양, 높은 음질, 흔한 어휘) 뜻밖에 좋지만, 그 바깥으로 나가면 꽤 빠르게 나빠집니다. 화자 분리, 다국어, 실시간 스트리밍 같은 더 복잡한 기능도 대개 지원하지 않습니다.
그게 이 문제에서 아주 설득력 있는 부분입니다.
모델을 일정 크기 문턱 아래로 줄일 수 있다면 지연 시간의 영역 자체를 없앨 수 있습니다. 예를 들어 모델이 L3 안에 통째로 들어가면, L3+DRAM에 걸쳐 있는 모델에 비해 요청 처리 지연 시간이 한 자릿수 배(또는 그 이상) 줄어듭니다.
L3가 DRAM보다 지연 시간이 한 자릿수 배 낮은 건 맞습니다. 하지만 시스템 전체로 놓고 보면 그 차이는 지연 시간보다는 처리량 차이로 나타나는 경우가 대부분입니다.