r/LocalLLaMA user posts unreviewed CPU-only DeepSeek V4.1 Flash build

A developer posting as u/Qwen30bEnjoyer on r/LocalLLaMA has released a CPU-only implementation of DeepSeek V4.1 Flash, titled in the thread as an experimental and sloppy build. The code is hosted at github.com/gjabdelnoor/Day1DeepseekV4.1-CPU. The stated goal is narrow: keep a bioinformatics lab machine producing tokens slowly for overnight and multi-week agentic jobs.

The author frames the appeal in personal terms, writing that they like having "infinite slow tokens" available on the lab machine for agentic jobs that run overnight or across weeks. The tradeoff is speed. The build is not meant to compete on latency. It is meant to use time the hardware would otherwise spend idle.

The author explains the hardware constraint behind the project. The Xeon box belongs to the lab and gets called away for genome assemblies, benchmarking and other work, so the implementation runs at whatever speed the idle machine allows rather than reserving resources. A watcher process is meant to kill the inference run within 15 seconds if someone else needs the computer.

Reported throughput on that Xeon comes to about 30 tokens per second for prefill and about 6 tokens per second for generation, with the n-gram table offloaded onto 50 percent of the threads. The post does not include a benchmark harness, test corpus or comparison against an existing CPU backend, so the figures are self-reported and unreproduced.

The author is direct about the condition of the release. The code was, in their words, "sloppily vibecoded by Opus 5.0" and remains unreviewed because they say they lack the skill to verify it. Shipping quickly ranked above quality assurance, which the author acknowledges. They describe the work as a starting point and ask readers with more kernel experience to open pull requests or publish forks.

The approach fits a familiar pattern among people running local models, where operators with spare or borrowed hardware try to get usable inference out of CPUs instead of GPUs. This one stands out for how openly the author disclaims responsibility for the code and for how much the shared, interruptible lab workstation shapes the design.

No additional reporting or independent testing of this build turned up in the coverage reviewed for this article, and the thread carries no third-party confirmation. That leaves questions open. Whether the watcher reliably frees the machine within 15 seconds under real contention remains untested outside the author's environment, as does the durability of the reported speeds on comparable Xeon configurations. The offloading strategy, which places the n-gram table on half the threads, has not been checked at larger thread counts.

The repository is public and the author has invited contributions, so what happens next depends on whether kernel developers take it up. Until someone reviews the code or reproduces the numbers, the release stands as one person's working experiment rather than a validated option for CPU-only agent workloads.