VibeVoice가 한국어 회의를 실시간으로 나눈다…가중치도 공개됐다

Microsoft Research 연구진이 2026년 9월 2일 VibeVoice-ASR-Streaming 기술 보고서와 1.5B·7B 가중치, 추론 코드를 공개했다. 9월 2일 제출된 기술 보고서 는 고정 길이 음성 조각과 제한된 미래 문맥을 읽어, 녹음이 끝나기 전부터 별도 화자 분리 단계 없이 발화 내용과 화자 표지를 함께 생성하는 모델이라고 설명한다.

한국어 지원과 공개 배포도 확인됐다. Microsoft의 공식 배포 페이지 에는 한국어를 포함한 10개 언어, MIT 라이선스, Safetensors 가중치가 표시돼 있다. 다만 모델 이름의 ‘7B’와 페이지가 집계한 전체 크기 ‘9B params’는 측정 범위가 다른 수치다.

음성 조각 안에서 발화와 화자를 함께 생성한다

VibeVoice-ASR-Streaming은 음성 인식 결과와 화자 정보를 하나의 자기회귀 생성 과정에서 출력한다. 음성을 먼저 전사한 뒤 별도 diarization 모듈의 화자 구간과 결합하는 전통적인 파이프라인과 달리, 현재 음성 조각에 대응하는 문장을 화자 표지와 함께 직접 만든다. 제목의 ‘회의를 나눈다’는 표현은 음원을 물리적으로 분리한다는 뜻이 아니라 발화를 화자별 텍스트로 귀속한다는 의미다.

입력 음성 조각과 그 조각의 화자 포함 전사문은 하나의 문맥 안에서 번갈아 배치된다. 앞서 들은 음성, 이미 생성한 문장, 이전에 붙인 화자 번호가 다음 조각을 처리할 때도 남기 때문에, 초반에 등장했던 사람이 뒤에 다시 말하면 기존 번호를 재사용할 수 있다. 화자 번호는 실제 이름이 아니라 처음 등장한 순서에 따라 정해지는 표지다.

공개된 체크포인트는 2.9초 음성 조각 뒤에 0.5초의 미래 음성을 추가로 살핀다. 이 구성에서 제시된 화자 귀속의 예상 알고리즘 지연은 2.00초다. 따라서 여기서 실시간은 단어가 발음되는 즉시 결과가 확정된다는 뜻이 아니라, 녹음 종료를 기다리지 않고 수 초 단위로 화자 포함 전사가 이어진다는 의미에 가깝다.

동시 발화도 별도의 병렬 음성 트랙으로 분리되지는 않는다. 직렬화된 출력 안에서 겹친 발화를 연속된 화자 표시 구간으로 내보내므로, 여러 사람이 자주 말을 겹치는 회의에서는 문장 인식과 화자 귀속을 따로 봐야 한다. 한 화자의 문장을 정확히 받아쓰더라도 다른 화자 번호에 배정될 가능성은 남는다.

한국어는 지원하지만 국내 회의 성능을 보장하지는 않는다

지원 언어는 중국어, 영어, 프랑스어, 독일어, 이탈리아어, 일본어, 한국어, 포르투갈어, 러시아어, 스페인어다. 한국어는 단순한 저장소 태그에만 포함된 것이 아니라 공개 평가의 MLC-Challenge 항목에도 들어갔다. 중국어·일본어·한국어는 단어 오류율 대신 문자 오류율인 CER와 화자 귀속을 반영한 cpCER로 평가됐다.

7B 백본과 2.9초 조각을 사용한 공개 표에서 한국어 결과는 인식 전용 CER 9.09, 화자 귀속을 포함한 cpCER 23.22로 제시됐다. 두 값의 차이는 문자를 맞히는 능력과 그 문장을 올바른 화자에게 배정하는 능력이 같은 문제가 아님을 보여준다. 수치는 연구진이 정한 데이터와 최대 480초의 평가 조건에서 나온 결과이므로 국내 기업 회의의 정확도로 그대로 옮겨 읽을 수 없다.

회의 전용 평가 코퍼스도 언어별로 구분할 필요가 있다. AISHELL-4와 AliMeeting은 중국어 회의 자료이고, AMI는 영어 회의 자료다. 한국어 수치는 한국 기업 회의 전용 코퍼스가 아니라 여러 언어의 대화 음성을 모은 MLC-Challenge에서 나온 값이어서, 한국어 회의실의 원거리 마이크나 사내 용어까지 검증했다고 볼 근거는 없다.

한국어 회의에서 남는 핵심 변수는 겹침 발화, 비슷한 음색의 참석자, 마이크와의 거리, 고유명사와 약어다. 모델은 이름·기술 용어·약어 같은 맞춤형 문맥 정보를 미리 전달하는 기능을 제공하지만, 특정 단어를 넣는 것만으로 화자 귀속까지 개선된다고 공개 결과가 입증한 것은 아니다. 전사 정확도와 화자 번호의 안정성을 분리해 해석해야 하는 이유다.

모델명의 7B와 배포 페이지의 9B는 같은 숫자가 아니다

기술 보고서에서 1.5B와 7B는 학습 가능한 Qwen2.5 언어모델 백본의 규모를 구분한다. 반면 Hugging Face 배포 페이지는 VibeVoice-ASR-Streaming-7B 저장소의 모델 크기를 9B 파라미터로 표시한다. 공개 자료만으로 정확한 집계 차이를 모두 분해할 수는 없지만, 백본 규모와 배포 체크포인트 전체의 집계값을 같은 범위의 수치로 취급해서는 안 된다.

배포 파일은 BF16 형식의 Safetensors 여덟 조각으로 제공되며 저장소에 표시된 전체 파일 규모는 약 17.4GB다. 이는 공개 가중치를 내려받아 자체 환경에 구성할 수 있다는 뜻이지만, 현재 이 모델은 Hugging Face의 추론 제공자에 배치돼 있지 않다. 가중치 공개와 준비된 웹 API 제공은 서로 다른 배포 상태다.

MIT 라이선스는 코드와 모델을 로컬 환경에 배치하고 수정·통합할 수 있는 여지를 제공한다. 그러나 라이선스가 회의 녹음 동의, 개인정보 처리, 음성 원본과 전사문 보관 정책까지 해결해 주지는 않는다. 로컬 실행을 택하더라도 저장 위치와 접근 권한은 배포 조직이 별도로 정해야 한다.

로컬 실행은 CUDA 환경과 실제 메모리 측정이 필요하다

현재 공개 형태는 완성된 소비자용 회의 앱보다 개발자가 체크포인트와 코드를 직접 구성하는 단계에 가깝다. 9월 3일 공개된 독립 실행 가이드 는 공식 설치 경로가 NVIDIA PyTorch Container와 CUDA GPU를 중심으로 하며, 소비자용 GPU별 최소 VRAM은 제시되지 않았다고 정리했다.

공개 실행 경로에는 VibeVoice 저장소 설치와 음성 디코딩용 ffmpeg가 필요하고, 환경에 따라 FlashAttention을 추가한다. FastAPI 데모는 브라우저와 WebSocket 연결을 유지하면서 마이크 또는 음성 파일을 받고 조각별 결과를 갱신한다. 일반 사용자가 설치 파일 하나로 실행하는 제품이나 CPU 전용 스트리밍 앱으로 공개된 상태는 아니다.

필요한 GPU 메모리는 모델 이름의 7B만으로 계산하기 어렵다. BF16 가중치 외에도 음성 인코더, 어텐션 구현, CUDA·PyTorch 런타임 버퍼, 문맥 길이와 동시 스트림 수가 최고 사용량에 영향을 준다. 과거 음성과 화자 기록을 압축하지 않은 채 문맥에 유지하는 구조여서 계산량과 메모리 비용은 세션이 길어질수록 늘어난다.

공개 체크포인트가 목표로 하는 녹음 길이는 최대 8분이다. 논문의 2.00초 지연도 음성 조각 길이와 미래 문맥에서 계산한 예상 화자 귀속 지연으로, 특정 GPU에서 디코딩과 화면 표시까지 포함해 측정한 종단 간 응답 시간이 아니다. 한국어 회의 도입 여부를 판단하려면 짧은 샘플의 첫 출력뿐 아니라 세션이 이어질 때의 누적 지연과 최고 VRAM을 함께 확인해야 한다.

현재 확인된 범위는 한국어 입력, 녹음 중 화자 포함 전사, 공개 가중치와 추론 코드, MIT 라이선스까지다. 반면 한국어 기업 회의 전용 성능, 소비자 GPU별 최소 메모리, 8분을 넘는 회의의 화자 일관성과 종단 간 지연에 관한 독립 측정은 아직 제시되지 않았다. 공개 모델이라는 사실은 분명하지만, 장시간 한국어 회의에 바로 투입할 수 있는 완성형 서비스로 단정할 단계는 아니다.