mjp004 LV
发表于 2025-4-9 11:59:00
应该是太不靠谱了，所以关注的人很少。
一方面，没给出啥关键信息，连算力、访存带宽这些都没有，只有比H100快20倍这个噱头。
另一方面，吹的也太离谱了。在一系列定性的、对自己有利的假设（条件）下，用加减乘除法去估算得到想要的结论——LLM任务是Compute bound的。这种做法得到的结论太脆弱了：条件（输入、输出长度，调度方式）稍有变化，结论就不成立了。
评估中假设推理系统采用了Continuous batching（如下图），一个batch中包含一个user的完整Prefill过程，以及其余user的产生一个token的Decoding过程；从而对权重的访存被所有user均摊。
下图来自sohu官网，评估中取了input_length = 2048，output_length = 128（官网说通常输入更长）。计算量和模型访存量都是没问题的；KV Cache访存量有误：64对应层数，应该为80层（来自已有回答）。KV Cache访存量 = 127 × 80 × 8 × 128 × (2048 + 127) × 2 × 2 = 84GB；127对应进行Decoding的user数，8对应Query头数（64）除以共享同一个KV的Query数（8），128对应每个头输出的隐层维度， (2048 + 127) 为序列长度，前一个2对应K和V，后一个2对应2个Byte。
Sohu号称比H100快20倍，且不是Memory bound，那么算力至少是H100的20倍。官网说了取H100的FP16的非稀疏算力，就按1000TFLOPS算；那么Sohu芯片的算力至少是20,000TFLOPS，这算力能达到吗？此时，计算量 ÷ 访存量 = 304T ÷ （140G + 84G）= 1390。与算力匹配的带宽 = 2 * 20000 / 1390 = 29TB/s（乘2是考虑FP16对应2Byte）。仅靠SRAM的话，8个芯片的容量是不够的（看起来也不像）；用HBM的话，带宽又做不到这么大。这用的都是什么神仙技术？
考虑input_length = output_length = 128的情况。计算量 = (128+ 127) * 70 * 2 = 35TFLOPs；KV Cache访存量 = 127 * 80 * 8 * 128 * (128+ 127) * 2 * 2 = 10G。此时计算量 ÷ 访存量 = 35T ÷（140G + 10G）= 239。这时候与算力匹配的带宽变成了input_length = 2048，output_length = 128时的大概6倍。计算量 ÷ 访存量 = 计算量 ÷ （权重访存量 + KV Cache访存量）。只改input_length时，计算量与KV Cache访存量同时减小，二者比值是个定值。而参数访存量不变，所以计算量与整体访存量之比会减少；对带宽的需求会增加。
考虑input_length = output_length = 2048的情况。计算量 = (2048 + 2047) * 70 * 2 = 560TFLOPs；KV Cache访存量 = 2047 * 80 * 8 * 128 * (2048 + 2047) * 2 * 2 = 2558G。此时计算量 ÷ 访存量 = 560T ÷（140G + 2558G）= 212。计算量 ÷ 访存量 = 计算量 ÷ （权重访存量 + KV Cache访存量）。计算量与（input_length + output_length）成正比，KV Cache访存量与output_length × （input_length + output_length）成正比；只增大output_length时，KV Cache访存量比计算量增长得更快。计算量与整体访存量之比还是会减少；对带宽的需求还是会增加。
考虑input_length = 128，output_length = 2048的情况。计算量 = (128 + 2047) * 70 * 2 = 297TFLOPs；KV Cache访存量 = 2047 * 80 * 8 * 128 * (128 + 2047) * 2 * 2 = 1359G。此时计算量 ÷ 访存量 = 297T ÷（140G + 1359G）= 203。这时候与算力匹配的带宽变成了input_length = 2048，output_length = 128时的大概7倍。
从上面的分析中可以看出，输出长度和输出长度，对计算量和访存量之比有很大的影响。不论是否合理，从结果来看，Sohu选了一个对自己最有利的——输入长且输出短的。其他三种情况对带宽的需求都是这个的约6-7倍。H100的算力取1000TOPS，带宽取3TB/s，与算力和带宽匹配的计算量与访存量之比为1000 ÷（3×2）= 167。从上面四个计算量与访存量之比看，Sohu选了一个对H100最不利的。从其他三种情况看，H100的算力、带宽还算匹配的。
在上面的评估中，直接假定了一个batch中的user数和output_length数相等：在output_length = 2048时，也需要有连续不断的2048个user请求的填充。如果没这么多请求呢，那么只有一些batch包括一个user的Prefill和其余user的部分Decoding，大部分batch只包括各user的Decoding，权重访存就不能再按照原来的方式均摊了。权重访存的次数大概为output_length数 ÷ user数，而不再为1。以user数为128为例，权重的访存次数 = 2048 ÷ 128 = 16。对于input_length = output_length = 2048的情况，计算量 ÷ 访存量 = 560T ÷（140G × 16 + 2558G）= 120。对于input_length = 128，output_length = 2048的情况，计算量 ÷ 访存量 = 297T ÷（140G × 16 + 1359G）= 85。总之，没有足够的user填充，就不能按理想的Continuous batching调度估计，还会进一步地降低计算量与访存量之比。
最后，也没想明白这个20倍是怎么来的，连H100的23,000token/s（看下图里大概也是这个值））怎么来的都没整明白。根据TensorRT-LLM，H100在FP16精度、8卡Tensor并行下，对于LLama2 70B 2048/128，也只能达到1230 token/s。按照算力估计出来的上限也不过—— 1000 / 304 * 128 * 8 = 3368 token/s（算力 ÷ 计算量 × 输出token数 × 8个芯片）。
|
|
