背景概述

在基于 vLLM-Omni 框架部署多模态大模型（如 Qwen-Image、Qwen-Image-Edit）的推理服务过程中，我们发现服务虽能正常启动并完成推理流程，但在返回结果阶段频繁抛出 pydantic_core._pydantic_core.ValidationError 错误，导致客户端收到 500 Bad Request 响应，且图像等多模态输出无法正常返回。该问题虽未造成服务崩溃，但严重影响了推理结果的可用性。

本文将从问题现象出发，深入分析根因，并提供多种可选的解决方案，帮助开发者快速定位并修复该类兼容性问题。

问题现象

服务状态：vLLM-Omni 服务可正常启动，推理过程无异常中断。

错误表现：在返回 ChatCompletionResponse 时，抛出如下异常：

pydantic_core._pydantic_core.ValidationError: 1 validation error for ChatCompletionResponse

客户端表现：请求返回 HTTP 500 错误，图像内容无法解码，但服务未崩溃。

复现环境：

模型：Qwen-Image / Qwen-Image-Edit

软件版本：quay.io/ascend/vllm-omni:v0.18.0

硬件平台：Atlas 800I A2（双卡混部）

根因分析

问题定位过程如下：

1. 异常溯源：错误发生在 serving_chat.py 文件中对 ChatCompletionResponse 的序列化阶段，具体为 UsageInfo 字段的 Pydantic 校验失败。

2. 模型定义检查：查阅 vllm/entrypoints/openai/engine/protocol.py 中 UsageInfo 的定义，确认其结构符合上游 vLLM 的规范，理论上不应触发校验错误。

3. 代码冲突排查：进一步发现，项目中存在一个平台级补丁文件：

   vllm_ascend/patch/platform/patch_minimax_usage_accounting.py

  该文件通过 猴子补丁（Monkey Patching） 方式，重写了 engine_protocol.UsageInfo、chat_protocol.UsageInfo 等核心类的定义，引入了新的字段 completion_tokens_details，并修改了类型定义。

4. 校验机制冲突：vLLM 内部的 Pydantic 模型默认配置为 extra='allow'，允许额外字段。但当补丁修改了原始模型结构后，若返回数据中包含未定义字段或类型不匹配，将触发校验失败。

5. 确认影响范围：经与项目维护者确认，该补丁仅用于优化 Minimax 场景下的 Token 统计逻辑，在使用 vLLM-Omni 时并非必需，可安全回退。

解决方案

方案一：规避校验限制（推荐临时方案）

由于 UsageInfo 仅用于统计 Token 消耗，不影响推理核心逻辑，可将其从 Pydantic 模型实例改为字典结构，绕过校验机制。

修改文件路径：  

/vllm-workspace/vllm-omni/vllm_omni/entrypoints/openai/serving_chat.py

修改位置：第 2257–2261 行

修改前：

usage=UsageInfo(
    prompt_tokens=len(prompt.split()),
    completion_tokens=1,
    total_tokens=len(prompt.split()) + 1,
)

修改后：

usage = {
    "prompt_tokens": len(prompt.split()),
    "completion_tokens": 1,
    "total_tokens": len(prompt.split()) + 1
}

效果：Pydantic 校验错误消失，服务返回正常，图像可成功生成。

方案二：回退平台补丁（推荐长期方案）

若无需 Minimax 场景的特殊优化，可直接禁用该补丁。

操作步骤：

编辑补丁初始化文件：

vim /vllm-workspace/vllm-ascend/vllm_ascend/patch/platform/__init__.py

注释以下两行（注意依赖关系，不可单独删除）：

# import vllm_ascend.patch.platform.patch_minimax_usage_accounting  # noqa
# import vllm_ascend.patch.platform.patch_glm_tool_call_parser  # noqa

效果：恢复 vLLM 原生模型定义，校验逻辑正常，问题彻底消除。

长期建议

vLLM-Ascend 主线分支已对相关补丁进行重构，避免全局污染。建议升级至 `vLLM-Omni` 镜像版本 **> v0.18.0**，即可自动规避该问题，无需手动修改代码或配置。

验证方法

使用以下命令验证修复效果：

启动服务：

vllm serve /data2/Qwen-Image/ --omni --host 0.0.0.0 --port 1025 -tp 2

发送测试请求：

curl -s http://localhost:1025/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {"role": "user", "content": "A beautiful landscape painting"}
    ],
    "extra_body": {
      "height": 1024,
      "width": 1024,
      "num_inference_steps": 50,
      "true_cfg_scale": 4.0,
      "seed": 42
    }
  }' | jq -r '.choices[0].message.content[0].image_url.url' | cut -d',' -f2- | base64 -d > output.png

验证结果：

- 当前目录生成 output.png 文件，内容为有效图像。

- 服务日志中无 ValidationError 或 Pydantic 相关错误。

总结

本问题源于平台补丁对 vLLM 原生模型定义的非预期修改，与 Pydantic 的校验机制产生冲突。通过 临时规避校验 或 回退补丁 ，可快速恢复服务稳定性。长期建议升级至更新版本，以获得更完善的兼容性保障。

该案例也提醒开发者：在使用第三方补丁或定制化模块时，需关注其对核心框架行为的影响，避免引入隐性兼容性问题。