What happened
Project Maya’s changelog records v1.1.35 on October 28, 2026. Its lead GLM change is for NVIDIA systems: when GPU memory can hold the model’s complete expert pool, Maya keeps every expert in VRAM. The changelog says this matches the existing behavior on AMD. Under the earlier behavior, a long prompt could evict experts; with the full pool resident, decode remains at full speed instead of incurring that eviction-related slowdown.
The release frames this as a conditional runtime behavior, not as a new model capability. “Complete expert pool” means the relevant experts must fit in the available GPU memory. When they do, Maya does not swap experts out during a long prompt. The intended consequence is steadier decode performance after prompt processing. When they do not fit, the release says behavior is unchanged. Operators that need the former behavior can explicitly restore it with MAYA_GLM_COMPLETE_POOL=0.
The project cites issue #474, attributed to @walker2kk, and gives one performance measurement: a reporter’s split across four A100 GPUs measured 2.5x decode. This is a reported observation from a particular hardware arrangement. The supplied release note does not describe a benchmark suite, workload, prompt length, output length, batch size, quantization, driver version, or repeated-run statistics. It also does not state whether the result refers to an average, a peak, or a comparison against a specified old configuration.
Several other items appear in the same v1.1.35 notes. Maya remeasures CPU-lane tunings after a driver or peer-to-peer (P2P) change. It keeps GLM picture chats in conversation slots. It also says Qwen-3.8-Flash-Next long prompts are faster on three or more GPUs and fixes MiniMax --parallel eviction of picture conversations. The supplied material provides no quantitative measurement for those separate changes. They should not be read as confirmation that the 2.5x GLM figure transfers to Qwen, MiniMax, picture chats, or CPU-lane work.
This release is therefore about the inference harness surrounding GLM rather than about a GLM weight release, a hosted endpoint, or a change in model availability. The source provides no pricing, license change, access change, or hardware purchase recommendation. It describes a new default behavior for a bounded condition: a Project Maya deployment on NVIDIA where the complete GLM expert set can remain in VRAM. The release also makes clear that the old pool behavior remains available as an opt-out setting.
For an operator, the practical sequence is limited but concrete. First establish the VRAM budget after accounting for the deployed model and runtime requirements. Then determine whether the full expert pool fits under that budget. Only then is the new residency path relevant. A comparison should use the team’s own long-prompt and decode workloads, because the supplied result does not establish a common gain across requests or installations.
What the archive adds
Project Maya is an MIT-licensed inference stack that runs the 321-billion-parameter GLM-5.3-Flash mixture-of-experts model on Linux workstations. covered Maya as a local inference harness for GLM-5.3-Flash. This is a new fact in a known Project Maya thread: the earlier note focused on the deployment stack, while v1.1.35 adds a specific expert-residency change and a reported result on four A100s.
Trend signal
This supports harness architecture outlives model choice: a deployment harness can create meaningful differences through runtime behavior around a model, including how experts occupy GPU memory. The evidence is narrow, however. One changelog entry and one reported split measurement establish a concrete implementation change, not a broad comparison showing that harnesses matter more than model choice across production systems.
Why it matters
For a team serving a large mixture-of-experts model locally, expert residency is an operational variable rather than merely an implementation detail. Long prompts can affect what stays in fast GPU memory, making decode performance dependent on memory pressure as well as model choice and GPU count. If the entire pool fits, Maya’s new behavior gives an operator a defined configuration to test against representative long-context workloads.
The reported 2.5x result may be material for an owner of a four-A100 deployment. But it is not enough to turn into a capacity forecast, a cost-saving claim, or a universal recommendation to change hardware. The source does not show the memory threshold, the GLM variant, or the conditions behind the measurement. It does establish an actionable distinction: systems able to keep the entire expert pool resident have a new runtime path to evaluate; systems that cannot do so should expect no behavioral change from this item.
That distinction matters when teams are diagnosing uneven inference performance. Before attributing slower decode solely to the model or to a driver, they can check whether expert residency changes as a prompt grows. The release’s opt-out switch also gives operators a way to compare the new and old pool behaviors in their own environment, rather than relying solely on the reported four-GPU result.
Limits and uncertainty
The supplied changelog excerpt does not specify the GLM variant, quantization, prompt length, decode batch, software and driver versions, baseline configuration, or measurement procedure behind the 2.5x result. It does not say how often the gain appears, whether it changes time-to-first-token, or how much memory the complete expert pool requires. The result is attributed to a reporter’s 4x A100 split, not presented as a broad benchmark.
The source does not establish effects on other GPU counts, other NVIDIA cards, other GLM configurations, or hosted inference. It also does not explain the performance trade-offs of retaining all experts in VRAM beyond the stated fit requirement. The fit-in-VRAM condition is explicit; outside it, the release says behavior is unchanged. Separate notes about Qwen and MiniMax are not evidence for the GLM claim.
Skill to build now
Build a small inference regression test that separates prompt processing from decode. Run a representative long prompt and fixed output generation before and after updating Maya, record VRAM use and decode throughput, then repeat with MAYA_GLM_COMPLETE_POOL=0. The useful output is not a single headline multiplier but a repeatable record of whether the full pool fits and whether residency changes latency on the requests your application actually serves.
Reader takeaway
If your team runs GLM through Project Maya on NVIDIA and can fit every expert in VRAM, v1.1.35 offers a concrete residency behavior to test against long prompts. Treat 2.5x decode as a reported result from one 4x A100 split, not a promised speedup. If the complete expert set does not fit, the changelog promises no change in behavior.