#3485 [Engine] Measurements for a disk tier under the conversation cache (single GPU, Linux)

Descripción

**What do you want to do?**

Measurements for a disk tier under the conversation cache (parked snapshots spill to SSD when the RAM budget is exceeded; a revisit restores from disk instead of re-reading the prompt). This is data for the roadmap, not a PR — agreeing the scope here first, per the template. The tracker reset note says closed does not mean rejected, so here it is in the open.

Why: the engine runs requests serially, so when the GPU idles waiting on the CPU or the network, a second conversation cannot be served. With a disk tier under the cache, the number of served conversations is roughly `1 + w/g` where `w` is the GPU idle share and `g` is the generation time; the switch cost is what decides whether that is worth building.

Measured on this box (RTX 5090, 64 GB RAM, dedicated 4 TB NVMe, Linux, our 0.1.42 build with the tier-ordered arena; all numbers are ours, measured here):

- switch (restore a parked conversation from disk into the live slot): 1.1–1.7 s; a cold re-read of a 32K prompt at the same time costs 6.6 s, disk recall 7.8 s
- park to disk with async write-back and incremental content-addressed segments (512 KiB, one file per record, compressed): 58 ms for the park call itself
- write volume in steady state: 21.0% of the full state per change (a full-file store cannot get below ~22% on this workload — the block map says the GDN state is 42% of the payload and 92% of writes are growth appends, so a 5% target is not reachable)
- the drive peaks at 1.54M IOPS multi-stream on an empty disk; the numbers above were taken with the root disk under load
- integrity: CRC32C per segment; a validation window on two arms finished with mismatch=0 and byte-identical answers; production has run the spill/restore path since 2026-10-20 (4 spills, 1 restore, accepted)

**What do you do today instead?**

We built it ourselves (Linux/CUDA only, opt-in, off by default for existing installs). Upstream today has the conversation cache in RAM and the session files as an explicit save/restore API; there is no automatic tier between them and no eviction path to disk.