An SSD can copy the first part of a large file at high speed, then settle at a much lower rate even though nothing else appears to have changed. That drop can be normal. Many consumer SSDs use part of their NAND as a fast write cache, allowing short bursts to finish before the drive has to sustain writes in its denser storage mode.
This behavior makes a single peak transfer number a poor description of every write workload. Cache size, free space, NAND type, controller policy, temperature, and the amount of data already waiting inside the drive can all affect the speed seen during a long transfer.
Fast writes can use a simpler flash state
NAND flash stores information by placing cells into distinguishable electrical states. A cell used in single-level-cell mode represents one bit with two states. Denser modes represent more bits per cell and require more states, which makes programming data more involved.
Many SSDs built with multi-bit NAND reserve or dynamically operate some flash in a single-bit mode. This area is commonly described as an SLC cache or pseudo-SLC cache. Incoming writes can land there first because programming the simpler state is comparatively quick.
The cache is not necessarily a separate physical type of flash. On many drives it is capacity from the same NAND operated temporarily in a lower-density mode. The controller later moves or folds cached data into the drive’s normal storage format.
That background work consumes NAND and controller resources, so the apparent speed of a transfer depends partly on whether the drive has room to absorb new data faster than it can reorganize older cached data.
Short benchmarks often stay inside the cache
A small write test may finish entirely within the fast cache. In that case, its result describes burst performance rather than the rate the SSD can maintain across a much larger amount of data.
A long sequential write can expose a different phase. Once incoming data consumes the available cache faster than the controller can reclaim it, new writes must proceed closer to the native programming rate of the underlying NAND. The displayed transfer speed can then fall sharply or decline in stages.
The exact pattern varies. Some controllers use a fixed cache, some vary cache capacity with available free space, and some combine multiple caching strategies. Firmware can also change when data is moved out of the cache and how aggressively background work runs.
For that reason, two SSDs with similar peak specifications can behave differently during a transfer that lasts several minutes.
Free space can change the available burst area
Dynamic caching often borrows unused NAND capacity. A relatively empty drive can therefore have more room available for fast single-bit operation than the same drive when it is nearly full.
The relationship is not a simple percentage that applies to every SSD. Controllers reserve spare area, manage flash translation tables, perform garbage collection, and follow firmware-specific policies. Some products publish cache behavior, while others provide little detail.
Still, a drive that performs long writes differently at different fill levels is not necessarily malfunctioning. Reduced free space can leave the controller with fewer convenient locations for incoming data and less flexibility for internal relocation.
This is also separate from the file system’s free-space display. The SSD controller manages physical NAND behind its logical block interface, so host-visible capacity does not expose every internal allocation decision.
Cache recovery takes time after a heavy write
Finishing a large copy does not guarantee that the SSD is immediately back to its fastest burst state. Cached data may still need to be converted or relocated into denser NAND storage.
During idle periods, firmware can perform that work and restore cache capacity. If another large write begins immediately, less fast cache may be ready, so the second transfer can slow earlier than the first.
Heavy background activity can produce a similar effect. Operating-system writes, application caches, downloads, virtual machines, and other storage traffic all compete for the same device resources. A benchmark run on an otherwise quiet drive can therefore look different from a real workload that keeps issuing writes.
Temperature can add another limit
Sustained writes keep the controller and NAND active. If an SSD reaches its thermal control threshold, firmware can reduce activity to keep temperature within its operating range. That creates a separate source of slowdown from cache exhaustion.
The two effects can occur in the same transfer. A drive may first leave its fast cache and later reduce throughput further as temperature rises, or thermal control may appear before the cache is fully consumed. The sequence depends on the hardware, cooling, ambient conditions, and workload.
A heatsink can help an SSD that is actually temperature-limited, but it does not increase the native programming rate of the NAND or make a finite cache unlimited. Cooling and caching address different constraints.
Sustained speed needs a sustained test
Peak write speed remains useful for workloads that fit within the drive’s fast path. Many everyday writes are small enough that cache behavior makes the system feel responsive, and the controller can reorganize data later.
Large media exports, disk images, local backups, and other continuous writes can cross that boundary. For those workloads, the useful figure is the rate maintained after the initial cache has been consumed, along with the conditions under which the test was performed.
A fair comparison also needs similar drive fill, temperature, transfer size, and source speed. If the source device cannot provide data fast enough, the destination SSD’s cache boundary may never become visible.
The changing transfer graph is therefore part of the storage design rather than a contradiction in the specification. Burst speed describes the fast intake phase; sustained speed shows what the SSD can continue delivering once caching, NAND programming, background relocation, and thermal limits all become part of the workload.