企业官网建设流程全解析

Qwen-7B 和 Qwen-VL 这两个模型，一个管纯文本，一个管图文，放在阿里云上跑起来并不难，难的是把显存、并发和账单同时按住。我最近把这两套服务从零搭了一遍，中间踩了 CUDA 版本、vLLM 启动参数、多模态图片路径、并发锁这几个坑。下面把完整的部署路径、显存计算过程和参数选择逻辑摊开讲，适合手里有一张 24GB 卡、想在云上快速验证 Qwen 系列模型，或者准备把多模态能力接进业务系统的朋友。纯文本部分我会用 vLLM 起 OpenAI 兼容服务，多模态部分用 FastAPI 包一层，两个环境分开，避免依赖打架。整套流程不需要你在本地有一台像样的机器，租一台云上 GPU 实例，按小时算成本，验证完就释放，试错代价比想象中低。

1. 先想清楚：两个模型为什么要分开部署

1.1 纯文本和多模态是两种完全不同的负载

Qwen-7B 的请求链路很短：文本进、文本出，瓶颈在 token 生成速度和并发序列数。vLLM 这类推理框架能把多个请求的 KV Cache 分页管理，连续批处理一开，吞吐能翻上去。Qwen-VL 不一样，它多了一个视觉编码器，每张图要先过 ViT 变成图像 token，再和文本 token 拼在一起送进语言模型。图片解码、缩放、编码这几步会吃 CPU 和显存，而且单次请求的耗时波动很大，一张大图和一张小图的处理时间能差出好几倍。

我一开始图省事，想把两个模型塞进同一张 24GB 卡里，结果 Qwen-7B 刚把 KV Cache 预分配完，Qwen-VL 加载视觉权重时直接 OOM。后来改成两个独立实例，Qwen-7B 用 vLLM 跑高并发，Qwen-VL 用单并发队列跑图文请求，稳定性立刻上来了。这个取舍看起来多花了一份实例钱，但省掉了大量互相挤显存、互相拖慢的排查时间。小规模验证阶段可以分时切换，生产环境建议物理隔离，至少也要分两张卡。

1.2 显存账先算再买卡，别先买卡再试

云上 GPU 实例的规格很多，24GB 的 A10、16GB 的 T4、32GB 的 V100、48GB 的 A40，价格差得不少。买之前先把权重、KV Cache、激活值三块账算清楚，比开一台机器上去撞 OOM 高效得多。权重部分好算：7B 模型 FP16 大约 14GB，INT8 大约 7GB，INT4 大约 4GB；Qwen-VL 因为多了视觉编码器，FP16 权重大约 19GB。KV Cache 按公式估算：2 × 层数 × 隐藏维度 × 序列长度 × 批大小 × 字节数。Qwen-7B 是 32 层、隐藏维度 4096，FP16 下每个 token 的 KV Cache 约 0.5MB，8192 token 就是 4GB，批大小 8 就是 32GB，这还没算激活值。

所以 24GB 卡跑 Qwen-7B FP16，比较稳的配置是max-model-len4096、并发 8 左右，或者max-model-len8192、并发 2 到 4。Qwen-VL 的 19GB 权重加载完只剩 5GB 左右，图片编码和生成阶段的激活值一挤，24GB 卡就是“刚好能跑、不能并发”的状态。我建议 Qwen-VL 至少上 32GB 卡，或者用 INT4 量化把权重压到 6GB 左右再谈并发。下面这张表是我实际选规格时用的对照，数值是理论估算加实测修正，不是厂商宣传页上的理想值。

1.3 裸机、容器还是托管服务，三种形态怎么选

云上部署一般有三条路：直接开 GPU 裸机实例、用容器服务编排、或者用平台提供的模型托管服务。裸机最直接，SSH 上去装依赖、起进程，适合验证阶段，出问题好排查，但扩容和迁移要自己写脚本。容器适合生产，把 CUDA 运行时、Python 依赖、模型路径全打进镜像，换机器时拉起容器就能跑，缺点是镜像体积大，GPU 驱动和容器运行时需要额外配置。托管服务省运维，但自定义参数、私有模型、特殊后处理会受限制，成本也通常更高。

我的做法是：验证期用裸机加 conda，把启动命令和参数先跑通；稳定后把环境打成 Docker 镜像，模型文件放对象存储或共享盘，容器启动时挂载进去。这样既保留了调试灵活性，又能在扩容时快速复制。这里有个细节，模型文件不要直接放容器镜像里，一个 Qwen-VL 镜像能干到 20GB 以上，推送和拉取都痛苦。把权重放共享存储，镜像只装代码和依赖，启动时挂载/models，是更省事的做法。

2. 环境准备：驱动、CUDA、Python 依赖一次锁死

2.1 实例开通与磁盘规划

云上开 GPU 实例时，系统盘默认通常只有 40GB 到 60GB，装完驱动和 CUDA 就剩不了多少。Qwen-7B 权重约 15GB，Qwen-VL 约 20GB，再加上 Python 环境、日志、临时图片，我建议系统盘 100GB 起步，另外挂一块 200GB 以上的数据盘专门放模型。数据盘挂到/data，模型统一放/data/models，后面换实例、做快照、迁移都方便。如果你打算两个模型都放一台机器上分时跑，数据盘直接给 300GB，省得后面扩容。

开通时注意安全组，默认只放行 SSH 端口，不要一上来就把 8000 端口开到公网。验证阶段用 SSH 隧道或者内网跳板机访问，生产环境走负载均衡和内网域名。GPU 驱动选择“自动安装”最省事，云厂商的公共镜像一般会带 NVIDIA 驱动，开好机nvidia-smi能出卡就行。如果镜像没带驱动，手动装也简单，但要注意内核头文件和编译工具链，后面装 flash-attn 时还会用到。

2.2 驱动和 CUDA 版本怎么对齐

CUDA 版本这事，踩一次坑能记一辈子。nvidia-smi右上角显示的CUDA Version是驱动支持的最高运行时版本，不是你当前装的 CUDA 版本。PyTorch 装的是 cu121 还是 cu124，决定了它依赖的 CUDA 运行时。vLLM 又对 PyTorch 和 CUDA 有要求，版本一错，启动时报的错能绕好几圈。我一般先用nvidia-smi看驱动版本，再决定装哪个 PyTorch 轮子。驱动版本够新的话，直接上 cu121 或 cu124 的 PyTorch，兼容性最好。

装完以后用三行命令验证：nvidia-smi看卡，python -c "import torch; print(torch.__version__, torch.cuda.is_available())"看 PyTorch 能不能识别 GPU，python -c "import torch; print(torch.version.cuda)"看 PyTorch 编译时的 CUDA 版本。三个都对得上，再往下走。如果torch.cuda.is_available()返回 False，先别怀疑代码，八成是驱动版本低于 PyTorch 要求的 CUDA 运行时，或者容器启动时没加--gpus all。

2.3 两个 conda 环境，别混用

Qwen-7B 走 vLLM，Qwen-VL 走 transformers 加 FastAPI，这两套依赖对 transformers、tokenizers、numpy 的版本要求经常打架。我试过在同一个环境里装，vLLM 能跑，Qwen-VL 加载 tokenizer 时报AttributeError，反过来也一样。后来干脆建两个 conda 环境，一个叫qwen7b，一个叫qwenvl，互不干扰。环境切换用conda activate，启动脚本里写死解释器路径，避免 systemd 拉起时找不到环境。

基础依赖我一般锁这几个：Python 3.10、PyTorch 2.1 以上、transformers 4.32 以上、accelerate、sentencepiece、tiktoken、pillow、fastapi、uvicorn。Qwen-VL 还要加torchvision和modelscope或huggingface-hub用来下载模型。vLLM 环境单独装vllm，版本不要追最新，选一个明确支持 Qwen 的稳定版，比如 0.4.x 到 0.5.x 之间的版本，装完先跑python -c "import vllm; print(vllm.__version__)"确认。

conda create -n qwen7b python=3.10 -y conda activate qwen7b pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install vllm==0.4.3 pip install fastapi uvicorn openai conda create -n qwenvl python=3.10 -y conda activate qwenvl pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install transformers==4.32.0 accelerate sentencepiece tiktoken pillow pip install fastapi uvicorn python-multipart

注意：vLLM 和 Qwen-VL 的 transformers 版本要求可能冲突，不要为了省空间共用一个环境。磁盘不够就删 pip 缓存，别在依赖上妥协。

2.4 模型下载与目录规划

模型下载有两条路：直接从模型仓库拉，或者先把权重下到本地再传到云上对象存储。云上实例直连仓库有时速度不稳定，尤其是大文件，断一次就得重来。我一般用支持断点续传的下载工具，或者用云平台的对象存储做中转。目录规划上，/data/models/Qwen-7B-Chat和/data/models/Qwen-VL-Chat分开，启动参数里写绝对路径，不要用相对路径，systemd 和容器里相对路径的当前目录经常不是你预期的位置。

下载完检查文件完整性，至少看config.json、tokenizer.json、model.safetensors这些关键文件在不在，文件大小对不对。Qwen-7B-Chat 的权重是分片的，少一个分片启动时才会报错，提前用du -sh看一眼总大小，15GB 左右算正常。Qwen-VL 还要确认视觉编码器的权重文件在，别只下了语言模型部分。

# 示例：用 modelscope 下载，支持断点续传 pip install modelscope python - <<'PY' from modelscope import snapshot_download snapshot_download('qwen/Qwen-7B-Chat', cache_dir='/data/models') snapshot_download('qwen/Qwen-VL-Chat', cache_dir='/data/models') PY # 检查目录 du -sh /data/models/Qwen-7B-Chat /data/models/Qwen-VL-Chat ls /data/models/Qwen-7B-Chat | head

3. Qwen-7B 服务化：vLLM 起服务与参数调优

3.1 显存估算与量化方案

Qwen-7B 的 FP16 权重约 14GB，vLLM 启动时会按gpu-memory-utilization预分配显存，默认 0.9，也就是 24GB 卡会拿 21.6GB 左右做权重加 KV Cache。权重占 14GB，剩下 7GB 左右给 KV Cache 和激活值。按每 token 0.5MB 算，7GB 大约能放 14000 个 token 的 KV，但这是所有并发序列共享的。你设max-model-len8192、max-num-seqs8，理论需求是 8192×8×0.5MB≈32GB，明显超了；实际 vLLM 按请求动态分配，不会一上来全占满，但峰值扛不住就会排队甚至 OOM。

所以 24GB 卡上我建议两种组合：要么max-model-len4096、max-num-seqs8，适合短文本问答；要么max-model-len8192、max-num-seqs4，适合长文档摘要。如果业务对长上下文要求高、并发也高，直接上 INT8 或 INT4 量化，把权重降到 7GB 或 4GB，腾出空间给 KV Cache。量化会带来一点效果损失，但 Qwen-7B 在 INT8 下日常问答基本感知不到差别，INT4 需要针对业务做一轮抽样验证，尤其是数字、代码、专有名词场景。

3.2 vLLM 启动命令逐参数解释

vLLM 的好处是开箱即用的 OpenAI 兼容接口，启动一条命令就能对外提供/v1/chat/completions。下面这条是我在 24GB 卡上跑 Qwen-7B-Chat 的常用配置，参数不是抄来的，是反复调出来的。--model写绝对路径；--served-model-name给模型起个短名字，客户端调用时不用带一长串路径；--trust-remote-code必须加，Qwen 的 tokenizer 和模型代码需要远程加载；--dtype float16明确精度，避免自动推断出幺蛾子；--max-model-len控制上下文长度；--gpu-memory-utilization 0.9留 10% 给系统和激活；--max-num-seqs控制并发序列数；--host 0.0.0.0让容器外能访问；--port 8000按需改。

conda activate qwen7b python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen-7B-Chat \ --served-model-name qwen-7b \ --trust-remote-code \ --dtype float16 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 8 \ --host 0.0.0.0 \ --port 8000

启动日志里重点看三行：模型加载耗时、KV Cache 块数、可用最大并发。如果日志提示The model weights are not fully loaded或者直接 OOM，先把max-model-len砍半，再把max-num-seqs降到 4，还不行就换 INT8。另一个常见问题是flash-attn编译失败，vLLM 会回退到 eager 模式，速度慢一些但不影响跑。想强制不用 FlashAttention，加--enforce-eager，排查阶段很有用，能排除掉一类底层报错。

3.3 接口联调与流式输出

服务起来后先用 curl 探活，再用 Python SDK 调。Qwen-7B-Chat 的对话格式由 tokenizer 的 chat template 处理，你只要按 OpenAI 的 messages 传就行。注意temperature、top_p、max_tokens这些参数在 vLLM 里都支持，repetition_penalty可以通过extra_body传。流式输出对前端体验提升明显，尤其是生成长文本时，首 token 时间比整段返回快很多。我一般把max_tokens限制在 512 到 1024，避免单个请求占住 KV Cache 太久。

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-7b", "messages": [{"role": "user", "content": "用三句话解释什么是向量数据库"}], "temperature": 0.7, "max_tokens": 512, "stream": false }'

from openai import OpenAI client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="not-needed") resp = client.chat.completions.create( model="qwen-7b", messages=[{"role": "user", "content": "写一个 Python 快速排序"}], temperature=0.2, max_tokens=800, ) print(resp.choices[0].message.content)

注意：如果服务要跨机器访问，别偷懒用api_key="not-needed"。vLLM 启动时加--api-key，客户端带对应的 key，至少能挡住扫描器随手调你的接口。

3.4 压测与并发上限

不压测就不知道真实容量，这是我踩过最多次的坑。用hey或者自己写个异步脚本，从并发 1 开始，每轮加 2，观察三个指标：首 token 延迟、每秒生成 token 数、GPU 显存峰值。并发到某个点后，延迟会突然抬升，说明请求开始排队，这个点就是当前配置的实际上限。24GB 卡跑 Qwen-7B FP16、4096 长度，我实测并发 8 左右还能保持可接受的首 token 延迟，再往上排队明显。

压测时把max_tokens设成业务典型值，不要用 10 个 token 测出来的假高吞吐。另外注意客户端超时，vLLM 生成长文本时单个请求可能跑几十秒，网关或 SDK 默认超时经常是 60 秒，提前调大。如果发现 GPU 利用率上不去、CPU 先满了，检查是不是 tokenizer 或网络层成了瓶颈，这种情况加并发没用，得换更细的实例或优化客户端。

4. Qwen-VL 部署：多模态请求链路怎么搭

4.1 Qwen-VL 的额外依赖与显存构成

Qwen-VL 在 Qwen-7B 的语言模型前面加了一个视觉编码器，权重总量到 19GB 左右，FP16 下 24GB 卡加载完只剩 5GB 左右。这 5GB 要装图片预处理后的像素张量、视觉编码器的中间激活、语言模型的 KV Cache，还有生成时的临时缓存。一张 448×448 的图经过 ViT 会变成几百个图像 token，多图请求 token 数直接翻倍。所以 Qwen-VL 的并发不能按纯文本的思路估，单卡单并发是最稳的起点。

依赖上，Qwen-VL 需要transformers、accelerate、tiktoken、torchvision、pillow，加载模型时trust_remote_code=True不能少。官方示例里图片路径用file://前缀，这个细节坑了不少人：你传http://或者裸路径，tokenizer 可能不认，报FileNotFoundError。服务端要先把手里的上传文件落盘到临时目录，再用绝对路径拼file://传给模型。临时文件用完就删，不然跑几天磁盘就满了。

4.2 FastAPI 封装与图片上传

Qwen-VL 官方没有像 vLLM 那样现成的 OpenAI 兼容服务，自己包一层 FastAPI 最直接。接口设计成POST /v1/vision/chat，表单里一个图片文件、一个文本问题。收到请求后把图片读到临时目录，调用model.chat，返回文本。模型加载放在启动阶段，全局只加载一次，不要每个请求都from_pretrained，那样光加载权重就能把显存打爆。

import os import uuid import asyncio import threading from fastapi import FastAPI, UploadFile, File, Form from transformers import AutoModelForCausalLM, AutoTokenizer app = FastAPI() lock = threading.Lock() model_path = "/data/models/Qwen-VL-Chat" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, device_map="cuda:0", trust_remote_code=True, ).eval() @app.get("/health") def health(): return {"status": "ok"} @app.post("/v1/vision/chat") async def vision_chat(image: UploadFile = File(...), question: str = Form(...)): data = await image.read() tmp_path = f"/tmp/{uuid.uuid4().hex}.jpg" with open(tmp_path, "wb") as f: f.write(data) def infer(): with lock: query = tokenizer.from_list_format([ {"image": f"file://{tmp_path}"}, {"text": question}, ]) response, _ = model.chat( tokenizer, query=query, history=None, max_new_tokens=512, ) return response loop = asyncio.get_event_loop() try: answer = await loop.run_in_executor(None, infer) finally: if os.path.exists(tmp_path): os.remove(tmp_path) return {"answer": answer}

启动命令用 uvicorn，注意--workers 1，多 worker 会加载多份模型，24GB 卡直接爆。--timeout-keep-alive可以调大一点，图片上传和推理耗时比纯文本长。

conda activate qwenvl uvicorn app:app --host 0.0.0.0 --port 8001 --workers 1 --timeout-keep-alive 75

4.3 并发控制与请求队列

Qwen-VL 的model.chat不是线程安全的，多个请求同时进来，轻则输出错乱，重则显存峰值叠加直接 OOM。上面的代码用threading.Lock把推理串行化，配合run_in_executor避免阻塞 FastAPI 的事件循环。这是最保守也最稳的做法，单卡单并发，请求排队等。如果你有多张卡，可以起多个进程，前面用负载均衡分发，但每个进程仍然只跑一个模型实例。

排队策略要看业务能不能忍。图文问答通常不是高频秒回场景，单并发加队列能撑住小流量。如果排队太长，优先考虑加卡或换更大显存的实例，而不是把锁去掉。我试过去掉锁跑并发 4，Qwen-VL 的输出开始串图，A 图的回答跑到 B 请求里，排查了半天才定位到模型实例共享状态。这个坑写在这里，希望你别再踩。

注意：FastAPI 默认线程池大小有限，run_in_executor不指定 executor 时用的是默认线程池。Qwen-VL 推理时间长，队列里堆太多请求会占内存，入口处加一个简单的信号量限制排队数量，超过就返回 429，比无限堆积体验好。

4.4 效果验证与输入坑

服务起来后先用一张清晰的商品图或文档截图测，问题问具体一点，比如“图里有哪些文字”“这个物体的颜色是什么”。Qwen-VL 对中文场景支持不错，但图片质量影响很大。上传前用 Pillow 做两件事：转 RGB 模式，处理 EXIF 旋转信息。手机拍的图经常带旋转标记，不处理的话模型看到的图是躺着的，回答自然不对。超大图先缩到长边 1024 左右，既省带宽也省显存，Qwen-VL 内部还会再缩放，但没必要让服务端先吃一张 4000×3000 的原图。

from PIL import Image, ImageOps img = Image.open(tmp_path) img = ImageOps.exif_transpose(img).convert("RGB") img.thumbnail((1024, 1024)) img.save(tmp_path, format="JPEG", quality=90)

另一个坑是临时文件权限和路径。容器里/tmp可能是内存盘，大图多了会占内存；多实例共享宿主机时，临时文件名要带随机串，避免互相覆盖。生产环境我一般把临时目录指到数据盘，加一个定时清理任务，删掉超过一小时的残留文件。

5. 上线后的稳定性与成本控制

5.1 进程守护与容器化

裸机上直接用python -m vllm...起服务，SSH 一断进程就没了。验证阶段可以用tmux或nohup，稳定后必须交给 systemd 或容器。systemd 的优点是简单，写一个 unit 文件，Restart=always，挂了自动拉起来，日志走 journald。容器的好处是环境一致，换机器时不用重新装依赖。我一般先写 systemd 跑通，再打 Docker 镜像做标准化。

systemd 单元里注意Environment指定 conda 环境路径，ExecStart用绝对路径的解释器，WorkingDirectory设到代码目录。Qwen-VL 的 uvicorn 进程要设--workers 1，别被默认值坑了。容器启动时加--gpus all，挂载模型目录和临时目录，端口映射到宿主机内网地址，不要直接映射到公网。

[Unit] Description=Qwen-7B vLLM Service After=network.target [Service] Type=simple User=ubuntu WorkingDirectory=/data/app Environment=PATH=/opt/conda/envs/qwen7b/bin:/usr/local/bin:/usr/bin ExecStart=/opt/conda/envs/qwen7b/bin/python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen-7B-Chat \ --served-model-name qwen-7b \ --trust-remote-code \ --dtype float16 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 8 \ --host 0.0.0.0 \ --port 8000 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

5.2 日志、监控与告警

日志分两层看：应用日志和 GPU 指标。vLLM 的日志会打印吞吐、排队长度、KV Cache 使用率，Qwen-VL 的 uvicorn 日志能看请求耗时和异常堆栈。GPU 层用nvidia-smi dmon或者云监控看利用率、显存、温度。告警至少设三条：显存持续超过 90%、服务健康检查连续失败、P99 延迟超过业务阈值。显存告警能提前发现内存泄漏或并发配置过大，健康检查失败能赶在用户投诉前处理。

日志轮转别忽略。vLLM 跑一天能写不少日志，Qwen-VL 的请求日志加上图片临时文件，磁盘很容易满。用 logrotate 按天切、保留 7 天，或者容器日志驱动限制大小。我遇到过磁盘满导致模型加载失败的情况，排查时先看df -h，再看日志，能省很多时间。

5.3 访问控制与网络安全

服务端口不要裸奔在公网。验证阶段用 SSH 隧道把 8000 和 8001 映射到本地，生产环境走内网负载均衡，安全组只放行负载均衡的流量。vLLM 启动时加--api-key，Qwen-VL 在 FastAPI 里加一个 Header 校验中间件，至少挡住没有 key 的请求。请求体大小也要限制，Qwen-VL 的图片上传接口设一个 10MB 上限，防止有人传超大文件把内存打满。

如果业务方需要从公网访问，前面加一层网关做限流和鉴权，不要把模型服务直接暴露。限流按 IP 和按 key 都要有，纯文本接口按 QPS 限，多模态接口按并发数限，因为后者单个请求占用资源多。这些措施不复杂，但能避免大部分“服务突然不可用”的事故。

5.4 账单优化：别让验证环境跑成长期成本

云上 GPU 实例按小时计费，验证完忘了关，一个月账单能吓一跳。我的习惯是验证阶段用按量付费，跑完立即释放；稳定后再考虑包月或节省计划。离线批处理任务可以用抢占式实例，成本低很多，但要注意它可能被回收，任务要能断点续跑。在线服务不要用抢占式，除非你做了多副本和快速故障转移。

模型量化是最直接的降本手段。Qwen-7B 从 FP16 降到 INT8，权重减半，同样一张卡能扛更高并发，或者换更小的卡。Qwen-VL 如果业务对精度要求不高，INT4 能把 24GB 卡从“勉强跑”变成“能跑一点并发”。另外，模型文件放对象存储、实例本地盘只做缓存，换实例时不用重新下载几十 GB 权重，也能省不少时间成本。

6. 常见问题排查实录

6.1 启动阶段：CUDA、依赖和模型加载

启动阶段的问题最集中，也最好定位，因为报错通常很直接。CUDA 版本不匹配看torch.cuda.is_available()；vLLM 报AttributeError多半是版本和模型代码不兼容，先升级 vLLM 或换稳定版；flash-attn编译失败看有没有装nvcc和内核头文件，临时加--enforce-eager绕过；模型加载 OOM 先降max-model-len和max-num-seqs，再考虑量化。Qwen-VL 加载报trust_remote_code相关错误，检查参数有没有漏，以及 transformers 版本是否过低。

模型文件缺失是另一个高频问题。下载中断、分片没下全、路径写错，都会在加载时暴露。先ls看目录结构，再对比官方仓库的文件列表，重点看model.safetensors.index.json里列的分片是不是都在。磁盘满也会导致加载失败，df -h一眼就能排除。

6.2 运行阶段：OOM、超时和图片路径

运行阶段 OOM 通常发生在请求峰值，表现是服务突然挂掉或者日志里出现CUDA out of memory。先看是不是某个请求的max_tokens设得太大，再看并发是不是超了。Qwen-7B 的 KV Cache 会随序列长度增长，长文本请求一来，显存曲线立刻往上抬。把max_tokens限制住，或者对超长请求做截断，能解决大部分问题。

Qwen-VL 的图片路径报错，九成是file://前缀没加或者路径不是绝对路径。容器里还要注意宿主机路径和容器内路径的映射，上传文件保存到容器内临时目录，传给模型时用容器内路径。请求超时先看网关和 SDK 的超时设置，再看模型生成时间，图片大、问题复杂、max_new_tokens高，都会拉长耗时。流式输出对多模态帮助有限，但纯文本接口可以开。

6.3 并发阶段：锁、队列和输出错乱

并发阶段最隐蔽的问题是输出错乱。Qwen-VL 的模型实例共享状态，不加锁并发调用会出现 A 请求拿到 B 请求的图片描述。排查时先看日志里的请求 ID 和图片路径能不能对上，对不上就是并发串了。解决方式就是串行化，单卡单并发，前面加队列。vLLM 本身对并发处理是安全的，不需要额外加锁，但要注意max-num-seqs和max-model-len的组合，排队太长时客户端会超时。

另一个并发坑是 tokenizer 的线程安全。Qwen-VL 的 tokenizer 在多线程下偶尔会出问题，和模型一起放在锁里最稳。如果吞吐实在不够，加卡多副本，每个副本独立进程、独立端口，前面用负载均衡分发，不要在一个进程里开多线程跑同一个模型实例。

最后再分享一个我在实际部署里养成的习惯：每次调整启动参数，先把变更记在一张纸上，包括改了哪个参数、为什么改、改完的显存峰值和延迟变化。Qwen-7B 和 Qwen-VL 的参数互相影响，今天为了压延迟调了max-num-seqs，明天可能为了长文本调了max-model-len，没有记录的话，一周后你根本不记得当前配置是怎么来的。云上部署的灵活性是优势，但前提是你知道每一次变更带来了什么。