ClipProj section: scope the timings to the card they were taken on

README.md

@@ -63,7 +63,7 @@ not ported.
 |---|---|---|
 | `mmh3-turbo-fl2va-q4tp.cmf` | 23.94 GB | **use this one** — text-to-video AND keyframe-to-video |
 | `mmh3-turbo-q4tp.cmf` | 23.47 GB | the same without the vision tower: text-to-video only |
-| `mmh3-turbo-clipproj4b-q4tp.cmf` | **13.16 GB** | text-to-video with a 4B stand-in prompt encoder. Peaks at 15.1 GB of VRAM, so a 20 GB card holds the whole run; 2x faster, and still four bits everywhere. Costs some set dressing — see below |
+| `mmh3-turbo-clipproj4b-q4tp.cmf` | **13.16 GB** | text-to-video with a 4B stand-in prompt encoder. Peaks at 15.1 GB of VRAM, so a 20 GB card holds the whole run instead of paging it; still four bits everywhere. Costs some set dressing — see below |
 | `mmh3-turbo-fl2va-q2tp.cmf` | 18.74 GB | two bits on the gate/up planes. Smaller, faster, and it stops following the prompt — kept for anyone who wants to push on it, not for rendering. See below |
 
 ## Keyframe to video
@@ -280,20 +280,27 @@ that the mechanism is wired right.
 
 ### What it costs
 
-Same prompt, same seed, same four steps, one RTX 3090, both files under
-identical settings:
+The one number that transfers between machines is the **encode stage**, because
+that is the only stage ClipProj replaced. Same prompt, seed and four steps,
+512x288x39, measured inside one run:
 
-| | encode | denoise | video VAE | audio VAE | **total** |
-|---|---|---|---|---|---|
-| `mmh3-turbo-q4tp` | 49.2 s | 116.4 s | 101.9 s | 6.7 s | **281 s** |
-| `mmh3-turbo-clipproj4b-q4tp` | **1.9 s** | 84.5 s | 45.6 s | 5.9 s | **140 s** |
-
-Encoding is 26x faster, which is the part ClipProj actually replaced. The rest
-is residency: 13.16 GB leaves the decoder room on a 24 GB card where 23.47 GB
-does not, and the video VAE more than halves without a line of its own
-changing. On the 20 GB card this variant exists for, that gap is the whole
-point — a reader of this repo measured 20 minutes for one 512x288 clip on an
-RTX 3080 20 GB, paging the encoder in and out of a ~19 GB weight budget.
+| | prompt encode |
+|---|---|
+| `mmh3-turbo-q4tp` — 32B tapped at 50 | 49.2 s |
+| `mmh3-turbo-clipproj4b-q4tp` — 4B tapped at 24 | **1.9 s** |
+
+Everything after that is residency, and residency is a property of YOUR card,
+not of this file. On the 24 GB RTX 3090 these were taken on, the whole render
+came out roughly half the time of the 23.47 GB file and the video VAE decode
+more than halved — but totals on that box drifted between 140 s and 210 s for
+one unchanged configuration as the card warmed, so treat the ratio as a
+direction and measure your own.
+
+The point is the 20 GB card this variant exists for, where the difference is
+not a ratio but a cliff: a reader of this repo measured **20 minutes** for one
+512x288 clip on an RTX 3080 20 GB, paging the 23.47 GB file through a ~19 GB
+weight budget. At 13.16 GB, with a polled whole-run peak of 15.1 GB of VRAM,
+there is nothing left to page.
 
 The parity probe takes the device arm on both files at the same `rel rms
 4.65e-3`, which is its own small proof that the DiT came through untouched.
@@ -319,8 +326,8 @@ plain ground. A 0.92 cosine is close, not equal, and where it is not equal is
 the scene's furniture rather than its subject or its action.
 
 So the ordering is not "smaller is worse". The two-bit file answers a different
-question; this one answers the right question with a plainer set, for 56% of
-the size and half the time. If you have the VRAM for the 32B encoder, use it —
+question; this one answers the right question with a plainer set, at 56% of
+the size. If you have the VRAM for the 32B encoder, use it —
 its framing is richer. If you are paging, this is the better trade, and unlike
 the two-bit build it is a trade rather than a loss.