浏览器里跑 AI 抠图第一次打开要等十几秒。多数人会先怪模型太大。我原来也这么以为毕竟快速档的模型文件有 44 MB。9 月 28 日晚上我量了一遍第一次运行的时间线并把它逐段拆开。模型 4.2 秒就下完了。拖住后面九秒的是一个 5.95 MB 的推理运行时文件。它还要等模型下完才开始下。浏览器端 AI 冷启动慢时间花在哪我在图映负责的是端侧编解码和模型加载这一块这轮只做测量。测的是快速 AI 档模型是 44 279 201 字节的 ISNet INT8。我用的是图映 ImgInghttps://imging.cn/9 月 3 日的线上版本做这组测量。机器是 16 GB 的 Apple M4 Mac。Chromium 149 开源构建搭 ONNX Runtime Web 1.27.0 跑推理。样本是一张程序生成的 1600×1200 瓶子商品图而不是真实照片。所有计时都来自直接调用页面里的 TYBG.segment 函数。界面上点「开始 AI 抠图」调的也是它只是我没有走点击。每次都开全新的浏览器上下文。模型和运行时因此都要重新下载。网络是我家里当时的普通宽带换个地区这个速度可能完全不同。我分两种状态各跑了一遍。一种是开着硬件加速、WebGPU 走 Metal 的 Chromium。另一种是没有可用 GPU 适配器的 Chromium关掉硬件加速就是这种状态。它会先试 WebGPU 再回退到 WASM。两种状态下模型都在 4.2 到 4.4 秒之间下完。开着硬件加速时从调用到出结果共 14.59 秒而推理本身不到 1 秒。没有适配器时共 16.02 秒而推理约 2.2 秒。两者中间都空着一段九秒多的等待正好对应运行时文件的下载与建会话。这张是图映线上页面在冷启动时的截图。红框圈出的状态条里要看的是那行字「模型已准备完成正在建立本页需要的内存推理会话 · 已用时 9 秒」。模型早就到了。界面却还停在初始化这一步而进度条也只走到一半多。这段停留里等的就是运行时 WASM 的下载和会话创建。截图为单次运行。停留时长和正文引用的数不完全一样。页面的网络记录里这两个文件的先后顺序很清楚。模型从 ModelScope 的 CDN 下载并在 4.2 秒下完。随后页面才请求 ort-wasm-simd-threaded.asyncify.wasm 这个放在图映自己站点上而不在 ModelScope 上的文件。它的 gzip 传输量是 5 955 745 字节解压后 24 254 953 字节在 13.2 秒才下完。一个 6 MB 的文件比 44 MB 的模型多花了一倍多的时间。我一开始怀疑是浏览器里同时发出的别的请求在抢这条线的带宽于是我用 curl 在同一时段单独下了两次这个文件。结果分别是 9.19 秒和 10.78 秒折合 552 到 648 KB/s。同一时段 curl 下那个 44 MB 模型只要 4.20 秒10.5 MB/s。这两个源在当晚这条网络上的下载速度差了十几倍。后来还有一次冷启动里这个运行时文件一直到 34.2 秒才下完。那一轮机器上同时跑着别的任务我只把它当作波动很大的证据而不拿来比。为什么走 WebGPU 也要等 WASM 文件直觉上 WebGPU 路径用显卡算而用不到 WASM。实测不是这样。开着硬件加速时页面同样请求并等完了这个文件因为 ORT 的 WebGPU 执行提供程序就打包在同一个 WASM 里。另一个关键点是时序这个 WASM 在建会话时才发起请求此时模型已经下完两段下载是串行的总耗时就是两者相加。缓存命中之后情况完全变了。同一个上下文里新开页面时模型从 Cache Storage 读出。ORT 文件带着 max-age31536000 和 immutable 响应头一次都不再请求。开着硬件加速时从调用到完成只要 930 毫秒没有适配器时是 2 643 毫秒。同一个页面第二次调用更短分别是 409 和 1 951 毫秒。第一次和之后几次之间的差额几乎全部落在那两段下载上。回退判定本身只花约 130 毫秒算不上瓶颈。自己的页面怎么查这一段我后来查这类问题都先开 DevTools 的 Network 面板并勾上 Disable cache然后按开始时间排序。我看的是 .wasm 请求在模型请求结束之前还是之后发起。只看体积会误判要看它的起止时间落在哪一段。第二步是把运行时文件和模型各自用 curl 单独下一遍并记下速率。浏览器里有并发和优先级的干扰单独下一次才分得清是源慢还是排队慢。这一轮只量了一台机器、一条家用网络和一个模型档位别的地区我还没有复测。这组数只能说明这条网络上两段下载的先后顺序和耗时比例。