vllm部署minimax模型

General
1

FL2VA mode: when uploading multiple images via multipart/form-data, the server parses input_references as string instead of file object.

Steps to reproduce:

  1. Start the service:
    docker run --gpus all -v /data/models/MiniMax-H3/FL2VA:/model -p 30010:8000
    vllm/vllm-omni:minimax-h3
    vllm serve /model --omni --host 0.0.0.0 --port 8000 --trust-remote-code --num-gpus 4

  2. Send the request:
    curl -X POST http://localhost:30010/v1/videos
    -F “prompt=test”
    -F “extra_params={“task”:“fl2va”,“duration”:5,“frame_indices”:[0,-1]}”
    -F “input_references=@/tmp/first.png;type=image/png”
    -F “input_references=@/tmp/last.png;type=image/png”

  3. Error response:
    Expected UploadFile, received: <class ‘str’>

Expected behavior:
input_references should be recognized as UploadFile type

Actual behavior:
input_references is parsed as string

Environment:
vLLM-Omni 0.26.0
Docker image: vllm/vllm-omni:minimax-h3

Additional notes:

  • Text-to-video (t2va) works normally
2

This is a known issue: in FL2VA mode, when sending multiple images as input_references via multipart/form-data, the server sometimes parses them as strings instead of file objects, causing errors like “Expected UploadFile, received: <class ‘str’>”. This is due to how FastAPI parses multipart fields and is not unique to your setup—other users have reported the same with similar curl commands and vLLM-Omni versions. The recommended approach is to ensure each input_references field is sent as a separate -F argument, as in your example, but if the server still parses them incorrectly, it is a server-side bug that needs to be fixed in vLLM-Omni’s request parsing logic for multi-file fields (see related discussion, MiniMax-H3.md).

Would you like more detail on possible workarounds or the relevant code paths?

Sources:

Hint: Mention @Herald in the post for followups.