ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

把老旧Echo Dot 2改造成本地LLM终端:嵌入式Linux与llama.cpp实战

把老旧Echo Dot 2改造成本地LLM终端:嵌入式Linux与llama.cpp实战 家里吃灰的旧设备除了二手卖掉其实还有一条特别有折腾价值的路子把它改造成一台能跑本地大模型的“小钢炮”。本文要聊的主角是 Amazon Echo Dot 2——一台已经停产的老款智能音箱。最近海外 DIY 社区里不少人把它破解hacked之后装上了 llama.cpp并且成功在本地运行小尺寸 LLM。这件事听起来很“极客”但拆开看其实是一套非常标准的嵌入式 Linux 流程拆机 → UART 调试口 → 修改 uboot 启动参数 → 拿到 root shell → 交叉编译推理框架 → 部署量化模型。这篇文章会从概念讲起逐步拆解硬件平台、破解思路、交叉编译方法、模型选型以及最终如何把 Echo Dot 2 变成一个纯本地的 LLM 终端。适合对嵌入式 Linux、LLM 部署、电子 DIY 感兴趣的读者。就算你手上没有 Echo Dot 2把里面的方法论迁移到其他 ARM 开发板、老旧电视盒子、路由器上同样成立。1. 背景与核心概念1.1 Echo Dot 2 是什么为什么值得折腾Echo Dot 2 是亚马逊在 2016 年发布的第二代智能音箱外观是一个扁平的圆形小饼内置扬声器、麦克风阵列默认通过 Alexa 云端服务完成语音交互。放到今天来看它的算力很弱、内存很小很多人家里都已经把它收进抽屉吃灰了。但正是这种“老旧设备”反而符合不少技术玩家的口味它本质上是一台小体积、带 Wi-Fi、带音频输入输出的 ARM Linux 电脑。只要能拿到 root 权限跑什么软件就由你说了算。相比树莓派Echo Dot 2 的二手价格更低外壳自带麦克风阵列和喇叭做成语音交互类的本地小项目非常合适。社区里已经有人把它刷成自定义系统、跑起了本地 LLM也有人把它接进 Home Assistant 做语音入口。1.2 “本地运行大模型”的真实含义“Run LLMs locally”不能从字面上理解成“在 Echo Dot 2 里跑一个 GPT-4”。本地运行大模型指的是在你自己掌控的硬件上通过 llama.cpp、Ollama 这类推理框架加载 GGUF 格式的开源模型不再把对话数据发送到云端 API。数据的处理和推理都在本地网络内完成。对于 Echo Dot 2 这种设备一般有两种理解方式严格意义模型权重完全放在设备本地推理也在设备上完成家庭局域网意义模型跑在家庭网络内的服务器上比如一台旧 PC、树莓派 5、Mac miniEcho Dot 2 充当语音终端或网络客户端数据不出门。两种方式都有价值。第一种挑战硬件极限第二种更贴近实际使用因为真正的语音识别和 TTS 也需要一定算力。本文会优先讲清楚第一种的完整实现路径再用一节讨论更实用的分流架构。1.3 算力与内存的现实问题在开始之前必须对设备性能有清醒认识。Echo Dot 2 的主控方案在拆机资料里普遍指向 MediaTek 平台的 ARM 处理器内存以 512MB 级别为主存储空间在 4GB 到 8GB 左右。具体参数请以你自己设备的free -m、df -h、uname -a输出为准。这样的配置决定了能跑的模型参数规模非常小。以 512MB 内存为参考量化后体积在 100MB 到 200MB 以内的模型才比较稳妥例如 TinyStories、SmolLM2-135M、Qwen2-0.5B 的 Q4 量化版本0.5B 比较极限需要实测。推理速度不会快。Echo Dot 2 的 CPU 没有 GPU 加速每秒只能生成几个 token做简单意图识别和短句生成可以长对话体验会很明显地“慢”。系统本身要精简。跑 LLM 之前尽量把不必要的系统服务关掉只保留网络、SSH 和推理进程。这不代表项目没有意义。本地模型的价值本来就不在“大”而在“私有化、可控、可折腾”。一个只负责意图识别和状态查询的小模型在家庭自动化场景里非常好用。1.4 合法与安全的边界破解设备属于安全研究范畴必须遵守几个基本原则本文后面所有操作都以此为前提只折腾你自己拥有的设备不要对他人设备下手设备固件可能含有第三方软件许可刷机、修改前请自行阅读相关协议操作前先备份刷机有变砖风险需要自己承担不要利用这类技术攻击云服务、绕过商业授权或窃取他人数据在测试环境验证遵循最小权限原则不要把调试口和 root 权限随意暴露到公网。如果你手头的 Echo Dot 2 还在正常使用并依赖 Alexa 服务建议先评估清楚修改系统后官方 OTA 升级可能会覆盖你的改动甚至导致设备无法启动。把“备份”看成第一步而不是可选项。2. 硬件与系统先摸清这台设备2.1 拆机与硬件平台Echo Dot 2 的拆机门槛不高底部有防滑垫撕开后能看到螺丝。拆开后你通常会看到一块主板上面有主控、内存颗粒、eMMC 存储芯片、Wi-Fi/蓝牙模块以及麦克风阵列和扬声器接口。不同批次的硬件版本可能存在差异所以不要照搬网络上的每一个引脚定义。正确做法是对照自己主板上的丝印、芯片型号去查数据手册再确认 UART 调试触点。Echo Dot 2 这一类设备在出厂时通常保留了 UART 调试口它的作用是在系统启动早期输出内核日志并提供引导加载程序bootloader的控制台。如果你对嵌入式硬件不熟建议先准备以下工具USB 转 TTL 串口模块常见的 CP2102、CH340 都可以3.3V 电平杜邦线若干电烙铁和细焊丝部分调试触点需要焊接可靠的 5V/2A 左右电源避免供电不足导致刷机中断一台运行 Linux 的电脑用于串口调试和交叉编译。2.2 固件与分区逻辑Echo Dot 2 内部运行的是基于 Linux 的定制系统启动流程大致是上电 → BootROM → uboot → Linux 内核 → rootfs根文件系统→ 亚马逊的守护进程。设备上的 eMMC 存储会被划分为多个分区包括 uboot 分区、内核分区、rootfs 分区、数据分区等。理解分区逻辑很重要因为“破解”的核心动作之一就是在 uboot 启动阶段修改内核启动参数让系统跳过正常的用户态服务直接进入一个可控制的 shell 环境。之后你才能挂载 rootfs、修改文件、放入自己的程序。这里要注意不同批次、不同固件版本的分区表可能不同。不要凭印象直接dd某个块设备也不要格式化你不认识的分区。正确顺序是先通过串口进入系统执行cat /proc/partitions查看真实分区情况。2.3 调试接口在哪里UART 调试口通常在主板上以排针焊盘或圆形测试点形式存在一般包含 GND、TX、RX 三个关键点。部分开发板还会有 VCC 引脚但调试口 VCC 不能随意接串口模块供电最好独立避免主板上电顺序异常。连接方法GND 接串口模块 GND主板 TX 接串口模块 RX主板 RX 接串口模块 TX不接 VCC串口模块用 USB 供电即可。接好之后在电脑上打开串口终端波特率通常从 115200 开始试。常见的替代波特率还有 57600、38400、921600。如果开机时能看到内核日志说明 UART 找对了如果屏幕全黑先检查 TX/RX 是否接反再检查 GND 是否共地。3. 获取 root 权限的通用路径3.1 准备工作在动手前请在电脑上安装串口终端工具例如minicom或screen。以screen为例# 先查看串口设备名一般是 /dev/ttyUSB0 或 /dev/ttyACM0 ls /dev/ttyUSB* sudo chmod 666 /dev/ttyUSB0 screen /dev/ttyUSB0 115200退出screen的组合键是CtrlA然后按K再按Y确认。连接好串口线、给设备上电如果能看到类似下面的日志说明你已经进入了引导流程U-Boot 2013.07 (xxx) DRAM: 512 MiB MMC: mmcxxx: 0 In: serial Out: serial Err: serial Hit any key to stop autoboot: 0这个Hit any key to stop autoboot提示就是进入 uboot 控制台的机会。不同固件的 uboot 控制台命令不尽相同但核心思路一致中断自动启动后用printenv查看环境变量用setenv修改启动参数用saveenv保存。3.2 从 UART 进入 uboot当 uboot 倒计时提示出现时按下任意键进入控制台。输入以下命令查看当前启动参数printenv bootargsbootargs是 uboot 传给内核的命令行参数里面通常包含根文件系统挂载方式、串口波特率、内存大小等信息。一个常见的示例输出如下bootargsconsolettyS0,115200 root/dev/mmcblk0p2 rootwait这里的root/dev/mmcblk0p2表示根文件系统在第二个分区。如果你想让系统启动后不进入正常业务进程可以先尝试在bootargs后面追加init/bin/sh让内核直接启动一个 shellsetenv bootargs consolettyS0,115200 root/dev/mmcblk0p2 rootwait init/bin/sh boot如果一切正常串口会进入一个 root shell 提示符。因为此时文件系统通常是只读挂载的所以接下来要重新挂载mount -o remount,rw /这是“拿到 root 的第一步”也是最容易变砖的地方。修改bootargs之前请先用printenv把原始值完整记录下来并且不要轻易执行saveenv。如果你只想临时验证不保存环境变量重启后 uboot 会恢复原样风险会小很多。3.3 修改启动参数拿到 root shell拿到临时 root shell 后接下来的目标是让设备能长期、方便地被你控制。常见做法有几种在 rootfs 中开启 telnet 服务或 dropbear SSH创建一个新的系统服务让它在正常启动时自动执行你的脚本或者干脆刷入一个精简的 rootfs去掉亚马逊原厂业务。如果你不想彻底刷系统只想最小化改动可以先把原厂 rootfs 挂载为可写然后添加一个自动执行脚本。例如创建一个/etc/init.d/S99local之类的启动脚本在里面启动 SSHD 或你的 LLM 服务。判断 CPU 架构这一步很重要uname -a cat /proc/cpuinfo | grep -i processor | head如果输出包含armv7l代表 32 位 ARM如果包含aarch64代表 64 位 ARM。这个结果直接决定后续交叉编译工具链的选择。3.4 全量备份是第一步在改动任何分区之前先做全量备份。备份方法不复杂如果设备上能挂载 U 盘可以把整个 eMMC 或关键分区导出。例如mkdir /mnt/usb mount /dev/sda1 /mnt/usb dd if/dev/mmcblk0 of/mnt/usb/echo_dot2_full_backup.img bs1M convsync,noerror statusprogress这条命令会把整个mmcblk0设备导出为一个镜像文件。if是输入文件设备of是输出文件bs1M指定块大小convsync,noerror让读取错误不至于中断备份。注意/dev/mmcblk0是整颗 eMMC实际设备名以你的系统为准。备份耗时取决于 eMMC 容量和 U 盘写入速度可能长达几十分钟期间不要断电。如果你不想备份整颗盘至少要把 uboot 分区、内核分区和 rootfs 分区单独备份出来。拿到备份后就可以大胆尝试修改了。常见的变砖原因是把bootargs里的root写错、把分区表破坏、或者格式化错设备。有了备份理论上可以通过 u盘启动或硬件编程器恢复但操作复杂度会高很多所以不要省这一步。4. 在设备上编译并运行 llama.cpp4.1 为什么选 llama.cppllama.cpp 是目前嵌入式设备上运行 LLM 的主流选择。它由 C/C 编写依赖少支持 CPU 推理支持 GGUF 量化模型并且提供了命令行交互工具llama-cli和 HTTP 服务工具llama-server。相比 Python 系的 transformers 方案llama.cpp 在低内存设备上的启动速度和内存占用都有明显优势。在 Echo Dot 2 上跑 llama.cpp 有两种方式直接在设备上编译设备性能太弱不推荐交叉编译更靠谱在电脑上交叉编译把二进制拷贝到设备上运行推荐。交叉编译的意思是在 x86 电脑上生成 ARM 平台可执行文件。你需要安装对应架构的交叉编译工具链。4.2 交叉编译 llama.cpp以 32 位 ARM 目标为例在 Ubuntu/Debian 电脑上安装工具链sudo apt update sudo apt install -y gcc-arm-linux-gnueabihf g-arm-linux-gnueabihf cmake git如果设备是 64 位 ARM则对应gcc-aarch64-linux-gnu和g-aarch64-linux-gnu这里以arm-linux-gnueabihf为例请根据真实uname -m调整。然后拉取 llama.cpp 源码并开始交叉编译git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_C_COMPILER/usr/bin/arm-linux-gnueabihf-gcc \ -DCMAKE_CXX_COMPILER/usr/bin/arm-linux-gnueabihf-g \ -DCMAKE_EXE_LINKER_FLAGS-static cmake --build build --config Release -j4这里的关键参数说明CMAKE_C_COMPILER/CMAKE_CXX_COMPILER指定交叉编译器路径CMAKE_BUILD_TYPERelease开启优化释放性能CMAKE_EXE_LINKER_FLAGS-static静态链接。设备上的动态库往往不完整静态链接能避免“找不到 libxxx.so”的问题-j4并行编译如果你的电脑核心数少可以改成-j2。编译完成后产物在build/bin/目录下最关键的是llama-cli命令行对话和llama-serverHTTP 服务。把这两个文件拷贝到设备上# 在电脑上假设设备 IP 是 192.168.1.100开启了 SSH scp build/bin/llama-cli build/bin/llama-server root192.168.1.100:/root/拷贝完成后在设备上验证可执行文件是否正常chmod x /root/llama-cli /root/llama-server /root/llama-cli --help | head如果输出帮助信息说明交叉编译成功如果提示Exec format error则说明架构选错了需要重新检查工具链。4.3 选择合适的小模型并生成 GGUFEcho Dot 2 的内存决定了模型不能大。这里给出一个参考系实际 GGUF 文件大小以你转换后的结果为准模型参数量量化方式大致体积是否适合 Echo Dot 2TinyStories33MQ4_0约 30MB适合英文故事生成SmolLM2-135M135MQ4_0约 100MB适合轻量对话Qwen2-0.5B0.5BQ4_K_M约 400MB很极限需实测可能 OOMLlama 3.2-1B1BQ4_K_M约 800MB不适合放服务器端你可以在 Hugging Face 上搜索对应的小模型下载后用 llama.cpp 自带的convert_hf_to_gguf.py转换成 GGUF。转换脚本在llama.cpp仓库的根目录# 在电脑上先安装依赖 pip install -r llama.cpp/requirements.txt # 假设你已经把模型下载到 ./SmolLM2-135M-Instruct/ 目录 python3 llama.cpp/convert_hf_to_gguf.py ./SmolLM2-135M-Instruct \ --outfile ./smollm2-135m-instruct-f16.gguf --outtype f16 # 进一步量化为 Q4_0减小体积 ./build/bin/llama-quantize ./smollm2-135m-instruct-f16.gguf \ ./smollm2-135m-instruct-q4_0.gguf Q4_0量化是把模型权重从 16 位浮点压缩到更低比特数的过程会带来少量精度损失但能显著减少内存占用和文件体积。对嵌入式场景来说Q4_0 往往是最实用的平衡点。转换完成后把 GGUF 文件上传到设备scp ./smollm2-135m-instruct-q4_0.gguf root192.168.1.100:/root/models/4.4 启动本地推理服务先在设备上做一次命令行验证确认模型能跑通/root/llama-cli -m /root/models/smollm2-135m-instruct-q4_0.gguf \ -p Hello, can you introduce yourself? -n 32 -t 2参数含义-m模型路径-p输入提示词-n生成 token 数量测试时可以给少一点-t线程数Echo Dot 2 的 CPU 核心有限建议从-t 1或-t 2开始试。如果显示内存不足、进程被 kill那就需要换更小的模型或者关闭更多系统服务。命令行验证通过后启动 HTTP 服务方便局域网内其他设备调用/root/llama-server -m /root/models/smollm2-135m-instruct-q4_0.gguf \ --host 0.0.0.0 --port 8080 -t 2注意--host 0.0.0.0表示监听所有网络接口这样局域网内其他设备都能访问。出于安全考虑建议在路由器上做好隔离不要把 8080 端口暴露到公网。4.5 测试接口在电脑上测试 llama-server 是否正常工作curl http://192.168.1.100:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {model:smollm2-135m-instruct,messages:[{role:user,content:你好简单介绍一下自己}]}llama-server 提供 OpenAI 兼容的/v1/chat/completions接口这意味着很多现成的客户端代码、聊天前端都可以直接接进来。返回结果是一个 JSON里面包含模型生成的回复内容。到这里Echo Dot 2 作为一台“本地 LLM 服务器”已经成立了。5. 更实用的形态Echo Dot 2 作为本地 LLM 终端5.1 设备内存不够时的分流架构如果你追求更好的对话质量和更快的速度不必把大模型硬塞进 Echo Dot 2。在家庭局域网里可以把它设计成一个“语音壳”真正的模型放在性能更好的设备上。一个典型的分流架构是Echo Dot 2 负责音频采集、按键唤醒、播放声音局域网内一台 PC 或树莓派运行 Whisper语音转文字 OllamaLLM Piper文字转语音Echo Dot 2 通过网络请求把录音发给服务器再把服务器返回的语音播放出来。这种方案的好处是数据仍然不出家庭局域网隐私可控同时模型选择范围大得多。Echo Dot 2 的角色从“LLM 推理机”变成了“LLM 语音终端”更符合它原来的产品定位。5.2 用 Ollama 在服务器端跑模型如果家里有一台多核 CPU 或带 N 卡的电脑直接用 Ollama 部署服务器端模型是最省事的方案# 在服务器上安装 ollama然后拉取模型 ollama pull qwen2.5:3b ollama serve默认 Ollama 监听127.0.0.1:11434要让局域网设备访问需要把监听地址改成0.0.0.0OLLAMA_HOST0.0.0.0 ollama serveEcho Dot 2 上的服务只需要调用接口即可。下面是一个用 Python 写的极简调用示例可以放到 Echo Dot 2 上作为测试脚本import requests def chat(prompt: str) - str: resp requests.post( http://192.168.1.200:11434/api/chat, json{ model: qwen2.5:3b, messages: [{role: user, content: prompt}], stream: False, }, timeout30, ) data resp.json() return data[message][content] if __name__ __main__: print(chat(写一句关于智能家居的欢迎语))注意这里的 IP192.168.1.200要替换成你服务器的实际 IP。在生产环境下建议不要用明文 HTTP 暴露服务至少限定在可信局域网加一层简单的 API Token 更稳妥。5.3 编写唤醒与转发脚本如果你想做语音交互Echo Dot 2 自带麦克风阵列但原厂驱动和音频链路不一定完全兼容你刷入的自定义系统。这一块是项目里最需要耐心的部分因为它涉及 ALSA 音频驱动、唤醒词引擎和录音管道的打通。一个可行的渐进策略是先用按键触发录音跑通“录音 → 上传 → 返回文字 → 播放”的闭环再引入离线唤醒词引擎如 Porcupine用关键词唤醒设备最后再尝试使用自带麦克风阵列进行声源定位和降噪这一步难度最高。如果只是做“本地 LLM 聊天盒子”完全可以先跳过语音直接用局域网 Web 页面或 MQTT 来控制。比如在 Echo Dot 2 上运行一个 MQTT 订阅脚本通过 Home Assistant 向它发送文本指令让它生成回复并推送消息这也是一种非常实用的落地方式。5.4 开机自启动与日志不要让 LLM 服务只能手动启动。当你刷完系统、调试稳定后应该把服务配置成开机自动运行。如果设备使用 systemd可以创建服务文件# 文件路径/lib/systemd/system/llama.service [Unit] DescriptionLocal LLM Server Afternetwork.target [Service] ExecStart/root/llama-server -m /root/models/smollm2-135m-instruct-q4_0.gguf --host 0.0.0.0 --port 8080 -t 2 Restarton-failure Userroot [Install] WantedBymulti-user.target然后执行systemctl enable llama.service systemctl start llama.service systemctl status llama.service如果设备没有 systemd只能用/etc/init.d脚本或 crontabreboot方式实现写法取决于你的 rootfs 实际使用的 init 系统。日志方面建议把 stdout 和 stderr 重定向到文件方便排查问题/root/llama-server ... /var/log/llama.log 21 6. 常见问题与排查思路以下问题按“现象 → 可能原因 → 解决思路”整理成一张速查表建议刷机前先存一份。问题现象常见原因解决思路串口屏幕没有任何输出TX/RX 接反、没有共地、波特率错误交换 TX/RX检查 GND尝试 115200/57600/38400设备反复重启bootargs中 root 分区写错、内核 panic恢复原始bootargs检查分区表执行llama-cli报 Exec format error交叉编译架构与设备 CPU 不匹配用uname -m确认架构重新编译启动模型时进程被 OOM killer 杀掉模型体积超过可用内存换更小模型关闭系统服务降低-t线程数减小上下文提示 mmap 失败或内存不足模型文件超过内存映射限制尝试 Q4_0 量化检查 swap 是否可用拷贝到设备后提示找不到动态库使用了动态链接设备缺库用-DCMAKE_EXE_LINKER_FLAGS-static重新编译模型输出乱码或重复模型 tokenizer 与 llama.cpp 版本不匹配升级 llama.cpp重新转换 GGUF 文件Wi-Fi 连接不稳定电源供电不足、驱动兼容问题更换电源检查内核日志 dmesg设备发热严重长时间满载推理降低线程数增加散热片避免长时间高负载修改文件后重启被还原rootfs 是只读挂载或固件校验确认 remount rw检查启动脚本是否被恢复6.1 关于 OOM内存不足的进一步说明Echo Dot 2 内存紧张OOM 是最常见的失败方式。在启动 llama-server 前可以先查看内存余量free -m如果总量 512MB系统运行占用 150MB那么模型能用的空间可能不到 350MB。这时候 0.5B 模型 Q4 量化后约 400MB就非常危险。建议明确以下三点用-c 256之类的小上下文减少 KV cache 占用用 mmap 方式加载模型llama.cpp 默认行为让权重按页加载而不是一次性全部读入内存如果 swap 可用可以加一个小的 swap 文件但 eMMC 寿命有限不要频繁换页。7. 最佳实践与工程建议7.1 把备份当成第一原则凡是涉及 eMMC 的写操作先备份再动手。你可以建立一套固定流程记录原版bootargs→ 备份关键分区 → 修改 → 验证 → 恢复。这样即使改坏也能快速回到初始状态。7.2 最小化系统服务Echo Dot 2 的硬件很弱跑 LLM 已经是超高负载。刷机后应该关闭不需要的服务蓝牙、音频播放守护进程、云服务客户端、日志服务等能关的都关。每节省 10MB 内存模型上下文就能大一点。7.3 网络与安全边界设备被 root 之后就相当于家里多了一台可被入侵的 Linux 主机。建议不要开启路由器端口映射不要把 8080/22 暴露到公网SSH 使用密钥登录关闭密码登录修改默认密码在路由器上单独划分 IoT 网段限制它只能访问家庭服务器定期检查/var/log看是否有异常连接。7.4 尽量使用静态链接交叉编译程序时优先静态链接。虽然静态链接会让二进制体积变大但在嵌入式系统里能省掉“缺库”的麻烦。如果静态链接失败某些库如 glibc 的 NSS 模块会有问题再考虑把对应动态库一起拷贝到设备上。7.5 性能调优从线程数开始Echo Dot 2 的 CPU 核心数少-t 2和-t 4的实测差距可能不大甚至线程过多还会导致上下文切换开销。建议用time命令对比不同线程数下的推理耗时选择一个最优值。另外关闭 CPU 调频的省电模式、接上稳定电源也能让推理速度更稳定。7.6 关注 eMMC 寿命小模型反复写日志、频繁使用 swap、格式化分区都会消耗 eMMC 的写入寿命。建议把日志写到 tmpfs内存文件系统或者限制日志大小。LLM 模型文件属于只读数据放 eMMC 没问题但临时文件和缓存尽量放 tmpfs。8. 总结与下一步把一台吃灰的 Echo Dot 2 改造成本地 LLM 设备是一条很完整的嵌入式技术链路拆机看到 UART 调试口通过 uboot 修改启动参数拿到 root shell备份分区后交叉编译 llama.cpp再选择合适的小模型量化部署。整个过程涉及硬件调试、Linux 系统、编译工具链、模型量化四个知识面啃下来之后你再看到市面上任何一台“智能音箱”都会下意识思考它内部的启动流程和可扩展性。下一步你可以往这几个方向深入研究 Wake Word 引擎让 Echo Dot 2 真正支持语音唤醒接入 Home Assistant把 LLM 生成的文本通过 MQTT 变成智能家居自动化动作尝试更小的蒸馏模型或自定义数据集微调让设备上的模型更贴合你的家庭场景把这套流程迁移到其他设备上比如旧路由器、电视盒子、开源开发板。动手之前先把设备拆开、接好串口、做完备份。只要做好了这三件事后面即使改错也有回头路。老硬件的浪漫就在于它不会被“过时”两个字定义只要还有人愿意为它写代码它就能继续发光。
返回列表