英文题目：Argmax Pro: Frontier-level Real-time Speech-to-text with Speakers and Custom Vocabulary on Mobile Devices
会议身份：
conference:interspeech:2026:conference-paper-id:angus26_interspeech
来源为官方会议 PDF；图片依据原页像素，表格数字依据原文引用。PDF 文字层不视为原始 TeX，未可靠恢复的结构不作推断。
标签：#模型融合 #端侧运行 #流式处理 #语音识别 #说话人分离标注
评分：5.0/10 | 创新 1.2/2 | 技术严谨 1.0/1.5 | 实验充分 0.2/1.5 | 清晰度 0.7/1 | 影响力 0.8/1.5 | 开源 0.0/1.5 | 可复现 0.1/0.5 | 工程/实践 1.0/1.5
排名：后50% | 文档类型：系统技术报告
👥 作者与机构
- Dylan Angus：机构信息未能从会议 PDF 纯文本可靠映射
- Chen Cen：机构信息未能从会议 PDF 纯文本可靠映射
- Berkin Durmus：机构信息未能从会议 PDF 纯文本可靠映射
- Arda Ibis：机构信息未能从会议 PDF 纯文本可靠映射
- Brian Keene：机构信息未能从会议 PDF 纯文本可靠映射
- Andrey Leonov：机构信息未能从会议 PDF 纯文本可靠映射
- Blaise Munyampirwa：机构信息未能从会议 PDF 纯文本可靠映射
- Zach Nagengast：机构信息未能从会议 PDF 纯文本可靠映射
- Arda Okan：机构信息未能从会议 PDF 纯文本可靠映射
- Atila Orhon：机构信息未能从会议 PDF 纯文本可靠映射
- Eduardo Pacheco：机构信息未能从会议 PDF 纯文本可靠映射
📌 核心摘要
该系统处理移动端实时麦克风流式音频，输出带说话人标签的文字流并支持用户定制词表，难点在于离线大模型直接分块流式化会损失精度，定制长尾词与多人嘈杂场景在端侧难以兼顾低延迟与功耗。流式推理模块先以中间结果可修正机制逼近离线精度，上下文偏置模块再用独立连接主义时间分类声学模型做关键词增强，说话人分离标注模块最后用合成数据微调版本附加说话人身份，三者并行运行于移动端神经加速单元。与云端方案相比，其机制差异在于全部推理保留在本地并以神经加速单元保障全天电池与热稳定。在定制词表任务设置下，Argmax Pro的词表规模指标为3000词，高于云端平台的词表规模指标不到500词。结论仅适用于作者声称的iOS与安卓消费级移动设备场景，在强噪声、重叠语音与长时高温运行下的外推尚未验证。原文未披露训练、推理或部署成本。
🔗 开源与复现资源
- 第三方资源：https://github.com/ggml-org/whisper.cpp — 链接可访问（HTTP 200）
- 第三方资源：https://huggingface.co/nvidia/parakeet-tdt-0.6b-v2 — 暂时无法访问 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入是什么，输出是什么，为什么手机实时转写这么难？
这篇论文的输入是手机麦克风持续采集的音频流，目标输出是带文字、带说话人标签、且支持用户专有名词的转写结果。也就是说，系统一边听一边吐字，同步标出这句话由哪位说话人说出，遇到人名、公司名、产品名这类长尾词保持高召回。
对刚进入语音领域的同学，白话先行：语音转文本就是把声波变成文字；说话人日志就是回答每 1 秒由谁在说话；自定义词表就是用户事先给一份希望认准的词单；端侧推理就是全程在手机上计算，音频与文本保留在本地处理；上下文偏置就是让模型在解码时优先输出词单里的词。
难点在于 3 个约束同时成立。第一是实时：音频持续到达，文字输出持续跟随，且延迟抖动小。第二是富功能：字认准的同时，还要切分说话人并认准专有名词，这通常要求多个大模型协同。第三是手机预算：3 个十亿级 Transformer 长时间同时运行，对功耗、温度与前后台资源分配提出很高要求。论文的中心目标正是：在手机本地同时交付实时性、前沿准确率和说话人与词表功能。
云端方案与第一代端侧方案各解决了什么，又留下了什么？
论文先把相关路线分成两类。同输入同目标的一类是云端富功能语音识别平台，代表是文献中的 Deepgram 与 AssemblyAI 文档。它们的做法是把音频传到服务器，用大模型做流式解码，支持中间结果逐步更新、最终结果锁定，以及自定义词表等功能。特点是功能完整、模型规模大，论文归纳其代价集中在延迟可靠性、服务间歇可用性、按音频分钟计费与数据隐私方面。
另一类是第一代端侧语音识别系统，论文点名了 whisper.cpp 这类开源实现作为参照。它们把模型搬到本地，支持隐私保护与离线可用，论文指出其在实时模式下的功能完整度与准确率仍有提升空间。换句话说，本地能跑与本地好用之间仍有距离需要跨越。
还有 3 条同组件路线被直接继承。转写主干是 Parakeet v2，原文称其为当前前沿的预录制语音转文本模型；偏置分支是 Canary v2 CTC，配合 CTC-WS 词发现算法做上下文偏置；说话人分支是 Streaming Sortformer v2，是流式说话人切分的前沿模型。论文把自身定位为统一实时推理系统，把这 3 条已有的前沿组件编排到手机上，并补齐流式化、词表扩展与鲁棒性三块能力。
论文把大目标拆成了哪四个可操作问题？
论文在引言末尾把要解决的挑战写成 4 条，每条都对应一个可检验的动作。第一，Parakeet v2 原生支持预录制输入，英伟达 NeMo 自带的分块流式算法存在准确率与延迟的权衡，目标是做到预录制与实时流式输入下的准确率持平。第二，单靠通用模型达到前沿的上下文语音识别准确率存在难度，目标是有效利用 Canary v2 CTC 做上下文偏置。第三，Streaming Sortformer v2 在学术基准上表现优异，在生产中对声学条件、说话人响度与背景噪声的变化更为敏感，目标是提升真实鲁棒性。第四，多个十亿级模型在手机上长时间实时运行，目标是做到全天电池续航、发热稳定且与其他应用和谐共存。
对初学者要理解，这 4 个问题分属不同运行阶段：第一个是推理协议问题，第二个是词汇知识注入问题，第 3 个是训练数据覆盖问题，第 4 个是部署与调度问题。论文后续的方法全景正是按这个顺序组织，一个样本走完的路径是：音频流进入转写分支吐字，词表分支提升专有名词召回，说话人分支给出说话人标签，3 路结果在端侧推理框架下对齐输出。
Argmax Pro 的全景是什么，谁负责什么？
Argmax Pro 被描述为统一实时推理系统，编排 3 个前沿十亿级 Transformer 模型，分别承担语音转文本、说话人日志与自定义词表。按论文的写法，转写主干是 Parakeet v2，偏置模型是 Canary v2 CTC 经由 CTC-WS 算法接入，说话人模型是经合成数据微调的 Streaming Sortformer v2。部署层则分别面向苹果神经网络引擎、高通与联发科的神经网络处理单元以及谷歌张量芯片做优化。
沿一个会议录音样本走一遍：手机采集的连续波形先进入流式切分，Parakeet v2 分片持续产生文字流，其中一部分是可更新的中间结果，一部分是锁定的最终结果；与此同时，Canary v2 CTC 分支用用户词表对解码做偏置，使词表中的词更易被发现；说话人分支则增量输出每 1 帧所属的说话人，最终 3 路按时间对齐成带说话人的转写。论文强调的目标是在手机上同时交付这 3 路能力，并达到可比肩云端富功能系统的水平。原文公开的融合细节集中在分工与数据流向，融合公式与阈值细节、端到端延迟分解属于待补参数，复述时以分工与流向为准。
非流式原生模型怎么做流式：中间结果与最终结果如何分工？
Parakeet v2 原生支持预录制音频，整段音频可见时模型能利用完整上下文，这是它准确率高的条件之一。一旦切成流式分块，模型每次只能看到局部，后文信息缺失容易在边界词上形成误差，这就是 NeMo 自带分块算法呈现准确率与延迟权衡的原因。
论文的做法是沿用作者团队在 WhisperKit 工作中提出的流式推理算法，其关键能力是允许模型在定稿前修正自身的输出。具体操作是把输出文字分为两类：中间的、可更新的转写与最终的、锁定的转写。系统先快速给出中间结果保证跟手，等更多音频到来后再修正并锁定为最终结果。云端平台通常也提供这两类输出，论文的目标就是在端侧复刻这种体验，从而实现预录制与实时流式输入之间的准确率持平。
流式语音转文本 × 中间结果与最终结果： 流式语音转文本负责在音频不断到来时持续输出文字，中间结果与最终结果负责区分可修改与不可修改的输出：前者允许模型在看到更多后文后纠正已吐出的词，后者才锁定写入，二者搭配的理由是流式分块本身会截断上下文造成割裂，新增作用是让非流式原生模型也能在延迟与准确之间先给后改，而不是 1 次定死。
论文公开的细节集中在算法选择与输出分类上，分块时长、前视长度、定稿策略与重解码开销、持平结论对应的词错率数字与测试集属于待补参数。复现时可把分块与定稿策略作为需要补齐的配置项，机制复述以纠错式流式输出为准。
自定义词表怎么做：Canary 偏置分支为何能撑到 3000 词？
通用模型记住每个用户的专有名词存在难度，这是长尾词误差的主要来源。论文的思路是保留主模型通用能力，另用一个 CTC 模型做词发现与偏置。CTC 模型输出帧级后验，适合快速扫描音频中是否出现词表词，再把这种倾向反馈给解码过程。Canary v2 CTC 在这里的分工是提供声学词证据，CTC-WS 的分工是以高效的词发现方式把大规模词表映射为可执行的偏置操作。
上下文偏置 × 自定义词表： 上下文偏置负责让通用声学语言模型更偏向特定词串，自定义词表负责由用户或开发者提供这些词串如人名公司名产品名，前者是计算机制，后者是输入来源，搭配理由是单靠通用模型记不住长尾专有名词，组合意义是把开放词表识别转化为给定词表下的加权发现过程。
论文报告的关键规模点是自定义词表可扩至 3000 词且在手机上保持运行时延迟表现，而对比的大多数云端平台限制在不到 500 词。这个对比直接关系到可用性：人名公司名产品名很容易就超过几百，词表上限决定了开发者能否 1 次导入完整名单。
下表提出的问题是：在相同自定义词表功能下，端侧系统与云端平台的词表规模上限与延迟代价有何差异，比较条件是论文原文陈述的运行时延迟影响，指标方向是上限越大越好、延迟增加越小越好。
| 系统类型 | 功能 | 词表规模上限 | 运行时延迟影响 | 对比含义 |
|---|---|---|---|---|
| Argmax Pro 端侧系统 | 自定义词表 | 3000 words | without impacting runtime latency | 大词表下保持手机实时 |
| 多数云端平台 | 自定义词表 | less than 500 words | 未在原文给出延迟代价 | 上限较小不适合大名单 |
表后解释如下。论文显示的主要收益是词表容量更大，3000 对不到 500，且明确声明手机端运行时延迟表现保持稳定，这是可部署性的关键。代价与限制同样要读出：原文公开的曲线集中在容量与延迟声明上，关键词识别准确率随词表增大的变化、误触发率与延迟的实测曲线、3000 词是硬上限还是测试配置属于待补参数，复现时需要补测不同词表规模下的召回与误报。论文还指出另有投稿专门分析野外人名与公司产品名的关键词准确率并称达到前沿，本篇正文公开的范围限定为存在该外部验证，数值引用以那篇投稿为准。
说话人切分怎么做：合成数据补的是哪类真实变化？
说话人切分在学术基准上容易显得已解决，因为基准的信道、响度与噪声相对干净。论文来自生产的观察是，Streaming Sortformer v2 对真实变化更为敏感，具体包括声学条件差异、说话人响度差异与背景噪声。这些因素会改变说话人嵌入的分布，使到达顺序与聚类逻辑漂移。
论文的修复动作是微调：用合成数据建模这些真实变化，合成工具为 FastMSS。白话说，就是用仿真生成大量多说话人会话，主动加入不同的房间、距离、响度与噪声，再拿这些数据继续训练切分模型，使其在训练时就见过生产中的复杂条件。
说话人日志 × 流式说话人切分： 说话人日志负责回答谁在何时说话，流式说话人切分负责在音频流到达过程中增量维护该答案，前者是任务目标，后者是运行约束，搭配理由是会议记录等场景不能等录音结束再切分说话人，组合意义是在延迟约束下持续更新说话人标签并与转写文字对齐。
原文公开的细节集中在合成数据微调以建模真实变化这一方法选择上，微调数据量、合成配比、训练轮数、冻结参数范围、监督信号构造方式、微调前后在公开基准与生产集上的切分错误率对照属于待补参数。复现时可把合成条件分布与评估协议作为需要补齐的配置项。
三个大模型如何在手机上长时间跑而不发烫掉电？
部署是论文强调最具挑战的部分。3 个十亿级 Transformer 同时实时运行，对中央处理器与图形处理器占用、与其他应用的资源协调、长时间运行的功耗与温度都提出很高要求。论文的选择是把计算卸载到专用加速器：在苹果手机平板与电脑上利用苹果神经网络引擎，在安卓侧针对高通与联发科神经网络处理单元以及谷歌张量芯片做优化。
端侧推理 × 神经网络加速器： 端侧推理负责把计算放在手机本地完成，神经网络加速器负责以低功耗高并行方式执行 Transformer 算子，前者是部署选择，后者是硬件分工，搭配理由是 3 个十亿级模型长时间实时运行会挤占 CPU 与电池，组合意义是把持续负载卸载到苹果神经网络引擎与高通联发科与谷歌张量芯片的专用单元以维持发热与续航稳定。
论文报告的重点是设计目标与手段，即全天电池续航、发热稳定与最小资源争用，并点名了所用的硬件单元，实测续航小时数、功耗瓦数、温度曲线、内存占用、与其他应用并跑时的帧率影响属于待补测量项。部署结论表述为采用了专用加速器卸载的方案，复现与选型时可自行测量长时间运行的功耗与热曲线。
训练与构造分别动了哪些参数，哪些没有动？
这篇论文不是从零训练声学模型的论文，方法职责更多是推理协议、偏置接入、微调与部署。按证据逐项交代：转写主干 Parakeet v2 是直接调用已有前沿模型并做流式化，原文未说明对其做继续训练；偏置分支 Canary v2 CTC 是 harness 调用并经 CTC-WS 接入，原文未说明更新其权重；说话人分支 Streaming Sortformer v2 明确做了微调，监督来源是合成数据所建模的真实声学变化，但优化器、学习率、轮数、冻结策略与梯度路径均未报告。
合成数据 × 真实声学变化： 合成数据负责可控地生成多说话人与噪声组合，真实声学变化负责指代生产中遇到的响度差异混响与背景噪声，前者是构造手段，后者是拟合目标，搭配理由是学术基准覆盖不了生产中的长尾条件，组合意义是用 FastMSS 思路的合成会话去微调切分模型以缩小基准与现网之间的差距。
对初学者要建立正确的学习依赖：没有报告训练细节不等于没有训练，只是本篇未公开可复述的超参数；同样，参数冻结未知时不能推定系统输出确定，也不能从模型名称推定实现版本。复现时应把说话人微调当作唯一明确的训练动作，把转写流式化与偏置接入当作推理与检索计算，把缺失的优化配置列为必须向附录或代码追问的清单。
数据、协议与指标按原文能交代到哪一步？
实验条件是这篇短文最薄弱的一环，需要如实说明边界。数据方面，正文没有给出转写评估集名称、时长、采样率、划分、信噪比分布或说话人数分布；说话人评估方面，只提到学术基准与生产使用，但未点名具体基准与生产采样协议；自定义词表方面，提到另有投稿在野外 earnings 场景下评测人名与公司产品名，但本篇未给出该评测的数据构成与指标定义。
协议与指标方面，论文没有定义词错率、关键词召回、误触发率、切分错误率、实时系数或首字延迟的计算口径，也没有说明聚合对象是按句、按文件还是按说话人平均，更没有报告统计显著性与重复次数。硬件预算方面，只点名了苹果、高通、联发科与谷歌的加速器类别，未给出具体机型、系统版本、功耗测量方法与后台负载条件。
因此本节的结论是：可复述的实验条件仅限于模型选型、流式输出分类、词表规模点与加速器类别，凡涉及准确率比较都缺少可核对的协议，读者不应把设计目标当作已验证结果。
主结果是什么，哪些数字是论文真正给出的？
论文直接报告的定量点非常少，核心是自定义词表规模的可扩展性。正文明确写出可扩至 3000 词且不影响手机运行时延迟，以及多数云端平台限制在不到 500 词。这两个数字是全文唯一可核对的规模对照，应作为主结果呈现，而不是用转写准确率来替代。
下表提出的问题是：统一实时推理系统由哪 3 个模型分担哪些子任务，词表规模证据如何支撑富功能主张，表中规模数字的单位与条件均保留原文写法，指标方向是功能覆盖越全、词表上限越大越好。
| 子系统 | 基础模型 | 承担任务 | 规模证据 | 运行条件 |
|---|---|---|---|---|
| 转写分支 | Parakeet v2 | speech-to-text | three billion-scale transformer models | real-time inference system |
| 偏置分支 | Canary v2 CTC | custom vocabulary | 3000 words | without impacting runtime latency |
| 切分分支 | Streaming Sortformer v2 | speaker diarization | less than 500 words 为云端对照 | on mobile devices |
表后解释如下。论文显示的组合收益是单系统同时覆盖转写、说话人与自定义词表，且词表上限明显大于云端常见限制，这支持其 peer alternative to cloud 的定位主张。但必须同时读出反例与代价：本篇没有给出任何词错率、说话人错误率、延迟毫秒数或功耗数字，3 个模型的协同开销、偏置带来的误报代价、切分微调的泛化边界均未量化，因此该表只能证明功能编排与规模点，不能证明前沿准确率已在手机上复现。重提结果时新增的适用条件是：当应用依赖大词表专有名词且需离线可用时，该架构值得尝试；当应用以通用词错率最低为唯一目标时，本文证据不足以做选型结论。
如果拿掉一路分支或换掉流式策略会怎样？
消融的本意是固定其他条件，只动一个部件，看指标如何变化。按原文证据，这篇论文没有报告任何消融表：没有比较有无 CTC-WS 偏置时的关键词召回，没有比较 NeMo 分块与新流式算法在相同延迟下的词错率，没有比较微调前后切分模型的错误率，也没有比较有无 NPU 卸载时的功耗与发热。
在缺少对照时，唯一可做的是按机制推演待验证的假设，而不是给出结论。例如，若拿掉偏置分支，预期长尾专有名词召回下降但误触发可能降低；若拿掉说话人分支，转写文字仍在但会议可读性下降；若改回简单分块而不做中间结果修正，预期边界词错误上升。这些都是可能与待验证的表述，不能写成论文显示。复现者若要补消融，应先固定音频集与延迟预算，再每次只切换一个分支，并同时记录准确率、误报与延迟 3 类指标，避免只看单一指标得出偏颇结论。
哪些边界没有评测，哪些推论不能做？
论文的未评测边界需要逐项列出。第一，准确率持平的声明缺少预录制与流式同集对照，没有词错率数字，不能推定流式化无损。第二，前沿上下文准确率的声明指向另篇投稿，本篇没有关键词精度召回数字，不能把词表容量大等同于识别更准，也不能推定误触发率更低。第三，真实鲁棒性微调缺少合成配比与生产评估协议，不能推定所有噪声与响度下都改善，总体趋势不等于每组都成立。第四，电池与发热目标缺少长时间实测，不能承诺续航与温度得到改善，训练资源、推理开销与实际延迟应分别讨论。
相关性不是因果的提醒同样适用：即使未来补测发现端侧与云端准确率接近，也不能直接归因于某 1 个分支，必须通过受控消融分离贡献。缺失证据不是技术错误，但读者在引用时应使用支持与可能的分级表达：凡原文直接写出的规模与部署选型用报告，凡机制合理但无数字的用支持，凡超出证据的用可能待验证。
要复现这套系统，先做什么，需要补哪些验证？
复现的第一步是还原可运行基线，而不是直接复刻 3 个大模型的联合优化。建议先用公开的 Parakeet v2 与 Canary 类 CTC 模型在预录制集上跑通转写与词发现，再接入 CTC-WS 逻辑验证 3000 词规模下的检索延迟，接着用流式协议把输出拆为可改的中间结果与锁定的最终结果，最后再接入流式切分模型并按时间对齐。部署侧应先在一种加速器上跑通单模型，再逐步叠加到 3 模型并行，并记录内存、功耗与温度。
关键信息条件按原文保留：转写主干为 Parakeet v2，偏置模型为 Canary v2 CTC 经 CTC-WS 接入，切分模型为经合成数据微调的 Streaming Sortformer v2，流式算法沿用 WhisperKit 报告的思路，加速器覆盖苹果神经网络引擎与高通联发科与谷歌张量单元。论文本身未声明代码与权重公开状态，正文参考文献指向的第三方实现中，whisper.cpp 仓库当前可用，而英伟达 Parakeet 模型卡链接在本次未能确认可达，因此不应写成系统已开源可下载，复现前需自行确认各模型权重许可与移动端转换工具链。
还需补的验证至少三项：相同测试集上的预录制与流式词错率对照，不同词表规模下的关键词召回与误触发曲线，以及多机型长时间运行的延迟、功耗与发热记录。只有补齐这三项，才能判断该系统在目标场景下是否真正可替代云端方案。
何时值得尝试这条路线，一句话如何带走？
回到开场的问题：输入是连续音频流，输出是带说话人与专有名词的实时文字，约束是手机预算与离线可用。Argmax Pro 的回答是用分工明确的 3 模型编排来拆解难题，转写保通用准确，偏置保长尾词汇，切分保说话人结构，加速器保续航与发热，中间结果机制保流式体验。
何时值得尝试很具体：当应用是会议记录、医疗法律等高风险记录或视频字幕，且必须离线、需保护隐私、有大量人名产品名，同时能接受先行验证功耗时，这条路线值得投入。反之，若场景是通用短语音听写且云端可用，或词表很小且对误触发零容忍，则无需照搬 3 模型全套，可先只验证偏置或切分其中一路。
常见的误解是把大词表上限当作准确率保证，或把无训练等同于确定性输出，或把加速器支持当作所有机型都已优化。按原文纠正：上限只是容量证据，冻结未知时输出行为仍需实测，加速器类别不等于具体机型已调优。带走的一句话是：该工作给出了手机端富功能实时转写的可行编排与一个可核对的 3000 词规模点，但前沿准确率与全天续航仍是待补数字验证的主张。
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
- 评分规则：type-aware-v1
- 评分模型：muse-spark-1.3-contributor
- 评分请求协议：openai_responses