跳转至内容
  • 版块
  • 最新
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • 浅色
  • 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

  • 默认(LCZ-Blue)
  • 不使用皮肤
  • LCZ-Green
  • LCZ-Blue
  • LCZ-Black
折叠
品牌标识

抡锤者

首页 版块 标签 硬件 AI 广场
  1. 主页
  2. 版块
  3. LLM讨论区
  4. 没苦硬吃!!3090带着小弟跑Qwen3.8-Flash-Next IQ4双卡实测

没苦硬吃!!3090带着小弟跑Qwen3.8-Flash-Next IQ4双卡实测

已定时 已固定 已锁定 已移动 LLM讨论区
rtx3090多卡部署qwen
10 帖子 5 发布者 486 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
回复
  • 在新帖中回复
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • J 离线
    J 离线
    johnnybegood
    劳动模范 技术大牛
    编写于 最后由 johnnybegood 编辑
    #1

    测试日期:2026-08-29
    llama.cpp 版本:b10676 / commit ba29f94da(master HEAD)

    结论先放

    把 Qwen3.8-Flash-Next(Uncensored-IQ4_XS,97 GB,176B 参数)放在RTX 3090 24G带 RTX 3070 8G 这种非对称双卡上,用 llama.cpp 最新 master build(含 qwen4exp 架构支持),实测四档 context 下来:

    • Prefill:4K 301 t/s → 16K 266 t/s → 32K 244 t/s → 64K 280 t/s
    • Decode:4K 26.1 t/s → 16K 23.2 t/s → 32K 19.6 t/s → 64K 15.2 t/s
    • Wall time:4K 灌入+生成 16 秒,64K 灌入+生成 238 秒
    • KV Cache 精度:4K / 16K 用 q8_0;32K / 64K 用 q4_0(显存装不下 q8_0)
    • 整体判断:在没有 R9700 / 5090 / 4090 的前提下,这台机器能把 176B 量级 MoE + sparse-attn 模型扛住到 64K context;本地日常使用(写代码、聊问答、做长摘要)完全 OK。

    1. 测试环境

    1.1 硬件一览

    微信图片_20260829130418_9_5.jpg

    项目 型号 / 规格
    CPU AMD Ryzen 9 3950X(16C / 32T)
    内存 64 GB (实际可用约 60 GB)
    GPU 0 NVIDIA GeForce RTX 3070(8 GB,sm_86,PCIe 4.0 x16 @ x16)
    GPU 1 NVIDIA GeForce RTX 3090(24 GB,sm_86,PCIe 4.0 x16 @ x16)
    总显存 32 GB(3070 + 3090)
    存储 系统 NVMe 4TB
    系统 Ubuntu 22.04.5 LTS(kernel 6.8.0-138-generic)
    NVIDIA 驱动 580.178.04(CUDA 13.0)
    CUDA toolkit nvcc 12.8.93(驱动兼容构建)

    这里要诚实说一句:这是非常不均衡的双卡 —— 一张 8G、一张 24G;而且不是 NVLink。MoE 大模型在两张卡之间按层切的时候,跨卡通信会变成主要瓶颈。但至少比纯 CPU 跑 176B 模型要快很多倍。也试过单张3090加内存跑,真的跑不动,我说的是可以跑起来, 但是跑时间长了就OOM死掉了。

    1.2 软件

    项目 版本
    llama.cpp b10676 / commit ba29f94da(master HEAD,2026-08-28 后)
    CUDA backend sm_86(RTX 3070 / 3090)
    cuDNN 驱动自带
    Backend ggml-cuda.so 0.22.0

    模型 qwen4exp 架构在 c1d0e7a00 之前的 llama.cpp 上会直接报 unknown model architecture: 'qwen4exp',必须升级到 b10660 之后、最好用 master latest。本次实测就是在自己本地源码重建 ba29f94da 之后做的,libllama.so 含 37 个 qwen4exp 相关符号。

    Screenshot from 2026-08-29 11-03-07.png

    1.3 模型

    项目 规格
    模型 Qwen3.8-Flash-Next
    量化 IQ4_XS(4.25 bpw)
    文件大小 97 GB(3 个 GGUF 分片:44.7 GB + 44.7 GB + 7.9 GB)
    参数量 176.94 B(n_params=176943899520)
    架构 qwen4exp(sparse attention + MoE + MTP)
    词表 n_vocab=248320
    嵌入维度 n_embd=2560

    2. 实测结果

    2.1 主表:4K / 16K / 32K / 64K KV Cache 下的 Prefill 与 Decode

    每个数据点跑 3 次(去除冷启动),取 median。

    Context (target) Prompt tokens (actual) Prefill t/s (median) Prefill t/s (max / min) Prefill ms/t (median) Decode t/s (median) Decode ms/t (median)
    4 096 4 057 301.10 308.07 / 292.41 3.32 26.13 38.28
    16 384 16 195 265.95 275.78 / 259.38 3.76 23.15 43.20
    32 768 32 617 244.26 274.77 / 217.99 4.09 19.56 51.11
    65 536 65 461 280.16 280.20 / 279.82 3.57 15.24 65.60

    一个值得注意的事实:Prefill 完全主导长 prompt 的总延迟。即便 64K 下 Decode 慢到 15.2 t/s,单条请求的 64 token 生成只要 4.1 秒;但 Prefill 那 234 秒是真等的。
    如果你的工作流是「长文档一次性灌入 + 短追问」,那你应该把眼睛盯在 Prefill 速度上;如果你做的是「多轮对话、每轮都要新生成 200+ token」,那么 Decode 速度才是体验瓶颈。
    bench_chart_speed.png

    3. 关键参数

    ① 不要写 -ngl 99 也不要写 --split-mode layer --tensor-split 1,3

    我最初是强制 -ngl 99,直接 cudaMalloc failed out of memory。原因很直白:

    • 模型 97 GB,两张卡总显存 32 GB,根本不可能全 offload。
    • 强制 -ngl 99 让 common_fit_params 跳过自动适配,结果某些 expert 层被推到 GPU 0(3070,8 GB)上,单 expert 47 GB 装不下,cudaMalloc 失败。
    • 手动 --tensor-split 1,3 也不行,因为 expert 层本身太大,不能被拆分。
      正确做法:不传 -ngl,让 llama.cpp 自动 fit 能上 GPU 的层,剩下的走 CPU + RAM。本地实测是 3070 占 6.5 GB、3090 占 23 GB、CPU 部分约 53 GB 落到系统内存。

    ② 双卡 + 不对称显存:要打开 --no-mmap

    默认 mmap 会让 CPU 部分按需从外置硬盘页入。我们的模型在外置 /media/johnnyz/PROG_980/ 上,mmap + 频繁换页会让速度大幅波动。加 --no-mmap(已 deprecated,新写法 --load-mode none)一次性预读到 RAM,Prefill 速度更稳定。

    ③ 32K+ 必须把 KV cache 降到 q4_0

    Context KV 精度 KV 占用 可行性
    4 K q8_0 ~0.2 GB ✅ 完全无压力
    16 K q8_0 ~0.8 GB ✅ OK
    32 K q8_0 ~1.6 GB ⚠️ 3090 23 GB 还能装下,但多轮后碎片占用会顶到 OOM
    32 K / 64 K q4_0 ~0.8 GB / ~1.6 GB ✅ 跑稳

    4. 主题深入

    4.1 为什么 Decode 比 Prefill 掉得慢?

    按理说 Decode 阶段每生成一个 token 都要过整个模型,应该比 Prefill 对 ctx 大小更敏感才对。但实测:

    • Prefill:4K → 64K 掉 7%(如果剔除 32K 热降频的噪声)
    • Decode:4K → 64K 掉 42%
      Decode 才是真的对 ctx 敏感。Decode ms/t 从 38 涨到 66(+73%),符合 KV cache scan 成本线性增长的预期。

    这台机器 Decode 慢的真正原因是 MoE 路由的 expert 集中在 GPU 上、但仍需要从 CPU 内存抓其它专家——Flash-Next 是 Q3.8 大改版,专家路由在长 ctx 下触发更频繁,CPU↔GPU 数据搬运更多。

    4.2 64K 反而比 32K Prefill 快的现象分析

    32K run 1 32K run 3 64K run 1 64K run 3
    GPU temp (估计) 73°C 90°C 70°C 85°C
    Prefill t/s 274.77 217.99 280.20 280.16

    表面看是 64K 比 32K 快。真相:

    • 64K 那 3 次 prefills 跑得比较快(每次 ~3.9 分钟),中间 GPU 没空冷
    • 32K 那 3 次拖了更久(每次 ~2.2 分钟预填 + 短生成 + 等待间隔),GPU 进入 thermal steady state
    • 32K 测量的 noise floor 包含了 thermal throttle

    4.3 跨 PCIe 通信开销(推测)

    两张 RTX 3070/3090 之间是 PCIe 4.0 x16,跨卡带宽 ~25 GB/s(实际单工 16-20 GB/s)。MoE expert layer 在 3090(装得下大头)+ 3070(小头)之间切换时,每次专家切换都要搬运 hidden state(2560 dim × FP16 = 5 KB),总量随 layer 数线性增长。

    5. 还没测的东西

    这篇主要是 4K / 16K / 32K / 64K 四档 Prefill + Decode 的单实例单请求测试。还没认真做:

    • --parallel 2/4 多并发压力测试(32GB 总显存不够同时两份全 ctx 跑)
    • 128K / 262K(原生上下文)下的 Prefill 速度——按 issue #27871 描述,262K 在某些驱动上会 cudaMalloc invalid argument;本机也想验证
    • 多轮对话"//////" 退化复现(issue #27797)—— 设 LLAMA_ATTN_ROT_DISABLE=1 是否有效
    • 不同量化(Q4_K_M / Q5_K_M / Q6_K / Q8_0)的速度与质量取舍
    • dflash draft MTP(需要单独下载 ~5 GB 模型)
    • Hermes CLI / MCP 接入测试
    • GPU 温度严格控制下的 32K vs 64K Prefill 对比
      所以这篇更适合当成一份 3950X + RTX 3070/3090 双卡 + Qwen3.8-Flash-Next 的实机配置记录,不是完整 benchmark。当初要买卡的时候,电脑里本来就有3070了,当时的目标卡是4080 32G, 只要9000多块(跟现在的3090一个价钱!),但是想了想24+8 也是32G,于是只买了3090,之前一直跑27B小模型, 只用得到单卡,但是这次是我在本地跑过最大的模型了,勉勉强强能跑下来已经不错,也证明了当初我预测后面会用到24+8的想法,如果只是3090单卡,真的是跑不起来了。

    最后的最后, 用 Flash-Next 生成了一个八卦图网站,请老特 @terry 品鉴。
    flash_full_compressed.jpg

    J 1 条回复 最后回复
    3
    • Tony WangT 离线
      Tony WangT 离线
      Tony Wang
      超级版主
      编写于 最后由 编辑
      #2

      不错, 虽然prefill慢一点儿, decode是不错的. 看来可以试着部署一下. 👍 👍

      J 1 条回复 最后回复
      0
      • Tony WangT Tony Wang

        不错, 虽然prefill慢一点儿, decode是不错的. 看来可以试着部署一下. 👍 👍

        J 离线
        J 离线
        johnnybegood
        劳动模范 技术大牛
        编写于 最后由 编辑
        #3

        @Tony-Wang

        @Tony-Wang 我也是同样的感觉, 我生成八卦图的时候, 平均速度达到了 24t/s , 真实可用了。 唯一慢的确实就是prefill, 基本第一次需要3分钟左右, 但是对话起来就快很多了。

        1 条回复 最后回复
        0
        • ,terryT terry 固定了此主题
        • terryT 离线
          terryT 离线
          terry
          超级版主
          编写于 最后由 编辑
          #4

          挺能折腾,顶一波。

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

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

            挺能折腾,顶一波。

            J 离线
            J 离线
            johnnybegood
            劳动模范 技术大牛
            编写于 最后由 编辑
            #5

            @terry 我觉得对个人来讲, 本地部署最大的意义不是隐私什么乱七八糟的, 个人能有多大隐私? 而是本地可以部署去审查模型, 之前特地对比过审查和去审查的区别, 还是蛮大的。 比如前一阵有人帮论坛做了OWASP渗透测试,实操的话一般模型应该会拒绝,但是去审查的就可以做。这只是最最小的一个例子,其他方方面面的那可多了去了,没法网上说了。 本地能跑 180B的去审查模型,我很欣慰。

            1 条回复 最后回复
            0
            • ,系统 取消固定了此主题
            • ,J johnnybegood 引用了 此主题
            • J johnnybegood

              测试日期:2026-08-29
              llama.cpp 版本:b10676 / commit ba29f94da(master HEAD)

              结论先放

              把 Qwen3.8-Flash-Next(Uncensored-IQ4_XS,97 GB,176B 参数)放在RTX 3090 24G带 RTX 3070 8G 这种非对称双卡上,用 llama.cpp 最新 master build(含 qwen4exp 架构支持),实测四档 context 下来:

              • Prefill:4K 301 t/s → 16K 266 t/s → 32K 244 t/s → 64K 280 t/s
              • Decode:4K 26.1 t/s → 16K 23.2 t/s → 32K 19.6 t/s → 64K 15.2 t/s
              • Wall time:4K 灌入+生成 16 秒,64K 灌入+生成 238 秒
              • KV Cache 精度:4K / 16K 用 q8_0;32K / 64K 用 q4_0(显存装不下 q8_0)
              • 整体判断:在没有 R9700 / 5090 / 4090 的前提下,这台机器能把 176B 量级 MoE + sparse-attn 模型扛住到 64K context;本地日常使用(写代码、聊问答、做长摘要)完全 OK。

              1. 测试环境

              1.1 硬件一览

              微信图片_20260829130418_9_5.jpg

              项目 型号 / 规格
              CPU AMD Ryzen 9 3950X(16C / 32T)
              内存 64 GB (实际可用约 60 GB)
              GPU 0 NVIDIA GeForce RTX 3070(8 GB,sm_86,PCIe 4.0 x16 @ x16)
              GPU 1 NVIDIA GeForce RTX 3090(24 GB,sm_86,PCIe 4.0 x16 @ x16)
              总显存 32 GB(3070 + 3090)
              存储 系统 NVMe 4TB
              系统 Ubuntu 22.04.5 LTS(kernel 6.8.0-138-generic)
              NVIDIA 驱动 580.178.04(CUDA 13.0)
              CUDA toolkit nvcc 12.8.93(驱动兼容构建)

              这里要诚实说一句:这是非常不均衡的双卡 —— 一张 8G、一张 24G;而且不是 NVLink。MoE 大模型在两张卡之间按层切的时候,跨卡通信会变成主要瓶颈。但至少比纯 CPU 跑 176B 模型要快很多倍。也试过单张3090加内存跑,真的跑不动,我说的是可以跑起来, 但是跑时间长了就OOM死掉了。

              1.2 软件

              项目 版本
              llama.cpp b10676 / commit ba29f94da(master HEAD,2026-08-28 后)
              CUDA backend sm_86(RTX 3070 / 3090)
              cuDNN 驱动自带
              Backend ggml-cuda.so 0.22.0

              模型 qwen4exp 架构在 c1d0e7a00 之前的 llama.cpp 上会直接报 unknown model architecture: 'qwen4exp',必须升级到 b10660 之后、最好用 master latest。本次实测就是在自己本地源码重建 ba29f94da 之后做的,libllama.so 含 37 个 qwen4exp 相关符号。

              Screenshot from 2026-08-29 11-03-07.png

              1.3 模型

              项目 规格
              模型 Qwen3.8-Flash-Next
              量化 IQ4_XS(4.25 bpw)
              文件大小 97 GB(3 个 GGUF 分片:44.7 GB + 44.7 GB + 7.9 GB)
              参数量 176.94 B(n_params=176943899520)
              架构 qwen4exp(sparse attention + MoE + MTP)
              词表 n_vocab=248320
              嵌入维度 n_embd=2560

              2. 实测结果

              2.1 主表:4K / 16K / 32K / 64K KV Cache 下的 Prefill 与 Decode

              每个数据点跑 3 次(去除冷启动),取 median。

              Context (target) Prompt tokens (actual) Prefill t/s (median) Prefill t/s (max / min) Prefill ms/t (median) Decode t/s (median) Decode ms/t (median)
              4 096 4 057 301.10 308.07 / 292.41 3.32 26.13 38.28
              16 384 16 195 265.95 275.78 / 259.38 3.76 23.15 43.20
              32 768 32 617 244.26 274.77 / 217.99 4.09 19.56 51.11
              65 536 65 461 280.16 280.20 / 279.82 3.57 15.24 65.60

              一个值得注意的事实:Prefill 完全主导长 prompt 的总延迟。即便 64K 下 Decode 慢到 15.2 t/s,单条请求的 64 token 生成只要 4.1 秒;但 Prefill 那 234 秒是真等的。
              如果你的工作流是「长文档一次性灌入 + 短追问」,那你应该把眼睛盯在 Prefill 速度上;如果你做的是「多轮对话、每轮都要新生成 200+ token」,那么 Decode 速度才是体验瓶颈。
              bench_chart_speed.png

              3. 关键参数

              ① 不要写 -ngl 99 也不要写 --split-mode layer --tensor-split 1,3

              我最初是强制 -ngl 99,直接 cudaMalloc failed out of memory。原因很直白:

              • 模型 97 GB,两张卡总显存 32 GB,根本不可能全 offload。
              • 强制 -ngl 99 让 common_fit_params 跳过自动适配,结果某些 expert 层被推到 GPU 0(3070,8 GB)上,单 expert 47 GB 装不下,cudaMalloc 失败。
              • 手动 --tensor-split 1,3 也不行,因为 expert 层本身太大,不能被拆分。
                正确做法:不传 -ngl,让 llama.cpp 自动 fit 能上 GPU 的层,剩下的走 CPU + RAM。本地实测是 3070 占 6.5 GB、3090 占 23 GB、CPU 部分约 53 GB 落到系统内存。

              ② 双卡 + 不对称显存:要打开 --no-mmap

              默认 mmap 会让 CPU 部分按需从外置硬盘页入。我们的模型在外置 /media/johnnyz/PROG_980/ 上,mmap + 频繁换页会让速度大幅波动。加 --no-mmap(已 deprecated,新写法 --load-mode none)一次性预读到 RAM,Prefill 速度更稳定。

              ③ 32K+ 必须把 KV cache 降到 q4_0

              Context KV 精度 KV 占用 可行性
              4 K q8_0 ~0.2 GB ✅ 完全无压力
              16 K q8_0 ~0.8 GB ✅ OK
              32 K q8_0 ~1.6 GB ⚠️ 3090 23 GB 还能装下,但多轮后碎片占用会顶到 OOM
              32 K / 64 K q4_0 ~0.8 GB / ~1.6 GB ✅ 跑稳

              4. 主题深入

              4.1 为什么 Decode 比 Prefill 掉得慢?

              按理说 Decode 阶段每生成一个 token 都要过整个模型,应该比 Prefill 对 ctx 大小更敏感才对。但实测:

              • Prefill:4K → 64K 掉 7%(如果剔除 32K 热降频的噪声)
              • Decode:4K → 64K 掉 42%
                Decode 才是真的对 ctx 敏感。Decode ms/t 从 38 涨到 66(+73%),符合 KV cache scan 成本线性增长的预期。

              这台机器 Decode 慢的真正原因是 MoE 路由的 expert 集中在 GPU 上、但仍需要从 CPU 内存抓其它专家——Flash-Next 是 Q3.8 大改版,专家路由在长 ctx 下触发更频繁,CPU↔GPU 数据搬运更多。

              4.2 64K 反而比 32K Prefill 快的现象分析

              32K run 1 32K run 3 64K run 1 64K run 3
              GPU temp (估计) 73°C 90°C 70°C 85°C
              Prefill t/s 274.77 217.99 280.20 280.16

              表面看是 64K 比 32K 快。真相:

              • 64K 那 3 次 prefills 跑得比较快(每次 ~3.9 分钟),中间 GPU 没空冷
              • 32K 那 3 次拖了更久(每次 ~2.2 分钟预填 + 短生成 + 等待间隔),GPU 进入 thermal steady state
              • 32K 测量的 noise floor 包含了 thermal throttle

              4.3 跨 PCIe 通信开销(推测)

              两张 RTX 3070/3090 之间是 PCIe 4.0 x16,跨卡带宽 ~25 GB/s(实际单工 16-20 GB/s)。MoE expert layer 在 3090(装得下大头)+ 3070(小头)之间切换时,每次专家切换都要搬运 hidden state(2560 dim × FP16 = 5 KB),总量随 layer 数线性增长。

              5. 还没测的东西

              这篇主要是 4K / 16K / 32K / 64K 四档 Prefill + Decode 的单实例单请求测试。还没认真做:

              • --parallel 2/4 多并发压力测试(32GB 总显存不够同时两份全 ctx 跑)
              • 128K / 262K(原生上下文)下的 Prefill 速度——按 issue #27871 描述,262K 在某些驱动上会 cudaMalloc invalid argument;本机也想验证
              • 多轮对话"//////" 退化复现(issue #27797)—— 设 LLAMA_ATTN_ROT_DISABLE=1 是否有效
              • 不同量化(Q4_K_M / Q5_K_M / Q6_K / Q8_0)的速度与质量取舍
              • dflash draft MTP(需要单独下载 ~5 GB 模型)
              • Hermes CLI / MCP 接入测试
              • GPU 温度严格控制下的 32K vs 64K Prefill 对比
                所以这篇更适合当成一份 3950X + RTX 3070/3090 双卡 + Qwen3.8-Flash-Next 的实机配置记录,不是完整 benchmark。当初要买卡的时候,电脑里本来就有3070了,当时的目标卡是4080 32G, 只要9000多块(跟现在的3090一个价钱!),但是想了想24+8 也是32G,于是只买了3090,之前一直跑27B小模型, 只用得到单卡,但是这次是我在本地跑过最大的模型了,勉勉强强能跑下来已经不错,也证明了当初我预测后面会用到24+8的想法,如果只是3090单卡,真的是跑不起来了。

              最后的最后, 用 Flash-Next 生成了一个八卦图网站,请老特 @terry 品鉴。
              flash_full_compressed.jpg

              J 离线
              J 离线
              johnnybegood
              劳动模范 技术大牛
              编写于 最后由 编辑
              #6

              這兩天把3070 8G 換成了 3080 20G, 果然有比較實質性的提升,結果如下:

              Qwen3.8 Flash Next 跑完!完整结果:

              场景 r comp TTFT (s) total (s) decode t/s tok/chunk
              code 1 512 2.481 19.98 29.2 1.00
              code 2 512 0.274 14.37 36.3 1.00
              en_tech 1 512 1.994 18.72 30.6 1.00
              en_tech 2 512 0.277 14.36 36.3 1.00
              cn_chat 1 512 1.793 18.64 30.3 1.00
              cn_chat 2 512 0.303 14.41 36.2 1.00
              cn_essay 1 474 0.702 16.45 30.0 1.01
              cn_essay 2 474 0.268 13.24 36.5 1.01

              tok/chunk = 1.00:纯 autoregressive(未启用 DFlash2 spec-decode,因为你没传 --spec-type draft-dflash + DFlash2 draft model 路径)。

              1 条回复 最后回复
              0
              • J 离线
                J 离线
                johnnybegood
                劳动模范 技术大牛
                编写于 最后由 编辑
                #7

                Qwen3.5 122B IQ4_XS (65GB)

                场景 r comp TTFT (s) total (s) decode t/s tok/chunk
                code 1 512 2.035 18.15 31.7 1.00
                code 2 512 0.338 15.67 33.3 1.00
                en_tech 1 512 1.788 17.68 32.2 1.00
                en_tech 2 512 0.335 15.76 33.1 1.00
                cn_chat 1 512 1.697 17.06 33.3 1.00
                cn_chat 2 512 0.334 15.34 34.0 1.00
                cn_essay 1 460 0.478 14.57 32.6 1.01
                cn_essay 2 460 0.339 13.91 33.8 1.00

                GPU 占用:3090 = 22.7 GB, 3080 = 18.6 GB(41.3 GB 共)— 63% 模型放 GPU

                David ChenD 1 条回复 最后回复
                0
                • williamlouisW 在线
                  williamlouisW 在线
                  williamlouis
                  超级版主
                  编写于 最后由 编辑
                  #8

                  换3080是对的。3070这个小弟属实有拖后腿的意思了。

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

                  1 条回复 最后回复
                  0
                  • J johnnybegood

                    Qwen3.5 122B IQ4_XS (65GB)

                    场景 r comp TTFT (s) total (s) decode t/s tok/chunk
                    code 1 512 2.035 18.15 31.7 1.00
                    code 2 512 0.338 15.67 33.3 1.00
                    en_tech 1 512 1.788 17.68 32.2 1.00
                    en_tech 2 512 0.335 15.76 33.1 1.00
                    cn_chat 1 512 1.697 17.06 33.3 1.00
                    cn_chat 2 512 0.334 15.34 34.0 1.00
                    cn_essay 1 460 0.478 14.57 32.6 1.01
                    cn_essay 2 460 0.339 13.91 33.8 1.00

                    GPU 占用:3090 = 22.7 GB, 3080 = 18.6 GB(41.3 GB 共)— 63% 模型放 GPU

                    David ChenD 离线
                    David ChenD 离线
                    David Chen
                    编写于 最后由 编辑
                    #9

                    @johnnybegood 可以分享你的啟動參數嗎?我想自己借你的啟動參數,用自己的設備實做一次...謝謝

                    J 1 条回复 最后回复
                    0
                    • David ChenD David Chen

                      @johnnybegood 可以分享你的啟動參數嗎?我想自己借你的啟動參數,用自己的設備實做一次...謝謝

                      J 离线
                      J 离线
                      johnnybegood
                      劳动模范 技术大牛
                      编写于 最后由 编辑
                      #10

                      @David-Chen 我让AI帮忙配置的, 忘了看参数了, 不过你可以看我文章 3.关键参数 , 那里面的注意就行了, 其他都是默认。

                      1 条回复 最后回复
                      0

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

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

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

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


                      • 登录

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