Chrome端侧AI实战：Gemini Nano模型加载与多用户资料排查全记录

我原本以为Chrome内置的Gemini Nano只是厂商宣传里的一个概念，直到某天我顺手打开chrome://components，发现在"优化指南"那一栏里躺着一个体积接近1GB的本地模型组件，才意识到端侧AI是真的住进浏览器了。但真正让我头疼的不是怎么找到它，而是同一台电脑上，默认用户资料能正常调用模型，新建的多用户资料却始终报"模型不可用"。

这篇文章就完整记录这次实测：从设备体检报告逐项解读，到摸清模型在硬盘里的藏身位置，再到多用户资料场景下模型加载失败的完整排查链路。如果你也准备在Chrome里跑本地AI，或者正卡在"模型明明存在却加载不出来"这类问题上，这篇内容可以直接照着排查。

1. 端侧AI的入口扫描：先确认你的Chrome里真的装着Gemini Nano

1.1 版本与前置条件，这一步最容易卡人

端侧AI不是装个最新版Chrome就能自动获得的，它有两个硬门槛：通道和版本。我用的是Windows 11桌面版Chrome，实测下来必须是Dev或Canary通道的较新版本，Beta和Stable通道即便版本号到了，界面里也可能看不到相关入口，这是因为Google在按通道灰度推送底层模型组件。

如果你不确定自己的版本号，地址栏输入chrome://version，可以看到"官方版本"字段。我实测时用的是Canary通道，版本号来到了130以后，chrome://components里才出现了"Optimization Guide On Device Model"这一项。版本太老或通道不对，下面的步骤都可以先不用做，因为组件列表里压根不会出现模型这一栏。

另外要说明一点：这个功能在Windows、macOS和Linux上都有覆盖，但模型格式和下载路径各不相同。我这边基于Windows环境展开，macOS和Linux的目录结构会不一样，排查思路相通。

1.2 三个FLAG开关，少开一个模型都不干活

确认版本后，接下来要检查三个实验开关。地址栏依次输入以下地址，把对应选项改为Enabled并重启浏览器：

chrome://flags/#prompt-api-for-gemini-nano chrome://flags/#optimization-guide-on-device-model chrome://flags/#built-in-ai

这三个开关分别负责：暴露给网页的Prompt API接口、底层模型加载器、以及浏览器内置AI功能总闸。很多人只开了第一个就以为万事大吉，但底层加载器没打开，模型文件即使下载了也无法被加载进推理进程。

提示：如果你在一台公司电脑上操作，还要检查是否存在企业策略禁用项。在地址栏打开chrome://policy，查看OptimizationGuideEnabled这类策略是否被强制设成false。有些管理员会统一禁用端侧AI，这种情况改FLAG权重也没用。

1.3 用chrome://components确认模型已经落盘

做完前置准备，chrome://components页面里会多出几个组件，其中关键的一项就是优化指南模型组件。它的状态正常时显示为"已更新"，并且能看到一个体积数字。我首次下载时花了大概十几分钟，走的是Google官方的组件更新通道，不是从网页上下载，所以硬盘里出现这个文件时，我还愣了一下——它连安装包都省了。

这里有个容易误判的点：组件列表显示"已更新"不代表模型文件已经完整。我遇到过状态显示正常、但模型目录里只有一个几十MB的残留文件的情况，这通常是下载被中断导致的。后续我会在聊硬盘目录时给出准确的检查方法，这里先记住一点——单一状态字段不足以证明模型就绪。

2. "体检报告"逐项解读：设备支持检查背后的判定逻辑

2.1 官方体检报告在哪里看

确认模型组件存在后，下一步是确认这台设备的硬件能不能跑起来。Chrome为此提供了一个自检页面：地址栏访问chrome://ai-internals。这个页面的输出很像一份体检报告，把设备信息和模型状态结构化地列出来。我第一次看到时，最直观的感受是：Google终于把这种内部调试页做得像点样子了。

如果你打开这个页面是空白的，说明当前版本还没有暴露这个内部入口，也不要慌，可以直接在DevTools的控制台里跑一段脚本来做能力探测：

(async () => { if (typeof window.ai === 'undefined') { console.log('AI接口不存在'); return; } const canCreate = await window.ai.canCreateTextSession(); console.log('canCreateTextSession:', canCreate); })();

canCreateTextSession()连带返回三种状态：available（模型已就绪可直接创建会话）、downloadable（模型未下载但可以触发下载）、unavailable（当前环境不支持）。这其实是比体检报告更直接的可用性结论。

2.2 硬件判定：内存是硬指标，CPU指令集是隐形门槛

体检报告里最关键的硬件字段是RAM和CPU能力。Gemini Nano的端侧版本经过量化压缩，对内存的最低要求是8GB，但注意"最低"和"流畅"是两回事。我在一台16GB内存的机器上实测，模型加载后内存占用增加大约1.2GB；在8GB机器上，同样的模型加载完成后可用内存告急，浏览器本身都开始卡。所以我的建议是：开之前想想自己平时要同时开多少个标签，内存紧张的话端侧AI会让体验雪上加霜。

CPU方面有一个很容易被忽略的硬性要求：指令集支持。端侧推理依赖特定的向量指令来加速矩阵运算，老CPU如果不支持相关指令集，模型会直接拒绝加载而没有任何明确的报错，日志里也只留下一串含糊的解释。判断方法很简单，在chrome://gpu里看CPU信息一栏，或者直接在任务管理器里看CPU型号，近几年的主流酷睿和锐龙都问题不大，太老的平台要先有这个意识。

2.3 软件判定：OS版本与显卡驱动也会插一脚

体检报告排第二位的坑在系统层面。Windows系统版本过旧时，Chrome会认为设备不满足端侧AI的运行环境，即使硬件够格也不会给你可用的标志。我测试时把Windows 11保持在最新补丁级别，没有遇到问题，但遇到一个Windows 10旧版本机器，模型组件可以下载，canCreateTextSession()却一直返回unavailable。

显卡驱动是我额外补充的一个检查点：GPU用于模型推理时的矩阵运算加速，驱动版本过旧可能导致推理进程启动后立即崩溃。体检报告对GPU的描述通常很模糊，真正确认GPU相关问题时，要去看崩溃日志或者chrome://gpu里的警告项。别把体检报告当成唯一依据。

2.4 实测环境：一台16GB内存机器的体检记录

我这次排错的测试机配置如下：Windows 11 23H2（更新到最新补丁）、i7-12700、16GB DDR4、NVIDIA GTX 1660 Super、Chrome Canary 130。chrome://ai-internals上显示的体检结论是：Device符合、RAM通过、CPU Capability为1（支持必要指令集）、模型状态为Downloaded。整体结论就是四个字：硬件合格。

这份体检报告的意义在于：当你后面遇到模型加载问题时，可以一步一步确认自己是不是死在硬门槛上。多用户资料排查过程中，我反复回头对比体检报告的结论，就是为了排除"模型坏了"之外的变量。我在实际操作里的体会是，先把硬门槛全部确认一遍，再往下追软件层面的问题，效率最高。

3. 模型到底藏在硬盘哪个角落：存储位置与Modelling加载机制

3.1 顺着用户数据目录找到模型本体

Chrome的模型不是装进安装目录的，它跟着用户数据走。Windows上，用户数据默认位于：

C:\Users\<用户名>\AppData\Local\Google\Chrome\User Data\

在这个根目录下，模型组件被放在"Optimization Guide"相关的子目录里。我这边实际看到的结构大概是这样的：

User Data\ Optimization Guide\ OnDeviceModel\ model_...\ weights.bin model_manifest.json

weights.bin就是真正的模型权重文件，体积在900MB到1GB之间。model_manifest.json记录版本号、格式和校验信息。我见过的实测数据里，这个模型文件总共占用了约923MB磁盘空间——这就是标题里说的"硬盘里藏着Gemini Nano"的含义：它就是实实在在躺在你硬盘里的一组二进制文件。

检查步骤非常简单，直接看文件夹大小：

dir "C:\Users\<用户名>\AppData\Local\Google\Chrome\User Data\Optimization Guide" /s

如果这个目录的体积明显小于900MB，说明模型没有完整下载，这就能直接解释"模型显示已更新但加载不了"的矛盾现象。

3.2 Chrome什么时候下载模型，什么时候真正加载它

模型下载不是浏览器一启动就发生的，它遵循一套懒加载策略：当你第一次调用AI能力（或者体检页面触发检测）时，浏览器才判断"模型缺失、可以下载"，然后开始拉取组件。Chrome会通过组件更新服务在后台静默完成下载，下载完成后并不会立刻常驻内存，只有当真正需要推理时，模型才会被加载进内存。

这带来一个感知上的差异：硬盘上有模型，和模型可以被调用，是完全两码事。前者只是文件存在，后者要求推理进程成功读取权重、初始化会话。很多排查卡在"文件在但用不了"，根因就在这里——加载环节出了问题，而不是文件缺失。

3.3 用启动日志观察模型加载过程

Chrome为调试这类问题提供了启动参数：--enable-logging。在命令行关闭所有浏览器实例后，用下面这种方式启动：

"C:\Program Files\Google\Chrome\Application\chrome.exe" --enable-logging --v=1

然后在页面里调用一次AI接口，回去翻生成的chrome_debug.log。正常加载时，日志中会出现成功读取模型文件的记录；失败时会出现文件读取错误、内存分配失败或指令集不支持之类的异常信息。我第一次排查多用户资料问题时，就是通过这种方式拿到了关键证据：模型文件读取成功、但模型会话初始化失败。

注意：--enable-logging产生的日志文件在Windows上位于用户数据目录下的chrome_debug.log，macOS则在~/Library/Logs/Chrome/chrome_debug.log。日志量大且会持续增长，排错完记得关掉这个参数，否则长期挂着会拖慢启动速度。

4. 多用户资料场景下的模型加载失败：完整排查链路

4.1 症状描述：默认资料能用，新建资料报错

我的实际使用场景是这样的：日常主力是默认用户资料（Default），在这个资料下打开AI能力一切正常；为了做测试，我新建了一个用户资料（Profile 1），在新资料里访问需要AI能力的页面，结果控制台返回：

window.ai.canCreateTextSession(): unavailable

关键在于：chrome://components里模型组件依然显示"已更新"，硬盘里模型文件也还在。同一个浏览器、同一台电脑、同样的模型文件，换了个用户资料就不可用了。这个现象很反直觉，也是我决定把排查过程完整写下来的原因。

4.2 第一步：区分"模型不存在"与"模型无法加载"

我的排查思路是这样的：先确认问题出在"找不到模型"还是"模型加载失败"。如果是找不到模型，说明新资料里浏览器无法定位到模型文件；如果是加载失败，说明文件找到了但初始化出错。这两个方向往下追的路径完全不同。

在默认资料里，chrome://ai-internals显示模型状态为已下载，可创建会话；在Profile 1里，同一页面显示模型状态为未下载。这个现象就很有意思了——模型文件明明在那，浏览器却说没下载。它提示我一个问题：模型可用性状态可能是按用户资料维度独立记录的。

4.3 第二步：翻找每个Profile的偏好设置

Chrome的每个用户资料文件夹下都有一个Preferences文件，里面记录这个资料的所有浏览器设置。我打开了Profile 1下的Preferences，重点查找与优化指南、AI相关的字段，和Default资料逐项对比。对比结果如下表：

发现没有？Profile 1里根本没有写入模型下载状态相关的字段。这意味着浏览器在判断"这个资料是否具备调用模型的资格"时，查不到任何记录，于是直接判定为不可用。而模型组件本身确实下载在用户数据目录里，所以两个资料看到的物理文件是一致的。

4.4 第三步：追踪组件目录与Profile的关联关系

这里我要解释一下Chrome的多用户资料目录结构。用户数据根目录下，默认资料是Default，后续新建的是Profile 1、Profile 2这样的独立文件夹。模型组件位于用户数据根目录下的"Optimization Guide"，它不归属于任何一个单独Profile，而是被所有Profile共用。

那为什么Profile 1会说"未下载"呢？原因在于：模型文件的物理存放是全局的，但"是否允许这个Profile使用模型"的标记是每个Profile独立记录的。Default资料因为早期使用过AI能力，Preferences里已经写入了下载状态；Profile 1是一个全新资料，从来没有触发过模型下载逻辑，所以浏览器认为它对模型没有任何所有权。

这个逻辑可以用一个生活类比来理解：公司仓库里有一台公用的打印机，A部门登记过可以使用（Preferences写入了授权记录），B部门没登记（Preferences里什么都没有），所以B部门虽然能看到打印机就在那，但门禁系统不认它，就是不让用。

4.5 根因确认：FLAG开关的Profile维度作用范围

实验还发现另一个细节：我在FLAG设置里启用的"Prompt API for Gemini Nano"，它的生效范围是浏览器全局的，但实际触发模型下载和写状态的动作，发生在哪个Profile里，状态就记在哪个Profile名下。你第一次在A Profile里调用AI时，浏览器为这个Profile写下"该下载了"的标记；切换到B Profile后，因为B没有自己的标记，即使全局开关还开着，也不认账。

这解释了最让人困惑的地方：FLAG明明开的是同一个，同一个浏览器实例里切资料，结果却天差地别。根因就在这里——全局开关只是能力入口，每个Profile自身的下载状态标记才是最终决定项。排查到这里，问题算是定位清楚了。

5. 绕过资料隔离的可行方案与实测结果

5.1 方案一：在新资料里重新触发一次模型下载

定位到根因后，最简单的解法是让Profile 1自己也走一遍"判断下载"的流程。具体操作是：在Profile 1窗口里打开页面调用AI接口，只要全局开关是开的，浏览器就会发现这个Profile没有下载记录，于是重新触发一次模型下载。

但这一步我实测有个坑：模型文件在硬盘上已经存在，浏览器应该识别到"文件已在"并直接写入状态记录。可实际跑的时候，它有时候会重新开始下载一遍——因为记录里找不到"文件在"的判断依据，它只能重新拉取。这就导致同样的900MB内容又下载了一次，而且下载中途如果切走资料，还会留下一个残留的未完成文件。我建议的做法是：如果你想走这个方案，先准备好等它跑完，中途别切Profile，也别关浏览器。

这个方案的好处是不用动系统文件，坏处是要多等一次下载流程，对网络和磁盘都是负担。而且实测下载完成后，chrome://components里会出现重复的版本记录，不影响使用，但看着很闹心。

5.2 方案二：手动迁移目录配合偏好补写

第二个方案是我最终采用的，思路是：既然物理文件是全局共用的，状态记录是Profile独立的，那把状态记录补上不就行了？理论上讲，直接把Default的Preferences里的相关字段复制到Profile 1，就能让新资料"认领"模型。

但实际操作中这个方案有两个风险。一是Preferences里有大量其他配置，复制字段时定位不准容易出现格式错误，浏览器会认为该文件损坏；二是直接编辑Preferences时如果浏览器还在运行，退出时会把内存中的配置写回去，把你改的内容覆盖掉。正确的操作方式是这样的：

1. 彻底关闭所有Chrome进程，包括托盘里的后台进程
2. 用文本编辑器打开User Data\Profile 1\Preferences
3. 定位到optimization_guide字段，把Default中完整对应的配置结构复制过来
4. 保存后重启浏览器

我在实测中还有一个替代操作更稳妥：不复制整个字段块，只新建资料后先触发一次全量下载，下载完成后检查Preferences，发现浏览器自己写入的字段和Default一致。这说明"触发下载"本身就是系统设计好的写状态入口，手动改文件只是绕过下载路径的取巧方式。

这两个方案我都试过，就可靠性而言，我的结论是：方案一（重新触发下载）虽然慢但最稳定，符合官方设计意图，后续遇到模型升级也不容易出问题；方案二省流量但属于"黑科技"操作，浏览器升级后字段结构变化时容易失效。

5.3 方案三：干脆把AI能力集中在主力资料里

第三种方案说不上是"解决"，更接近"规避"：如果多用户资料场景下你没有强诉求让所有Profile都具备AI能力，那就把AI调用集中在已经可用的主力资料里。Chrome的端侧模型是共用的，这意味着模型的下载和更新在整个用户数据目录里只维护一份，你主力资料里的调用行为等同于替其他资料把模型"养"在硬盘上。其他资料未来如果升级到支持版本或重置了配置，写状态时识别的还是同一套模型文件，因此从存储角度看并不会造成双倍负担。

实测下来，这种方法对日常使用最省心。我最后的做法是：主力资料跑AI任务，测试资料用来做页面调试，不做AI调用。如果你是因为某个特定工作流必须在新资料里用AI，那还是老老实实走方案一。

6. 踩坑总结：模型加载与多用户资料场景值得记住的三件事

6.1 模型存在不等于模型可用

整次排查里我最大的感受是：盘上的文件、组件的状态、可用的会话，这三个环环节节都不直接相等。组件显示"已更新"只是说明下载系统认为文件完整；canCreateTextSession()告诉你的是当前Profile能否真正创建一个推理会话。这两者中间隔着Profile状态记录、加载进程初始化、硬件支持判定三道关卡。以后遇到"模型明明下载了但用不了"，先别急着删了重新下，按这个链路排查：

1. 查chrome://components确认组件状态不是错误
2. 查模型目录体积确认文件真正完整
3. 查chrome://ai-internals或跑canCreateTextSession()确认当前Profile的可用性
4. 换到曾经正常过的Profile试试，锁定Profile因素

6.2 多用户资料场景先想到Preferences，而不是模型本身

如果问题只出现在新Profile，默认Profile正常，那么九成概率和模型文件本身无关。Chrome把"是否记录过下载状态"存在Profile的Preferences里，这个设计让很多人绕了一大圈去检查模型目录，实际上模型根本没问题。未来再遇到类似情况，我就建议直接对比两个Profile的Preferences和FLAG状态，能省掉很长时间。

6.3 端侧AI的排查日志比界面状态更可靠

调试这类问题，界面状态永远只能给你结论，给不了原因。我推荐的组合是--enable-logging --v=1启动加控制台脚本探测，配合Preferences对比，基本能把大多数模型加载问题定位到具体环节。日志文件虽然读起来费劲，但里面的关键行比任何状态页面都诚实。用熟了之后你会觉得，端侧AI的调试流程和普通浏览器功能调试没本质区别，核心还是定位数据和状态写在哪。

最后补一个经验：每次Chrome大版本更新后，我建议重新看一次chrome://components里的模型组件状态，大版本升级偶尔会重置组件更新数据，导致模型需要重新下载。发现问题早点触发下载，比等到要用AI的时候发现不可用要从容得多。希望这份实测记录能给同样在端侧AI坑里折腾的人省点时间。