Running DeepSeek V4.1 on an RTX 3060: Cracking the Out-of-Core MoE Prefill Bottleneck

Title

Running DeepSeek V4.1 on an RTX 3060: Cracking the Out-of-Core MoE Prefill Bottleneck

Meta Description

Project Betelgeuse runs DeepSeek^Ad V4.1 Flash Q8_XL on an RTX 3060 12GB with 16GB RAM, boosting prefill from 3-6 tok/s to 61.80 tok/s and decoding to 19 tok/s. This article breaks down its out-of-core MoE prefill bottleneck solution, performance comparisons, and limitations.

Article Content

Running frontier large models on consumer hardware has always been constrained by VRAM and RAM capacity. Recently, a project called Betelgeuse demonstrated running DeepSeek V4.1 Flash Q8_XL (over 300GB in total size) at usable speeds on a budget gaming PC with an RTX 3060 12GB and 16GB single-channel DDR4 memory. According to the project author's Reddit share, decoding reached 19 tok/s, and prefill speed was raised from an initial 3-6 tok/s to 61.80 tok/s. Based on that share, this article outlines the technical approach and key trade-offs.

The Core Pain Point of Out-of-Core MoE: Prefill

For large MoE models with expert layers placed on SSD or hybrid storage, time-to-first-token (TTFT) is the biggest experiential obstacle. A 500-token prompt might take 30-60 seconds to process under a traditional implementation, during which the engine crawls along at 1-3 tok/s. The reason is that the prefill phase activates nearly every expert across all 40 layers; if loaded sequentially, the GPU sits idle for long stretches while the bus is blocked.

The Betelgeuse author previously drew attention for a Qwen 3.8 Flash Next share, but the community was more interested in whether this approach could work for frontier models like DeepSeek V4.1 Flash. The answer is yes. They emphasize this is not running a small IQ2_XS-quantized model, but a 305.6+110.6GB expert backbone at Q8_XL precision, paired with an IQ4_NL Engram table.

MoE (Mixture of Experts) architecture: Frontier models like DeepSeek use a MoE structure, where each layer contains multiple "expert" subnetworks, but each token is routed to only a few of them. In this article's model, total parameters exceed 300GB, but a single forward pass activates only some experts, so in theory it can run under limited VRAM—provided the needed experts can be efficiently moved from slow storage to the GPU. The difficulty with MoE lies in the prefill phase: when processing a long prompt, almost all experts get activated by different tokens, causing a large amount of weights to flow from SSD/RAM into the GPU, creating an I/O bottleneck. This is the core contradiction of out-of-core MoE inference: during decoding, activation is sparse and transfer volume is small; during prefill, activation is dense and transfer volume is large. Betelgeuse's three optimizations are designed precisely for this asymmetry.

TTFT (Time to First Token): The latency from when a user submits a prompt to when the model outputs the first token—a key metric for interactive application experience. For out-of-core MoE, TTFT is mainly determined by the prefill phase: the engine must first process the entire prompt, activate and load the required experts, and only then begin token-by-token decoding. Under traditional implementations, a 500-token prompt might take 30-60 seconds, which users perceive as "frozen." Betelgeuse raises hot prefill to 61.80 tok/s, meaning prefill time for a 500-token prompt is compressed from tens of seconds to about 8 seconds, making TTFT nearly instantaneous—this is the core of its experience improvement.

Three Optimizations Crack the Prefill Bottleneck

Betelgeuse achieved an order-of-magnitude improvement in prefill speed through three targeted changes.

Position-Independent Cache Partitioning

Each layer maintains 20 resident slots (5 VRAM hot slots + 15 host memory slots) with strict non-interfering routing. This design lets active experts stay resident stably, reducing repeated loads.

Single-Pass Layer-First Prefill

Unlike splitting the prompt into 3-token micro-batches (which destroys Tensor Core occupancy), prefill runs in full 16-token sub-batches. All active host-memory experts stream in parallel over PCIe into the execution ring, overlapping with computation.

End-of-Pass Physical VRAM Consolidation

The engine learns which experts the prompt and early generation actually need, and at the end of the first pass physically swaps the 5 most active experts into VRAM hot slots without changing the model's logical routing trajectory.

The author reports hot prompt processing speed rose from 3-6 tok/s to 61.80 tok/s, and TTFT for standard prompts is now nearly instantaneous.

Non-interfering expert caching and routing: In MoE inference, the router selects experts for each token; if the caching strategy frequently changes which experts reside in fast storage, the routing trajectory may become inconsistent with cache contents, causing repeated loads or correctness issues. Betelgeuse's "position-independent cache partitioning" maintains 20 resident slots per layer (5 VRAM hot slots + 15 host memory slots) with strict non-interfering routing—meaning caching decisions do not change the model's logical routing choices, only the physical residency location. This lets active experts stay resident stably, reducing repeated PCIe transfers while keeping outputs consistent with the original model.

PCIe parallel streams and computation overlap: During prefill, expert weights in host memory must be transferred to the GPU over the PCIe bus. If executed sequentially as "load→compute→load→compute," the GPU idles heavily waiting on the bus. Betelgeuse's "single-pass layer-first prefill" processes a full 16-token sub-batch at once, with all active host-memory experts streaming in parallel over PCIe into the execution ring, overlapping with GPU computation. This is similar to CPU prefetching and pipelining: while computing the current layer, experts needed for the next layer are moved ahead of time, hiding bus wait time behind computation and significantly improving throughput.

Performance Comparison: Betelgeuse vs. Strata

The author provides a benchmark comparison with Strata. It should be noted that Strata used 64GB RAM and 3.6 GB/s NVMe on an RTX 5070, while Betelgeuse runs on an RTX 3060 with 16GB RAM and 1.7 GB/s NVMe—the hardware conditions are not equivalent.

On a comparable RTX 3060 platform, Betelgeuse's hot prefill is 61.80 tok/s, while Strata reaches 149 tok/s at an 8K prompt; but for decoding, Betelgeuse is 18.15-18.92 tok/s versus Strata's 8-10 tok/s. The author also notes that upgrading to dual-channel 16GB memory could raise prefill speed from 61 tok/s to around 120 tok/s.

Other metrics include: decoding peak 27.92 tok/s, agentic work decoding 24.22 tok/s, cold SSD reads 0.00%, disk I/O wait 0.0 ms, and peak memory usage 10.61 GiB. These figures come from the author's own testing and have not been independently verified.

Precision and Correctness Validation

Betelgeuse uses Q8_XL (UD - 3.1) quantization, while Strata uses GSQ-RCO IQ2_XS. The author claims to have verified the correctness of Python syntax and logic across multiple runs, but provides no detailed testing methodology. For production environments, users are advised to perform their own task-level validation.

Quantization formats Q8_XL and IQ2_XS: Quantization is a technique for representing model weights with fewer bits to compress size. Q8_XL typically refers to 8-bit quantization (XL may denote a specific grouping or mixed-precision strategy), striking a good balance between precision and size; IQ2_XS is an extremely low-bit quantization of about 2 bits, smaller in size but with greater precision loss. In this article, Betelgeuse runs a Q8_XL 305.6+110.6GB expert backbone, while Strata uses GSQ-RCO IQ2_XS—the model precisions differ, so direct speed comparisons should be interpreted cautiously. The author's emphasis that this is "not running a small IQ2_XS model" is meant to show that Betelgeuse still achieves usable speed at higher precision, which is an important premise for its technical value. Readers reproducing this should pay attention to how quantization format affects VRAM usage, load bandwidth, and output quality.

Engineering Details: Engram Table and DSpark Drafter

The 110 GB Engram table lives entirely on NVMe SSD. Since Engram is only activated in layers 1 and 14, and each token touches only 48 rows (about 192 KB), these active rows are staged into a 2MB VRAM buffer at t=0, so the 110 GB file basically uses no RAM and does not trigger CPU graph splits.

Additionally, the project uses DeepSeek's native DSpark drafter (p_min = 0.50), achieving about 80-90% acceptance on structured code, amortizing the forward pass over more than 4 tokens per sweep. After cache warm-up, disk reads drop to 0.00%, generation holds steady at 18-19 tok/s with no swap thrashing. The author notes DSpark is disabled by default on the RTX 3060 and enabling it can add 2-13% performance.

Engram table: Can be understood as a large sparse lookup table or memory module in the model, storing vast amounts of discrete knowledge fragments. In this article the Engram table is 110GB; loading it entirely into memory would far exceed a budget PC's capacity. Its key property is sparse activation: it is only queried at layers 1 and 14, and each token touches only 48 rows (about 192KB). Betelgeuse exploits this by staging active rows into a 2MB VRAM buffer at t=0, so the 110GB file basically uses no RAM and does not trigger CPU graph splits. This is a "paging on demand" approach: only the tiny fragment needed by the current token is moved into VRAM, rather than loading the entire table.

DSpark drafter and speculative decoding: DSpark is DeepSeek's native draft model used for speculative decoding. The principle: a small drafter first quickly generates multiple candidate tokens, which the large model then verifies in parallel; if the draft tokens are accepted, one forward pass can produce multiple tokens, improving decoding speed. In this article DSpark achieves 80-90% acceptance on structured code, amortizing the forward pass over more than 4 tokens per sweep. p_min = 0.50 is an acceptance threshold parameter controlling the trade-off between drafter and verifier. The author notes DSpark is disabled by default on the RTX 3060 and enabling it adds 2-13% performance, indicating its gains depend on task type and hardware conditions.

Limitations and Outlook

The current version performs best on the sm_86 architecture, and future versions will attempt further compression. The author did not disclose a specific release timeline. For users wanting to reproduce: single-channel memory is a clear bottleneck, and dual-channel can bring nearly double the prefill improvement; moreover, all performance data comes from the author's unilateral testing, and actual experience may vary by system configuration, driver version, and task type.

The project is open-sourced on GitHub (Betelgeuse-AI/Betelgeuse), and the author welcomes questions about memory tiering and doorbell synchronization.

Key Takeaways

• Running DeepSeek V4.1 Flash Q8_XL on an RTX 3060 12GB + 16GB RAM: decoding about 19 tok/s, prefill about 62 tok/s.
• The prefill bottleneck is solved via position-independent cache partitioning, 16-token single-pass layer-first prefill, and end-of-pass VRAM consolidation.
• The Engram table exploits sparse activation to use almost no RAM; the DSpark drafter improves decoding efficiency.
• The comparison with Strata involves different hardware conditions and should be interpreted cautiously; dual-channel memory can significantly boost prefill.
• Performance data comes from the author's own testing; independent verification is recommended before production use.

One-line Summary

Betelgeuse runs a 300GB-class DeepSeek V4.1 Flash on an RTX 3060 at 19 tok/s decoding and 62 tok/s prefill.

Paragraph Summary

The Betelgeuse project demonstrates running DeepSeek V4.1 Flash Q8_XL (over 300GB total) at usable speeds on a budget PC with an RTX 3060 12GB and 16GB single-channel DDR4 memory. Its core breakthrough is solving the out-of-core MoE prefill bottleneck: through position-independent cache partitioning, 16-token single-pass layer-first prefill, and end-of-pass physical VRAM consolidation, prefill speed rose from 3-6 tok/s to 61.80 tok/s, with decoding around 19 tok/s. The Engram table exploits sparse activation to use almost no RAM, and the DSpark drafter achieves 80-90% acceptance on code tasks. The comparison with Strata requires cautious interpretation due to different hardware conditions, and dual-channel memory can nearly double prefill. All data comes from the author's own testing and has not been independently verified.