KV Cache on SSDs: Calculate the Write Budget Before the Capacity

I would judge an SSD-backed KV cache by the repeat computation it avoids for each terabyte written, not by capacity alone. If AI services retain more reusable context, I expect admission policy and endurance to matter alongside read speed. That is where I would look for Korean memory suppliers to demonstrate value.

The first calculation is therefore a write budget: how many bytes reach each drive per day, compared with that drive's endurance rating? Capacity tells you how much can remain stored at once. It does not tell you how often that space is rewritten.

Count the bytes at the right boundary

Suppose a server creates KV state for a conversation. Some blocks remain in GPU memory, some may be retained in CPU memory, and some are admitted to an SSD cache. A policy can decline to persist blocks whose expected reuse is too low.

That creates three different quantities: newly generated KV data, host writes sent to the SSD, and physical writes inside its NAND flash. Replication, metadata and retries can increase host traffic. Internal flash management can increase NAND traffic beyond host traffic. Combining those stages into one unexplained “cache size” hides the work the drive actually performs.

Solidigm's platform discussion illustrates why I/O organization matters: its tiering and buffering approach changes the writes reaching QLC storage. That is evidence that software layout matters, not a universal endurance multiplier for another cache engine.

The earlier KV cache calculation guide estimates retained logical state. Here, the missing dimension is time. A cache holding a modest amount of data can receive far more than its capacity over a day if entries churn rapidly.

Conceptual accounting boundaries. Admission, replication and device write amplification must be measured separately; based on Solidigm's endurance and platform documentation.

A small admission decision becomes terabytes per day

Take a hypothetical workload producing 0.20 GB of new, unique KV data per second, averaged across the day. Use decimal units: 1 TB equals 1,000 GB. Assume the SSD admission policy persists 25% of those bytes, once, with no extra metadata, retries or replication.

Daily host writes = new KV rate × admission fraction × 86,400 seconds

The result is 0.20 × 0.25 × 86,400 = 4,320 GB, or 4.32 TB/day. Persisting everything instead produces 17.28 TB/day. These are AI NodeLab teaching assumptions, not measured traffic from a named model.

Policy in the hypothetical workload	Host writes per day
Admit one quarter of new KV bytes	4.32 TB
Admit all new KV bytes	17.28 TB
Admit one quarter, keep two physical copies	8.64 TB across both copies

The last row needs a placement map. If each copy goes to its own dedicated drive, each drive receives 4.32 TB/day; neither individually receives the full 8.64 TB. If both copies share a device, or several cache writers converge on one SSD, that device's budget changes. Count per physical device before comparing ratings.

Admission rate is not cache-hit rate. Saving fewer bytes might preserve useful repeats, or it might discard precisely the data users return to. A defensible policy comparison reports both bytes written and useful work avoided.

Compare daily writes, not DWPD alone

Drive writes per day, or DWPD, expresses a write allowance relative to a drive's capacity under specified conditions. Solidigm's endurance discussion explains why capacity and the rating must be considered together, and relates them to writes over the warranty period.

Consider two invented ratings—not actual product recommendations:

Assumed drive	Assumed rating	Calculated daily allowance
A: 7.68 TB	1 DWPD	7.68 TB/day
B: 15.36 TB	0.5 DWPD	7.68 TB/day

At 4.32 TB/day, the workload uses about 0.563 drive writes per day on A and 0.281 on B. Both fall below their respective assumed allowances. At 17.28 TB/day, both exceed them. The smaller DWPD label did not make B's absolute daily-write allowance smaller.

For a real purchase or deployment, check the exact capacity variant, workload definition, endurance limit and warranty terms. This arithmetic does not guarantee a drive's lifetime, and a rating is not a promise that the hardware fails at a particular byte count.

Keep the comparison at the host-write boundary when the vendor's TBW or PBW rating uses host writes. Do not multiply those same host bytes by a guessed NAND write-amplification factor and compare the result as though it were still host traffic. Instead, check the drive's documented counters and how its rated workload differs from yours.

What this changes about Korea's AI storage story

Solidigm's KV-offload demonstration makes SSD-backed reuse a concrete workload to examine. Its result should be read with the particular software, hardware and requests, rather than applied as a speedup promise to every inference service.

SK hynix's September 2026 SALT-KV demonstration adds a relevant policy angle: the company describes choosing storage tiers using reuse value and storage cost. That announcement supplies a reason to investigate which data gets persisted. It does not supply a public endurance outcome for the hypothetical workload above.

I see that opportunity as conditional. If an admission policy keeps valuable repeats while reducing avoidable writes, NAND, controller software and serving software can complement each other. If most persisted blocks are never reused, growing the cache may buy storage activity rather than a better service. Product adoption and financial results require separate evidence.

Build a write ledger before a longer trial

For the same request trace, record new KV bytes, admitted bytes, per-drive host writes, cache hits that actually avoid computation, and client-visible latency. Include first fills, evictions, restarts and busy periods. Then compare policies with the same model and quality requirements.

Start with the 4.32 TB/day calculation and replace its rate and admission fraction with measured values. Add the traffic the simplified example excluded. Finally, check whether the most heavily written drive—not the fleet average—fits the intended endurance budget.

That produces a useful question for the next storage demonstration: how much repeat computation did each terabyte of host writes avoid? The answer links an SSD specification to the service it is supposed to improve.