跳转至内容
  • 首页
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • 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. 版块
  3. AI硬件
  4. 让你们看看垃圾魔改卡2080ti 的威力 qwen3.6-27b fp8 精度 速度能到 60tokens/s nvlink 连接

让你们看看垃圾魔改卡2080ti 的威力 qwen3.6-27b fp8 精度 速度能到 60tokens/s nvlink 连接

已定时 已固定 已锁定 已移动 AI硬件
27 帖子 13 发布者 885 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • 5 离线
    5 离线
    566656661
    超凡大师
    编写于 最后由 编辑
    #2

    以前手上有2080ti 22gb的時候只用過llama.cpp混合其他卡使用

    那個時候還沒有mtp, FA 2不支援(現在好像也是)

    GEMM運算搭配4070 Ti Super偶爾會掛, 所以玩了幾個月就賣掉了

    1 条回复 最后回复
    0
    • yu zhengyangY yu zhengyang

      1. 硬件环境

      项目 规格
      GPU 2 × NVIDIA GeForce RTX 2080 Ti(SM75 / Turing)
      GPU 显存 22,528 MiB / 卡(共 ~44 GB)
      GPU 驱动 580.159.03
      NVLink 2 Link/GPU,双向 25.781 GB/s/Link(NV2)
      GPU 最大时钟 GPU0: 2160 MHz / GPU1: 2175 MHz;显存: 7000 MHz
      CPU AMD Ryzen 7 5700X 8 核 16 线程
      内存 47 GiB DDR4
      操作系统 Ubuntu 24.04.4 LTS(Kernel 6.17.0-29-generic)
      CUDA Toolkit 12.9

      2. 软件环境

      组件 版本
      Python 3.12.3
      vLLM 0.24.0
      PyTorch 2.11.0
      FlashInfer 0.6.12(flashinfer-python + flashinfer-cubin,含 PR3621 SM75 patch)
      Triton 3.6.0
      Transformers 5.12.1
      NumPy 2.3.5

      vLLM 源码路径:/home/zyyuc/vllm-2080ti-0.24.0-qwopus
      Python venv 路径:/home/zyyuc/vllm-env-0240-qwopus
      FlashQLA 路径:/home/zyyuc/FlashQLA-SM70-SM75


      3. 模型信息

      项目 值
      模型名称 Qwen3.6-27B-DSV4Pro-Thinking-FP8
      模型路径 /home/zyyuc/models/Qwen3.6-27B-DSV4Pro-Thinking-FP8
      服务名称 qwen-local
      架构 Qwen3_5ForConditionalGeneration
      model_type qwen3_5
      Hidden layers 64
      Hidden size 5120
      Attention heads 24
      KV heads 4(GQA)
      Vocab size 248,320
      最大位置编码 262,144
      量化方式 FP8(Marlin weight-only,block_size=128×128)
      模型总大小 ~29 GB(12 个语言模型 shard + 879 MB vision + 456 MB MTP)
      多模态 支持图片输入(Qwen3VL Processor,vision_config hidden_size=1152)
      MTP 支持(MTP3 投机解码,3 个 speculative tokens)

      混合架构说明

      该模型为 Mamba + Attention 混合架构:

      • Attention 层:使用 KV cache,O(n) 随上下文增长
      • Mamba 层(linear_attn):固定递归状态,O(1) 不随上下文增长
      • Mamba cache mode:align(与 prefix caching 兼容)

      4. 服务加载参数

      4.1 systemd unit 完整配置

      [Unit]
      Description=Qwopus3.6 27B FP8 vLLM 0.24.0 stable server FP8 KV 100K
      After=network-online.target
      Wants=network-online.target
      
      [Service]
      Type=simple
      User=zyyuc
      WorkingDirectory=/home/zyyuc/vllm-2080ti-0.24.0-qwopus
      
      # ===== 环境变量 =====
      Environment=CUDA_HOME=/usr/local/cuda
      Environment=PATH=/usr/local/cuda/bin:/home/zyyuc/vllm-env-0240-qwopus/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      Environment=LD_LIBRARY_PATH=/usr/local/cuda/lib64:/usr/local/cuda/lib64/stubs
      Environment=PYTHONPATH=/home/zyyuc/FlashQLA-SM70-SM75
      Environment=HF_ENDPOINT=https://hf-mirror.com
      Environment=VLLM_USE_DEEP_GEMM=0
      Environment=OMP_NUM_THREADS=8
      Environment=VLLM_USE_FLASHINFER_SAMPLER=0
      Environment=VLLM_QWOPUS_MTP_BF16_DRAFT=1
      Environment=VLLM_SM75_SPEC_SYNC_MODE=safe
      
      # ===== 启动前校验 =====
      ExecStartPre=/home/zyyuc/check-flashinfer-pr3621-sm75.sh
      
      # ===== 启动命令 =====
      ExecStart=/home/zyyuc/vllm-env-0240-qwopus/bin/python -m vllm.entrypoints.openai.api_server \
        --host 0.0.0.0 \
        --port 8000 \
        --model /home/zyyuc/models/Qwen3.6-27B-DSV4Pro-Thinking-FP8 \
        --served-model-name qwen-local \
        --dtype half \
        --tensor-parallel-size 2 \
        --device-ids 0,1 \
        --quantization fp8 \
        --kv-cache-dtype fp8_e4m3 \
        --max-model-len 100000 \
        --enable-prefix-caching \
        --max-num-seqs 1 \
        --max-num-batched-tokens 4096 \
        --enable-chunked-prefill \
        --no-async-scheduling \
        --skip-mm-profiling \
        --reasoning-parser qwen3 \
        --reasoning-config '{"reasoning_start_str":"<think>","reasoning_end_str":"</think>","default_thinking_token_budget":4000}' \
        --default-chat-template-kwargs '{"enable_thinking":true}' \
        --enable-auto-tool-choice \
        --tool-call-parser qwen3_coder \
        --chat-template-content-format string \
        --gpu-memory-utilization 0.92 \
        --additional-config '{"gdn_prefill_backend":"flashqla_legacy"}' \
        --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
        --compilation-config '{"cudagraph_mode":"PIECEWISE","cudagraph_capture_sizes":[4],"max_cudagraph_capture_size":4}' \
        --override-generation-config '{"temperature":0.6,"top_p":0.95,"top_k":20,"min_p":0.0,"presence_penalty":0.0,"repetition_penalty":1.06}' \
        --cpu-offload-gb 0 \
        --disable-uvicorn-access-log
      
      Restart=always
      RestartSec=10
      TimeoutStartSec=900
      StandardOutput=append:/home/zyyuc/vllm-0240-main-8000.log
      StandardError=append:/home/zyyuc/vllm-0240-main-8000.log
      
      [Install]
      WantedBy=multi-user.target
      

      4.2 关键参数说明

      参数 值 说明
      --dtype half FP16 计算 SM75 无 BF16 Tensor Core,FP16 最快
      --tensor-parallel-size 2 TP2 双卡并行,单卡 11GB 装不下 27B
      --device-ids 0,1 GPU 0+1 明确选卡,不设 CUDA_VISIBLE_DEVICES
      --quantization fp8 Marlin FP8 Weight-only 量化,节省显存
      --kv-cache-dtype fp8_e4m3 FP8 KV Cache KV cache 容量 +79.5%(115K→207K tokens)
      --max-model-len 100000 100K 上下文 经 95K smoke 验证通过
      --enable-prefix-caching 开启 重复前缀加速,Mamba align 模式
      --max-num-seqs 1 单请求 保证长上下文和显存稳定
      --max-num-batched-tokens 4096 4K Chunked prefill 分块大小
      --enable-chunked-prefill 开启 长上下文必须,否则 prefill OOM
      --no-async-scheduling 关闭 max_num_seqs=1 时无收益
      --skip-mm-profiling 跳过 不为多模态预留显存 profiling
      --reasoning-parser qwen3 Qwen3 thinking 匹配 <think></think> 格式
      --tool-call-parser qwen3_coder coder parser 兼容 Claude 等客户端工具调用
      --gpu-memory-utilization 0.92 92% 留 8% 余量防止 OOM
      --additional-config gdn_prefill_backend=flashqla_legacy FlashQLA SM75 GDN prefill 必须用 legacy 后端
      --speculative-config mtp,num_speculative_tokens=3 MTP3 投机解码,3 个 draft tokens
      --compilation-config cudagraph_capture_sizes=[4] 仅 size 4 max_num_seqs=1 + MTP3 = 4 token slots
      --override-generation-config 采样参数 temperature=0.6, top_p=0.95, top_k=20, repetition_penalty=1.06

      4.3 环境变量说明

      环境变量 值 说明
      VLLM_USE_DEEP_GEMM=0 关闭 SM75 不支持 DeepGEMM
      VLLM_USE_FLASHINFER_SAMPLER=0 关闭 SM75 上 FlashInfer sampler 有 bug
      VLLM_QWOPUS_MTP_BF16_DRAFT=1 BF16 draft MTP draft 模型用 BF16 精度
      VLLM_SM75_SPEC_SYNC_MODE=safe safe 模式 SM75 投机解码安全同步
      OMP_NUM_THREADS=8 8 线程 CPU 端 tokenizer 并行
      PYTHONPATH=.../FlashQLA-SM70-SM75 FlashQLA SM75 GDN kernel 路径
      HF_ENDPOINT=hf-mirror.com 镜像 国内 HuggingFace 镜像

      5. 运行时状态

      5.1 KV Cache 配置

      指标 值
      cache_dtype fp8_e4m3
      block_size 1600(自动对齐)
      num_gpu_blocks 162
      kv_cache_size_tokens 207,692
      kv_cache_max_concurrency 2.077
      mamba_cache_mode align
      mamba_ssm_cache_dtype float32
      enable_prefix_caching True

      5.2 GPU 显存占用

      GPU 已用 总量 利用率
      GPU0 21,720 MiB 22,528 MiB 96.4%
      GPU1 21,752 MiB 22,528 MiB 96.5%

      5.3 显存分配估算

      模型权重 (27B FP8 / TP2):  ~19,500 MiB/卡  (固定不可变)
      CUDA context + PyTorch:    ~1,700 MiB/卡   (固定开销)
      KV cache (162 blocks):       ~507 MiB/卡   (很小)
      剩余空闲:                     ~280 MiB/卡
      

      6. 性能测试结果

      6.1 测试方法

      • 测试脚本:/home/zyyuc/fp8_vs_fp16_ab_test.py
      • 每个 prompt 使用 64 字符随机 UUID + 随机词库生成,确保 prompt_tokens_cached=0
      • JIT 暖机:短请求 ×2 + 20K 暖机 + 60K 暖机
      • 正式测试:20K ×3(max_tokens=256)+ 60K ×2(max_tokens=128)
      • 流式请求,记录 TTFT、decode tok/s、prefill tok/s、MTP acceptance

      6.2 FP8 KV Cache 测试结果(当前生产配置)

      Run 上下文 TTFT (s) Prefill (tok/s) Decode (tok/s) MTP Acceptance
      run1 17,042 tok 13.090 1,301.9 88.0 78.9%
      run2 17,052 tok 13.138 1,297.9 77.6 ⚠️ 68.3%
      run3 17,041 tok 13.182 1,292.7 87.8 78.9%
      run1 50,983 tok 45.587 1,118.4 87.1 63.6%
      run2 51,109 tok 46.039 1,110.1 105.6 76.1%

      ⚠️ run2 受 Triton JIT 编译干扰,decode 偏低

      6.3 FP16 KV Cache 基线对比

      Run 上下文 TTFT (s) Prefill (tok/s) Decode (tok/s) MTP Acceptance
      run1 17,131 tok 13.180 1,299.8 87.0 77.5%
      run2 17,129 tok 13.236 1,294.1 87.0 77.1%
      run3 17,054 tok 13.162 1,295.7 81.5 71.6%
      run1 51,036 tok 45.733 1,116.0 117.7 81.1%
      run2 51,036 tok 46.042 1,108.5 94.9 68.3%

      6.4 汇总对比

      指标 FP16 均值 FP8 均值 差异 结论
      20K TTFT 13.193s 13.137s -0.4% 持平
      20K Prefill 1,296.5 tok/s 1,297.5 tok/s +0.1% 持平
      20K Decode 85.2 tok/s 84.5 tok/s -0.8% 持平
      20K MTP 75.4% 75.4% 0% 持平
      60K TTFT 45.888s 45.813s -0.2% 持平
      60K Prefill 1,112.3 tok/s 1,114.2 tok/s +0.2% 持平
      60K Decode 106.3 tok/s 96.3 tok/s -9.4% 持平*
      60K MTP 74.7% 69.8% -4.9pp 持平*
      KV cache 容量 115,714 tok 207,692 tok +79.5% FP8 优势

      *60K 仅 2 次采样,方差大,不具统计显著性

      6.5 关键结论

      1. FP8 KV Cache 不带来 decode/prefill 性能提升:与 FP16 基本持平,符合 SM75 架构预期(无原生 FP8 Tensor Core,KV 需反量化为 FP16 计算)
      2. FP8 KV Cache 的唯一真实收益是容量 +79.5%:从 115K tokens 提升到 207K tokens
      3. 性能瓶颈是 GPU 计算饱和:SM 利用率 96-100%,功耗接近 200W 限制
      4. MTP3 投机解码有效:acceptance ~75%,decode 速度显著高于无投机解码(~85 vs ~29 tok/s)0a5cc0af4379e04afd30118c12ca5199.jpg 501ad836559120875e35186d535980aa.jpg
      williamlouisW 离线
      williamlouisW 离线
      williamlouis
      超级版主
      编写于 最后由 编辑
      #3

      @yu-zhengyang 很好的实践。主板的型号能介绍一个下吗?

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

      1 条回复 最后回复
      1
      • yu zhengyangY 离线
        yu zhengyangY 离线
        yu zhengyang
        编写于 最后由 编辑
        #4

        华硕的x570 pro 很普通的板子 不过可以自动拆分 pcie 8*8

        1 条回复 最后回复
        0
        • terryT 在线
          terryT 在线
          terry
          超级版主
          编写于 最后由 编辑
          #5

          很好,实践是检验真理的唯一标准

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

          1 条回复 最后回复
          0
          • V 离线
            V 离线
            vosrock
            德高望重 劳动模范
            编写于 最后由 编辑
            #6

            又多了一个性价比之选,显存大还是硬道理

            1 条回复 最后回复
            0
            • S 离线
              S 离线
              seabass
              编写于 最后由 编辑
              #7

              谢谢分享,我也要试试

              1 条回复 最后回复
              0
              • S 离线
                S 离线
                seabass
                编写于 最后由 编辑
                #8

                NVlink 重要吗?没有会慢吗?

                1 条回复 最后回复
                0
                • Metal ZhaoM 离线
                  Metal ZhaoM 离线
                  Metal Zhao
                  编写于 最后由 编辑
                  #9

                  这个测试非常详尽,效果非常理想,甚至超过了双3090的速度。会不会导致2080ti魔改卡再涨价 lol

                  williamlouisW A 2 条回复 最后回复
                  0
                  • Metal ZhaoM Metal Zhao

                    这个测试非常详尽,效果非常理想,甚至超过了双3090的速度。会不会导致2080ti魔改卡再涨价 lol

                    williamlouisW 离线
                    williamlouisW 离线
                    williamlouis
                    超级版主
                    编写于 最后由 编辑
                    #10

                    @Metal-Zhao 不会的。驱动就会慢慢淘汰这些老卡。技术上我点赞,现有的就跑跑是好事。没有的选择入手就是被降智了。4系都站在生命周期上了。价格下来后。游戏卡=算力卡的事会慢慢分开。

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

                    1 条回复 最后回复
                    0
                    • L 离线
                      L 离线
                      llchen
                      编写于 最后由 编辑
                      #11

                      那双3080 20G魔改 效果不是更好吗

                      terryT 1 条回复 最后回复
                      0
                      • Metal ZhaoM Metal Zhao

                        这个测试非常详尽,效果非常理想,甚至超过了双3090的速度。会不会导致2080ti魔改卡再涨价 lol

                        A 离线
                        A 离线
                        applejuice
                        技术大牛 劳动模范
                        编写于 最后由 编辑
                        #12

                        @Metal-Zhao 为什么超过双3090?的确是便宜过3090好多

                        1 条回复 最后回复
                        0
                        • S 离线
                          S 离线
                          stormaround
                          编写于 最后由 编辑
                          #13

                          这么装不改水,温度能压住吗?

                          1 条回复 最后回复
                          0
                          • L llchen

                            那双3080 20G魔改 效果不是更好吗

                            terryT 在线
                            terryT 在线
                            terry
                            超级版主
                            编写于 最后由 编辑
                            #14

                            @llchen 是的,有人发过,老帖子里找下。

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

                            1 条回复 最后回复
                            0
                            • jingy yiJ 离线
                              jingy yiJ 离线
                              jingy yi
                              编写于 最后由 编辑
                              #15

                              很好的经验,谢谢,但我没有复现成功,请教下:

                              1. 模型的确切下载来源(HF repo 名),和 Distill 版是什么关系(我下载的是Qwen3.6-27B-DSV4Pro-Thinking-Thinking-Distill-FP8)
                              2. VLLM_QWOPUS_MTP_BF16_DRAFT=1 具体做了什么——是运行时把 FP8 MTP 权重 cast 成 BF16,还是加载外部 BF16 shard?对应 fork 里哪个 commit/文件?
                              3. 这个 patch 能否在主线 vLLM 0.24 上单独应用(他们既然在 0.24 base 上改的,patch 大概率能摘出来)
                              4. 你是否试过不开这个开关的接受率——如果他们 FP8 draft 也是 ~46%,开了到 75%,就是你缺的那块拼图的完整对照数据
                              5 terryT 2 条回复 最后回复
                              1
                              • jingy yiJ jingy yi

                                很好的经验,谢谢,但我没有复现成功,请教下:

                                1. 模型的确切下载来源(HF repo 名),和 Distill 版是什么关系(我下载的是Qwen3.6-27B-DSV4Pro-Thinking-Thinking-Distill-FP8)
                                2. VLLM_QWOPUS_MTP_BF16_DRAFT=1 具体做了什么——是运行时把 FP8 MTP 权重 cast 成 BF16,还是加载外部 BF16 shard?对应 fork 里哪个 commit/文件?
                                3. 这个 patch 能否在主线 vLLM 0.24 上单独应用(他们既然在 0.24 base 上改的,patch 大概率能摘出来)
                                4. 你是否试过不开这个开关的接受率——如果他们 FP8 draft 也是 ~46%,开了到 75%,就是你缺的那块拼图的完整对照数据
                                5 离线
                                5 离线
                                566656661
                                超凡大师
                                编写于 最后由 编辑
                                #16

                                @jingy-yi

                                1. 應該就是nerkyor/Qwen3.6-27B-DSV4Pro-Thinking-Distill-FP8, 不過我看不懂為什麼你這個有2個Thinking...

                                2. 前者, 至少我看完Model Card之後理解是FP8 Scale up到BF16, 對應mtp.safetensors

                                3. 可以, 但是不要用cu129 nightly, 目前ffmpeg有bug, vllm的container會起不來

                                4. Draft的接受率很看工作性質, 如果是編程或者輸出為Structured Output接受率會很高, 如果內容很飄忽跟沒有固定形式則會很低, 不能直接比較

                                1 条回复 最后回复
                                0
                                • jingy yiJ jingy yi

                                  很好的经验,谢谢,但我没有复现成功,请教下:

                                  1. 模型的确切下载来源(HF repo 名),和 Distill 版是什么关系(我下载的是Qwen3.6-27B-DSV4Pro-Thinking-Thinking-Distill-FP8)
                                  2. VLLM_QWOPUS_MTP_BF16_DRAFT=1 具体做了什么——是运行时把 FP8 MTP 权重 cast 成 BF16,还是加载外部 BF16 shard?对应 fork 里哪个 commit/文件?
                                  3. 这个 patch 能否在主线 vLLM 0.24 上单独应用(他们既然在 0.24 base 上改的,patch 大概率能摘出来)
                                  4. 你是否试过不开这个开关的接受率——如果他们 FP8 draft 也是 ~46%,开了到 75%,就是你缺的那块拼图的完整对照数据
                                  terryT 在线
                                  terryT 在线
                                  terry
                                  超级版主
                                  编写于 最后由 编辑
                                  #17

                                  @jingy-yi
                                  1,基础底座(Base):Qwen3.6-27B。
                                  2, “DSV4Pro-Thinking-Distill”(逻辑思维蒸馏)这是民间技术大神(Nerkyor 等人)做的核心魔改。
                                  老师是谁:DeepSeek-V4-Pro(具有极强的推理、多轮对话和 Agent 思考能力)。
                                  3, 怎么蒸馏的:开发者使用 LoRA 技术($r=64, \alpha=128$),把 DeepSeek-V4-Pro 在思考、推理以及对抗“长文本无限复读”时的思考方式与收敛习惯(Thinking Style),硬生生蒸馏灌输进了 Qwen3.6-27B 里面。
                                  4, 带来的改变:普通 Qwen 在面对极其复杂的 Agent 任务或硬核推理时,有时会陷入死循环或冲破 32K 窗口崩溃;而这个“DSV4Pro 蒸馏版”极大地压缩了无效思考的废话,学会了“如何高效、正确地收敛出答案”,其 GPQA 和长文本 Agent 稳定性直接暴涨。
                                  以上为AI回答,下面这句话是我写的:
                                  就是蒸馏Deepseek的思维方式去提升Qwen3.6

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

                                  1 条回复 最后回复
                                  2
                                  • jingy yiJ 离线
                                    jingy yiJ 离线
                                    jingy yi
                                    编写于 最后由 编辑
                                    #18

                                    感谢两位回复,补充说明一下,我的问题可能没表达清楚:

                                    先澄清:双 Thinking 是我打错了,就是 Nerkyor 的 Qwen3.6-27B-DSV4Pro-Thinking-Distill-FP8,模型背景我了解,不需要科普。我卡住的是复现的工程细节,收窄成三个具体问题:

                                    1. patch 具体位置:#16 说这个 patch 可以摘到主线 0.24 上用——那具体是 fork 里哪个 commit / 哪个文件?求 diff 链接。我知道它是把 mtp.safetensors 的 FP8 scale 到 BF16,但不知道改动在哪,没法摘。

                                    2. 同机同负载的开关对照:#16 说 acceptance 看工作性质不能直接比——完全同意,所以我要的恰恰不是跨环境比较,而是楼主自己同一台机、同一批 prompt 下,VLLM_QWOPUS_MTP_BF16_DRAFT 开/关各跑一次的 acceptance。只有这个对照能证明提升来自 BF16 draft 本身,而不是工作负载差异。如果楼主还留着环境,跑一把关掉的数就够了。

                                    3. 75% 是什么采样条件下测的:greedy(temp=0)还是带温度采样?这个变量比想象中大得多,见下面我们的数据。

                                    作为交换,附上我们的实测(A800 / vLLM 0.24 主线 / MTP3 / FP8 draft 未打 patch,acceptance 用 /metrics 前后差分):

                                    • greedy,10K 上下文:acceptance 52.8%,decode 75.7 tok/s
                                    • greedy,长短上下文合并(278/10K/53K):~46%
                                    • temp=1.0(生产配置,gen_config 默认):acceptance 32.8%,decode 55.7 tok/s

                                    也就是说光温度一个变量就能把 acceptance 从 53% 打到 33%,20 个点。所以楼主的 75% 里,BF16 draft、greedy、编程类负载各贡献多少,不做开关对照 + 对齐采样条件是拆不开的。如果 patch 真有净贡献,我这边 33% 的生产口径能提多少,非常想对齐一下。

                                    5 1 条回复 最后回复
                                    0
                                    • jingy yiJ 离线
                                      jingy yiJ 离线
                                      jingy yi
                                      编写于 最后由 编辑
                                      #19

                                      再补一个关键数据点:我另外下载了 BF16 主仓(全模型高精度、含原生 MTP 头)做对照,同条件(greedy / 10K / MTP3 / metrics 差分)实测 acceptance 也只有 ,46%,和 FP8 版基本持平。这说明精度不是 acceptance 的瓶颈——而这个 patch 的机制如果只是把 FP8 draft cast 成 BF16,那全 BF16 就是它的效果上限,上限都到不了 75%。所以我现在更倾向于:要么 patch 里还有 cast 之外的改动(那就更需要 diff 了),要么 75% 主要来自采样条件和负载类型。楼主给一把开关对照数据,这事就能一锤定音。

                                      1 条回复 最后回复
                                      0
                                      • jingy yiJ jingy yi

                                        感谢两位回复,补充说明一下,我的问题可能没表达清楚:

                                        先澄清:双 Thinking 是我打错了,就是 Nerkyor 的 Qwen3.6-27B-DSV4Pro-Thinking-Distill-FP8,模型背景我了解,不需要科普。我卡住的是复现的工程细节,收窄成三个具体问题:

                                        1. patch 具体位置:#16 说这个 patch 可以摘到主线 0.24 上用——那具体是 fork 里哪个 commit / 哪个文件?求 diff 链接。我知道它是把 mtp.safetensors 的 FP8 scale 到 BF16,但不知道改动在哪,没法摘。

                                        2. 同机同负载的开关对照:#16 说 acceptance 看工作性质不能直接比——完全同意,所以我要的恰恰不是跨环境比较,而是楼主自己同一台机、同一批 prompt 下,VLLM_QWOPUS_MTP_BF16_DRAFT 开/关各跑一次的 acceptance。只有这个对照能证明提升来自 BF16 draft 本身,而不是工作负载差异。如果楼主还留着环境,跑一把关掉的数就够了。

                                        3. 75% 是什么采样条件下测的:greedy(temp=0)还是带温度采样?这个变量比想象中大得多,见下面我们的数据。

                                        作为交换,附上我们的实测(A800 / vLLM 0.24 主线 / MTP3 / FP8 draft 未打 patch,acceptance 用 /metrics 前后差分):

                                        • greedy,10K 上下文:acceptance 52.8%,decode 75.7 tok/s
                                        • greedy,长短上下文合并(278/10K/53K):~46%
                                        • temp=1.0(生产配置,gen_config 默认):acceptance 32.8%,decode 55.7 tok/s

                                        也就是说光温度一个变量就能把 acceptance 从 53% 打到 33%,20 个点。所以楼主的 75% 里,BF16 draft、greedy、编程类负载各贡献多少,不做开关对照 + 对齐采样条件是拆不开的。如果 patch 真有净贡献,我这边 33% 的生产口径能提多少,非常想对齐一下。

                                        5 离线
                                        5 离线
                                        566656661
                                        超凡大师
                                        编写于 最后由 566656661 编辑
                                        #20

                                        @jingy-yi

                                        如果我沒理解錯的話vLLM自己就是這個Patch, FlashInfer裏面的話應該就是這個3620跟3621

                                        Temperature本身就是用來控制模型的隨機程度, 越高代表越不可控, 自然會讓MTP Acceptance Rate大大降低啊, 詳情可以看這份期刊的7.4點

                                        雖然我個人更加相信這個是來自工作内容差異, 而不是關於FP8跟BF16的分別, 畢竟兩者本體27B (FP8對上BF16) 的KLD也小於0.05, MTP估計也會維持在這附近

                                        jingy yiJ 1 条回复 最后回复
                                        0
                                        • 5 566656661

                                          @jingy-yi

                                          如果我沒理解錯的話vLLM自己就是這個Patch, FlashInfer裏面的話應該就是這個3620跟3621

                                          Temperature本身就是用來控制模型的隨機程度, 越高代表越不可控, 自然會讓MTP Acceptance Rate大大降低啊, 詳情可以看這份期刊的7.4點

                                          雖然我個人更加相信這個是來自工作内容差異, 而不是關於FP8跟BF16的分別, 畢竟兩者本體27B (FP8對上BF16) 的KLD也小於0.05, MTP估計也會維持在這附近

                                          jingy yiJ 离线
                                          jingy yiJ 离线
                                          jingy yi
                                          编写于 最后由 编辑
                                          #21

                                          @566656661 说:

                                          @jingy-yi

                                          如果我沒理解錯的話vLLM自己就是這個Patch, FlashInfer裏面的話應該就是這個3620跟3621

                                          Temperature本身就是用來控制模型的隨機程度, 越高代表越不可控, 自然會讓MTP Acceptance Rate大大降低啊, 詳情可以看這份期刊的7.4點

                                          雖然我個人更加相信這個是來自工作内容差異, 而不是關於FP8跟BF16的分別, 畢竟兩者本體27B (FP8對上BF16) 的KLD也小於0.05, MTP估計也會維持在這附近

                                          这个模型的作者说后续会研究发布Patch,说明发布的模型的MTP是未Patch修改版。我实测下来,FP8和FP16的MTP命中率是一样的,就35~55%,代码类高,问题类低。而楼主的MTP命中率较高,所以我想问问是不是他有更新的模型或Patch方法。

                                          1 条回复 最后回复
                                          0

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

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

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

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


                                          • 登录

                                          • 没有帐号? 注册

                                          • 登录或注册以进行搜索。
                                          • 第一个帖子
                                            最后一个帖子
                                          0
                                          • 首页
                                          • 版块
                                          • 最新
                                          • 标签
                                          • 热门
                                          • 用户
                                          • 群组