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

[zzutmebwd]

看到很多人对 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 中甚至占有主导地位。

[superkkk]

叽哩咕噜说啥呢？这不是和你输入输出长度多少有关吗

[Puteulanus]

/t/1212780
只能尽量提高缓存命中率来补救，Hermes 的命中率还尤其低，体验就很惨了

[zzutmebwd]

@Puteulanus 我的命中率是正常的 一直在九十以上

[coefu]

还得和 context 长度挂钩，越长越线性下降。

[shoushen]

感谢分享

[zzutmebwd]

@coefu 是的 decode 基本不变，prefill 线性降低，所以上下文越长首词越慢，上文数据是 100k 左右上下文时的，满 256k 时就更夸张了。

[oldlamp]

@zzutmebwd

对，这个关系目前不知道是不是能够找到一个均衡点

[coefu]

@zzutmebwd 根本性的解决方案是 pp 过程，怎么保持 O(n)的算法。要是能找到个方案，那真的是非常嗨皮了。