1. 为什么要在路由器上跑 AI 提示流把 AI 引擎塞进一台华硕路由器听起来像是极客的恶趣味但真做过一轮之后你会发现这个方向解决的是一个非常具体的痛点家庭和小型办公网络里越来越多的智能请求需要就近处理而不是全部甩到云端。我最初动这个念头是因为家里那台常年开着的路由器其实一直处于算力闲置状态。它每天做的事情无非是拨号、转发、跑个轻量级服务CPU 占用长期在个位数徘徊。而与此同时我手头有一堆零散的 AI 调用需求定时把某些文本做摘要、把设备日志做归类、把语音转写后的内容做结构化整理。这些任务单个都不重但全都依赖外部服务一旦网络抖动或者服务限流整条链路就断了。于是就有了这个项目用 Merlin 插件做载体用 Go 写一个轻量边缘网关在路由器本地完成 AI 提示流的编排与调度。所谓提示流编排器说白了就是把输入 → 预处理 → 调用模型 → 后处理 → 输出这一串动作做成可配置、可组合、可复用的流水线而不是每次都在代码里硬编码。这个项目适合谁如果你满足下面任意一条那这篇内容对你会很有用手里有华硕路由器刷了 Merlin 固件想榨干它的剩余价值写过一些 Go想找一个真实的小项目练手而不是停留在语法层面对边缘计算感兴趣但不想一上来就搞 FPGA、搞通信测试终端那种重资产方案需要把 AI 能力下沉到本地减少对外部服务的强依赖。需要提前说明的是路由器上的资源非常有限。我用的这台是 ARM 架构、内存 512MB 级别的机型能跑起来的东西必须足够轻。所以整个方案的核心思路是Go 编译成静态二进制网关只做编排和转发真正的模型推理要么走本地小模型要么走可配置的远端接口。这个边界一定要先划清楚否则后面会不断踩坑。2. Merlin 插件机制与运行环境摸底2.1 Merlin 固件的插件加载逻辑Merlin 固件本质上是华硕官方固件的一个增强分支它保留了官方的底层框架同时开放了一些扩展点。插件通常放在/jffs/分区下这个分区是可读写的掉电后内容保留是放自定义程序的最佳位置。插件要能被系统识别一般需要满足几个条件有一个可执行的入口脚本、有对应的配置声明、能被services-start之类的启动钩子调用。我实测下来最省事的做法是把自己的二进制和启动脚本都丢进/jffs/scripts/和/jffs/下的自定义目录然后在services-start里加一行调用。这里有个容易忽略的点Merlin 的启动脚本执行时机比较早此时网络可能还没完全就绪。如果你的网关启动时要绑定端口或者做 DNS 解析直接跑会失败。我的处理方式是在启动脚本里加一个等待循环检测到默认路由可用之后再拉起网关进程。#!/bin/sh # /jffs/scripts/services-start 片段 while ! ip route | grep -q default; do sleep 2 done /jffs/ai-gateway/start.sh 2.2 ARM 环境下的 Go 交叉编译要点路由器是 ARM 架构而我的开发机是 x86 的所以必须交叉编译。Go 在这方面非常友好设置好GOOS和GOARCH就行GOOSlinux GOARCHarm GOARM7 go build -ldflags-s -w -o ai-gateway .几个关键参数解释一下。GOARM7对应 ARMv7 指令集绝大多数中高端华硕路由器都是这个。-ldflags-s -w是去掉符号表和调试信息能把二进制体积压下来不少我实测从 12MB 压到了 8MB 左右对路由器那点存储空间来说很关键。注意如果你的路由器是较新的型号可能是 ARM64那就把GOARCH换成arm64并且不需要GOARM。编译前最好先uname -m确认一下目标架构别想当然。还有一个坑Go 默认会动态链接一些库但路由器上的 libc 版本可能和编译机不一致。解决办法是加CGO_ENABLED0强制静态编译这样二进制不依赖目标机的任何动态库扔过去就能跑。CGO_ENABLED0 GOOSlinux GOARCHarm GOARM7 go build -ldflags-s -w -o ai-gateway .2.3 存储与内存的现实约束路由器上能用的存储通常只有几十 MB 的 JFFS 空间内存也就几百 MB。这意味着二进制不能太大8MB 已经是比较舒服的上限不能把模型文件放本地除非是极小的量化模型运行时内存占用要控制Go 的 GC 虽然好用但默认参数在低内存环境下可能过于激进。我做过一次内存压测网关在空闲时占用约 15MB处理请求峰值到过 40MB。这个数字在 512MB 内存的机器上是安全的但如果你的路由器只有 256MB就要更谨慎可能需要限制并发数。3. 提示流编排器的核心设计3.1 把提示流抽象成可组合的节点编排器的核心思想是把一次 AI 处理拆成若干个节点Node每个节点做一件小事节点之间用数据流连接。这样设计的好处是新增一种处理逻辑只需要加一个节点而不用改动整条链路。我定义的节点类型主要有这几类节点类型作用典型场景Input接收原始输入HTTP 请求体、文件内容Transform对数据做转换模板填充、字段提取Model调用模型本地推理或远端接口Condition条件分支根据内容长度走不同路径Output输出结果返回响应、写入日志每个节点实现一个统一的接口输入是上一步的输出输出传给下一步。这种设计参考了管道Pipeline的思路但在 AI 场景下多了模型调用这个异步环节所以接口设计上要支持超时和重试。type Node interface { Name() string Process(ctx context.Context, input []byte) ([]byte, error) }接口保持极简只有Process一个方法。上下文用来传递超时和取消信号这在边缘环境下特别重要——网络不稳定时一个卡住的请求可能拖垮整个网关。3.2 用配置文件描述一条完整的流节点定义好之后怎么把它们串起来我的选择是用 YAML 配置文件描述而不是写死在代码里。这样改流程不用重新编译直接改配置重启即可。flow: name: log-summarize nodes: - name: input type: input - name: clean type: transform params: template: 请对以下日志做归类{{.content}} - name: infer type: model params: endpoint: http://127.0.0.1:8080/v1/chat timeout: 30s retry: 2 - name: output type: output这个配置描述了一条日志归类的流先接收输入然后用模板把内容包进提示词再调用模型最后输出。整个过程对调用方来说就是一个 HTTP 接口内部怎么编排是透明的。提示模板里的{{.content}}是 Go 的 text/template 语法用起来很顺手。但要注意对输入做转义避免用户输入的内容破坏模板结构。3.3 为什么选 Go 而不是 Python这个问题我被问过很多次。Python 写 AI 相关的东西确实生态好但在路由器这个环境下Go 有几个压倒性的优势第一是部署简单。Go 编译出来就是一个静态二进制扔过去就能跑不需要装解释器、不需要配虚拟环境。路由器上装 Python 环境本身就是个麻烦事各种依赖还可能编译不过。第二是资源占用低。Go 的运行时开销比 Python 小得多启动速度快内存占用可控。在 512MB 内存的机器上这个差距是决定性的。第三是并发模型适合网关场景。Go 的 goroutine 处理大量并发请求非常自然而网关的核心工作就是转发和编排天然是高并发的。当然Go 也有短板比如做复杂的文本处理不如 Python 顺手。但在这个项目里复杂的处理都交给模型了网关本身只做轻量的编排所以这个短板影响不大。4. 边缘网关的请求处理链路4.1 从 HTTP 入口到节点调度网关对外暴露的是一个标准的 HTTP 接口调用方不需要知道内部有多少个节点。请求进来之后处理链路大致是这样的解析请求提取流名称和输入数据根据流名称加载对应的配置按顺序执行节点把上一步的输出传给下一步收集最终结果返回给调用方。这里有个设计决策值得说一下我选择了同步执行而不是异步队列。原因是路由器上的任务大多是轻量的、实时的引入队列会增加复杂度和内存占用收益不明显。如果某个流确实很慢那应该在配置里设置合理的超时而不是靠队列来缓冲。func (e *Engine) Run(ctx context.Context, flowName string, input []byte) ([]byte, error) { flow, ok : e.flows[flowName] if !ok { return nil, fmt.Errorf(flow not found: %s, flowName) } data : input for _, node : range flow.Nodes { var err error data, err node.Process(ctx, data) if err ! nil { return nil, fmt.Errorf(node %s failed: %w, node.Name(), err) } } return data, nil }这段代码是整个引擎的核心逻辑很直白按顺序跑节点任何一步出错就中断并返回错误。错误信息里带上节点名称方便排查问题。4.2 超时、重试与降级策略边缘环境最大的特点就是不稳定。网络可能断远端服务可能限流本地资源可能被抢占。所以网关必须有一套完整的容错机制。超时是最基本的。每个模型节点都应该有独立的超时设置我一般设 30 秒因为大部分文本处理任务在这个时间内都能完成。超时之后根据配置决定是否重试。重试策略我用的是指数退避第一次失败等 1 秒第二次等 2 秒第三次等 4 秒。这样既能应对偶发的网络抖动又不会在服务真的挂掉时疯狂重试把资源耗光。func (n *ModelNode) Process(ctx context.Context, input []byte) ([]byte, error) { var lastErr error for i : 0; i n.retry; i { if i 0 { time.Sleep(time.Duration(1uint(i-1)) * time.Second) } result, err : n.call(ctx, input) if err nil { return result, nil } lastErr err } return nil, lastErr }降级策略则是最后一道防线。如果模型调用彻底失败可以配置一个兜底节点返回一个默认结果或者原始输入至少保证调用方不会拿到一个硬错误。4.3 本地模型与远端接口的混合调度这个项目里模型调用有两种模式本地和远端。本地模式适合轻量任务比如简单的文本分类、关键词提取远端模式适合复杂任务比如长文本摘要、多轮对话。混合调度的关键在于路由规则。我在配置里加了一个route字段可以根据输入的特征决定走哪条路- name: infer type: model params: routes: - when: len(content) 200 endpoint: http://127.0.0.1:8080/v1/chat - when: len(content) 200 endpoint: https://api.example.com/v1/chat timeout: 60s短文本走本地长文本走远端这样既节省了本地算力又保证了复杂任务的处理质量。when条件用的是简单的表达式求值我实现了一个极简的解析器支持长度比较和关键词匹配够用就行。5. 实测中的性能与稳定性问题5.1 内存泄漏的排查过程项目跑起来之后我遇到过一个很典型的问题网关运行几天后内存占用越来越高最后被系统 OOM 杀掉。这个问题在开发机上完全复现不出来因为开发机内存大跑几天也看不出异常。排查过程是这样的。首先确认不是配置问题因为重启后内存会回落。然后怀疑是 goroutine 泄漏用pprof抓了一份 goroutine 快照发现数量确实在缓慢增长。顺着调用栈找下去问题出在模型节点的 HTTP 客户端上——每次调用都新建了一个http.Client而旧的客户端没有被回收。修复方法很简单把http.Client做成全局单例复用连接池var httpClient http.Client{ Timeout: 60 * time.Second, Transport: http.Transport{ MaxIdleConns: 10, MaxIdleConnsPerHost: 5, IdleConnTimeout: 90 * time.Second, }, }改完之后内存占用稳定在 20MB 左右连续跑一周没有明显增长。这个坑的教训是在资源受限的环境下任何每次新建的操作都要警惕连接、缓冲区、临时对象能复用就复用。5.2 高并发下的请求堆积第二个问题是并发。我做了个压测同时发 50 个请求结果发现响应时间急剧上升部分请求直接超时。原因有两个。一是模型调用本身是串行的本地模型一次只能处理一个请求二是网关没有做并发限制请求全堆在内存里等着。解决办法是引入信号量机制限制同时执行的流数量type Engine struct { sem chan struct{} } func (e *Engine) Run(ctx context.Context, flowName string, input []byte) ([]byte, error) { select { case e.sem - struct{}{}: defer func() { -e.sem }() case -ctx.Done(): return nil, ctx.Err() } // ... 执行流程 }信号量的容量根据路由器性能设置我设的是 4也就是最多同时跑 4 条流。超出的请求会等待等待时间超过上下文超时就直接返回错误。这样虽然牺牲了一部分吞吐但保证了系统的稳定性不会因为突发流量而崩溃。5.3 日志与可观测性的取舍路由器上的存储空间有限日志不能无限写。我的做法是只记录关键事件请求开始、请求结束、错误发生。每条日志包含时间戳、流名称、耗时、状态格式尽量紧凑。log.Printf(flow%s status%s cost%dms, flowName, status, cost.Milliseconds())不记录完整的请求和响应内容因为那会迅速把存储写满。如果确实需要调试可以临时开启详细日志排查完再关掉。注意日志文件要配置轮转否则再小的日志也会把 JFFS 写满。我用的是一个简单的按大小轮转策略超过 1MB 就切分保留最近 3 个文件。6. 从能跑到好用几个关键优化6.1 启动速度的优化网关的启动速度直接影响路由器的可用性。最初的版本启动要 5 秒以上主要时间花在加载配置和初始化模型客户端上。优化思路是延迟初始化配置在启动时加载但模型客户端等到第一次真正调用时才创建。这样启动时间压缩到了 1 秒以内路由器重启后网络恢复得更快。type ModelNode struct { clientOnce sync.Once client *http.Client } func (n *ModelNode) getClient() *http.Client { n.clientOnce.Do(func() { n.client http.Client{ /* ... */ } }) return n.client }sync.Once保证了客户端只创建一次同时又是线程安全的非常适合这种场景。6.2 配置热更新的实现每次改配置都要重启网关体验很差。所以我加了一个简单的热更新机制监听配置文件的变化检测到修改后重新加载。实现上用的是文件修改时间轮询每 10 秒检查一次。虽然不够优雅但在路由器这种环境下足够可靠而且实现简单不引入额外的依赖。func (e *Engine) watchConfig(path string) { var lastMod time.Time for { info, err : os.Stat(path) if err nil info.ModTime().After(lastMod) { lastMod info.ModTime() e.reload(path) } time.Sleep(10 * time.Second) } }重载的时候要注意加锁避免正在执行的请求读到半成品配置。我用的是读写锁读操作执行流加读锁重载操作加写锁。6.3 二进制体积的进一步压缩前面提到用-ldflags-s -w压缩体积但 8MB 对某些路由器来说还是偏大。进一步压缩可以用 UPX能把二进制压到 3MB 左右。不过 UPX 有个代价启动时需要解压会稍微慢一点。在路由器上这个差异大概是几百毫秒可以接受。如果你的存储特别紧张值得一试。upx --best --lzma ai-gateway提示UPX 压缩后的二进制在某些环境下可能被杀毒软件误报路由器上一般没这个问题但心里要有数。7. 这套方案还能怎么扩展跑通基础版本之后我陆续加了一些扩展这里挑几个有代表性的说说。第一个是 WASM 插件支持。Go 对 WASM 的支持不错可以把一些自定义的处理逻辑编译成 WASM 模块在网关里动态加载。这样扩展功能不需要重新编译整个网关只需要替换 WASM 文件。这个方向我还在摸索目前跑通了一个简单的文本替换插件。第二个是多路由器协同。如果家里有多台路由器可以让它们各自跑一个网关然后通过一个轻量的协调层做任务分发。这个思路和边缘计算的分布式架构是一致的只是规模小很多。第三个是和 NAS 的联动。我手头有一台飞牛 NAS上面跑着一些存储服务。网关可以把处理结果直接写到 NAS 的共享目录形成一个完整的采集 → 处理 → 存储链路。这个组合在实际使用中很顺手尤其是做日志归档和内容整理的时候。需要提醒的是扩展要克制。路由器资源有限每加一个功能都要评估它对内存和 CPU 的影响。我踩过的坑是加了一个看似轻量的缓存层结果因为缓存策略没设计好内存占用翻了一倍。后来把缓存改成固定大小、LRU 淘汰才把问题解决。8. 我在实际部署中总结的几条经验第一先在开发机上把逻辑跑通再往路由器上搬。路由器上调试很不方便没有完整的调试工具日志也有限。把能在本地验证的部分都验证完能省下大量时间。第二二进制一定要静态编译。动态链接在路由器上是个大坑libc 版本不匹配的问题会让你怀疑人生。CGO_ENABLED0是必须的。第三并发限制宁小勿大。路由器不是服务器别指望它能扛高并发。我一开始设的信号量容量是 10结果系统频繁卡顿降到 4 之后就稳定了。第四日志要克制。JFFS 空间宝贵日志写满了会导致整个系统出问题。关键事件记录详细内容按需开启用完就关。第五配置和代码分离。把流程定义放在配置文件里改流程不用重新编译。这个习惯在边缘设备上尤其重要因为编译和部署的成本比服务器高得多。这套方案我从最初的想法到稳定运行前后折腾了大概两周时间中间踩的坑基本都写在上面了。如果你也在琢磨怎么把 AI 能力下沉到边缘设备希望这些经验能帮你少走点弯路。路由器这个平台虽然资源紧张但正因为限制多反而逼着你去思考什么才是真正必要的这个过程本身就很有价值。