UMIE: one resident model, modular behavior

UMIE—the Universal Modular Inference Engine—is a Rust inference substrate for the fungOS ecosystem. A base model stays resident; validated behavior assets change its operation. Model-specific Lua recipes resolve into typed plans. Rust owns checkpoint bytes, memory, kernels, scheduling and execution.

UMIE has native Metal and CUDA paths, a Rust SDK, C ABI and serving interfaces. Model coverage is a set of explicit operations and encodings, rather than a blanket promise that every model in a family works. The engine is in active development. Model weights and their upstream licenses are separate from UMIE's Apache-2.0 software license.

What “support” means

A recipe names a model and maps its tensors. A schema check validates that plan. Checkpoint admission then checks actual tensor names, dtypes and derived shapes. A backend must implement the required operators and encodings. Finally, real checkpoint execution and semantic parity need their own evidence.

This page separates those levels. Historical benchmark records are reported as operations performed at their recorded revisions. The documentation work did not rerun GPU models, establish current quality, or certify every configuration. A missing record means unknown. A recipe or timing result alone is insufficient evidence of reliable generation.

Model families and execution evidence

Recorded greedy generation operations are separated from embeddings, RMSNorm, RoPE, linear kernels and decoder-stack measurements in the generated evidence table below. CPU RLCD reduction is an algorithmic operation, not a CPU implementation of every whole model.

Audio and structured policy models

Audio and ASR have their own input, frontend, output-rate and checkpoint contracts. They do not become interchangeable merely because UMIE serves them. Image diffusion-transformer work is a separate execution target; this matrix does not invent image model coverage absent a reviewed recipe and execution record.

Behavior and data boundaries

• Model recipes: instruction-bounded, I/O-free Lua resolves tensor mappings and materialization policy. A recipe is not authenticated just because its sandbox accepts it; admission/signature policy belongs to callers.
• Resident base: tensor materialization is owned by Rust. Adapters, constrained decision plans and other admitted assets have explicit identities.
• RLCD: bounded schema-constrained choices are scored from model logits; tokenizer continuation boundaries are owned by umie-tokenizer.
• Cache identity: inputs that change tensors or KV semantics must participate in identity. A matching model name alone is insufficient.
• Checkpoints: SafeTensors metadata and shard indices are validated before execution. A readable GGUF checkpoint is not automatically executable; its native encoding must have a backend path.

Integration entry points

For embedding, begin with the repository's SDK guide. It documents Rust, C ABI ownership and streaming contracts. Use that contract for handles and buffer release rather than reproducing internal layouts.

The serving layer exposes health, model discovery and metrics:

GET /health
GET /v1/models
GET /metrics

A running process is not evidence that the selected model has finished loading. Verify readiness and the operation actually required by the client. The repository's Rust HTTP SDK reference covers the HTTP client boundary. These repository links may require access.

Regenerate the inventory

UMIE owns the catalog and its provenance. From its checked-out repository:

scripts/catalog-models
scripts/catalog-models --check
scripts/catalog-models --site-source /path/to/fungos-web/docs-source/umie.md
scripts/catalog-models --site-source /path/to/fungos-web/docs-source/umie.md --check
cargo test -p umie-spec --example model_catalog
cargo test -p umie-spec --test incubator_catalog

The deterministic Rust example resolves recipes using the existing sandbox, emits JSON plus Markdown, and checks generated-file drift. It records per-backend resolution errors explicitly. Historical benchmark JSON contributes operation, encoding and the report's last committed revision/date; those dates are commit dates, not inferred measurement timestamps.

The outputs are docs/reference/model-recipes.json and docs/reference/model-support.md. The catalog reference explains evidence levels and limitations. A reviewer must update this page's watched code baseline after examining changed source; regeneration never automatically blesses new behavior.

UMIE model recipe matrix

Generated by scripts/catalog-models. A schema pass is not working model support. Both columns use synthetic host facts and default recipe inputs; no weights, device, latency, quality, or parity are tested. Execution remains unverified by this catalog. Recipes requiring admitted checkpoint context can be unresolved here without being unsupported by their owning subsystem.

JSON includes resolver errors and evidence. Incubator upstream revisions and metadata hashes are maintained in specs/incubator/catalog.json; the catalog's tests compare them to fixtures. training_policy_reference.lua is a training policy, not a model, and is excluded. A resolved decoder family can still be rejected by model compilation or a backend with missing operators.

Recorded runtime operations

Derived from checked-in benchmark reports, separately from schema resolution. These are historical operation records, not tests performed by this command or a guarantee of correctness. Date and revision refer to the report's last committed change, not a measurement timestamp. Missing recorded evidence means unknown, not unsupported.