1. Define one narrow task
“Add AI” is not a model requirement. “Classify short English feedback as positive or negative” is. A narrow task makes it possible to test correctness, choose a smaller model, and explain limitations.
2. Check the available browser format
The model needs weights and operations supported by the selected browser runtime, commonly ONNX through WebAssembly or WebGPU. A model being open source does not automatically make it browser-compatible.
3. Treat download size as product design
A 50–100 MB opt-in download may be reasonable for a reusable desktop tool and unreasonable for a single mobile action. Show the approximate size before starting, provide progress, and explain cache behavior.
4. Account for memory, not only file size
Compressed or quantized weights can expand into additional buffers during initialization and inference. Token length, intermediate tensors, and multiple runtime copies can make peak memory materially larger than the downloaded file.
5. Choose CPU or GPU intentionally
WebAssembly reaches a wider range of browsers and works well for compact models. WebGPU can accelerate larger workloads but availability, drivers, and memory still vary. A capability check should produce a fallback, not just a green badge.
6. Verify source, license, and limitations
Record the model identifier, source, license, supported language, training objective, known limitations, quantization, and the exact revision used. Product users should not have to reverse-engineer those facts from a network panel.
Task · format · quantization · first download · peak memory · runtime · device range · source · license · data path.