64 Releases in 40 Days: How Strata Uses Release Velocity to Define Its AI Local Inference Roadmap

The Strata project shipped 64 releases in 40 days. If you add up the release notes for every version, they total more than 460,000 characters. A Bilibili creator read through all of them and distilled a clear evolution path: first make it run, then make it run fast, and finally make it run reliably. Based on that video and four key screenshots, this article reconstructs Strata's three-step leap from 0.1.0 to 0.2.10, and shows how ordinary users can find their tier based on their hardware.

Release density is itself the roadmap

Strata's release cadence shows an obvious pattern: dense at the start, sparser later, and heavier as it goes. In the first five days it shipped 17 versions, with as many as 8 in a single day; over the next 20 days it shipped 35 versions; in the final 15 days only 12. The count is decreasing, but the length of each release note is increasing—in the 0.1 era, the average note was about 4 times 87 characters, while in the 0.2 era it averaged 17,782 characters, nearly 4 times more.

This change in density shows that early on the project adopted a "fix one issue, ship one release" rhythm, while later it shifted to heavier, architecture-level changes. In the 0.2 era, at most two versions were shipped on the same day, but each version covered a significantly broader feature surface. Release density reflects the project's shift from tentative fixes to systematic refactoring.

Step one: make requests actually run (0.1.0 - 0.1.18)

The first version, V0.1.0, had release notes of only 384 characters and shipped with a Windows CUDA 13 installer supporting RTX 30 through 50 series. The next five versions all solved the same class of problem: whether requests could run properly. 0.1.2 made tool calls stream, so pressing stop actually stops; 0.1.7 fixed a bug where recovery stalled at 1024 tokens; 0.1.8 grew the first app in the browser and brought an optional 4-bit KV cache, reducing 128k context from 1.52 GB to 0.83 GB.

There was not a single speed promise in this stage—all effort went into making the inference pipeline stable and usable. For a local deployment tool, getting it to run is the top priority, and Strata spent about 18 versions on this step.

Day 5's 0.1.16 was a turning point, doing three things in one day, each of which changed what was possible for the following month. First, it switched to MIT open source; second, it integrated the first search model, Gsqrcocoder, with the original text saying "remove half the experts, keeping only the ones needed for code, tool calls, and images," lowering the memory threshold to 32G, with a 12G card reaching 599 to 1350 tokens per second on prompts; third, it moved weights into the strata data directory so updates no longer download tens of GB from scratch. Open sourcing was not a gesture but a shift from "we tested it" to "you can test it yourself"—all later benchmarks hold up because of this step.

KV cache is a key optimization mechanism in Transformer inference. During autoregressive generation, each new token requires recomputing attention over all previous tokens, with computation growing quadratically with sequence length. KV cache stores the Key and Value vectors of historical tokens to avoid recomputation, reducing complexity to linear. But the cache itself consumes VRAM: at 128k context, a traditional FP16-precision KV cache can exceed 1.5 GB. The "4-bit KV cache" introduced by Strata in 0.1.8 quantizes and compresses cache precision, reducing 128k-context cache usage from 1.52 GB to 0.83 GB, making large contexts possible on consumer GPUs at the cost of a very small accuracy loss.

Step two: turn one card into a product line (0.1.21 - 0.1.44)

The main thread of the next 20 days and 35 versions was turning support for one card into a product line covering multiple hardware and scenarios. 0.1.21 implemented paired splitting across two to three NVIDIA cards, with 5080 plus 3090 at 32k raising prompt throughput from 1970 to 2357 tokens per second; 0.1.39 catered to Pascal, Volta, and old CPUs, all marked experimental; 0.1.40.2 promoted Intel ARK to stable; 0.1.41 removed FP64 from the A750 sampler, raising decoding from 9.8 to 12.0, a 22% improvement; 0.1.43 entered AMD RDNA; 0.1.44 entered Apple Silicon.

The most noteworthy thing in this stage is not the numbers but how the benchmarks were written. The author used paired medians, alternated two defaults on the same machine, created a new engine each round, and phrased conclusions as "8 out of 8 faster" rather than "4% faster." He used an identity gate—10 prompts plus exact answer comparison at 4k and 20k—and only dared to say a change affected only defaults if the answers were unchanged; if answers changed, he switched to kr distance. 0.2.3 explicitly states "words entering ties may differ"; 0.2.8 also admitted that a speedup default caused repeated text in frequent drawing, and preferred to turn it back off. Moreover, every new default came with a reverse environment variable—"changes that can't be written with a fallback don't go into defaults." This rigorous measurement methodology is more worth learning from than the specific numbers.

Paired median is a rigorous benchmarking method: for the same machine and the same set of prompts, alternate between two configurations being compared (such as before and after optimization), create a new inference engine each round, record the latency or throughput of each run, and finally take the median of the paired differences as the conclusion. Compared with single measurements or averages, the paired median cancels out machine state drift and warm-up differences, reducing random error. The original text's "8 out of 8 faster" refers to the median result of 8 paired tests, not a simple percentage improvement—a more conservative and credible phrasing.

Step three: make installation and updates trustworthy (after 0.2.0 beta)

By 0.2.0 beta, the whole shape changed. In the 0.1 era, users had to run start here themselves or compile from source; 0.2.0 split into three components: app, terminal, and engine. The app is an installer for three platforms, the terminal installs with one command, and the engine is split into ten packages by platform and GPU, with an installer bundled in, so a model can start right after installation. There was also a fourth: an Ed25519-signed update channel, switching only after the main file verification passes, with automatic rollback on failure. The cost is also clear—ten installers correspond to ten hardware combinations.

Nearly every one of the 12 versions of 0.2.x had a different protagonist. 0.2.2 let GPUs set mean helper or off; 0.2.3 raised streaks halo's response speed by 6% to 19%; 0.2.4 brought deep seek v4 flash into the terminal, runnable on a 12G card plus 16G RAM; 0.2.7 entered DGX Spark; 0.2.8 went from 60 to 63 up to 71 to 74 on two Arc Pro B65s. 0.2.10 made dflash2 the default, and from then on speed numbers were grouped by machine model.

The latest version changed three defaults, each with a cost. First, dflash2 completed the default drafter at 0.7G, replacing the 5.2G mtp layer, improving single-card decoding by 5.8% to 12.0%, but on Arc A750 it was actually 2% slower. Second, on Linux, full-card successfully split engines start automatically, with two A6000s raising code editing from 195 to 377 to 394 tokens per second, at the cost of 32k prompt first-token time going from 7.65 seconds to 4.1 seconds. Third, 8G cards start at 128k context. There is also a pitfall: upgrading from 0.2.9 requires running update twice.

Ed25519-signed update channel is a cryptographic mechanism that ensures software distribution integrity. Ed25519 is an elliptic-curve-based digital signature algorithm that is fast, has short keys, and offers high security. In automatic update scenarios, the publisher signs the main file of the update package with a private key, and the client verifies the signature with a built-in public key; only after verification passes does it switch to the new version, otherwise it automatically rolls back to the old version. This prevents update packages from being tampered with or replaced in transit, ensuring users install official builds. After Strata split the update channel into app, terminal, and engine layers, each layer needs independent signature verification, increasing the complexity of attack surface management but also improving overall trustworthiness.

Which tier does your card fall into?

For NVIDIA single-card users, 12G is the watershed. An RTX 3060 running Qwen 3.8's IQ3XXS writes answers at 46.8k to 67 tokens per second and reads prompts at 374 to 397, enough for daily conversation and agents. 8G can only choose IQ3S; 128k context can start, but don't expect concurrency—two simultaneous requests will clearly degrade throughput. A 16G A4000 is more comfortable at the same quantization, with VRAM no longer the bottleneck; the bottleneck shifts to RAM and disk. Above 24G, single-card gains diminish, and multi-card splitting should be considered.

The key point: a 12G card running deep seek only gets 4 to 8 tokens per second—that's a chat tier, not a work tier. To run agents, look at RAM and disk first, not the GPU.

Treat "technical debt" as the roadmap

Strata has no public plan, but every version includes a section on "what hasn't been done yet," and these sections are the next version's checklist. One already-delivered example: 0.2.4's notes explicitly said Mac and Strix Halo were not in this version and deep seek could not run; three versions later, 0.2.7's title was "deep seek on DGX Spark and Mac," delivering both in just 9 days.

0.2.10's debt is the nearest map: the drafter fetch logic is clearly a later change; Windows plus N-card deep seek is marked not run yet; GIFOS dual-card and 3-4 card full-card splitting have also not been run. These are priorities inferred from the main text, not promised schedules, but debt written in the main text is basically always paid off in the next few versions.

Almost every feature follows the same four steps: single card first, then matrix; opt in first, then default; test first, then talk. 0.2.3 was just a switch in the terminal, and after 7 versions and 9 days it became official; 0.2.8 even turned off one of 0.2.7's speedup defaults. The version number itself also indicates whether to upgrade: xy0 and beta are architecture-level changes, where installers and directory structure may change, worth following but wait 48 hours for patches; the third digit 1-4 is a fix within the same architecture, usually for a specific model, so upgrade if your model is on the list; the fourth digit is a single-point regression fix, covering only one fix, so upgrade if you hit the problem. When upgrading across engines, app, control, and engine each have their own version—read the updating section first.

identity gate is the test method Strata uses to verify whether an optimization changes model output: prepare 10 fixed prompts, generate answers at 4k and 20k context lengths with the pre-optimization and post-optimization engines, and compare token by token exactly. Only if answers are completely identical is the optimization allowed to become the default; if answers differ, a looser kr distance (Kullback-Leibler divergence) is used to measure distribution shift. This mechanism ensures performance optimization does not sacrifice output quality, and explains why some speedup defaults were turned back off after repeated text was found—the identity gate did not pass.

The easily overlooked hardware support path

Strata's hardware support is basically user-reported, author-added. Support for task call, Volta, Arc, RX 6000, and others is all marked in the notes as reported by or built not tested—built but not run on real cards. After open sourcing, 27 notes directly name and thank 32 contributors, and 886 issue numbers appear across the 64 notes. The meaning for users is direct: if your card is not on the list, opening an issue is the fastest path; no need to wait in an official queue.

In 40 days, the order of these three stages never reversed once: first make it run, then make it run fast, and finally make it run reliably. For those following local inference tools, Strata's release record is a rare sample—treating releases themselves as a measurement instrument, using release density and debt lists to infer the project's real priorities.