在浏览器层面实现本地 AI 推理是近年来前端工程领域最具变革性的技术演进之一。Chrome 浏览器通过内置 Gemini Nano 模型，将大语言模型的能力直接带入用户的设备环境，这一实现涉及复杂的存储管理、动态资源加载与跨硬件适配机制。本文从工程视角剖析 Chrome 本地 AI 模型的后台实现架构，聚焦存储布局、加载管线与推理运行时的核心设计。
模型存储位置与磁盘布局
Chrome 并未将 Gemini Nano 模型放置在系统级共享目录中，而是将其纳入 Chrome 用户数据目录进行管理。这种设计遵循浏览器插件与扩展的资源管理模式，使模型的生命周期与用户 profile 紧密绑定。具体而言，模型文件存储在用户本地的 Chrome 数据目录内，路径类似于 ~/.config/google-chrome/Default/ModelCache/ 或 Windows 下的 %LOCALAPPDATA%\Google\Chrome\User Data\Default\ModelCache\。这种布局的优势在于：模型随用户 profile 迁移、可以通过浏览器内置的 chrome://on-device-internals 页面直接查看模型状态与版本信息，且在多账户环境下实现资源隔离。
值得注意的是，Chrome 针对不同硬件配置会下载不同规模的模型变体。设备 GPU 性能较强时，浏览器会选择下载 4B 参数版本的 Gemini Nano 以获得更强的推理能力；若设备图形性能有限，则退而求其次下载 2B 参数的轻量版本。这一选择过程发生在首次调用内置 AI API 时，Chrome 通过运行一段代表性着色器基准测试来评估设备 GPU 实际算力，据此决定下载哪种模型变体。若设备完全不满足 GPU 推理的硬件要求，Chrome 会在满足静态条件的前提下回退到 CPU 推理模式，此时模型仍会被下载但推理路径完全不同。
存储管理方面，Chrome 实现了相当激进的空间回收策略。当设备可用磁盘空间低于特定阈值时，浏览器会自动删除已下载的 Gemini Nano 模型以释放空间。此外，企业策略禁用该功能、用户超过 30 天未满足使用条件（如未调用相关 API）也会触发模型清理。清理过程可能在会话中途发生，这意味着开发者不能假设模型在整个会话期间始终可用。
动态加载管线与生命周期
Chrome 本地 AI 模型的加载采用按需触发机制，而非浏览器启动时预加载。首次调用任何依赖 Gemini Nano 的内置 API（例如 Summarizer.create()、Writer.create() 或 Translator.create()）时，Chrome 才会启动模型下载流程。这种惰性加载策略有效避免了浏览器安装包体积膨胀，同时也确保下载的模型版本与目标硬件精确匹配。
下载过程被设计为具备弹性恢复能力：网络中断时，下载会暂停并在恢复连接后从断点继续；触发下载的标签页被关闭后，下载继续在后台进行；浏览器完全退出后，下次启动时会在 30 天内自动恢复未完成的下载。这些细节体现了 Chrome 在资源调度层面的工程成熟度。
部分 API（如 Proofreader API）依赖 LoRA（Low-Rank Adaptation）权重来适配基础模型以执行特定任务。LoRA 权重会与基础模型一起下载，但 Chrome 不会主动预下载其他 API 的 LoRA 权重，这种按需策略平衡了功能完整性与存储成本。模型更新采用热切换机制：Chrome 在后台下载新版本模型，下载完成后立即生效，后续任何新的 AI API 调用都会使用新模型。更新过程是全量替换而非增量 delta 升级，这是因为模型权重版本间差异可能较大，计算和应用 delta 的开销反而更高。
推理运行时：WebGPU 与 WebNN 的协同
Chrome 本地 AI 推理的核心 runtime 建立在 WebGPU 与 WebNN 两层抽象之上。WebGPU 作为底层计算骨架，提供接近原生性能的着色器计算能力，专门针对神经网络算子进行了优化。WebNN 则是更高层的神经网络的 API 抽象，它屏蔽了底层硬件差异，使开发者能够以统一接口调度模型推理，而无需关心底层是 DirectML、Vulkan 还是 Metal 后端。
推理工作流的典型模式包含四个阶段：初始化阶段创建 WebNN 上下文并绑定推理后端；加载阶段将模型权重从磁盘读取到内存并构建计算图；执行阶段接收输入张量，经过模型前向传播后返回输出；优化阶段通过 warmup 运行评估设备实际延迟，为后续请求进行性能调优。Chrome 特别强调，开发者使用内置 AI API 时无需关心后端切换细节，API 会在 GPU 可用时自动使用 GPU 加速，在仅 CPU 环境下自动回退到 CPU 推理路径。
从 Chrome 127 版本开始，CPU 推理支持得到显著扩展，使没有独立显卡的设备也能运行本地模型。CPU 路径的实现借助了 WebAssembly 优化与 SIMD 指令集加速，虽然延迟高于 GPU 版本，但确保了更广泛的设备兼容性。开发者在设计产品时需要考虑这种运行时波动，不能假设每次请求的响应延迟都保持恒定。
工程实践要点
基于上述架构分析，开发者应关注以下工程实践要点。首先，模型可能被随时删除，代码层面应妥善处理 availability() 返回不可用状态的情况，并在 UI 上给予用户明确反馈。其次，首次调用 *.create() 会触发下载，应向用户展示进度指示而非假设即时可用。第三，由于模型更新可能在上次请求完成后立即生效，开发者不应缓存模型版本相关信息。第四，针对 CPU 与 GPU 设备的不同延迟特征，可以考虑在客户端进行简单的设备能力检测并向用户说明预期性能。
Chrome 的本地 AI 实现体现了现代浏览器作为应用运行时的演进方向 —— 从单纯的文档渲染引擎逐步演化为具备强大本地计算能力的综合性平台。理解这一底层架构，有助于开发者在构建基于浏览器的 AI 应用时做出更合理的工程决策。
资料来源：Google Chrome 开发者文档《Understand built-in model management in Chrome》