​作者​：昇腾实战派
​知识地图​：https://blog.csdn.net/Lumos_Lovegood/article/details/161601003

背景概述

在基于 vLLM-Ascend 框架部署 Qwen3.5-27B 进行推理服务的过程中，部分场景下服务在启动后出现异常崩溃，表现为 Worker proc VllmWorker-1 died unexpectedly, shutting down executor. 错误。本文基于实际排查过程，系统分析问题根因，并提出可复用的优化方案。

问题现象

服务启动后，日志中出现如下关键错误：

Worker proc VllmWorker-1 died unexpectedly, shutting down executor.

伴随该错误，上游请求无法正常处理，服务整体不可用。通过查看日志与运行时监控，发现异常发生在推理任务执行阶段，且与输入数据质量及资源配置密切相关。

问题分析

1. 上游输入数据异常(直接原因)

通过分析plog日志发现，多个异常调用链中存在以下三类上游输入问题：

1）图片格式不合法

PIL.UnidentifiedImageError: cannot identify image file

说明传入的图像数据无法被 PIL 识别，可能原因包括：图像文件损坏或非标准格式

2）图片尺寸异常

ValueError: absolute aspect ratio must be smaller than 200, got 444.66

该错误表明输入图像存在极端宽高比（如 1334x3），超出模型支持的范围。

3）对话模板错误

System message must be at the beginning.

说明客户端发送的messages结构不符合Qwen模型的对话模板要求。

综合上面的问题，plog日志表明上游业务传递的数据存在严重问题。

2. 推理服务器配置不当（根本原因）

服务运行环境为 800I A2 单机四卡，每卡显存 32GB。但推理配置参数显著高于官方推荐值，导致显存使用严重超限。
推理参数对比官方文档：

配置项	官方推荐值	当前配置值
显存	64GB	32GB
gpu-memory-utilization	0.90	0.95
TP（Tensor Parallelism）	2	4
max-model-len	133000	262144
max-num-seqs	32	128

发现在显存32G情况下，相关推理服务参数配置仍高于官方指引(显存64G)。

显存占用估算：

Total Cache ≈ 模型权重 + KV Cache（约27B×2Bytes）+ 128 × 256K × 2Bytes × 4卡 ≈316GB
发现客户侧配置明显超出实际物理显存阈值 4×32G=128G 。

问题根因

推理服务在显存资源严重不足的条件下，叠加上游输入数据存在格式错误、尺寸异常等问题，导致在处理请求时触发内存溢出与异常退出，最终引发进程崩溃。资源超限是根本原因，输入异常是直接诱因，二者叠加导致服务不可用。

解决方案

1. 推理侧：环境配置相关参数遵循官方推荐配置，或根据实际硬件资源进行适度下调。建议参考 Qwen3.5-27B 官方部署指南 进行配置优化。
2. 数据输入侧：优化客户端请求，规范化输入数据，如：

• 检查图片格式：确保上传的图片是常见格式（JPEG、PNG等），且文件没有损坏。
• 添加尺寸过滤：在上传或处理图片之前，对其进行尺寸检查，过滤掉宽高比异常(>200)或尺寸极端(如1334x3)的图片。
• 规范消息结构：严格按照Qwen模型的对话模板构造messages；确保role为user的消息包含有效请求，system消息必须位于对话的开头等优化检测机制等。

总结

本问题通过配置合理推理参数、严格校验输入数据，可有效避免因资源超限或数据异常导致的服务崩溃。

📌 **最佳实践建议**：

• 始终以实际硬件资源为基准，避免盲目追求高并发与长序列；
• 在服务入口增加数据校验，拦截非法请求；
• 关注plog日志，及时发现并预警潜在 OOM 风险。