本地 AI 的连接与调度

三句话读懂

发现：本地算力要像今天的打印机一样，插上电就能被找到，而不是让人手填 IP 和接口。

判断：每一次请求都要先回答一个问题——它能不能离开本地。

调度：在隐私约束之内，把合适的任务交给合适的模型和机器。

给算力装一个大喇叭

痛点

从云端切到本地，得打开配置文件，填 Base URL，再配置模型名称和接口格式。好不容易连上，换个网络环境又得重新改一遍。算力是有了，想连上还得费半天功夫。

做法

先给两台机器装上「大喇叭」。接上网络，它们就会向局域网大喊一声：我是 AI 节点，地址在哪，支持什么，应该怎么调用。

这样一来，同一个网络里的其他设备就能直接获取到完整配置，不需要用户一个字一个字填进去。

技术底座

建立在 mDNS、DNS‑SD 这类局域网发现技术之上，设备不用提前知道 IP 地址，也能自动找到同一网络里的服务。
约定了一种叫 LocalAI 的服务声明，用来提供接口位置、模型信息和鉴权要求：服务端负责发布，客户端负责接收和调用。

一个类比

小时候用打印机，得先连网线、再配置 IP，最后回电脑上装好驱动才能开始打印。但现在的打印机只要插上电、连好网，就能在电脑自带的打印功能里看到，点一下就能用。

我们做的，就是把「发现打印机」拓展成「发现 AI」。电视投屏、本地文件分享，甚至智能家居，用的都是这套逻辑：服务先告诉别人自己是谁、能做什么，客户端再决定要不要使用。

落地

在一个号称「一切皆插件」的插件平台上写了个发现插件，负责持续获取当前网络里的 AI 服务，每隔几秒扫一下。发现可用节点后，它会弹出提醒，问你要不要切换。

点一下，插件就把这个本地 AI 注册进去，原本找 IP、填接口、设置模型的过程全都被接管了，再发请求，已经是在调用本地模型。

还差一步

这个实验版本只解决了自动发现。想真正进入生产使用，还得加上节点身份认证、签名等安全机制。

这个请求能不能离开本地

第二个问题

本地推理不花钱、保护隐私，但算力毕竟有限。尤其是多个 Agent 一起跑，排队都得等半天。

可并不是所有请求都必须在本地处理：分析内部项目，和解释一个公开的编程概念，对隐私的要求显然不一样。前者不能因为排队太久就直接上传，后者也没必要占着本地资源一起等。

于是又写了一个隐私路由插件，它只回答一个问题：这个请求能不能离开本地？

两步判断

先用正则规则检查已知格式的敏感信息，例如身份证片段、手机号，命中就留在本地。
没有命中，再交给本地的分类模型，结合语义和上下文判断它属于可以公开处理的 public，还是需要留在本地的 private。

两个例子

问「HTTP/3 协议有啥好」，它会直接扔给云端接口，效率拉满。

让它查看未公开的代码，插件会识别出接下来是要获取一个未发布的本地项目或文件内容，属于私有且并未发布的源代码，于是把这个请求摁在本地。

这个判断也不止针对当前这一句话。再问一句「有啥能优化的」，虽然字面上没有任何敏感信息，它仍然能根据前文知道，你讨论的是刚才那个私有仓库，不会突然把任务切到云端。

关键陷阱

发给模型的可不只是用户刚输入的那句话。请求里还会包含系统提示词、工具定义、工具执行结果，以及整段历史对话。

也就是说，即使后来换了一个公开话题，前面读过的私有代码也可能仍然躺在请求上下文里。只检查最新的提示词，再把整包内容原样发出去，隐私边界照样会被绕过。

所以

路由插件不会因为当前请求被标记为 public，就给整份请求直接放行。而是重新构建一份新的请求参数，只包含明确批准的 public 信息，所有打了隐私标签的对话、工具调用等信息都会被剔除，相应的处理结果也能在对话界面里看到。

本地小模型，还够用吗

能力对标

一个本地小模型的评分是 1436，而 GPT‑4.5 preview 是 1445，GPT‑4o 是 1443。

GPT‑4o 在大模型军备竞赛下已经不够看了，但当年刚发布的时候还是很惊艳。现在一个本地模型已经能对标它，其实还是很夸张的。

这意味着本地模型值得被放进真实工作流里测试，而不只是作为一个「隐私更好但能力几乎为零」的备用选项。

变强的不只是模型

同一个模型放在同一块硬件上，推理引擎也能通过更好的计算内核和内存管理提高运行效率。比如更有效地管理 KV cache，减少内存浪费，为更多请求同时运行腾出空间。

英伟达提到：新版 llama.cpp 在 RTX 5090 上的吞吐最高能达到之前的 1.9 倍。
vLLM 在双 DGX Spark 配置上的性能，最高能达到原来的 1.4 倍。

也就是说，就算当钉子户一直不换硬件，本地也能随着软件栈升级持续改善使用体验。

把合适的事，交给合适的模型

为什么需要调度

用户看起来只是提了一个需求，Agent 的背后却得先规划，再读文件、生成代码、运行测试，发现问题后继续修改。一项任务往往对应多轮模型调用，而这些步骤的难度相差悬殊。

既有需要深入推理的步骤，也有范围明确、可以单独完成的小任务——这就给进一步的调度留下了空间。

怎么分

在满足隐私要求的前提下，把经过验证、适合小模型的工作优先交给本地。
遇到本地能力不足的公开任务，再调用更强的云端模型。
不能一看到 public 就永远上云，也不能一看到本地模型就把所有工作都塞进去。

尤其是当 Agent 连续跑几个小时、几天，甚至希望它 7×24 小时工作的时候，每一步调用什么模型，都会影响整条工作流的成本和体验。

能上云的分走了，剩下的还在排队

新的瓶颈

能上云的请求已经分出去了，必须留在本地的任务却越来越多，最后全挤在同一台机器上排队。

但以后能承担本地推理的，可能还不只是专门买回来的 DGX Spark。

算力会到处都是

英伟达发布了一款面向 Windows 的小型 AI 设备，下个月就上市。它把大容量统一内存架构直接塞进笔记本和小型桌面电脑，最高提供 1 PFLOPS 算力和 128GB 统一内存。

也就是说，以后你日常的办公电脑本身，就可以是一台能跑大模型和 Agent 的本地节点。

于是场景变得很有意思：办公室里可能有两台 DGX Spark，旁边有一台 RTX 工作站，同事的笔记本也正好闲着。明明整个局域网里到处都是算力，某台机器却排着长队。总不能每次 Agent 发请求之前，还得先挨个看看哪台电脑最闲。

算力池

Personal AI Router（简称 PAIR）就在尝试解决这个问题。它把局域网内兼容的设备组织起来，形成算力池，让应用通过一个统一入口使用多台机器的推理能力。支持的设备包括 DGX Spark，甚至搭载 M4 和更新芯片的 Mac。

关键区别：它不是把几台机器的显存拼成一张超级显卡。这里的每台设备仍然独立运行，每一次推理请求都会交给一台符合条件的节点，从头执行到尾。

但如果一个 Agent 同时拆出了好几个任务，或者几个 Agent 一起工作，就可以把这些请求分散到不同节点上，不需要堵在同一块 GPU 后面。

官方演示

同一套五个 sub‑agent 的工作流，只用一台 RTX 笔记本要跑 18 分钟；加上一台 DGX Spark 和一台 RTX 5090，三台机器组成集群以后，缩短到了 8 分 48 秒。

可惜的是，设想中那种手机、平板、手表都能连上来一起分担算力的效果，现在还没法实现。而且多几台机器也只能解决排队问题，没办法做到模型能力 1+1=2。

另一种分工：云端只收筛选后的上下文

思路

一个知名 AI 搜索引擎的产品尝试了另一种分工方式：把模型任务编排和工具执行默认放在本地，并针对小模型的能力特点调整 harness。

遇到困难的时候，本地模型可以向更强的云端模型请求建议。

调用云端之前

harness 会挑选上下文，用分类器标记敏感信息，并展示哪些内容将发送到云端；是否启用这种调用、采用手动还是自动审批，都由用户控制。
它还能对上下文做局部打码：一整段话里面有个手机号，把它替换成「手机号」三个字，这段内容就安全了，又不影响 AI 分析。

总之，云端只能接受筛选后的上下文，返回的也只有文字建议，不能直接访问本地文件和工具，实际操作仍然由本地系统执行。

这就比「整条请求留在本地」或者「整条请求上云」多了一种选择：把能够获准分享的问题交给云端请教，把资料、工具、权限和执行过程继续留在本地。相当于隐私路由的 Pro Max 版。

真正要补齐的，是中间那一层

折腾到这里，越来越觉得本地 AI 接下来要补齐的，可能不只是模型能力。模型与工作流之间的这一层连接和管理，也非常重要。

先找到可以使用的可信节点；
再判断任务允许携带哪些信息；
最后在这些约束之内，自动选择合适的模型和机器。

总不能每换一个地方，就重新改一遍 API endpoint、provider 和模型配置。

就像今天没人需要记住打印机的 IP 一样，未来我们可能也不用关心一次请求到底跑在哪张显卡上，只需要知道自己的隐私数据是安全的就行了。

—— 关于本地 AI 的一点想象

留一个问题给你：分布式算力会成为下一代 AI 基础设施的一部分，还是只属于少数本地 AI 玩家的乐趣？

也许以后走进一家咖啡馆，我们除了连上网络，还会顺口问一句：你们这儿有什么模型能用？

本地 AI 的连接与调度 · 笔记