MOSS-TD × SGLang Omni 深读：90 分钟多说话人 ASR 如何真正跑起来

核心判断

原文准确描述了一套成熟的长音频 serving 工程，但把“模型能容纳 90 分钟”“优化组件已经实现”“默认请求能可靠返回完整 90 分钟结果”和“公开数字可被第三方复现”四件事写得过于接近。逐项核验后，前两项成立；后两项仍有明显缺口。

模型能力：成立

0.9B MOSS-TD 使用 128K 上下文，把识别、说话人标签和时间戳放入一次自回归输出；约 12.5 audio token/s，使 90 分钟输入约占 67.5K token。

系统结果：有条件成立

单张 H100 80GB 上，文章报告短音频并发 16 达 379.5 audio-s/s，38 分钟会议达 97.5 audio-s/s；算术内部一致，但依赖私有数据、未钉住的代码版本与特定运行参数。

生产承诺：尚未闭环

默认输出预算可能静默截断长转写；极端非语音片段可让贪心解码循环；公开 cookbook 的短音频性能又比文章低约 4.6 倍。

最重要的限定“支持 90 分钟”首先是输入表示与上下文容量声明，不等于默认 API 已经拥有足够的输出 token 预算。开放中的长音频修复记录显示，38.7 分钟样本曾在 HTTP 200 下只返回 18,400 个字符中的 6,782 个；同一修复分支才完成 90 分钟全量转写。调用方若不检查 finish_reason、末尾时间戳和覆盖时长，会把截断误判为成功。

先把模型说清：它不是“Whisper 加一个说话人后处理”

16 kHz 波形切成约 30 秒片段，提取 80-bin log-Mel

Whisper Encoder24 层，hidden 1024；四倍时间合并

投影与长上下文4096→1024 adapter，把音频特征映射到 Qwen3 表示空间

一次自回归输出正文 + [S01] + 起止时间戳

技术报告把系统称为 end-to-end speaker-attributed, time-stamped transcription（SATS）：模型在单次生成里共同预测文字、说话人身份和段落时间，而不是先做 ASR、再用另一个 diarization 模型切人、最后对齐时间。它的工程优势是链路短、全局语境连续，尤其适合跨很远距离仍需保持说话人一致性的会议；代价则是所有结构化结果都继承语言模型解码的失败模式。

CER忽略说话人身份后的字符错误率，主要衡量“字写对没有”。

cpCER先寻找预测说话人与真实说话人的最优置换，再计算拼接字符错误率；同时惩罚转写与归属错误。

ΔcpcpCER − CER，发布方用它近似隔离说话人归属造成的额外损失；但两项若采用不同归一化或样本池，差值可能出现反常负数。

DER说话人日志错误率。文章代码采用 0 秒 collar，是比常见宽容边界更严格的计分设置。

RTF处理时间 / 音频时长。0.021 表示单请求约 47.6× 实时；它与多请求聚合 audio-s/s 不是同一个维度。

真正的主线：音频越长，瓶颈越不像传统 ASR

工作负载	并发	Encoder	Prefill	Decode	系统含义
5 秒	1	8.9%	14.7%	76.4%	单请求仍以解码为主，但短前端开销可见
5 秒	16	38.2%	29.7%	32.1%	批量化 decode 后，encoder/prefill 成为新热点
60 秒	16	13.7%	9.5%	76.8%	生成长度开始压倒固定前端成本
20 分钟	16	11.6%	2.6%	85.7%	长音频的吞吐上限主要由逐 token 解码决定

这张分解表比最终 QPS 更有迁移价值。把并发从 1 提到 16 后，短音频 decode 占比从 76.4% 降到 32.1%，说明批处理确实摊薄了语言模型生成；但 encoder 与 prefill 的相对占比同步升高。到了 20 分钟，哪怕并发 16，decode 仍占 85.7%，说明继续只优化音频编码器不会带来同量级收益。

长度是调度变量，不只是输入字段短片段服务要优先追求大批量、encoder graph 与低排队开销；长会议服务要优先限制并发、预算 KV cache、按音频时长配置输出上限，并监控生成尾部。将两者放进同一个队列、使用同一并发上限，既容易让长请求拖垮短请求 SLO，也容易让短请求的高 QPS 掩盖长请求的显存与截断风险。

优化栈逐层拆解：哪些互补，哪些互斥，哪些只对特定流量有用

Encoder CUDA Graph

为 1–8 个 30 秒片段预捕获固定 shape，跳过 Python 和 kernel launch 开销；超过默认约 4 分钟的桶范围会回退 eager。短音频、批量小 shape 最受益。

torch.compile

以静态 bucket 编译 Whisper encoder，是显式 opt-in；与 encoder graph 二选一。曾使用 reduce-overhead 时和 decode graph 共存触发非法内存访问，后改回默认模式。

4GB CPU LRU Encoder Cache

流水线默认配置把缓存打开，最多 64 条、4GB。对重试、A/B、重复音频有价值；真实 ASR 若大多是一次性输入，命中率不会自动很高。

Decode CUDA Graph

为固定 batch bucket 捕获语言模型单步解码，减少 launch 开销；收益取决于并发能否稳定落入 bucket，也必须正确回收 KV slot。

异步 one-step lookahead

CPU 在 GPU 计算当前 token 时准备下一步元数据，利用 pinned buffer 双缓冲；并发越高越能隐藏 host 工作。对应 PR 在另一套 H200/DP2 环境报告约 +14.4% QPS。

Chunked Prefill + SSE

把长音频 prefill 切成 4096-token 块，与其他请求 decode 交错，避免单个长请求霸占设备；prefill 期间不把中间状态错当输出，流式缓冲还要保留不完整 UTF-8。

这些组件不是可以直接相加的百分比菜单。encoder CUDA Graph 与 torch.compile 互斥；CPU cache 只在重复输入时命中；异步解码的公开增益来自 H200、两 worker data parallel，而文章总表是单张 H100 colocated。把不同硬件、拓扑和 workload 的 PR 增益相加，得不出文章最终性能。

时间线也要分开文章发布后一天，主分支才合入“预语言模型 encoder service”，通过让音频编码与 LM 计算重叠，在 H200、并发 16 的独立测试里再提高约 9% audio throughput。它不能反向解释文章发布时的数字。文章列作下一步的 piecewise prefill graph 已关闭未合并，tensor parallel 仍是 draft，长音频输出预算修复仍开放。

性能数字复核：算术成立，跨文档口径却没有闭合

文章环境是单张 H100 80GB、BF16、单 GPU colocated、贪心解码，max_running_requests=16、decode graph 最大 batch 16、静态显存比例 0.80。Movies 是 800 条、平均约 12 秒的私有短片段；AISHELL-4 Long 是 20 条、平均约 38 分钟的会议。短集每点取 3 次均值，长集每点只跑 1 次，准确率只在并发 16 跑一次。

数据 / 并发	请求吞吐	RTF	audio-s/s	平均延迟	P95
Movies / 1	4.55 req/s	0.022	52.7	0.219 s	0.500 s
Movies / 16	32.79 req/s	0.043	379.5	0.422 s	0.935 s
AISHELL-4 Long / 1	0.021 req/s	0.021	47.0	48.7 s	71.1 s
AISHELL-4 Long / 16	0.043 req/s	0.127	97.5	291.0 s	374.5 s

复算得到 Movies 从并发 1 到 16 的请求吞吐倍率为 7.21×，audio-s/s 倍率为 7.20×，两者吻合；长会议的 audio-s/s 则只提高 2.07×。38 分钟会议单请求平均 48.7 秒，也确实约等于 47× 实时。需要避免的误读有两种：

97.5× 聚合实时不是单条会议 97.5×。并发 16 时单请求 RTF 0.127，即约 7.9× 实时；97.5 audio-s/s 是许多请求同时完成后的设备总产能。
高吞吐不是低延迟。长会议并发 16 把设备总产能翻倍，却把平均单请求延迟从 48.7 秒推到 291 秒，约增加 5 倍。

公开资料的直接冲突同一官方仓库的 cookbook 在核验时仍给出 Movies 并发 16 仅 7.08 req/s、81.98 audio-s/s；文章则是 32.79 req/s、379.5 audio-s/s，相差约 4.6 倍。AISHELL-4 Long 两处数字又大致接近。可能原因包括代码版本、router/worker 布局、预热或数据处理差异，但文章未给 commit hash，公开资料也未解释。因此短音频 headline 目前只能视为发布方在未完全钉住环境中的结果。

准确率：短音频的说话人归属仍是主要短板

文章数据集	CER	cpCER	Δcp	Speaker timestamp DER	解读
Movies	5.92%	13.12%	7.20pp	21.20%	字词识别尚可，但短段、多说话人切换使归属损失明显
AISHELL-4 Long	13.76%	15.07%	1.31pp	10.25%	长会议文字更难，但说话人额外惩罚较小

技术报告的主表提供了另一组发布方结果：MOSS-TD 在 AISHELL-4 上 CER/cpCER 为 14.84/15.83，在 Movies 上为 6.36/12.76，并在四个数据集上与多家闭源 API 比较。它支持模型的基础竞争力，却有三个边界：Podcast 与 Movies 是内部整理数据；不同闭源服务受输入长度和输出格式约束，表中存在缺测；论文主表没有报告时间戳 DER，尽管“time-stamped”是模型核心卖点。

更值得警惕的是，技术报告 Alimeeting 一行的 CER 24.86 高于 cpCER 22.17，导致 Δcp = −2.69。若两者严格在同一归一化和样本池上计算，cpCER 按定义通常不应因为加入说话人约束而更低。报告没有解释这个反常值，说明跨系统表格还需要指标实现和归一化细节才能严谨比较。

解码策略也是正确性的一部分将默认温度校准为 0 的贪心解码，能减少随机性并让 DER 更稳定；但公开问题记录显示，一条 9.7 秒的笑声片段会进入重复 ha ha… 循环直到耗尽输出预算，使单请求慢约 40 倍，并拖低整组吞吐约 19%。评测归一化又可能删掉这些笑声，CER 看不出失败，800 条中的单个异常甚至不一定改变 P95。生产指标必须加入输出长度/音频时长比、重复率、结束原因和最大 token 命中率。

主张审计：证据强度到哪里为止

主张	判断	证据与边界
模型可在单上下文表示 90 分钟音频	已验证	128K 配置、音频 token 密度、技术报告与 90 分钟分支探针相互支持；不等于默认输出不会截断。
单卡 H100 可达到 379.5 / 97.5 audio-s/s	发布方测量	表内算术一致，但数据私有、长集单次运行、代码版本未钉住；短集与官方 cookbook 冲突。
整套优化共同带来最终提升	不能归因	缺少统一 baseline→final 对照；不同 PR 使用 H100/H200、单卡/DP2 和不同数据，且 compile 与 graph 互斥。
质量在 serving 优化后保持不变	部分支持	若干 PR 有小规模或单次 accuracy 对照；早期同 checkpoint 的 SGLang 与 Omni 曾有明显 CER/QPS 差距，关闭 issue 未给出完整最终 parity 复跑。
长音频 API 已默认生产就绪	尚未成立	输出预算、上下文 clamp、超长请求 400 映射和异常时间戳修复截至核验仍在开放 PR。
结果可由第三方完整复现	尚未成立	驱动代码公开，但 Movies 与 Podcast 受许可限制；文章未钉 commit、模型 revision、完整命令和预热策略。

技术报告本身也更像模型发布说明，而非完整训练论文：没有公开训练数据规模、训练 token 数、优化器超参数、训练算力或关键消融；模拟数据描述了 2–12 位说话人、重叠与噪声策略，但真实数据只概括为公开互联网与内部来源。90 分钟长上下文的 corpus-level 45–90 分钟质量验证仍在 roadmap，当前公开的 90 分钟证据是一条拼接探针。

如果真要上线，优先补的不是另一个 graph

按时长分队列。至少拆分短片段与长会议的 admission control、并发上限和 SLO；调度指标使用 audio-seconds/s、RTF 和排队延迟，不能只看 req/s。
输出预算随音频时长增长。同时 clamp 到剩余上下文；对 finish_reason=length、最后时间戳远离音频末尾、输出段覆盖率不足直接判失败。
给贪心循环加护栏。监控重复 n-gram、字符/音频秒比、异常高 token/speech-second；为非语音和音乐单独建集，不让文本归一化把失败删掉。
把基准环境写进结果。钉住代码 commit、模型 revision、驱动参数、worker/router 拓扑、预热轮数、缓存状态和数据清单；至少报告均值、方差、P99/max 与失败数。
质量与系统指标联动。每次吞吐改动都同时跑 CER、cpCER、DER、timestamp 覆盖、finish reason 和极端输出长度，避免“更快”来自截断或提前终止。

一个更诚实的生产表述“在指定单卡 H100 配置与私有基准上，系统展示了高于实时数十倍的聚合处理能力；模型上下文可容纳 90 分钟音频。上线前仍需合入或等价实现时长感知输出预算、极端解码护栏，并用自有长音频集复测。”这比“单卡稳定支持 90 分钟、97.5× 实时”更准确。

独立 Insight：长音频 ASR 已经是一个生成式系统问题

1. 吞吐 headline 属于 scheduler

模型决定“能否表示”和基础质量，调度器决定批量、交错与设备利用率。97.5 audio-s/s 不是 0.9B checkpoint 的固有属性，而是模型、实现、队列、硬件和流量分布的联合函数。

2. 90 分钟是双预算问题

长上下文解决输入预算，完整转写还要解决输出预算。只扩展 max_position_embeddings，却保留固定 max_new_tokens，会制造最危险的“HTTP 200 静默不完整”。

3. 尾部正确性会反噬平均吞吐

一个笑声循环既是语义失败，也是调度失败：它占住 KV cache、推高 max latency、降低整批 QPS。ASR 系统不能把解码异常只交给 CER 评测。

4. 最佳配置应随长度切换

短音频值得投入 encoder graph 与大 batch；长音频更需要 decode、KV 和预算治理。下一步合理方向不是为所有请求再叠一个开关，而是 duration-aware routing 与分层容量规划。

因此，这篇文章最值得带走的不是某张最终表，而是一种性能分析方法：先按音频时长和并发画出 encoder / prefill / decode 的占比，再决定优化对象；每个速度增益都必须和完整输出、说话人归属、时间戳、尾部失败一起验收。对生成式 ASR 来说，系统吞吐与模型正确性已经无法分开治理。

证据边界与资料索引

本文完整核对原帖所链接长文、MOSS-TD 技术报告、模型卡、SGLang Omni 源码与公开 benchmark/issue/PR。性能表是发布方测量，本轮未拥有 H100 环境，也未取得私有 Movies/Podcast 音频，因此只做算术复算、源码默认值、版本时间线和跨文档一致性审计，不声称独立复现实验。

Yichi Zhang 原帖与完整 X Article：Optimizing ASR Models to Transcribe 90-Minute Multi-Speaker Audio。
文章的公开 Markdown 版本：机制、profiling、benchmark 与限制的主要来源。
MOSS Transcribe Diarize Technical Report与官方模型卡：模型结构、上下文、训练数据概况与质量表。
SGLang Omni 仓库及官方 cookbook：实现默认值与公开基准对照。
ASR 优化路线图 #924、早期 parity 问题 #959、贪心解码循环 #975。
异步解码 PR #966、Encoder CUDA Graph PR #973、torch.compile 稳定性 PR #1046、发布后 encoder/LM overlap PR #1045。
长音频输出预算 PR #1034、piecewise prefill graph PR #1035与tensor parallel draft #1041：用于区分已合入能力与后续工作。

返回页首 ↑