Mamba3 PsiV cache scaffold

This is a useful public example because it does not pretend an unfinished cache path is already a working optimization.

The right contract for a scaffold like this is fail closed. If the gate is turned on explicitly, the run should refuse to continue until the feature is implemented. A silent fallback would give the operator the wrong performance story and make it harder to tell whether the cache path was ever active.

That is why the checked-in example publishes the scaffold state itself. The interesting thing is not the missing implementation. The interesting thing is the refusal rule.

If these cache terms are new

For first-touch readers, three terms matter. PsiV is the per-step or per-chunk product v * psi, where v is the live activation and psi is the learned MIMO-side parameter carried by the kernel path. A scaffold means the integration seam is published early enough to inspect, but it is not yet sold as an active optimization. Fail closed means the gate refuses the run when the feature is requested before the implementation exists, so operators cannot accidentally publish "cache-enabled" numbers from a baseline lane. The smallest checked-in proof surface is PsiV cache scaffold example, where is_enabled(...), refuse_if_gated(...), and scaffold_status() keep that contract explicit. The broader cluster context is split on purpose: Mamba3 kernel journey explains why this cache even looks tempting, and Mamba 3 parallel performance explains why it still has to earn a measured runtimeQuick term guideRuntime boundariesWhy MegaCpp pays first-compile and recompile costs in exchange for steady-state throughput, and the operational rules that keep torch.compile,…GroundingThe Compile-Time Tax We Accept for Runtime Speed Regional compile without losing the plot receipt before it graduates from scaffold status.

Why this is better than a quiet fallback

That is the same design instinct behind how we keep a patch lane and one morning of bugs: fail closed, leave a visible receipt, and do not let a quiet fallback contaminate later performance claims. It is also why throughput vs quality knobs treats silent path changes as fake knobs rather than real trade-offs, and why Mamba 3 parallel performance treats the cache as "measure the ceiling first" work instead of an already-landed win.

Performance scaffolds are dangerous when they lie. A clean refusal is noisy, but honest. A quiet fallback is easier in the moment and worse for every later benchmark, profiling run, and regression investigation.

A scaffold also needs a visible state surface. If the gate trips, the run record should show that the feature was refused, not merely absent. That is the same artifact-first debugging stance used in Modal Debugging Guide for Training and Benchmark Failures.

What the scaffold actually guarantees

The checked-in scaffold is intentionally narrow. It guarantees that the gate is visible, that enabling it without a real implementation refuses execution, and that the run record can distinguish "feature requested but unsupported" from "feature never enabled." That is the useful public artifact here. The kernel-side motivation lives in Mamba 3 kernel journey, and the perf-side reason for caring lives in Mamba 3 parallel performance. The code-level bridge is straightforward in the checked-in sample: the cache gate is explicit, and the refusal message tells the operator to leave that gate off rather than silently taking a cold path.

The visible status surface is more specific than a single supported/unsupported bit. In the checked-in sample, scaffold_status() reports Python-side precompute, global-memory pooling, and the two cache-input reuse paths as separate unfinished stages. That matters because a future implementation can land one phase without pretending the whole cache is complete, and the run record can still say exactly which part of the cache path remains scaffolded.

One more useful boundary from the local checked-in code is the memory story: this cache is intentionally intra-step, not cross-step. The public-safe sample keeps that implicit, while the local runtimeQuick term guideRuntime boundariesWhy MegaCpp pays first-compile and recompile costs in exchange for steady-state throughput, and the operational rules that keep torch.compile,…GroundingThe Compile-Time Tax We Accept for Runtime Speed Regional compile without losing the plot implementation sketch behind it spells the opportunity as one (B, S, H, R, P) activation-side materialization whose only honest first question is "does one saved materialization move the receipt enough to be worth the memory?" That is why this article keeps sending readers back to Mamba 3 parallel performance instead of promoting the scaffold itself to a speedup claim.

The other useful line from the research brief is that PyTorch grad-mode surfaces still live on a different layer than the cache gate. torch.no_grad() or torch.inference_mode() can reduce bookkeeping around an already supported path, but they do not stand in for a missing PsiV cache implementation. The honest contract is still the explicit cache flag plus a visible refusal when that flag is requested too early.