Qwen3.8 27B, 单卡也可以跑191 tok/s : 一套优化到极致的部署与实测
-
大家都在用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
