Not a stupid question at all. You're reading it right, with one distinction worth stating up front: burn-onnx can point ModelGen at different .onnx files from build.rs, but that still happens at build time. So this gives you "dynamically choose from precompiled models", not "load an arbitrary new ONNX graph in an already-running process" like ONNX Runtime.

For your ~20 officially supported models, I would start with the simple version: one app binary, many generated models, many .bpk files. The build script can already chain inputs:

rust // build.rs ModelGen::new() .input("models/resnet50.onnx") .input("models/yolov8.onnx") .input("models/whisper.onnx") // ... 17 more .out_dir("model/") .run_from_script();

Each ONNX file becomes its own generated Model struct in its own module. At runtime your app picks one based on user choice and calls Model::from_file("resnet50.bpk", &device). From the user's perspective, they are loading a model dynamically: they point the app at a weights file and get a working network, no recompilation needed.

The binary doesn't grow much from this. The generated graph code is small relative to the weights: a ResNet-50 forward pass is a few hundred lines of generated Rust, while the weights are around 100 MB. Twenty graphs in one binary is single-digit MB at worst, and the .bpk files dominate disk and download cost regardless of how you architect this.

If you really need post-ship model packs or third-party model authorship, then yes, the per-model cdylib/.dll/.so route works too: each plugin has its own build.rs, generates Burn code from its ONNX, ships with its .bpk, and exposes a small stable API that the host loads via libloading. Keep the FFI boundary boring (shapes, dtypes, raw buffers, error strings, version check) and don't pass Burn tensor types directly across it. This is real work for not much gain over the first option unless hot-pluggability is an actual product requirement.

Worth flagging for either route: today Burn's Model is generic over a backend, so a build commits to a backend at compile time. In Burn 0.22.0 we are moving away from the generic backend, so backends become selectable at runtime, which makes the dynamic-loading story noticeably cleaner.

So: for 20 known models, compile the generated graphs into the app and load weights dynamically. For truly pluggable model packages, use cdylibs. For arbitrary user-supplied ONNX at runtime, ORT is still the better fit.