WebAssembly AI 插件开发短记：延迟和成本怎么一起看
把模型放进浏览器，听上去像是“少调一次接口”这么简单。实际做小插件时，我会先问两个更具体的问题：模型文件下载后页面还能不能正常交互？如果本地跑不动，切到远端的请求会不会超出自己设的预算？
这里的 AI 输入可以是一段用户主动提交的文本，输出是分类标签或改写建议。浏览器端不应把整页内容、长期设备标识或隐私字段拿来做分流。若确实需要决定本地还是远端执行，使用本次会话能否启用 WebGPU、模型大小这类短暂信号就够了；用户也应能明确选择不调用远端服务。
struct RuntimeChoice { has_webgpu: bool, model_size_mb: u32, } fn run_locally(choice: &RuntimeChoice) -> bool { // 这是练习用规则，不是通用阈值。 choice.has_webgpu && choice.model_size_mb <= 20 } #[test] fn chooses_a_small_local_model() { let choice = RuntimeChoice { has_webgpu: true, model_size_mb: 12 }; assert!(run_locally(&choice)); }我会在同一台测试设备上分别记录三件事：从点击到可用结果的耗时、页面是否出现明显卡顿、远端请求是否被触发。不要把某一次测试的数字当成所有人的结论；不同浏览器、网络和模型差别很大。远端返回后，也需要把结果标明为“AI 建议”，让用户确认再使用，而不是自动替他提交内容。
本地推理不是天然更好。模型太大、设备不支持或者结果质量不够时，直接提示功能不可用或让用户选择远端，通常比悄悄降级更诚实。先把输入范围、退出方式和人工确认做清楚，再谈性能优化。
