Upload FINDINGS.md with huggingface_hub

FINDINGS.md

@@ -18,7 +18,29 @@ Numbers without a measurement behind them are marked as estimates.
 Prefill never exceeding decode by much is the tell: this deployment is not
 compute-bound on the GPU, it is dominated by whatever runs on the host.
 
-## Bottom line: throughput is invariant, and we do not know why
+## The answer: host vCPU, not VRAM
+
+The same configuration, on the same model, using the same two GPUs — three
+further GPUs sitting idle at 267 MiB — runs at **1.9× the speed** on a bigger
+host:
+
+| Pod | GPUs | vCPU | RAM | decode |
+|---|---|---|---|---|
+| `cumv30dk07dfdy` | 2× A40 | **16** | 93 GB | 2.31 / 2.98 / 2.88 |
+| `okinf3ln9k8tsp` | 5× A40 | **41** | 234 GB | 4.86 / 5.28 / 5.44 / 5.64 |
+
+Prefill moves even harder: 0.99 → 8.01 tok/s.
+
+RunPod scales vCPU with GPU count, so renting more GPUs buys host parallelism as
+much as it buys VRAM. Every placement experiment below kept 70–90 GB of weights
+being processed by 16 saturated threads, which is why moving that work between
+CPU and GPU changed nothing: the CPU side was the wall in all of them.
+
+This is the mechanism the section below says was missing. It was found by
+accident — a 5-GPU pod picked up the 2-GPU placement script before the guard
+was published, and ran the *identical* configuration on a larger host.
+
+## Why the placement experiments all looked the same
 
 ~3 tok/s is the ceiling for this model on 2× A40, and the reason is not the one
 that seems obvious.