WebAssembly AI 插件开发短记：延迟和成本怎么一起看

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

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 建议”，让用户确认再使用，而不是自动替他提交内容。

本地推理不是天然更好。模型太大、设备不支持或者结果质量不够时，直接提示功能不可用或让用户选择远端，通常比悄悄降级更诚实。先把输入范围、退出方式和人工确认做清楚，再谈性能优化。