A new version of Project Maya, inference software for running huge AI models locally, v1.1.28, was released on October 26, 2026 (JST). The update improves how data is fed from RAM to the GPU on Linux systems using a single NVIDIA GPU. In a comparison on the same PC with an RTX 3090, the developer measured DeepSeek text generation speed rising from 12.9 to 27.8 tokens per second, about 2.2 times faster. The release also adds 512K and 1M context lengths as selectable options. However, the speedup and the 1M-context support were verified in different environments, so users should not assume they can get both benefits at once.
Project Maya is software that lets huge language models built on a Mixture of Experts (MoE) architecture run even with limited GPU memory. MoE models select the parts of the network (experts) needed for each input, and Maya takes advantage of this by distributing experts across GPU VRAM, system RAM and NVMe SSD according to how often they are used. Supported models include the 321-billion-parameter GLM-5.3-Flash and the 748-billion-parameter DeepSeek-V4.1-Flash-1017. Running on one GPU does not mean the whole model fits in VRAM. For example, Maya-S for DeepSeek requires about 340GB of memory including Engram, and the actual amount varies with the quantization method and configuration.
Better RAM-to-GPU data feeding makes generation about 2.2 times faster
The core of the speedup is a rework of the path that supplies experts held in RAM to the GPU. The new method lets the GPU reference data in RAM directly, eliminating the intermediate buffer copy that was previously required. The new transfer path is also used when DSpark's speculative decoding verifies multiple tokens, and loaded experts are now kept in a cache in VRAM. Previously, during DSpark verification the GPU could sit idle while the CPU computed experts that were not in VRAM. The change aims to cut that waiting time and improve GPU utilization.
The pull request (PR) #476 that implemented the change includes measurements from a PC with an RTX 3090 (24GB), a Ryzen 5 5600X and 125GB of DDR4 memory. Using Maya-XS and DSpark with a fixed expert usage profile and comparing against v1.1.27, generation speed at a 64K context setting rose from 12.9 to 27.8 tokens per second. After a 128K-token input it went from 14.0 to 23.2 tokens per second, and after a 256K-token input from 15.9 to 26.1 tokens per second, showing clear improvement in every case. The size of the gain varies with input length and processing conditions.
Prefill speed, at which the model reads the input text, was almost unchanged. For 8K, 128K and 256K-token inputs, the previous version processed 563, 1,158 and 1,417 tokens per second respectively, compared with 560, 1,148 and 1,407 with the new method. In other words, the improvement mainly helps the answer-generation stage and does not shorten the time to read long documents by the same proportion.
mw00, the Project Maya maintainer, also reported a generation speedup of about 14% on an NVIDIA V100 paired with Maya-XS, and about 35% under conditions with little free VRAM. These results cannot be applied to every GPU, however. Because the division of computation between CPU and GPU and the order of operations change, differences in the least significant bits of outputs may arise. The developers' tests found no substantial change in perplexity, but generated output is not guaranteed to match exactly.
1M context support comes with time and VRAM costs
v1.1.28 adds 512K and 1M as selectable DeepSeek context lengths. Previously the settings screen and setup offered only up to 256K, but the change makes the model's native maximum of 1,048,576 tokens available. This is the limit for the whole context, input and output combined, so space must also be reserved for generated answers. Note that this support does not come from changes to the inference engine itself or from RoPE scaling, which extends positional handling. It simply makes the range the model already supported selectable from the settings.
The developer who implemented it published long-context test results in PR #442. The tests used a total of nine GPUs with tensor parallelism set to 8, and a 3.5-bit quantized model from LibertAIDAI. Using files in the repository as the input document, the tester embedded three codes at the 10%, 50% and 90% positions and checked whether they could be retrieved correctly. All three codes were recovered for inputs of 118,084, 497,760 and 1,028,310 tokens.
Processing time grows with input length, however. Reading 118,084 tokens took 2.3 minutes, 497,760 tokens took 10.4 minutes, and the largest input of 1,028,310 tokens took 23.8 minutes. Speed at the maximum input was 720 tokens per second. The maximum-input test also used the v1.1.26 inference engine and split the input into chunks with --prefill-chunk 2048. The update therefore does not mean a single GPU can comfortably handle a million tokens. Likewise, being able to retrieve information embedded at specific positions does not guarantee comprehension of long text in general.
Extending the context also directly affects VRAM consumption. According to the developer, holding context requires about 1.1KB of VRAM per token position on each GPU in the tensor-parallel group. This space competes with the expert cache, so a longer context leaves room for fewer experts in VRAM and may increase RAM reads and CPU computation. In addition, the compute cost of the indexer used in input processing grows with the square of input length. To make use of a 1M context, users must weigh load time and VRAM usage as well as the maximum input length.
Speedup depends on the environment; a roughly 19% slowdown was reported
The speedup does not apply equally in every environment. In GitHub Issue #496, user talisp reported lower generation speed on an NVIDIA L40S-48Q vGPU (48GB) on Linux. The test setup was a virtual machine with a Xeon Platinum 8580, 32 virtual CPUs (vCPUs) and about 504GB of RAM, with 28 threads assigned to inference. In a comparison using the UD-Q8_K_XL quantized model and DSpark, v1.1.26 averaged 42.4 tokens per second, while v1.1.28 with default settings averaged 34.4 tokens per second, a drop of about 19%.
Further analysis reported a drop of about 17% even when the share of experts handled by the CPU was matched. The reporter also corrected an earlier claim: the average-speed gap seen against the old version with the new data path disabled was due to differences in the share of experts the CPU handled, which varied with the generated text. Log analysis showed that in this environment, computing directly on the CPU was faster than transferring from RAM to the GPU, and transfers through the new path were not actually occurring. The fact that performance dropped anyway suggests additional cache management or synchronization overhead may be a factor, but the cause has not been identified.
The new data supply path is enabled by default on Linux with a single NVIDIA GPU and no auxiliary GPU. Windows, AMD GPUs and multi-GPU configurations keep the previous path. The main changes and test results are summarized below.
| Environment / change | Status | Measured result / main change | Caveats |
|---|---|---|---|
| New data supply path, Linux, single NVIDIA GPU | Enabled by default | 12.9→27.8 tokens/s on RTX 3090 | Compared with v1.1.27. Prefill speed nearly unchanged |
| DeepSeek 512K / 1M context | Selectable in settings | Processed input of up to 1,028,310 tokens in 23.8 minutes | Tested on 9 GPUs total. Max-input test used v1.1.26 |
| Linux, L40S-48Q vGPU | New path enabled by default | Average 42.4→34.4 tokens/s, about 19% lower | Compared with v1.1.26. Individual user report |
| Extra GLM / AMD features | Optional | Combination with layer splitting, expert computation for RDNA, etc. | Disabled by default |
| Extra DeepSeek multi-GPU features | Optional | Distributed DSpark processing, expert placement on auxiliary GPUs | Auxiliary-GPU feature is Linux only. Disabled by default |
Because the baseline versions, model configurations and CPU performance differ between the RTX 3090 and L40S tests, the absolute speeds cannot be used to judge which GPU is better. What matters is that whether transferring data from RAM to the GPU is more efficient than computing directly on the CPU depends on the hardware configuration. In environments with strong CPU compute in particular, increasing transfers to the GPU does not necessarily speed things up. All current measurements are reports from developers and users, and independent third-party verification has not been completed.
Extra features for Windows and AMD, and how to update
This release also adds features for Windows, AMD GPUs and multi-GPU setups. For running GLM on AMD GPUs, there is now a feature that combines model layer splitting with expert offloading assistance, along with an expert computation kernel optimized for RDNA. For DeepSeek multi-GPU setups, DSpark's speculative decoding can be distributed within the tensor-parallel group, reducing memory use on the first GPU. A feature for assigning experts that do not fit in VRAM to an auxiliary GPU is also provided, but it is Linux only. All of these are disabled by default and require individual configuration.
The user interface has also been improved. Display flicker and unnatural scrolling when generating long code have been fixed, and auto-following of new output now stops when the user scrolls up. The sidebar now shows the model name and logo. The update can be run from "About > Update" in the dashboard; to update manually, run ./setup.sh after git pull. On Windows, use START-MAYA.bat. Changed parts must be recompiled, but models do not need to be downloaded again.
When applying the update, first check the startup log to confirm the new data supply path is enabled. Then, using the same model, quantization method, input data and settings, compare prefill speed and generation speed separately. The 1M context support widens the scale of input that can be handled, but users should be aware of the increase in VRAM consumption and load time that long inputs bring. Project Maya v1.1.28 benefits most in environments where transferring data from RAM to the GPU reduces CPU-side waiting, and the actual effect will depend on each PC's configuration and workload.