Chrome 浏览器从 126 版本开始正式集成 Gemini Nano 模型，标志着浏览器从单纯的内容渲染引擎向智能交互平台的转型。这一集成的核心并非简单的模型嵌入，而是一套经过大规模生产验证的推理框架 ——LiteRT-LM。作为 Google AI Edge 栈的核心组件，LiteRT-LM 负责在资源受限的边缘设备上完成千亿级参数模型的推理调度，其工程实现中蕴含的资源管理思想值得深入剖析。
Engine 与 Session 的双层抽象
LiteRT-LM 的架构设计围绕两个核心类展开：Engine 和 Session。这种划分并非人为的模块分割，而是对实际生产需求的精准映射。在多特征共存的浏览器环境中，内存占用与推理延迟始终是矛盾的两端。传统方案为每个 AI 特性独立部署完整模型，导致数十亿参数的模型在内存中复制多份，资源浪费严重。LiteRT-LM 通过共享底层资源、分离可变状态的方式，将这一矛盾转化为可工程化的问题。
Engine 在整个架构中扮演单例资源池的角色。它拥有并管理所有重量级的共享资源，包括基础语言模型、多模态编码器以及 tokenizer 等组件。Engine 负责根据运行时环境智能决定资源的加载与卸载策略。当系统内存紧张或电池电量不足时，Engine 可以主动释放部分非核心资源；当用户切换回需要 AI 能力的场景时，Engine 再按需重新加载。这种动态资源调度机制使得 Chrome 能够在数亿台不同配置的设备上稳定运行，而无需针对每种硬件配置进行单独优化。
Session 则代表每个独立的对话或任务上下文。与 Engine 的全局性不同，Session 是有状态的，它维护着自身的对话历史、当前上下文以及任务特定的配置。不同的浏览器功能可以创建各自的 Session 实例，例如标签页摘要功能与智能回复功能各自拥有独立的 Session，它们共享底层的 Engine 资源，却互不干扰。更重要的是，Session 可以附加轻量级的 LoRA 适配器，在不增加基础模型体积的前提下，针对特定任务进行行为微调。这种设计使得 Chrome 能够在有限的二进制体积内支持多种差异化 AI 能力。
上下文切换与状态持久化
当用户在浏览器中频繁切换不同的 AI 任务时，如何保证状态的一致性与切换的效率成为关键挑战。LiteRT-LM 借鉴了操作系统的进程调度思想，将每个 Session 的完整上下文 —— 包括 Transformer 的 KV-cache、LoRA 权重以及其他状态信息 —— 封装为可序列化单元。在任务切换时，系统执行类似进程上下文切换的操作：保存当前 Session 的完整状态到持久化存储，随后恢复目标 Session 的状态到内存中。
这种机制带来的直接好处是内存占用的可预测性。即使同时存在多个活跃的 AI 任务，内存中只需要保留当前前台任务的完整状态，其他任务的中间状态以压缩形式存储在磁盘上。对于内存通常在 4GB 到 8GB 之间的普通笔记本电脑而言，这一设计确保了浏览器在极端情况下也不会因为 AI 功能而崩溃或显著影响其他应用性能。
Session 克隆功能进一步优化了特定场景下的推理效率。在实际应用中，用户经常需要在某个对话分支上进行多轮探索式对话，此时克隆已有 Session 可以复用已经计算完成的 KV-cache 前缀，无需从头开始处理提示词。根据 Google 官方数据，Copy-on-Write 优化使得 Session 克隆耗时控制在 10 毫秒以内，这对于交互式应用而言几乎无感。
硬件加速与跨平台适配
Chrome 的内置 AI 需要面对极为碎片化的硬件环境。从搭载最新 NPU 的 Windows 笔记本，到仅有 CPU 的老旧 Chromebook，再到各种 ARM 架构的移动设备，每种配置都需要获得最优的推理性能。LiteRT-LM 通过分层抽象实现这一目标：底层依赖 LiteRT 运行时进行硬件抽象，上层提供统一的 C++ 接口供应用层调用。
在具体加速策略上，LiteRT-LM 支持三种后端的动态选择。当设备配备独立 GPU 或集成高性能 NPU 时，推理任务优先调度到专用加速器，通常能够获得 3 到 5 倍于纯 CPU 推理的吞吐提升。对于不具备独立 AI 加速单元的设备，系统会自动回退到高度优化的 CPU 实现，采用 NEON 指令集等 SIMD 加速技术。开发者在使用 LiteRT-LM 时，只需在 EngineSettings 中指定 Backend::AUTO，系统会自动探测并选择最优执行路径。
跨平台兼容性则通过抽象平台相关组件实现。文件描述符映射、内存映射文件（mmap）以及线程调度等与操作系统紧密相关的操作，均被封装在平台抽象层之后。LiteRT-LM 为 Linux、macOS、Windows、Android 以及 Raspberry Pi 等平台提供了原生实现，开发者无需关心底层差异即可获得一致的行为表现。
开发者可用的 API 层级
Chrome 为 Web 开发者提供了三个层级的 AI 能力接入方式。最顶层是任务导向的 Task API，包括 Summarizer API、Translator API、Writer API、Rewriter API 以及 Language Detector API。这些 API 设计简洁，开发者无需了解模型内部机制，只需调用对应接口即可完成特定任务。例如，使用 Summarizer API 只需三行代码即可实现页面内容的摘要生成，且无需关心模型的下载、更新与缓存管理。
中间层是 Prompt API，它允许开发者发送自由格式的提示词并获取结构化输出。这一层级的灵活性高于 Task API，但相应地需要开发者对提示工程有基本理解。Prompt API 目前主要面向 Chrome 扩展程序开发者，未来有望逐步开放给普通网页应用。
底层则是 LiteRT-LM 的 C++ 接口，面向需要深度定制的高级开发者。通过直接操作 Engine 与 Session 类，开发者可以实现完全自定义的推理流水线，包括多模型协作、条件分支推理以及实时结果流式输出等高级特性。Google 已在 GitHub 上开源了 LiteRT-LM 的预览版本，附带完整的 API 文档与示例代码。
值得注意的是，W3C WebML 工作组已经开始讨论将 Summarizer API、Writer API 等规范纳入浏览器标准，这意味着未来这些能力可能成为所有浏览器厂商的共同支持。Language Detector API 与 Translator API 已获得 Mozilla 的标准立场支持，标准化进程正在稳步推进。
工程实践中的关键参数
在生产环境中部署基于 LiteRT-LM 的 AI 功能时，有几个参数需要特别关注。首先是 max_concurrent_sessions，它控制单个 Engine 实例允许的最大 Session 数量。默认值通常设置为 4，但在内存充裕的高端设备上可以适度提高以支持更多并行任务。其次是 kv_cache_memory_limit，它决定了单个 Session 的 KV-cache 最大内存占用，设置过低会影响长文本处理能力，设置过高则可能与其他浏览器标签页竞争资源。
对于需要与服务器端模型协同的场景，Chrome 文档推荐采用混合架构：以本地 AI 处理对延迟敏感、隐私相关的请求，以云端模型处理需要大规模推理的复杂任务。这种架构在保证用户体验的同时，也控制了云端推理成本的边际增长。
资料来源：Google Developers Blog (2025-09-24), Chrome for Developers Built-in AI 文档。