尧图网站建设 
MOSS-Transcribe-Diarize生产部署SGLang Omni服务化与OpenAI兼容API实战【免费下载链接】MOSS-Transcribe-DiarizeA 0.9B model for long-form transcription in 50 languages with speaker diarization, timestamps, and acoustic event awareness项目地址: https://gitcode.com/gh_mirrors/mo/MOSS-Transcribe-DiarizeMOSS-Transcribe-Diarize 是 OpenMOSS 团队开源的 0.9B 长音频理解模型一次推理即可完成语音转写、说话人分离、时间戳标注与声学事件感知支持 50 语言。本文带你用SGLang Omni把它部署为生产级转写服务并通过OpenAI 兼容的/v1/audio/transcriptionsAPI对外提供能力——从环境准备、服务启动到长音频调优一份完整的生产部署指南。为什么生产环境需要转写分离一体化模型 传统语音管线要把 ASR、VAD、说话人分离等模型拼在一起服务多、延迟叠加、维护成本高。MOSS-Transcribe-Diarize 走的是端到端单模型路线输入原始音频直接输出带时间戳和说话人标签的紧凑转写流标准输出格式为[0.48][S01]Welcome everyone[1.66][12.26][S02]The new transcription pipeline is ready for evaluation[13.81]对会议、电话、播客、访谈、课程录像这类多人长音频场景它还能输出可选的声学事件标注让下游系统知道谁在什么时候说了什么。在 AISHELL-4、Alimeeting 等公开基准上0.9B 版本的 cpCER 全面领先同规模的商用与开源方案详见 README.md 中的客观评测表。模型侧的完整实现可以对照阅读模型结构modeling_moss_transcribe_diarize.py音频前端与处理器processing_moss_transcribe_diarize.py转写结果解析把紧凑格式切分成结构化分段transcript_parser.py模型架构一图看懂0.9B 如何一次输出时间戳与说话人架构要点一览来自 README.md 架构表组件规格文本主干Qwen3-0.6B 风格因果解码器音频编码器Whisper-Medium 编码器配置音频前端WhisperFeatureExtractor16 kHz80 mel 分频30 s 分块音文桥接4x 时间合并 MLP 适配器融合方式音频特征通过masked_scatter替换\|audio_pad\|嵌入输出格式[start][Sxx]text[end]紧凑转写说话人标签如[S01]0.9B 的轻量体积意味着单卡即可承载这是它适合生产服务化的关键前提。SGLang Omni 部署 MOSS-Transcribe-Diarize 完整步骤SGLang Omni 是官方推荐的推理服务后端针对长音频场景做了优化。注意SGLang Omni 目前面向 CUDA 13 环境CUDA 12 环境请看后文的 vLLM 方案。第 1 步准备代码与 Python 环境如需使用仓库内置的字幕工具链git clone https://gitcode.com/gh_mirrors/mo/MOSS-Transcribe-Diarize cd MOSS-Transcribe-Diarize uv venv --python 3.12 .venv source .venv/bin/activate uv pip install -e .[torch-runtime] --torch-backendauto第 2 步下载模型权重hf download OpenMOSS-Team/MOSS-Transcribe-Diarize第 3 步启动服务sgl-omni serve \ --model-path OpenMOSS-Team/MOSS-Transcribe-Diarize \ --port 8000 \ --max-running-requests 16 \ --cuda-graph-max-bs 16 \ --mem-fraction-static 0.80三个关键启动参数的作用--max-running-requests 16同时处理的转写请求上限决定并发能力--cuda-graph-max-bs 16CUDA Graph 覆盖的批大小需与前一项匹配以获得稳定加速--mem-fraction-static 0.80静态显存占比长音频场景留一些余量避免 OOM。调用 OpenAI 兼容转写 APIcurl 与 Python 实战 ⚡服务启动后你得到的就是一个标准的 OpenAI 兼容端点POST /v1/audio/transcriptions。用 curl 快速验证30 秒打通链路curl -X POST http://localhost:8000/v1/audio/transcriptions \ -F modelOpenMOSS-Team/MOSS-Transcribe-Diarize \ -F fileaudio.wav \ -F response_formatverbose_json用 Python 接入业务系统import requests with open(audio.wav, rb) as f: resp requests.post( http://localhost:8000/v1/audio/transcriptions, data{model: OpenMOSS-Team/MOSS-Transcribe-Diarize, response_format: verbose_json}, files{file: (audio.wav, f, audio/wav)}, timeout300, ) payload resp.json() for seg in payload.get(segments, []): print(f[{seg[start]:.2f}-{seg[end]:.2f}] {seg[text]})response_format的取值直接影响返回内容取值返回内容json默认原始转写文本verbose_json解析好的说话人分段start/end/text需要分段信息时选它text纯文本完整的请求参数契约含language语言提示、prompt自定义指令等见 README.md 的 SGLang Omni 参数表。长音频调优指南max_new_tokens 与并发设置⚠️ 最容易踩的坑默认max_new_tokens5120对长多人对话不够用解码器会在转写中途被截断。长音频务必显式调高curl -X POST http://localhost:8000/v1/audio/transcriptions \ -F modelOpenMOSS-Team/MOSS-Transcribe-Diarize \ -F fileaudio.wav \ -F response_formatverbose_json \ -F max_new_tokens65536单张 H100 的实测数据摘自 README.md 基准可以帮你估算容量场景并发吞吐 (req/s)RTF 均值音频处理速率 (s/s)短序列movies12.570.06129.8短序列movies167.080.09282.0长序列aishell4_long10.0220.02050.6长序列aishell4_long160.0430.12498.8RTF 1 意味着处理速度跑赢实时。经验法则短请求拉满并发换吞吐长音频并发越高单请求延迟越长16 并发时平均 283 s按 SLA 取平衡点即可。CUDA 12 环境替代方案vLLM 服务化部署如果你的集群还在 CUDA 12用 vLLM 路径同样得到 OpenAI 兼容 API。安装时选用包含 MOSS-Transcribe-Diarize 模型注册的 vLLM 版本CUDA 12 用 cu129 轮子CUDA 13 用 cu130然后vllm serve OpenMOSS-Team/MOSS-Transcribe-Diarize --trust-remote-code调用方式与 SGLang Omni 完全一致POST /v1/audio/transcriptionsmultipart 上传。仓库本身就内置了一个现成的 vLLM API 客户端 VllmRunner值得参考它的工程细节先把任意媒体统一转成 16 kHz WAV 再上传_media_to_wav_bytes用streamtrue走SSE 流式返回边收边更新进度_consume_sse_transcription相关行为由 tests/test_vllm_runner.py 覆盖。字幕 Web 应用也能直接挂到这个远程服务上server.py 中按backend选择本地模型或远程 vLLMmtd-subtitle-web \ --backend vllm \ --vllm-base-url http://127.0.0.1:8000/v1 \ --port 7860打开http://127.0.0.1:7860即可上传音频、在线校对分段并导出 SRT/ASS 或烧录 MP4。生产部署检查清单与常见问题 检查项建议CUDA 版本CUDA 13 → SGLang OmniCUDA 12 → vLLM注意力后端优先 flash-attn 或 SDPAeager显存随音频长度平方增长长音频会 OOM长音频max_new_tokens调至 65536 起步分段需求response_formatverbose_json业务超参客户端超时 ≥ 300 s长音频转写耗时远超普通 HTTP 默认值专有名词通过prompt参数追加热词提示提升识别率默认提示词见 inference_utils.py其他生态选项若你在 FunASR 体系内1.4.12 版本可把 vLLM 的说话人归因响应归一化为通用sentence_info契约详见 README.md 的 FunASR 章节模型微调请参考 FINETUNING.md。小结SGLang OmniCUDA 13或 vLLMCUDA 12两条路径都能把 MOSS-Transcribe-Diarize 变成一个标准的 OpenAI 兼容转写服务——三条命令起服务一个curl打通链路剩下的就是按并发、max_new_tokens和显存占比做容量调优。0.9B 的体量让它单卡可用转写分离一体又省掉了整条管线非常适合快速落地。【免费下载链接】MOSS-Transcribe-DiarizeA 0.9B model for long-form transcription in 50 languages with speaker diarization, timestamps, and acoustic event awareness项目地址: https://gitcode.com/gh_mirrors/mo/MOSS-Transcribe-Diarize创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MOSS-Transcribe-Diarize生产部署：SGLang Omni服务化与OpenAI兼容API实战
MOSS-Transcribe-Diarize生产部署SGLang Omni服务化与OpenAI兼容API实战【免费下载链接】MOSS-Transcribe-DiarizeA 0.9B model for long-form transcription in 50 languages with speaker diarization, timestamps, and acoustic event awareness项目地址: https://gitcode.com/gh_mirrors/mo/MOSS-Transcribe-DiarizeMOSS-Transcribe-Diarize 是 OpenMOSS 团队开源的 0.9B 长音频理解模型一次推理即可完成语音转写、说话人分离、时间戳标注与声学事件感知支持 50 语言。本文带你用SGLang Omni把它部署为生产级转写服务并通过OpenAI 兼容的/v1/audio/transcriptionsAPI对外提供能力——从环境准备、服务启动到长音频调优一份完整的生产部署指南。为什么生产环境需要转写分离一体化模型 传统语音管线要把 ASR、VAD、说话人分离等模型拼在一起服务多、延迟叠加、维护成本高。MOSS-Transcribe-Diarize 走的是端到端单模型路线输入原始音频直接输出带时间戳和说话人标签的紧凑转写流标准输出格式为[0.48][S01]Welcome everyone[1.66][12.26][S02]The new transcription pipeline is ready for evaluation[13.81]对会议、电话、播客、访谈、课程录像这类多人长音频场景它还能输出可选的声学事件标注让下游系统知道谁在什么时候说了什么。在 AISHELL-4、Alimeeting 等公开基准上0.9B 版本的 cpCER 全面领先同规模的商用与开源方案详见 README.md 中的客观评测表。模型侧的完整实现可以对照阅读模型结构modeling_moss_transcribe_diarize.py音频前端与处理器processing_moss_transcribe_diarize.py转写结果解析把紧凑格式切分成结构化分段transcript_parser.py模型架构一图看懂0.9B 如何一次输出时间戳与说话人架构要点一览来自 README.md 架构表组件规格文本主干Qwen3-0.6B 风格因果解码器音频编码器Whisper-Medium 编码器配置音频前端WhisperFeatureExtractor16 kHz80 mel 分频30 s 分块音文桥接4x 时间合并 MLP 适配器融合方式音频特征通过masked_scatter替换\|audio_pad\|嵌入输出格式[start][Sxx]text[end]紧凑转写说话人标签如[S01]0.9B 的轻量体积意味着单卡即可承载这是它适合生产服务化的关键前提。SGLang Omni 部署 MOSS-Transcribe-Diarize 完整步骤SGLang Omni 是官方推荐的推理服务后端针对长音频场景做了优化。注意SGLang Omni 目前面向 CUDA 13 环境CUDA 12 环境请看后文的 vLLM 方案。第 1 步准备代码与 Python 环境如需使用仓库内置的字幕工具链git clone https://gitcode.com/gh_mirrors/mo/MOSS-Transcribe-Diarize cd MOSS-Transcribe-Diarize uv venv --python 3.12 .venv source .venv/bin/activate uv pip install -e .[torch-runtime] --torch-backendauto第 2 步下载模型权重hf download OpenMOSS-Team/MOSS-Transcribe-Diarize第 3 步启动服务sgl-omni serve \ --model-path OpenMOSS-Team/MOSS-Transcribe-Diarize \ --port 8000 \ --max-running-requests 16 \ --cuda-graph-max-bs 16 \ --mem-fraction-static 0.80三个关键启动参数的作用--max-running-requests 16同时处理的转写请求上限决定并发能力--cuda-graph-max-bs 16CUDA Graph 覆盖的批大小需与前一项匹配以获得稳定加速--mem-fraction-static 0.80静态显存占比长音频场景留一些余量避免 OOM。调用 OpenAI 兼容转写 APIcurl 与 Python 实战 ⚡服务启动后你得到的就是一个标准的 OpenAI 兼容端点POST /v1/audio/transcriptions。用 curl 快速验证30 秒打通链路curl -X POST http://localhost:8000/v1/audio/transcriptions \ -F modelOpenMOSS-Team/MOSS-Transcribe-Diarize \ -F fileaudio.wav \ -F response_formatverbose_json用 Python 接入业务系统import requests with open(audio.wav, rb) as f: resp requests.post( http://localhost:8000/v1/audio/transcriptions, data{model: OpenMOSS-Team/MOSS-Transcribe-Diarize, response_format: verbose_json}, files{file: (audio.wav, f, audio/wav)}, timeout300, ) payload resp.json() for seg in payload.get(segments, []): print(f[{seg[start]:.2f}-{seg[end]:.2f}] {seg[text]})response_format的取值直接影响返回内容取值返回内容json默认原始转写文本verbose_json解析好的说话人分段start/end/text需要分段信息时选它text纯文本完整的请求参数契约含language语言提示、prompt自定义指令等见 README.md 的 SGLang Omni 参数表。长音频调优指南max_new_tokens 与并发设置⚠️ 最容易踩的坑默认max_new_tokens5120对长多人对话不够用解码器会在转写中途被截断。长音频务必显式调高curl -X POST http://localhost:8000/v1/audio/transcriptions \ -F modelOpenMOSS-Team/MOSS-Transcribe-Diarize \ -F fileaudio.wav \ -F response_formatverbose_json \ -F max_new_tokens65536单张 H100 的实测数据摘自 README.md 基准可以帮你估算容量场景并发吞吐 (req/s)RTF 均值音频处理速率 (s/s)短序列movies12.570.06129.8短序列movies167.080.09282.0长序列aishell4_long10.0220.02050.6长序列aishell4_long160.0430.12498.8RTF 1 意味着处理速度跑赢实时。经验法则短请求拉满并发换吞吐长音频并发越高单请求延迟越长16 并发时平均 283 s按 SLA 取平衡点即可。CUDA 12 环境替代方案vLLM 服务化部署如果你的集群还在 CUDA 12用 vLLM 路径同样得到 OpenAI 兼容 API。安装时选用包含 MOSS-Transcribe-Diarize 模型注册的 vLLM 版本CUDA 12 用 cu129 轮子CUDA 13 用 cu130然后vllm serve OpenMOSS-Team/MOSS-Transcribe-Diarize --trust-remote-code调用方式与 SGLang Omni 完全一致POST /v1/audio/transcriptionsmultipart 上传。仓库本身就内置了一个现成的 vLLM API 客户端 VllmRunner值得参考它的工程细节先把任意媒体统一转成 16 kHz WAV 再上传_media_to_wav_bytes用streamtrue走SSE 流式返回边收边更新进度_consume_sse_transcription相关行为由 tests/test_vllm_runner.py 覆盖。字幕 Web 应用也能直接挂到这个远程服务上server.py 中按backend选择本地模型或远程 vLLMmtd-subtitle-web \ --backend vllm \ --vllm-base-url http://127.0.0.1:8000/v1 \ --port 7860打开http://127.0.0.1:7860即可上传音频、在线校对分段并导出 SRT/ASS 或烧录 MP4。生产部署检查清单与常见问题 检查项建议CUDA 版本CUDA 13 → SGLang OmniCUDA 12 → vLLM注意力后端优先 flash-attn 或 SDPAeager显存随音频长度平方增长长音频会 OOM长音频max_new_tokens调至 65536 起步分段需求response_formatverbose_json业务超参客户端超时 ≥ 300 s长音频转写耗时远超普通 HTTP 默认值专有名词通过prompt参数追加热词提示提升识别率默认提示词见 inference_utils.py其他生态选项若你在 FunASR 体系内1.4.12 版本可把 vLLM 的说话人归因响应归一化为通用sentence_info契约详见 README.md 的 FunASR 章节模型微调请参考 FINETUNING.md。小结SGLang OmniCUDA 13或 vLLMCUDA 12两条路径都能把 MOSS-Transcribe-Diarize 变成一个标准的 OpenAI 兼容转写服务——三条命令起服务一个curl打通链路剩下的就是按并发、max_new_tokens和显存占比做容量调优。0.9B 的体量让它单卡可用转写分离一体又省掉了整条管线非常适合快速落地。【免费下载链接】MOSS-Transcribe-DiarizeA 0.9B model for long-form transcription in 50 languages with speaker diarization, timestamps, and acoustic event awareness项目地址: https://gitcode.com/gh_mirrors/mo/MOSS-Transcribe-Diarize创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考