Echo Dot 2 能以不错的速度运行 28M 参数 LLM

代码和说明在此：https://github.com/albertoZurini/echo-dot-2-playground 大家好！经过几天的实验，我成功地在 Amazon Echo Dot 2 上运行起了一个完全本地的语音流水线。对这个社区来说有趣的是，即使硬件非常有限，该设备也能同时运行 `llama.cpp` 和离线语音识别。Echo Dot 2 配备 ARMv7 处理器和 512 MB 内存。我为 `armeabi-v7a` 编译了 `llama.cpp`，并通过常驻的 `llama-server` 进程运行模型。保持服务器存活很重要，否则每次请求都要从头加载模型。在较小的实验中，我使用了一个 28M 参数的模型，与某些 ESP32 语音项目使用的通用模型系列相同。在 Echo Dot 上，提示处理阶段约为 7 tokens/s，生成阶段约为 4 tokens/s。这显然不算快，但足以处理简短的结构化命令，例如开灯或调节音量。我还测试了 `MobileLLM-143M-Q4_K_M.gguf`。它能运行，但完成一次简单的命令预填充和生成大约需要 20 秒，这让它在这款硬件上作为交互式语音助手显得太慢了。最大的改进来自于改变推理架构。助手不再为每次语音启动 `llama-cli`，而是只启动一次 `llama-server` 并让它常驻后台。请求提示将所有不变的指令和输出格式放在开头，用户的文本放在最后。请求使用 `cache_prompt=true`，这样 llama.cpp 可以复用稳定前缀的 KV 缓存，只处理变化的用户文本。在我的测试中，这将热查询延迟从冷调用 `llama-cli` 的大约 17 秒降低到使用常驻服务器和缓存提示后的大约 2.3 秒。流水线的其余部分使用 Sherpa-ONNX 进行离线流式语音转文字。唤醒词服务向助手发送本地事件，助手录制语音，运行 STT，然后将转录文本发送到本地 llama.cpp 服务器。模型被限制为输出简单的 JSON 动作而不是对话式回复，这样生成内容很短，即使在低 token 速率下也很有用。这不是一个通用聊天机器人。模型太小，硬件也太慢，无法胜任。它更像一个微型的本地意图解析器，可以将语音转换为设备动作，而无需将音频或文本发送到云端。我能够通过语音触发简单的工具，并将完整交互保留在 Echo Dot 上。代码和构建说明在此：https://github.com/albertoZurini/echo-dot-2-playground 我很想听听大家会在这种老式 ARM 硬件上尝试哪些其他小型 GGUF 模型或 llama.cpp 设置。主要限制是内存、模型加载时间，以及保持提示足够小，让缓存的前缀真正起作用。