Project Maya is a Strata and llama.cpp fork built for running massive MoE models like DeepSeek V4.1 Flash locally. Here's how it works.
What is Project Maya? #
Project Maya is a fork of Strata, which is itself a hybridized fork of llama.cpp. It’s built specifically to run very large mixture-of-experts (MoE) models, like DeepSeek V4.1 Flash and GLM 5.3, on hardware that has no business running models of that size. That’s the whole point of the project: take models with hundreds of billions of parameters and make them usable on aging workstations, dual-GPU rigs, and machines that would otherwise choke on prefill speed or context handling.
The lineage matters here. Llama.cpp is the open-source inference engine that popularized running quantized LLMs on consumer CPUs and GPUs. Strata took that codebase and modified it for specific runtime optimizations. Project Maya takes Strata further, with its own quant format (referred to as “Maya-N” in recent releases) and tuning aimed at squeezing usable throughput out of massive MoE architectures on modest hardware.
How does Project Maya differ from stock llama.cpp? #
Other agents start typing. Remy starts asking. #
Scoping, trade-offs, edge cases — the real work. Before a line of code.
The headline difference is raw performance on large MoE models when context windows get long. In testing on a Dell Precision T5810 (dual RTX 3060s, a 22-core/44-thread Xeon E5-2696 v4, and 256GB of RAM), a machine nobody would call powerful by current standards, Project Maya pushed roughly 11.1 tokens per second on DeepSeek V4.1 Flash and around 55-60 tokens per second on GLM 5.3 Flash. Prefill speed, which determines how fast the model ingests a long prompt or codebase before it starts generating, ran between roughly 1,100 and 1,500 tokens per second across a context window reaching up to a million tokens in some sessions.
Compare that to running the same DeepSeek checkpoint through stock llama.cpp with a standard UD IQ1M quant (around 250GB at 1-bit quantization), which is noticeably slower to produce output on the same hardware. The gap isn’t about raw compute, it’s about how the runtime handles expert routing, memory layout, and quantization specifically for MoE architectures rather than treating them like dense models.
Why does this matter for running models like DeepSeek V4 and GLM 5.3? #
DeepSeek and GLM’s larger releases use mixture-of-experts designs, meaning only a subset of the model’s total parameters activate for any given token. That should, in theory, make them cheaper to run than a dense model of equivalent size. In practice, getting that efficiency to show up on consumer-grade or older enterprise hardware (think dual 3060s instead of a rack of H100s) requires a runtime that understands how to route, cache, and quantize those experts without wasting memory or stalling on prefill.
That’s the gap Project Maya is targeting. The demonstrated results show a 22-core workstation from several years ago producing usable tokens-per-second numbers on models in the DeepSeek V4.1 Flash and GLM 5.3 class. That’s a meaningfully lower barrier to entry than the multi-GPU server setups these models were originally expected to need.
What can you actually build with it? #
The practical test documented wasn’t a benchmark chart, it was a real build: a browser-playable on-rails shooter called Turret Control, styled after World War II arcade shooters like Medal of Honor: Allied Assault, built around roughly 350 million tokens of generation and about 56 commits over a couple of days, entirely with GLM 5.3 running through Project Maya. The game includes wave-based difficulty scaling, adaptive enemy behavior so no playthrough is identical, a cel-shaded visual effect, damage mechanics, and multiple enemy and vehicle types.
That kind of result is a more useful signal than a synthetic benchmark. It shows the runtime holding up over a long, iterative coding session (hundreds of commits, sustained context use, long single-session generations) rather than just handling a one-shot prompt. For developers, that’s the real question: not “can it generate a function,” but “can it sustain a multi-day build without falling apart or slowing to a crawl as context grows.”
Simpler creative tasks also held up well. Asked to generate an animated SVG of a cat walking on a fence, a classic test for checking how well a model handles constrained, visually-evaluable code generation, GLM 5.3 produced a complete scene: a cat with visible whisker detail, a collar, blinking stars, animated clouds, and a looping animation, all rendered from a single prompt. DeepSeek V4.1 Flash, run on the same prompt, took considerably longer (thousands of seconds of “thinking” time) and produced a comparatively simpler result, closer to a silhouette with a single eye and a more bulbous body shape.
Is Project Maya worth running over alternatives? #
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
For anyone already running Strata or stock llama.cpp specifically to use large MoE models locally, Project Maya is worth testing, especially if prefill speed or long-context performance has been a bottleneck. The gains shown (sub-10 to low-double-digit tokens per second on a 1-bit-scale 250GB-class DeepSeek checkpoint, and 50+ tokens per second on GLM 5.3 Flash) on genuinely old enterprise hardware suggest the optimizations are real rather than marginal. The tradeoffs are the usual ones for any fast-moving fork: newer checkpoint support arrives fast (the DeepSeek V4.1 Flash 1017 checkpoint had support within hours of release in one documented case), but that pace means less time for hardening compared to mainline llama.cpp. Anyone running it should expect to track releases closely and accept some rough edges in exchange for being first to support new model drops.
For hobbyists and local-AI enthusiasts with multi-GPU or high-RAM workstations sitting around, rather than access to datacenter-class hardware, this is the kind of project that extends what’s actually runnable. It doesn’t change what a model can do, but it changes who can run it and how large a model they can justify trying.
Frequently Asked Questions #
What is the relationship between Project Maya, Strata, and llama.cpp?
Llama.cpp is the base inference engine. Strata is a hybridized fork of llama.cpp with its own runtime modifications. Project Maya is a further fork of Strata, specialized for running very large mixture-of-experts models efficiently on consumer and older enterprise hardware.
Can Project Maya run DeepSeek V4.1 Flash and GLM 5.3 locally?
Yes. Both were demonstrated running through Project Maya, including a DeepSeek V4.1 Flash checkpoint (1017) that gained support within hours of its release, and GLM 5.3 Flash, which produced strong results on both coding and creative generation tasks.
What hardware do you need to run these models through Project Maya?
The demonstrated setup was a Dell Precision T5810 with dual RTX 3060 GPUs, a 22-core/44-thread Xeon E5-2696 v4 processor, and 256GB of RAM, far from top-tier hardware. It produced roughly 11 tokens per second on DeepSeek V4.1 Flash and 50-60 tokens per second on GLM 5.3 Flash, which suggests the runtime is optimized to work on hardware well below datacenter specs.
How is Project Maya different from running the standard quantized version in stock llama.cpp?
In testing, the standard 1-bit UD IQ1M quant run through stock llama.cpp on the same hardware produced notably slower output than the equivalent model run through Project Maya, largely due to how each runtime handles MoE-specific routing and memory management.
Is Project Maya stable enough for serious long-term projects?
One documented case involved a multi-day coding project (a full browser game) spanning roughly 350 million tokens and 56 commits, built using GLM 5.3 through this runtime stack without the session breaking down, suggesting it can sustain long, iterative workloads, not just short demos.