本文使用 V100-SXM2-16GB 双卡运行:
基础配置从 UD-IQ4_XS + 256k context + Q4 KV + mmproj 开始
这个配置是我感觉目前最理想的配置:
所以可以从这个配置开始,进行微调
services:
qwen3.8-27b:
image: ghcr.io/ggml-org/llama.cpp:server-cuda
container_name: qwen3.8-27b
restart: unless-stopped
ports:
- "8013:8013"
volumes:
- /home/debian/models/gguf:/models
command: >-
--port 8013
--metrics
--verbosity 4
-m /models/unsloth/Qwen3.8-27B-UD-IQ4_XS.gguf
--alias "Qwen3.8-27B"
--n-gpu-layers all
--ctx-size 262144
--predict 32768
--batch-size 4096
--ubatch-size 1024
--flash-attn auto
--cache-prompt
--cache-type-k q4_0
--cache-type-v q4_0
--spec-type ngram-simple
--spec-ngram-mod-n-max 32
--temp 1.0
--top-p 0.95
--top-k 20
--min-p 0.00
--mmproj /models/unsloth/Qwen3.8-27B-mmproj-F16.gguf
--image-min-tokens 1024
deploy:
resources:
reservations:
devices:
- driver: nvidia
capabilities: [gpu]
device_ids: ["0", "1"]
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8013/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
然后说一下一些调整:
往下调到 Q2 劣化非常明显,我认为达不到生产可用程度,但如果你只有 16G 显存,可以考虑用这个玩玩,也能跑到 256k 上下文
Q4 可以再往上调一点,显存是够的,理论上 Q5/Q6 都是能跑的。
Q4 的缓存实际上也是有比较明显的劣化的。
但实测 Q8 KCache (只调整 Key )的 Prefill 速度只剩 60tok/s 了。你的 ttft 会从 20s 内涨到 160s 以上,我认为是生产不可用的程度。
Q5 则是提升不明显,但速度降低显著,也不推荐。
所以我认为 Q4 Cache 虽然有劣化,但仍然是当前 v100 的最优解。
多模态加不加都行,也就占 1G 左右,我测试过程中就没出现就差 1G 就能跑的情况,所以就一直开着
这个投机解码( ngram )收益不是很高,看不太出区别,换 mtp 也差不多,我的建议是显存还够就可以开,但是命中率也很低,看不出明显区别。
总的来说,32G 内存跑 Q4 实际上是很够的,剩下的内存可以用来:提高一点 batch-size (可以 prefill 快一点);加多模态;加投机解码。如果你想要跑更高的量化模型,则可以考虑去掉上面说的这些。或者你也可以继续尝试其他厂家量化的模型,会有些许区别。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.