주요 특징

• 가장 큰 설계 차별점은 전사와 화자 분리를 하나의 모델이 한 번에 처리한다는 점입니다. 일반적인 파이프라인은 ASR로 텍스트를 뽑은 뒤 pyannote 같은 별도 화자분리 모듈을 붙여 시간축을 맞추는데, 이 과정에서 경계 오차가 누적됩니다. MOSS-Transcribe-Diarize는 두 작업을 공동 학습해 `[0.48][S01]Welcome everyone[1.66]` 형태로 시작 시각·화자 라벨·본문·종료 시각이 하나의 토큰 스트림으로 흘러나오도록 만들었습니다. 선택적으로 음향 이벤트 주석까지 함께 출력할 수 있어 회의·통화·팟캐스트·인터뷰·강의처럼 화자가 뒤섞인 긴 녹음을 다루기에 적합합니다.
• 구조는 의외로 단순하고 가볍습니다. 텍스트 백본은 Qwen3-0.6B 계열 코잘 디코더, 오디오 인코더는 Whisper-Medium 인코더 구성을 그대로 쓰고, 16kHz·80 mel bin·30초 청크의 WhisperFeatureExtractor로 특징을 뽑습니다. 오디오와 텍스트를 잇는 브리지는 4배 시간축 병합 후 MLP 어댑터를 거치며, 추출된 오디오 특징이 `masked_scatter`로 오디오 패드 임베딩 자리를 대체하는 방식입니다. 전체가 0.9B에 불과해 단일 GPU에서 충분히 돌릴 수 있습니다.
• 벤치마크는 CER·cpCER(순열 최소화 연결 CER)·Δcp 세 지표로 공개돼 있습니다. 0.9B 모델 기준 AISHELL-4에서 CER 14.84·cpCER 15.83·Δcp 0.99, Alimeeting에서 24.86/22.17/-2.69, 팟캐스트에서 5.97/7.37/1.40, 영화 셋에서 6.36/12.76/6.40을 기록했습니다. 같은 표에서 Gemini 3 Pro는 AISHELL-4 cpCER 27.43, VibeVoice ASR은 팟캐스트 cpCER 48.30으로 나와 화자분리가 섞인 조건에서 격차가 크게 벌어집니다. 다만 Alimeeting의 CER 24.86처럼 원거리 마이크 회의 환경에서는 여전히 오차가 높고, 더 강한 Pro 모델은 온라인 플레이그라운드로만 제공돼 가중치가 공개돼 있지 않습니다.
• 서빙은 SGLang Omni를 권장 백엔드로 삼고 vLLM도 지원하며, 두 경우 모두 OpenAI 호환 `/v1/audio/transcriptions` 엔드포인트로 호출합니다. `response_format=verbose_json` 을 주면 파싱된 화자 세그먼트가 함께 돌아옵니다. 단일 H100 기준 성능도 공개돼 있는데, 짧은 영화 클립 셋에서는 동시요청 16개일 때 초당 7.08건·RTF 0.0922·초당 오디오 81.98초를 처리하고, 긴 AISHELL-4 셋에서는 동시요청 16개에 평균 지연 282.8초·초당 오디오 98.83초를 냅니다. 긴 오디오는 디코더가 끝까지 쓸 수 있도록 `max_new_tokens` 를 65536 수준까지 올리라고 안내합니다.
• 실사용 편의 기능도 함께 들어 있습니다. 기본 프롬프트 뒤에 열쇳말을 덧붙이는 방식으로 핫워드 힌트를 줄 수 있고, `mtd-subtitle-web` 로 로컬 자막 웹앱을 띄우면 오디오·영상을 업로드해 세그먼트를 검토한 뒤 JSON/SRT/ASS로 내보내거나 FFmpeg로 자막을 태워 MP4로 뽑을 수 있습니다. `mtd-subtitle` 은 같은 작업을 배치로 돌립니다. 로더는 flash_attention_4부터 eager까지 어텐션 구현을 명시적 우선순위로 시도하고 무엇이 선택됐는지 로그로 남기는데, 최후의 eager 폴백은 긴 오디오에서 이차 크기의 어텐션 텐서를 만들기 때문에 경고를 띄웁니다. Python 3.12 · Transformers 5.x 환경에서 테스트됐습니다.