本地优先AI路由器GreenRoute：该让提示词离开你的笔记本吗？

一个被主流路由工具忽略的问题

每次你使用AI功能——无论是聊天机器人、写作助手还是"总结这段内容"的按钮——请求都会发送到数据中心。哪怕你只是问"澳大利亚的首都是哪里"，哪怕你笔记本上的小模型完全能答好这个问题。

市面上已有不少LLM路由工具：OpenRouter、NotDiamond、Martian，以及各大云平台内置的模型路由器。它们解决的是"哪个云端模型性价比最高"，但没有人在此之前问一句：这个请求到底需不需要离开设备？

开发者ironman2cool构建了GreenRoute来回答这个问题。它为每个请求判断是否应该本地处理，解释判断依据，并估算节省了多少资源。项目从周末黑客松原型起步，之后被重写为一个包含真实路由器、本地推理、基准测试和可验证数据的完整版本。

LLM路由（LLM routing）指在多个可用模型之间动态选择执行某个请求的过程，目标是兼顾质量、成本、延迟等指标。主流工具如OpenRouter、NotDiamond、Martian关注的都是云端模型之间的横向比较——例如用便宜的小模型处理简单问题、把难题交给旗舰模型。它们默认请求必须离开设备，因此优化空间仅限于“送到哪个云端”。GreenRoute提出的是一种正交的划分：先判断请求究竟需不需要出设备，再在“本地”与“云端”之间做二选一。这相当于把路由的决策空间从“云端模型集合”扩展为“本地 + 云端”的混合结构，也把能耗、水耗、隐私和离线可用性纳入优化目标。

核心机制：故意"无聊"的路由器

GreenRoute是一个基于FastAPI的轻量Python服务，前端是一个Web聊天界面。对每个提示词，它执行四步操作：分类请求（任务类型和复杂度）、检查设备状态（本地模型大小、可用内存、电池电量）、路由到本地模型（Ollama运行的Llama 3.2 1B）或云端（Google Gemini），最后估算该回答相对于"全部走云端"基线的资源足迹。

如果本地模型缺失或生成中途崩溃，请求会自动转移到云端并通知用户。没有任何路径会以空回复结束。

规则驱动而非训练分类器

作者没有训练分类器，而是使用一套可一次性读完的规则。这是刻意的选择：每个决策必须能用一句话解释，且必须在远低于1毫秒内完成，绝不能拖慢请求。

分类步骤通过模式匹配确定任务类型（问答、摘要、改写、翻译、代码、分析、长文写作、图像生成等）。每种类型有基础复杂度分数，再根据证据调整：输入长度（3000 token的文档比一句话难得多）、预期输出长度（"1500字""5段""一句话"）、以及"详细""逐步""简要"等线索词。

作者分享了两个构建教训。第一，关键词只能在指令中计数，不能在你粘贴的材料中计数：在把这封邮件改得礼貌些："现在把报告发给我。"中，"报告"这个词不应该把请求变成报告写作任务。第一个版本恰恰犯了这个错误。第二，当多条规则同时触发时，最复杂的任务获胜，这样错误会偏向云端——即昂贵方向而非错误答案方向。

七项检查按序执行

路由器的第二步是七项检查，第一个失败的检查将请求送往云端，并成为用户看到的原因：

检查项	送往云端的情况
任务类型	图像请求（本地文本模型无法绘图）
设备模式	设备被标记为低配
电池	低于20%且未插电
输入长度	提示词超过约1500 token
置信度	请求无法分类
复杂度	分数超过本地模型上限
内存	没有足够空闲RAM加载模型

复杂度上限取决于本地模型大小：约1B模型为0.35，约3B为0.5，约7B为0.6。更大的本地模型能把更多工作留在设备上。每个回答都有一个"为什么？"面板列出所有检查项，让用户看到具体是哪条规则把请求送走的。

Ollama是一个开源的本地大模型运行时，提供类似OpenAI的HTTP接口，能在消费级硬件上加载并推理Llama、Mistral、Gemma等开源权重模型。它负责模型下载、量化权重管理、内存分配和推理调度，使开发者不用自己拼装推理栈。GreenRoute选择Ollama作为本地执行层，因此“本地可用性”实际取决于两件事：Ollama是否已拉取到对应模型，以及当前设备是否有足够RAM把该模型完整载入。文章后续的“内存检查”“设备模式”等规则，本质上都是在判断Ollama能否稳定完成这次推理。

诚实的数学：本地AI真的更省吗？

"本地AI更环保"说起来容易，算对却很难。作者用了可追溯的公开数据来源。

云端一侧采用Google自己公布的数据（2025年8月）：向Gemini发送的中位数文本提示消耗0.24 Wh能量、0.26 mL水和0.03 g CO₂e。这涵盖了加速器、主机、为可靠性保留的空闲容量以及数据中心冷却。这比2023年流传的吓人估算低得多，作者以此为基线。

本地一侧并非免费。笔记本在生成时也在耗电。GreenRoute用额外功耗×实测生成时间估算，笔记本CPU默认25W，碳排放基于电网强度（458 gCO₂/kWh，2025年世界平均值，来自Ember经Our World in Data发布）。本地推理不使用数据中心冷却水。双方都不计入发电厂用水，保持对等比较。

节省 = 云端基线 − 本地成本。 如果高功耗机器上缓慢的本地回答成本超过云端，节省会显示为负数。作者希望工具能说出"这一次不划算"。

**Wh（瓦时）**是能量单位，1 Wh 表示以 1 瓦功率运行 1 小时所消耗的能量，常用于比较不同计算设备的单次任务能耗。**CO₂e（二氧化碳当量）**则把不同温室气体按全球变暖潜势折算成等量的二氧化碳，便于统一衡量碳足迹。本文的对比建立在“单次提示”尺度上：云端一侧使用Google公布的中位数（0.24 Wh、0.03 g CO₂e），本地一侧用额外功耗乘以实测生成时间。理解这两个单位有助于读懂后文的盈亏平衡点：当本地额外功耗达到约136W时，单位时间能耗乘以较长生成时间，恰好抵消云端基线，再往上就变成负节省。

实验结果：路由准确性与质量落差

测试设计

作者在运行任何测试之前，先编写了60个日常提示词并逐一标注它们应该在哪里运行——判断标准是"约1B的设备端模型能否给出足够好的答案，让我不需要再问一次？"其中38个标注为本地，22个标注为云端。然后在作者的笔记本（Intel Core i5-1135G7，4核，12GB RAM，无独立GPU）上运行真实系统，同时为了对比，将本地模型跑在所有提示词上，包括路由器送走的那些。一个更大的云端模型（Gemma 4 26B通过Gemini API）撰写参考回答，并对每个本地回答按1-5分评分。

路由表现

GreenRoute将60个提示词中的35个留在设备上（58%），与人工标注在57/60上一致。三个分歧全部偏向安全一侧：作者认为可以本地处理的问题（一个关于Python len()的问题、一行SQL查询、一封给房东的短邮件）被送往云端。没有任何标注为云端的提示词被留在本地。

有些云端决策的正确原因并不那么体面：一个证明题、一个旅行行程和一个系统设计问题没有匹配任何规则，是被"无法分类，保守处理"检查送走的，而非被识别为困难任务。

质量：最关键的发现

这是作者最关心的结果。在路由器保留在本地的35个提示词上，1B模型的回答被判定可接受30次（86%，平均4.4分/5分）。在送往云端的23个文本提示词上，同一个模型的回答只有4次可接受（17%，平均2.0分）。路由器划定的界线大致落在小模型能力下降的位置。

被放过的五个弱回答很有启发性：一个语法修正没改掉"Me and him"、两个翻译、一个日期提取丢了"June 3rd"、一个TL;DR改变了项目延期的原因。对1B模型来说，"简单"不等于"安全"。

资源足迹

与将全部60个提示词送往云端相比，GreenRoute的估算足迹在能量上低48%（7.5 vs 14.4 Wh），水低58%（6.5 vs 15.6 mL），CO₂e低19%（1.46 vs 1.80 g）。碳节省最小，因为Google的单次提示数据已反映其清洁能源采购，而作者的笔记本运行在平均电网上。如果每个弱本地回答都重新在云端问一遍，节省缩小到39%、50%和11%。

单次提示节省约0.1 Wh，数字很小，但在规模化时意义重大：同样的节省如果放在每天十亿次提示上，约为每天100 MWh。

能量结果高度依赖设备。本地路由在额外生成功耗约136W时停止节省能量。笔记本CPU（约25W）或Apple Silicon Mac（约10W）远低于此；而游戏台式机GPU推到150W则不然，会比全云端基线多用约6%的能量。

速度

在作者笔记本上，1B模型处理其负责的提示词中位耗时4.4秒（90分位12.8秒），约12 token/秒。用于参考回答的免费Gemma 4端点中位5.8秒，但快速商业模型更快：Gemini 2.5 Flash在作者的抽查中对短提示词约1-2秒。在笔记本CPU上，本地不是快选项。它的优势在能量、水、隐私和离线可用。

局限性

60个提示词是小样本，标注者只有作者一人。评判者本身是LLM，且同时撰写了参考回答。本地功耗是假设值（25W）而非实测，Google的数字是其自身流量和模型的中位数。所有提示词、标注、评判提示词和原始回答都在仓库中公开，任何人都可以检查或重跑。

**基准测试（benchmark）**在这里并非标准化的公开评测集，而是作者自建的60条日常提示词，并附有人工“应该本地/应该云端”的标注。它的价值在于可复现：所有提示词、标注、评判提示词和原始回答都公开在仓库中，任何人可以重跑或质疑。需要留意的是，这类小样本基准的结论带有较强条件性——设备型号、模型版本、甚至当天电网碳强度都会影响结果。因此文中“48%能量节省”等数字应理解为该配置下的估算，而非普遍定律。

下一步改进方向

作者认为决策本身应保持现状：少量廉价规则，运行在1毫秒以内，能用一句话解释。工作重点是在不增加重量的前提下让规则更准。

按任务类型设定上限。 目前同一模型大小的所有任务共享一个复杂度上限。基准测试显示1B模型在事实和改写上可靠，但在翻译和提取上不稳。按任务类型设置上限表仍然是查表操作，能拦住几个被放过的弱回答。

从反馈中调整上限。 本地回答上的"踩"按钮加上基准测试的评判分数，足以随时间微调每个任务的上限。这是每个任务类型的运行计数，不是模型训练。

对本地回答做廉价检查。 有些失败只在输出中显现：回答远短于要求、重复自己、或遗漏请求的一部分。对回答的简单检查（长度对比请求、提示词关键词是否出现）可以标记可疑的本地回答并静默重试云端。路由决策保持廉价，只有可疑情况才为此付出第二次调用。

修复已知遗漏。 三次路由失误都是短的、无害的请求：一个Python函数问题、一行SQL和一条短消息。一条"短代码问题"规则和一条"短消息"规则就能覆盖它们。

仅在规则不再可扩展时才引入小型学习评分器。 如果规则列表变得难以维护，对规则已计算的信号（任务关键词、输入长度、请求长度、细节线索）做逻辑回归，会用拟合权重替代手工权重。它仍然是微秒级运行的加权求和，权重仍能解释每个决策。

值得思考的问题

代码已在GitHub开源（ironman2cool/greenroute），支持Windows、macOS和Linux，只需一个免费Gemini密钥，Ollama是可选的。基准测试、提示词、评判提示词和所有结果都在仓库中。

如果你的应用默认将每个请求送往云端，值得问一句：其中有多少真的需要离开设备？