• 请不要在回答技术问题时复制粘贴 AI 生成的内容
SSang
V2EX  ›  程序员

32G 显存 Qwen3.8-27B-GGUF 配置分享

  •  
  •   SSang · Aug 26 · 6998 views
    This topic created in 71 days ago, the information mentioned may be changed or developed.

    本文使用 V100-SXM2-16GB 双卡运行:

    起始配置

    基础配置从 UD-IQ4_XS + 256k context + Q4 KV + mmproj 开始

    这个配置是我感觉目前最理想的配置:

    • 能跑满 256k 上下文,真正可以用在编码/生产场景了
    • prefill 速度在 300-400tok/s ,decode 速度在 30-60tok/s
    • 默认就是 4 并发,再往上调意义不大,4 并发的 decode 就只剩 10tok/s 了

    所以可以从这个配置开始,进行微调

    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 快一点);加多模态;加投机解码。如果你想要跑更高的量化模型,则可以考虑去掉上面说的这些。或者你也可以继续尝试其他厂家量化的模型,会有些许区别。

    53 replies  •  2026-09-17 12:56:11 +08:00
    paranoiagu
    paranoiagu
    Aug 26❤️2
    1
    我也分享一下我的。
    以下是 7900XTX 24G 的

    nohup ./build/bin/llama-server \
    -hf unsloth/Qwen3.8-27B-GGUF:UD-IQ4_XS \
    --ctx-size 262144 \
    --parallel 1 \
    --n-gpu-layers 999 \
    --flash-attn on \
    --cache-type-k q4_0 \
    --cache-type-v q4_0 \
    --split-mode none \
    --spec-type draft-mtp \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 20 \
    --min-p 0.0 \
    --presence-penalty 0.0 \
    --repeat-penalty 1.0 \
    --jinja \
    --chat-template-file qwen3.8.jinja \
    --reasoning on \
    --reasoning-preserve \
    --chat-template-kwargs '{"enable_thinking":true,"reasoning_effort":"xhigh"}' \
    --host 0.0.0.0 \
    --port 4086 \
    -fit off \
    --cache-ram 1024 \
    --batch-size 2048 \
    --ubatch-size 512 \
    --log-file run_Qwen3.8-27B-GGUF-Thinking.log \
    > /dev/null 2>&1 &


    以下是 2 张 16G V100 的

    #!/bin/bash

    nohup ./build/bin/llama-server \
    -hf unsloth/Qwen3.8-27B-GGUF:Q4_K_M \
    --parallel 1 \
    --ctx-size 262144 \
    --split-mode none \
    --cache-type-k q4_0 \
    --cache-type-v q4_0 \
    --flash-attn on \
    --split-mode tensor \
    --spec-type draft-mtp \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 20 \
    --min-p 0.0 \
    --presence_penalty 0.0 \
    --repeat_penalty 1.0 \
    --jinja \
    --chat-template-file /mnt/data/llama.cpp/qwen3.8.jinja \
    --reasoning on \
    --reasoning-preserve \
    -fit off \
    --cache-ram 1024 \
    --host 0.0.0.0 \
    --port 4086 \
    --n-gpu-layers 999 \
    --chat-template-kwargs '{"enable_thinking":true,"reasoning_effort":"xhigh"}' \
    --log-file run_Qwen3.8-27B-GGUF-Thinking.log \
    > /dev/null 2>&1 &
    SSang
    SSang
    OP
    Aug 26 via Android
    2
    @paranoiagu 这个 chat template 你用的是哪个。有用吗,我还没自己测这块,之前 Qwen3.6 的时候调了半天,最后发现调的乱七八糟的。
    paranoiagu
    paranoiagu
    Aug 26 via Android❤️1
    3
    https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates

    用了这个才能在 Claude code 中调用
    catazshadow
    catazshadow
    Aug 26 via Android
    4
    4 张 T10 ,AWQ 量化,F16 的 kv ,256K 长度,vllm tp ,mtp 长度 2 ,decode 能有 45 tps ,并发 2 的时候能摸到 80 tps ,爽了很久了
    SSang
    SSang
    OP
    Aug 26
    5
    @catazshadow prefill 的速度怎么样
    SSang
    SSang
    OP
    Aug 26
    6
    我觉得 V100 用 Q4 KV 就是极限了,只有用 Q4 能到 500 左右的 prefill 速度,Q5 开始就几乎上不了 3 位数了。
    catazshadow
    7
    @SSang 看 log 平均 7 、800 的样子吧,有时能飙到一千多但我觉得应该是算错了,还见过一次一万多的
    catazshadow
    8
    @SSang Q5 应该是有些量化方法在反量化的时候,硬件没有原生支持,需要的指令太多。老卡上我都不敢碰非 2 的整数次幂的量化
    chengsitom
    9
    电费呢?
    SSang
    SSang
    OP
    Aug 26
    10
    @chengsitom 一天 4 度左右吧
    SSang
    SSang
    OP
    Aug 26
    11
    @catazshadow 确实是这样。V100 Q4 有时候也能 1000 多,应该不是算错,感觉是合理峰值。Q5 性能确实比 Q8 还更差,Q8 偶尔还能上 100.
    realJamespond
    12
    32g 可以跑 udq6kl,kvq8,mtp3,c64k
    jhytxy
    jhytxy
    Aug 26
    13
    只能跑 q4 的话建议用 gemma4 qat
    qat 版本训练的时候就针对小显存,q4 量化的性能可以和 q8 打
    catazshadow
    14
    @SSang 可以找个带 switch 的 PCIe 扩展板上 4 卡,V100 好像玩的人比 T10 多一点
    GuardX
    GuardX
    Aug 26
    15
    话说 5070 12G 能跑吗
    SSang
    SSang
    OP
    Aug 26
    16
    @realJamespond udq6kl,kvq8,mtp3,c64k 这个配置你主要是用在什么场景?

    我这里的话 c64k 太小了,写代码一直在那 compact ,然后 kvq8 100tok/s 的 prefill 速度我写代码平均 ttft 都要 100 多秒,有点难受。
    SSang
    SSang
    OP
    Aug 26
    17
    @jhytxy 是 gemma4-31B 吗?我看 AA 上面的 Intelligence Index 还蛮低的,满血才 30 分,上一代的 qwen3.6-27B 满血都有 38 分了。他的 Q4 的会比 Qwen3.8-27B 的 Q8 量化还厉害吗?

    上一代的 Qwen3.6-27B-Q4 对我来说也是不可用的状态。3.8 我这几天用下来感觉是达到可用水平了。
    SSang
    SSang
    OP
    Aug 26
    18
    @catazshadow hh ,我也在考虑,但是现在好像 nvlink 都还是挺贵的状态。

    这个 T10 是 Tesla 还是 Turing 啊?
    SSang
    SSang
    OP
    Aug 26
    19
    @GuardX 12G 能跑 q2 吧,上下文应该能到 128k ,不行就将降低到 64k ,kv 应该也只能跑 q4 ( q8 理论占用就要 8G 显存了),但我觉得 q2 写代码的话还是不太行的,你日常对话玩玩还行。
    lyonll
    lyonll
    Aug 26
    20
    hello 劣化是怎么测的呢,试试 kv 用 turbo3 试试呢
    --cache-type-k turbo3 `
    --cache-type-v turbo3 `

    我试了 5060ti 16G 不开多模态 q3 能开到 161k 35tok/s 左右,但是不好测效果
    SSang
    SSang
    OP
    Aug 26
    21
    @GuardX 反正我看了其他的帖子基本上也是这个结论:「 Q4 及以上质量良好,Q4 以下断崖式下降」
    SSang
    SSang
    OP
    Aug 26
    22
    @lyonll 我有空也测测 turbo3 ,但其实 q4 我觉得就已经有些不太行了。

    我就是体感劣化,有的是很明显的劣化的,就是很简单的任务,比如我让他改一个前端展示从 ID 改成获取名称展示,改了量化之后他直接开始一直循环不输出结果,这种就是明显的劣化了。

    我 q8 跑就是很慢,但是基本上任务都能完成,但是 q4 还是会有概率出现乱回答或者死循环。

    ---

    然后还有就是我个人感觉本地部署 prefill 速度比 decode 速度重要,decode 只要有 10tok/s 就有一点安慰作用了,但是我要是等几分钟他还在那转圈,就会开始怀疑是不是模型挂了还是报错了。

    (我之前其实是有算过的,特别是长上下文编码的场景,prefill 速度会很大程度决定任务的总耗时,100k 左右的上下文,基本上要缓存命中到 98% 以上,decode 速度才会对总耗时有些影响)
    catazshadow
    23
    @SSang 图灵,相当于 2080 这代

    nvlink 自己玩玩用不上,PCIe 就足够了,我这个甚至是跨了 NUMA 节点的 PCIe 通信。T10 也没有 nvlink 。

    nvlink 黄鱼上 300 块一个桥接器简直就是抢钱
    SSang
    SSang
    OP
    Aug 26
    24
    @catazshadow 噢噢,就是直接 pcie 拆分 4 卡的是吧。确实 pcie 也听够了,我之前搞过一个 pcie x1 拆分 4 卡的,当时也测不出有什么差距,但后来不知道被我丢哪去了。
    catazshadow
    25
    @SSang 垃圾佬服务器主板上直插的,甚至都不全是 x16 的槽
    realJamespond
    26
    我这边是双 3090 有 50ts 左右,c64k 一般用在主 agent 分配任务给子 agent + 任务列表 修改多个文件还行。子 agent 不会被主 agent 上下文影响。
    ashong
    ashong
    Aug 26
    27
    7900xtx 现在跑 unsloth/ud-q5-k-xl 或者 unsloth/ud-q5-k_m
    cache-kv q8_0 上下文 140k
    或者
    cache-kv bf16 上下文 100k
    lyonll
    lyonll
    Aug 26
    28
    @SSang 期待测试 turbo3 的结果
    我用 turbo3 可以节省很多显存,看原理好像很强 几乎没有降智的感觉
    不过就是一直没合并到主线,因为好像 turbo3 目前只针对特定平台
    wises
    wises
    Aug 26
    29
    最近想买显卡的心越来越重, 一个消费级别小主机, 配了 48G DDR5 内存, 跑了下 qwen3.5/3.6 - 27B/35B 全卡那里却显卡了. 不知道买 24G 显存的显卡是否可以?
    paranoiagu
    paranoiagu
    Aug 26 via Android
    30
    楼主,今天我看到这个,你试过吗?

    1CatAI/1Cat-vLLM: V100 / SM70-focused vLLM engineering fork for modern LLM inference. https://share.google/ltDrm9bzMUKScR6xR
    BingoW
    BingoW
    Aug 26
    31
    如果是单卡 4080s 32G 情况会更好吗?我本人是 2080ti 22G 的卡,再考虑要不要升级
    strobber16
    32
    建议上 kvarn 试下
    zzutmebwd
    zzutmebwd
    Aug 26
    33
    今晚要发布高度稀疏的 3.8 flash next 了,源神启动!
    zzutmebwd
    zzutmebwd
    Aug 26
    34
    @BingoW 我的升级路线是 mi50 32g x2 → 2080ti 22g x2 → 4080s 32G x2 → pro6000 96G 。感受就是欲望永无止境。4080s 32g 跑 27b 还是慢,预填充两三千,解码六七十。换 pro6000 感觉就是翻倍多一点,显存用不完。
    SSang
    SSang
    OP
    Aug 26 via Android
    35
    @paranoiagu 他这个是用来跑原生 tensor 模型的,好像最少也得 64G 显存吧。玩不起,32G 还是老老实实 gguf 吧
    SSang
    SSang
    OP
    Aug 26 via Android
    36
    @strobber16 主要不是显存不够,是 prefill 太慢了
    SSang
    SSang
    OP
    Aug 26 via Android
    37
    @zzutmebwd 有些过于富有了,只能说玩 V100 的都是穷人
    paranoiagu
    paranoiagu
    Aug 27 via Android
    38
    @SSang 看了介绍好像可以 awq 量化模型,但是有人反应上下文不够长,我今天试试
    ljian6530
    ljian6530
    Aug 27
    39
    # 我也试了一下,2 张 T4 卡,启动参数如下:
    export CUDA_VISIBLE_DEVICES=0,1

    /opt/llama.cpp/build/bin/llama-server \
    --host 0.0.0.0 \
    --port 8000 \
    --metrics \
    --verbosity 3 \
    -m /var/unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-IQ4_XS.gguf \
    --alias Qwen3.8-27B \
    --n-gpu-layers all \
    --split-mode layer \
    --tensor-split 1,1 \
    --ctx-size 131072 \
    --parallel 1 \
    --predict 8192 \
    --batch-size 4096 \
    --ubatch-size 1024 \
    --flash-attn on \
    --cache-type-k q4_0 \
    --cache-type-v q4_0 \
    --cache-prompt \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 20 \
    --min-p 0.0 \
    --load-mode mmap
    # 结果
    Prefill:70.50 tok/s
    Decode:13.51 tok/s
    1024 tokens:75.8s
    这速度几乎是无法生产的,大佬看看这堆废铁( nvidia Tesla T4 16GiB )还有必要跑吗,但使用 8 张卡跑四个实例并行是不是也是可以?
    coefu
    coefu
    Aug 27
    40
    @ljian6530 你用 8 卡 128G 跑最新的 qwen3.8 flash ,都比这个好。
    SSang
    SSang
    OP
    Aug 27
    41
    @ljian6530 T4 我觉得,不然你拿去玩 Minimax H3 吧(狗头),kvq4 这个 prefill 速度,没有优化的空间了。你就算 8 卡速度 x4 ,也才 280tok/s
    SSang
    SSang
    OP
    Aug 27
    42
    我发现了一个新的参数 `--split-mode tensor` 之前我用 row 一直报错 not support split buffers ,我以为不能并行,但是用 tensor 又能并行了,很神奇。

    然后没有 nvlink 的话可能要加环境变量 NCCL_P2P_DISABLE=1 。

    开了这个之后我的 prefill 速度大概到了 600tok/s 了
    SSang
    SSang
    OP
    Aug 27
    43
    不对,我重新又试了一下,关掉 `--split-mode tensor` prefill 速度其实也是 600tok/s 。

    他除了能让我两张卡同时跑满之外,没有任何提升(笑哭),甚至还有些许下降我觉得。估计是 PCIe 拖累了。
    jinsongzhaocn
    44
    @paranoiagu --cache-type-k q4_0 --cache-type-v q4_0 这两个参数试过 q8_0 吗,不知道这样的精度--ctx-size 要不要减半。“编程场景优先选 q8_0/q8_0 ,行业公认甜点配置”
    paranoiagu
    paranoiagu
    Aug 27 via Android
    45
    @jinsongzhaocn q8_0 会 爆显存,除非降上下文
    nosugar
    nosugar
    Aug 27
    46
    调成 bf16 或 f16 的 KV ,Q4 KV 好像会影响能力,f16 会占用更多 VRAM ,需要缩一下上下文 256k context 真的有必要这么大吗
    nosugar
    nosugar
    Aug 27
    47
    参考 1 楼,`--parallel 1`对应设置成“1”后面的会排队,4 的话也会占用 VRAM ,VRAM 不够会溢出到内存,速度大降,速度调整核心是要保证 VRAM 够,不会溢出
    paranoiagu
    paranoiagu
    Aug 27 via Android
    48
    @nosugar bf16 ,v100 不支持,写程序的话,256K 还是有必要的
    paranoiagu
    paranoiagu
    Aug 27 via Android
    49
    @nosugar 我测试结果是并行*2 , 后
    上下文/2 ,所以我为了长上下文,并行改为 1
    paranoiagu
    paranoiagu
    Aug 31 via Android
    50
    @SSang 有没有试过 dflash2 加速?
    SSang
    SSang
    OP
    Sep 7
    51
    统一回复一下:

    1. --parallel ,这个会直接平均分配你的上下文窗口,需要考虑清楚,如果你的上下文已经不够了,不建议开
    2. 我认为 256k 是能让主 Agent 达到生产可用的基线,可以根据实际情况降低一点,但不能太少。
    3. v100 的 kv 用 q8_0 ,prefill 速度降低将近 10 倍,我觉得已经不可用于生产了( q4 劣化是不可避免的,社区普遍认为会损失 20% 左右智商,而 q8 一般被认为是几乎不损失)
    4. dflash, mtp, ngram 这些投机解码技术实际上很吃场景,如果用过小米的那个 ultraspeed 就知道了,最开始几轮都能达到 1000toks/s ,但随着上下文增加或任务变得复杂,采纳率会大幅降低,最后也拉不开太大差距了。还有资源的可以考虑开一开(所以目前我都不太研究投机解码技术,而且实际干活的时候我更关心 prefill 我的场景,prefill 基本要占用总耗时的 80%)。
    5. turbo 量化看起来是社区版本,一猫的那个我之前也有关注,我可能等过段时间有空了,再研究研究吧,现在他稳定跑着我有点找不到时间停机测试(我的用量还蛮大的)。


    > PS:我这里的达到生产可用指的是能作为主 Agent ,执行一般复杂的任务(即实现某个功能/调研某个产品/输出某个分析等的 AgentLoop ,而不是简单的修改/整理文件工作或 Chat ),并且不会有长时间的等待(常规任务 Prefill 最多不能超过 30s ,或者至少 500tok/s 左右; Decode 至少 10tok/s 吧)。

    > 如果你只是想要玩一玩 Chat ,或者作为 Subagent 执行一些简单任务,比如搜索,整理文件,提交代码,生成 Changelog 等,则一般 32-64k 已经非常足够(通常 Agent 的初始上下文会有 4-16k ,简单任务一般不会超过 32k )。玩酒馆的话一般还是建议至少 128k 以上的上下文。写代码我觉得至少 200k 吧,不然就一直在压缩。
    SSang
    SSang
    OP
    Sep 7
    52
    哦,酒馆的话,decode 速度可能就还蛮重要的,特别是那些用 html 的本。
    lovoror
    lovoror
    Sep 17
    53
    写代码的话还是 Q5 起步吧,是可以感受到差别的。其他的 Q4 就行
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   5025 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 108ms · UTC 07:11 · PVG 15:11 · LAX 23:11 · JFK 02:11
    ♥ Do have faith in what you're doing.