前言本人单位内部有一台双4090 24G的工作站需要用它来部署Qwen3.8-27B。之前是3.6-35B-A3B用来跑Hermes Agent速度还可以但是同事给换到27B后速度慢得离谱于是想动手优化一下最终加上 vLLM 的 MTP 投机解码后实测单对话生成速度能稳定在55 tokens/s左右。整个过程如下硬件与环境GPURTX 4090 24G × 2模型Qwen3.8-27B框架vLLM v0.20.2Docker 镜像vllm/vllm-openai:latest-x86_64-cu129-ubuntu2404KV Cache量化FP8启动参数使用如下参数启动模型docker run -d \ --gpus all \ -p 8080:8000 \ --restart unless-stopped \ --ipchost \ -v /data/AI_models/qwen3.8-27B:/models \ vllm/vllm-openai:latest-x86_64-cu129-ubuntu2404 \ --model /models \ --tensor-parallel-size 2 \ --kv-cache-dtype fp8 \ --speculative-config {method:mtp,num_speculative_tokens:2} \ --enable-prefix-caching \ --max-num-seqs 32 \ --gpu-memory-utilization 0.93 \ --max-model-len -1 \ --served-model-name Qwen3.8-27B \ --reasoning-parser qwen3 \ --api-key your-api-key \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder \ --default-chat-template-kwargs {\reasoning_effort\: \low\}参数要点--tensor-parallel-size 2双卡张量并行27B 模型必须 TP2 才能装入 24G 显存--kv-cache-dtype fp8FP8 KV Cache 省显存4090 Ada 架构原生支持--speculative-config {method:mtp,num_speculative_tokens:2}MTP 投机解码draft token 数设为 2--max-num-seqs 32关键参数见下方踩坑记录遇到的坑默认 max_num_seqs256 导致启动随机 OOMvLLM 默认 max_num_seqs256但在 24G 显存跑 27B TP2 时启动阶段会按最坏情况预留激活内存activation memory预留量与 max_num_seqs 成正比。256 个序列的预留会把 gpu_memory_utilization 配额吃得很紧。更坑的是由于 PyTorch CUDA 内存分配器的碎片问题同样的启动命令有时成功、有时直接 OOM排查极其痛苦。解决显式限制 --max-num-seqs 32大幅降低启动时的激活内存预留启动成功率 100%。实测结果使用Hermes完成一个PPT制作任务只使用FP8 KV Cache的情况下单对话推理速度约为40tokens/s开启MTP后单对话推理速度约为55tokens/s生成吞吐 ~51 - 58 tokens/s平均 ~55 tokens/sMTP 平均接受长度 ~2.4MTP 整体接受率 ~67% - 77%平均 ~70%Prefix Cache 命中率 ~88%
前言本人单位内部有一台双4090 24G的工作站需要用它来部署Qwen3.8-27B。之前是3.6-35B-A3B用来跑Hermes Agent速度还可以但是同事给换到27B后速度慢得离谱于是想动手优化一下最终加上 vLLM 的 MTP 投机解码后实测单对话生成速度能稳定在55 tokens/s左右。整个过程如下硬件与环境GPURTX 4090 24G × 2模型Qwen3.8-27B框架vLLM v0.20.2Docker 镜像vllm/vllm-openai:latest-x86_64-cu129-ubuntu2404KV Cache量化FP8启动参数使用如下参数启动模型docker run -d \ --gpus all \ -p 8080:8000 \ --restart unless-stopped \ --ipchost \ -v /data/AI_models/qwen3.8-27B:/models \ vllm/vllm-openai:latest-x86_64-cu129-ubuntu2404 \ --model /models \ --tensor-parallel-size 2 \ --kv-cache-dtype fp8 \ --speculative-config {method:mtp,num_speculative_tokens:2} \ --enable-prefix-caching \ --max-num-seqs 32 \ --gpu-memory-utilization 0.93 \ --max-model-len -1 \ --served-model-name Qwen3.8-27B \ --reasoning-parser qwen3 \ --api-key your-api-key \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder \ --default-chat-template-kwargs {\reasoning_effort\: \low\}参数要点--tensor-parallel-size 2双卡张量并行27B 模型必须 TP2 才能装入 24G 显存--kv-cache-dtype fp8FP8 KV Cache 省显存4090 Ada 架构原生支持--speculative-config {method:mtp,num_speculative_tokens:2}MTP 投机解码draft token 数设为 2--max-num-seqs 32关键参数见下方踩坑记录遇到的坑默认 max_num_seqs256 导致启动随机 OOMvLLM 默认 max_num_seqs256但在 24G 显存跑 27B TP2 时启动阶段会按最坏情况预留激活内存activation memory预留量与 max_num_seqs 成正比。256 个序列的预留会把 gpu_memory_utilization 配额吃得很紧。更坑的是由于 PyTorch CUDA 内存分配器的碎片问题同样的启动命令有时成功、有时直接 OOM排查极其痛苦。解决显式限制 --max-num-seqs 32大幅降低启动时的激活内存预留启动成功率 100%。实测结果使用Hermes完成一个PPT制作任务只使用FP8 KV Cache的情况下单对话推理速度约为40tokens/s开启MTP后单对话推理速度约为55tokens/s生成吞吐 ~51 - 58 tokens/s平均 ~55 tokens/sMTP 平均接受长度 ~2.4MTP 整体接受率 ~67% - 77%平均 ~70%Prefix Cache 命中率 ~88%
