MOSS-Transcribe-Diarize 0.9B, open-sourced by OpenMOSS on July 9, 2026 under Apache-2.0, targets a specific and stubborn failure mode in speech recognition: transcribing long recordings with several people talking. It has drawn roughly 1,200 GitHub stars and 117,000 Hugging Face downloads in under three weeks, and on July 14 it took first place in the 2nd MLC-SLM Challenge at INTERSPEECH 2026 across 14 languages. The design choice behind it is worth stating up front — transcription and speaker diarization happen jointly, in one model pass, rather than as two systems bolted together. ## Why Joint Modeling Matters The conventional pipeline runs ASR to get text, runs a separate diarization system to get speaker turns, then aligns the two by timestamp. Every stage compounds the previous stage's errors, and the alignment step is where multi-speaker transcripts typically fall apart — overlapping speech, short interjections, and rapid turn-taking all produce misattributed lines. MOSS-Transcribe-Diarize emits a single stream instead: `[start_time][Sxx]transcribed speech[end_time]`, with timestamps in seconds and consistent speaker labels such as `[S01]` and `[S02]` maintained across the whole recording. Segments concatenate into one output, so a meeting transcript arrives already structured — who spoke, what they said, and when — without a downstream merge step. Optional acoustic event annotations add awareness of non-speech sounds. ## Architecture The model is compact by design at 0.9B parameters. A Qwen3-0.6B-style causal decoder serves as the text backbone; a Whisper-Medium encoder configuration handles audio, fed by a standard `WhisperFeatureExtractor` frontend at 16 kHz with 80 mel bins over 30-second chunks. The bridge between them is a 4x temporal merge plus an MLP adaptor, and audio features are fused by replacing audio-placeholder embeddings via `masked_scatter` — the same pattern used across Qwen's multimodal line, which means the message flow will look familiar to anyone who has worked with those models. Language coverage is 50+ languages. ## Benchmark Results The evaluation uses character error rate, concatenated minimum-permutation CER, and Δcp, which measures how much error the diarization step adds on top of raw transcription. That third metric is where the joint approach shows its value. On AISHELL-4, the 0.9B model records a Δcp of 0.99 against 9.68 for Doubao, 18.36 for ElevenLabs, and 10.72 for Gemini 2.5 Pro — an order-of-magnitude difference in speaker-attribution penalty. On Alimeeting the figure is negative (-2.69), meaning speaker conditioning actually improved transcription accuracy rather than degrading it. Raw accuracy is competitive rather than dominant: CER of 14.84 on AISHELL-4, 5.97 on Podcast, and 6.36 on Movies, generally ahead of the commercial systems compared but behind the closed MOSS-Transcribe-Diarize Pro, which OpenMOSS keeps for its hosted playground. The picture is consistent — a sub-1B open model matching or beating substantially larger commercial APIs on messy multi-speaker audio, with its clearest advantage in attribution rather than pure word accuracy. ## Deployment Setup is a standard `uv` install against Python 3.12 and Transformers 5.x. The Python path uses `AutoModelForCausalLM` and `AutoProcessor` with `trust_remote_code=True`, plus helper functions for building transcription messages and parsing the timestamped output into segment objects. For serving, SGLang Omni is the recommended backend and exposes an OpenAI-compatible `/v1/audio/transcriptions` endpoint — meaning existing Whisper API clients can point at a local server with minimal change, and `response_format=verbose_json` returns parsed speaker segments. vLLM is supported for CUDA 12 environments where SGLang Omni's CUDA 13 requirement does not fit. Custom prompts and hotword biasing are available, a fine-tuning guide ships in the repository, and a subtitle web UI supports English and Simplified Chinese. ## Pros and Cons The strengths are the joint architecture's measurable payoff on speaker attribution, a parameter count small enough to serve cheaply, Apache-2.0 licensing with no usage restrictions, an OpenAI-compatible serving path that lowers migration cost, and a competition result that provides third-party validation across 14 languages. The limitations are real. The strongest model in the family — Pro — is not open; the 0.9B release is consistently second-best in OpenMOSS's own tables, so the published numbers understate what the family can do while the open weights cannot reach them. Raw CER on hard Chinese meeting corpora like Alimeeting remains high in absolute terms (24.86), reflecting genuinely difficult audio rather than a model flaw, but it means expectations should be calibrated. Benchmarks lean toward Mandarin datasets, so the 50-language claim is thinner outside the MLC-SLM results. `trust_remote_code=True` is required, which some security-conscious deployments will not accept without review. And the recommended serving stack targets CUDA 13, with vLLM as the fallback for older environments. ## Outlook The practical demand for speaker-aware transcription is large and growing — meeting notes, call analytics, podcast production, and increasingly as the ingestion layer for LLM agents that need to know who said what. Whisper made transcription commodity but never solved diarization; the ecosystem filled that gap with pyannote and WhisperX pipelines that work but carry the compounding-error problem. A jointly trained model that fits under a billion parameters is a credible replacement for that stack, and OpenMOSS's Δcp numbers make the argument concretely rather than rhetorically. ## Conclusion MOSS-Transcribe-Diarize 0.9B is a strong choice for teams building meeting, call, or podcast transcription where speaker attribution matters as much as word accuracy, especially those already running Whisper-compatible infrastructure. Teams working primarily in languages outside the benchmarked set should validate on their own audio first, and those needing the family's best accuracy will find it only behind OpenMOSS's hosted API.