Reduzierung der Schreibverstärkung in QLC-SSDs

AI training, checkpointing, and data ingest push QLC SSDs harder than ever, and smarter firmware is how you keep endurance and performance on track.

Quad-level cell (QLC) SSDs have become the go-to choice for high-capacity storage in AI data centers. A single drive can now hold more than 245 TB. That makes QLC hard to ignore when you’re building a data lake or a training cluster that needs petabytes sitting close to the GPUs. There’s a catch that doesn’t show up on the capacity line of a spec sheet, though, and it’s called write amplification. 

That’s why reducing write amplification in QLC SSDs has moved off the firmware team’s whiteboard and into conversations about endurance, performance, and total cost of ownership. Here’s what causes it, why AI makes it worse, and what you can do about it. 

What write amplification is, and why QLC is more prone to it

Write amplification compares the amount of data a host writes with the amount the SSD actually writes to NAND once garbage collection and wear leveling are counted. If your application writes 1 GB and the drive ends up writing 3 GB to flash, you have a write amplification factor (WAF) of 3. Under random or fragmented I/O, QLC SSDs tend to see higher write amplification than TLC. That matters more now than it used to. AI training, checkpointing, and data ingest produce constant, often randomized writes, which are much harder on QLC than the sequential, read-heavy work it was first built for. 

The gap between host writes and NAND writes comes from how flash works. Every SSD writes data in pages and erases it in much larger blocks. When data changes, the drive can’t overwrite it in place. It writes the new version somewhere else and marks the old copy invalid. Sooner or later the drive has to reclaim that space by copying the still-valid pages out of a block and then erasing the block. That cleanup is called garbage collection, and every page it moves is an extra write the host never asked for. On most drives, garbage collection is the biggest source of write amplification. 

QLC stores four bits per cell. That’s great for density and harder on a few other fronts. QLC blocks are larger, so a block holding a mix of hot and cold data can contain a lot of valid pages that need relocating. High-capacity drives also tend to track data in bigger chunks to keep DRAM requirements reasonable. A small random write can force the drive to read, modify, and rewrite one of those larger units. And many QLC drives stage incoming data in an SLC cache before moving it into QLC, which adds one more round of writes. 

Then there’s endurance. QLC cells handle fewer program/erase cycles than TLC cells. A WAF of 4 on a TLC drive is annoying. On QLC it can use up the drive’s rated life much faster than the host write numbers would suggest.  

Why AI workloads make this worse

When QLC first moved into the enterprise, it mostly handled read-heavy, sequential jobs like archives, content libraries, and backup targets. Data went in once as large streams and was read many times after that. Write amplification stayed low because big sequential writes fill blocks with data that ages together and gets deleted together. 

AI pipelines behave very differently. Ingest brings in a steady flow of files of every size from many sources at once. Training jobs shuffle and preprocess data and write intermediate results and logs, all while reading heavily. Checkpointing saves model state on a schedule, and older checkpoints get deleted as new ones arrive. Run several of these on the same drive, or let multiple jobs share a storage pool, and the incoming writes get interleaved. Data with very different lifetimes ends up packed into the same NAND blocks. 

For garbage collection, that’s the worst case. When a checkpoint is deleted, its pages are scattered across many blocks that still hold live data. The drive has to move all of that live data before it can erase anything. As a result, the write amplification factor for AI workloads can climb well above what the same drive would see in a traditional read-heavy deployment. 

The cost shows up in three places. 

• Endurance. A higher WAF burns through the drive’s program/erase budget faster and shortens its useful life. 

• Performance consistency. Garbage collection competes with host I/O, so latency spikes while the drive is busy cleaning up. Unpredictable tail latency can leave GPUs waiting on data. 

• Cost. Drives that wear out early, or that need extra overprovisioning to stay healthy, raise the real cost per usable terabyte. 

How controller intelligence and firmware reduce write amplification

The good news is that most write amplification comes from how a drive decides where to put data. The controller and its firmware make those decisions, so better decisions there produce measurable results. 

Workload-aware data placement, or flexible data placement approaches 

The most effective approach is to keep data with similar lifetimes together. If everything in a block tends to become invalid at about the same time, garbage collection finds blocks that are mostly or completely empty and has very little to copy. 

Workload-aware data placement can happen inside the SSD, with firmware detecting hot and cold data and sending each to different blocks. It can also be shared with the host. Flexible Data Placement (FDP), part of the NVMe specification, lets the host tag each write with a placement handle. The SSD then routes related data, such as a single checkpoint or one ingest stream, into its own set of blocks. The host knows which data belongs together, and the drive knows how to lay it out on NAND. FDP is also backward-compatible, so applications that don’t use it keep working normally. 

Smarter garbage collection and wear-leveling strategies 

Firmware decides when garbage collection runs, which blocks it cleans, and how much work it does at once. Good policies choose the blocks with the fewest valid pages, clean up in the background before free space gets tight, and pace the work so host latency stays steady. Wear leveling spreads program/erase cycles evenly across the NAND, and a smart implementation does that without moving cold data more often than necessary. Firmware also controls how the SLC cache is sized and flushed and how the drive handles small writes that don’t line up with its internal mapping. 

Why this is increasingly a strategic concern

Write amplification sounds like a low-level detail. In practice it feeds directly into the economics of QLC NAND in enterprise storage. QLC’s appeal is a lower cost per terabyte and more capacity per rack, which saves power and floor space. That appeal assumes the drives last their planned service life at the endurance you budgeted for. If the real-world WAF of your AI workloads runs three or four times higher than you expected, you’ll end up replacing drives sooner, overprovisioning more capacity, or moving write-heavy jobs back onto more expensive TLC. Any of those eats into the savings that made QLC attractive in the first place. 

If you’re evaluating QLC SSD endurance for AI, ask vendors a few direct questions: 

• What DWPD rating does the drive carry, and what workload assumptions was it measured under? 

• Does the drive support FDP or another placement mechanism, and does it work with our software stack? 

• How does the firmware handle small random writes and mixed read/write traffic? 

• What happens to latency during sustained garbage collection? 

• Who writes the firmware, and can it be tuned for our workloads? 

How Pascari drives support QLC endurance 

Phison designs its own NAND controllers and writes its own firmware. That gives Phison’s engineers room to tune data placement, garbage collection, and wear leveling as a single system for the mixed, high-volume I/O that AI training and checkpointing produce. Controller and firmware are developed side by side, so endurance management is built into how the drive works from the start.  

You can see the results in the published endurance specs of our Pascari-Portfolio an Enterprise-SSDs. The Pascari D-Series D206V, for instance, fits 245.76 TB of 3D QLC NAND into a single U.2 drive and is rated at 0.3 drive writes per day (DWPD). On a drive that size, that works out to about 74 TB of writes every day for the drive’s rated life. That’s a lot of headroom for read-intensive AI data lakes and training datasets.  

Get more out of your drives

QLC will keep growing in AI infrastructure because the capacity and density math is too good to pass up. Write amplification decides whether that math holds up over years of real use. AI workloads generate exactly the kind of mixed, short-lived writes that push WAF up, so the controller and firmware matter as much as the NAND inside the drive. Reducing write amplification in QLC SSDs comes down to smart data placement, well-tuned garbage collection, and support for host-guided approaches like FDP. 

Entdecken Sie, wie Pascari Enterprise-SSDs combine high-capacity QLC, Phison-designed controllers, and in-house firmware to keep endurance and performance steady under demanding AI workloads. Or, Kontaktieren Sie einen Pascari-Vertriebsmitarbeiter Heute.    

Häufig gestellte Fragen (FAQ):