Claude Code方案：4080s 32G + vLLM + Qwen27b 256K MTP部署 60tokens/s
-
4080s 32G推出以来，一直广受关注。全新显卡的价格也从8500一路上涨到目前的1.1w，也多次被老特在视频中推荐。相比较两万多的5090，4080s的价格非常亲民，32G显存也刚好处在小模型的甜点。
虽然关注度很高，但是论坛里一直没有相关的帖子。经过一段时间的折腾，目前总算跑到了一个性能，速度都还满意的配置。下面简单介绍一下我的配置，以及为什么需要这样配，给网友们提供一些思路和避坑指南。
再说说我的工作环境与需求：题主主要用AI来做本地知识库的整理以及辅助完成工作中的编程任务，主要工具是claude code。众所周知，claude对上下文长度要求很高，用deepseek v4 flash，几轮对话之后，上下文长度经常在400k以上，因此，上下文长度对于题主来说是刚需，128k以下长度可能无法坚持一轮对话。生成速度方面，ollama默认配置下，27b模型在4080s上速度大概33tokens/s，虽然还算可观，但是对于长编程而言还是有点慢了，50tokens/s以上属于可以接受的范畴。部署工具方面，ollama，lamma.cpp，vllm等工具对比下来，在长上下文场景下，无疑vllm是最优秀的，稳定性也是这几个工具中最好的，通过细致的参数，可以最大化的利用显卡性能。
因此，考虑到隐私性需求，综合考虑上下文长度，速度等方面因素，最终选择了量化版本的Qwen27b模型。经过几轮调优，单用户在4080s下最终达到了60tokens/s的峰值速度，256k上下文对于小型项目而言基本足够。
最终模型选取了cyankiwi/Qwen3.6-27B-AWQ-INT4，这是一个很热门的Q4量化的版本，AWQ格式对于vllm来说性能也更优。搭建流程如下：
-
vLLM安装
uv venv source .venv/bin/activate uv pip install -U vllm --torch-backend=auto -
huggingface下载模型
source .venv/bin/activate hf download cyankiwi/Qwen3.6-27B-AWQ-INT4 --local-dir ./qwen3.6-27b-awq-agent -
启动模型
#!/bin/bash # ============================================================ # vLLM 启动脚本 — Qwen3.6 27B AWQ Int4 【满血均衡版】 # 核心策略: 显式 AWQ 量化 + 256K上下文 + 极速 CUDA 计算图 + MTP加速 # ============================================================ # ---- 底层防碎片化，为 CUDA Graphs 预留纯净空间 ---- export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True exec /your/path/vllm-venv/.venv/bin/python3 -m vllm.entrypoints.openai.api_server \ --model /your/path/qwen3.6-27b-awq-int4 \ --served-model-name qwen3-27b \ --host 0.0.0.0 \ --port 11435 \ \ `# ---- 1. 空间折叠与防 OOM 护城河 ----` \ --kv-cache-dtype fp8 \ --gpu-memory-utilization 0.97 \ --max-model-len 262144 \ --max-num-seqs 1 \ \ `# ---- 2. 前端防超时调度 (解决 Timeout 痛点) ----` \ --enable-chunked-prefill \ --max-num-batched-tokens 3072 \ --scheduling-policy priority \ \ `# ---- 3. Agent 解析器与缓存外挂 ----` \ --language-model-only \ --enable-auto-tool-choice \ --reasoning-parser qwen3 \ --tool-call-parser qwen3_coder \ --enable-prefix-caching \ \ `# ---- 4. 引擎加速 (不再受限于 Eager 模式) ----` \ --max-cudagraph-capture-size 128 \ --no-enable-log-requests \ --speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}' -
添加守护进程
创建守护进程脚本:sudo nano /etc/systemd/system/vllm.service
粘贴下面的内容:[Unit] Description=vLLM Qwen3.6 27B API Server (FP8 256K Version) After=network.target [Service] User=youruser Group=yourgroup WorkingDirectory=/your/path Restart=always RestartSec=10 # 使用 -lc 参数（Login Command），让系统先加载你的终端环境变量，再去执行脚本！ ExecStart=/bin/bash -lc '/your/path/vllm-start.sh'创建守护进程实现开机自启:
sudo systemctl daemon-reload sudo systemctl enable vllm sudo systemctl start vllm启动后查看vllm日志:
journalctl -u vllm.service -f
-
-
辛苦了, up這個配置也很接近我目前工作正在用的配置了
如果想再更進一步可以考慮試試Autoround + TurboQuant 4-bit KV Cache, kv cache會比FP8再少一半
@566656661 TurboQuant 4-bit KV Cache会不会影响模型的智力呢？尝试配置过，启动报错就放弃了
-
@566656661 TurboQuant 4-bit KV Cache会不会影响模型的智力呢？尝试配置过，启动报错就放弃了
-
，
T terry 固定了此主题
-
我也是4080S32G用户，但我是小白，在hermes中让deepseek flash调试了很久，其中不断把启动参数发给豆包和gemini三方博弈，还是突破不了128K上下文。兄弟你测试的60tokens/s的峰值速度是单线程还是并发的数据呢？
我也列一下我的启动参数和测试数据
#!/bin/bash
# 启动 vLLM 服务 - Qwen3.6-27B GPTQ Int4 @ 128K context + MTP + Prefix Caching
# 端口 8000source ~/vllm-workspace/venv/bin/activate MODEL_DIR=/home/demo/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-GPTQ-Int4 CHAT_TEMPLATE=~/vllm-workspace/buun_chat_template.jinja export VLLM_USE_FLASHINFER_SAMPLER=1 export CUDA_HOME=/usr/local/cuda-13.0 export PATH=$CUDA_HOME/bin:$PATH export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True exec vllm serve "$MODEL_DIR" \ --port 8000 \ --host 127.0.0.1 \ --max-model-len 131072 \ --dtype auto \ --gpu-memory-utilization 0.93 \ --kv-cache-dtype fp8 \ --compilation-config '{"cudagraph_capture_sizes": [1, 2, 4], "cudagraph_mode": "PIECEWISE"}' \ --enable-chunked-prefill \ --max-num-batched-tokens 3072 \ --chat-template "$CHAT_TEMPLATE" \ --trust-remote-code \ --enable-auto-tool-choice \ --tool-call-parser hermes \ --limit-mm-per-prompt '{"image":1}' \ --speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}' \ --enable-prefix-caching \ --served-model-name Qwen3.6-27B-GPTQ-Int4让deepseek做的压力测试脚本数据：
压测结果：Qwen3.6-27B-GPTQ-Int4单线程 | 轮次 | tokens | 耗时 | tok/s | |------|--------|--------|-------| | #1 | 1024 | 22.65s | 45.2 | | #2 | 1024 | 23.26s | 44.0 | | #3 | 1024 | 23.10s | 44.3 | | 平均 | 1024 | 23.00s | 44.5 | 并发压测 | 并发数 | 墙钟耗时 | 总产出 | 吞吐量(tok/s) | 单请求平均 | |--------|----------|----------|---------------|------------| | 2路 | 37.56s | 2048 tok | 54.5 | 27.5 tok/s | | 4路 | 49.74s | 4096 tok | 82.4 | 20.9 tok/s | | 8路 | 41.86s | 8192 tok | 195.7 🚀 | 25.1 tok/s | 关键结论 1. 单线程 44.5 tok/s — 稳定，MTP + FlashInfer 效果不错 2. 并发吞吐线性增长 — 2路 54.5 → 4路 82.4 → 8路 195.7 tok/s 3. 8路反而比4路快 — 41.86s vs 49.74s 🤔 可能因为 batch 大了，MTP speculative decoding 的 acceptance rate 更高，vLLM 调度器在更大 batch 下更高效 4. 单请求延迟 — 并发下每请求约 20-27 tok/s，比单线程慢一半，但总吞吐翻了 4 倍 -
@demo 关于128K上下文突破不了的问题，我看了你的启动参数，有几个建议：
-
gpu-memory-utilization 0.93对于 GPTQ Int4 + 128K context 可能不够。 4080S 32G 跑 Qwen3.6-27B GPTQ Int4（约16-18G）加上 128K 的 KV cache（fp8_e4m3 约 4-5G），总共需要 20-23G。0.93 利用率实际可用约 29.8G，按理说够。但关键问题是： -
kv-cache-dtype fp8对 4080S (Ada Lovelace) 来说，fp8 不是原生支持最快的格式。 Ada 架构的 fp8 支持比 Hopper (4090/5090) 差。建议试下--kv-cache-dtype fp8_e4m3显式指定格式，或者干脆用--kv-cache-dtype auto让 vLLM 自己选。 -
真正的瓶颈应该是
max-model-len 131072+ MTP 同时开启。 MTP（Multi-Token Prediction）模型在做 speculative decoding 时需要同时加载 draft model 的 KV cache，会让显存占用突然暴涨。试下先用--speculative-model None关掉 MTP 确认能不能跑 128K，如果能跑再逐步加 MTP 参数。 -
检查 tensor_parallel 设置。 单卡 4080S 不需要 TP，确保没开
--tensor-parallel-size。 -
你说的 60t/s 是单线程（streaming）速度，并发下因为 KV cache 共享会有明显下降。那个数字是单用户单请求的峰值。
建议先试：
--kv-cache-dtype auto --speculative-model None --max-model-len 131072 --gpu-memory-utilization 0.95 -
-
，系统 取消固定了此主题
-
我也是4080S32G用户，但我是小白，在hermes中让deepseek flash调试了很久，其中不断把启动参数发给豆包和gemini三方博弈，还是突破不了128K上下文。兄弟你测试的60tokens/s的峰值速度是单线程还是并发的数据呢？
我也列一下我的启动参数和测试数据
#!/bin/bash
# 启动 vLLM 服务 - Qwen3.6-27B GPTQ Int4 @ 128K context + MTP + Prefix Caching
# 端口 8000source ~/vllm-workspace/venv/bin/activate MODEL_DIR=/home/demo/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-GPTQ-Int4 CHAT_TEMPLATE=~/vllm-workspace/buun_chat_template.jinja export VLLM_USE_FLASHINFER_SAMPLER=1 export CUDA_HOME=/usr/local/cuda-13.0 export PATH=$CUDA_HOME/bin:$PATH export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True exec vllm serve "$MODEL_DIR" \ --port 8000 \ --host 127.0.0.1 \ --max-model-len 131072 \ --dtype auto \ --gpu-memory-utilization 0.93 \ --kv-cache-dtype fp8 \ --compilation-config '{"cudagraph_capture_sizes": [1, 2, 4], "cudagraph_mode": "PIECEWISE"}' \ --enable-chunked-prefill \ --max-num-batched-tokens 3072 \ --chat-template "$CHAT_TEMPLATE" \ --trust-remote-code \ --enable-auto-tool-choice \ --tool-call-parser hermes \ --limit-mm-per-prompt '{"image":1}' \ --speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}' \ --enable-prefix-caching \ --served-model-name Qwen3.6-27B-GPTQ-Int4让deepseek做的压力测试脚本数据：
压测结果：Qwen3.6-27B-GPTQ-Int4单线程 | 轮次 | tokens | 耗时 | tok/s | |------|--------|--------|-------| | #1 | 1024 | 22.65s | 45.2 | | #2 | 1024 | 23.26s | 44.0 | | #3 | 1024 | 23.10s | 44.3 | | 平均 | 1024 | 23.00s | 44.5 | 并发压测 | 并发数 | 墙钟耗时 | 总产出 | 吞吐量(tok/s) | 单请求平均 | |--------|----------|----------|---------------|------------| | 2路 | 37.56s | 2048 tok | 54.5 | 27.5 tok/s | | 4路 | 49.74s | 4096 tok | 82.4 | 20.9 tok/s | | 8路 | 41.86s | 8192 tok | 195.7 🚀 | 25.1 tok/s | 关键结论 1. 单线程 44.5 tok/s — 稳定，MTP + FlashInfer 效果不错 2. 并发吞吐线性增长 — 2路 54.5 → 4路 82.4 → 8路 195.7 tok/s 3. 8路反而比4路快 — 41.86s vs 49.74s 🤔 可能因为 batch 大了，MTP speculative decoding 的 acceptance rate 更高，vLLM 调度器在更大 batch 下更高效 4. 单请求延迟 — 并发下每请求约 20-27 tok/s，比单线程慢一半，但总吞吐翻了 4 倍
