phi 4 multimodal vllm 部署

你手里有一张卡、一个多模态权重，想用 vLLM 把服务跑起来，结果卡在权重识别、图片输入格式或者显存不够上。这篇按「先对齐版本、再起服务、最后验图」的顺序走一遍，每一步给判断标准和排查动作；参数只给方向和取值思路，具体数字到站内页面按你的卡自行核定。

你手里有一张卡、一个多模态权重，想用 vLLM 把服务跑起来，结果卡在权重识别、图片输入格式或者显存不够上。这篇按「先对齐版本、再起服务、最后验图」的顺序走一遍，每一步给判断标准和排查动作；参数只给方向和取值思路，具体数字到站内页面按你的卡自行核定。

先说明一件事：多模态在 vLLM 里不是「什么模型都能直接吃」的，它按模型架构逐家适配。所以第一遍别急着调参，先回答「我这个权重，当前 vLLM 认不认」这个问题。认，再往下走；不认，换版本或换推理框架比硬试省时间。

先确认三件事：版本、权重、卡

顺序不能反。很多人一上来就调显存比例，其实是权重没被识别，调什么都没用。先把这三件事各自确认一遍，再动手写启动命令。

1. 确认版本支持范围到 /models/deploy 与 /models 查该权重在你当前 vLLM 版本的支持列表里在不在。不在就换版本或换框架，别硬试，报错信息通常不会直说「不支持」。
2. 核对权重目录完整性模型权重、config、processor 与图像预处理相关文件缺一个都会在加载阶段炸。先在本地把文件清单列出来跟来源页对一遍，再启动服务。
3. 按卡型先算显存参考 /compute/sizing 和 4090-vram-model-limit 的思路估一遍。要点：图片输入会额外吃显存，多模态比同参数的纯文本更紧，别按纯文本的余量去留。

启动参数怎么定：先跑通再调优

第一遍用最小可用配置，只开模型路径、端口和张量并行度，确认能起来；能起来之后再逐步加 max-model-len、batch 相关参数。这个顺序的价值在于：出问题时你能确定是「本来就起不来」还是「被你调崩的」。

• 张量并行张数、显存占用比例这类量级问题，参考 /compute/gpus 对照你实际卡型，具体取值不要背别人的，按自己卡容量试
• max-model-len 别照纯文本的惯用值直接抄，多模态的图片 token 会占上下文，先小后大
• 图片预处理相关的批大小与缓存参数，先保持默认，等服务稳定了再逐个动
• 每改一个参数就重启验一次，一次改三四个参数等于放弃定位能力

判断标准很简单：服务能在日志里打出「已就绪」并且不报显存相关警告，就算这一步过了。如果你不确定自己卡上合理区间在哪，去 /compute/gpus 核对当时的数字再定。

服务起了不等于能用：图片输入的验证动作

这是最容易被跳过的一步。服务监听成功、纯文本请求能返回，都不代表多模态通路打通了。要专门拿图去验。

1. 先用纯文字截图提问截一张有文字的图，问图里写了什么。返回内容能对上，说明图像通路至少没断。
2. 再用带表格或图表的图换一张结构复杂的图，看返回是否真的读到了图内容。纯文字截图能过，不代表表格和图表也能过。
3. 确认图片传法请求里图片的传法各家接口格式不同：URL、base64、本地路径的字段名都可能不一样。先确认服务端接受哪个字段，再写客户端，不然会一直 400/500。
4. 量一个延迟基线用 /tools/speed-test 的思路量一下单图请求的延迟，之后再谈并发，否则优化没有参照。

常见报错按这个顺序排查

报错不要从最复杂的可能性开始想，按发生阶段分三层查，效率最高：加载阶段、请求阶段、运行一段时间之后。

这个顺序的意义是：加载阶段的问题基本跟卡无关，先别怀疑硬件；请求阶段的问题多半在接口格式，不用动部署参数；跑久了才崩的，才轮到显存与并发这块。分层查能省掉大量来回试。