Upload README.md with huggingface_hub

README.md

@@ -184,7 +184,61 @@ Caveats, stated plainly:
 - The Hub checkpoint stores float32 weights and the harness ran it at `bfloat16` (see §5.2).
   The two agree to within 0.002 on every task listed, so precision is not driving the table.
 
-### 4.4 Effect of the P0 revision
+### 4.4 Inference cost and speed (RTX 4090D, bfloat16)
+
+Measured with the project's own `scripts/bench_resources.py` on the card that trained the model
+(RTX 4090D 24 GB, no other process on it), bfloat16, `torch.no_grad()`, greedy decoding of 64
+tokens after a prefill of 1,024 / 2,048 / 4,096 tokens, identical script for both models.
+
+**The checkpoint exactly as shipped** (`ssa_force_full_window: true` — see below), 1,024-token
+prefill:
+
+| Metric | Qwen3-0.6B-Base | BaiHu-V1-Flash |
+|---|---|---|
+| Parameters (M) | 596.0 | 598.8 |
+| Peak memory, prefill (GB) | 1.63 | **1.52** |
+| Peak memory, generate (GB) | 1.78 | 2.01 |
+| Prefill latency = TTFT (s) | 0.025 | 1.48 |
+| TPOT — time per output token (ms) | 17.3 | 68.4 |
+| Decode throughput (tok/s) | 57.8 | 14.6 |
+| Attention FLOPs per token (GFLOPs) | 0.118 | 0.202 |
+| Attention keys read per query (vs full attention) | 1.00× | 1.72× |
+| GPU utilization mean (%) / power mean (W) | 15.5 / 69.8 | 20.0 / 69.0 |
+
+How both quantities scale with context (same run, every cell in the order *base → ours*):
+
+| Prefill | TTFT (ms) | TPOT (ms) | Decode (tok/s) | Keys read per query | Generate peak (GB) |
+|---|---|---|---|---|---|
+| 1,024 | 25 → 1,477 | 17.3 → 68.4 | 57.8 → 14.6 | 1.00× → 1.72× | 1.78 → 2.01 |
+| 2,048 | 39 → 2,113 | 19.8 → 78.7 | 50.4 → 12.7 | 1.00× → 1.45× | 2.35 → 2.82 |
+| 4,096 | 72 → 3,610 | 21.4 → 108.8 | 46.7 → 9.2 | 1.00× → 1.24× | 3.53 → 4.43 |
+
+Stated plainly:
+
+- **There is no speed advantage at any length tested.** Prefill (TTFT) is 50–59× slower in
+  wall-clock — 1.48 s vs 25 ms at 1 K — decode is 3.9× slower at 1 K and 5.1× at 4 K, and peak
+  memory is comparable (slightly *lower* for this model during prefill, slightly higher during
+  generation).
+- **The sparse path is not actually saving anything here.** This checkpoint is trained *and
+  released* with `ssa_force_full_window: true`: the dense local window always covers the entire
+  causal prefix, so the shared and sparse paths are **additive on top of full attention** instead
+  of replacing part of it. Hence keys read per query above 1.00×.
+- **Read the 1.72× honestly.** It is the measured cost of the shipped configuration, and it is
+  also why the model spends more attention FLOPs per token than the dense base (0.202 vs 0.118
+  GFLOPs at 1 K) while still being far slower in wall-clock. Sparsity only starts to bite once
+  `top_k × block_size` is small relative to the context (see the next point).
+- **Turning the window shrinkage on is a flag, not a retrain** — but it was never validated in
+  that mode, because the weights were trained with the window forced open. For reference, with
+  `ssa_force_full_window=false` the same weights read **0.90× / 0.54× / 0.29×** as many keys at
+  1 K / 2 K / 4 K and decode at 20.7 / 18.5 / 14.8 tok/s. Even then it stays **2.5–3.2× slower**
+  than the dense base, and quality in that mode is **unevaluated** — treat the numbers as the
+  architecture's ceiling on this implementation, not as a free win.
+- What follows from this is an implementation item, not an architecture one: the per-block Python
+  loop in the SSA layer issues many small kernels, so launch overhead dominates the arithmetic
+  saved (GPU utilization never exceeds ~28%). The sparse path has to be fused before any of this
+  can pay off on real hardware.
+
+### 4.5 Effect of the P0 revision
 
 Measured with the same data, recipe and seed, P0 vs the old single-vector shared branch:
 
@@ -278,11 +332,15 @@ above, loads them at **1.20 GB** and leaves the (float32) rotary tables untouche
    (reuse the earlier rule/format, answer directly), not new reasoning ability.
 2. **The shared branch is still barely used** (gate ≈ 0.0101 after SFT, same as the old
    revision). Whether P0 pays off can only be decided in a long-context / window-shrink regime.
-3. **Trained on synthetic dialogues.** The 1,294 conversations are model-generated; style and
+3. **No inference speedup — in fact a slowdown.** As shipped, the model is 3.9–5.1× slower to
+   decode and ~50× slower to prefill than the dense base, and reads *more* attention keys,
+   because the released configuration forces the dense window open (see §4.4). Use it to study
+   the architecture, not to serve traffic.
+4. **Trained on synthetic dialogues.** The 1,294 conversations are model-generated; style and
    coverage are limited to the six transfer kinds and the topics they cover. Evaluation above
    is on a held-out slice of the same distribution — not a general capability claim.
-4. **Custom architecture, no llama.cpp/GGUF support** (SSA attention is not implemented there).
-5. **Not an instruct model at large.** It is a 0.6B research model; expect terse answers and
+5. **Custom architecture, no llama.cpp/GGUF support** (SSA attention is not implemented there).
+6. **Not an instruct model at large.** It is a 0.6B research model; expect terse answers and
    occasional arithmetic slips.
 
 ## 7. License