Machine Intelligence for Rust

Small models. Systems-grade intelligence.

Use MiRust as a project guide for micro language models, Small Language Models (SLMs), local-runtime architecture, model formats, quantization, memory behavior, evidence, and governance in the Rust ecosystem. The guide now includes a source-grounded map of the supplied GGUF.MiRust.com implementation while keeping executable code and model artifacts outside WordPress.

MiRust conceptual runtime pipelineA model artifact flows through loading, validation, precision selection, compute dispatch, runtime execution, and output.ModelartifactLoaderValidatemetadataPrecisionComputebackendRuntimeexecutionOutput
Architecture documentation only. This website does not execute model inference.

Project boundary: MiRust.com is the public project guide and evidence surface. GGUF.MiRust.com is the separately governed enterprise Rust browser-runtime implementation project identified by the owner. Guide content is not implementation proof.

Review the project boundary · Browse research tracks

Implementation snapshot / Reviewed 2026-06-25 UTC

Document the code that exists—not the system imagined around it.

The supplied GGUF.MiRust.com-20260625.zip snapshot contains TinyRustLM 0.1.0: a four-crate, dependency-free Rust workspace, a compiled WebAssembly module, a synchronous browser shell, a custom SLM1 model container, scalar transformer inference, byte and BPE tokenizers, f32/q8_0/q4_0 tensor paths, KV caching, sampling, diagnostics, conversion tools, and deterministic smoke artifacts.

Observed

Runtime core

Raw WASM ABI, explicit error codes, parser validation, transformer forward pass, generation state, and model lifecycle.

Observed

Custom SLM1 format

108-byte header, 64-byte tensor entries, 64-byte tensor alignment, embedded tokenizers, checksums, and three weight encodings.

Not yet present

Modular intelligence layer

No skill registry, adapter loader, router, worker pool, persistent verified cache, GPU backend, or Teleodynamic slow loop is present in the reviewed source.

Framework scope

Three engineering concerns, one evidence model

Model lifecycle

Model acquisition, metadata, licenses, formats, precision, validation, caching, and loading remain explicit and source-aware.

Read model lifecycle

Runtime architecture

Loader, memory manager, execution plan, backend abstraction, scheduler, decoding, and error boundaries form a modular pipeline.

Review runtime architecture

Engineering discipline

Type-driven APIs, explicit errors, observability, testing, supply-chain review, and reproducible measurement constrain the design.

Review engineering guidance

Architecture at a glance

Four layers with explicit boundaries

Each module can carry a visible status so conceptual design is not mistaken for implemented support.

01

Loader and initialization

Capability detection, model metadata, caching, validation, and initialization.

Proposed
02

Memory and resources

Host memory, GPU buffers, allocation reuse, model residency, and lifecycle.

Research
03

Compute and dispatch

Graph planning, kernels, backend selection, scheduling, and execution boundaries.

Research
04

Results and observability

Decoding, metrics, errors, traces, and user-facing output.

Proposed

Small-model focus

Resource behavior matters more than a single threshold

Micro language models

Useful for narrowly bounded tasks and constrained environments. Evaluate artifact size, working memory, tokenizer cost, context, precision, and backend kernels together.

Small language models

Useful where broader language capability is required within defined device or service budgets. Parameter count alone does not determine deployability.

Embedding and specialist models

Encoders, rankers, classifiers, audio, and vision models often provide higher task efficiency than generative models, but still require format and backend verification.

Runtime targets

Compatibility is an editorial record

The matrix is maintained under Settings → MiRust and defaults to Not verified.

Runtime target compatibility. Statuses reflect explicit editorial entries, not inferred support.
TargetStatusEvidence or constraint
Native CPUNot verifiedNo verification note has been recorded.
Native GPUNot verifiedNo verification note has been recorded.
Browser CPUNot verifiedNo verification note has been recorded.
Browser GPUNot verifiedNo verification note has been recorded.
Embedded or constrained environmentsNot verifiedNo verification note has been recorded.
Server or edge nodesNot verifiedNo verification note has been recorded.

Formats and precision

Portable artifacts still require backend-specific verification

Safetensors

Primary use: tensor artifacts with explicit metadata and contiguous data.

Benefits: bounded metadata parsing and direct tensor-region access.

Constraints: model architecture and operators remain runtime concerns.

Known backend requirements: a loader supporting the stored dtypes, shapes, and model architecture.

Last verified UTC: Not verified · Source: Not configured

GGUF

Primary use: metadata-rich, frequently quantized language-model artifacts.

Benefits: model metadata and quantization variants can travel with the artifact.

Constraints: variant and kernel support differ by runtime.

Known backend requirements: exact architecture, tensor encoding, and quantization-kernel support.

Last verified UTC: Not verified · Source: Not configured

ONNX

Primary use: portable compute graphs across model families.

Benefits: a documented graph and operator representation with broad tooling.

Constraints: operator coverage and export correctness must be tested.

Known backend requirements: compatible opset, shapes, data types, and execution-provider coverage.

Last verified UTC: Not verified · Source: Not configured

FP32

Primary use: numeric baseline and compatibility reference.

Benefits: broad arithmetic support and reduced precision-conversion complexity.

Constraints: larger files, working memory, and bandwidth.

Known backend requirements: complete 32-bit floating-point operator support.

Last verified UTC: Not verified · Source: Not configured

FP16

Primary use: reduced storage and bandwidth where half precision is supported.

Benefits: lower model-residency and transfer costs than FP32.

Constraints: numerical behavior and operator support vary by target.

Known backend requirements: native or emulated FP16 kernels for every required operator.

Last verified UTC: Not verified · Source: Not configured

INT8

Primary use: quantized inference with integer weights or activations.

Benefits: smaller artifacts and potentially efficient integer kernels.

Constraints: calibration, scaling, and operator coverage affect quality and speed.

Known backend requirements: the exact quantization convention and matching integer kernels.

Last verified UTC: Not verified · Source: Not configured

Lower-bit quantization

Primary use: aggressive reduction of model storage and residency.

Benefits: reduced memory bandwidth and expanded constrained-target options.

Constraints: quality loss, packing scheme, group size, and mixed precision must be recorded.

Known backend requirements: kernels implementing the exact named quantization scheme.

Last verified UTC: Not verified · Source: Not configured

Developer workflow

A six-step lifecycle, not an automation claim

  1. Select a task and target

    Define outputs, latency, memory, privacy, hardware, and licensing constraints.

  2. Select or train a model

    Choose capability based on evidence for the target workload.

  3. Validate licensing and metadata

    Record source, revision, terms, tensor metadata, and integrity evidence.

  4. Quantize or optimize

    Name the exact transformation and measure quality, file size, and memory effects.

  5. Select a runtime backend

    Verify operators, precision, target, fallback behavior, and resource limits.

  6. Benchmark and deploy

    Publish methodology, raw data, limitations, and repeatable instructions.

Architecture patterns

Rust-native architecture without object-oriented imitation

Traits act as architectural ports; adapters isolate infrastructure; enums represent closed state spaces; generics specialize hot paths; trait objects belong at application boundaries; typestate validates transitions; newtypes protect domain values; RAII manages deterministic resources; and message passing replaces pervasive shared mutability.

Read the Architecture documentation

Research tracks

Bounded questions, explicit evidence gates

Current tracks cover TinyLM-16M as a reference workload, teleodynamic and resource-bounded systems, a Standard ML compiler/runtime case study, browser and native execution constraints, and enterprise delivery. Each remains Research until exact artifacts and methods are verified.

Open the research index · Read research documentation

Modular tiny-model architecture

Choose the installed library. Bound the active set.

The Tiny Model Composer turns model scale, model count, specialist roles, orchestration, and resource posture into a transparent non-executing architecture plan. It distinguishes cached capacity from active compute and exports a JSON handoff for GGUF.

N-total

Installed specialists

Download, cache, provenance, license, and update surface.

K-active

Resident specialists

Peak weights, workspace, context state, and route scope.

K-parallel

Concurrent specialists

Immediate compute contention, latency, and power pressure.

Teleodynamic AI research

Turn “self-regulation” into state, actions, evidence, and falsifiable claims.

MiRust now treats Teleodynamic Learning as a narrow research program: coupled structure and parameter dynamics, an endogenous resource ledger, local action selection, explicit no-op behavior, and observable phases. The guide separates that theory from ordinary resource management and from any unverified GGUF implementation.

H

Structure

Hypotheses, rules, routes, memory, or other representational organization.

θ

Parameters

Continuous adaptation within the currently available structure.

E

Resource

Internal state that actions alter and that constrains later actions.

τ

Trajectory

Replayable observations, decisions, costs, rewards, and phase diagnostics.

Enterprise engineering

Governance as technical design

  • Dependency governance
  • Supply-chain review
  • Reproducible builds
  • Typed error boundaries
  • Structured observability
  • Property testing and fuzzing
  • Benchmark regression
  • Minimum supported Rust version policy
  • Unsafe-code review
  • Software bill of materials
  • Release signing

Review enterprise guidance

Maintained knowledge

Latest content

Dates are rendered from WordPress in UTC-aware form. Verified model and benchmark sections remain empty until evidence-backed entries are published.

Recently updated documentation

DocumentationExperimental

Worker-owned runtime migration

Defines the concrete browser changes required to move synchronous inference off the main thread without obscuring cancellation, result ownership, or error semantics.

DocumentationExperimental

Verified persistent model store

Defines cache keys, chunking, cryptographic verification, transactional activation, quotas, eviction, and corruption recovery for a browser-local artifact store.

DocumentationExperimental

GGUF compatibility implementation path

Defines how to add real GGUF support as a distinct parser and model-adapter path while preserving honest SLM1 naming and tests.

Recent guides

GuideExperimental

Inside the SLM1 model container

The exact 108-byte header, 64-byte tensor directory, tokenizer sections, quantized storage, checksum, and shape contract used by TinyRustLM.

GuideExperimental

How TinyRustLM generates one token

A source-grounded walk through embedding lookup, pre-norm attention, RoPE, causal KV-cache attention, residual flow, SwiGLU, logits, and sampling.

Recently verified model profiles

Model profileExperimental

TinyLM-16M deterministic smoke — f32

Observed TinyRustLM SLM1 f32 artifact from the 2026-06-25 implementation source snapshot. Deterministic runtime smoke only; no trained assistant quality is claimed.

Model profileExperimental

TinyLM-16M deterministic smoke — q8_0

Observed TinyRustLM SLM1 q8_0 artifact from the 2026-06-25 implementation source snapshot. Deterministic runtime smoke only; no trained assistant quality is claimed.

Benchmark reports

No benchmark report are published.

Roadmap and status

Only explicit WordPress entries appear here

Available or documented now

No explicit roadmap entries are published in this category.

Experimental or being validated

No explicit roadmap entries are published in this category.

Proposed or planned

No explicit roadmap entries are published in this category.

Engineering evidence

Build from verified constraints, not assumptions.