v0.3-preview

Why this exists: v0.3 — the repack without the second copy — turned out to be a longer
road than one release cycle, so this is a checkpoint published as a pre-release. It shares
where v0.3 stands today, in a form you can actually run. It is not the finished v0.3 and
does not claim to be.

What changed

• The repacker can now build a virtual repack: instead of writing a second packed copy
  of the experts (which costs your disk the model's size again), it writes a small manifest
  and the engine serves experts straight out of your original GGUF file. Space cost is
  exactly 1.0x and no data is moved.
• The launcher can serve a virtual repack as an opt-in. The packed path you already use
  is untouched and stays the default. The launcher's model menu now offers a repack mode
  toggle (packed | virtual); when the menu is skipped it asks once before identifying the
  model.
• Prefetch is a property of the catalog row, not of the virtual path. Two rows ship with
  it on by default (static K=8/N=4): qwen35-122b-nonextn and kimi-k2.6-ram-447gb. The other
  four rows ship off (qwen35-397b is additionally on promotion hold), and the launcher
  leaves them off. In a preregistered A/B on the 122B test model, prefetch made virtual-mode
  decode about 14% faster at under 2% extra bytes read.
• Engine and repacker binaries are updated to carry the virtual path. The packed pipeline
  in them is unchanged in behavior.
• The bundled catalog models.json moves to schema version 2.

Good to know

• The virtual path is slower than the packed path today. Reading in place means the
  experts sit scattered through the original file, so fetching them costs more. Prefetch
  claws part of that back — and note the 14% above is virtual-with-prefetch versus
  virtual-without, not virtual versus packed. That 14% is a PROBE-grade measurement,
  not a gate run, and it was taken on a working tree that predates the release binary
  rather than on the binary in this zip. We have not published a formal packed-vs-
  virtual comparison yet; that measurement comes with the finished release. If your disk
  fits the packed copy, keep using it.
• This pre-release is a status report, not the v0.3 the roadmap promises. The polished
  in-place release — call it v0.3.1 — follows once more of the gap is closed, and that
  work is under way.
• The virtual path has been exercised end to end on the 122B test model. Treat other
  models as untested in this preview.
• Known issue: on a virtual run the launcher's status screen still reports the packed
  path's rows. The launcher does not yet tell the two modes apart on that screen, so
  copy integrity, serving validation, the performance gate row and the reference
  numbers all show what the packed path would show. A virtual repack copies nothing, so
  the copy integrity row does not apply to it; the row simply inherits a true it was
  handed. The virtual path is verified separately, by an 8-item virtual plan gate in the
  launcher and the engine's own re-derivation of the manifest, and that row reflects none
  of it. The speed figures on that screen are packed measurements, and the virtual path
  is not under the performance gate at all:
  a -Repro or -Smoke run can go as far as printing performance gate : PASS on a
  virtual serve, and that verdict belongs to the packed criteria, not to what you are
  running. The screen is fixed in v0.3.1.

Verify the download

moe-direct-v0.3-preview-win-x64.zip  (541,608,407 bytes)
SHA-256: 5cffcec0732c0f673222eee58c6a4bb361f0d7130991df16bac4dc0a09517ba0

SHA256SUMS.txt (shipped alongside the zip):

5cffcec0732c0f673222eee58c6a4bb361f0d7130991df16bac4dc0a09517ba0  moe-direct-v0.3-preview-win-x64.zip