在设备上运行语音智能体
一条管线，三种内存预算。
本地语音智能体不是单个模型——它是由四部分组成的管线：语音活动检测、语音转文字、语言模型和文字转语音，由一个轮次状态机串联起来。这条管线在手机和笔记本上是相同的。变化的是每个环节放哪个模型，而这由两个数字决定：你有多少内存，以及你在喂哪个加速器。
要记住的数字是整条循环，而不是单个模型：语音感知（STT）+ 答案生成（LLM）+ 语音合成（TTS）全部装进这个预算——iPhone 上约 1.2 GB，Galaxy S23 上约 1.5 GB，配上真正对话大脑的 Mac 上不到 4 GB。
管线是可移植的部分。
编排逻辑位于 speech-core，是一个纯 C++ 状态机，且与模型无关：四个环节都是接口，你可以插入任意后端——端侧 ONNX、LiteRT、CoreML/MLX，甚至云端 API——因此同一条管线既能在手机上跑 270M 的工具调用器，也能在 Mac 上跑 Gemma 4 大脑。
一条循环，四个环节。唤醒词、AEC 和增强是可选的 VAD 前置步骤；正是 LLM 的工具调用让它能行动，而不只是回答。
编排器是 VoicePipeline，位于 speech-core。它负责轮次检测、打断、对话历史、工具调用循环和语音队列——但自身不含任何模型。每个环节都可通过 接口 （VADInterface、STTInterface、LLMInterface、TTSInterface）替换，你可以用 ONNX Runtime、LiteRT、CoreML/MLX（经由 speech-swift 姊妹库），甚至云端 API 来实现。还有更轻的模式——Echo（VAD → STT → TTS）和 TranscribeOnly（VAD → STT → 文本）。
NPU 优先，整条循环装进约 1.5 GB。
在手机上，约束是内存、电量和散热——而不是原始算力。正确的目标是神经处理单元（NPU）：iOS 上的 Apple Neural Engine，Android 上的 NNAPI / Hexagon。它以远低于 CPU 或 GPU 的功耗运行量化后的 Transformer，并让 CPU 空出来处理音频和界面。
为什么是 NPU 而不是 CPU 或 GPU？NPU 是一种为单一任务打造的固定功能数据流引擎——即神经网络所依赖的低精度乘加运算。它把权重保存在片上 SRAM，紧挨着计算单元，并跳过了消耗 CPU 或 GPU 大部分能量的取指/译码和宽通用数据通路。搬运数据的开销远大于计算本身，所以让两者都保持在本地就是关键：同样的矩阵乘法只用一小部分的瓦特——没有热降频、不掉电，CPU 也能腾出来做别的。
因此移动端管线用的是小巧、量化、对 NPU 友好的模型：Silero VAD、Parakeet-EOU 120M（轻量流式 STT，内置话语结束检测）、FunctionGemma 270M（工具调用大脑），以及 Kokoro-82M 或 Supertonic-3 作为语音。设备实测：
| 环节 · 模型 | iPhone 16 Pro（CoreML / ANE） | Galaxy S23（LiteRT / ONNX，CPU） |
|---|---|---|
| STT · Parakeet-EOU 120M | 0.04 RTF · 297 MB | 0.21 RTF · 232 MB |
| STT · Omnilingual 300M | 0.28 RTF · 495 MB | 0.15 RTF · 831 MB |
| TTS · Kokoro-82M | 0.08 RTF · 676 MB | 0.53 RTF · 640 MB |
| TTS · Supertonic-3 99M | 0.15 RTF · 956 MB | 0.34 RTF · 832 MB |
| LLM · FunctionGemma 270M | 128 tok/s · 236 MB | 118 tok/s · 611 MB |
RTF = 墙钟时间 ÷ 音频秒数（越低越快；<1.0 即快于实时）。峰值内存为各模型单独测得。
每个环节都快于实时。为一个实时智能体一起加载时，常驻工作集在 iPhone 上约 1.2 GB、Galaxy S23 上约 1.5 GB——差距几乎全在 LLM：FunctionGemma 在 ANE 上是 236 MB，而在 S23 CPU 上是 611 MB。iOS 已经跑在 NPU 上（这就是 0.04 RTF 的 STT 和 128 tok/s 的 LLM）；Android 目前是纯 CPU 也能实时，NNAPI/Hexagon 委托是加分项，而非必需。
试一试： Examples/iOSEchoDemo 在 iPhone 上把 Parakeet + Silero + Kokoro 跑成一个完整的回声循环；Android 端在 speech-android，封装的是同一条管线。（Examples/iOSBenchmark 就是上面 iPhone 数据背后的测试工具。）
一个能操控机器的真正 LLM——仍在 4 GB 以内。
在 Mac 上约束放宽了：CPU 与 Metal GPU 共享的统一内存。仍是四个环节，但换上更大的模型，关键是用一个真正的对话大脑取代 270M 的工具调用器——而整条循环仍装在约 4 GB 内。
LLM 是大脑，也是模型大小不再可有可无的地方。经过测试，有两个模型胜任：移动端的 FunctionGemma 270M（足以发出一个工具调用，手机端智能体所需的一切）和桌面端的 Gemma 4 E2B/E4B（4-bit MLX）（真正经得住多轮对话与推理，同时保持轻量）。中间那档诱人的选择——不到 1B 的紧凑对话模型——footprint 看着免费，却在真实多轮对话中站不稳，因此没能入选。真正重要的跨越不是 0.27B → 0.8B；而是 FunctionGemma 的工具调用 → Gemma 4 的对话。
栈的其余部分也随之升级：桌面端把轻量的 Parakeet-EOU 换成 Parakeet-TDT（完整多语言），TTS 各处都保持 Supertonic-3——快、44.1 kHz、稳定。我们有意跳过更重的零样本克隆 TTS 模型；克隆还不够稳定，不适合放进一个常开的智能体里。
| 环节 | 移动端 | 桌面端（Mac / MLX） |
|---|---|---|
| VAD | Silero v6.2.1 | Silero v6.2.1 |
| STT | Parakeet-EOU (streaming) | Parakeet-TDT (multilingual) |
| LLM | FunctionGemma 270M | Gemma 4 E2B/E4B |
| TTS | Kokoro-82M / Supertonic-3 | Supertonic-3 |
| Resident set | iPhone ~1.2 GB · S23 ~1.5 GB | ~4 GB |
那条桌面路径正是 Runner Agent 所交付的——一个已公证的 macOS 应用，完全在本地运行 Mic → VAD → Parakeet-TDT → Gemma 4 → Supertonic TTS，安装包 47 MB DMG，整条循环在 Apple Silicon 上约 4 GB。而正因为大脑会发出工具调用，Runner 不只是回话——它用语音操控机器：打开浏览器并执行 DOM 操作，打开 Telegram 或 WhatsApp 读取来消息并输入回复，启动并控制应用——全部来自口头指令，全部在本地。这正是桌面端需要 Gemma 4 而不是 270M 工具调用器的真正原因：对机器采取行动需要真正的推理，而不只是填槽。
一条管线，按预算匹配。
VAD → STT → LLM → TTS 在哪里都一样。有意思的全部在于把每个环节匹配到设备的加速器和内存。
电量和散热决定选型。ANE 让 iOS 在 CPU 上几乎零负担；Android 目前纯 CPU 即可实时，NPU 还有余量。
整条循环装进约 4 GB，这个预算换来能用语音操控机器的 Gemma 4 推理，外加多语言的 Parakeet-TDT。
音频和对话状态从不离开设备——感知、推理和合成都跑在你面前的这台机器上。