跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • 深色
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(不使用皮肤)
  • 不使用皮肤
折叠
品牌标识

抡锤者

  1. 主页
  2. LLM讨论区
  3. 4 X L20 部署本地模型 ,求大神指点

4 X L20 部署本地模型 ,求大神指点

已定时 已固定 已锁定 已移动 LLM讨论区
nvidial20multi-gpu
19 帖子 5 发布者 341 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • Foster XuF Foster Xu

    我做了一下测试,好像数据很垃圾啊

    6c791cda-f8e6-4d9c-a704-3d2d22a13064-image.jpeg

    terryT 离线
    terryT 离线
    terry
    超级版主
    发表于 最后由 terry 编辑
    #10

    @Foster-Xu 好吧确实如此,SG-Lang Bug较多,版本地狱。你折腾VLLM也对,你的主板PCIE再差,也不至于这个速度,肯定是配置有问题。但是我们没环境,没办法帮你分析。你要实在搞不定,就用4卡单独跑4个实例。按理说你的卡是数据中心卡,支持NVLINK的,试试看?

    油管:https://www.youtube.com/@抡锤者

    1 条回复 最后回复
    0
    • Foster XuF 离线
      Foster XuF 离线
      Foster Xu
      发表于 最后由 编辑
      #11

      刚才部署了单卡的情况,请参考。

      INT8 单卡部署成功了!关键数据:

      模型权重:18.06 GiB(从 54 GB 量化到 18 GB)
      KV cache 可用:20.78 GiB
      KV cache 容量:332,662 tokens
      最大并发:2.54x(128K 请求)
      enforce-eager 模式(无 CUDA graph)


      INT8 + CUDA graph: 33.41 tok/s。比 enforce-eager 的 23 tok/s 快了很多,但和 TP=4 BF16 的 34 tok/s 差不多。单卡没快多少,原因是 CUDA graph 部分 capture 失败,回退到了 eager 模式的那些层变慢了。

      现在清理 INT8,试 INT4 (AWQ)。但 vLLM 的在线 AWQ 量化不太稳定,让我改试 --quantization fp8——FP8 量化更轻量,精度损失极小,且 L20 支持 FP8 计算。


      1 条回复 最后回复
      0
      • Foster XuF 离线
        Foster XuF 离线
        Foster Xu
        发表于 最后由 编辑
        #12

        9a5566a0-ed30-438f-8ada-7be445773609-image.jpeg

        1 条回复 最后回复
        0
        • kop wangK 在线
          kop wangK 在线
          kop wang
          超级版主
          发表于 最后由 编辑
          #13

          这个只能围观了。没打过这么富裕的仗……

          说正经的,单卡,8比特量化,33.41 tok/s这个数据从他的显存位宽来看也差不多合理。但是多卡*4就完全不是我能理解的领域了……
          我更好奇的是prefill性能如何。

          虚心交流,一起进步

          1 条回复 最后回复
          0
          • Foster XuF 离线
            Foster XuF 离线
            Foster Xu
            发表于 最后由 编辑
            #14

            太复杂了,都是GLM 5.1 + ClaudeCode在干,我也是围观的人... -_-!

            1 条回复 最后回复
            0
            • kop wangK 在线
              kop wangK 在线
              kop wang
              超级版主
              发表于 最后由 编辑
              #15

              按理说这么大的显存,而且多卡并行,应该是无脑FP16+256K上下文的。但是因为完全没经验,所以就不班门弄斧了。
              期待楼主的成果。

              虚心交流,一起进步

              1 条回复 最后回复
              0
              • williamlouisW 离线
                williamlouisW 离线
                williamlouis
                超级版主
                发表于 最后由 williamlouis 编辑
                #16

                直接生成一套方案:参考即可。
                其中夹杂了,AI长期学习我产生的记忆。会按我的习惯做出部署。可以直接忽略。
                这套 4×L20(184GB 显存) 的配置,最适合的定位是:本地大模型推理 API 节点,跑 32B–70B 级别 Dense 模型 或 量化版 MoE 模型,对外提供 OpenAI 兼容接口。

                个人主页:xlkj.org Telegram https://t.me/xlkjorg

                1 条回复 最后回复
                1
                • terryT terry 于 将此主题固定
                • terryT 离线
                  terryT 离线
                  terry
                  超级版主
                  发表于 最后由 编辑
                  #17

                  大佬,你的卡算力比4090弱一点,带宽稍差一点,但是也足够了,显存很大,如果没有NVLink,我建议直接跑Qwen3.6 27b q4km量化模型,上LLamal.cpp,每个卡跑一个实例,不要跑什么INT8之类的。Q4量化足够了,推理时会返回BF16计算,这是目前最成熟的生态,KV量化方案你是N卡,建议上Turoquant Turbo3,既然是AI在操作,可以和它说明你的需求,AI不是一直很聪明的,你要坚持自己的意见,否则无限制折腾。记得把MTP加上,一步到位。VLLM的AQW量化模型没有不稳定的说法,我亲测过,完全没问题。你的单卡跑AI视频或者任何其他应用都够,大模型你可以选择2张卡,3张卡,空出一张卡做ComfyUI。我认为这样比较有性价比,调度也自由,不用考虑互联带宽问题。

                  油管:https://www.youtube.com/@抡锤者

                  Foster XuF 1 条回复 最后回复
                  0
                  • 易 离线
                    易 离线
                    易先生
                    编写于 最后由 编辑
                    #18

                    L20单卡,我用SGLANG部署的qwen3.6-27B(FP8),MTP设置为3,速度大概45,开130K上下文,但只能2个
                    并发

                    1 条回复 最后回复
                    1
                    • terryT terry

                      大佬,你的卡算力比4090弱一点,带宽稍差一点,但是也足够了,显存很大,如果没有NVLink,我建议直接跑Qwen3.6 27b q4km量化模型,上LLamal.cpp,每个卡跑一个实例,不要跑什么INT8之类的。Q4量化足够了,推理时会返回BF16计算,这是目前最成熟的生态,KV量化方案你是N卡,建议上Turoquant Turbo3,既然是AI在操作,可以和它说明你的需求,AI不是一直很聪明的,你要坚持自己的意见,否则无限制折腾。记得把MTP加上,一步到位。VLLM的AQW量化模型没有不稳定的说法,我亲测过,完全没问题。你的单卡跑AI视频或者任何其他应用都够,大模型你可以选择2张卡,3张卡,空出一张卡做ComfyUI。我认为这样比较有性价比,调度也自由,不用考虑互联带宽问题。

                      Foster XuF 离线
                      Foster XuF 离线
                      Foster Xu
                      编写于 最后由 编辑
                      #19

                      GPU: 4× NVIDIA L20 (48GB each, Ada Lovelace, sm_89)
                      CPU: 4× L20 = 192GB 总显存 (用了 33GB / 18%)
                      RAM: 251GB
                      存储: /home 2.5TB 可用
                      驱动: NVIDIA 550.54.14
                      OS: CentOS 7.9

                      Model: Qwen3.6-27B-FP8 (基础架构 qwen3_5_text, hybrid GatedDeltaNet)
                      架构: 64 层, 5120 hidden, 24 attention heads, 4 KV heads
                      注意力: 16 × (3× GatedDeltaNet + 1× Gated Attention) (3:1 比例)
                      MTP: 1 个 MTP 头 (multi-token prediction)
                      训练 ctx: 262,144 (256K)
                      量化: Q5_K_XL (Unsloth Dynamic 2.0)
                      文件: /home/models/qwen3-27b-mtp-gguf/Qwen3.6-27B-UD-Q5_K_XL.gguf
                      大小: 19.0 GB
                      GGUF源: unsloth/Qwen3.6-27B-MTP-GGUF

                      主机

                      mkdir -p /tmp/llama-build/host-out
                      cd /tmp/llama-build && git clone --depth 1 https://github.com/ggml-org/llama.cpp.git

                      构建脚本(必须放在源码树内,容器才能看到)

                      cat > /tmp/llama-build/llama.cpp/build-wrapper.sh <<'EOF'
                      #!/bin/bash
                      exec >/tmp/build-out/build.log 2>&1
                      set -e
                      apt-get update -qq
                      apt-get install -y -qq cmake build-essential git ninja-build
                      cd /src/llama.cpp
                      rm -rf build
                      cmake -B build -G Ninja
                      -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
                      -DCMAKE_CUDA_ARCHITECTURES='89'
                      -DGGML_NATIVE=OFF -DGGML_CUDA_F16=ON
                      -DGGML_RPC=OFF -DBUILD_SHARED_LIBS=OFF
                      cmake --build build -j$(nproc) --target llama-server llama-cli llama-quantize
                      EOF
                      chmod +x /tmp/llama-build/llama.cpp/build-wrapper.sh

                      docker run -d --name llama-cpp-build
                      -v /tmp/llama-build/llama.cpp:/src/llama.cpp
                      -v /tmp/llama-build/host-out:/tmp/build-out
                      -w /src/llama.cpp
                      nvidia/cuda:12.4.0-devel-ubuntu22.04
                      bash /src/llama.cpp/build-wrapper.sh

                      mkdir -p /home/models/qwen3-27b-mtp-gguf
                      nohup bash -c '
                      curl -L --fail --retry 5
                      -o /home/models/qwen3-27b-mtp-gguf/Qwen3.6-27B-UD-Q5_K_XL.gguf
                      "https://hf-mirror.com/unsloth/Qwen3.6-27B-MTP-GGUF/resolve/main/Qwen3.6-27B-UD-Q5_K_XL.gguf"
                      ' > /tmp/gguf-dl.log 2>&1 &

                      === 模型 ===

                      -m /models/Qwen3.6-27B-UD-Q5_K_XL.gguf

                      === 服务 ===

                      --host 0.0.0.0
                      --port 8003
                      --api-key 7cd5aace-734d-4223-813c-2406506c4b0a

                      === 上下文(256K 完整原生)===

                      -c 262144
                      -ngl 999 # 所有层上 GPU

                      === 多 GPU 切分(2×L20)===

                      --split-mode layer # 按层切分
                      --tensor-split 0.5,0.5 # GPU 2+3 各 50%
                      --main-gpu 0 # 主 GPU(相对 0 = 物理 GPU 2)

                      === 并发 ===

                      --parallel 2 # 2 路并发
                      --kv-unified # ⭐️ 关键:共享 KV 池
                      --cont-batching # 连续批处理

                      === KV 量化(节省 50% 显存)===

                      --cache-type-k q8_0
                      --cache-type-v q8_0

                      === MTP 投机解码(1.7-2× 加速)===

                      --spec-type draft-mtp # ⭐️ 关键
                      --spec-draft-n-max 3 # 草稿 3 token
                      --draft-p-min 0.85 # 接受阈值

                      === 性能优化 ===

                      --flash-attn auto # Flash Attention
                      --no-mmap --mlock # 不 mmap,锁内存
                      --batch-size 512
                      --ubatch-size 128

                      === 采样 ===

                      --top-p 0.95 --top-k 20 --temp 0.7 --repeat-penalty 1.0

                      === 模板 ===

                      --jinja
                      --chat-template-kwargs '{"enable_thinking":false}'
                      --reasoning off

                      🔚 结论

                      vLLM 7.5 TPS 是 L20 + Qwen3-27B-FP8 物理上限(之前我们认为无法突破)。

                      llama.cpp + MTP 投机解码 在相同硬件上达到 50 TPS(平均)/ 80 TPS(峰值),6.7-10.7× 加速,且能跑 256K 完整原生上下文 + 2 路并发,显存只用 33GB。

                      关键启示:vLLM 框架本身在 hybrid Mamba/GDN 模型上有性能瓶颈(vLLM 0.5.x 测速 7.5 TPS,0.20.1 测速 7.45 TPS,几乎一样)。要突破必须换底层框架 — llama.cpp + MTP speculative decoding 是当前唯一现实路径。

                      1 条回复 最后回复
                      2
                      • ,terryT terry 取消固定了此主题
                      • ,terryT terry 固定了此主题
                      • ,系统 取消固定了此主题

                      你好!看起来您对这段对话很感兴趣,但您还没有一个账号。

                      厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。

                      有了你的建议,这篇帖子会更精彩哦 💗

                      注册 登录
                      回复
                      • 在新帖中回复
                      登录后回复
                      • 从旧到新
                      • 从新到旧
                      • 最多赞同


                      • 登录

                      • 没有帐号? 注册

                      • 第一个帖子
                        最后一个帖子
                      0
                      • 版块
                      • 最新
                      • 标签
                      • 热门
                      • 用户
                      • 群组