zzutmebwd
V2EX  ›  Local LLM

关于低算力 gpu 推理时 prefill 在总时长中的占比问题

  •  
  •   zzutmebwd · 4h 25m ago · 404 views

    看到很多人对 llm 推理速度的描述都是 decode 主导/带宽控制/prefill 忽略不计,我想要提醒的是,这只对高算力 gpu/代码等密集推理来说是客观的,如 pro6000/5090 这类,本地 agent 场景并不是这样。

    首先明确几个问题: 1 、未命中缓存的输入量:输出量是多少?长输出的密集推理往往输出大于输入(未命中缓存部分),甚至能达到 2:1 。工具密集的 agent 场景,根据我的 hermes agent 的数据,最近三天的数据是新输入量 / 输出量 = 4,882,795 / 377,561 ≈ 12.9 : 1,主要任务是信息检索/汇总/文件处理/智能家居。 2 、本地 agent 更多的工作在哪个场景?我认为主流场景是 12.9:1 这种,指望本地 ai 跑密集推理+编码任务不太现实啊。 3 、不同硬件的 prefill 速度和 decode 速度?以近期最火的 qwen3.6 27b 为例( 8bit 开 mtp 参考值),5090 prefill 3000tps ,decode 70tps ,m3 ultra prefill 300tps ,decode 30tps 。 4 、此时,5090 prefill 1628s ,decode 5394s ,确实是 decode/带宽主导; m3 ultra prefill 16276s ,decode 12585s, prefill 占比 56%。 5 、对于本地部署常见的 4bit ,prefill 时间占比更高。

    综上所述,对于低算力/大显存设备,prefill 所用时长是相当显著的,在工具调用密集型 agent 中甚至占有主导地位。

    6 replies    2026-06-09 16:32:41 +08:00
    superkkk
        1
    superkkk  
       3h 59m ago via Android
    叽哩咕噜说啥呢?这不是和你输入输出长度多少有关吗
    Puteulanus
        2
    Puteulanus  
       3h 16m ago
    /t/1212780
    只能尽量提高缓存命中率来补救,Hermes 的命中率还尤其低,体验就很惨了
    zzutmebwd
        3
    zzutmebwd  
    OP
       2h 29m ago via Android
    @Puteulanus 我的命中率是正常的 一直在九十以上
    coefu
        4
    coefu  
       1h 54m ago
    还得和 context 长度挂钩,越长越线性下降。
    shoushen
        5
    shoushen  
       1h 37m ago
    感谢分享
    zzutmebwd
        6
    zzutmebwd  
    OP
       11 mins ago via Android
    @coefu 是的 decode 基本不变,prefill 线性降低,所以上下文越长首词越慢,上文数据是 100k 左右上下文时的,满 256k 时就更夸张了。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5489 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 57ms · UTC 08:44 · PVG 16:44 · LAX 01:44 · JFK 04:44
    ♥ Do have faith in what you're doing.