Build. Test. Question.

Perception. Interpretation. Action.

A selective view of experimental software and technical inquiry. We report working mechanisms, measured findings, and limitations separately. Source implementations remain private unless deliberately released.

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
01 / INPUTRequest and model stateLocal inference
02 / RESIDENCYExpert set and component loadingGPU memory budget
03 / EVALUATEGenerated answer and measured tradeoffsQuality / Latency / Memory

Conceptual software workflow / Not a visual of measured data

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)

WHAT DIDN'T
WORK.

The earlier v0.1 restricted adaptive selector substituted a 16-expert working set for the router's choices and degraded output. It is no longer the current approach; selection v2 was designed in response.

Historical v0.1 evaluation, eight tasks per method
v0.1 execution modeTasks passed
Exact execution5 / 8
Ordinary quantization5 / 8
Restricted adaptive (16 experts)2 / 8

THE HARD PART
IS NEXT.

Planned tests include an expanded set of independent tasks, long contexts, randomized replicates, isolation of which mechanism drives each effect, host-memory limitations, and overlapping exact transfers.

Research-stage software / Private repository / No consumer product announced

  1. /01Perception

    Sensing & classification utilities

    Small, non-sensitive examples of signal handling and object classification pipelines.

  2. /02Inference

    Evaluation & orchestration patterns

    Reference patterns for evaluating models and composing intelligent workflows.

  3. /03Oversight

    Human-in-the-loop interfaces

    Interface studies for reviewing machine recommendations before action.

  4. /04Explainability

    Inspectable AI Interfaces

    Interface patterns for transparent model explanations, uncertainty, evidence provenance, and human correction or override.

Visit GitHub (opens in a new tab)

Company research is described here without disclosing unpublished source code or private experimental materials.