개요

MOSS-Transcribe-Diarize

0.9B는 OpenMOSS-Team이 구축한 엔드투엔드 (end-to-end) 멀티모달 거대 언어 모델 (multimodal large language model)로, 단 한 번의 패스 (single pass)로 음성 전사 (speech transcription), 화자 분리 (speaker diarization), 타임스탬프 생성 (timestamp generation)을 동시에 수행합니다. 이 모델은 Qwen3-0.6B 스타일의 인과적 디코더 (causal decoder)와 Whisper-Medium 오디오 인코더 (audio encoder)를 결합하였으며, masked_scatter 연산을 사용하여 오디오 특징을 텍스트 백본 (text backbone)에 융합하는 4x 시간적 병합 (temporal merge) + MLP 어댑터 (adaptor) 브릿지를 통해 연결됩니다. 이 모델은 최대 90분 길이의 오디오 입력을 처리할 수 있는 128k 컨텍스트 윈도우 (context window)를 지원하며, [S01] 및 [S02]와 같은 익명 화자 라벨과 정밀한 타임스탬프가 포함된 컴팩트한 화자 인식 전사본을 생성합니다. 모델은 trust_remote_code=True 옵션과 함께 transformers 라이브러리를 통해 로드되며, bfloat16 정밀도로 CUDA에서 실행되거나 float32 정밀도로 CPU에서 실행됩니다. 가중치(weights)와 커스텀 코드는 Hugging Face에서 사용할 수 있습니다.

최적의 사용 사례

회의 및 통화 전사 (Meeting and call transcription): 이 모델은 화자의 신원과 타이밍이 모두 중요한 실제 다중 화자 비즈니스 커뮤니케이션을 처리하는 데 탁월합니다. 배경 소음과 겹치는 음성이 포함된 회의 녹음은 별도의 ASR(자동 음성 인식) + 화자 분리 파이프라인에서 흔히 발생하는 실패 지점이지만, 방대한 야생 데이터 (wild data)에 대한 공동 엔드투엔드 학습과 128k 컨텍스트 윈도우 덕분에 이 모델은 컨텍스트 파편화 (context fragmentation)나 화자 라벨 혼동 없이 90분 세션 동안 화자 일관성을 유지할 수 있습니다.

팟캐스트 및 인터뷰 처리 (Podcast and interview processing): 긴 형식의 대화형 오디오는 중간 파이프라인 스티칭 (pipeline stitching) 없이 화자의 연속성을 추적하는 모델의 능력으로부터 이점을 얻습니다. 고정된 진행자와 교체되는 게스트가 등장하는 팟캐스트는 시간적 융합 (temporal fusion) 메커니즘이 긴 구간 동안 화자 기억을 유지하기 때문에 잘 처리되며, 음향 이벤트 인식 (acoustic event awareness) 기능은 단순한 음성 텍스트를 넘어 다운스트림 메타데이터 생성에 풍부함을 더해줍니다.

강의 및 교육 콘텐츠 (Lecture and educational content): 대학 강의, 웨비나 (webinar) 녹화본, 그리고 간헐적인 질의응답 (Q&A) 세션이 포함된 교육용 영상은 전사 (transcription) 정확도와 구조적 정보를 모두 얻을 수 있습니다. 타임스탬프 (timestamp) 출력은 정밀한 탐색과 챕터 생성을 가능하게 하며, 화자 분리 (speaker diarization) 기능은 수동 주석 작업 없이도 강사와 학생의 질문을 자동으로 구분합니다.

비디오 자막 생성 (Video subtitle generation): 이 모델은 오디오와 비디오 파일을 모두 수용하며, 포함된 자막 웹 앱을 통해 직접 자막 출력을 생성합니다. 이러한 워크플로우 (workflow)는 별도의 전사 및 화자 분리 단계를 거치지 않아 오류의 누적을 방지하며, FFmpeg 번인 (burn-in) 지원을 통해 VTT 또는 SRT 형식으로 단일 패스 (single-pass) 내보내기가 가능합니다.

음향 이벤트 기록 (Acoustic event documentation): 음성을 넘어, 모델은 프롬프트 (prompt)가 주어지면 음향 이벤트 주석을 생성할 수 있어, 비음성 오디오(배경 소음, 박수, 일시 정지)에 대한 메타데이터로 전사 내용을 풍부하게 만듭니다. 이는 단순히 말해진 단어뿐만 아니라 전체 음향 환경을 이해하는 것이 중요한 접근성 작업 및 콘텐츠 분석을 지원합니다.

한계점 (Limitations)

문맥 및 길이 제약 (Context and length constraints): 128k 컨텍스트 윈도우 (context window)는 상당한 수준이지만, 이는 일반적인 말하기 속도에서 약 90분 분량의 오디오에 해당합니다. 더 긴 녹음 파일은 전사 내용을 병합하기 위해 청킹 (chunking) 및 후처리 (post-processing)가 필요하며, 이 과정에서 경계 지점의 화자 라벨 재설정 및 타임스탬프 불연속성이 발생할 가능성이 있습니다.

청크 간 화자 라벨 일관성 (Speaker label consistency across chunks): 오디오가 컨텍스트 윈도우를 초과할 경우, 모델은 분할된 세그먼트 (segment) 간에 화자 정체성의 일관성을 유지할 수 있는 장기 기억력이 부족합니다. 여러 개의 출력 청크를 병합하려면 화자 라벨을 재정렬하기 위한 외부 로직이 필요하며, 이는 진정으로 끊김 없는 8시간 이상의 전사 결과물을 요구하는 애플리케이션의 복잡성을 증가시킵니다.

소음이 있거나 겹치는 음성에 대한 화자 분리 (Diarization) 정확도: AISHELL-4 및 Alimeeting에서의 지표는 강력하지만 (14.84 CER, 15.83 cpCER), 팟캐스트 데이터에서는 성능이 눈에 띄게 저하됩니다 (5.97 CER이지만 cpCER은 7.37에 불과함). 또한 cpCER과 CER 사이의 격차는 화자 경계 불일치 (speaker boundary misalignment)를 나타냅니다. 공동 학습 (joint training)에도 불구하고, 심한 화자 중첩 (speaker overlap), 교차 대화 (cross-talk), 또는 동시 대화는 모델을 혼란스럽게 만듭니다.

하드웨어 및 추론 속도 (Inference speed): 단일 H100 GPU는 단일 동시 요청 시 짧은 영화 시퀀스(2~10분)를 0.0612의 실시간 계수 (Real-Time Factor, RTF)로 처리하며, 이는 10분 길이의 클립을 처리하는 데 약 37초가 소요됨을 의미합니다. 긴 시퀀스 오디오 (AISHELL-4)의 경우 단일 요청 시 0.0197 RTF로 성능이 저하되어, 60분 길이의 파일은 거의 200초가 소요됩니다. 이는 실시간 전사 (real-time transcription)를 배제하며, 배치 처리 (batch processing) 또는 큐잉 (queueing) 인프라를 필요로 합니다.

언어 및 코덱 제한: 모델은 WhisperFeatureExtractor를 통해 16 kHz 샘플링 레이트와 80개의 멜-스펙트로그램 빈 (mel-spectrogram bins)으로 오디오를 처리하며, 이는 음성 대역 오디오로 제한됩니다. 비음성 오디오 분석은 얕으며, 음향 이벤트 (acoustic events)를 위해서는 수동 프롬프팅 (manual prompting)에 의존합니다. Qwen3 백본 (backbone)이 다국어를 지원할 수는 있지만, 명시적인 다국어 학습 세부 사항은 공개되지 않았습니다.

라이선스 및 상업적 이용: 모델은 Apache 2.0 라이선스로 출시되어 로열티 없이 상업적 이용, 수정 및 재배포가 가능합니다. 그러나 포함된 자막 웹 앱과 GitHub 유틸리티는 자체적인 종속성 라이선스 (PyTorch, torchvision, librosa)를 가지고 있으며, 이는 폐쇄형 소스 배포 (closed-source deployments) 시 반드시 준수해야 합니다.

안정성 및 후처리 오버헤드 (Post-processing overhead): 모델 출력은 화자 태그와 타임스탬프가 인라인으로 삽입된 단일 텍스트 문자열입니다 ([0.5][S01]Hello[2.3]). 이 형식을 파싱하려면 외부 유틸리티 (GitHub 패키지의 parse_transcript())가 필요하며, 화자 라벨 충돌이나 잘못된 형식의 타임스탬프와 같은 예외 상황(edge cases)에 대해서는 문서화되어 있지 않습니다. 이 모델은 성숙한 상용 시스템에 비해 실제 환경에서의 배포 사례가 제한적입니다.

비교 분석

MOSS-Audio-8B-Thinking은 전사 (Transcription)를 넘어 더 넓은 오디오 작업(음악 이해, 소리 분류, 감정 탐지)을 처리하는 더 큰 범용 오디오 이해 모델입니다. 만약 유일한 목표가 강력한 벤치마크 수치를 가진 화자 식별 전사 (Speaker-attributed transcription)라면 MOSS-Transcribe-Diarize를 선택하십시오. 멀티태스크 오디오 추론 (Multi-task audio reasoning) 또는 비음성 오디오 이해 (Non-speech audio understanding)가 필요하다면 MOSS-Audio로 전환하십시오. 이 경우 8B 파라미터 수로 인해 더 느린 추론 (Inference) 속도와 더 높은 VRAM 비용을 감수해야 합니다.

MOSS-Audio-4B-Instruct는 0.9B와 8B 변체 사이에서 범용성과 속도의 균형을 맞추며, 맞춤형 작업을 위한 오디오 지시 (Audio instructions)를 수용합니다. 혼합된 오디오 작업을 처리할 유연성이 필요하거나 도메인 특화 오디오 이해를 위해 미세 조정 (Fine-tune)을 원하는 경우 MOSS-Audio-4B를 사용하십시오. 반면, 순수 전사 정확도가 중요하다면 MOSS-Transcribe-Diarize를 고수하십시오. 0.9B 특화 아키텍처가 화자 분리 (Diarization) 지표에서 4B 모델보다 우수하기 때문입니다 (AISHELL-4에서 15.83 vs 더 높은 cpCER).

MOSS-Audio-8B-Instruct는 8B 모델의 지시어 미세 조정 (Instruction-tuned) 변체로, 프롬프트 기반의 오디오 이해 작업 제어를 가능하게 합니다. 전사와 더불어 화자 식별 (Speaker identification), 감정 탐지 (Emotion detection), 음악 태깅 (Music tagging)을 하나의 모델로 처리해야 한다면 MOSS-Transcribe-Diarize 대신 이를 선택하십시오. 만약 아키텍처의 유연성보다 처리량 (Throughput)과 전사 전용 성능이 더 중요하다면 MOSS-Transcribe-Diarize를 선택하십시오.

MOSS-TTSD-v0.5는 스크립트를 대화형 음성으로 변환하는 텍text-to-speech (TTS) 대화 모델로, 전사의 역과정입니다. 이 모델들은 상호 보완적입니다. 녹음 파일에서 대화를 추출하기 위해 MOSS-Transcribe-Diarize를 사용한 다음, 그 출력을 MOSS-TTSD에 입력하여 음성 복제 (Voice cloning)와 자연스러운 운율 (Natural prosody)이 적용된 음성 버전을 합성하십시오.

MOSS-TTSD-v1.0은 v0.5에서 개선된 프로덕션 준비 완료 (Production-ready) TTS 모델입니다. 이는 오디오 처리 파이프라인에서 MOSS-Transcribe-Diarize와 쌍을 이룹니다. 여기서 전사 출력이 팟캐스트 더빙, 오디오북 생성 또는 다국어 콘텐츠 적응을 위한 음성 합성 (Speech synthesis)으로 직접 연결됩니다.

기술 사양 (Technical specifications)

아키텍처 및 구성 요소 (Architecture and components):

• 텍스트 백본 (Text backbone): Qwen3-0.6B 스타일의 인과적 디코더 (causal decoder)

• 오디오 인코더 (Audio encoder): Whisper-Medium 인코더 구성

• 오디오-텍스트 브리지 (Audio-text bridge): 4x 시간적 병합 (temporal merge) + MLP 어댑터 (adaptor)

• 융합 메커니즘 (Fusion mechanism): masked_scatter 연산을 통해 오디오 특징 (audio features)이 <|audio_pad|> 임베딩 (embeddings)을 대체

• 출력 형식 (Output format): [S01], [S02]와 같은 화자 태그 (speaker tags)가 포함된 컴팩트한 [start_time][Sxx]text[end_time] 전사 (transcripts)

오디오 처리 (Audio processing):

• 입력 샘플링 레이트 (Input sample rate): 16 kHz

• 스펙트로그램 빈 (Spectrogram bins): 80 mel-frequency bins

• 청크 크기 (Chunk size): 30초 오디오 청크

• 컨텍스트 윈도우 (Context window): 128k 토큰 (최대 90분의 오디오 지원)

• 지원되는 입력 유형 (Supported input types): WAV, MP3 및 비디오 파일 (ffmpeg을 통해 오디오 추출)

추론 사양 (Inference specifications):

• 정밀도 (Precision): CUDA에서는 bfloat16, CPU에서는 float32

• 파라미터 수 (Parameter count): 총 0.9B

• 기본 max_new_tokens: 5,120 (더 긴 다중 화자 세션의 경우 65,536으로 상향)

• 모델 로딩 (Model loading): trust_remote_code=True 옵션과 함께 AutoModelForCausalLM.from_pretrained() 사용

• 프로세서 (Processor): 동일한 원격 코드 플래그와 함께 AutoProcessor.from_pretrained() 사용

벤치마크 데이터셋 성능 지표 (Performance metrics on benchmark datasets) (문자 오류율 (Character Error Rate) / cpCER / Delta-cp):

• AISHELL-4: 14.84 / 15.83 / 0.99 (CER 및 cpCER 측면에서 최상위권으로 밑줄 표시)

• Alimeeting: 24.86 / 22.17 / -2.69 (CER 및 cpCER 측면에서 최고 성능으로 밑줄 표시)

• Podcast: 5.97 / 7.37 / 1.40 (CER 및 cpCER 측면에서 최고 성능으로 밑줄 표시)

• Movies: 6.36 / 12.76 / 6.40 (CER 측면에서 최고 성능으로 밑줄 표시)

• 프로 버전 (MOSS-Transcribe-Diarize Pro)은 모든 데이터셋에서 더 낮은 오류율을 달성함

서빙 및 배포 (Serving and deployment):

• 프레임워크 (Frameworks): transformers (네이티브), vLLM (cu129/cu130 CUDA 휠이 포함된 고정된 나이틀리 빌드(pinned nightly build)를 통해 지원), SGLang Omni (프로덕션 환경 권장)

• API 엔드포인트 (API endpoint): SGLang을 통한 OpenAI 호환 /v1/audio/transcriptions

• 응답 형식 (Response formats): json (전사 텍스트만), verbose_json (시간 정보가 포함된 파싱된 화자 세그먼트), text

• H100에서의 처리량 (Throughput on H100, 짧은 시퀀스 기준): 동시성(concurrency)에 따라 초당 2.57–7.08 요청

• H100에서의 처리량 (Throughput on H100, 긴 시퀀스 기준): 초당 0.022–0.043 요청

• 짧은 오디오에서의 평균 RTF (Real-Time Factor): 0.0612–0.0922 (10분 분량의 클립을 처리하는 데 37–55초 소요)

• 긴 오디오에서의 RTF (Real-Time Factor): 0.0197–0.1237 (60분 분량의 클립을 처리하는 데 190–445초 소요)

의존성 및 라이선스 (Dependencies and licenses):

• 라이선스 (License): Apache 2.0 (허용적인 상업적 이용 가능)

• 핵심 라이브러리 (Core library): 커스텀 원격 코드 (custom remote code)를 포함한 transformers

• 오디오 처리 (Audio processing): librosa, torchaudio

• 선택적 서빙 (Optional serving): 일치하는 CUDA 버전을 사용하는 vLLM 또는 SGLang Omni

• 요구 사항 (Requires): Python 3.12, PyTorch 2.0+

모델 입력 및 출력 (Model inputs and outputs)

입력 (Inputs)

오디오 파일 (Audio file): WAV, MP3 또는 비디오 형식; librosa 또는 ffmpeg를 통해 16 kHz 모노(mono)로 디코딩됨

비디오 파일 (Video file): MP4, MKV 또는 기타 형식; 오디오가 추출되어 위와 동일하게 처리됨

커스텀 프롬프트 (Custom prompt) (선택 사항): 기본 [S01][S02][S03] 화자 템플릿을 재정의하거나 핫워드 (hotwords)를 추가하기 위한 텍스트 문자열 (예: 특정 용어에 편향을 주기 위한 [S01][S02][S03]1, 2, 3)

언어 힌트 (Language hint) (선택 사항): 언어가 모호할 경우 전사 언어를 안내하기 위한 텍스트 문자열

온도 (Temperature): 샘플링의 무작위성을 제어하는 부동 소수점 (Float) 값; 결정론적 (deterministic) 출력을 위한 기본값은 0.0

최대 신규 토큰 (Max new tokens): 최대 출력 길이를 제어하는 정수 (Integer) 값; 기본값은 5,120이며, 긴 다중 화자 세션의 경우 65,536으로 높임

출력 (Outputs)

전사 텍스트 (Transcript text): 화자 라벨과 타임스탬프가 [시작_시간_초][Sxx]발화_텍스트[종료_시간_초] 형식으로 포함된 단일 문자열, 예: [0.5][S01]Hello[2.3][S02]Hi there[4.1]

파싱된 세그먼트 (Parsed segments) (verbose_json 사용 시): 다음 키를 가진 객체 배열: start (초 단위 부동 소수점), end (초 단위 부동 소수점), speaker (S01과 같은 문자열), text (문자열)

원시 전사 (Raw transcript) (json 사용 시): 구조화된 파싱이 없는 일반 텍스트

음향 이벤트 (Acoustic events) (선택 사항): 프롬프트가 제공된 경우 [APPLAUSE], [SILENCE], 또는 [MUSIC]와 같은 비음성 주석

시작하기 (Getting started)

import torch
from transformers import AutoModelForCausalLM, AutoProcessor
from moss_transcribe_diarize import parse_transcript
...

SGLang Omni를 사용한 프로덕션 서빙의 경우:

# 설치 및 다운로드
pip install sglang-omni
hf download OpenMOSS-Team/MOSS-Transcribe-Diarize
...

자주 묻는 질문 (Frequently asked questions)

Q: 이 모델을 상업적으로 사용할 수 있나요?

A: 네. 이 모델은 Apache 2.0 라이선스 하에 공개되었으며, 이는 로열티 비용이나 별도의 허가 없이도 상업적 이용, 수정 및 재배포를 허용합니다.

Q: 이 모델을 실행하려면 어떤 GPU VRAM과 하드웨어가 필요한가요?

A: 모델의 파라미터(Parameters) 수는 0.9B이므로, 8GB 이상의 VRAM을 갖춘 GPU(단일 RTX 4060 또는 RTX 3080 Mobile)에서 여유롭게 구동 가능합니다. H100에서 SGLang Omni를 통해 프로덕션 추론 (Production inference)을 수행할 경우, 동시성 (Concurrency)에 따라 60분 분량의 파일을 전사 (Transcribe)하는 데 45~200초가 소요될 것으로 예상됩니다 (RTF 0.0197 ~ 0.1237).

Q: 전사 (Transcription) 성능 면에서 GPT-4o와 비교하면 어떤가요?

A: Movies 벤치마크에서 GPT-4o는 14.37 CER를 달성한 반면, MOSS-Transcribe-Diarize는