# K3 Rental Test — Prep Report (2026-08-25)

Offline preparation for `k3-rental-test-plan.md` §3 pre-flight. **Verdict: ready to
rent, with two deltas to internalize first (§3 below).**

## 1. Pre-flight checklist — verified

| Plan §3 item | Status | Evidence |
|---|---|---|
| K3 artifacts downloadable | ✅ direct GGUF path, no conversion phase | [unsloth/Kimi-K3-GGUF](https://huggingface.co/unsloth/Kimi-K3-GGUF): **UD-Q4_K_XL = 32 shards, 1508.7 GB** (~49 GB/shard), matching the plan's 1.5 TB assumption. Also IQ1_S 594 GB / IQ2_XXS 711 GB / Q8_K_XL 1560 GB (=lossless). Optional `mmproj-BF16.gguf` for vision. Official weights: [moonshotai/Kimi-K3](https://huggingface.co/moonshotai/Kimi-K3). |
| Runtime KDA support | ✅ llama.cpp **mainline** | [PR #26185 "model: add Kimi-K3 text model"](https://github.com/ggml-org/llama.cpp/pull/26185) merged 2026-08-15, first released in [b10448](https://github.com/ggml-org/llama.cpp/releases/tag/b10448). KDA + Gated-MLA + AttnRes + latent-MoE + SiTU all implemented; MXFP4 experts repacked **losslessly** (no dequant→BF16 hours). Vision needs [unsloth fork PR #48](https://github.com/unslothai/llama.cpp/pull/48) — text-only plan ⇒ mainline OK. Pinned in `config.env`: `d222767` (2026-08-25 master). |
| Smoke model staged | ✅ | [Qwen/Qwen3-30B-A3B-GGUF](https://huggingface.co/Qwen/Qwen3-30B-A3B-GGUF) `Q4_K_M` (~18.6 GB). |
| Scripts repo | ✅ | `k3-test/` — see README. `bash -n` clean; flags verified against pinned source. |
| Plan + review HTML accessible | ✅ | in `/Users/danielleensign/prog/chat/` — rsync with the repo. |
| Rental offers live | ❌ can't verify offline | Vast offer IDs are ephemeral & need an API key — **day-of check via the web console** (§4 below). |

### Flags verified in llama.cpp source @ d222767
`--cpu-moe` (`-cmoe`), `--n-cpu-moe N` (`-ncmoe`), `-ot "<regex>=<buffer>"` (**first
matching pattern wins**; buffer names `CPU`, `CUDA0..3`), `--numa distribute`,
`--load-mode mmap|mlock|dio|none`, prompt-lookup spec via `--lookup-cache-static /
--lookup-cache-dynamic`, `--single-turn`, `--no-conversation`.
Expert tensor naming confirmed in `src/llama-arch.cpp`:
`blk.N.ffn_{gate,up,down}_exps.weight` — the pattern `.ffn_(up|gate|down)_exps.=CPU`
is exactly what `--cpu-moe` injects internally.

### config.json (replaces plan's estimates)
93 layers = 69 KDA + 24 Gated-MLA (full-attn layers 4,8,…,92,93); hidden 7168;
96 heads; MLA kv_lora_rank 512, q_lora_rank 1536; **896 routed experts** (moe_ff 3072,
latent-compressed) + 2 shared; vocab 163840; ctx 1 048 576; AttnRes block size 12;
KDA gate_lower_bound −5.0.

## 2. Budget re-check
Q4 download at the box's measured 6.4 Gbps ≈ **32–39 min ≈ $1.30** @ $2.278/hr — on plan.
Disk need 1508.7 + 18.6 + logs ≈ 1.56 TB < 2.74 TB — fine with the plan's headroom.

## 3. ⚠ Two deltas from the plan to internalize BEFORE renting

**(a) Trunk VRAM reality.** UD-Q4_K_XL keeps the dense trunk mostly **Q8_0** (Unsloth:
"the remaining tensors … are Q8_0"). Dense trunk ≈ 56B params ⇒ **~55–60 GB**, which
**does not fit 2×24 GB**. On the rental the default is trunk split across **3 GPUs**
(`TSPLIT=1,1,1`, leaving GPU 3 for E6), with E0b/E0c measuring the 2-GPU / 1-GPU
CPU-spill penalty. On the **home build (1×3090)** the trunk cannot be VRAM-resident at
all: ~35 GB of trunk lives in RAM and is re-read every token (CPU side total then
~50–60 GB/token ⇒ ~2.5–3.5 tok/s at 150–180 GB/s, *below* the plan's 5–6 prediction),
unless the trunk is separately re-quantized (Q4 trunk ≈ 29 GB — still >24 GB; Q3
borderline). **The rental test must quantify this spill penalty (E0) — it is now the
home build's central unknown.**

**(b) "RAM-resident" is physically impossible on the rental** (1508.7 GB model vs
~612 GB RAM+VRAM) — but that's fine: mmap page-cache streaming **is** the
reference-4-bit-streaming architecture. The experiments map plan-terms onto kernel
reality:
- E1 "experts fully RAM-resident" → E1b **warm page cache** (hot set resident); E1a
  cold = SSD streaming for the same workload. The pair measures plan E1+E2.
- E3 "prefetch OFF" → `--load-mode dio` (every expert read hits NVMe — no llama.cpp
  expert-prefetch engine exists; readahead knob `read_ahead_kb 128→4096` is E2's "ON").
- E4 cache-size sweep → **RAM filler** (`/dev/shm`) shrinks effective page cache to
  emulate 200/320/450-expert hot sets.
- E8: llama.cpp has **no router top-k override** for kimi-k3 @ d222767 — script probes
  and logs UNSUPPORTED rather than failing. (Can patch `llm-graph` if it matters —
  ~5 lines; decide on-box.)
- Hot-set arithmetic: expert mass ≈ 1449 GB ÷ 896 ≈ **1.6 GB/expert** ⇒ ~490 GB usable
  RAM caches **~300 experts**, slightly under the plan's 320–360. E4 measures the knee
  directly, so plan §6's hit-rate criteria still apply.

## 4. Day-of-rental checklist (cannot be done offline)

1. Open vast.ai console → verify offer **#18138411** live; else fallbacks in plan §2
   (#43104468 → #12239073). Reject anything <1 Gbps down.
2. `rsync -a k3-test/ root@box: && ssh`, `tmux new -s k3`, `./run_all.sh`.
3. Watch download rate for 15 min (`tail -f logs/download_k3.log`);
   <2 Gbps effective ⇒ kill, re-rent #43104468 (plan §7).
4. After experiments: `./30_teardown.sh`, pull tarball off-box (7.6 Gbps up),
   **destroy instance in the console**.

## 5. Sources
- llama.cpp K3 model support: <https://github.com/ggml-org/llama.cpp/commit/ad1de39e0708e3ced9c71bb3c82d93a2c046a73f>
- Release b10448: <https://github.com/ggml-org/llama.cpp/releases/tag/b10448>
- Unsloth GGUF repo + sizes: <https://huggingface.co/unsloth/Kimi-K3-GGUF>
- Unsloth run guide (quant table, fork note): <https://unsloth.ai/docs/models/kimi-k3>
- Official repo: <https://huggingface.co/moonshotai/Kimi-K3> / <https://github.com/MoonshotAI/Kimi-K3>
- K3 tech report: arXiv:2607.24653 · NeMo arch notes: <https://docs.nvidia.com/nemo/automodel/model-coverage/large-language-models/moonshotai/kimi-k3>