tootfsg
V2EX  ›  Local LLM

关于 5070ti 模型推理的速度和本地部署思考

  •  
  •   tootfsg · 22h 27m ago via Android · 807 views
    前置条件:5070ti 16g ,llama.cpp ,全跑在显存。

    1. 跑 gemma4 26b a4b iq4_xs 量化( MoE 结构)

    速度大概是 120t/s-150t/s ,首 token 和后续输出都很快

    2. 跑 devstral small2 24b q4_k_m 量化 (稠密结构)

    速度大概是 8t/s-10t/s ,首 token 可能很慢,整体输出都慢得多。



    思考:

    现在的模型有两种结构:稠密( Dense )和 MoE (混合专家模型)。

    以上述两种模型举例

    稠密模型是所有层( dev 这个有 40 层)都参与计算,消耗 24b 的完整算力,也就是单 token 2x24b=48gflops (不算量化),算力消耗大,推理成本高。

    moe 是总共 26b 参数,每次推理只激活 4b

    参数,只消耗激活参数 4b 的算力,单 token 算力消耗 2x4=8gflops ,算力消耗小很多,但有 26b 的参数(知识)。gemma 这个有 128 个专家,每次激活 8 个专家和 1 个共享专家(所有 token 必须首先经过共享专家),moe 模型是通过动态路由判断选择专家的。



    可以看出算力需求差异巨大。



    常见的几个顶级开源模型

    glm5.1 参数 754b 激活 40b

    deepseek-v4 pro 参数 1.6t 激活 49b

    v4 flash 参数 284b 激活 13b

    minimax2.5 参数 229b 激活 10b



    moe 模型虽然每次激活的参数少,但必须把完整参数都全量加载到显存中。也就是说算力消耗大大减少,但显存需求没变。



    可以大概推测,顶级大模型以后可能只有 moe 结构了,参数小的可能有稠密架构,因为算力成本还尚可接受,参数量很大的稠密结构,恐怕算力成本高到厂商也难以商用吧。



    本地部署,我看来推理速度有 40-50token/s ,基本可以自用了,这是一个及格线。



    我看来有两种比较好的本地部署方案



    1. 买 nv 工作站显卡,pro6000 96g 咸鱼 6w 多,pro6000d 84g (显存没 ecc ,整体比 6000 略差)咸鱼 4w ,pro5000 84g 这种。

    2. 用同等价钱稍微低点,等 m5 pro 的 mac mini/studio 发布后购买。



    改显存,矿卡,二手的很久的专业卡等就不讨论了,不懂这部分。



    mac 跑推理,olmx 官网我看了模型推理速度排行榜,还是差了点,不知道 4w 价钱的 m5 pro 的 mac mini/studio 会不会明显提高。



    还有就是比如双 5070ti 跑模型推理,不知道速度怎么样,价钱相对不贵。我用的是 ddr4 pcie 4.0 的主板,双显卡要 pcie 拆分 8x8 ,pcie5.0 肯定更好,我得换主板换内存,成本太高,没法测试,如果内存没这么贵,就换主板买内存搞个 5060ti 16g 来测试了,这个可能也是一种方案吧。
    7 replies    2026-05-20 14:01:22 +08:00
    tootfsg
        1
    tootfsg  
    OP
       17h 59m ago via Android
    可以看出,统一内存只适合 MoE
    coefu
        2
    coefu  
       11h 43m ago   ❤️ 1
    1 ,开源 70B 以下参数的 moe 逻辑能力比 dense 差太多了。

    层宽和层深之间有个甜点位,不同参数量的甜点位又不同。总体来看,那几个大的 moe ,active 的 expert 层数应该都要搞到 40 ~ 60 ,在宽度上做取舍。

    gemma4 E4B 有 42 层,比 qwen3.5 9B 的 32 层 更深,按理来说,逻辑能力应该更好,但是受限于总参数量导致的宽度窄,表征能力不行,所以更容易在逻辑推理的起始位就跑偏,导致整个推理完全无法收敛。这点,通过中等数学的奥赛题可以验证。就算是 gemma4 E4B 横向增加 experts + router ,把总参数也堆起来,依然也无法解决问题。

    2 ,dense 只需要在原始架构上达到了甜点位,横向+experts + router ,依然很能打。如果这种架构做层 plug-in 模式,更有搞头。总体来看,在 linear attention 这条路线上来看 qwen3.6 27B 已经是甜点位了。在纯 transformer 路线上来看 gemma4 31B 似乎也到了甜点位。如果可以搞一个 plug-in 架构,类似 TTT 模式,那真的就是开源福音。
    uprit
        3
    uprit  
       4h 51m ago
    你那个 devstral small2 24b q4_k_m ,肯定爆显存了,部分内容跑在内存里了,所以才这么慢。
    tootfsg
        4
    tootfsg  
    OP
       53 mins ago via Android
    @uprit 没爆显存,我所有模型都开-ngl 99 的,我 cpu 很低,10t/s 都跑不了的,而且爆了直接启动不了的,光上下文调了很多次的。
    不过确实慢了,我记着以前好像是 20 多 t/s 的。我怀疑可能是 cuda 的版本问题,我电脑有 13.1 和 13.2 ,但是 13.2 有人提起过可能有问题。

    启动参数 ngl 99 ,fa on ,jinja ,ctk q8 ,ctv q4 ,np 1 ,c 25600 ,启动后占用显存 15193 ,模型 13302 ,上下文 1625 。

    我 cpu 是 12400f 和 ddr4 ,这个跑不了 10t/s 吧
    唯一的可能就是可能指定了 cuda13.2 编译 llama.cpp 。
    tootfsg
        5
    tootfsg  
    OP
       52 mins ago via Android
    @uprit 稠密模型特别耗算力,光纸面比较就比 26b a4b 高了 6 倍算力需求。
    tootfsg
        6
    tootfsg  
    OP
       50 mins ago via Android
    说起稠密模型,前些天 mistral 发布了一个 110b 的稠密模型,大的吓人,我想试试,可是中转都买不到。
    tootfsg
        7
    tootfsg  
    OP
       16 mins ago via Android
    @uprit 我刚才用 cuda13.1 重新编译了最新 llama.cpp ,发现问题了,不是 cuda 版本问题,是上下文问题。
    我在之前的 chat 上继续问一开始也是 10t/s ,然后我开新 chat ,速度刚开始有 45t/s ,随着输出速度越来越低,完成任务最后 32.08t/s ,总共 1424tokens ,44s 。
    然后我问了第二个问题,刚开始有 22t/s ,速度也是随着输出越来越慢,完成后 17.72t/s ,1813tokens ,1min 42s 。
    两个问题都是编程相关问题,实现某个小功能。
    到此,原因总算是真相大白,水落石出了。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5746 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 06:18 · PVG 14:18 · LAX 23:18 · JFK 02:18
    ♥ Do have faith in what you're doing.