给图片做语义检索，成本最高的从来不是模型推理，而是那一次上传→云函数→向量库→返回的网络往返。而它本可以从架构里彻底消失。
上周帮一个做电商的朋友扒竞品素材，需求很朴素：把几个详情页、小红书笔记里的图全存下来，然后按「找一张有跑车和晚霞的图」这种自然语言去搜。他一开始用的是某个在线 AI 图库工具，300 张图上传花了四分钟，其中两张带用户头像评价截图被拒了------理由是「云端内容审核未通过」。那一刻我们都明白问题出在哪：图的隐私性和检索的即时性，天生不该交给远端。
下面按我实际踩坑的顺序拆，从特征提取、向量归拢到打包下载，每一层都有能省掉的东西。
一、大多数「AI 图库」的架构，其实懒得很
标准链路长这样：
- 前端读图 → base64 → POST 到云函数
- 云端跑 CLIP 出 512 维向量 → 写向量数据库
- 搜索时前端再请求一次，拿回相似结果
这套东西要付三笔账：算力账单、隐私账单、延迟账单。 而你真正需要的算力，可能只有 4MB 的模型体积和 20ms 的单图推理。
MobileNetV3-small 的中间层（GAP 前一层，1024 维）在通用语义区分上表现足够好------它区分不了「哈士奇」和「阿拉斯加」，但完全能把「跑车」「晚霞」「猫」「室内人像」拆开。对素材筛选这个场景，这就是性价比的甜点。
二、端侧推理，三个必须做对的决策
决策 1：Web Worker，没有商量余地。 200 张图在主线程跑推理，你的输入框会卡到打不出字，滚动条变成 PPT。把模型加载、张量预处理、推理全塞进 Worker，主线程只负责 postMessage 和画进度条。
决策 2：向量必须 L2 归一化后再存。 不然余弦相似度就得每次算范数，白烧 CPU；归一化之后，余弦 = 内积，一次 reduce 搞定。
决策 3：近重复阈值别拍脑袋。 同一张图的不同分辨率变体（800×800 和 1200×1200），余弦相似度通常落在 0.94~0.99；不同构图但同主题的两张图，大约 0.75~0.88。0.92 这条线就是这么试出来的------再往下调，会把「两张不同角度的车」误折叠成一张。
三、比 AI 更脏的活：逆向 CDN 缩略图后缀
你右键存下来的图，八成是缩略图。真正的母图藏在 URL 参数里：
- 阿里云 OSS：
?x-oss-process=image/resize,w_200 - 腾讯云 COS：
?imageMogr2/thumbnail/200x - 七牛：路径尾部
-200x200 - 小红书/微博图床：
/w/1080/format/webp之类
写好一组正则，按域名分流剥离参数，直出原图链接，这一步的收益比模型调参大得多------没有原图，再准的搜索也是搜缩略图。
四、2000 张图打包，为什么你的 ZIP 会炸
这是最容易翻车的地方。前端库默认用 DEFLATE 压缩，全量读进内存累积 ArrayBuffer。2000 张 4K 图，光解压后的缓冲区就能顶到 2GB，Chrome 标签页直接 OOM 白屏。
正确的做法两条：
- 用 STORE 模式，零压缩。 JPEG/PNG 本身就是压缩格式，再 deflate 一遍省不下 3%，却要吃掉满核 CPU 和内存栈。
- 流式写入。 边取图边算 CRC32 边写块，内存里只驻留当前这一张的缓冲，配合读流限速，2000 张也能稳在几百 MB 以内。
五、我最后落地的方案
上面这些拼起来，就是我现在常驻侧边栏的 OmniPic Studio Pro：
- MobileNet 离线嵌在 Web Worker，0 云端成本、100% 本地运算，断网照样搜；
- 1024 维向量 + 自然语言/以图搜图，没 Alt 标签也能搜「跑车」「晚霞」；
- 余弦 ≥ 0.92 自动折叠同图不同分辨率，图库瞬间清爽一半；
- 自动剥离各云厂商缩略图参数，直出 4K 母图；
- STORE 流式打包，2000+ 大图文 ZIP 不崩；
- 画框嗅探 + 悬浮原图直存，还能直连 Eagle / Billfish。
把它当成一个「本地视觉索引器」用，而不是又一个下载器------这是它和同类插件最本质的差别。
六、装完之后，建议按这个顺序试
- 随便开一个电商详情页或图库站，点开侧边栏让它扫一遍；
- 在搜索框打一句中文描述，看它能不能命中------这一步最能体现端侧语义检索的价值；
- 切到重复图视图，看它把多少张缩略图折叠掉了；
- 全选导出，观察 ZIP 生成时内存曲线，你就知道流式写盘到底救了多少条命。
最后留个问题：你平时收集素材，是靠文件夹命名硬扛，还是已经有自己的一套索引习惯？评论区聊聊，我挑几个典型场景写进下一篇实操。