[furionw]

Why

The release branch can't serve MiniMax M3.1 Flash yet. Its stable vLLM and SGLang images don't run the model. Its frontend also decides how to parse M3 reasoning from the request, but the M3.1 Flash template ignores thinking_mode, so reasoning can leak into content. Open-source vLLM and SGLang now publish multi-arch images that serve the model, so this PR builds the vLLM and SGLang runtimes on them. TensorRT-LLM keeps its base: no public TensorRT-LLM build serves the model yet, so TensorRT-LLM images from this branch don't serve it either.

What Change

• MiniMax M3: reasoning parser state comes from the rendered prompt; guided output as content.
• Responses: phased commentary and final-answer items; TensorRT-LLM multimodal and vLLM import fixes.
• vLLM and SGLang runtime bases pinned to the public MiniMax M3.1 Flash images by digest.

Test Plan

• This PR's CI-built vLLM and SGLang images, GB300 aggregated
• Same inputs earlier: P/D on GB300 and B200; vLLM BFCL matches vllm serve. TRT-LLM unit tests pass.

Notes

• Published images. The published 1.6.0-minimax-m3.1-flash-dev.1 images were built from this PR's Dynamo source on pre-release engine builds (vLLM on CUDA 13.4.1, SGLang on CUDA 13.0.3, TensorRT-LLM 1.4.0rc1). This branch builds vLLM and SGLang on the public MiniMax M3.1 Flash images and keeps the stock TensorRT-LLM base, so it does not reproduce those images, and its TensorRT-LLM image does not serve the model. We will follow up on aligning the published tags with this branch.

🤖 Generated with Claude Code

[pvijayakrish]

Release-ops review. Holding off on approval for the two items below.

**1. The description says TensorRT-LLM images from this branch don't serve the model, while the published tensorrtllm-runtime tag does. Please either note this in the release notes / PR description or make the tag point at code that matches what was published.

2. vLLM test failures that look functional, not just API drift (vllm-runtime / Test cuda13.0, amd64, 11 failed / 1853):

• test_vllm_kv_events_api.py::test_block_stored_fields / test_block_removed_fields: BlockStored / BlockRemoved fields changed. These feed KV-aware routing, so the router may misread KV events on this base.
• test_vllm_renderer_api.py::test_engine_core_struct_contract (EngineCoreRequest changed) and test_vllm_api_contract.py::test_scheduler_output_new_connector_fields_remain_optional (SchedulerOutput.partial_tail_offloads is gone).
• test_realtime_handler.py: No module named 'scipy' — the new base doesn't ship scipy, so realtime transcription is broken on this image.
• test_vllm_request_processor.py video tests: imageio missing.

SGLang runtime tests (both arches), dynamo-runtime sequential tests and lychee are also red. Can you confirm which of these already fail on the release branch and which this PR introduces?

Looks fine:

• Both bases are pinned by digest. Good — the SGLang tag has already moved on Docker Hub (now 614b1509…), the pin protects the build.
• Dropping baseline_sbom attributes the whole image in /legal, which is the conservative choice for a new CUDA 13.4 base.
• The CUDA 13.4 license_overrides.yaml entries are NVIDIA CUDA Toolkit packages under the same EULA mapping as the existing 13.0 entries.

Minor:

• nixl==1.5.0 / nixl-cu13==1.5.0 are now pip installed at build time without a hash pin.
• SGLang builds on the larger dev- image since no -runtime variant exists; worth a follow-up to switch once one is published.

Not reviewed: the Rust changes in lib/llm (preprocessor, Responses stream converter). Those need a lib/llm owner.

[furionw]

Thanks, Pravithra.

1. Published images vs this branch. All three published 1.6.0-minimax-m3.1-flash-dev.1 images were built on 2026-10-21 from the same Dynamo source as this PR, but on pre-release engine builds that are not public: vLLM (CUDA 13.4.1), SGLang (CUDA 13.0.3) and TensorRT-LLM 1.4.0rc1. This branch builds vLLM and SGLang on the public MiniMax M3.1 Flash images and keeps the stock TensorRT-LLM base, so it cannot reproduce the published images byte-for-byte, and its TensorRT-LLM image does not serve the model. I added this as a Notes section in the description; we will follow up on aligning the published tags with the branch.

2. Which failures this PR introduces, compared with the release branch's own CI at 42e61e00 (post-merge run 38325632535):

Job	At 42e61e00	Cause	From this PR
vLLM tests (11 failed)	1 unrelated failure (test_vllm_omni)	new engine base	yes
SGLang tests (2 failed)	passed	new engine base	yes
dynamo-runtime sequential (10 profiler tests)	passed	pandas 3.1 DataFrame.drop(inplace=) deprecation; fixed on main by #17161	no
SGLang Snapshot Deploy Test	skipped	CI infrastructure: snapshot-agent pods unschedulable (unbound PersistentVolumeClaims)	no
lychee	n/a	2 dead external links in docs this PR does not touch	no

On the ones this PR introduces:

• KV events: the new vLLM appends ownership and session_id to BlockStored, and ownership to BlockRemoved. The router's decoder on this branch already parses ownership and skips extra trailing elements (lib/kv-router/src/zmq_wire/deserialize.rs), so KV events are not misread; the tests pin vLLM 0.31's field list.
• EngineCoreRequest gains a trailing kv_hints. Dynamo does not construct it (vLLM's input processor does), and the worker already passes kv_hints. SchedulerOutput.partial_tail_offloads is not referenced outside tests. Both are stale guard tests.
• scipy / imageio are missing from the public vLLM image. They back realtime audio transcription and the video encoding helper; MiniMax M3.1 Flash uses neither, and video input decoding works on this image.
• SGLang: test_external_mm_hashes_rebuild_padding_after_hash_override uses a stale fake item (this SGLang calls item.padding_sequence()). test_sglang_pad_value_formula_unchanged reflects a real change: this SGLang derives four 62-bit pad values per image instead of one 30-bit value, so the router cannot predict KV cache hits for image prefixes on SGLang. Responses are not affected. We will follow up on main.