Strata VRAM requirements

An open-source engine (GitHub Niko1221/Strata; MIT; C++; created September 24, 2026) that runs Qwen3.8-Flash-Next on ordinary PCs. The README's own line: 'Strata runs Qwen3.8-Flash-Next, a 125-billion-parameter model that normally needs a server, on a normal PC' — where '125B' is the language body; the total parameter count is ~175B once the 51.2B n-gram embedding table is counted, the same caliber wording as the base page (body ~125B, total ~175B including the 51.2B n-gram embedding table). The engine's model of the model is a 'team of 24,576 small specialists' — 512 experts × 48 layers, which reconciles with the official config — of which 10 per layer need to be resident, letting the rest tier across VRAM, RAM, and SSD, with a 29 GB n-gram lookup table (≈27 GiB) read from disk. Version at the October 20, 2026 README: 0.2.0-beta. Reception: front page of Hacker News on October 4, 2026 (900+ points at capture, linked below); ≈28K stars as of October 2026. Lineage, stated once: Strata wraps Qwen3.8-Flash-Next — engine × base, two dimensions, one page each. Every figure in this answer is the engine's or GitHub's own claim, reported and linked; this site measures files, not engines.

No — the engine already lists a second model, the technique is architecture-general, but support arrives per architecture, not automatically. The facts, from the pinned README (reported): its model menu pairs Qwen3.8-Flash-Next with Qwen3.6-35B-A3B — 'a smaller, different model that reads pictures and can answer several requests at once' — both sparse-MoE designs. The theory: what the engine streams is experts — only the hot few of each layer's hundreds need to be resident while the rest tier across VRAM, RAM, and SSD — which is a property of sparse-MoE architecture, not of one model; any large sparse-MoE release is a candidate, while dense models have no experts to stream and do not get a door like this. The reasonable inference: successor MoE models are the likely next additions — but each architecture needs engine-side support, and that part is documented rather than inferred: the QWEN36 doc states the second model runs on 'its own engine path (`src/qwen35`; `strata` switches to it from the file's architecture)' — so day-1 support for a brand-new architecture is not the thing to assume; check the README's current model list before buying hardware for a future model. All of the above is the engine's own claim, reported and linked; this site measures files — and when a second model's files matter here, they get their own measured page, linked from this one.

Per the README's stated door (pinned): at least 32 GB of RAM and graphics memory together, on a single card with 12GB or more — RTX 20/30/40/50 class, AMD RX 6800 or newer, Intel Arc, Apple Silicon (M1+, macOS 15+), or Strix Halo — plus about 80 GB of free disk (≈74.5 GiB). First launch loads 35–55 GB into RAM. Then the tier table, in the README's own GB figures: 32GB combined → Gyro-S or Coder; 40GB → Swift 1.5 IQ2_XS or Gyro-M; 48GB → IQ3_XXS; 64GB → IQ3_S; 96GB and up → UD-IQ4_XS through Q8_0. What the tiers mean: Gyro-S and Coder are the small-memory specialists (Coder keeps half the experts and is weaker outside code); the IQ2_XS → IQ3_S ladder trades quality for memory; 96GB+ is where the standard quants begin. Weights come from the engine's credited publishers — ISTA-DASLab, UkisAI, agentionai, and Unsloth builds. All of the above is reported, not measured by us — and a beta engine's tier table is a moving target, so re-check the pinned README before buying hardware.

Three install paths per the README: a desktop app (.exe / .AppImage / .dmg), a terminal one-liner (curl or PowerShell, scripts on the repo), or an AI-assisted install; building from source is documented too (START-HERE.bat / setup.sh). The engine fetches its weight builds itself from the credited publishers. Practical notes from the same README: keep the n-gram table on an SSD — a 29 GB lookup file; image input falls back to CPU when VRAM is under 24GB (one rig logged 57 ms versus 3.1 s for a 260-token image); and version 0.2.0-beta is young software, with hundreds of open issues on the October 2026 GitHub snapshot (GitHub's count includes PRs and the count swings daily under active triage — read it as 'very actively triaged', not a stable figure) — expect the moving parts of a beta.

The README's own rig table — reported, with the rigs pinned by line in our collection notes: on an RTX 5070 12GB with 64GB of system RAM, Q2_0 decodes at 94 tok/s with 2,650 tok/s prefill; IQ2_XS 79/2,090; IQ3_XXS 62/1,750; IQ3_S 53/1,620; Coder 55/2,180. An RX 9070 XT 16GB rig logs Q2_0 at 60/1,160. For the RTX 3090 the README's words are 'should write about 100-140 tokens per second' — a prediction, quoted as written, not a measurement. Speculative decoding claims 1.6-1.8× ('the same answer, sooner'), and long-document prefill is chunked at 8,192 tokens at over 1,000 tok/s. Two honesty notes: these are engine-published figures on engine-chosen rigs, so treat them as the top of a plausible range rather than a guarantee; and a 12GB card sharing residency with system RAM will not match datacenter throughput — it matches your desk, which is the point.

In the README's own sentence: 'Your chats and files stay on your PC.' One stated exception, same section: the chat's web-search feature sends the search words to DuckDuckGo — search is the one feature that ships something off the machine. Everything else — chats, files, the local API — stays local by architecture rather than by policy promise: the engine serves localhost endpoints (OpenAI-compatible at 127.0.0.1:8080/v1, an Anthropic-style /v1/messages, a Responses API, and an MCP server), so the serving path needs no third party. Whether a given build does anything beyond what the README states is a question to take to the repo — this page makes no telemetry claims.

The file is the same; the residency is not. The raw Q2_0 build totals 62.4 GiB (2× a 24GB card), and a llama.cpp-class runtime loads it whole into addressable memory — so the hardware doors are the ones in the tables above: 128GB appliance, one B200, 512GB Mac Studio. Strata's change is where the bytes live: only 10 of each layer's 512 experts are resident at a time, the rest tier across VRAM, RAM, and SSD, and the 29 GB n-gram table reads from disk — which is how a file with no consumer door gets a stated 32GB-combined one. The costs, honestly: the low tiers are low-bit quants (a quality trade-off against the Q4-and-up builds priced on the base page); the Coder build keeps half the experts and is weaker outside code; disk-resident experts are slower than VRAM-resident ones; and every number in this answer is the engine's claim, reported and linked. The raw-file route remains the quality ceiling — Strata is how you reach it from a desk, not a replacement for it.

Four names, four different things (README tier table, reported). Coder: keeps half of the experts — the 32GB-friendly specialist, code-strong and 'weaker outside code' by the README's own words. Swift 1.5: UkisAI's low-thinking finetune, offered at IQ2_XS for 40GB-class machines. Gyro-S and Gyro-M: agentionai builds — Gyro-S needs 27.6 GB (≈25.7 GiB) of memory (58.5 GB ≈ 54.5 GiB download), Gyro-M 35 GB (≈32.6 GiB), at about IQ3_XXS quality and 17-21% slower than Q2_0; NVIDIA/AMD only, no Intel or Mac build. Two more from the same table: an NVFP4 tier that needs about 80GB of RAM, and an OrcaRouter Uncensored IQ3_XXS variant that installs manually. The plain quants (IQ2_XS, IQ3_XXS, IQ3_S, UD-IQ4_XS up to Q8_0) are the standard ladders from the credited publishers — the tiers just map them to memory sizes.