端侧推理不再是演示
浏览器里跑 AI 模型，一两年前还是技术演示性质：模型小、速度慢、效果勉强。现在 WebGPU 逐步铺开、Transformers.js 这类运行时成熟之后，一套 React + TypeScript 项目已经能把五个真实场景跑顺——推理全程在用户设备完成，不走 API、没有按 token 计费、数据不出设备。模型下载一次、缓存之后可以离线跑。
先给能力画像：能跑的是几千万到几亿参数的小模型，专门任务上表现相当好，通用能力别指望。推理放 Web Worker 里避免卡界面，优先 WebGPU，不支持就回退 WASM 跑 CPU。
五个场景，五个量级
背景移除（RMBG-1.4，约 44M 参数，170MB）。 效果最直观的一个。上传照片、主体与背景分离、导出带透明通道的 PNG。电商和拍卖场景想象空间直接：卖家随手一拍，应用内一键去底，照片不上传任何服务器。注意这个模型的许可证有商用限制条款，上线前必须核实。
替代文本生成（Florence-2-base-ft，约 230M，350~450MB）。 给图片生成 alt 文本初稿，对无障碍访问有价值。生成结果必须人工审——模型不知道你为什么放这张图，会漏细节也会编内容。项目里那个"附加说明"输入框，实现上只是把文字拼接到结果后面，并不真正影响模型理解，别高估。
智能工单创建（Qwen2.5-0.5B-Instruct，约 500M，786MB）。 最意外也最费劲的一个。难点不在理解口语化报修描述，而在稳定输出结构正确的 JSON：不编字段、不返回畸形格式。最后靠提示词设计 + 输出解析 + Zod 模式校验才跑通。这个模式值得抄到生产：AI 做枯燥初稿，用户确认后提交，人保留控制权。
语义搜索（all-MiniLM-L6-v2，22M，CPU 版仅 23MB）。 小模型真正发光的地方。工单和查询都转向量、余弦相似度比对，不需要生成式大模型，速度快结果有用。数据量大了之后要补索引和持久化——演示里向量放内存，思路成立但别直接照搬到大文档集。
暂停并提问（LFM2.5-VL-450M，450M，约 400MB）。 摄像头画面周期性描述，可暂停某一帧提问。作为本地视觉问答实验有意义，离可靠的无障碍工具还有距离。
WebGPU 可用性：先探测再降级
模型表现很大程度押在 WebGPU 上，但各浏览器进度不一：Chromium 系（Chrome/Edge 113+）默认开启，体验最完整；Safari 较新版本部分可用；Firefox 默认仍需手动开启。所以运行时探测是必需动作，不是可选项：
async function pickDevice() {
if (!('gpu' in navigator)) return 'wasm';
try {
const adapter = await navigator.gpu.requestAdapter();
return adapter ? 'webgpu' : 'wasm';
} catch { return 'wasm'; }
}
拿到 wasm 就要有心理预期：速度差的不止一点，复杂模型可能慢到不可用。产品上给这类用户降级方案（缩小模型、减少功能）比硬扛体验好。
三个容易翻车的工程点
模型加载与缓存。 体积从 23MB 到近 800MB 不等，首载等待不能忽略。模型文件按版本固定 URL，缓存走浏览器 Cache API——但存储配额有限，浏览器可能随时清掉，缓存失效后要能静默重下。加载失败重试必须做，尤其是移动端网络。
跨域报错。 从模型托管站拉权重时，CORS 配置不对会直接报跨域错误且日志很迷惑。要么用托管方提供的带签名的直链，要么把权重转存到自己的对象存储并配好 CORS 头再加载。
输出兜底。 语言模型会返回畸形 JSON 或编造字段，模式校验（Zod 一类）加输出解析是必需项不是加分项。校验失败的重试策略也要定：重试几次、失败后降级成人工填写，都得写进流程。
选型判断
端侧模型现在的合理定位：现有功能的增强层，不是关键任务系统的唯一依赖。最值得优先落地的信号有两个——隐私敏感（数据不能出设备）和成本敏感（高频、小额任务不值得按 token 付费）。选型时别默认上通用语言模型：语义搜索这种任务，一个 20MB 的专用嵌入模型比大模型效果更好、成本更低。任务专一就选专用小模型，这是端侧推理和云端调用最大的选型差异。
评论0