Slurm: support Qwen3.8-capable vLLM runtimes #1085

Priority Level

High (Major improvement)

Problem

DD Slurm's vLLM runtime gate blocks migration of an existing Qwen/Qwen3.8-Flash-Next workload. The resolver currently admits only 0.21.x and 0.22.x. Our existing model-specific serving artifact reports 0.1.dev20073+g8e685d198 and is rejected at preflight; switching to the supported official 0.22 image also cannot load this checkpoint.

Reproduction and confirmed results

Tested the Slurm integration at 9ba05f5451f99df65dbf3835916139e23ad523e4, with hosted-provider PR #1080 applied at 4be9ff26249f09f751cff22234f9f84e9f4e3841. The runtime gate is unchanged by that PR.

1. Native DD Slurm image import/inspection succeeded for vllm/vllm-openai:v0.22.0, pinned to OCI digest sha256:0fec7ec5f3e6bc168e54899935fb0557da908a4832a1dbc88e2debcf2f889416. Inspection correctly reported vLLM 0.22.0.

2. Inside that image on a CPU allocation (aarch64, Transformers 5.9.0), load the same checkpoint's config:

   from transformers import AutoConfig
   
   AutoConfig.from_pretrained(
       "/models/Qwen3.8-Flash-Next",
       local_files_only=True,
       trust_remote_code=False,
   )

   Result: ValueError: The checkpoint you are trying to load has model type qwen4_exp but Transformers does not recognize this architecture.

   Its config declares Qwen4ExpForConditionalGeneration with no auto_map; the image's vLLM registry also lacks that architecture. This check required no GPU allocation or weight loading.

3. The existing runtime validator rejects both the model-specific development version and 0.30.0, reporting that only 0.21.x and 0.22.x are supported.

Proposed path

Qualify a Qwen-capable upstream runtime and extend the tested release coverage, including a small generation/collection smoke with the existing checkpoint and inference settings. The upstream Qwen recipe currently specifies stable vLLM >=0.30.0 or nightly; those runtimes have not yet been qualified with DD Slurm.

Document the supported path for model-specific/nightly images and preserve the specific version rejection in preflight errors. If an opt-in compatibility path is needed, bind it to the inspected image digest and explicit qualification rather than accepting every version or rewriting its reported version.

Investigation and context

• Runtime gate and rejection.
• Image import packages the selected upstream runtime into SQSH; it does not add missing model implementations. Rebuilding the same 0.22 image therefore does not resolve this gap.
• Hosted-only CPU generation and collection passed under feat(slurm): support hosted models through native DD provider settings #1080. Mixed-provider SQL qualification remains blocked by this independent local-serving compatibility issue; no end-to-end success is claimed.
• Related: Run Slurm generation without a client image using a versioned vLLM serving image #969 (versioned serving images), Resolve deployment-owned vLLM serving plans for Slurm #866 (serving resolution), Support external model providers in Slurm runs #1079 (hosted providers).
• Reviewed existing issues and found no duplicate covering this model/runtime gap.

Checklist

• I've reviewed existing issues and the documentation.
• This is a design proposal, not a "please build this" request.