SL2610 系列上的实时语音识别

自动语音识别（ASR）让各类应用中的智能语音设备成为可能。得益于 AI 模型与硬件加速（如 Synaptics 的 Torq NPU）的进步，开发者现在可以在低功耗产品中部署实时语音识别。这为用户与产品交互带来更直观的方式。如果你希望把实时语音识别带到自己的边缘 AI 应用中，这篇博客会手把手带你上手。你也可以直接运行演示应用体验效果。

演示所需物品：

1. 运行 Astra SDK v2.4 或更高版本 Linux 系统的 Astra Machina SL2619 或 Synaptics Coralboard。

2. 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 上，步骤如下：

1. 获取 ONNX 模型组件

2. 修改模型组件：静态化并应用优化

3. 使用 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 个块）启动一次解码器，以预览已经说了什么。

设计难题

以下是出现的一些设计问题：

1. 模型组件要求静态形状：由于解码器需要固定的 cross-kv 输入和 self-kv 缓冲区，我们需要固定话语（utterance）长度。此外，每次解码都会在整段话语上运行。

2. 主机 CPU 与设备 NPU 之间的内存边界：我们希望限制跨边界的内存传输，因此需要让 cross-kv 和 self-kv 缓存常驻于设备上。

3. 何时以及如何运行解码器？我们应该从话语开头重新解码整段音频吗？

简单的部分：让 KV 缓存常驻设备

这是一项关键优化。我们需要让数据常驻在 NPU 上，而不是通过缓慢的内存连接来回搬运：

1. 交叉注意力 KV 缓存在每次解码调用中都是恒定的。

2. 自注意力 KV 缓存可在解码调用的各次前向传播之间复用。

仅仅通过让这两个缓存都常驻设备，我们就能显著削减昂贵的内存传输。此外，由于模型组件和 I/O 都是静态的，实现这一特性非常简单。

棘手的部分：决定何时“提交”一个 token（词片段）

获得实时预览的最直接、最准确的方式，就是简单地从头重新解码整段转录。毕竟，解码器将拥有整段音频的更佳上下文，也就是最大化的 cross-kv 缓存。但正如你所见，这可能会慢得令人望而却步，因为计算成本随输入音频长度的平方增长。此外，由于我们采用了静态模型组件，每次解码器调用在带掩码输入的情况下都要昂贵得多。

作为替代，我们可以通过随着音频推进而提交预览的前缀来削减这一成本。我们押注于这样一个想法：有了足够的上下文，最初的转录就是准确的，现在可以定稿了（既然它们只会是相同的 token，重做只是一种浪费）。

因此我目前使用两条启发式规则来决定何时提交一个 token：

1. 它不再变化（LocalAgreement-2）：该 token 在最近两次连续解码中保持一致。

2. 它已经“老”了：该 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.

补充说明

1. 正如我们稍后将看到的，我们也可以把 I/O 全部放到设备上，但融合它们免去了这里的麻烦。
2. 注意不要做过头，因为这可能会影响准确率或延迟。

一些性能数据

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：采用完整重新解码时，队列深度几乎难以跟上实时进度。