0.32 秒延迟之外把说话人分离与 30B 转写拼成一条流水线【免费下载链接】NVIDIA-Nemotron-3.5-Transcribe-30B-A4B项目地址: https://ai.gitcode.com/hf_mirrors/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B「0.32 秒」这个数字在最近两周的社区文章里被反复引用8 人说话人分离、约 1 亿参数、实时流式、DIHARD III 与 NOTSOFAR-1 上错误率大幅下降。它对应的其实是 Nemotron-3-Diarization 这条专门的分离模型。而眼前这个仓库NVIDIA-Nemotron-3.5-Transcribe-30B-A4B是一个 34B 总参数、4.3B 激活参数、最高支持 1 小时录音的离线语音大模型模型卡里有一句必须被反复强调的话This is an offline model.Internal audio chunking does not make it a real-time streaming ASR service.于是真正的工程问题变成了当一个「0.32 秒级」的流式分离能力被装进一个「离线整段转写」的 30B 模型里流水线该怎么拼本文不讨论发布会的参数罗列只讨论三件事——两条流的时间轴怎么对齐、重叠语音的归属怎么判定、端到端延迟预算怎么分配。所有结论都能在仓库的config.json、processor_config.json与模型卡找到对应证据。一个 checkpoint而不是两个服务大多数「ASR 说话人分离」方案是级联式先跑分离拿到 speaker turns再按 turn 切片送进 ASR最后把两边的文本和时间戳做字符串级别的缝合。这种拼法有两个固有误差源切片边界会切断音素且两套模型的帧率不一致对齐只能靠猜。Nemotron 3.5 Transcribe 把这件事收进了同一个前向config.json里的pe_encoder_config指向ParallelExpertEncoderPT它并列挂着两条分支——一条 32 层、d_model1280、10 个注意力头的 Transformer ASR 编码器和一条来自 Nemotron-3-Diarization 的说话人编码器31 层、hidden_size512、8 个注意力头、num_speakers8。两条分支的输出经 1280 维的IdentityConnector拼接再投影到 2688 维喂给 Mamba-2 / Transformer 混合的 MoE 主干128 个路由专家、每 token 激活 6 个 1 个共享专家、hidden_size2688。这就是「一条流水线」和「两条流水线」的本质区别说话人信息不是后处理附加的标签而是在编码阶段就与声学特征并置进入语言模型的上下文。模型卡把这条路径描述为 speaker-aware perception并给出了直接后果——多说话人 ASR 的均值 cpWER 为 15.80而此前最好的公开组合 DiCoW v3.3 DiariZen 是 16.83。级联方案的天花板被一次联合编码抬高了。值得注意的是底层的规模账语言主干约 3.5B 激活参数加上约 800M 参数的联合音频编码器600M ASR Transformer 约 99M 说话人编码器合计约 4.3B 激活。也就是说那个「1 亿参数的分离神器」并没有消失它成为了 30B 模型里的一个子模块——这解释了为什么它能同时做转写和分离也解释了为什么它不再是 0.32 秒的流式服务。时间轴对齐80ms 一个 token10ms 一个网格对齐问题在联合模型里并没有自动消失只是从「跨进程缝合」变成了「同一张网格上的三次量化」。第一层量化来自前端。processor_config.json写明sampling_rate: 16000、hop_length: 160、win_length: 400、n_fft: 512、feature_size: 128、subsampling_factor: 8——10ms 一帧梅尔谱再经 8 倍下采样得到模型卡所称的「约 80ms 一个音频 token」。这是语言模型能「看见」音频的最小刻度。第二层量化来自 CTC 时间戳头。config.json的ctc_timestamps.decoder_config里upsampling_factor: 2配upsampling_mode: conv_transpose把 80ms 的声学网格插值回 40ms 的词片word-piece网格解码器只有 2 层、16 头、pos_emb_max_len: 5000本质是一个轻量的对齐器而非第二个 ASR。它的词表vocabulary长度 23862前 51 个位置被结构化 token 占满ev:*事件标签 10 个breath、laughter、throat_cough 等、spk:0到spk:15共 16 个说话人标签、sty:stt:*/sty:end:*共 22 个说话风格标签。所以「谁在何时说了什么」在输出层是同一条 token 序列里的不同符号而不是三个服务各自的 JSON。第三层量化来自后处理细化。ctc_timestamps.alignment_config.parameters是一组被训练/调参固化的常数直接决定边界落在哪里参数取值含义boundary_grid_seconds0.01边界搜索的最终网格精度onset_snap_seconds0.08起始点向能量起振处吸附的窗口boundary_max_correction_seconds0.04边界允许的最大修正量maximum_token_len1.0364单 token 最长持续时间秒的约束系数max_word_frames19单次对齐窗口的最大帧数interpolation_enabledtrue是否启用边界插值含 24 组系数与 offset这张表说明一件容易被忽略的事模型输出的start/end并不是原始注意力权重的简单 argmax而是「CTC 后验 → 40ms 网格 → 80ms onset 吸附 → 10ms 网格」的合成结果。做过字幕对齐的人都知道词级时间戳的误差通常不来自识别错而来自边界定义——这组常数正是把边界定义写死的地方。而word_timestamp_config里blank_token_id: 23862、vocab_size: 23863的 1 关系也印证了 CTC 词表是在 23862 类之上追加一个 blank。重叠语音不是二选一而是加权归属大纲里「重叠语音段落的归属判定」是最容易被写成玄学的一节。在这个仓库里它其实有明确的可调参数。对齐阶段的归属是由声学证据与文本后验共同投票的alignment_config给出了三个权重speaker_logprob_weight: 0.6057、speaker_activity_threshold: 0.1881、vad_threshold: 0.4641。换句话说一个词被贴上spk:N既要求说话人分支在该帧的活动概率越过 0.1881 这个较低的软阈值又要求 CTC 后验在候选说话人之间给出区分度两者按约 0.6 : 0.4 的比例融合。低阈值的设计意图很清楚宁可让两个说话人同时活动也不要在重叠段提前判负把消歧留给文本侧的语言模型上下文。而说话人分支自身是流式友好的audio_config.diarization_config里chunk_length: 500、chunk_left_context: 50、chunk_right_context: 50、fifo_length: 40streaming_config再给出fifo_length: 264、speaker_cache_length: 188、speaker_cache_update_period: 222、prediction_score_threshold: 0.25。这套环形缓冲 说话人缓存的配置正是「0.32 秒延迟」得以成立的机制来源——它只依赖固定长度的左右上下文而不是整段音频。但在 30B Transcribe 里这个流式配置被包在一个离线推理流程中前后文被 30 秒的编码器分块encoder_chunk_size_seconds: 30.0重新组织于是流式的低延迟被换成了整段的更高精度。精度的代价与收益都可以量化。模型卡给出的多说话人结果里同一会议语料在两种拾音条件下的差距比模型差异更能说明问题测试集条件cpWER (%)AMI个体头戴麦克风IHM10.29AMI单远端麦克风SDM17.34NOTSOFAR-1个体头戴麦克风IHM14.94NOTSOFAR-1单通道远端麦克风SC25.91CALLHOMECH109 电话对话11.50Mixer 6Channel 414.80cpWER 会先把预测的说话人映射到参考说话人再算词错误率——也就是说归属错了会直接计入错误率不存在「文本对了就算过」的余地。远端麦克风下的翻倍误差指向的是重叠与混响而非词汇量。还有一个可直接用在产品里的实测对比当近场指令要求「只转写离麦克风最近的说话人、不要转写其他人声」时把 LibriSpeech test-clean 语音与 NOTSOFAR-1 远端语音混合WER 为 4.78%换成普通的单说话人转写 prompt同一段音频的 WER 是 27.32%。这不是模型能力差异而是归属判定的边界由 prompt 定义——在双人抢话的会议里你要的可能是前者在圆桌讨论里你要的恰恰是后者。端到端延迟预算把 0.32 秒放进正确的位置先给出一个必须承认的现实在这个仓库的部署形态下你拿不到 0.32 秒的端到端首字延迟。原因不是模型慢而是三处硬约束写在了服务参数里。第一处是入参限制。模型卡明确时间戳请求只接受一条音频、streamfalse、n1。CTC 对齐需要把整段输出与整段音频做单调对齐天然与增量解码冲突。第二处是运行器互斥。要词级时间戳必须VLLM_USE_V2_MODEL_RUNNER0V1 runner并挂载ctc_timestamp_middleware而 DFlash2 草稿模型只在 V2 runner 上运行且--hf-overrides {ctc_timestamps:{enabled:false}}会直接关掉对齐。换句话说「最准的时间戳」与「最高的吞吐」在 vLLM 0.32.0 上是两个部署档位不能同时开。第三处是编码窗口。encoder_chunk_size_seconds: 30.0意味着任何「伪流式」实现的最小等待粒度是分块级别而不是帧级别。模型卡对此的措辞很克制这是内部的加工选择不是 30 秒录音上限也不是流式延迟承诺。所以延迟预算应该这样拆T_e2e T_vad T_enc(chunk) T_prefill T_decode T_align T_post其中真正可被服务端优化的是T_prefill T_decode。仓库给出的锚点是在单张 RTX PRO 6000 Blackwell 上NIM 路径可用 NVFP4 DFlash2 做到 2238 秒音频/秒30 秒录音的转写结果在 0.13 秒内返回而 NeMo Speech 发布日提供的开源 vLLM 集成面向模型开发预期慢约 2 倍。H100 80GB 上的批量吞吐则是 MTP2 约 410 RTFx、MTP8 约 270、DFlash2 K7 约 340、K15 约 260。注意 RTFx 与「单请求延迟」是两件事410 RTFx 指批量负载下每秒处理 410 秒音频不代表单条 30 秒音频 73 毫秒出结果。把 RTFx 当延迟用是这类评测文章最常见的误读。一张可落地的预算表按「先分级、再并行」的思路配置链路环节负责组件量级可调手段端点检测 / 切片应用层 VAD数百 ms切片长度对齐到 30s 整数倍减少 padding声学编码Parallel Expert Encoder随切片线性16kHz 单声道避免重采样引入额外帧PrefillMoE 主干chunked prefill 已开与音频 token 数正相关--max-num-batched-tokens 4096、--mm-processor-cache-gb 0DecodeMTP / DFlash2与输出 token 数正相关MTP2 保延迟、MTP8/DFlash2 提吞吐CTC 对齐2 层轻量对齐器十毫秒级仅在需要时间戳时开启配合 V1 runner后处理cleanup_generation_loops可忽略去除字符/块级重复生成工程上由此得到一个清晰的双档架构在线低延迟档用 DFlash2 V2 runner只做纯文本转写与翻译把说话人标签交给 prompt 让语言模型直接生成离线精修档用 MTP V1 runner CTC middleware产出词级时间戳与 diarization 分段用于会议纪要、客服质检与字幕校准。两档共享同一个 checkpoint不共享同一份启动参数。把流水线跑起来三种取时间戳的正确姿势服务端的关键几步完整命令见模型卡 Quick Start 与 Inference Setupexport VLLM_PLUGINSnemo_speechlm export VLLM_MAX_AUDIO_DECODE_DURATION_S3600 # 默认仅 600 秒 export VLLM_MAX_AUDIO_CLIP_FILESIZE_MB180 export VLLM_USE_V2_MODEL_RUNNER0 # 词级时间戳依赖 V1 runner vllm serve ./NVIDIA-Nemotron-3.5-Transcribe-30B-A4B \ --served-model-name nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B \ --trust-remote-code --dtype bfloat16 --gpu-memory-utilization 0.94 \ --max-model-len 65536 --max-num-batched-tokens 4096 --max-num-seqs 192 \ --enable-chunked-prefill --no-enable-prefix-caching \ --use-replayssm --mamba-backend flashinfer --mamba-cache-mode none \ --limit-mm-per-prompt {audio:{count:6,length:120000000}} \ --speculative-config {method:mtp,num_speculative_tokens:8} \ --reasoning-parser nemotron_v3 \ --trust-request-mm-kwargs \ --middleware nemo.collections.speechlm2.vllm.salm.ctc_serving.ctc_timestamp_middleware--use-replayssm --mamba-backend flashinfer --mamba-cache-mode none与--no-enable-prefix-caching这组参数不要随意改Mamba 层的状态缓存与 KV 前缀复用语义不同混用会让长音频的内存占用失控。客户端侧时间戳只在三个条件同时成立时返回请求带mm_processor_kwargs: {capture_ctc_timestamps: True}、prompt 里要求了说话人标签、且服务端挂了 middleware。import base64 from pathlib import Path from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) PROMPT ( Transcribe this audio with punctuation and capitalization. Include all spoken words and verbal fillers. Write numbers in their standard written form. Put speaker tags spk:0 spk:1 spk:2 spk:3 on the transcription. ) audio base64.b64encode(Path(meeting.wav).read_bytes()).decode() resp client.chat.completions.create( modelnvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B, messages[{role: user, content: [ {type: text, text: PROMPT}, {type: audio_url, audio_url: {url: fdata:audio/wav;base64,{audio}}}, ]}], temperature0, max_tokens16384, extra_body{ chat_template_kwargs: {enable_thinking: False}, skip_special_tokens: False, # 必须保留 spk: 标签 spaces_between_special_tokens: False, seed: 0, mm_processor_kwargs: {capture_ctc_timestamps: True}, }, ) align resp.model_dump()[ctc_timestamps] if align[error] is not None: raise RuntimeError(align[error]) # 对齐失败原因要先检查 tag_map align[speaker_tag_to_diarization_speaker] for seg in align[diarization]: print(f[{seg[start]:.2f} - {seg[end]:.2f}] diar_speaker{seg[speaker]}) for w in align[words]: print(f{w[start]:7.2f} {w[end]:7.2f} {w[speaker]:7} {w[word]})三个工程细节值得展开其一error字段必须前置检查。对齐是单调匹配一旦文本与音频不匹配例如幻觉出一段不存在的语音、或音频被截断结果不是「略微偏移」而是整段失效。把它当异常而不是警告处理能避免下游字幕错位几十秒。其二speaker_tag_to_diarization_speaker是两层系统的接缝。文本侧的spk:N由语言模型自回归生成它在长音频里可能重复、跳号、甚至在两人对话中复用同一个标签而diarization分段来自声学分支说话人数量与出现顺序都是稳定的。用这张映射表把文本标签回落到声学说话人是纠正「标签漂移」的唯一可靠方式。模型卡对此有一句关键提醒评估分离效果时应当用diarization分段而不是词级时间戳——因为词级时间戳的 speaker 字段是把两者融合后的产物不适合作为分离的独立度量。其三采样设置不能想当然。转写、翻译、语种识别用temperature0且关闭思考音频理解类任务才用 0.6 / top_p 0.95 / top_k 关闭并开启推理。把enable_thinking打开去做转写除了变慢还会让模型在文本里夹带推理痕迹。别忽略的四个现实约束说话人上限是 8不是 16。CTC 词表里确实有spk:0到spk:15共 16 个标签但说话人编码器的head_config.num_speakers与流式配置的num_speakers都是 8。标签空间留了余量声学分支并没有。9 人以上的圆桌需要外接分离模型或者按时间段切分。中文是多说话人支持而非领先。语言矩阵里 Chinese Mandarin 的 ASR、翻译、多说话人、code-switching 全部打勾但质量档位是 Supported需要微调才能达到生产水准英语、法语、德语、印地语、意大利语、韩语、葡萄牙语、俄语、西班牙语等才是 Leading。中文会议的 cpCER 参考值是 AISHELL-4 32.91、AliMeeting 34.95——这是含说话人归属的字符错误率与纯文本 CER 不可直接比较但足以说明中文多说话人仍有明确的优化空间。长音频要吃满输出预算。模型卡直说一小时密集对话可能需要约 20000 个输出 token。默认max_tokens16384会把尾部截断而对齐失败又往往表现为「文本短于音频」两者很容易被误判成同一个 bug。生成循环要有兜底。模型卡给出了一个后处理函数把连续重复 ≥21 次的单字符、以及 1–4096 字符块重复 ≥20 次的情况折叠为一份。它只在转写、翻译、语种识别链路上建议启用推理类长答案里这个正则容易误伤 Markdown 表格的分隔线。结语0.32 秒是一个模块指标不是系统指标把这件事讲清楚比复述参数更有价值0.32 秒属于那个约 1 亿参数的流式说话人分离模块它靠固定长度左右上下文与说话人缓存换取低延迟而 Nemotron-3.5-Transcribe-30B-A4B 把它收进 Parallel Expert Encoder用 30 秒编码分块与 80ms 音频 token 换取整段一致性再用 CTC 头把 23862 类词表对齐回 40ms 网格最终以 cpWER 15.80 的成绩压过级联方案。所以「把说话人分离与 30B 转写拼成一条流水线」的正确拼法不是让 30B 模型去追 0.32 秒而是承认两档存在需要秒级响应的场景让流式分离 轻量 ASR 顶在前面需要「谁说了什么、精确到词」的场景把整段录音交给这个联合模型用diarization分段做归属、用speaker_tag_to_diarization_speaker做校正、用boundary_grid_seconds: 0.01的网格做边界。延迟预算从来不是被某一个数字决定的而是被「你愿意为哪一段误差付多少钱」决定的。【免费下载链接】NVIDIA-Nemotron-3.5-Transcribe-30B-A4B项目地址: https://ai.gitcode.com/hf_mirrors/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
0.32 秒延迟之外把说话人分离与 30B 转写拼成一条流水线【免费下载链接】NVIDIA-Nemotron-3.5-Transcribe-30B-A4B项目地址: https://ai.gitcode.com/hf_mirrors/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B「0.32 秒」这个数字在最近两周的社区文章里被反复引用8 人说话人分离、约 1 亿参数、实时流式、DIHARD III 与 NOTSOFAR-1 上错误率大幅下降。它对应的其实是 Nemotron-3-Diarization 这条专门的分离模型。而眼前这个仓库NVIDIA-Nemotron-3.5-Transcribe-30B-A4B是一个 34B 总参数、4.3B 激活参数、最高支持 1 小时录音的离线语音大模型模型卡里有一句必须被反复强调的话This is an offline model.Internal audio chunking does not make it a real-time streaming ASR service.于是真正的工程问题变成了当一个「0.32 秒级」的流式分离能力被装进一个「离线整段转写」的 30B 模型里流水线该怎么拼本文不讨论发布会的参数罗列只讨论三件事——两条流的时间轴怎么对齐、重叠语音的归属怎么判定、端到端延迟预算怎么分配。所有结论都能在仓库的config.json、processor_config.json与模型卡找到对应证据。一个 checkpoint而不是两个服务大多数「ASR 说话人分离」方案是级联式先跑分离拿到 speaker turns再按 turn 切片送进 ASR最后把两边的文本和时间戳做字符串级别的缝合。这种拼法有两个固有误差源切片边界会切断音素且两套模型的帧率不一致对齐只能靠猜。Nemotron 3.5 Transcribe 把这件事收进了同一个前向config.json里的pe_encoder_config指向ParallelExpertEncoderPT它并列挂着两条分支——一条 32 层、d_model1280、10 个注意力头的 Transformer ASR 编码器和一条来自 Nemotron-3-Diarization 的说话人编码器31 层、hidden_size512、8 个注意力头、num_speakers8。两条分支的输出经 1280 维的IdentityConnector拼接再投影到 2688 维喂给 Mamba-2 / Transformer 混合的 MoE 主干128 个路由专家、每 token 激活 6 个 1 个共享专家、hidden_size2688。这就是「一条流水线」和「两条流水线」的本质区别说话人信息不是后处理附加的标签而是在编码阶段就与声学特征并置进入语言模型的上下文。模型卡把这条路径描述为 speaker-aware perception并给出了直接后果——多说话人 ASR 的均值 cpWER 为 15.80而此前最好的公开组合 DiCoW v3.3 DiariZen 是 16.83。级联方案的天花板被一次联合编码抬高了。值得注意的是底层的规模账语言主干约 3.5B 激活参数加上约 800M 参数的联合音频编码器600M ASR Transformer 约 99M 说话人编码器合计约 4.3B 激活。也就是说那个「1 亿参数的分离神器」并没有消失它成为了 30B 模型里的一个子模块——这解释了为什么它能同时做转写和分离也解释了为什么它不再是 0.32 秒的流式服务。时间轴对齐80ms 一个 token10ms 一个网格对齐问题在联合模型里并没有自动消失只是从「跨进程缝合」变成了「同一张网格上的三次量化」。第一层量化来自前端。processor_config.json写明sampling_rate: 16000、hop_length: 160、win_length: 400、n_fft: 512、feature_size: 128、subsampling_factor: 8——10ms 一帧梅尔谱再经 8 倍下采样得到模型卡所称的「约 80ms 一个音频 token」。这是语言模型能「看见」音频的最小刻度。第二层量化来自 CTC 时间戳头。config.json的ctc_timestamps.decoder_config里upsampling_factor: 2配upsampling_mode: conv_transpose把 80ms 的声学网格插值回 40ms 的词片word-piece网格解码器只有 2 层、16 头、pos_emb_max_len: 5000本质是一个轻量的对齐器而非第二个 ASR。它的词表vocabulary长度 23862前 51 个位置被结构化 token 占满ev:*事件标签 10 个breath、laughter、throat_cough 等、spk:0到spk:15共 16 个说话人标签、sty:stt:*/sty:end:*共 22 个说话风格标签。所以「谁在何时说了什么」在输出层是同一条 token 序列里的不同符号而不是三个服务各自的 JSON。第三层量化来自后处理细化。ctc_timestamps.alignment_config.parameters是一组被训练/调参固化的常数直接决定边界落在哪里参数取值含义boundary_grid_seconds0.01边界搜索的最终网格精度onset_snap_seconds0.08起始点向能量起振处吸附的窗口boundary_max_correction_seconds0.04边界允许的最大修正量maximum_token_len1.0364单 token 最长持续时间秒的约束系数max_word_frames19单次对齐窗口的最大帧数interpolation_enabledtrue是否启用边界插值含 24 组系数与 offset这张表说明一件容易被忽略的事模型输出的start/end并不是原始注意力权重的简单 argmax而是「CTC 后验 → 40ms 网格 → 80ms onset 吸附 → 10ms 网格」的合成结果。做过字幕对齐的人都知道词级时间戳的误差通常不来自识别错而来自边界定义——这组常数正是把边界定义写死的地方。而word_timestamp_config里blank_token_id: 23862、vocab_size: 23863的 1 关系也印证了 CTC 词表是在 23862 类之上追加一个 blank。重叠语音不是二选一而是加权归属大纲里「重叠语音段落的归属判定」是最容易被写成玄学的一节。在这个仓库里它其实有明确的可调参数。对齐阶段的归属是由声学证据与文本后验共同投票的alignment_config给出了三个权重speaker_logprob_weight: 0.6057、speaker_activity_threshold: 0.1881、vad_threshold: 0.4641。换句话说一个词被贴上spk:N既要求说话人分支在该帧的活动概率越过 0.1881 这个较低的软阈值又要求 CTC 后验在候选说话人之间给出区分度两者按约 0.6 : 0.4 的比例融合。低阈值的设计意图很清楚宁可让两个说话人同时活动也不要在重叠段提前判负把消歧留给文本侧的语言模型上下文。而说话人分支自身是流式友好的audio_config.diarization_config里chunk_length: 500、chunk_left_context: 50、chunk_right_context: 50、fifo_length: 40streaming_config再给出fifo_length: 264、speaker_cache_length: 188、speaker_cache_update_period: 222、prediction_score_threshold: 0.25。这套环形缓冲 说话人缓存的配置正是「0.32 秒延迟」得以成立的机制来源——它只依赖固定长度的左右上下文而不是整段音频。但在 30B Transcribe 里这个流式配置被包在一个离线推理流程中前后文被 30 秒的编码器分块encoder_chunk_size_seconds: 30.0重新组织于是流式的低延迟被换成了整段的更高精度。精度的代价与收益都可以量化。模型卡给出的多说话人结果里同一会议语料在两种拾音条件下的差距比模型差异更能说明问题测试集条件cpWER (%)AMI个体头戴麦克风IHM10.29AMI单远端麦克风SDM17.34NOTSOFAR-1个体头戴麦克风IHM14.94NOTSOFAR-1单通道远端麦克风SC25.91CALLHOMECH109 电话对话11.50Mixer 6Channel 414.80cpWER 会先把预测的说话人映射到参考说话人再算词错误率——也就是说归属错了会直接计入错误率不存在「文本对了就算过」的余地。远端麦克风下的翻倍误差指向的是重叠与混响而非词汇量。还有一个可直接用在产品里的实测对比当近场指令要求「只转写离麦克风最近的说话人、不要转写其他人声」时把 LibriSpeech test-clean 语音与 NOTSOFAR-1 远端语音混合WER 为 4.78%换成普通的单说话人转写 prompt同一段音频的 WER 是 27.32%。这不是模型能力差异而是归属判定的边界由 prompt 定义——在双人抢话的会议里你要的可能是前者在圆桌讨论里你要的恰恰是后者。端到端延迟预算把 0.32 秒放进正确的位置先给出一个必须承认的现实在这个仓库的部署形态下你拿不到 0.32 秒的端到端首字延迟。原因不是模型慢而是三处硬约束写在了服务参数里。第一处是入参限制。模型卡明确时间戳请求只接受一条音频、streamfalse、n1。CTC 对齐需要把整段输出与整段音频做单调对齐天然与增量解码冲突。第二处是运行器互斥。要词级时间戳必须VLLM_USE_V2_MODEL_RUNNER0V1 runner并挂载ctc_timestamp_middleware而 DFlash2 草稿模型只在 V2 runner 上运行且--hf-overrides {ctc_timestamps:{enabled:false}}会直接关掉对齐。换句话说「最准的时间戳」与「最高的吞吐」在 vLLM 0.32.0 上是两个部署档位不能同时开。第三处是编码窗口。encoder_chunk_size_seconds: 30.0意味着任何「伪流式」实现的最小等待粒度是分块级别而不是帧级别。模型卡对此的措辞很克制这是内部的加工选择不是 30 秒录音上限也不是流式延迟承诺。所以延迟预算应该这样拆T_e2e T_vad T_enc(chunk) T_prefill T_decode T_align T_post其中真正可被服务端优化的是T_prefill T_decode。仓库给出的锚点是在单张 RTX PRO 6000 Blackwell 上NIM 路径可用 NVFP4 DFlash2 做到 2238 秒音频/秒30 秒录音的转写结果在 0.13 秒内返回而 NeMo Speech 发布日提供的开源 vLLM 集成面向模型开发预期慢约 2 倍。H100 80GB 上的批量吞吐则是 MTP2 约 410 RTFx、MTP8 约 270、DFlash2 K7 约 340、K15 约 260。注意 RTFx 与「单请求延迟」是两件事410 RTFx 指批量负载下每秒处理 410 秒音频不代表单条 30 秒音频 73 毫秒出结果。把 RTFx 当延迟用是这类评测文章最常见的误读。一张可落地的预算表按「先分级、再并行」的思路配置链路环节负责组件量级可调手段端点检测 / 切片应用层 VAD数百 ms切片长度对齐到 30s 整数倍减少 padding声学编码Parallel Expert Encoder随切片线性16kHz 单声道避免重采样引入额外帧PrefillMoE 主干chunked prefill 已开与音频 token 数正相关--max-num-batched-tokens 4096、--mm-processor-cache-gb 0DecodeMTP / DFlash2与输出 token 数正相关MTP2 保延迟、MTP8/DFlash2 提吞吐CTC 对齐2 层轻量对齐器十毫秒级仅在需要时间戳时开启配合 V1 runner后处理cleanup_generation_loops可忽略去除字符/块级重复生成工程上由此得到一个清晰的双档架构在线低延迟档用 DFlash2 V2 runner只做纯文本转写与翻译把说话人标签交给 prompt 让语言模型直接生成离线精修档用 MTP V1 runner CTC middleware产出词级时间戳与 diarization 分段用于会议纪要、客服质检与字幕校准。两档共享同一个 checkpoint不共享同一份启动参数。把流水线跑起来三种取时间戳的正确姿势服务端的关键几步完整命令见模型卡 Quick Start 与 Inference Setupexport VLLM_PLUGINSnemo_speechlm export VLLM_MAX_AUDIO_DECODE_DURATION_S3600 # 默认仅 600 秒 export VLLM_MAX_AUDIO_CLIP_FILESIZE_MB180 export VLLM_USE_V2_MODEL_RUNNER0 # 词级时间戳依赖 V1 runner vllm serve ./NVIDIA-Nemotron-3.5-Transcribe-30B-A4B \ --served-model-name nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B \ --trust-remote-code --dtype bfloat16 --gpu-memory-utilization 0.94 \ --max-model-len 65536 --max-num-batched-tokens 4096 --max-num-seqs 192 \ --enable-chunked-prefill --no-enable-prefix-caching \ --use-replayssm --mamba-backend flashinfer --mamba-cache-mode none \ --limit-mm-per-prompt {audio:{count:6,length:120000000}} \ --speculative-config {method:mtp,num_speculative_tokens:8} \ --reasoning-parser nemotron_v3 \ --trust-request-mm-kwargs \ --middleware nemo.collections.speechlm2.vllm.salm.ctc_serving.ctc_timestamp_middleware--use-replayssm --mamba-backend flashinfer --mamba-cache-mode none与--no-enable-prefix-caching这组参数不要随意改Mamba 层的状态缓存与 KV 前缀复用语义不同混用会让长音频的内存占用失控。客户端侧时间戳只在三个条件同时成立时返回请求带mm_processor_kwargs: {capture_ctc_timestamps: True}、prompt 里要求了说话人标签、且服务端挂了 middleware。import base64 from pathlib import Path from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) PROMPT ( Transcribe this audio with punctuation and capitalization. Include all spoken words and verbal fillers. Write numbers in their standard written form. Put speaker tags spk:0 spk:1 spk:2 spk:3 on the transcription. ) audio base64.b64encode(Path(meeting.wav).read_bytes()).decode() resp client.chat.completions.create( modelnvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B, messages[{role: user, content: [ {type: text, text: PROMPT}, {type: audio_url, audio_url: {url: fdata:audio/wav;base64,{audio}}}, ]}], temperature0, max_tokens16384, extra_body{ chat_template_kwargs: {enable_thinking: False}, skip_special_tokens: False, # 必须保留 spk: 标签 spaces_between_special_tokens: False, seed: 0, mm_processor_kwargs: {capture_ctc_timestamps: True}, }, ) align resp.model_dump()[ctc_timestamps] if align[error] is not None: raise RuntimeError(align[error]) # 对齐失败原因要先检查 tag_map align[speaker_tag_to_diarization_speaker] for seg in align[diarization]: print(f[{seg[start]:.2f} - {seg[end]:.2f}] diar_speaker{seg[speaker]}) for w in align[words]: print(f{w[start]:7.2f} {w[end]:7.2f} {w[speaker]:7} {w[word]})三个工程细节值得展开其一error字段必须前置检查。对齐是单调匹配一旦文本与音频不匹配例如幻觉出一段不存在的语音、或音频被截断结果不是「略微偏移」而是整段失效。把它当异常而不是警告处理能避免下游字幕错位几十秒。其二speaker_tag_to_diarization_speaker是两层系统的接缝。文本侧的spk:N由语言模型自回归生成它在长音频里可能重复、跳号、甚至在两人对话中复用同一个标签而diarization分段来自声学分支说话人数量与出现顺序都是稳定的。用这张映射表把文本标签回落到声学说话人是纠正「标签漂移」的唯一可靠方式。模型卡对此有一句关键提醒评估分离效果时应当用diarization分段而不是词级时间戳——因为词级时间戳的 speaker 字段是把两者融合后的产物不适合作为分离的独立度量。其三采样设置不能想当然。转写、翻译、语种识别用temperature0且关闭思考音频理解类任务才用 0.6 / top_p 0.95 / top_k 关闭并开启推理。把enable_thinking打开去做转写除了变慢还会让模型在文本里夹带推理痕迹。别忽略的四个现实约束说话人上限是 8不是 16。CTC 词表里确实有spk:0到spk:15共 16 个标签但说话人编码器的head_config.num_speakers与流式配置的num_speakers都是 8。标签空间留了余量声学分支并没有。9 人以上的圆桌需要外接分离模型或者按时间段切分。中文是多说话人支持而非领先。语言矩阵里 Chinese Mandarin 的 ASR、翻译、多说话人、code-switching 全部打勾但质量档位是 Supported需要微调才能达到生产水准英语、法语、德语、印地语、意大利语、韩语、葡萄牙语、俄语、西班牙语等才是 Leading。中文会议的 cpCER 参考值是 AISHELL-4 32.91、AliMeeting 34.95——这是含说话人归属的字符错误率与纯文本 CER 不可直接比较但足以说明中文多说话人仍有明确的优化空间。长音频要吃满输出预算。模型卡直说一小时密集对话可能需要约 20000 个输出 token。默认max_tokens16384会把尾部截断而对齐失败又往往表现为「文本短于音频」两者很容易被误判成同一个 bug。生成循环要有兜底。模型卡给出了一个后处理函数把连续重复 ≥21 次的单字符、以及 1–4096 字符块重复 ≥20 次的情况折叠为一份。它只在转写、翻译、语种识别链路上建议启用推理类长答案里这个正则容易误伤 Markdown 表格的分隔线。结语0.32 秒是一个模块指标不是系统指标把这件事讲清楚比复述参数更有价值0.32 秒属于那个约 1 亿参数的流式说话人分离模块它靠固定长度左右上下文与说话人缓存换取低延迟而 Nemotron-3.5-Transcribe-30B-A4B 把它收进 Parallel Expert Encoder用 30 秒编码分块与 80ms 音频 token 换取整段一致性再用 CTC 头把 23862 类词表对齐回 40ms 网格最终以 cpWER 15.80 的成绩压过级联方案。所以「把说话人分离与 30B 转写拼成一条流水线」的正确拼法不是让 30B 模型去追 0.32 秒而是承认两档存在需要秒级响应的场景让流式分离 轻量 ASR 顶在前面需要「谁说了什么、精确到词」的场景把整段录音交给这个联合模型用diarization分段做归属、用speaker_tag_to_diarization_speaker做校正、用boundary_grid_seconds: 0.01的网格做边界。延迟预算从来不是被某一个数字决定的而是被「你愿意为哪一段误差付多少钱」决定的。【免费下载链接】NVIDIA-Nemotron-3.5-Transcribe-30B-A4B项目地址: https://ai.gitcode.com/hf_mirrors/nvidia/NVIDIA-Nemotron-3.5-Transcribe-30B-A4B创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
