浏览器原生 AI 是一项针对具体功能的决策：你的团队尚未权衡的四个维度

过去，那种“在标签页中运行模型”的故事很容易被忽视：小模型、新奇的演示、在笔记本电脑风扇狂转前只能运行 30 秒的 Whisper 语音转录。现在，那个时代已经结束了。量化技术得到了改进，WebGPU 已经在所有主流浏览器中发布，设备端缓存获得了持久配额，现在 4-bit 3B 模型在价值 500 美元的笔记本电脑上输出 token 的速度，已经快到让用户感到“流畅”。“这是否应该在服务端运行？”不再是一个默认选项 —— 这是一个关键的架构决策，如果你的产品团队每次都直接接受平台团队的第一个方案，那么他们就在无意中做出了这个决定。

随之而来的错误比演示效果变差更严重。团队为整个产品选择一种后端 —— 通常是服务端推理，有时是浏览器推理 —— 然后在每个不匹配的功能上付出错误的代价。对隐私敏感的功能输给了对延迟敏感的功能，因为架构强制给出了单一答案。或者更糟，团队因为演示时的惊艳效果选择了浏览器原生方案，然后发布了一个“机群级”的体验，导致长尾设备群体中 30% 的用户获得了一个性能降级的产品，而仪表盘却无法察觉。

浏览器原生 AI 并不是更快的 TensorFlow.js。它是一个具有不同 SRE 逻辑、不同成本模型以及四个无法坍缩为单一答案的权衡维度的不同运行时。将其视为“API 调用的廉价版本”是 2026 年最典型的架构错误。

四个维度并非单一光谱

舆论总是不断地将其简化为一个维度 —— 通常是“延迟”或“隐私” —— 其结果是引发了一场针对每个产品的宗教战争，却忽略了决策的实际结构。这里有四个维度，一个功能可以处于这些维度的任何组合位置。它们之间并不相关。

延迟下限 vs 冷启动成本。 浏览器推理消除了网络往返，这大约是 50–200ms 的延迟，你在服务端无法优化掉。对于每一个交互都需要感觉是即时的功能 —— 自动补全、实时字幕、页内搜索 —— 延迟下限胜出。但同样的架构带来了服务端所没有的冷启动成本：用户首次访问时，在任何功能运行之前，都需要支付 300MB–2GB 的模型下载费用。闲时预取和持久缓存有助于第二次访问，但首次访问的体验在性质上比调用服务端差。每个会话仅使用一次的功能支付了冷启动税却没有任何收益。而持续使用的功能则可以在几秒钟内摊销这一成本。

默认隐私 vs 缺乏调试日志。 浏览器原生推理意味着用户的 Prompt 和输入永远不会离开设备。对于受监管的数据、敏感文件或任何涵盖在 GDPR 数据最小化原则下的内容，这不只是营销话术 —— 这是从架构上减少了合规覆盖面。但这是一把双刃剑。你依赖于调试的服务端可观测性技术栈 —— 请求追踪、Prompt 日志、用于评估的输出样本 —— 在设备上默认是不存在的。你无法调试你看不见的问题。如果团队发布了浏览器原生推理，并假设现有的日志流水线仍能工作，那么他们发布的就是一个黑盒。

设备碎片化税 vs 服务端同质化。 你的服务端运行在你配置的同质化 GPU 集群上。而用户的设备群体横跨三个操作系统版本、四代芯片、集成和独立 GPU 以及两三个内存层级。考虑到量化容忍度、散热余量和可用 VRAM，每种组合都有不同的“最佳模型”。WebGPU 通过 GPUSupportedLimits 暴露了适配器限制，但为了防止指纹识别，这些限制是按层级分桶的，因此信号非常粗糙。为所有人发布单一模型变体的团队，要么是在旗舰机上过度消耗电池，要么是在长尾设备上发布降级体验。而为每个层级发布不同变体的团队，现在已经进入了“模型 CDN”业务领域。

模型尺寸上限 vs 全能前沿能力。 目前浏览器驻留模型的上限在 3B–7B 范围，采用 4-bit 量化。这足以完成分类、提取、短文档摘要、结构化输出以及针对小上下文的聊天。但这不足以前沿推理、长文本合成，或任何 3B 模型与 200B 模型之间存在质的性能差异的功能。一个价值取决于前沿能力的功能，绝对无法在浏览器中运行。而一个价值存在于小模型领域的功能则可以运行 —— 并且单次任务的成本降至零。

这些维度无法分解为单一答案，因为没有哪个单一功能在所有四个维度上都处于相同位置。实时字幕功能对延迟下限要求高，对冷启动容忍度低，隐私需求中等，能力需求低 —— 浏览器原生胜出。法律文件摘要功能对延迟需求中等，对隐私需求高，对能力需求高 —— 混合架构是唯一诚实的答案。针对小型产品手册的聊天功能对延迟、隐私和能力的需求都很低 —— 服务端即可，浏览器原生版本则属于过度设计。为这三种功能选择同一种架构的团队，肯定在某些地方付出了错误的代价。

必须落地的工程规范

决策规则并非“浏览器原生更好”或“服务器端更安全”。而是针对每个功能的文档记录，明确四轴权衡（four-axis trade-off），并指定驱动选择的“主导轴”。

每个功能的决策记录应包含：哪个轴占主导地位、二阶约束是什么、哪些轴被视为成本，以及重新评估触发器。触发器至关重要，因为成本曲线一直在变动——Transformers.js v4 在 2026 年初放弃了 C++ 运行时，速度比 v3 提升了 3–10 倍；Chrome 增加了 FP16 着色器和 DP4a 打包整数点积（DP4a packed integer dot products）；能在中端笔记本电脑上流畅运行的模型大小在一年内从 1B 增长到了 3B。第一季度做出的决策到第三季度可能就是错的。如果没有重新评估触发器，你在 WebGPU 尚处萌芽期时锁定的架构，到了 WebGPU 成熟期仍将是你交付的架构，无论之前的权衡是否依然成立。

能力检测（Capability detection）必须是一个真正的子系统，而不仅仅是页面加载时的三行特性检测代码。行之有效的模式是：探测 WebGPU 适配器，读取相关的限制参数，将设备划分为不同的等级（通常是三个或四个桶——旗舰、中端、低端、无 GPU），并路由到该等级实际能运行的模型变体。回退链（Fallback chain）至关重要：WebGPU → WebGL → WASM → 服务器。每一步都是用能力换取兼容性，且每次转换都需要进行评估，以证明该等级上的变体对于其服务的功能没有出现回归（non-regressing）。如果团队只发布一个变体并简单粗暴地回退到服务器推理，那么在中端设备上会损失质量，在低端设备上则会浪费带宽。

缓存管理不是“存到 IndexedDB 然后祈祷”。浏览器在存储压力下会驱逐缓存数据，对于非持久化存储，驱逐策略是 LRU（最近最少使用）。一个 1.5GB 的模型在与用户的照片缓存竞争时注定会失败。工程规范是明确请求持久化存储（persistent storage），将模型权重结构化为可分片缓存的 Blob（这样部分驱逐就不会导致整个下载失效），在重用前通过校验和（checksums）验证分片，并将缓存命中率作为一级遥测指标（telemetry metric）进行追踪。缓存缺失率即冷启动率，也就是跳出率；不测量这一指标的团队，永远不会知道为什么他们的浏览器原生功能在指标上表现不佳。

服务器端回退（Server-side fallback）不是可选的。它是捕获设备端路径产生的所有失败模式的安全网——包括不支持的硬件、超出配额、模型加载超时、推理中途运行时崩溃、热节流（thermal throttle）。回退契约必须透明：无论在哪里运行，你得到答案应该是相同的，且团队会收到遥测信号，说明回退触发的频率以及在哪些设备类别上触发。5% 的回退率是健康的。30% 的回退率意味着设备端路径调优不力，团队在用户首次访问时支付了冷启动成本，却在第二次访问时没能享受到延迟底线的收益。

没人提及的失败模式

单后端失败模式是最常见的，但更隐蔽的是在缺乏所需的 SRE 体系的情况下发布浏览器原生推理。

浏览器现在是一个真正的推理目标，这意味着它继承了真实的运维关注点：模型版本管理、遥测、崩溃报告、A/B 测试、渐进式发布。这些几乎都不是开箱即用的。模型版本管理不是 npm 包版本——它是用户缓存的权重 Blob 版本，如果用户没有被强制下载更新，该版本可能比部署的应用版本滞后数周。如果团队调高了模型版本并假设下次页面加载就会生效，那么他们发布的是一群运行着陈旧权重且配合新 Prompt 模板的用户，这是引发质量回归的导火索，且在支持工单出现之前这种回归是不可见的。

缺乏服务器的遥测是一个更难的问题。你所依赖的服务器端可观测性栈——Prompt 日志、输出样本、评估汇总、延迟直方图——是基于请求跨越你所控制的网络边界这一假设构建的。浏览器原生推理并不跨越这个边界。你可以将遥测信标（telemetry beacons）发回服务器，但 Prompt 和输出可能正是“默认隐私”原则禁止你记录的数据。工程规范是测量那些不涉及用户内容的事项：延迟分布、缓存命中率、服务的模型变体、回退率、错误类别、感知质量信号（用户是否重试、编辑、放弃）。这种遥测的形式与服务器端 Prompt 日志不同，消费它的评估流水线也是一套不同的流水线。

能够跨标签页存续的崩溃报告本身就是一个工程难题。WebGPU 设备丢失（device loss）时有发生——GPU 重置、标签页后台运行时间过长、操作系统回收显存（VRAM）——推理状态随之消失。恢复路径应该是：检测设备丢失、重新获取适配器、从缓存重新加载模型、重放处理中的请求，并将丢失记录为遥测事件。跳过这些步骤中的任何一步，都会给用户带来一个偶尔莫名失败的功能，这是 AI 功能最糟糕的用户体验（UX），因为这种失败看起来像是模型坏了，而实际上是运行时出了问题。

浏览器原生功能的 A/B 测试也比服务器端等效功能更难。分组分配（Cohort assignment）必须在模型加载之前发生，因为加载错误的变体会浪费用户的带宽和存储。评估必须跨越设备等级，因为在旗舰设备上胜出的功能可能会在长尾设备上失败，而分组级的平均值会掩盖这两种效应。发布节奏受限于缓存传播，而这并不受你控制。这些都不是障碍——它们是团队在发布前必须规划的工作项，未经规划就发布的团队注定会在生产环境中发现这些问题。

“混合”的真实含义

对大多数产品来说，诚实的答案是混合模式，而不是纯浏览器端或纯服务器端。但在那句话中，“混合”承担了太多意义，而廉价的版本只是将两个技术栈强行拼接在一起，没有任何共享协议。

真正有效的版本将浏览器视为路由决策中的一层，与服务端廉价模型和服务端前沿模型并列。路由器存在于产品代码中，而不是推理栈中，因为路由维度是一个产品问题——哪个维度在这个功能中占主导地位——而不是模型质量问题。各层之间的协议是一个归一化的输出模式 (schema)，因此消费端代码不会因为推理运行的位置而产生分支。评估集 (eval set) 涵盖了所有三条路径，因为即使其他路径正常，其中一层的退化也是真实的退化。

Chrome 内置的 AI API——由 Gemini Nano 支持的 Prompt API，以及用于摘要、翻译和写作辅助的特定任务 API——是值得提及的第四层。它们提供了一个由浏览器维护的强大模型，对你的应用来说没有下载成本，也没有模型版本管理的负担。它们也有局限性：支持的平台有限、模型尺寸有限、对提示词界面的控制有限。但对于适用的功能，它们将四维权衡简化为“免费层，直接用”。如果一个团队忽视这些 API，而为浏览器已经提供的任务自行构建 WebGPU 流水线，那么他们是在重复平台厂商已经完成的基础设施工作。

架构上的觉醒

浏览器正在成为一个真正的推理目标，这意味着它正在成为一个真正的生产环境，也就意味着它拥有自己的 SRE 体系。如果团队将其视为“性能更好的 TensorFlow.js”，那么发布的功能可能在开发阶段运行良好，但在全量发布时就会失败。而如果团队将其视为服务端推理栈的同等组件——具备能力检测、模型版本管理、尊重隐私的遥测技术、崩溃恢复、降级协议 (fallback contracts) 以及针对每个功能的决策记录——那么他们将能发布真正影响指标的浏览器原生功能。

2026 年产品团队面临的抉择不是是否采用浏览器原生 AI，而是是否在正确的功能上、以正确的纪律、按正确的重新评估节奏来采用它。四维权衡是使这一决策变得清晰的产物。没有将其记录下来的团队无论如何都在做决策，只是做得很糟糕。

带入你下一个规划周期的路线图问题很具体：你的产品中哪些功能的主导维度是由浏览器原生端比服务端更好地满足的，而你又将哪些维度作为成本接受？如果答案是“我们还没有对其进行拆解”，那么这就是你要做的工作。架构图不是交付物——针对每个功能的决策记录才是。