Qwen3.8 27B, 单卡也可以跑191 tok/s : 一套优化到极致的部署与实测
-
@johnnybegood 您好贴主，可否分享一下双卡3090的实测速度结果和方案呢，目前单卡的上下文拉不到256k，我正在考虑要不要在买一张3090组双卡，采用这个方案可否实现256k上下文并且速度不知道可以增加多少，跪求测试数据了，感谢！！！！
-
显卡价格才是榨汁的原动力。
3090 还真是老当益壮，承受他不应该承受的卡生！
赞 -
今天折腾了 syv-ai/qwen38-27b-rtx3090 这个项目 —— 把 Qwen3.8-27B 这个 27B 参数的 thinking 模型，跑到一张消费级 RTX 3090 (24GB) 上，OpenAI 兼容 API + DFlash2 投机解码。从零开始到实测出平均 118 tok/s ，最高 191 tok/s 的 decode 速度，记录一下供后来人参考。
项目是什么
syv-ai/qwen38-27b-rtx3090做的事情：
- W4A16 量化主模型（int4 权重 + 16-bit 激活），把 27B 压到 ~15 GB
- DFlash2 投机解码：用一个 ~1 GB 的 drafter 每次提议 7 个 token，target model 一次 verify，跑出来比纯 MTP（4 个一阶）更快
- 64k 上下文，OpenAI 兼容 API，端口 18020
- 全部 vLLM 0.28.0 + 针对性 patch（KVarN 量化缓存、int4 KV per-token-head、marlin int8 layer-select 等等），做成了 docker 镜像
容器化做得很干净：
docker compose --profile single up -d一行起，模型自动下载 + 量化 + 启动。硬件 & 环境
- 一台 Ubuntu 24.04 机器，RTX 3090 (24GB), 3950X, 64G DDR4
- 系统盘：nvme 4TB（用了大约 30GB）
部署过程
第一步：把用户加进 docker 组
sudo usermod -aG docker $USER但这有个坑：新组要重新登录 shell 才生效。如果你在一个已经打开的终端/hermes session 里操作，当前进程的 supplementary groups 不会刷新，还是会 permission denied。
解决办法：要么重启 session，要么用
sg docker -c '...'把 docker 命令包一层起新会话。后续命令我都用了这个：sg docker -c 'docker compose build single'第二步：拉镜像
官方提供了 prebuilt 镜像：
ghcr.io/syv-ai/qwen38-27b-rtx3090:latest，9.5GB。直接 pull：sg docker -c 'docker compose pull single'第三步：本地 build
docker-compose.yml里image:和build:都写了，pull 失败可以直接走 build：sg docker -c 'docker compose build single'我这边 build 一次过了。build 过程大致分这几步：
阶段 耗时 apt-get install（gcc-13 / cuda-nvcc-13-0 / python3.12 等） ~3 分钟 pip install vllm 0.28.0（torch 526MB + cudnn 366MB + cusparselt 170MB + nccl 206MB + 一堆小 wheels） ~15 分钟 apply patches (KVarN / dflash2 / int4-kv / ... 共 30+ 个) ~30 秒 verify.sh --install+ 单元测试~35 秒 export layers + image flatten ~5 分钟 总构建时间大约 20-30 分钟，镜像最终 14.6 GB。
第四步：写
.envcp .env.example .env echo "VLLM_API_KEY=$(openssl rand -hex 24)" >> .env # 本机可以不设，但建议加上 echo "PORT=18020" >> .env echo "NVIDIA_VISIBLE_DEVICES=1" >> .env # 选 3090 echo "SPEC=dflash2" >> .env # 用 DFlash2 投机解码 echo "PREFIX_CACHE=1" >> .env # 推荐 echo "VLLM_WSL2_ENABLE_PIN_MEMORY=1" >> .env # WSL2 需要，本机无所谓第五步：启动
sg docker -c 'docker compose --profile single up -d'会启动两个容器：
prepare：下载 ~20 GB 的 Qwen3.8-27B-W4A16-AutoRound 模型 + ~1.2 GB 的 DFlash2 drafter + 跑量化脚本（lm_head / embed_tokens int8 化，MTP int8 量化，drafter draft vocab 等）。完成后 exit 0。single：等 prepare 完成后启动 vLLM server。首次启动要做 torch.compile + CUDA graphs + FlashInfer JIT，约 2-3 分钟。后续启动因为/cachevolume 里缓存了编译产物，只要 1 分钟左右。
up -d命令本身会一直挂着等single服务健康才返回，这是depends_on: prepare: { condition: service_completed_successfully }的设计。第六步：验证
curl http://127.0.0.1:18020/health # 空 body, HTTP 200 = healthy curl http://127.0.0.1:18020/v1/models # {"object":"list","data":[{"id":"qwen3.8-27b",...}]}实际聊一句：
curl -X POST http://127.0.0.1:18020/v1/chat/completions \ -H "Authorization: Bearer $VLLM_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3.8-27b", "messages": [{"role":"user","content":"用一句话介绍你自己"}], "max_tokens": 200 }'返回：
我是通义千问（Qwen），一个能帮你解答问题、写文案、做分析和写代码的 AI 助手。
usage显示 prompt_tokens=56, completion_tokens=70, 其中 reasoning_tokens=40 —— Qwen3.8 是 thinking 模型，会先输出思考过程再给答案。注意：thinking 模型的 thinking tokens 也算 decode token。速度实测
写了个 streaming 测速脚本（仓库里
bench/bench_speed.py，跑 8 个真实 chat prompt 测 C1 速度）：p00 r0 | ctx= 186t out= 106t | TTFT=0.19s decode=1.22s | decode= 87.1 tok/s p01 r0 | ctx= 194t out= 231t | TTFT=0.20s decode=2.20s | decode= 104.9 tok/s p02 r0 | ctx= 188t out= 256t | TTFT=0.19s decode=2.63s | decode= 97.2 tok/s p03 r0 | ctx= 190t out= 135t | TTFT=0.19s decode=1.66s | decode= 81.2 tok/s p04 r0 | ctx= 187t out= 215t | TTFT=0.19s decode=1.12s | decode= 191.4 tok/s <- 代码生成 p05 r0 | ctx= 187t out= 256t | TTFT=0.19s decode=2.39s | decode= 107.0 tok/s p06 r0 | ctx= 189t out= 185t | TTFT=0.20s decode=1.20s | decode= 154.5 tok/s <- 英文输出 p07 r0 | ctx= 186t out= 256t | TTFT=0.19s decode=2.06s | decode= 124.2 tok/s === 8 runs, avg ctx=188t avg out=205t === TTFT 0.19s decode tok/s 118.5 e2e tok/s 105.5118.5 tok/s decode (C1 greedy, 250-350W) — 跟项目 README 里 single-user 的 120-130 tok/s (dflash2) 参考值基本一致。
观察：
任务类型 速度 原因猜测 代码生成 (p04) 191.4 tok/s 结构化 token，draft acceptance 高 英译中 (p06) 154.5 tok/s 英文 token 模式更可预测，acceptance 高 中文输出 (p01, p05, p07) 100-125 tok/s 普通水平 短回答 (p00, p03) 81-87 tok/s prefill 占比大，avg 下来低 SPEC=dflash2 + DFLASH_TOKENS=15：reproducing 25k 文档能到 382 tok/s（draft 主要从 context 复制）
总结
这套方案把 Qwen3.8-27B 模型专门针对3090 24GB进行优化，全套打包安装运行，成品直接可以测试。如果只是想要个本地模型玩玩，这个项目是目前最省事的方案之一 ——
docker compose up -d三条命令搞定，剩下的全是细节调优。 -
@Prio 速度增加不了多少了， 哪怕是 nvlink， 这个速度基本最高了。 即使3090双卡张量并行， 也就是到 250左右把最高。 不过就像你说的， 双卡可以开更多的上下文， 而且可以开 radix cache , prefill 数据会好很多。 所以不用光盯着decode速度看， 花钱总是有好处的。
@johnnybegood 好的，那目前看来我不用买nvlink桥接器了，我如果后续跑comfy 好像nvlink作用也不大？
-
，
J johnnybegood 引用了 此主题
-
大家都在用qwen 3.8 - 27B模型，请问下这个模型在编程、文学方面怎么样？和目前deepseek v4 flash 差多少。
编程能力对比：本地旗舰 vs 云端快枪
Qwen 3.8-27B 在编程基准测试上表现抢眼，多项Agentic编程和软件工程评测得分甚至高于Claude Opus 4.6 Max。在SWE-bench Pro上得分61.7，LiveCodeBench v6更是达到90.3分。不过，这些亮眼数据目前主要来自阿里官方，缺乏独立的第三方复现验证。实际使用中，有用户反馈其代码能力的上下限差距较大，在复杂长任务中表现可能不够稳定。DeepSeek V4 Flash 则更侧重于“高效交付”。它在Terminal Bench 2.1上得分82.7，LiveCodeBench得分91.6，编程实力不容小觑。其MoE架构使得每次推理仅激活约13B参数，运行速度极快且API成本极低，非常适合需要快速迭代、批量处理代码的开发场景。社区实测中，有用户将其接入编码工具后反馈“works wonderfully”，未出现错误。
小结：如果你追求本地部署、数据绝对隐私，且硬件配置充足，Qwen 3.8-27B是很好的选择。如果你需要低成本、高并发地处理编程任务，或集成到云端工作流中，DeepSeek V4 Flash的性价比和速度优势明显。
️ 文学创作对比：中文网文感 vs 全面创意力
Qwen 3.8-27B 在中文文学创作上展现出独特的“网文质感”。有用户实测其辅助写小说时，能一针见血地指出文案“爽点不够、整体太平”，对爽文节奏的把控优于偏理工型的模型。社区还基于它训练了中文网文风格的LoRA模型，使其在写作时能带有自然的网络小说质感。其原生262K上下文（可扩展至1M）也足以一次性处理整本小说进行总结或改写。DeepSeek V4 Flash 的创意写作能力则更为“全面且稳定”。在第三方评测中，其“短篇故事开头”用例得分92.8分，“文学角色”扮演得分87分。正式版在角色扮演方面的提升显著，写文质量据评测可“基本追平GLM 5.2”。它的1M原生上下文非常适合处理超长篇小说，且生成速度快，有评测显示其创意写作速度可达67 tokens/秒，是前代的3倍。
小结：如果你主要进行中文网络小说创作，且希望模型能理解“爽点”等网文特有概念，Qwen 3.8-27B的针对性更强。如果你需要广泛的创意写作支持（包括科幻、角色扮演等），并追求生成效率和极低的成本，DeepSeek V4 Flash是更稳妥的选择。
总结与选择建议
两者的差距并非简单的“谁强谁弱”，而是设计哲学的不同：选择 Qwen 3.8-27B，如果你：拥有24GB以上显存的GPU，重视数据隐私和本地离线运行，需要图像/视频理解能力，且主要任务是中文网文创作或Agent编程。
选择 DeepSeek V4 Flash，如果你：追求极致的API性价比，需要处理超长文本（百万级），看重稳定的云端服务速度，或希望模型在广泛的创意写作和编程任务中都有均衡表现。
-
测试平台 尔英12700H DDR4 64G 技嘉3090 24G
.me/uploads/9cf793af-b18b-4eb8-bdb4-ec1a8fe535a9.png)
-
也部署了这个仓库：vLLM vs llama.cpp 同条件 A/B（3090 单卡，128K 上下文）
楼主好，也部署了这个仓库（vLLM 0.28 + W4A16 AutoRound-fast + DFlash2），同样是单卡 3090 24G。但我的用法和楼主不太一样：我是拿它给 agent 长会话（DSH）当后端，每步平均上下文约 79K token，比仓库标准测速的 ~190 token 深得多。所以顺手做了 vLLM 和 llama.cpp 的同条件 A/B 对比，数据放出来供参考。
部署配置
项 vLLM 侧 llama.cpp 侧 硬件 RTX 3090 24G 独占（功耗墙 280W），另有 3070 8G 未参与 同左 环境 Windows 10 + WSL2 (Ubuntu)，vLLM 0.28.0 原生 venv llama.cpp，Windows 原生 模型 Qwen3.8-27B-W4A16-AutoRound-fast（项目自带，与楼主同款）Qwen3.8-27B-Uncensored-Q4_K_M.ggufKV 精度 int8（ int8_per_token_head，CTX=long）q8_0 上下文上限 131072 131072 投机解码 DFlash2，7 草稿 draft-mtp，3 草稿 视觉塔 启用 启用（mmproj F16） 环境备注：Docker 路线放弃了——NVIDIA Container Toolkit 的 nvidia.github.io 源国内实测 0~1 KB/s，清华/中科大/阿里云镜像全 404/403。改走 WSL2 原生 venv + 离线 wheel（torch/vllm/triton/flashinfer 共 180 个 wheel 离线备好），装完不需要 toolkit。
测试口径（保证可比性的 5 条）
- decode = completion_tokens / (total − ttft)，严格剔除预填，绝不把 prefill 平均进去
- 用真实提示词（仓库文档 + vLLM 源码，约 3.2 MB），不用随机 token——投机解码接受率完全取决于草稿能否猜中，随机 token 跑分没有意义
- 每个提示词加盐，避免被前缀缓存服务，测到的才是「冷」预填
- 先预热再测，丢弃首轮（含 JIT 编译，读数偏低 30~50%）
- 两侧都关思考（
enable_thinking: false）——否则思考 token 会把max_tokens预算吃光，两边不可比（实测：不关时 16 token 全被思考占掉，content为空）
实测数据
冷预填
上下文 vLLM llama ~1K 1141 t/s（0.90s） 977 t/s（1.05s） ~3.8K 1141 t/s（3.37s） 1083 t/s（3.54s） ~15.7K 936 t/s（16.78s） 1070 t/s（14.68s） ~44K 645 t/s（67.44s） 936 t/s（47.08s） vLLM 预填随上下文衰减明显（1141→645），llama 平稳得多（977→936），15.7K 起反超，44K 处快 45%。
★ 深上下文 decode（核心发现）
上下文 vLLM llama 胜负 ~1.9K 96.4 t/s 48.7 t/s vLLM 2.0× ~7.6K 72.1 t/s 50.7 t/s vLLM 1.4× ~23K 40.7 t/s 44.9 t/s llama 1.1× ~44K 29.2 t/s 42.4 t/s llama 1.45× ~75K 18.2 t/s 42.0 t/s llama 2.3× 差距不在绝对速度，在衰减曲线的形状：
vLLM : 96.4 → 18.2 t/s 掉 −81% ← 断崖式衰减 llama: 48.7 → 42.0 t/s 掉 −14% ← 几乎平坦交叉点在 20K 附近：浅上下文 vLLM 快一倍，深上下文 llama 反超且差距持续拉大。
前缀缓存（对 agent 场景价值最大的一项）
冷 TTFT 热 TTFT 加速 命中率 vLLM 39.38s 2.17s 18.2× 96% llama 31.65s 0.21s 147.6× 100% agent 场景反复发送同一前缀（工具定义 + 历史消息），llama 热启动几乎瞬时，这项差异直接体现在每一轮的响应延迟上。
根因分析
vLLM 为什么深上下文崩得快：
- 投机解码验证开销随上下文线性增长：DFlash2 每步要对 7 个草稿 token 做一次多查询验证注意力，上下文越长这一步的 KV 读取越贵。DFlash2 接受率 48.0%、tokens/step 4.36——这是它浅上下文快 2 倍的直接原因，但这个优势随上下文增长迅速蒸发
- int8 KV 反量化开销：CTX=long 用
int8_per_token_head配 Triton attention 反量化，llama 的 q8_0 KV 有更成熟的 dequant 路径 - CUDA graph 捕获尺寸限制：为了不 OOM，
max_cudagraph_capture_size被压到 32，深上下文的部分 shape 落到 eager 路径
llama 为什么能保持平坦：
draft-mtp是模型自带的 MTP 头（非独立草稿模型），验证成本远低于 DFlash2 的 7 草稿 + 路径选择器，GGML 的 KV 管理也更直接。代价是浅上下文只有 vLLM 的一半——MTP 接受率不如 DFlash2。结论与建议
场景 推荐 理由 agent 长会话（20K+ 上下文） llama.cpp 75K 处快 2.3×；热启动 0.21s 短问答 / 单轮任务 vLLM 1.9K 处快 2.0× 需要视觉 两者都支持 都加载了视觉塔 我的当前决策：日常主力切回 llama.cpp，vLLM 方案完整保留作备选。
给楼主和各位两个提示：
- 仓库标准测速（8 条真实聊天 prompt，~190 token）覆盖的是 vLLM 占优的浅上下文区间；如果拿来做 agent 长会话，建议补一组深上下文 decode 测试（23K/44K/75K），否则断崖要等真实使用才会暴露
- 「128K prefill 1200t/s」应该是前缀缓存开启 + 固定 prompt 的口径；我们的「冷预填」（加盐防前缀缓存命中）在 44K 是 645 t/s 且还在衰减。两个数字都对，口径不同
顺带：无审查版也测了
leminkozey/Qwen3.8-27B-Uncensored-W4A16-AutoRound（同 AutoRound W4A16 配方，abliterated 无审查版）：DFlash2 接受率 52.2%（略高于官方版 48.0%）、tokens/step 4.66，浅上下文 ~100 tok/s，245K 上下文。深上下文衰减曲线与官方版一致——瓶颈在 vLLM/DFlash2 侧，不在模型侧。一个 Qwen3.8 的坑（与部署无关但很影响体验）
Qwen3.8 官方
chat_template.jinja默认reasoning_effort=xhigh，思考 token 会把输出预算烧光导致content为空（实测同问题 xhigh=373 token / low=136 /enable_thinking=false=28，答案质量无差异）。vLLM 侧用请求参数{"chat_template_kwargs": {"enable_thinking": false}}即可覆盖，不用换模板。 -
也部署了这个仓库：vLLM vs llama.cpp 同条件 A/B（3090 单卡，128K 上下文）
楼主好，也部署了这个仓库（vLLM 0.28 + W4A16 AutoRound-fast + DFlash2），同样是单卡 3090 24G。但我的用法和楼主不太一样：我是拿它给 agent 长会话（DSH）当后端，每步平均上下文约 79K token，比仓库标准测速的 ~190 token 深得多。所以顺手做了 vLLM 和 llama.cpp 的同条件 A/B 对比，数据放出来供参考。
部署配置
项 vLLM 侧 llama.cpp 侧 硬件 RTX 3090 24G 独占（功耗墙 280W），另有 3070 8G 未参与 同左 环境 Windows 10 + WSL2 (Ubuntu)，vLLM 0.28.0 原生 venv llama.cpp，Windows 原生 模型 Qwen3.8-27B-W4A16-AutoRound-fast（项目自带，与楼主同款）Qwen3.8-27B-Uncensored-Q4_K_M.ggufKV 精度 int8（ int8_per_token_head，CTX=long）q8_0 上下文上限 131072 131072 投机解码 DFlash2，7 草稿 draft-mtp，3 草稿 视觉塔 启用 启用（mmproj F16） 环境备注：Docker 路线放弃了——NVIDIA Container Toolkit 的 nvidia.github.io 源国内实测 0~1 KB/s，清华/中科大/阿里云镜像全 404/403。改走 WSL2 原生 venv + 离线 wheel（torch/vllm/triton/flashinfer 共 180 个 wheel 离线备好），装完不需要 toolkit。
测试口径（保证可比性的 5 条）
- decode = completion_tokens / (total − ttft)，严格剔除预填，绝不把 prefill 平均进去
- 用真实提示词（仓库文档 + vLLM 源码，约 3.2 MB），不用随机 token——投机解码接受率完全取决于草稿能否猜中，随机 token 跑分没有意义
- 每个提示词加盐，避免被前缀缓存服务，测到的才是「冷」预填
- 先预热再测，丢弃首轮（含 JIT 编译，读数偏低 30~50%）
- 两侧都关思考（
enable_thinking: false）——否则思考 token 会把max_tokens预算吃光，两边不可比（实测：不关时 16 token 全被思考占掉，content为空）
实测数据
冷预填
上下文 vLLM llama ~1K 1141 t/s（0.90s） 977 t/s（1.05s） ~3.8K 1141 t/s（3.37s） 1083 t/s（3.54s） ~15.7K 936 t/s（16.78s） 1070 t/s（14.68s） ~44K 645 t/s（67.44s） 936 t/s（47.08s） vLLM 预填随上下文衰减明显（1141→645），llama 平稳得多（977→936），15.7K 起反超，44K 处快 45%。
★ 深上下文 decode（核心发现）
上下文 vLLM llama 胜负 ~1.9K 96.4 t/s 48.7 t/s vLLM 2.0× ~7.6K 72.1 t/s 50.7 t/s vLLM 1.4× ~23K 40.7 t/s 44.9 t/s llama 1.1× ~44K 29.2 t/s 42.4 t/s llama 1.45× ~75K 18.2 t/s 42.0 t/s llama 2.3× 差距不在绝对速度，在衰减曲线的形状：
vLLM : 96.4 → 18.2 t/s 掉 −81% ← 断崖式衰减 llama: 48.7 → 42.0 t/s 掉 −14% ← 几乎平坦交叉点在 20K 附近：浅上下文 vLLM 快一倍，深上下文 llama 反超且差距持续拉大。
前缀缓存（对 agent 场景价值最大的一项）
冷 TTFT 热 TTFT 加速 命中率 vLLM 39.38s 2.17s 18.2× 96% llama 31.65s 0.21s 147.6× 100% agent 场景反复发送同一前缀（工具定义 + 历史消息），llama 热启动几乎瞬时，这项差异直接体现在每一轮的响应延迟上。
根因分析
vLLM 为什么深上下文崩得快：
- 投机解码验证开销随上下文线性增长：DFlash2 每步要对 7 个草稿 token 做一次多查询验证注意力，上下文越长这一步的 KV 读取越贵。DFlash2 接受率 48.0%、tokens/step 4.36——这是它浅上下文快 2 倍的直接原因，但这个优势随上下文增长迅速蒸发
- int8 KV 反量化开销：CTX=long 用
int8_per_token_head配 Triton attention 反量化，llama 的 q8_0 KV 有更成熟的 dequant 路径 - CUDA graph 捕获尺寸限制：为了不 OOM，
max_cudagraph_capture_size被压到 32，深上下文的部分 shape 落到 eager 路径
llama 为什么能保持平坦：
draft-mtp是模型自带的 MTP 头（非独立草稿模型），验证成本远低于 DFlash2 的 7 草稿 + 路径选择器，GGML 的 KV 管理也更直接。代价是浅上下文只有 vLLM 的一半——MTP 接受率不如 DFlash2。结论与建议
场景 推荐 理由 agent 长会话（20K+ 上下文） llama.cpp 75K 处快 2.3×；热启动 0.21s 短问答 / 单轮任务 vLLM 1.9K 处快 2.0× 需要视觉 两者都支持 都加载了视觉塔 我的当前决策：日常主力切回 llama.cpp，vLLM 方案完整保留作备选。
给楼主和各位两个提示：
- 仓库标准测速（8 条真实聊天 prompt，~190 token）覆盖的是 vLLM 占优的浅上下文区间；如果拿来做 agent 长会话，建议补一组深上下文 decode 测试（23K/44K/75K），否则断崖要等真实使用才会暴露
- 「128K prefill 1200t/s」应该是前缀缓存开启 + 固定 prompt 的口径；我们的「冷预填」（加盐防前缀缓存命中）在 44K 是 645 t/s 且还在衰减。两个数字都对，口径不同
顺带：无审查版也测了
leminkozey/Qwen3.8-27B-Uncensored-W4A16-AutoRound（同 AutoRound W4A16 配方，abliterated 无审查版）：DFlash2 接受率 52.2%（略高于官方版 48.0%）、tokens/step 4.66，浅上下文 ~100 tok/s，245K 上下文。深上下文衰减曲线与官方版一致——瓶颈在 vLLM/DFlash2 侧，不在模型侧。一个 Qwen3.8 的坑（与部署无关但很影响体验）
Qwen3.8 官方
chat_template.jinja默认reasoning_effort=xhigh，思考 token 会把输出预算烧光导致content为空（实测同问题 xhigh=373 token / low=136 /enable_thinking=false=28，答案质量无差异）。vLLM 侧用请求参数{"chat_template_kwargs": {"enable_thinking": false}}即可覆盖，不用换模板。 -
测试平台 尔英12700H DDR4 64G 技嘉3090 24G
