Resident Model Lab

Perception. Interpretation. Action.

Resident Model Lab studies local language-model inference around the existing OLMoE mixture-of-experts model. Nurowerx develops the runtime, not the foundation model. The question is which expert weights should remain in GPU memory without changing the model router’s choices.

Research software / Active development

RESIDENT MODEL
LAB.

Resident Model Lab is an implemented local research platform for studying how an existing mixture-of-experts language model can operate with fewer of its components held in fast GPU memory at once. The software manages component loading and residency, then measures GPU memory, logical expert reads, response time, and output fidelity.

What is working

An experimental command-line runtime manages a bounded GPU-resident expert set. Selection v2 keeps the router's expert choices intact while a layer-partitioned cache decides which expert weights stay GPU-resident. Generated tokens were identical across all 128 tested requests.

OLMoE / Expert residency / Resource accounting
FIG. RML-A / Native routing · bounded memory · local expert storeResident Model Lab / v0.2 selection v2
Resident Model Lab conceptual three-tier architectureThree stacked planes. Top: model execution in the existing OLMoE model, where the native router selects model experts, illustrated here by a small representative subset of paths; actual expert and layer counts are not represented. The selections shown are the ones the router requested, and selection v2 preserves them. Middle: GPU residency, a layer-partitioned expert cache holding a small set of resident experts per layer partition. Bottom: local storage holding the full expert weight store of about 12 GiB. Dashed paths show an expert being loaded on demand from storage into the cache, then computed in the model exactly as the router requested.L1*L2*L3*L4*NATIVE ROUTERT1 / MODEL EXECUTIONExisting OLMoE · router selections preservedT2 / GPU RESIDENCYRepresentative layer partitions · bounded slotsT3 / LOCAL STORAGEFull expert weight store · ~12 GiB · stays localINPUT CONTEXTPrompt tokens enter each layerEXPERT REQUESTSRequested experts protected,others evicted per layerOUTPUT FIDELITY CHECKTested token matchesOUTPUT COMPARISONReference ⟷ selection v2See measured results ↓Router-selected expertGPU-resident expertOn-demand load / eviction* Illustrative layer partitions — not the full model topology
Conceptual architecture · not to scale · not experimental telemetryIllustrative subset of layers and expert paths — not full model topology
  1. T1 / Model execution

    The existing OLMoE router chooses experts for each layer. Selection v2 computes exactly those experts — no substitution, no compression.

  2. T2 / GPU residency

    A bounded, layer-partitioned cache decides which experts stay on the GPU, protecting the ones the current request needs and evicting others.

  3. T3 / Local storage

    The complete expert weight store (about 12 GiB) stays on local storage; missing experts are loaded on demand. Storage is not active model context.

PRESERVE. MANAGE.

/01 Router choices preserved

Compute what the model asks for.

Selection v2 always executes the experts requested by OLMoE's original router. It is not model compression and does not substitute experts. Nurowerx builds the surrounding local runtime; the foundation model is existing open work.

Existing OLMoE model / RTX 5070 test setup
/02 Layer-partitioned residency

Decide what stays on the GPU.

Expert caches are partitioned by layer, with protection for experts the current request needs, replacing a single global LRU cache. The complete expert store (about 12 GiB) remains on local storage and is loaded on demand.

Measured: GPU tensor allocation only — not total system or host memory

MEASURE WHAT
MATTERS.

Results from one small experiment with serial, nonrandomized passes and an empty application cache. Timings are subject to caching, thermal, and CPU effects. Each figure is annotated with what it does and does not show.

38.3%Lower peak GPU tensor allocation

New 128-slot vs prior 256-slot default. Caused by halving cache capacity, not by the new algorithm alone — and mean latency was 11.4% higher.

128/128Requests with identical generated tokens

16 engineering tasks × 2 cache conditions × 4 configurations. Not a claim of universal output equivalence.

6.3%Lower mean latency at equal 128-slot capacity

Also 13.6% fewer logical expert reads (9.9% / 4.8% at 256 slots). Logical reads are not measured SSD I/O.

24/24Fidelity tests passed

Includes bitwise-equal full next-token logits for three selected prompts, empty and warm cache.

Resident Model Lab cache strategy comparison, empty application cache
Cache strategyGPU slotsPeak GPU tensorsMean response
Prior global LRU2563.92 GiB14.53 s
Layer-partitioned (v2)2563.92 GiB13.10 s
Prior global LRU1282.42 GiB17.28 s
Layer-partitioned (v2)1282.42 GiB16.19 s
Observed

All four configurations solved the same 10 of 16 tasks, including shared failures — fidelity was preserved, correctness was not improved. At equal capacity, layer partitioning reduced mean latency and logical expert reads.

Not established

Only eight novel independent tasks; no independent audit or full public code release. No host-memory savings, cheaper hardware, or commercial benefit is claimed.

Read the public technical research note (v0.2) → (opens in a new tab)

Interpreting the experiment

An MoE expert is a mathematical model component, not necessarily a domain specialist. Cache residency changes which weights are held in fast memory, not which experts the router requests. Logical expert reads count runtime requests; they are not measured physical SSD reads.

Layer partitioning and request protection were tested together, not independently. The public note proposes larger independent task suites, longer contexts, randomized repetitions, isolated mechanism studies and host-memory constraints. Those experiments are not completed findings.

Related research

Public notes disclose reported methods and limitations; they are not a substitute for independent validation.

All research themes →

Independent inquiry.
Deliberate visibility.

Visit GitHub (opens in a new tab)