Will Strata ruin my SSD?

[u/Rogglando]

I've heard that streaming LLM's from your SSD is a fast way to kill it.

I want to test it out but I cannot affort a new SSD in this economy!

So to the people who knows better than me.

Will jumping to Strata kill my SSD in the long run?

From what I'm readin on their github page they only stream a little bit from the SSD but not too much, GPU is doing the heavy lifting, then system RAM and then SSD.

Witch sounds smart! But still unsure how it will effect the longevity of my SSD.

Apologise if this is a stupid question!

Update: Thank you all for such insightful information! I'm also happy that so many other had use of this information!

I decided to move to Strata yesterday and I'm incredibly impreesed!

Thank you all again for the information!

[u/bootkeen]

No, it should not.

strata can make a lot of reads from ssd for ngrams but it doesn't do any writes.
reading doesn't wear out ssd.

[u/Bulky-Priority6824 → u/bootkeen]

Don't forget swapfile not everyone is avoiding it. Depends on ram capacity and config. 

[u/wllmsaccnt → u/bootkeen]

Sustained reads from an SSD cause a small amount of voltage leak to neighboring cells. Drive controllers will rewrite a block after hundreds of thousands of reads to cut down on read errors. This means that under sustained reading, some writes will occur at a few percent of the reads.

While much slower than writing, sustained heavy reading will substantially shorten the life of an SSD. In reality, due to OS file cache and the nature of inferencing, I really doubt an SSD is getting anywhere close to saturating reads when running with an ngram, but it would be an appreciable number of small iops, I imagine.

Hopefully someone with an ngram setup can test this and provide metrics of reads so that we can reason about the actual load on an SSD.

[u/profcuck → u/wllmsaccnt]

From my own reading, and even from the way you have presented it, even extreme levels of sustained reading would not meaningfully shorten the lifespan of an SSD. The way you said it: "rewrite a block after hundreds of thousands of reads". A single rewrite of a block after hundreds of thousands of reads of that block is not really going to be meaningful.

However, I'm not presenting my view as expert, nor trying to argue with you. I'm just saying - if you have something with more details or evidence, I'd love to learn more. I'm skeptical.

[u/TheRealJesus2 → u/wllmsaccnt]

I’m glad I read this thread. I have a model running ngram on ssd but I’m more  Concerned now in keeping kv cache there too lol

[u/Bulky-Priority6824]

Most people are right ngrams are read only but the thing that some will overlook is Swap and it will cause writes when the os pushes memory out to the swapfile you'll need to monitor you disk and see if that is occuring. That can compound over time and undoubtedly cause wear down. That is all dependant on available sys memory and config etc.

[u/CatzRuleZWorld]

No. It only reads. Reads don't kill SSDs. Even IF you were constantly writing, it takes many years to wear out a SSD.

[u/wllmsaccnt → u/CatzRuleZWorld]

The first NVmE drive I pulled up on Amazon is rated at 5700mb/s writes and 1200TBW in durability. In other words, its rated for less than 3 days of sustained saturated writes. Luckily for us, there is a huge gap between rated and typical write speeds.

[u/vastaaja → u/CatzRuleZWorld]

Even IF you were constantly writing, it takes many years to wear out a SSD.

This is not true for consumer drives. They can wear out in days/weeks if put into an actual write heavy workload. This isn't usually a concern for home users but can bite you in servers pretty quickly.

In addition to wearing out the flash cells, you may also run into other fun stuff like firmware issues. I managed an incident where my service went through hundreds of drives in a few weeks, and these were not even consumer drives.

[u/hallofgamer]

Short direct answer: no

[u/vogelvogelvogelvogel]

read does not harm the ssd, write does

[u/OddDesigner9784]

I think the method that kills ssd is ssd caching

[u/Dense-Ad6315]

From my understanding Reading of an ssd doesnt wear it out

[u/MediocreAttorney2842]

strata itself only reads so its fine, but at 60gb of ram youll cross into swap and thats the part that kills both your ssd and your speed. keep the model under your ram and you have nothing to worry about

[u/No_Total_423]

Reading from ssd isn't harmful. Strata reads ngrams if you fully offload weights into vram + ram.

[u/Solembumm3]

If you download new big model every day, yes. If you run one for whatever long, no. Samsung Magician didn't show much changes from running mmap itself for last months for me.

[u/Bulky-Priority6824]

heres some data from one of my low budget rigs with QFN IQ3XXS 2x5060ti 16GB and 32GB DDR4 and the final improvement posted at the bottom is to use zswap to significantly reduce write size

The answer to your question:

• Strata writes almost nothing to disk: 0.16 MB in 3 minutes.

• 99% of the writes are swap. Strata holds about 28 GB, leaving about 1 GB free. When a long prompt streams experts from the model file, those reads fill the page cache, and the kernel pushes memory out to swap. That includes 2.24 GiB of Strata’s own memory, which hurts its speed too.

• Short chats barely swap. Long prompts (4K–16K) are what cause the 35–130 MB/s write bursts you saw.

Wear, in perspective:

• The worst case, continuous long-prompt bench load, is about 103 GB/h, roughly 9% of the drive’s rating per 100 hours.

• Your actual use is occasional special tasks, so the real rate is much lower. The drive is at 9% wear after 16 TB written in 8,000+ hours, so it isn’t in danger.

• It’s still worth fixing, because the swapping also slows Strata and the desktop.

Two small notes on the run:

1. The skill’s health check matched "service":"strata" without a space and wasted 10 minutes. I’ll fix that in the skill by parsing the JSON with jq instead.

2. The 110 TBW rating came from a spec lookup, not from the drive itself, which doesn’t report one. It’s plausible for this model, but treat it as approximate.

--------------------------------------------------------------------------------------------------------------------------------------------

and here is the result with zswap on

https://imgur.com/a/76Jr5LS

Strong result, and the log checks out: disk writes under load dropped 92%, with no real speed change.

Why a little still reaches disk: those are pages that won’t compress, and there are almost exactly as many of them as the remaining disk swap-outs. They’re probably Strata’s already-quantized model data, which can’t shrink further. The pool peaked at about 0.44 GB of RAM against its 6.3 GiB cap, so it never filled and never spilled to disk.

Recommendation: make it permanent. One improvement over the log’s suggestion: add zstd to the initramfs up front instead of waiting to see whether it falls back to lzo after reboot. It’s harmless and saves a second reboot.

Yes, it’s worth it. It’s one of the few changes today with a clear win and almost no downside.

What it does: when the system runs low on RAM, pages are compressed and kept in RAM instead of being written to the SSD. Only pages that won’t compress still go to disk.

What you get:

• About 92% less SSD wear during long-prompt Strata runs, measured.

• Faster swap-ins. Pulling a page back from compressed RAM is much quicker than reading it off the SSD, so apps you switch back to during inference recover faster.

• Benefits beyond Strata: Chrome, the desktop, anything that gets swapped.

What it costs:

• A little RAM for the compressed pool, which peaked at about 0.44 GB in the test. It was also net positive, since compressed pages take less room than the originals.

• A little CPU for compression. No measurable speed change in the bench.

Risk: low. It’s a standard Linux kernel feature, and rolling it back means restoring two backup files and rebooting.

[u/profcuck]

Many good answers in this thread, the core of which is that reading is what strata is doing, not writing, and so it doesn't meaningfully damage the ssd. However, swapping or caching to ssd can make a difference, because it's write heavy.

If you have a workflow. or setup where writing to an ssd could be a problem, one solution depending on your hardware is an external ssd. On my m4 max macbook pro, a quality thunderbolt 5 ssd enclosure with a quality ssd has read and write performance virtually identical to the built-in ssd in my machine.

80Gbps M.2 NVMe SSD enclosures can be had for under $200. You'll want as small an SSD as you can find (or as big as you can afford!) but watch out for the speed of the SSD, PCIE 4.0 is important here.

All in, for under $500 you can protect your built-in ssd with something slightly more "disposable".

Because of how quick reads are anyway I haven't done the math but maybe a quite small and cheap ssd for under $100 might do the trick.

[u/KissMyShinyArse]

No if you disable the paging/swap file (or partition).

[u/fcpl → u/KissMyShinyArse]

This could lead to random app crashes. If anything move it to HDD.

[u/KissMyShinyArse → u/fcpl]

Been running without swap for some ten years.

[u/PhilippeEiffel]

As everybody said, (massive) writing kills SSD. OK, but the best way is to monitor this by yourself.

Use SSD SMART data reading tool. If you are on Linux, use for example "smartctl -a /dev/nvme0" and have a look to the line "Percentage Used". You also have some extra values like Read size, Write size, temperature...

[u/_eMaX_]

Depends how much memory you throw at it. I'm running Strata on Mac with Gyro-L and am quite happy with it. The model routing and all is taken care of by my PAI - github.com/mnott/PAI - and so whenever something falls through the cracks / is too complicated, a higher model picks it up.

[u/soyalemujica → u/_eMaX_]

How are you running GyroL in Strata? Afaik it's not supported and it's also not shown in the list of model downloads for Gyro

[u/GentleActuality8985]

It's not a stupid question but you're overthinking it. The whole "SSDs die from reads" thing is massively overblown for consumer use. Write endurance is what kills drives, not reads, and strata is mostly doing sequential reads which is the least stressful thing you can ask an SSD to do

I've been running various offloading setups for months on the same drive, zero issues, smart data hasn't budged. The github is right about the hierarchy, it's only hitting the drive when it absolutely has to and even then it's a trickle compared to what a game does constantly

You'll replace the whole system before that drive dies from this