SL2610 系列上的实时语音识别
自动语音识别（ASR）让各类应用中的智能语音设备成为可能。得益于 AI 模型与硬件加速（如 Synaptics 的 Torq NPU）的进步，开发者现在可以在低功耗产品中部署实时语音识别。这为用户与产品交互带来更直观的方式。如果你希望把实时语音识别带到自己的边缘 AI 应用中，这篇博客会手把手带你上手。你也可以直接运行演示应用体验效果。
演示所需物品：
-
运行 Astra SDK v2.4 或更高版本 Linux 系统的 Astra Machina SL2619 或 Synaptics Coralboard。
-
USB 麦克风
如果您想直接跳到演示部分，请点击这里。
Moonshine V2——现已支持流式处理！
Moonshine 是由 Moonshine AI 开发的一系列面向低延迟转录的语音识别模型（Jeffries 等，2024；Kudlur 等，2026）。他们提供了微型模型，参数量小至 3400 万（约 130MB），即使在浮点精度下也能在 Astra 设备上实时运行。
基础的 Moonshine 模型基于经典的编码器-解码器 Transformer 模型（Vaswani 等，2017）。它由一个编码器和一个解码器组成：编码器审视整段语音以捕捉上下文，并将这一“编码”传递给解码器，由解码器自回归地生成转录结果。随后于 2026 年发布的 Moonshine V2 进行了改进，在模型的编码器部分引入了滑动窗口注意力机制。这意味着我们不再需要等待整段语音结束才开始输出第一个 token，从而缩短了首 token 时间（TTFT），因为编码器现在可以将编码帧“流式”传递给解码器。
Astra SL2610 与 Torq NPU
SL2610 是一款异构 SoC：
-
Arm Cortex-A55 核心（CPU），
-
Mali-G31 GPU，以及
-
Torq T1 NPU（1 TOPS）。
Torq 是 Synaptics 围绕 Google 的 Coral NPU 打造的芯片与编译器技术栈，Coral NPU 是一个开源的 RISC-V NPU 核心，原生支持 AI 工作负载。在设计上，该 NPU 针对 AI 时代普遍存在的矩阵运算进行了优化。
我们将在芯片上运行完整的 ASR 系统，把 Moonshine V2 模型放在 NPU 上。有关我们这样做的原因，请参阅性能提升表格。
使用 Torq 准备模型
我们希望把模型放到 NPU 上，步骤如下：
-
获取 ONNX 模型组件
-
修改模型组件：静态化并应用优化
-
使用 Torq 工具链生成二进制文件
获取 ONNX 模型组件
以我自己的流程为例：我先从 Huggingface（UsefulSensors/moonshine-streaming-tiny）下载了 model.safetensors，然后使用 torch.onnx.export(dynamo=True) 导出了 ONNX 组件。有时你可以直接从 Huggingface 获取 ONNX 模型；但如果从 PyTorch 权重层开始，你就能更灵活地在这个层面做编辑。例如可以设计自定义模型接口、修改组件函数，以及更容易地融合/拆分模型组件。
Moonshine Voice 将完整模型拆分为 5 个 ONNX 组件：frontend、encoder、adapter、cross_kv 和 decoder_kv。
图 2：Moonshine V2 的 ONNX 模型组件。
| 组件 | |
|---|---|
| frontend | 有状态的音频前端，接收原始音频块 + 滚动卷积缓冲区，运行带步长的因果卷积堆栈，输出特征嵌入 + 更新后的缓冲区。 |
| encoder | Transformer 编码器层（有状态），使用因果/滑动窗口注意力掩码将 frontend 特征转化为 带上下文的隐藏状态，从而可以逐块运行。 |
| adapter | 一个小型投影（pos_emb + proj），将编码器隐藏状态重塑为解码器交叉注意力所期望的形式。 |
| cross_kv | 每块从编码器隐藏状态中预先计算一次交叉注意力的 K/V 投影，这样解码器就无需在每个生成的 token 处重新计算它们。 |
| decoder_kv | 自回归解码器：接收上一个 token + 自注意力 KV 缓存 + 预计算的交叉注意力 KV，输出下一个 token 及更新后的自注意力缓存。 |
修改模型组件
通过融合组件减少不必要的数据传输
对于给定的输入音频块大小，decoder_kv 之前的各组件可以按序工作，因此我们可以通过融合它们来优化拆分。这将减少设备到主机（NPU - CPU）之间的数据传输，使完整模型保持在原位[1]。我们将其称为“编码器”，而把 decoder_kv 简称为“解码器”。
将动态维度改为固定长度（静态）
由于 Torq T1 NPU 支持固定长度的 I/O 和操作，我们需要将动态维度更新为某个固定大小。当前的流水线使用 ONNX 手术工具 onnx_graphsurgeon 来完成此操作。
将特殊算子分解为常见算子
此外，如果当前版本的 Torq 编译器不支持某些特殊算子（请务必拉取最新更新！它们经常更新），我们可以通过将其分解为更简单的算子来临时支持它们[2]。例如，在 frontend 中，我不得不用多项式来拟合 asinh 算子，而编码器中的 layernorm 由于 MLIR lowering 的问题需要被分解。
将模型组件编译为 VMFB 文件（NPU 二进制）
一旦我们准备好静态的 ONNX 文件，就可以将其传递给 torq-compiler，生成可在 Astra SL2610 上运行的二进制文件。你可以按照该仓库中的文档来“lower”ONNX 模型。首先，我们使用 IREE 工具生成一个优化过的 MLIR 文件，然后将其交给 Torq，由后者输出 .vmfb 二进制文件。
Synaptics 提供的完整导出流水线（自动化转换过程 ）
torq-tools 仓库中的导出流水线已经把修改、优化、编译模型组件整个过程自动化。可以通过下面命令执行完整导出（先阅读 readme 并完成环境配置）：
torq-export-model moonshine_streaming --chunk-len 1280 --input-seconds 8 --extract-embeddings --export-attention --convert-dtypes
以下是一些有用的参数：
-
--chunk-len（必填，无默认值）：馈送给编码器的每个流式块的音频采样数（例如1280 samples= 80ms @16kHz）。 -
-i/--input-seconds（默认为 5）：约束解码器的输入（交叉 KV 缓存）及其自 KV 缓存。换句话说，这限制了静态解码器每次能够关注的总音频长度（上下文）。 -
--extract-embeddings：将解码器的首个输入从整数 token id 切换为浮点inputs_embeds张量，把嵌入表查找移到主机端（与单独导出的decoder_token_embeddings.npy配对使用）。 -
--convert-dtypes：精度转换。生成.vmfb文件时请务必包含此参数。
对于当前的演示，我选择了 8 秒的最大转录长度，编码器每次处理 1280 个采样的音频（80ms）。这应会在以下目录中生成 encoder.vmfb 和 decoder.vmfb 文件
torq-tools/models/UsefulSensors/moonshine-streaming-tiny/export/torq/converted/static
另请注意在下面的目录中生成的五个文件：adapter_pos_emb.npy、decoder_token_embeddings.npy、streaming_config.json、tokenizer.json 和 config.json：
torq-tools/models/UsefulSensors/moonshine-streaming-tiny/export/onnx/float/static
运行演示
这是一个简洁的实时语音转录演示：它使用 Moonshine V2 模型，并基于 Moonshine Voice 仓库改编，可在 Coralboard 或 Machina Kit 上完整板端运行。你对着接到开发板的麦克风讲话时，转录会随着你说话实时更新，我们把这称作“预览（preview）”，它会随着新音频到来不断修正。正如前文所述，这得益于 V2（流式版本）的改进：编码器利用滑动窗口注意力把嵌入写入一个不断增长的缓冲区，而不是每次都重跑整段音频。
请确保开发板运行的是 Astra SDK（Yocto Project Linux）scarthgap_6.12_v2.4.0 或更新版本的 SL2619 OOBE 镜像。
- Astra Machina SL2619 Kit 使用镜像：
sl2619_oobe_scarthgap - Coralboard SL 2GB 使用镜像：
sl2619_coralboard_oobe_scarthgap
可参考 Astra SDK Documentation 和 Astra SDK Releases 获取更多细节。
克隆包含子模块的 demo 仓库，运行 setup 脚本，并按 sl2610-examples README.md 安装基础 Python 依赖。
然后进入 speech_to_text_streaming 目录执行：
cd speech_to_text_streaming
pip install -r requirements.txt
安装麦克风输入所需的 PortAudio 系统库：
../setup/install_portaudio.sh
下载模型：
python setup_demo.py
确认麦克风已连接开发板。
然后运行应用：
python app.py
可通过以下命令查看 --device 编号：
python app.py --list-device
也可以提供预录 WAV 文件来模拟实时转录：
python app.py --wav ../../librispeech_clean.wav --realtime
图 3：转录输出
与真实文本相比，转录结果相当准确：
Yesterday you were trembling for a health that is dear to you. Today you fear for your own. Tomorrow it will be anxiety about money. The day after tomorrow, the diatribe of a slanderer. The day after that, the misfortune of some friend. Then the prevailing weather. Then something that has been broken or lost. Then a pleasure with which your conscience and your vertebral column reproach you. Again, the course of public affairs.
你可能已经注意到，我把 --vad-silence 设为了 0.5 秒，因为这段音频清晰且噪声低，VAD 很容易捕捉到语音。当你用自己的麦克风测试时，请务必相应地调整这个旋钮，因为背景噪声可能会导致你的转录过于频繁地中断。
以下是该算法的工作流程：
图 4：实时流式转录流水线。
一个工作线程持续将原始音频推入队列。另一个独立线程将音频重采样到 16kHz，并将其切分为固定的 80ms （1280 采样）片段，然后运行一个轻量级的基于能量的 VAD 来判定当前的语音阶段。如果你正在讲话，它会将该音频块馈送给运行在 NPU 上的编码器。编码器需要一定的前瞻量，因此我们需要丢弃一些预热的编码器输出帧，但每个音频块都会向交叉注意力缓冲区（cross-kv 缓存）追加固定批次的新帧。然后我们每隔一段时间（比如每 15 个块）启动一次解码器，以预览已经说了什么。
设计难题
以下是出现的一些设计问题：
-
模型组件要求静态形状：由于解码器需要固定的 cross-kv 输入和 self-kv 缓冲区，我们需要固定话语（utterance）长度。此外，每次解码都会在整段话语上运行。
-
主机 CPU 与设备 NPU 之间的内存边界：我们希望限制跨边界的内存传输，因此需要让 cross-kv 和 self-kv 缓存常驻于设备上。
-
何时以及如何运行解码器？我们应该从话语开头重新解码整段音频吗？
简单的部分：让 KV 缓存常驻设备
这是一项关键优化。我们需要让数据常驻在 NPU 上，而不是通过缓慢的内存连接来回搬运：
-
交叉注意力 KV 缓存在每次解码调用中都是恒定的。
-
自注意力 KV 缓存可在解码调用的各次前向传播之间复用。
仅仅通过让这两个缓存都常驻设备，我们就能显著削减昂贵的内存传输。此外，由于模型组件和 I/O 都是静态的，实现这一特性非常简单。
棘手的部分：决定何时“提交”一个 token（词片段）
获得实时预览的最直接、最准确的方式，就是简单地从头重新解码整段转录。毕竟，解码器将拥有整段音频的更佳上下文，也就是最大化的 cross-kv 缓存。但正如你所见，这可能会慢得令人望而却步，因为计算成本随输入音频长度的平方增长。此外，由于我们采用了静态模型组件，每次解码器调用在带掩码输入的情况下都要昂贵得多。
作为替代，我们可以通过随着音频推进而提交预览的前缀来削减这一成本。我们押注于这样一个想法：有了足够的上下文，最初的转录就是准确的，现在可以定稿了（既然它们只会是相同的 token，重做只是一种浪费）。
因此我目前使用两条启发式规则来决定何时提交一个 token：
-
它不再变化（LocalAgreement-2）：该 token 在最近两次连续解码中保持一致。
-
它已经“老”了：该 token 至少落后前沿 3 秒的音频。
这两条启发式规则都可以针对你的具体用例进行调整，只需分别尝试一些数值，看看它们与“黄金”全上下文解码的一致程度即可。
更难的部分：连续流式处理
在我当前的设置下，转录并非真正意义上无限音频长度的流式转录。具体来说，我们受限于在固定话语上限（设为 8 秒）内进行流式处理。
即便如此，我们仍可以通过在系统层面与 VAD 协同来获得伪流式的用户体验。当检测到长时间停顿时，我们可以重置转录流水线以及模型组件的状态和缓冲区。只要没有超过 8 秒固定窗口的长话语，我们就能体验到流畅的流式转录。
其他策略，如对 cross-kv 缓存进行滑动窗口处理，或在话语边界之间进行缓冲和拼接，可能会影响准确率，但值得探索。
我们诚邀你研究如何在系统层面协调模型，以提供最佳的流式转录。
总结
在本博客中，我们了解了：
-
Moonshine V2 流式模型的简要概览，
-
如何从 PyTorch 导出和准备模型的简短指南，
-
实时流式语音转录的简单演示，以及
-
一些设计难题及其解决方法。
下一步是什么？
-
正如我们前面讨论的，要在系统层面实现更好的协调以处理两段话语之间的间断，仍有一些工作要做。
-
为了进一步改善延迟和内存占用，我们可以采用 INT8 量化（尤其是在解码器上），代价是损失一些准确率。
参考文献
-
Jeffries, N., King, E., Kudlur, M., Nicholson, G., Wang, J., & Warden, P. (2024). Moonshine: Speech recognition for live transcription and voice commands. arXiv preprint arXiv:2410.15608.
-
Kudlur, M., King, E., Wang, J., & Warden, P. (2026). Moonshine v2: Ergodic streaming encoder asr for latency-critical speech applications. arXiv preprint arXiv:2602.12241.
补充说明
- 正如我们稍后将看到的，我们也可以把 I/O 全部放到设备上，但融合它们免去了这里的麻烦。
- 注意不要做过头，因为这可能会影响准确率或延迟。
一些性能数据
Tiny 模型
| 组件 | CPU (ms) | NPU (ms) | 加速比 | DRAM: CPU → NPU (MB) | 内存: CPU → NPU (MB) |
|---|---|---|---|---|---|
| Encoder | 81.6 | 23.4 | 3.49× | 122.3 → 82.9 | 90.1 → 41.0 |
| Decoder | 37.9 | 28.3 | 1.34× | 170.5 → 131.3 | 138.0 → 68.2 |
表 1：在 Coralboard 上对 3400 万参数模型（tiny）使用 NPU 相比 CPU 的性能提升。
Small 模型
| 组件 | CPU (ms) | NPU (ms) | 加速比 | DRAM: CPU → NPU (MB) | 内存: CPU → NPU (MB) |
|---|---|---|---|---|---|
| Encoder | 409.0 | 174.2 | 2.35× | 361.1 → 526.3 | 328.9 → 262.9 |
| Decoder | 99.0 | 68.6 | 1.44× | 391.4 → 313.4 | 358.9 → 164.2 |
表 2：在 Coralboard 上对 1.23 亿参数模型（small）使用 NPU 相比 CPU 的性能提升。
图 5：采用完整重新解码时，步数随音频长度呈二次方增长。
图 6：因此，采用完整重新解码策略时，解码调用的延迟比增量策略增长得快得多。
图 7：采用完整重新解码时，队列深度几乎难以跟上实时进度。
