真正的权衡
本地推理通常被框定为延迟优化。但不止于此。当模型在设备上运行时,输入永远不会离开设备。这是一个数据出境决策,涉及隐私、合规和离线行为后果,并且恰好也减少了往返时间。
这种权衡是结构性的,而非增量性的。
本地推理换来:
- 数据留在设备边界内;
- 无网络运行,这对现场工具、车辆、临床环境以及任何在地下室使用的东西都很重要;
- 硬件付费后,每次请求成本可预测;
- 不依赖远程端点的可用性或速率限制。
本地推理付出:
- 能力:更小的参数量、激进的量化和有限的上下文窗口降低了推理深度、工具使用可靠性和长文档处理能力;
- 内存和热预算,这限制了哪些模型可以与应用程序其余部分同时运行;
- 第二个推理栈需要评估、版本管理和发布;
- 迭代更慢,因为更新设备上的模型是分发问题,不是部署命令。
远程推理则完全相反。它换来能力——更大的模型、更长的上下文、更强的工具编排——代价是数据跨越产品无法控制的边界,加上对连接性和第三方正常运行时间的硬依赖。
大多数有用的系统两者都需要。因此工程问题不是“本地还是远程”,而是“边界在哪里,以及什么决定给定请求落在哪一侧”。

划定边界
常见的错误是按模型置信度路由:本地运行,如果本地模型不确定,就升级。这很诱人,因为容易插桩,但它是错的,原因有二。第一,小型量化模型的置信度分数校准很差,因此升级触发器会不可预测地触发。第二,更重要的是,它路由的变量错了。载荷是否可以离开设备是数据的属性,而不是问题难度的属性。
改为按数据类别路由。明确定义类别,并为每个类别分配允许的执行位置:
class examples locus
--------------- -------------------------------- ------------------
regulated-pii identifiers, health notes local only
device-private raw sensor frames, local files local only
user-content drafts, transcripts, messages local default,
remote on consent
derived embeddings, redacted summaries remote allowed
public docs, reference material remote preferred
分类步骤在推理之前对输入运行,尽可能确定:模式检查、字段级标签、来源溯源。如果分类需要模型,使用一个小型本地分类器,其唯一工作是输出类别标签——而不是回答用户。
一个有用的模式是:在载荷私密的情况下,将推理保留在本地,将工具调用放在远程。本地模型决定做什么以及用什么参数;远程调用只携带最小参数集,绝不携带完整上下文。日历查询需要日期范围,而不是产生它的对话。检索调用需要查询字符串和命名空间,而不是用户的草稿。这为受益于远程服务的部分保留了其能力——新鲜数据、大型索引、繁重计算——同时私密材料留在设备上。
这就是诚实的权衡所在。将推理与工具调用分离,代价是远程模型无法看到完整上下文,而这正是远程模型擅长模糊、多步任务的原因。你是在用一些答案质量换取更小的出境面。这种权衡应该按类别有意识地做出并记录。
将降级运行设计为一等状态,而不是错误路径。
ent:

- 哪些请求在本地以降低的质量服务;
- 哪些请求排队并在连接恢复时重放,以及重放如何与幂等性交互;
- 哪些请求被直接拒绝,并附上说明原因的消息;
- UI 传达什么,以便用户能区分降级输出和完整输出。
一个在离线时静默产生更差答案而不发出信号的系统,比一个明确表示当前无法做某事的系统更难信任。
衡量拆分
边界存在后,需要插桩。三项测量承担大部分重量。
第一,本地服务比例:完全在设备上服务的请求份额,按数据类别细分。单一聚合数字掩盖了你关心的事情,因为由琐碎请求驱动的高本地比例并不能说明敏感类别是否真的留在本地。按类别跟踪,并跨模型和应用版本跟踪,因为提示变化可能改变路由。
第二,每个类别的质量差异。对于每个类别,保留一个小型评估集,并针对本地和远程路径分别运行。差异告诉你边界在答案质量上的代价。如果某个类别的差异可以忽略,本地路径可以扩大。如果差异很大,你就有了当前拆分的文档化理由——以及针对性改进而非全面升级的候选。
第三,端到端测量的往返延迟,包括上下文的序列化。这是本地与远程比较最常出错的地方。远程调用不仅仅是网络时间;它是提示组装、分词、序列化、传输、端点排队、预填充、解码和反序列化。本地调用有自己的开销:模型加载、内存压力以及与应用程序其余部分竞争的成本。从同一起点测量两者——输入可用的那一刻——否则比较毫无意义。
然后注意静默升级。这是一种失败模式,本地回退在某些条件下将完整提示转发到远程端点。它通常通过以下几种机制之一出现:重试包装器重新发送原始载荷而不是缩减后的载荷;日志或追踪路径将原始输入发送到可观测性后端;工具调用适配器因为远程 API 期望消息列表而将整个对话作为上下文传递;或者功能标志将某个类别从本地翻转为远程,而没有相应的出境策略变更。
防御措施是使出境显式且可审计。每个出站载荷应由一个知道数据类别的单一组件构建,并且只能发出该类别允许的字段。在测试中断言:给定 regulated-pii 输入,出站载荷必须不包含禁止集合中的任何字段。记录离开的类别和字段名,而不是值。如果策略在一个瓶颈点而非每个调用点执行,静默升级就变成测试失败而不是生产事故。
实用总结:按敏感性对输入分类,基于该分类路由,将私密载荷留在设备上,同时为需要远程能力的部分借用远程能力,按类别定义离线行为,并对拆分进行插桩,使本地比例、质量差异和出境面都可见。延迟是用户注意到的收益。数据出境才是决定系统是否可部署的关键。
