MINA LABS
Start creating free
vLLM has published v0.29.0rc1, a release candidate focused on one bugfix: handling padded routes in CUTLASS mixture-of-experts permutations. The release is documented in the official vLLM release notes, published on September 2, 2026.
The change is narrow, but it targets a part of the inference path that can affect how work is arranged before execution. The release notes identify the fix as issue #54747. They do not describe a new model, a new API, or a benchmark result.
Mixture-of-experts models do not send every input through every part of the network. A routing step selects which experts should process particular tokens. The system then has to organize those tokens into the right layout for the expert computation and restore the results to the expected order afterward.
That organization is where permutations come in. CUTLASS is used for GPU computation, and vLLM’s title for this release points specifically to the CUTLASS MoE permutation path. “Padded routes” suggests that some routed batches include added space or entries to make the computation fit a required layout. The bugfix is intended to handle that case correctly.
For a developer, this is less about visible output quality and more about execution reliability. If an inference backend mishandles a routed or padded batch, the problem may appear only with particular prompts, batch shapes, sequence lengths, or expert assignments. A narrow fix can therefore matter even when the release does not add a headline feature.
The available announcement does not say that v0.29.0rc1 improves throughput, lowers memory use, or changes latency. It also does not provide a before-and-after example. The practical takeaway is more limited: teams testing CUTLASS-backed MoE inference have a release candidate that includes a specific correction for padded route handling.
Because this is an rc1 release, it should be treated as a candidate for validation rather than an automatic drop-in upgrade. Makers running a stable production service would want to test the release against the model and batch patterns they actually use. The relevant checks would include successful generation, output consistency, error rates, and resource behavior on workloads that exercise MoE routing. Those are recommended validation steps, not results reported by the release.
What it costs and whether it is on Mina Labs
The vLLM release itself is an inference-engine update, not a separately priced image or text generation model. On Mina Labs, the relevant model access is available here, so makers can use the platform rather than assembling the serving stack themselves.
For one image from the available image-generation route, the price is 8. The announcement does not state that v0.29.0rc1 changes the price, image quality, supported formats, or model behavior on Mina Labs. Its contribution is at the serving layer: a fix for a specific CUTLASS MoE routing path in vLLM.
That distinction matters when deciding whether this release is useful today. If your work does not use an affected MoE path, this announcement may not change your workflow. If you do depend on that path, the release is worth evaluating because the fix is aimed at correctness in a part of the execution pipeline that can be difficult to test exhaustively.
What we would use it for
We would use v0.29.0rc1 as a targeted validation release for workloads that run mixture-of-experts models through CUTLASS kernels. First, we would compare the same prompts and batch shapes before and after the update. The goal would be to check whether cases involving padded routing now complete consistently.
Next, we would test different batch sizes and sequence lengths. Route padding often becomes relevant when inputs do not divide neatly into the layout expected by a kernel. These tests could help expose the class of edge case named in the release without assuming that every workload is affected.
We would also use it when investigating discrepancies between ordinary single-request tests and batched production traffic. A system can appear healthy under simple prompts while taking a different route through its kernels under concurrent load. The release gives teams a concrete version to test when padded CUTLASS MoE permutations are part of that path.
There is no evidence in the announcement that this release adds a user-facing capability. Its value is operational and specific. For makers using affected vLLM inference paths, that can still be enough reason to test it. For everyone else, the sensible action is to monitor the release and wait for a stable version or clearer compatibility details before changing a working deployment.