本地优先的推理，正在重写桌面端工具的整层栈

上一篇关于"端上"的延伸。过去一年里，新出现的桌面 AI 工具的架构形态明显变了，值得在不点名具体产品的前提下记一笔。

一年前，"AI 桌面工具"的主流套路是一个薄薄的原生壳子，跟一个远端推理端点说话。壳子负责 UI，所有有意思的事都在服务器上发生。本地的二进制其实是个带操作系统集成的聊天客户端。

现在不一样了。壳子还在，但壳子底下多了一个不轻量的本地运行时 — 模型加载器、量化感知的执行引擎、几条端到端跑在设备上的小流水线。远端端点也还在，但它从"工作发生的地方"被降级成了"本地路径不够时去的地方"。从默认变成了可选 fallback。

这一重排同时影响产品怎么做和怎么想。本地运行时带来新的依赖面：模型文件、权重、有时还有加速器专属的算子内核，都得分发、更新、版本管理。桌面 AI 工具的打包故事比以前重 — 首次下载更大、更新机制要处理不小的二进制文件、安装占用要交代。

另一面，运维故事轻多了。本地优先做默认的工具，不需要把推理服务器集群随用户数同步扩。用量爆发耗的是用户电池，不是运营方的云账单。对小团队来说这是结构性优势。

更有意思的影响在产品表面。本地推理重塑了"什么样的交互甚至可以做"。每敲一个键要等 600ms 才回的拼写浮层不是真产品；本地的 30ms 响应版本是。每句话停下来"想一下"的语音输入笨拙；和说话同步流出的语音输入是另一种东西。最近从"印象深刻"过渡到"用着舒服"的桌面 AI 工具有一个共同特征：热路径短、在本地、同步。

这里关于工具设计的教训不太能写成单条铁律：你选的架构对你能构建的交互的约束，比通常承认的要强。云优先的设计会一直推你往异步请求-响应的方向走，因为那是它的传输层奖励的方式。本地优先的设计会推你往连续的、同步的交互走，因为那是它的传输层让其变便宜的方式。表面看起来相似，但是不同的产品。

我们不主张哪一种永远更好。我们想记下的是：形变了；这个变化对用户基本不可见，但对做工具的人基本可见；2026 年在这个领域做东西的人，选架构那一刻，已经在隐式地选边站。