华硕路由器刷Merlin固件，用Go打造AI提示流编排器

1. 为什么要在路由器上跑 AI 提示流把 AI 引擎塞进一台华硕路由器听起来像是极客的恶趣味但真做过一轮之后你会发现这个方向解决的是一个非常具体的痛点家庭和小型办公网络里越来越多的智能请求需要就近处理而把所有数据都往云端丢既不经济也不够快。我最初动这个念头是因为家里那台常年开着的华硕路由器刷了 Merlin 固件算力其实一直闲着而我又不想为了跑几个提示词编排任务专门再开一台小主机或者租一台云服务器。所谓AI 提示流编排器说白了就是把多个 AI 调用步骤串成一条流水线先做意图识别再决定走哪个模型接着做参数填充、结果校验、格式转换最后把结果吐给下游。这套东西如果放在云端每次都要走一遍网络往返延迟叠加起来很可观而放在路由器这种边缘网关上局域网内的设备请求可以在一跳之内完成编排响应快、隐私好、还省了云端的调用成本。关键词里提到的Merlin、边缘网关、Go三个词基本勾勒出了整个方案的技术骨架。Merlin 是华硕路由器的第三方固件生态它提供了比原厂固件更开放的软件包管理能力和可执行环境边缘网关指的是路由器在这个架构里扮演的角色——它不再只是转发数据包而是承担一部分计算和决策Go 语言则是实现这个编排器的首选因为它的交叉编译极其方便、运行时依赖少、内存占用可控非常适合在路由器这种资源受限的设备上跑。这篇文章适合三类人看一是手里有华硕路由器、刷了 Merlin 固件、想折腾点新玩法的玩家二是做 IoT 或边缘计算、需要理解轻量网关如何承载 AI 编排的开发者三是想学 Go 语言在嵌入式/边缘场景落地实践的工程师。我会从硬件与固件的可行性判断讲起一路讲到编排器的核心设计、部署细节和实测踩坑尽量把每一步的“为什么”都说清楚。需要先说明一点路由器上的资源是有限的别指望它能跑动大模型推理。我们做的是编排也就是调度和串联真正的模型推理还是交给局域网内的其他算力节点或者云端 API。路由器在这里的价值是“就近调度 协议转换 缓存加速”把这个定位想清楚后面的设计才不会跑偏。2. 华硕路由器 Merlin 固件的可行性边界2.1 先搞清楚你手里这台机器能不能干活不是所有华硕路由器都适合干这件事。核心看三个指标CPU 架构、可用内存、以及 JFFS 分区大小。Merlin 固件支持的大部分中高端型号比如 RT-AX88U、RT-AC86U 这类用的是 ARM 架构Go 交叉编译到 ARM 非常成熟这是前提。内存方面我建议至少 512MB因为 Go 运行时本身加上编排逻辑再留出缓存空间256MB 会非常紧张。你可以通过 SSH 登录路由器后跑几条命令快速摸底# 查看 CPU 架构 uname -m # 查看内存总量和可用量 free -m # 查看 JFFS 可用空间 df -h | grep jffs我实测下来RT-AX88U 这类机器uname -m返回aarch64内存 1GBJFFS 有几十 MB 可用跑一个轻量 Go 服务绰绰有余。但如果你的是入门型号内存只有 256MB那就要慎重了可能跑起来之后路由器本身的转发性能都会受影响。提示JFFS 分区是用来持久化存储的重启不丢。但它的读写寿命有限不要把高频写入的日志或缓存放在这里建议把运行时数据放到/tmp或者挂载一个 U 盘。2.2 Merlin 固件给了你哪些原厂没有的能力原厂固件最大的问题是封闭你没法方便地安装自定义软件包。Merlin 固件在这方面开放了很多它内置了Entware的支持Entware 是一个面向嵌入式设备的软件包管理器你可以用它安装 Python、curl、jq 这类工具。但要注意Entware 里的 Go 工具链往往版本较老我建议不要在路由器上编译 Go 程序而是在开发机上交叉编译好再把二进制文件传上去。Merlin 还提供了JFFS 脚本钩子比如services-start、firewall-start这些可以让你在路由器启动时自动拉起自己的服务。这是实现“开机自启”的关键后面部署章节会详细讲。另外一个容易被忽略的点是Merlin 的防火墙和端口管理。默认情况下路由器对外的端口是关闭的你要跑一个 HTTP 服务给局域网设备调用需要在防火墙规则里放行对应端口或者干脆只监听内网网段。我一般选择后者安全省事。2.3 资源受限下的设计取舍在路由器上做开发最重要的一条原则是能省则省。我总结了几个具体的取舍取舍点云端做法路由器上的做法原因模型推理本地加载模型只做编排推理外调算力不够数据存储数据库内存缓存 文件减少 IO 和依赖并发模型大规模线程池有限 goroutine 队列内存和 CPU 有限日志全量落盘环形缓冲 按需输出保护 JFFS 寿命依赖管理随便引库尽量用标准库减小二进制体积这张表是我踩了不少坑之后总结出来的。比如一开始我想在路由器上直接存调用历史到 SQLite结果发现 SQLite 的写入会频繁触发 JFFS 擦写而且 CGO 编译出来的二进制体积大了一倍。后来改成内存里维护一个固定长度的环形缓冲需要持久化的时候再异步写文件问题就解决了。3. 提示流编排器的核心架构设计3.1 编排器到底在编排什么很多人对“提示流编排”这个概念比较模糊我用一个具体场景来解释。假设你在家里搭了一个语音助手用户说“帮我把客厅灯调暗一点然后放点轻音乐”。这句话进来之后需要经过这么几步意图识别判断这是两个意图——调灯和放音乐。参数抽取从“调暗一点”里抽出设备是客厅灯、动作是调暗从“轻音乐”里抽出音乐类型。路由决策调灯走本地设备控制接口放音乐走某个音乐服务。执行与校验分别调用检查是否成功。结果聚合把两个结果合并成一句自然的回复。这一整条链路就是一条提示流。编排器的职责就是定义这条流、按顺序执行、处理中间的错误和分支。在路由器上我们不可能用太重的工作流引擎所以核心设计要足够轻。我的做法是用Go 的 goroutine channel来实现一个极简的 DAG有向无环图执行器。每个节点是一个处理函数节点之间通过 channel 传递数据。这样既利用了 Go 的并发优势又不需要引入任何外部工作流库。3.2 用 Go 实现一个极简 DAG 执行器先看核心数据结构。一个节点包含它的名字、处理函数、以及下游节点的列表type Node struct { Name string Handler func(ctx context.Context, input []byte) ([]byte, error) Next []string } type Pipeline struct { nodes map[string]*Node entry string }执行的时候从入口节点开始每个节点处理完把结果发给所有下游。这里有个细节如果下游有多个节点是并行执行还是串行我的选择是并行因为路由器上大部分编排步骤是 IO 密集型的等 API 返回并行能显著降低总延迟。但并行也带来了结果聚合的问题所以我用一个sync.WaitGroup加一个结果收集 channel 来处理。func (p *Pipeline) Run(ctx context.Context, input []byte) ([]byte, error) { results : make(chan []byte, len(p.nodes)) var wg sync.WaitGroup wg.Add(1) go p.execNode(ctx, p.entry, input, results, wg) go func() { wg.Wait() close(results) }() var final []byte for r : range results { final r // 简化处理实际需要按节点聚合 } return final, nil }这段代码是简化版实际实现里我加了节点级别的超时控制、错误传播和结果合并策略。但核心思路就是这样用最少的抽象把编排逻辑跑起来。3.3 为什么不用现成的工作流引擎你可能会问为什么不用 Temporal、Argo 这类成熟的工作流引擎答案很简单它们在路由器上跑不起来。这些引擎要么依赖数据库要么依赖消息队列要么二进制体积几十 MB 起步。路由器那点资源光是启动它们就撑不住。我试过把某个轻量工作流库交叉编译到 ARM结果二进制 40 多 MBJFFS 直接放不下。后来自己写的这个 DAG 执行器编译出来不到 8MB内存占用稳定在 20MB 以内这才是路由器能接受的量级。注意自己写执行器意味着你要自己处理超时、重试、错误传播这些细节。别小看这些我第一版就是因为没做超时控制某个下游 API 卡住之后整个编排器都挂死了。4. 把 Go 二进制塞进路由器的完整流程4.1 交叉编译在开发机上生成 ARM 可执行文件Go 的交叉编译是它最大的优势之一。假设你的路由器是 ARM64 架构aarch64在开发机上只需要设置两个环境变量GOOSlinux GOARCHarm64 CGO_ENABLED0 go build -ldflags-s -w -o orchestrator这里有几个关键点要解释。CGO_ENABLED0是必须的因为路由器上没有完整的 C 库开启 CGO 会导致二进制依赖动态链接库传上去跑不起来。-ldflags-s -w是去掉调试信息和符号表能把二进制体积缩小 30% 左右。我实测一个中等复杂度的编排器不加这个参数是 12MB加了之后 8MB 出头。编译完之后用file命令确认一下架构对不对file orchestrator # 应该输出类似ELF 64-bit LSB executable, ARM aarch64如果输出的是 x86-64说明环境变量没生效检查一下是不是在命令前正确设置了。4.2 传输与权限设置把二进制传到路由器上我习惯用scpscp orchestrator admin192.168.50.1:/jffs/orchestrator/传上去之后SSH 登录路由器给它加上可执行权限chmod x /jffs/orchestrator/orchestrator这里有个坑Merlin 固件的 JFFS 分区默认可能没有挂载可执行权限。如果你执行的时候报Permission denied检查一下挂载参数mount | grep jffs如果看到noexec那就需要重新挂载或者把二进制放到/tmp下执行。我一般选择后者因为/tmp是内存文件系统执行权限没问题而且读写速度快。但缺点是重启会丢所以启动脚本里要包含“从 JFFS 拷贝到 /tmp 再执行”的逻辑。4.3 开机自启用 Merlin 的 services-start 钩子Merlin 固件会在启动时执行/jffs/scripts/目录下的几个钩子脚本其中services-start是最适合拉起自定义服务的。我的做法是创建一个启动脚本#!/bin/sh # /jffs/scripts/services-start # 等待网络就绪 sleep 30 # 拷贝二进制到内存文件系统 cp /jffs/orchestrator/orchestrator /tmp/orchestrator chmod x /tmp/orchestrator # 启动服务日志重定向到文件 /tmp/orchestrator -config /jffs/orchestrator/config.json /tmp/orchestrator.log 21 别忘了给脚本加执行权限chmod x /jffs/scripts/services-start那个sleep 30是我踩坑之后加的。一开始没加结果服务启动的时候网络还没完全就绪编排器尝试连接下游 API 全部失败。后来加了等待时间问题解决。具体等多久取决于你的路由器启动速度可以先用sleep 60保守一点稳定之后再往下调。5. 轻量边缘网关的通信与协议转换5.1 为什么路由器适合做协议转换层家庭网络里的设备协议五花八门有的用 HTTP有的用 MQTT有的用私有 TCP 协议还有的只支持串口。如果每个上层应用都要自己去适配这些协议开发成本极高。而路由器作为网络的中心节点天然适合做协议转换层——把各种异构协议统一成一种内部格式上层应用只需要跟路由器打交道。我在编排器里设计了一个适配器层每个适配器负责一种协议。比如 MQTT 适配器订阅某个主题收到消息后转成内部 JSON 格式再交给编排器处理。这样上层逻辑完全不用关心底层是什么协议。type Adapter interface { Name() string Start(ctx context.Context, out chan- Message) error Send(ctx context.Context, msg Message) error } type Message struct { Source string Payload []byte Meta map[string]string }这个接口设计的关键是out chan- Message适配器把收到的消息往 channel 里丢编排器从 channel 里读。这样适配器和编排逻辑完全解耦加一个新协议只需要实现这个接口。5.2 局域网内的服务发现与调用编排器需要调用局域网内的其他服务比如模型推理节点、设备控制接口。这些服务的地址如果写死在配置里一旦 IP 变了就要改配置。我的做法是用mDNS做服务发现让各个服务自己广播自己的存在。Go 里有现成的 mDNS 库但考虑到路由器资源有限我简化了一下用一个静态配置 健康检查的方案配置文件里列出所有下游服务的地址编排器定期 ping 它们的健康检查接口把可用的服务维护在一个列表里。调用的时候从可用列表里选。{ services: [ {name: llm-node, url: http://192.168.50.10:8080/health, weight: 1}, {name: device-ctrl, url: http://192.168.50.20:9090/health, weight: 1} ], health_check_interval: 30 }这个方案比 mDNS 简单但足够用。weight字段是为了后面做负载均衡预留的如果同一个服务有多个实例可以按权重分配请求。5.3 请求缓存与去重边缘网关有一个天然优势它能看到所有经过它的请求。这意味着它可以在本地做缓存和去重。比如同一个提示词在短时间内被多个设备请求编排器可以只调用一次下游然后把结果分发给所有请求方。我用一个带过期时间的 map 来实现这个缓存type Cache struct { mu sync.RWMutex items map[string]cacheItem } type cacheItem struct { value []byte expires time.Time }缓存 key 是提示词内容的哈希value 是下游返回的结果。过期时间我设的是 60 秒因为大部分场景下提示词的结果不需要实时到秒级。这个缓存命中率在实测中能达到 30% 左右对减少下游压力很有帮助。提示缓存要注意内存占用。我设了一个最大条目数超过之后按 LRU 淘汰。路由器内存有限不设上限的话缓存会把内存吃光。6. 实测中的性能表现与踩坑记录6.1 延迟与吞吐的实测数据我在 RT-AX88U 上跑了一轮压测编排器处理一个包含 3 个节点的提示流意图识别、参数抽取、结果格式化下游是一个局域网内的推理服务。测试结果如下指标数值说明单次编排延迟无缓存45-60ms主要是下游推理耗时单次编排延迟缓存命中2-5ms几乎就是内存读取并发 10 请求平均 80ms有排队但不严重并发 50 请求平均 320ms开始出现明显排队内存占用18-25MB稳定CPU 占用空闲1%几乎不占CPU 占用满载40-60%单核跑满这组数据说明路由器上的编排器适合中低并发场景。如果你家里有几十个设备同时发请求那可能需要考虑把编排器放到更强的硬件上。但对大多数家庭和小型办公场景这个性能完全够用。6.2 我踩过的三个典型坑第一个坑goroutine 泄漏。我最初的实现里每个请求都起一个 goroutine 去调用下游但没有设置超时。结果某个下游服务偶尔卡住goroutine 就一直挂着跑了一天之后路由器内存被吃光直接重启了。修复方法是给每个下游调用都加上context.WithTimeout超时之后强制返回。第二个坑日志写爆 JFFS。我一开始把日志全量写到 JFFS 分区结果跑了几天之后 JFFS 满了路由器各种异常。后来改成日志写到/tmp内存文件系统并且限制日志文件大小超过就轮转。JFFS 只存配置和二进制不存运行时数据。第三个坑DNS 解析阻塞。编排器需要解析下游服务的域名但路由器的 DNS 有时候会抽风解析一个域名要好几秒。这个问题很隐蔽因为平时看不出来只有 DNS 慢的时候才暴露。我的解决方案是在启动时把所有下游域名解析成 IP 缓存起来后续直接用 IP 调用定期刷新缓存。6.3 稳定性优化的几个实用技巧除了上面三个坑我还总结了几个让服务更稳的技巧用 systemd 风格的守护虽然 Merlin 没有 systemd但我写了一个简单的守护脚本定期检查编排器进程是否还在不在就拉起来。限制并发数用一个带缓冲的 channel 做信号量限制同时处理的请求数避免过载。优雅退出收到终止信号时等待正在处理的请求完成再退出避免请求丢失。配置热加载配置文件改动后不用重启编排器定期检查文件修改时间有变化就重新加载。这些技巧看起来琐碎但正是它们决定了服务能不能长期稳定运行。我在实际使用中发现一个能跑一天的服务和一个能跑一年的服务差距往往就在这些细节上。7. 从单机编排到多节点协同的扩展思路7.1 什么时候需要考虑多节点单台路由器上的编排器能撑住的并发是有限的。当你发现 CPU 经常跑满、请求排队严重的时候就该考虑扩展了。扩展的方向有两个纵向是换更强的硬件横向是加节点做集群。横向扩展的思路是多台路由器或者路由器 小主机各自跑一个编排器实例前面加一个简单的负载均衡。但这里有个问题编排器的状态比如缓存是分布式的怎么同步我的做法是不做强同步每个节点维护自己的缓存允许不一致。因为提示流的缓存本来就是尽力而为的不一致带来的影响很小。7.2 节点间通信的轻量方案节点之间需要通信的场景主要有两个一是共享一些全局配置二是做请求转发。我用的是最简单的方案基于 HTTP 的 gossip。每个节点定期向其他节点广播自己的状态负载、可用性收到广播的节点更新自己的节点列表。type NodeInfo struct { ID string Address string Load float64 LastSeen time.Time }这个方案不追求强一致性只追求最终一致。在家庭网络这种小规模场景下完全够用。而且实现简单不需要引入 etcd、Consul 这类重型组件。7.3 这个方向还能怎么玩把 AI 编排器塞进路由器只是边缘智能的一个起点。顺着这个思路还能做很多有意思的扩展本地模型缓存把常用的提示词和结果缓存在路由器上形成一个“提示词 CDN”。设备联动编排器直接对接家里的智能设备实现“一句话控制全屋”。隐私过滤在数据出局域网之前编排器先做一遍敏感信息过滤保护隐私。离线降级云端 API 不可用的时候自动切换到本地的小模型或者规则引擎。这些扩展的共同点是利用路由器的位置优势在数据离开局域网之前做尽可能多的事情。这也是边缘计算的核心价值所在。我个人在实际操作中的体会是路由器这个平台虽然资源有限但它的稳定性和常驻特性是其他设备比不了的。一台路由器可以连续运行几个月不出问题而你的开发机可能每天都要重启。把一些轻量的、常驻的服务放在路由器上是一种被低估的架构选择。当然前提是你得接受它的性能边界别指望它干重活。把编排、缓存、协议转换这些“轻活”交给它把推理、训练这些“重活”留给更强的节点各司其职整个系统反而更稳。