Strata shipped three releases in three days claiming "+30%", and in the same three days users reported "21% slower on two RTX 3090s" and "output cuts off on a 5090"

Haru here. This week, among people running large models locally, one project's "it got faster" and "it got slower" were flying around at the same time. Niko1221/Strata. It is an MIT-licensed implementation for running Qwen3.8-Flash-Next, a 125B (125 billion parameter) model, on 12GB-class gaming GPUs, and over the three days from October 10 to 12 it put out three releases: v0.1.42, v0.1.43, and v0.1.43.1. I didn't run it myself; this is newsroom research based on reading through the release notes and the GitHub issues. But across those three days, the gap between "the author's numbers" and "users' numbers" was interesting enough to be a story on its own 👀

Three releases in three days: what the author's "faster" consisted of

Start with the author's numbers. v0.1.42, released on October 10, is a version that raises generation speed on a single GPU. It contains two things. One skips the computation for the "experts" inside the model that barely affect the answer; the other measures the actual bandwidth of PCIe (the data path between the CPU and the GPU) and splits the work between CPU and GPU accordingly. Both were turned on by default.

The numbers go like this. RTX 5070 (Windows): 77.0→85.6 tok/s (tokens, roughly fragments of words, per second), +11.2%. RTX 3060: 47.7→62.1 tok/s, +30.0%, when the PCIe split is optimized. RTX A4000: +12.9%. Tesla P100: +14.6%. What is written candidly here is that the answers change slightly. The average KL divergence (a measure of how far the output has drifted from the original behavior) is 0.0058, and three environment variables are listed for restoring the original behavior. It doesn't hide the trade-off, faster at the cost of slightly different answers, and that made a good impression.

The next day, October 11, v0.1.43 was Radeon and Arc's turn. On Radeon (16GB), decoding of IQ3_XXS (a version squeezed down to roughly 3-bit) is +21 to 38%; on the Arc Pro B70, prompt processing for 4K tokens went from 8.5 seconds to 3.3 seconds, and 16K from 27.4 seconds to 13.4 seconds. The Windows build switched to reading experts from file in parallel, and GGUF streaming decode is said to be 1.35 to 1.85x faster. It also bundled a NaN guard that detects a broken stretch of decoding and retries it, plus BENCH.bat / bench.sh so users can measure speed under the same conditions. That turns out to matter later.

Then on the 12th, v0.1.43.1. This is a hotfix, a correction to the previous day's version. The notes say the cause of slower decoding on Linux + NVIDIA was the callback handling in adaptive overlap (a feature that overlaps CPU and GPU work so they run at the same time). The results after the fix: RTX 3060 (Linux) 36.5→56.5 tok/s, two RTX A4000s with 4 concurrent requests 62.3→85.2 tok/s, and RX 6800 (Windows) prompt processing 584–596→798–808 tok/s. It also includes a case where a long 77,800-token prompt on a SATA SSD went from 76–154 to 884 tok/s. And a 65-minute load test with 6 clients on an R9700 with 0 errors. In other words, the author themselves acknowledged that "v0.1.43 had actually gotten slower on some hardware" and fixed it the next day 🛠️

"It's slower on my machine," arriving in the same three days

Here is the main story. During the same three days when the author's release notes were lining up "+X%", users' measurements on their own hardware came in as issues.

The first is Issue #2138. The owner of a seriously beefy Ubuntu machine: two EPYC 7663s, two RTX 3090s (24GB), and 384GB of RAM. Comparing v0.1.42 with v0.1.43, throughput with adaptive overlap enabled and two requests processed concurrently fell from 155.67 to 121.53 tok/s, a drop of about 21%. And this person didn't stop at "it's slower." They confirmed that disabling the feature with STRATA_ADAPT_OVERLAP=0 restored 153.60 tok/s, and analyzed the cause as synchronization waits from the extra host callbacks (the mechanism by which the GPU tells the CPU "done up to here") added in the batched-processing path. On top of that, they requested either excluding batched processing from the feature or making it opt-in rather than on by default. As a bug report it is almost too perfect; I was a little moved ✨

The second is Issue #2167. A report from zhang2939, who is running the IQ3_S version on a Windows machine with an i9-14900KF, an RTX 5090, and 96GB of RAM. v0.1.43 and v0.1.43.1 are slower than v0.1.42, and on top of that, output that completed in v0.1.42 now cuts off partway through without any error. Logs from both versions are attached, but as of when I looked, there was no reply from the author yet. In practice, "silently cuts off partway" hurts more than fast or slow. You have it writing a long piece, it stops in the middle, and because there is no error it is easy to miss.

Those two are the three-day story, but open issues stood at 407 at the time of checking. Even a quick skim turned up: memory growing until a crash on an Arc A770 (#2194), the first request timing out on an RTX 4070 SUPER (#2188), occasional crashes while running the IQ3_S version (#2192), and processing stalling when connected to development tools like Trae (#2200). Different GPUs, different operating systems, yet the "runs, but not stably" category of reports clustered in the same week 🤔

Why the author's numbers and users' numbers diverge

This is worth unpacking. When you run a large model locally, speed isn't determined by GPU performance alone. In Strata's case, a 125B model doesn't fit entirely in a 12GB GPU, so the part that doesn't fit lives in CPU-side memory or on the SSD and gets shuttled to the GPU when needed. That means four things all matter: GPU speed, the bandwidth of the path between CPU and GPU, SSD read speed, and how many requests you are handling at once.

Every number in the author's release notes is qualified: "this GPU, this OS, these conditions." The RTX 3060's +30.0% is "when the PCIe split is optimized," and the SATA SSD improvement is for a long 77,800-token prompt. Meanwhile, the person in #2138 is running two concurrent requests on two 3090s, and the person in #2167 is running IQ3_S on a 5090. If the combination the author tested differs from the user's, it is entirely normal for the same version to produce results pointing in opposite directions. The v0.1.43.1 release notes say it fixed the Linux + NVIDIA slowdown, yet the person in #2167 says v0.1.43.1 is still slow on Windows + 5090. That is probably a different cause, which is exactly why a reply is being waited on.

One more thing: the "premise" behind the numbers. Strata's speeds are for versions heavily quantized down to 2 to 3 bits (the numbers inside the model coarsened to shrink its size), not the model Qwen used for its official benchmarks. The PromptHackers roundup of the October 4 HN front-page post reportedly included voices saying "for real work you don't go below 4-bit" and "at that point you rent a cloud GPU for a dollar an hour." That predates these three days, so I note it as background, but the point that "fast" and "equally smart" don't come as a set still stands. The v0.1.42 change in default answers (KL 0.0058) is on that same continuum.

The scale of the momentum, and what to know before you try it

Let's also get a sense of scale. According to AICoder, when v0.1.39 came out on October 4 and hit the HN front page (507 points), the project reportedly had about 10,700 stars. When I checked on October 13, it was about 22,700, forks had gone from 946 to about 2,200, and commits stood at 1,892. GitTrend's monthly tally for October reportedly puts it in 5th place with +18,600 stars. From v0.1.39 (10/4) to v0.1.43.1 (10/12) is about seven releases in eight days, so something changes almost every day 📊

If you are going to use software that changes this fast, the bundling of BENCH.bat / bench.sh in v0.1.43 matters a lot. Author and users can now produce numbers with the same method of measurement, so "it's slow on my machine" becomes a comparable number rather than an impression. I think the #2138 report landed precisely because it came in reproducible form: turn it off and it comes back, and here is the cause. That applies not just to Strata but to every local LLM project.

There are concerns too. The install procedure has you paste code into an AI coding assistant and let it run, which the PromptHackers roundup points out is "the same as piping a download straight into your shell." Running something without reading it carries the same risk with any tool. Also, reverting the features that are now on by default requires setting three environment variables, so anyone who wants to "measure under the same conditions as the previous version" has that extra step.

Haru's take: both are true, so measure

What struck me following this is that in the local LLM world, the gap between "the author's numbers" and "your numbers" becomes the story itself. With a cloud API, speed is the provider's problem and users only need to look at the results. But locally, your own hardware is the stage, so the author's +30% can be your −21%. Neither side is lying; the conditions are just different.

In that sense, the author fixing v0.1.43's slowdown the next day, and a report like #2138 that isolated the cause, landing in the same three days captures this project's current state well. On the other hand, reports like #2167 remain without a reply, and 407 open issues is frankly a lot. That is also evidence that "has momentum" and "is stable" are different things.

Conclusion. It got faster: true. Some people's got slower: also true. Both are public, with numbers. That was Strata this week. If you try it, first run bench to get your own numbers, then see what happens when you turn off the on-by-default features. That alone should tell you which side you are on 🚀