为什么我们把语音AI装进设备，而不是云端

把语音功能做进App时，默认路径是把音频送到服务器。麦克风采集声音，打包成WAV或Opus，流式传输到API端点，取回带有识别文本的JSON，业务逻辑再基于文本运转。这种模式之所以占据主流，不是因为它是最好方案，而是因为历史上它是唯一能在真实生产模型规模下跑通的方案——开放ASR模型太大，端侧模型质量明显落后云端，移动硬件也无法在后台持续跑ML推理而不在一小时内榨干电池。

VoxRT团队从第一天起就为端侧而建，没有从云端迁移过来，而是一开始就选了另一条路。

让团队改变思路的经济账

假设一个语音笔记App有10万月活用户，平均每人每月口述20分钟，那就是200万分钟音频需要转写。按主流云ASR供应商约0.004美元/分钟的偏低费率计算：200万 × 0.004 = 每月8000美元，一年9.6万美元，仅仅用于转写，还不含唤醒词、关键词识别和TTS。

端侧的逻辑完全不同。工程投入是前置的，不随用户增长。集成端侧SDK通常需要2到6周（单平台起步），跨平台或需要定制优化时更长。持续成本也存在：模型版本更新后的SDK升级、设备特定回归的调试、新OS版本的验证。但这些都不随用户分钟数线性增长，单位可变成本趋近于零。

有一点不宜掩饰：端侧SDK并非普遍免费。VoxRT的技术栈采用混合许可证（开放包装层、专有运行时），其他端侧语音厂商则采用按席位、按部署或收入分成定价。对多数团队而言，工程成本加许可费合起来，在规模化时仍然优于按分钟计的云端定价，但完整判断需要把两边都算进去。

盈亏平衡点取决于用户基数。对上述假设的App，几千名付费用户就足以让端侧在经济上胜出。如果预期App达到数十万甚至数百万用户，端侧几乎无一例外地在长期占优。

这个计算还忽略了二阶效应：没有网络冷启动延迟，没有峰值负载下的限流，增长时没有扩容成本，也不需要后端团队监控ASR管线可用性。对规模化运行的语音笔记App，前两项最重要；对大型App中偶尔使用的语音功能，移动SDK的工程承诺可能即使按分钟算最终划算，也未必值得。

RTF（Real-Time Factor，实时因子） 是端侧语音推理中最常用的性能指标，定义为处理音频所需时间与音频本身时长的比值。RTF = 1.0 表示处理 1 秒音频耗时 1 秒，刚好达到实时；RTF < 1 表示比实时更快，留有余量；RTF > 1 则意味着推理跟不上音频到达速度，会出现卡顿或丢帧。文中提到的“0.97% RTF”实际是 0.0097，即处理 1 秒音频仅需约 9.7 毫秒，这个量级对浏览器内的语音 UX 已经足够即时。

RTF 的测量高度依赖前提条件：设备型号、CPU 核心与频率、是否启用 SIMD 指令、线程数、批处理还是流式分块、音频采样率与位深。因此单独一个 RTF 数字很容易误导集成者。负责任的发布方式是给出多设备矩阵、明确测试集与硬件配置，并区分平均 RTF 与 p99 分块延迟——后者决定了最坏情况下的卡顿体验。

端侧干净胜出的三类场景

隐私是法律要求。 带语音笔记的医疗App、记录客户会议的法律工具、个人日记。这些场景里，把音频送到第三方服务器不是性能问题，而是合规问题。当音频从未物理离开设备时，HIPAA、GDPR和EU AI Act的运营都更简单。向律师证明用户语音从未发送到服务器，在架构上根本无法发起网络调用时容易得多。

App必须离线工作。 巡检员、建筑工人、测量员的现场工具，飞机上或没有数据漫游国家的旅行App，偏远地区医护和急救人员的工作流。如果用户在这些场景需要语音输入，纯云端不是选项。你可以通过缓存构建离线兜底，但如果端侧部分已经在做了，为什么还要并行维护云端路径？

延迟必须低于100毫秒。 对唤醒词和热词检测，“用户说了、App响应”的循环必须感觉即时。任何网络往返都会破坏体验。即使在完美的5G上，光是RTT就要损失50到150毫秒，再加上服务器端推理。端侧唤醒词推理通常在50到200毫秒端到端之间。对唤醒检测流程，这就是“能用”和“烦人”的区别。

这三类不是边缘案例，而是真实语音用例的相当大一部分：隐私敏感App、离线优先工具，以及更大语音栈中始终在听的触发层。

RTT（Round-Trip Time，往返时延） 指数据包从客户端发出到收到服务器响应所经历的总时间，包含去程、服务端处理与回程三段。在移动网络上，RTT 通常远高于理论带宽所暗示的延迟：即便在理想 5G 下，物理传播、基站调度与协议栈开销也会带来数十到上百毫秒。

对于唤醒词这类“始终在听”的触发层，用户的感知阈值非常敏感：超过约 100 毫秒就明显感觉“慢半拍”，超过 200 毫秒则接近被认为卡顿。云端方案必须额外叠加 RTT 与服务端排队、推理时间，而端侧唤醒词推理在同一设备上完成，省去了网络往返这一不可控项。这也是为什么低延迟场景往往不是“云端优化得不够好”，而是架构上就无法与端侧竞争。

端侧真正困难的地方

不写这一节，这篇文章就不诚实。

模型大小与质量的权衡。 要把模型塞进100 KB（VoxRT的唤醒词），必须深度裁剪架构。唤醒词接受了固定触发短语（“Hey Assistant”）并只发布一个经过验证的模型，而不是每个用户定制训练一个。这对场景有效，但意味着无法在不公开训练管线的情况下提供自定义触发短语。流式ASR模型更大（中等模型约60 MB权重），仍远低于云供应商服务端运行的多GB模型。

硬件碎片化是真实存在的。 技术栈覆盖iOS、Android、浏览器（通过WASM）和Linux（树莓派、Jetson、服务器）。共享的Rust运行时可编译到各目标平台，但每个目标仍需自己的基准测试运行和构建调优，针对本地SIMD扩展、内存布局和音频API约定。发布一个跨所有平台的单一“RTF 0.05”数字是不诚实的。现实是不同设备上有5到10个基准点，每个都有自己的前提条件。这比云供应商面对的工作更多，因为他们的基础设施是统一的，而端侧不是。

更新通过SDK发布周期走。 如果云ASR有bug，把修复推到服务器，明天所有人都用上。对端侧，bug意味着新SDK版本、npm/pip/CocoaPods更新，用户必须升级。移动开发者从任何原生库都熟悉这种痛苦。运行时和SDK绑定之间稳定的C ABI能降低破坏性变更频率，但无法消除用户升级这一步。这是尚未解决的摩擦。

基准测试需要纪律。 挑一个设备发布一个漂亮数字很容易。发布一个多设备矩阵，包含实测RTF、不同核心上的不同CPU预算、p99分块延迟，则很难。VoxRT刻意让自己更难，因为另一种做法会误导集成者，让他们基于与自身硬件不匹配的预期去构建。每次新旗舰手机发布，问题都会累积。

生产环境的端侧调试更薄弱。 云ASR在特定用户上回归时，服务器团队有日志、指标和回放音频的能力。端侧，你的遥测范围仅限于能从用户设备拿回而不违反当初选择端侧所基于的隐私前提。VoxRT只通过选择加入的遥测回传RTF计数器和检测分数，即便如此也以用户愿意分享为界限。诊断某个特定芯片家族的回归，往往意味着买那台设备在本地复现。

SIMD（Single Instruction, Multiple Data，单指令多数据） 是一类 CPU 指令集扩展，允许一条指令同时处理多个数据元素，对矩阵乘法、卷积等语音模型的核心算子有数倍加速效果。常见实现包括 x86 的 AVX/AVX2/AVX-512、ARM 的 NEON，以及浏览器中通过 WebAssembly 暴露的 SIMD128。

SIMD128 是 WASM 的 128 位向量扩展，Chrome 91+、Firefox 89+、Safari 16.4+ 均已支持。在此之前，浏览器内的语音推理只能走标量路径，典型只能达到 2-4 倍实时，难以支撑严肃的端侧 ML。启用 SIMD128 后，同样模型可降到低于 1% 的 RTF，浏览器才真正成为一等推理目标。这也是文中反复强调“针对本地 SIMD 扩展做构建调优”的原因：不同设备与浏览器的 SIMD 支持程度不同，基准测试必须逐平台分别进行。

这些权衡最终落在哪里

以下数字不是推销，而是证据：端侧路径在2026年有真实的工程形态，不只是理想。

一个能塞进100 KB、在15美元的树莓派Zero 2 W上只占用单个A53核心5.3%的唤醒词模型，处于当今端侧能力的极端。在Pi 4 B或Pi 5上降到1%到2% CPU。迫使目标定为100 KB的约束（单一触发短语、固定、SDK内无自定义训练）是真实限制，不是功能。发布它们是因为在如此便宜的硬件上，替代方案是干脆不发布。

在中端安卓（骁龙662级别）上以3% CPU运行的语音活动检测器，是让始终在听的麦克风采集不毁电池的上限。VoxRT只在移动端发布VAD，不在浏览器，因为持续音频采集的WASM配置差异足够大，尚未证明工程投入合理。

在Chrome WASM中以0.97% RTF、在骁龙662上以16% RTF运行14个固定英语命令的关键词识别，让浏览器语音UX感觉即时。完整浏览器栈（含运行时）打包约1.47 MB，小到对多数App无所谓，大到对针对移动3G优化的落地页有影响。

流式ASR（NeMo FastConformer，60 MB权重）在移动端实时运行。部分转写结果在用户还在说话时就到达，静音超时后最终确定。这个模型三年前不可能端侧发布，如今是出货选择。

这些数字位于github.com/VoxRT的README中，附带测试集、硬件、方法和前提条件。VoxRT不把子集测量结果放在另一个供应商的全集测量结果旁边。如果唤醒词要与其他方法比较，两个数字必须在同一测试集上，否则不构成比较。

云端仍然诚实胜出的地方

云端ASR在几个场景是正确的选择：

50多种语言的多语言覆盖。 稀有语言的开放ASR模型往往明显差于云端。如果需要斯瓦希里语、泰语或他加禄语语音，云供应商仍然领先。端侧多语言覆盖正在追赶，但更慢。

模型的快速迭代。 云端团队今天推送改进的模型，明天每个用户就获得更好的准确率，App无需任何改变。端侧App必须重新发布。对在模型质量上快速迭代的产品，这是有意义的速度差异。

API周围的企业合规工具。 主要云ASR供应商带有SOC2、HIPAA和PCI-DSS合规基础设施、审计日志和企业SLA协议。如果卖给财富500强，通过供应商购买合规有时比端侧部署时自己证明更容易。

开放式复杂工作流。 如果你的语音UX是“用语音问AI一个复杂问题，跑ASR，送给LLM，得到语音回复”，整条管线已经在服务器上。在同一服务器上加转写只多花很少额外延迟。当每一步都在云端跑时，第一步的端侧优势很小。

这些案例是真实的。端侧不是万能答案，它是一组特定产品场景的正确答案，而这些场景正变得越来越常见。

GPAI（General-Purpose AI，通用人工智能模型） 是 EU AI Act 中使用的法律分类，指能够执行多种任务、可被广泛集成到不同系统中的基础模型，例如大规模语言模型与多模态模型。EU AI Act 对 GPAI 提供者施加了透明度、文档、版权政策与风险评估等义务，并随着“带着执法牙齿”逐步适用，意味着合规不再是自愿声明，而可能面临实际处罚。

对语音 App 公司而言，这一监管趋势把“数据是否离开设备”从工程偏好变成法律论证问题。当架构上根本不发起网络调用时，向监管者或客户证明用户语音从未上云，远比事后审计日志与合同承诺更可靠。这正是端侧方案在隐私敏感细分领域从“锦上添花”变为“合规姿态”的根本原因，也是文中判断端侧份额将持续扩大的政策驱动力之一。

趋势指向哪里

为理解为什么端侧会抢到更多市场份额，看看已经转移了多少地盘会有帮助。三年前不切实际或仅限研究的能力，今天是标准工程选择：

能力	2022-2023状态	2026状态
移动端流式ASR	Whisper级模型（1-3 GB，批处理架构）对实时移动流式不切实际	FastConformer级模型（约60 MB权重）在普通移动硬件上实时运行
浏览器语音推理	SIMD128之前的WASM，典型2-4倍实时，Safari直到2023年3月才支持SIMD128	所有主流浏览器支持SIMD128，可实现低于1%的RTF
廉价硬件上的唤醒词	Pi Zero级可复现开放基准稀少，多为专有付费层	开放基准已发布，15美元Pi Zero 2 W上实测5.3% RTF
端侧语音克隆TTS	端侧语音克隆处于研究阶段，生产级语音克隆仅云端	已有出货产品，单步流采样让快速合成成为现实

两到三年视野内的三个趋势：

移动芯片的ML能力成为标配。 iPhone的Apple Neural Engine、Google Tensor TPU、骁龙Hexagon NPU。每个旗舰现在都有专用于ML推理的芯片。2022年的壮举（在手机上跑transformer）在2026年是标准能力。

浏览器成为一等目标。 WASM SIMD128（Chrome 91+、Firefox 89+、Safari 16.4+可用）为浏览器中的严肃ML推理打开了大门。100 KB唤醒词在Chrome M4上以0.16% RTF运行。几年前没有原生包装层不可能。完全在浏览器内的语音UX现在是真实选项。

隐私成为合规要求。 EU AI Act对GPAI模型开始带着执法牙齿适用。美国和亚洲的监管者在跟进。对语音App公司，向监管者证明用户语音从未送到云端，在架构上使其不可能时更容易。端侧从锦上添花变成合规姿态。

VoxRT的预测是：未来2-3年，云端ASR在广泛应用中仍是默认，但端侧在隐私敏感、离线优先和延迟关键细分领域抢到市场份额。这不是“端侧会杀死云端”，而是两种架构方法针对不同用例的合理共存。

仓库与资源

运行时和SDK在github.com/VoxRT。平台特定绑定：

• Linux（Pi、Jetson、服务器）：voxrt-wake-word-linux、voxrt-kws-linux、voxrt-asr-linux
• 浏览器（WASM）：voxrt-wake-word-browser、voxrt-kws-browser
• 移动端：iOS和Android绑定在各自仓库中

更多端侧语音技术文章在dev.to/voxrtio。

如果你最近评估过端侧语音但最终选了云端，决定因素是什么？诚实的答案才值得听。