UCRT64 + first real Kimi-Linear container on Windows: whole-model oracle PASS on AVX2, and five gaps no CI job can reach

[GTSUltear]

---

Context

Built and ran WASTE v0.6.6 (df54209) natively on Windows 11 x86_64 under MSYS2
UCRT64, then took Kimi-Linear-48B-A3B-Instruct all the way through: 91.5 GB of source
safetensors, a full convert.py run, and generation from the resulting 18 GB container.

This complements #3 rather than repeating it:

	#3 (v0.6.0)	this run
subsystem	MinGW-w64 / Git-Bash; CI now MINGW64	UCRT64
ISA	AVX-512 (Zen 4)	AVX2 (Zen 2, Ryzen 5 3600X)
oracle scope	KDA kernel (kda_ref.py)	whole-model logits (kimi_ref.py)
container	none (synthetic)	real 18 GB, converted on this machine

That last row is why this is worth sending, and reading ci.yml on main sharpened the
point more than expected:

• windows-native uses MINGW64 and installs no uv; it runs bash tests/run.sh
  with no argument, so the synthetic container.
• The only job that installs uv is the Linux build job, and it runs
  tests/run.sh /nonexistent-container — deliberately synthetic.
• No job on any platform runs the suite against a real container.
• tools/diskbench.c is never compiled in CI at all, on any platform.

So the checks that skip without weights — the budget check, the oracle diff, the
container round-trip — have never executed anywhere. Every gap below lives in that
space: each needs a real download, a real conversion, or a container to reach. None is
in src/; the engine came out clean.

Tested on v0.6.6. Every gap below re-verified against main at 2056d44 — i.e.
after v0.6.7 — and all five are still present. Note v0.6.7 reworked the automatic budget
resolver, so the cache measurements further down describe v0.6.6 behaviour.

Environment: AMD Ryzen 5 3600X (Zen 2, 6C/12T), 64 GB DDR4-3200, Sabrent Rocket NVMe4
1 TB, NTFS. gcc 16.2.0 (Rev3, MSYS2), GNU Make 4.4.1, CPython 3.12.8 (MSVC) in a venv
with torch 2.13.0.

---

Results

Build is clean. make produced waste.exe, libwaste.a, libwaste.dll,
libwastevq.dll, no errors, no Windows-specific warnings — only pre-existing style ones
(-Wformat-truncation at cli/main.c:944, -Wmisleading-indentation in
src/tokenizer.c and src/image.c). No CC= override needed; UCRT64 ships a cc.

make check on the synthetic container: 28 passed, 0 failed, 14 skipped.

tests/run.sh against the real container, WASTE_ORACLE and WASTE_REF_SRC set:
32 passed, 1 failed, 9 skipped. The one failure is gap 1 below — a check that cannot
execute on Windows, not an engine defect. Newly passing versus the synthetic run:

PASS  expert records read through the C structs (52 records over 26 banks)
PASS  trace simulator agrees with the engine's cache (41.2% vs 42.3%)
PASS  engine matches the shipped PyTorch oracle
PASS  learned hotlist warms the cache (279 -> 206 misses)
PASS  prompt text cannot forge control tokens (markup mode still can)

That third line is run.sh's own label and is worth disambiguating: WASTE_ORACLE was
pointed at an oracle generated from this container, so it did not compare against the
shipped fixture. Against the shipped fixture it fails — that is gap 3.

Whole-model oracle: PASS at 4.29e-05. tools/kimi_ref.py against the container under
test, diffed against test_forward on the same 16 ids:

engine vs oracle    max|diff| = 4.29153e-05   PASS (threshold 1e-3)
argmax 318 both; max logit 17.9862 vs 17.986

23x inside tolerance over 163,840 f32 logits, exercising AVX2 dispatch, VQ3R expert
decode and the KDA recurrence together. #3 validated the KDA kernel in isolation on
AVX-512; this is the full forward pass on AVX2.

The container round-trips. tools/verify_container.py --experts 1 against the
91.5 GB source: PASS - container round-trips, ~19.5% per-tensor relative error, which
is 3-bit VQ's expected quantization error.

Direct I/O engages on the real container. No page cache not bypassed note in any
bench run, including a 6-configuration sweep where it was explicitly counted. Confirms
#3's result on an 18 GB container rather than a synthetic one.

convert.py works end to end. The spawn worker pool (3 processes), sharded
safetensors reading, VQ3R encode, 4 KiB-aligned bank writing (682,622,976 B = 651 MiB
exactly), trunk quantization, tokenizer/specials/chat-template emission, manifest
publish. Resume works — a re-run marks finished layers [cached]. 26 MoE layers total, of
which this run converted 24 in ~94 minutes at --jobs 3 (two were already done from an
earlier --layers 1,2 trial). No POSIX path assumption surfaced anywhere in it.

The serve suite passes all 168 checks.

---

Gap 1 — check_budget.sh cannot measure RSS on Windows, and reports FAIL

This is the single failure in the 32/1/9 run.

$ tests/check_budget.sh /path/to/kimi-linear.waste
ModuleNotFoundError: No module named 'resource'
could not read peak RSS
=== check_budget exit=1 ===

resource is Unix-only. $RSS comes back empty, the script exits 1, and run.sh:797
greps for ^BUDGET OK and falls through to no "peak RSS exceeded the budget".

The budget was never measured. The reported overrun is a false negative — and more
importantly, whether the engine honours waste_cfg.ram_budget_bytes on Windows is
currently untested. For an engine whose stated premise is that the budget is a hard
ceiling rather than a hint, that seems worth closing.

This is a sibling of gap 4 in #3 (os.sysconf in the default-budget check), which you
fixed. It survived because the check needs a container and no CI job has one — without
one it skips as "needs a tokenizer to drive the CLI", on every platform.

Polling Process.PeakWorkingSet64 externally suggests the engine does stay inside its
ceiling: 7.81 GB peak against an 8G budget, and never above 9.71 GB at any budget
up to 60G. Corroboration rather than a substitute — different prompt and budget, and
working set is not exactly ru_maxrss.

Suggested: distinguish "could not measure" from "exceeded", and SKIP the former with its
reason. run.sh's own header says a missing prerequisite "says SKIP, loudly" and is
"never treated as a pass"; it should equally never be treated as a failure.

Gap 2 — fetch_weights.sh resume never matches on Windows (CRLF)

Re-running against a fully downloaded directory:

shards        : 0 / 20 complete
already here  :      0.0 GB
FATAL: need ~96 GB with margin, only 73 GB free

All 20 shards on disk and listed in .download-state. The check (L180 on main) is
grep -qxF "$f" "$STATE", and the two files disagree on line endings:

.shards          ...s a f e t e n s o r s  \r  \n
.download-state  ...s a f e t e n s o r s  \n

.shards is generated by a python3 heredoc; MSYS2's python3 is a Windows build whose
stdout does text-mode \n -> \r\n translation. .download-state is appended by bash.
So have stays 0 and nothing is ever recognised as complete.

Everything the header promises about surviving a long haul is inert on Windows: an
interrupted K3 pull re-fetches from zero, or refuses to start on a bogus free-space
calculation. The first run looks perfect, which is what makes it easy to miss.

Suggested: strip CR when generating or reading .shards.

Gap 3 — the oracle fixture's provenance check misses the --device axis

tests/run.sh:557 gates on trunk alone. The sidecar records
"trunk": "Q4G/Q8G/F32", and a default convert.py run on a CPU-only machine also
produces Q4G/Q8G/F32 — so the check passes and the diff runs against a fixture whose
sidecar also says "converted_on": "macOS arm64, --device mps".

engine vs fresh oracle (this container, device=cpu)    max|diff| = 4.29153e-05  PASS
engine vs shipped fixture (macOS arm64, device=mps)    max|diff| = 2.77152      FAIL
fresh oracle vs shipped fixture                        max|diff| = 2.77151      FAIL

Lines 2 and 3 agree to 1e-05 — the PyTorch reference computed from the same container
diverges from the fixture by the same amount the engine does, so the engine contributes
essentially none of it. That is the signature the sidecar itself records for #7: "a fresh
oracle diverged from that fixture by exactly the amount the engine did."

The comment beside the check already notes that --device changes the codebooks. So this
is #7 recurring on a second axis, and it is not Windows-specific: anyone without uv
and without MPS meets it, which per the CLAUDE.md note about Linux skipping more for
having no uv in Dockerfile.test includes that path.

Suggested: record --device, or a codebook hash, in the sidecar and check it alongside
trunk; or skip unless every conversion parameter matches, since the sidecar already says
the fixture "is only comparable against a container quantized the way this one was".

Gap 4 — tools/diskbench.c does not build on Windows, and would report a false bypass

$ cc -O2 -o diskbench tools/diskbench.c
error: implicit declaration of function 'posix_memalign'
error: implicit declaration of function 'pread'; did you mean 'fread'?
error: implicit declaration of function 'fsync'

So there is no way to get the storage denominator on Windows at all. There is also no
Makefile rule and no CI step for it on any platform, so nothing would have caught this.

Worse than not building: there is no _WIN32 branch anywhere in the file, and both
assignments that clear g_direct (L106, L114) sit inside the __linux__ and __APPLE__
blocks. Control would reach the plain buffered open() at L108 with g_direct still 1,
so bypass_note() would print cache bypassed over page-cache numbers.

The file's own comments describe exactly this outcome — L12, L88, and the #22 note at
L45-48 about a Gen3 x4 drive benching at 44 GB/s against a 3.9 GB/s link. 0.6.6 fixed
that class for Linux.

The engine is unaffected: src/platform.h:293 uses CreateFileA with
FILE_FLAG_NO_BUFFERING and bank_open confirms with a transfer. Only the standalone
tool reimplements the I/O layer in raw POSIX.

Suggested: include platform.h and use waste_pread / waste_aligned_alloc /
waste_open_stream, and clear g_direct on the non-bypass path unconditionally.

Gap 5 — WASTE_MLOCK wires nothing on Windows

The README raises this as an open question. Answer: not a single page.

waste: could not wire 5928 of 5928 cache slots; those stay pageable
waste: wired 0.00 GB of trunk (some buffers were refused)

On a machine with 54 GB free and nothing paging. src/ecache.c:104 is
VirtualLock(p, n), which is bounded by the process maximum working set rather than
by available memory. The default limit is far below a 14.72 GB cache, so calls beyond it
fail with ERROR_WORKING_SET_QUOTA. SetProcessWorkingSetSize has to raise it first —
the POSIX mlock branch has no equivalent requirement, which is why the port works
everywhere else.

It reports the failure honestly, so nothing is silently wrong. It is not quite a no-op
either — 5928 failed syscalls are still issued and paid for — though the cost I measured
sits inside this machine's run-to-run noise, so I would not put a figure on it.

Suggested: raise the working set before the first VirtualLock and fall back cleanly if
refused; or detect the quota up front and skip with one line rather than issuing thousands
of calls that cannot succeed.

Minor

• No timeout around the five uv run calls in run.sh. Absent uv, they skip
  cleanly. A uv that is present but non-functional hangs the suite indefinitely instead
  of failing. That happened here — the MSYS2 package mingw-w64-ucrt-x86_64-uv 0.12.1
  (x86_64-pc-windows-gnu) opens no TCP sockets at all, five processes and zero
  connections. The packaging is not your problem; the missing timeout is.

• run.sh:261 names the wrong cause. SKIP container round-trip — source weights not at $SRC fires when the weights are present but uv is not, since the condition is
  [ -d "$SRC" ] && command -v uv. Running verify_container.py directly under a plain
  torch interpreter passes.

---

Measurements

Sustained generation ~5.6 tok/s at 97% hit (waste run -n 400: 5.63 / 5.60 / 5.52),
roughly 1.7x off the README's M5 Pro figure on a 2019 six-core.

The deterministic results are the useful ones — hit rate and bytes read carry no noise,
since routing is fixed. The expert cache saturates at ~16G and the budget is inert
above it:

budget	cache	hit	disk read
2G	737 MB	67.0%	83.54 GB
8G	6.72 GB	89.2%	19.07 GB
16G	14.72 GB	92.7%	11.60 GB
32G-60G	up to 58.72 GB	92.7%	11.60 GB

Three things follow:

• No cliff is reachable with this model. The cache allocates lazily — a 30.72 GB
  cache commits 9.71 GB of working set — and a 16.9 GB expert set cannot fill a 58 GB
  cache. LEARNED's 58-vs-46 GB result needs a container big enough to fill it.
• An explicit --budget bypassed the 7/8-of-physical ceiling on v0.6.6. v0.6.7
  lowered that ceiling for automatic selection (§57); whether an explicit budget is now
  bounded too, I have not retested. On v0.6.6, --budget 60G was
  accepted on a 63.9 GB machine, producing a 58.72 GB cache; the guard governs automatic
  selection only. Inert here because nothing commits, but on a container large enough to
  fill it that is the route into the documented cliff.
• Storage is not the limit here. 4G reads 46.76 GB against 16G's 11.60 GB — four
  times the traffic — for indistinguishable throughput.

WASTE_Q8=0 is roughly 2x slower (2.67 vs 5.16 tok/s; 2.39 vs 4.98 at a lower memory
clock). An f32 trunk costs ~8 GB instead of ~988 MB and removes per-token dequantization,
but streams 8x the bytes per token. On this machine the 4-bit trunk is a speedup, not
merely a footprint saving. Incidentally this confirms #6's fix holds — WASTE_Q8=0 loads
a Q4G trunk without complaint now.

WASTE_XPAR=1 helps by less than the published figure, and I would not quote the
magnitude tightly. Four runs each at --budget 16G -n 200:

configuration	runs	mean
no WASTE_XPAR	4.88, 5.04, 5.08, 5.03	5.008 tok/s
WASTE_XPAR=1	5.18, 5.18, 5.15, 5.14	5.163 tok/s

The groups do not overlap (p ≈ 0.014 for 4 vs 4), so the direction is sound. The size is
not: +3.1% is smaller than the baseline arm's own 4.0% spread, and falls to +2.2% without
the low run. Call it +2 to +3% against a documented 1.18-1.24x. Six Zen 2 cores may
have less to gain from one-task-per-routed-expert; this run cannot say more than that.

This may be of use to #32, which notes that §47's tuning table is an ARM result and
that no non-emulated x86 machine is available to retest it. Two caveats before it is read
that way: this container is VQ3R, not the VQ4P path #32 is about, and the figure is a
bound rather than a point.

waste bench understates steady state. Misses are near-constant in absolute terms
(1379-2487 across 64-358 token runs) because they are compulsory, so a short window is
mostly cold-start: -n 200 reports 92.7% hit where sustained generation reaches 97%.

On method, since it cost me two discarded sets of figures: total CPU load is useless as a
contention guard because the benchmark saturates every core. Snapshotting per-process CPU
before and after each run and summing the delta for everything that is not waste.exe
works. The tell for a bad batch was variance, not the mean — spread jumping to 7-10%.

---

Offer

Happy to test patches for any of the above — this machine has the container, the source
weights and the UCRT64 toolchain set up, so re-running is cheap. Raw logs available for
everything here.

—

Reported by Kirin.

🤖 Built, measured and triaged with Claude Code.