ruos-foundry-cu-qwen3-30b-a3b-e64

ruos-foundry-cu-qwen3-30b-a3b-e64 is a ruOS specialist cut from Qwen/Qwen3-30B-A3B-Instruct-2507 with MoE-Foundry (ADR-064): the parent's routed experts were traced on the ruOS ruos-cu calibration set, the 64 most-used experts per routed layer were kept, and a complete smaller Mixture-of-Experts model was exported — same backbone, same tokenizer, same token top-k, fewer experts per layer. No weight was changed; experts were removed and renumbered and the router rows sliced to match.

Status: unevaluated and disabled

Per MoE-Foundry's rule an exported specialist starts quality_status: unevaluated, enabled: false. A structural export proves tensor integrity, not retained capability. This checkpoint is published so that slim-eval (slim/eval: run, redteam, regression, verdict) can measure it against the parent on the frozen ruOS test split; until that verdict is recorded here it must not be routed to. The full parent remains the fallback.

Parent

Calibration

Domain ruos-cu: 148 rows (148 from the val split, 0 topped up from train; the test split is never used for calibration), ~63523 tokens, families {"browser_step":142,"cu_step":6}, licences {"project-owned":148}. Calibration file sha256 94a5527b141269ab5078a14e3d129b387aa69412c65334160715fd9a58dbfef5. Texts are the ChatML prompt plus the reference answer.

Router traces: 412 tasks, 148144 tokens, 7110912 rows on NVIDIA A100-SXM4-80GB (bfloat16, transformers 4.51.3); trace sha256 7aabb05cbf715156437393fc5a5b0d756951ecee35eb4542a06fc812f11f9403.

Selection method: mass (accumulated routing probability per expert per layer) — a usage proxy, not causal importance.

Receipt

separator_receipt.json in this repo is the full MoE-Foundry receipt including the per-layer expert mask.

Files

Run

vllm serve ruvnet/ruos-foundry-cu-qwen3-30b-a3b-e64 --max-model-len 8192

Loads with transformers as a standard qwen3_moe checkpoint (single safetensors file, num_experts reduced in config.json).

Limitations

• Unevaluated: no capability, memory or latency claim is made here.
• Retained experts were chosen by routing mass on ruOS calibration prompts; requests outside that domain should go to the parent.
• Memory: fewer experts means a smaller checkpoint; loading several specialists next to the parent can use more total memory than the parent alone.

Provenance

• MoE-Foundry 6677a25 (moe-separator inspect → profile_hf → select → export → mixture)
• run foundry-20260907T172935Z-qwen3-30b-a3b on a single vast.ai GPU; ruos-desktop slim/foundry + slim/scripts/foundry-e2e.sh
• authorisation: rUv, "implement this using ruvnet/MoE-Foundry using vast.ai in a worktree, implement e2e and push models to repo"