vLLM 部署 Qwen3.5 滿血&量化版，并發性能測試，附部署腳本

最近openclaw在國內火的優點離譜，脫離其實力范圍的火，以至于我也要在文中加上兩句才可能有流量。。。主要是我個人一直玩的是自己折騰的一套，比較放心

不過本周我會測試國產的兩個claw，敬請期待。

本文繼續折騰Qwen3.5 不出意外是最后一篇了。

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

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

我的系統總是有幺蛾子，所有還是用的 Docker

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

我是 4090 的卡，所以選擇官方 FP8

35B 權重文件 37GB

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

cyankiwi/Qwen3.5-35B-A3B-AWQ-4bitcyankiwi/Qwen3.5-27B-AWQ-4bit

然后使用了同樣的部署腳本，只是它倆更省卡，2 張 4090 就能跑起來，我可以同時跑 27B 和 35B，而且我還在原代碼基礎上 加大了 max-num-seqs

Moe 確實省顯卡

我把它倆接入到了 openwebui，都關閉思考情況下，27B 也慢得多！看樣子我之前的判斷大錯特錯了，27 太拉垮了。

日志顯示 27B 70+ t/s

35B 100+ t/s

代碼能力呢，都不太能看，臥龍鳳雛了

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

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

總結，以我的需求，暫時不想替代 Qwen3-32B，還是 32B 跟穩。

而且 3.5 還整了騷操作，把開頭的 從“動態生成”變成了“靜態預置”，下游對接的系統苦了。。。要么模型測，要么應用測，是要改的。

再加上它本身不支持思考與否的軟關閉，這個級別能力提升也不見得能彌補這些缺點，企業級應用，我感覺很多都不太樂意升 3.5