抡锤者

3080涨了600,3090涨了2000

@老鬼 单卡20g跑27b一般是爆显存，再搞一张正好很舒服。

CUDA_SCALE_LAUNCH_QUEUES=4 /home/simon/llama.cpp/build/bin/llama-server
-m /home/simon/models/Qwen3.6-27B-Q4_K_M.gguf
--mmproj /home/simon/models/mmproj-Qwen_Qwen3.6-27B-f16.gguf
-ngl 99
--host 127.0.0.1
--port 8082
-c 131072
--temp 0.1
--reasoning-budget 2048
--spec-type draft-mtp,ngram-mod
--spec-draft-model /home/simon/models/mtp-Qwen_Qwen3.6-27B-Q8_0.gguf
--spec-draft-n-max 3
--spec-ngram-mod-n-max 5
--spec-ngram-mod-n-min 3
--ubatch-size 768
--batch-size 2048
-fa on
-ctk q4_0
-ctv q4_0

@applejuice 对，hermes子代理最高能飙到70t/s，已经足够了其实

@coin1860 我是两张3080 20g，一共5800好像。hermes跑27b多模态，子代理最高飙到70t/s就极限了。平时就是40-55t/s，主要看MTP猜不猜的中

@ping-lin 先安装hermes，接DeepSeek，让DeepSeek给你检测环境帮你安装

@vosrock 有条件还可以研究一下API的跑图，也都不贵，解放本地算力哈哈。

@gg-lib 先把赚钱放一边，热爱才是能够坚持的原动力。先把DeepSeek接进hermes，让他帮你折腾本地。我是花了不到20块钱，边学边做把本地都搞定了，现在本地稳定50t/s左右，响应体感跟DeepSeek持平

@kop-wang 主要是本地经常更新、调试，出现问题了还可以让DeepSeek救回来。特别是对我这种新手很实用，配置稳定以后还可以让DeepSeek调参，测试本地推理极限

@applejuice 想想就爽

@vosrock 还得是大显存。40g显存可以一边跑模型一边打游戏哈哈，或者一边跑模型一边剪辑看视频

@applejuice 牛皮！这个速度已经很舒服了。hermes用子代理干活也能提高速度，3080最高能跑到70t/s

@applejuice prefill应该是最快的可以双卡同时算，后面就单卡了。感觉最大的优势还是48g，关注一波

@vosrock moe现在确实不行，就算DeepSeep v4这么强的模型也是moe，就能够得到qwen 27b的水平

@vosrock 支持的啊，下午还让AI找了个多模态的用上了

跟贴补充：多模态版 Qwen3.6-27B 测试（ubatch-768）

---

测试日期：2026.05.26

看到前面讨论 ubatch-size 加大能提 prompt 速度 —— 说个反直觉的发现：换了多模态版之后，ubatch 降到 768，生成速度反而没降反升。

背景

从纯文本版升级到多模态版（支持图片理解），模型文件从 1 个变成 3 个：

文件	大小
Qwen3.6-27B-Q4_K_M.gguf（主模型）	17GB
mmproj-Qwen_Qwen3.6-27B-f16.gguf（视觉编码器）	884MB
mtp-Qwen_Qwen3.6-27B-Q8_0.gguf（MTP 权重）	3GB

多了 4GB 权重，GPU1 从 17.2GB → 17.5GB，ubatch-size 从 2048 降到 768（1024 会 OOM）。

启动命令

CUDA_SCALE_LAUNCH_QUEUES=4 /home/simon/llama.cpp/build/bin/llama-server \
  -m /home/simon/models/Qwen3.6-27B-Q4_K_M.gguf \
  --mmproj /home/simon/models/mmproj-Qwen_Qwen3.6-27B-f16.gguf \
  -ngl 99 --host 127.0.0.1 --port 8082 -c 131072 --temp 0 \
  --spec-type draft-mtp,ngram-mod \
  --spec-draft-model /home/simon/models/mtp-Qwen_Qwen3.6-27B-Q8_0.gguf \
  --spec-draft-n-max 3 \
  --spec-ngram-mod-n-max 5 --spec-ngram-mod-n-min 3 \
  --ubatch-size 768 --batch-size 2048 \
  -fa on -ctk q4_0 -ctv q4_0

注意：多模态版需要额外指定 --mmproj 和 --spec-draft-model（MTP 权重单独文件）。

测试结果

每次冷加载后测三次取中值：

测试项	纯文本版（ubatch-2048）	多模态版（ubatch-768）	变化
Prompt 处理速度	50.17 tok/s	180~380 tok/s	受 prompt 长度影响
生成速度	53.18 tok/s	~55 tok/s	+3%
MTP 接受率	—	77~85%	—
GPU0 VRAM	16.1 GB	14.9 GB	↓
GPU1 VRAM	17.2 GB	17.5 GB	↑

几点观察

1. ubatch 降到 768 生成速度反而 54~55 tok/s，比之前 53 tok/s 略高。猜测是 MTP 权重在独立文件中布局更好，或者 ngram 互补起了作用。（也可能是测量误差范围，但同一天多次测试结果一致）

2. Prompt 速度有波动：短 prompt（17t）→ 28 tok/s，长 prompt（55t）→ 378 tok/s。受 CUDA kernel 启动开销影响，prompt 越长越接近纯文本版的 best case。

3. 显存接近极限但并不需要紧张：GPU1 占 17.5GB/20GB，只要不上 ubatch-1024 就不会 OOM。128K 上下文也正常工作。

4. 多 3 分钟调试时间成本，换来图片理解能力，性价比不错。

与之前结论的关系

之前建议 "ubatch-size 尽量拉大" —— 这个结论仍然成立，只是多模态版因额外文件占显存，需要降 ubatch 来腾空间。好消息是降 ubatch 对生成速度的影响微乎其微，主要牺牲的是首 token 延迟和 prompt 处理吞吐。

如果你也在跑多模态模型，建议 ubatch 从 512 开始试，慢慢加到 OOM 之前回退一格，生成速度不会吃亏。

@vosrock 对啊！最起码体感很舒服了，跟云端差不太多了。再就等DFlash了，让AI预估了一下3080估计能到60t/s了

@joker_chang 再搞一个3090啊，后面DFalsh合并进来绝对是福音

@joker_chang 要么就是24g显存不够了。我3080 40g，27b 128k上下文展开就占了32g显存

@joker_chang --ubatch-size 2048改成1024就行，跟Windows没关系

@applejuice 48g我的天，后面还可以关注DFlash，你这跑27b速度不得到80t/s