vLLM 部署 Qwen3.5 满血&量化版，并发性能测试，附部署脚本

最近openclaw在国内火的优点离谱，脱离其实力范围的火，以至于我也要在文中加上两句才可能有流量。。。主要是我个人一直玩的是自己折腾的一套，比较放心

不过本周我会测试国产的两个claw，敬请期待。

本文继续折腾Qwen3.5 不出意外是最后一篇了。

Qwen3.5 系列我一直没有拿 vLLM 部署，，趁着周末，玩一下。

首先需要升级 vLLM，唯一需要注意的是自己的硬件及 CUDA 版本

我的系统总是有幺蛾子，所有还是用的 Docker

正常拉取镜像即可：docker pull vllm/vllm-openai:v0.17.0

我是 4090 的卡，所以选择官方 FP8

27B 权重文件 30GB

遭遇各种 OOM 之后。。。。

最终调整到了一版合适的参数，脚本以 35B 为例，27B 仅需修改模型文具地址和对应 name 即可，我只有 4 卡，所有还要测完 35B 后 stop 才能起 27B

#!/usr/bin/env bash
set -euo pipefail

MODEL_DIR="/data/models/Qwen3.5-35B-A3B-FP8"
CONTAINER_NAME="qwen35-35b-a3b-fp8"
PORT=8000

docker rm -f ${CONTAINER_NAME} 2>/dev/null || true

docker run -d \
  --name ${CONTAINER_NAME} \
  --gpus '"device=0,1,2,3"' \
  --ipc=host \
  --shm-size=16g \
  -p ${PORT}:8000 \
  -v ${MODEL_DIR}:/model:ro \
  -e NCCL_P2P_DISABLE=0 \
  -e NCCL_IB_DISABLE=1 \
  -e VLLM_USE_V1=1 \
  vllm/vllm-openai:v0.17.0 \
  --model /model \
  --served-model-name qwen3.5-35b-a3b-fp8 \
  --tensor-parallel-size 4 \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.9 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --language-model-only \
  --enable-prefix-caching \
  --default-chat-template-kwargs '{"enable_thinking": false}' \
  --host 0.0.0.0 \
  --port 8000

这里说明一下
--tensor-parallel-size 4我又 4 张 4090 显卡
--max-model-len 262144是我的强需求，可以稍微牺牲一点并发
--kv-cache-dtype fp8这是为了降低 KV cache 内存占用，从而支持更长上下文
--gpu-memory-utilization 0.9是为了给真实运行时留空间。实际部署中，除了权重和 KV cache，还会吃掉显存的还有：CUDA graph、NCCL 通信 buffer、allocator 碎片、连续 batching 带来的波动等等
--max-num-seqs 4避免长上下文 + 高并发叠加把显存直接顶爆，感觉还有空间往上加
--max-num-batched-tokens 8192参数控制一次调度里的总 token 规模。它过大时，会带来更高吞吐，但也会加大运行时显存波动和调度压力
--language-model-only我不需要多模态，所以只要文本推理
--enable-prefix-caching高效的 KV 管理和吞吐优化参数
--default-chat-template-kwargs '{"enable_thinking": false}'：加了思考我这配置卡的很，思考太过漫长了

而且我用的 FP8 它的思考居然是英文

实际运行，性能特别差 27B 几乎没有并发能力，35B-A3B 还可以，但是 RPS 很低，首 Token 延迟都奔 10s 了

没办法，我放弃官方 FP8，上了 4bit

然后使用了同样的部署脚本，只是它俩更省卡，2 张 4090 就能跑起来，我可以同时跑 27B 和 35B，而且我还在原代码基础上 加大了 max-num-seqs

我把它俩接入到了 openwebui，都关闭思考情况下，27B 也慢得多！看样子我之前的判断大错特错了，27 太拉垮了。

日志显示 27B 70+ t/s

35B 100+ t/s

代码能力呢，都不太能看，卧龙凤雏了

性能方面，27B 依然相当差劲，比 PF8 好多了

35B 比 FP8 提升多了，也比 27B 强多了

总结，以我的需求，暂时不想替代 Qwen3-32B，还是 32B 跟稳。

而且 3.5 还整了骚操作，把开头的 从“动态生成”变成了“静态预置”，下游对接的系统苦了。。。要么模型测，要么应用测，是要改的。

再加上它本身不支持思考与否的软关闭，这个级别能力提升也不见得能弥补这些缺点，企业级应用，我感觉很多都不太乐意升 3.5