~100 seconds → ~5 seconds to start a new OpenCode project session... - Vibeus
~100 seconds → ~5 seconds to start a new OpenCode project session on a gaming PC. That is the result of HearMeOut-13’s experimental Strata patch for DeepSeek V4.1 Flash, combining conversation-cache reuse with resident-only routing while reading prompts. It is a startup result on one machine, not a 20× increase in generation speed.
The setup: RX 9070 XT 16 GB, Ryzen 7 5800X3D, 64 GB DDR4 and a PCIe 3.0 NVMe. The model is DeepSeek V4.1 Flash IST-DAS 1.75 bpw at 1M context, with experts split across VRAM, RAM and SSD. The quantization lab reports 98.7% of the full model’s task average; that claim is separate from the quality of these new patches.
Generation at about 7 tokens per second was usable for this owner. The frustrating part was rereading the roughly 37K-token system prompt and tools every time a new OpenCode session started: about 100 seconds before the first token.
The first change, KV splice, deals with changing text inside the system prompt: working directory, date, project CLAUDE.md and skill paths with random IDs. Those differences break ordinary prefix reuse. The patched engine aligns the new prompt against saved conversations, removes stale lines from the cached state, shifts cached rows, rotates window rings and records a RoPE gap. It then reads only the new lines and message. Lines move whole, so the model does not see broken fragments.
The second change makes prompt tokens choose experts already resident in VRAM or RAM instead of streaming almost the whole model from SSD. Even a fresh 1.2K-token prompt had read 58 GB from disk. Generation still uses normal routing; the substitutions happen during prompt reading.
On the same machine, a fresh roughly 1.2K-token prompt went from 22.8 seconds and 58 GB read to 8.2 seconds and 1.3 GB. A new OpenCode session in another project reused 36,949 tokens and read 513 in about 5 seconds, versus roughly 100 seconds stock. Follow-up turns in a 90K-token conversation took about 4–10 seconds. The attached image is the original results table.
There are real tradeoffs. KV splice is approximate: cached tokens after a cut were computed with the removed text still in their context. The author has not noticed an effect from short guidance lines, but has no formal quality evaluation of the splice. Resident routing also changes answers because it substitutes experts during prompt reading.
The hard coding suite scored 12/13 both ways, one run per configuration, with one problem flipping in each direction. The primary issue gives pass@1 with thinking enabled, temperature 0.6, top_p 0.95, top_k 20, seed 1234 and a 16,384-token limit. Stock missed sudoku at the token limit; the patched run missed cron_next on an off-by-one-minute case. That single pair of runs does not establish unchanged quality. Repeated runs, a KL/perplexity comparison and broad long-context quality tests have not been done.
This branch was built and tested only with HIP on gfx1201. CUDA, SYCL and Metal have not been built or tested. Both features are on by default in dsv41-kv-splice; STRATA_DS4_REORDER=0 and STRATA_DS4_PROMPT_RESIDENT=0 turn them off. The branch also includes a one-line fix for a GPU page fault encountered with a 37K-token prompt, tracked as #4912.
For the HIP build, the shared instructions enable STRATA_ENABLE_HIP, disable STRATA_ENABLE_CUDA, set CMAKE_HIP_ARCHITECTURES=gfx1201 and STRATA_BUILD_DSV41=ON, then build the strata-dsv41 target. Launch uses STRATA_DSV41_EXE pointing to that binary and DS4_CHUNK_MIN=16. The complete clone/build commands and branch are in the source.
For OpenCode, the model entry also needs "interleaved": { "field": "reasoning_content" }. Otherwise earlier reasoning is dropped and cache reuse misses more often. The implementation and measurements are documented in upstream issues #4921 and #4936 and the PhialsBasement/Strata dsv41-kv-splice branch; this is a proposed branch change, not a claim that it has merged upstream.