옴니모달 음성 입력: 멀티모달 이해, MoE, 스트리밍 텍스트 출력

저는 Loqua.ai의 창립자 Shuran이에요. 이 글은 우리의 옴니모달 음성 입력 스택 뒤편의 깊은 엔지니어링 노트예요 — 왜 어쿠스틱 인식을 멀티모달 과제 이해와 텍스트 렌더링에서 분리하는지, 조건부 전문가가 어디서 도움이 됐고 어디서 그렇지 않았는지, 그리고 왜 스트리밍이 거의 모든 아키텍처 선택을 좌우했는지.

왜 모놀리식 오디오 LM이 맥의 벽에 부딪히는가

모놀리식 오디오 언어 모델은 종이 위에서는 매력적이에요. 오디오, 화면 프레임, 텍스트를 하나의 큰 모델에 넣고 최종 받아쓰기를 내놓으라고 시키는 거죠. 일상 맥 사용에서 이 설계는 세 가지 벽에 동시에 부딪혀요. 첫째, 레이턴시 예산이 잔혹해요. 화자가 잠시 멈춘 뒤에 첫 유용한 토큰이 도착한다면, 음성 입력은 타이핑이 아니라 배치 받아쓰기처럼 느껴져요.

저희가 스스로에게 부과하는 예산은 이래요. 마이크에서 처음 보이는 글자까지 약 200밀리초가 있어요. 그중 대략 40ms는 플랫폼 오버헤드(Core Audio 버퍼링, 프로세스 간 전달, 최종 렌더링)이고, 60ms는 어쿠스틱 특징 추출과 프론트엔드 추론, 70ms는 첫 부분 결과를 위한 인스트럭션 플래너 디코딩, 그리고 30ms가 텍스트 렌더러가 안전한 조기 커밋을 내놓을 시간으로 남아요. 모든 단계를 1B+ 파라미터의 단일 오디오 LM이 그 창 안에서 돌리는 건 벤치마크 머신에서는 가능해 보여도, 브라우저, IDE, Zoom이 이미 돌아가는 실제 노트북에서는 불안정해요.

둘째, 사용자에게 보이는 일은 단순한 자동 음성 인식이 아니에요. 같은 발화가 Slack 문단이 되거나, Git 커밋 제목이 되거나, Cursor 프롬프트가 되거나, 파이썬 주석이 되어야 해요. 모놀리식 모델이 그걸 다 하도록 학습될 수는 있지만, 매 앱마다 포맷 컨벤션을 다시 학습해야 하고 커서가 움직일 때마다 다시 추론해야 해요. 셋째, 모델은 노트북의 열·메모리 한계 안에 머물러야 해요. IDE 인덱스 옆에 7B 오디오-비전-텍스트 모델을 VRAM으로 스왑하는 건 열 쓰로틀링과 시끄러운 팬 소리의 레시피예요. Whisper나 최근 옴니 모델 보고서 같은 공개 연구는 분야가 견고한 오디오 및 멀티모달 모델링을 이해하도록 도왔지만, 로컬 제품을 출시하려면 더 좁고 의견 있는 선택을 해야 해요.

저희 결론은 단순했어요. 옴니모달 음성 입력은 단일 만능 블록이 아니라 파이프라인이어야 한다. 파이프라인은 각 레이어가 작은 목표, 측정 가능한 실패 모드, 한정된 런타임 비용을 유지하게 해줘요.

멀티모달 인스트럭션 파이프라인

Loqua의 이 제품 경로에는 음성 응답이나 TTS 레이어가 없어요. 인스트럭션 플래너는 스트리밍 오디오 특징, 선택된 화면 컨텍스트, 활성 앱 메타데이터, 커서 주변의 최근 텍스트, 그리고 활성 인스트럭션 프롬프트를 소비해요. 그것이 컴팩트한 텍스트 출력 계획을 만들어요 — 의도, 엔터티, 편집 모드, 목표 포맷, 불확실성.

텍스트 렌더러는 그 계획을 텍스트로 변환해요. 오디오, 음성 응답, TTS 출력을 생성하지 않아요. 계획이 마크다운 체크리스트가 될지, 문장이 될지, 코드 주석이 될지, 구조화된 지시가 될지 결정해요. 이 분리는 사용자가 그냥 산문을 받아쓰고 있을 때 비싼 크로스 모달 추론을 핫 패스 밖에 두게 해줘요.

각 레이어가 하지 말아야 할 것

훈련의 핵심은 우리가 제거한 것에 있어요. 어쿠스틱 프론트엔드는 목적지 포맷에 대해 똑똑해지려 하지 않아요 — 타이밍과 신뢰도를 가진 오디오 토큰을 내놓을 뿐이에요. 인스트럭션 플래너는 최종 산문을 쓰지 않아요 — 저렴하게 수정할 수 있을 만큼 작은 구조화된 계획을 만들어요. 텍스트 렌더러는 오디오를 다시 읽거나 음성을 합성하지 않아요 — 계획, 목적지 컨텍스트, 인스트럭션 프롬프트를 신뢰해요. 어느 레이어든 이 경계를 넘게 두는 것이 초기 프로토타입에서 가장 흔한 레이턴시 회귀 원인이었어요. 크로스 레이어 피드백 루프는 트레이스를 읽기 전까지 아무도 모르는 사이에 스트리밍을 배치 처리로 바꿔놓거든요.

이점은 디버깅 가능성이에요. 출력이 잘못되었을 때, 인식기가 잘못된 단어를 들었는지, 인스트럭션 플래너가 잘못된 의도를 골랐는지, 텍스트 렌더러가 잘못된 어조로 썼는지를 알 수 있어요. 그게 길고 숨겨진 단일 궤적을 해석하는 것보다 훨씬 쉬워요. 사내 트리아지에서, 출시 후 품질 수정의 약 3분의 2는 단일 레이어로 깔끔하게 격리됐고, 나머지는 크로스 레이어 변경이 필요했지만 진단이 명확해진 뒤에야 가능했어요.

오디오 인코더의 MoE

오디오 인코더가 조건부 연산이 빛을 발한 곳이에요. 모든 발화가 같은 어쿠스틱 처리를 필요로 하는 건 아니에요. 조용한 음성, 억양 있는 영어, 영어와 중국어 혼합, 코드 식별자, 회의실 배경 잡음이 모델의 서로 다른 부분에 부담을 줘요. 작은 MoE 라우터는 인코더가 어려운 영역에 더 많은 용량을 쓰게 해주면서, 매 프레임을 비싸게 만들지 않아요.

라우팅은 보수적으로 유지했어요. 라우터는 개인 사용자 프로필이 아니라 어쿠스틱 통계와 얕은 어휘 힌트를 조건으로 해요. 전문가들은 저음량 음성, 빠른 기술 받아쓰기, 코드 스위칭 같은 패턴에 특화돼요. 더 큰 전문가 풀은 거절했어요 — 라우팅 불안정성이 스트리밍 동작을 악화시켰거든요. 정확하지만 발화 도중 스타일이 바뀌는 모델은 타이핑에 쓸 수 없어요.

시도했다가 버린 것들

연구에서는 매력적이었지만 제품에서는 실패한 두 가지 아이디어. 첫째, 사용자별 전문가 적응 — 헤비 유저별로 작은 어댑터를 학습. 내부 테스트 세트에서 콜드 스타트 정확도를 몇 포인트 올렸지만, 콜드 런치 메모리 풋프린트를 두 배로 만들고 프라이버시 경계를 흐릿하게 만들었어요. 둘째, 활성 앱 식별자를 강한 신호로 받는 라우터. 흔한 앱 몇 개에 과적합되고 새 앱에서는 조용히 성능이 떨어졌어요. 현재의 어쿠스틱·어휘 라우터로 교체했고, 앱 인식 동작은 인스트럭션 플래너와 텍스트 렌더러로 끌어 올렸어요. 거기가 제자리거든요.

실용적으로 보면, 오디오 인코더 MoE는 Loqua가 공통 경로를 빠르게 유지하면서 꼬리(tail)는 덜 부서지게 만들어줘요. 그게 제품의 가치예요 — 벤치마크 트릭이 아니라, 라이브러리 이름, 조용한 구절, 이중 언어 조각이 흐름을 깨는 순간이 줄어드는 것.

스트리밍: 토큰 단위 vs 구절 단위

스트리밍은 가장 어려운 트레이드오프였어요. 토큰 단위 출력은 반응적으로 느껴지지만, 성급한 추측을 드러낼 수 있어요. 구절 단위 출력은 더 깔끔하지만 늦게 느껴져요. 우리는 하이브리드를 써요. 저위험 구간에는 이른 부분 결과를, 화면 컨텍스트가 필요한 엔터티와 편집에는 지연된 커밋을.

예를 들어 "change the fetch profile function to return early if the auth client is missing"라고 말하면, 시스템은 평범한 단어들을 빠르게 스트리밍할 수 있어요. 하지만 fetchProfile과 authClient 주변 토큰은 컨텍스트 레이어가 보이는 식별자를 확인할 때까지 기다려요. 텍스트 렌더링이 인식에서 분리된 이유가 이거예요 — 텍스트를 커밋하기 전에 작은 구간을 수정할 수 있고, 전체 발화를 다시 시작할 필요가 없어요.

문장 중간의 이중 언어 입력도 비슷한 케이스예요. "把这个 retry 函数改成指数退避"라고 말하면, 인스트럭션 플래너는 중국어 구간과 영어 코드 토큰 하나를 엮은 텍스트 출력 계획을 만들어요. 텍스트 렌더러는 중국어 글자가 내부 신뢰도 임계값을 넘으면 바로 내놓고, 영어 식별자에 대해서는 보이는 IDE 버퍼와 대조해 확인할 몇 밀리초를 더 기다려요. 사용자는 중국어 흐름을 먼저 보고, 그다음 식별자, 그다음 나머지를 봐요. 출력 순서를 재정렬하면 더 빨랐겠지만 이상하게 느껴졌어요. 눈은 왼쪽에서 오른쪽으로 가는 타이핑을 기대하니까요.

커밋 경계는 또 다른 다이얼이에요. 커밋 경계는 텍스트 렌더러가 더 이상 수정하지 않겠다고 약속하는 순간이에요. 자연스러운 멈춤, 문장 종결자, 문단·리스트 항목·코드 블록 같은 구조 전환에 그것을 박아둬요. 커밋 경계 안에서는 텍스트 렌더러가 자유롭게 수정할 수 있고, 일단 커밋되면 사용자 관점에서는 텍스트가 최종이에요. 그 계약이 스트리밍을 떨림이 아니라 정직하게 느껴지게 해줘요.

결과는 즉각적으로 느껴지지만 모든 이른 어쿠스틱 추측을 최종으로 다루지 않는 스트리밍 음성 스택이에요. 음성 입력에서는 그 타협이 원시 받아쓰기 속도보다 더 중요해요.

공개 연구 컨텍스트

우리는 공개 연구를 가까이 따라가요. 제품에서 보는 문제들에 대한 어휘를 날카롭게 해주거든요. 오디오-언어 모델링, 멀티모달 인코더, 선호 최적화에 관한 논문들과 보고서들은 분야가 책임 분할, 스트리밍 제약, 크로스 모달 정렬로 수렴하고 있음을 보여줘요. 배경을 위해 Whisper, Qwen2 기술 보고서, 공개된 Qwen2.5-Omni 개요부터 시작해 보세요.

중요한 제품 경계: 이 참고문헌들은 문헌 컨텍스트예요. Loqua의 프로덕션 스택은 맥 받아쓰기를 위해 사내에서 학습되고 최적화된 독자 연구예요. 공개 연구를 인용하는 건 분야를 설명하기 위함이지 출처를 시사하려는 게 아니에요.

우리가 만든 것과 다음 단계

이 방향에서 출시된 것은 좁은 시스템이에요 — 듣고, 로컬 화면 컨텍스트를 읽고, 앱 인식 텍스트를 적는 맥 음성 입력. 다음 작업은 더 엄격한 평가예요. 레이턴시, 기술 NER, 다국어 WER, 화면 컨텍스트 모호성 해결에 대한 공개 방법론이 필요해요. 그래야 도그푸딩 루프 바깥에서도 주장이 리뷰될 수 있어요.

두 번째 방향은 더 나은 캘리브레이션이에요. 모델이 보이는 식별자에 대해 불확실할 때, 안전한 출력 형태를 고르거나 원시 구절을 보존해서 사용자에게 덜 요구해야 해요. 텍스트 렌더러에 가벼운 불확실성 마커를 두는 것도 탐색 중이에요. 그러면 다운스트림 UI가 받아쓰기 리듬을 깨지 않으면서 낮은 신뢰도 구간을 키보드로 빠르게 교정할 수 있도록 강조 표시할 수 있어요.

세 번째 방향은 비단어(non-word) 오디오예요. 그 작업은 아직 프로토타입 단계이고, 의미를 가진 소리에서 별도로 다뤄요. 강화 학습과 멀티모달 리스너 작업과 함께, 이건 우리 옴니모달 음성 입력 스택의 다음 1년 어젠다를 이뤄요.