当前位置：首页 > news >正文

公司签约网站看空间

news 2025/10/24 10:38:45

公司签约网站,看空间,wordpress开发小工具,做图书网站的代码译者序本文翻译自 2024 年的一篇文章#xff1a; LLM inference speed of light#xff0c; 分析了大模型推理的速度瓶颈及量化评估方式#xff0c;并给出了一些实测数据#xff08;我们在国产模型上的实测结果也大体吻合#xff09;#xff0c; 对理解大模型推理内部工… 译者序本文翻译自 2024 年的一篇文章 LLM inference speed of light 分析了大模型推理的速度瓶颈及量化评估方式并给出了一些实测数据我们在国产模型上的实测结果也大体吻合对理解大模型推理内部工作机制和推理优化较有帮助。 A100-80GB PICe 推理延迟与吞吐。Image Source 译者水平有限不免存在遗漏或错误之处。如有疑问敬请查阅原文。以下是译文。摘要在开发 calm 的过程中我们考虑的一个核心问题是推理的极限在哪儿因为我们需要以此为准绳去衡量真实推理系统的速度。 calm 是一个基于 CUDA、完全从头开始编写的轻量级 transformer-based language models 推理实现。本文试图讨论这个极限及其影响。如果对推导细节感兴趣可参考这个 python notebook。 1 推理机制 1.1 transformer逐 token 生成无法并行当语言模型生成文本时它是逐个 token 进行的。可以把语言模型特别是 decoder-only text transformer本文统称为 LLM 看做是一个函数输入一个 token输出一组概率每个概率对应词汇表中一个 token。推理程序使用概率来指导抽样产生从词汇表中选择下一个 token 作为最终输出。词汇表vocabulary通常由单词、单词片段、中文汉字等组成这些都称为 token。 vocabulary 长什么样可以可以看一下 bert-base-chinese 的词典 vocab.txt。更多基础 GPT 是如何工作的200 行 Python 代码实现一个极简 GPT2023。Transformer 是如何工作的600 行 Python 代码实现 self-attention 和两类 Transformer2019 译注。文本生成过程就是不断重复以上过程。可以看出在生成一个文本序列时没有并行性的可能性。 speculative execution 尝试通过一个 less accurate predictor 来实现某种程度的并行本文不讨论。 1.2 生成过程建模矩阵乘法广义上当处理一个 token 时模型执行两种类型的操作矩阵-向量乘法一个大矩阵例如 8192x8192乘以一个向量得到另一个向量 attention 计算。在生成过程中模型不仅可以看到当前 token 的状态还可以看到序列中所有之前 token 的内部状态 —— 这些状态被存储在一个称为 KV-cache 的结构中它本质上是文本中每个之前位置的 key 向量和 value 向量的集合。 attention 为当前 token 生成一个 query 向量计算它与所有之前位置的 key 向量之间的点积然后归一化得到的一组标量并通过对所有之前的 value 向量进行加权求和来计算一个 value 向量使用点积得到最终得分。 This description omits multi-head attention and the details of “normalization” (softmax), but neither are critical for understanding the inference performance. 1.3 瓶颈分析以上两步计算有一个重要的共同特征从矩阵或 KV-cache 读取的每个元素只需要进行非常少量的浮点运算。矩阵-向量乘法对每个矩阵元素执行一次乘加运算2 FLOPsattention 对每个 key 执行一次乘加对每个 value 执行一次乘加。 1.3.1 典型“算力-带宽”比现代 CPU/GPU 的 ALU 操作乘法、加法内存 IO 速度要快得多。例如 AMD Ryzen 7950X67 GB/s 内存带宽和 2735 GFLOPSFlop:byte 40:1NVIDIA GeForce RTX 40901008 GB/s 显存带宽和 83 TFLOPSFlop:byte 82:1NVIDIA H100 SXM3350 GB/s 内存带宽和 67 TFLOPS 对于矩阵乘法tensor core 提供 ~494 TFLOPS 稠密算力Flop:byte 147:1。对于 FP16/FP8 等精度较低的浮点数比率更夸张 H100 TensorCore 对于 dense FP8 矩阵的理论吞吐量为 1979 TFLOPSFLOP:byte 590:1。在这些场景中无论是否使用 TensorCore 或使用什么浮点格式ALU 都非常充足。 1.3.2 瓶颈访存带宽因此transformer 这种只需要对每个元素执行两次操作的场景必定受到访存带宽的限制。所以基于下面几个因素模型配置参数多少KV-cache 大小访存带宽我们就能估计推理过程的最短耗时。下面以 Mistral 7B 为例来具体看看。 2 以 Mistral-7B 为例极限推理延迟的计算 2.1 参数权重数量的组成/计算 Mistral-7B 有 72 亿参数所有矩阵元素的总数是 72 亿个。参数的组成如下 4096 * 32000 131M 用于 embedding 矩阵 4096: hidden size (tokens per hidden-vector)32000: vocabulary size矩阵-向量乘法中不会使用这整个大矩阵每个 token 只读取这个矩阵中的一行因此数据量相对很小后面的带宽计算中将忽略这个 32 * (4096 * (128 * 32 128 * 8 * 2) 4096 * 128 * 32) 1342M 用于计算与 attention 相关的向量32 * (4096 * 14336 * 3) 5637M 用于通过 feed-forward 转换 hidden states4096 * 32000 131M 用于将 hidden states 转换为 token 概率这与 embedding 矩阵不同会用于矩阵乘法。以上加起来大约有 7111M (~7B) “活跃”参数用于矩阵乘法。 2.2 计算一个 token 所需加载的数据量 2.2.1 总数据量如果模型使用 FP16 作为矩阵元素的类型那每生成一个 token需要加载到 ALU 上的数据量 7111M params * 2Byte/param ~14.2 GB 虽然计算下一个 token 时每个矩阵都可以复用但硬件缓存的大小通常只有几十 MB 矩阵无法放入缓存中因此我们可以断定这个生成推理过程的速度不会快于显存带宽。 attention 计算需要读取当前 token 及前面上下文中所有 tokens 对应的 KV-cache 所以读取的数据量取决于生成新 token 时模型看到多少前面的 token 这包括系统提示词通常对用户隐藏用户提示词前面的模型输出可能还包括长聊天会话中多个用户的提示词。 2.2.2 KV-cache 部分的数据量对于 MistralKV-cache 为每层的每个 key 存储 8 个 128 元素向量为每个层的每个 value 存储 8 个 128 元素向量这加起来每个 token 对应 32 * 128 * 8 * 2 65K 个元素如果 KV-cache 使用 FP16那么对于 token number P我们需要读取 P * 130 KB 的数据。例如 token number 1000 将需要从 KV-cache 读取 130MB 的数据。跟 14.2GB 这个总数据量相比这 130MB 可以忽略不计了。 2.3 以 RTX 4090 为例极限延迟计算根据以上数字现在可以很容易地计算出推理所需的最小时间。例如在 NVIDIA RTX 40901008 GB/s上 14.2GB (fp16) 需要 ~14.1ms 读取因此可以预期对于位置靠前的 token 每个 token 大约需要 14.1msKV-cache 影响可以忽略不计。如果使用 8bit 权重需要读取 7.1GB这需要大约 7.0ms。这些都是理论下限代表了生成每个 token 的最小可能时间。 2.4 ChatGLM3-6B/Qwen-7B 实测推理延迟译注简单的单卡推理测试16bit 权重平均延迟仅供参考 LLMRTX 4090 24GB (2022)A100 80GB (2020)V100 32GB (2017)ChatGLM3-6B16ms/token18ms/token32ms/tokenQwen-7B19ms/token29ms/token41ms/token 可以看到单就推理速度来说只要模型能塞进去 24GB4090 与 A100 相当甚至更快比 V100 快一倍。说明以上测的是 4090不带 D4090D。 3 数学模型和理论极限的用途以上根据数学建模和计算得出了一些理论极限数字接下来看看这些理论极限有什么用。 3.1 评估推理系统好坏要接近理论极限需要一个高质量的软件实现以及能够达到峰值带宽的硬件。因此如果你的软件硬件离理论最优很远那肯定就有问题可能在软件方面也可能在硬件方面。例如在 RTX 4090 上 calm 使用 16 位权重时达到 ~15.4 ms/tok使用 8 位权重时达到 ~7.8 ms/tok 达到了理论极限的 90%。 Close, but not quite there - 100% bandwidth utilization is unfortunately very hard to get close to on NVidia GPUs for this workload. Larger GPUs like H100 are even more difficult to fully saturate; on Mixtral - this is a different architecture but it obeys the same tradeoffs for single sequence generation if you only count active parameters - calm achieves ~80% of theoretically possible performance, although large denser models like Llama 70B can get closer to the peak. 在 Apple M2 Air 上使用 CPU 推理时calm 和 llama.cpp 只达到理论 100 GB/s 带宽的 ~65% 然后带宽就上不去了这暗示需要尝试 Apple iGPU 了。 3.2 指导量化带宽与每个权重使用的 bit 数成正比这意味着更小的权重格式量化能实现更低的延迟。例如在 RTX 4090 上 llama.cpp 使用 Mistral 7B 16 bit 权重~17.1 ms/tok82% 的峰值8.5 bit 权重~10.3ms/tok 71% 的峰值4.5 bit 权重~6.7ms/tok 58% 的峰值因此对于低延迟场景可以考虑低精度量化。 3.3 指导优化方向除了为推理延迟提供下限外上述建模还表明推理过程并未充分利用算力ALU。要解决这个问题需要重新平衡 FLOP:byte 比例 speculative decoding 等技术试图部分解决这个问题。 3.3.1 批处理 batch 1 - N瓶颈访存带宽 - 算力这里再另一种场景多用户场景。注意到当多个用户请求同时处理时我们用相同的矩阵同时执行多个矩阵-向量乘法这里可以将多个矩阵-向量乘法变成一个矩阵-矩阵乘法。对于足够大的矩阵来说只要矩阵-矩阵乘法实现得当速度就比访存 IO 快因此这种场景下瓶颈不再是访存 IO而是算力ALU。这就是为什么这种 ALU:byte 不平衡对于生产推理系统不是关键问题 —— 当使用 ChatGPT 时你的请求与同一 GPU 上许多其他用户的请求并发评估GPU 显存带宽利用更加高效。 3.3.2 批处理无法改善所需加载的 KV-cache 数据量批处理通常不会减轻 KV-cache 带宽除非多个请求共享非常大的前缀因为 KV-cache 大小和带宽随请求数量的增加而增加而不像权重矩阵保持不变。像 Mistral 这样的混合专家模型MoEscaling 特性稍有不同batching initially only increases the bandwidth required, but once the expert utilization becomes significant the inference becomes increasingly ALU bound. 3.4 硬件相对推理速度评估带宽是评估推理性能的关键指标对于模型变化/设备类型或架构来说是一个恒定的因此即使无法使用 batch processing也可以用它来评估你用的硬件。例如NVIDIA RTX 4080 有 716 GB/s 带宽所以可以预期它的推理速度是 RTX 4090 的 ~70% —— 注意游戏、光线追踪或推理其他类型的神经网络等方面相对性能可能与此不同 4 GQA (group query attention) 的影响 Mistral-7B 是一个非常平衡的模型在上面的所有计算中几乎都能忽略 KV-cache 部分的 IO 开销。这背后的原因较短的上下文Mistral-7B 使用 windowed attention限制 4096 token 的窗口使用了 GQA这个是更重要的原因。 LLaMA 2开放基础和微调聊天模型Meta/Facebook2023 也使用了 GQA。 4.1 GQA 为什么能减少带宽在 GQA 中with a 4x ratio为了得到 attention 的 4 个点积不是使用 4 个 query 向量并分别与 4 个相应的 key 向量计算点积而是只取一个 key 向量然后执行 4 个点积。这能够减少 KV-cache 的大小和所需带宽也在某种程度上重新平衡了 ALU:bandwidth 比例。 4.2 有无 GQA 的数据量对比这对于 KV-cache 内存大小也很关键不过这可能对短上下文模型不太明显 4096 token 上下文的 Mistral 需要 0.5GiB没有 GQA 的可比模型如 Llama 7B“只需要”2 GiB。让我们看看一个最近不使用 GQA 的模型Cohere 的 Command-R。 Command-R has a large vocab (256K) and large hidden state (8192) so it spends a whopping 2B parameters on embeddings, but it reuses the same matrix for embedding and classification so we don’t need to exclude this from the inference bandwidth calculation. 模型本身有大约 35b 参数所以以 16 位/权重计算我们在推理期间需要为每个 token 读取 70 GB 的权重。对于每个 token 它需要在 KV-cache 中存储 40 * 128 * 64 * 2 655K 元素以 16 位/元素计算是每个 token 1.3 MB。因此一个 4096 token 的上下文将需要大约 5.3GB 与 ~70 GB 的权重相比这已经相当显著了。然而如果考虑到 Cohere 的模型宣传有 200K token 上下文窗口 —— 计算最后一个 token 需要读取 260 GB还需要 260GB 的显存来存储它 4.3 多用户场景下 KV-cache 占用的显存规模这么大的模型典型的生产环境配置单用户 weights 通常使用 4bit 量化通常的实现占用 ~4.5bit/权重KV-cache 可能会使用 8bitFP8值。如果我们“保守地”假设上下文为 100K则模型权重占 ~19.7GBKV-cache 占 ~65GB 计算到最后一个 token 时我们需要从内存中读取这么大的数据。可以看到突然之间attention 计算部分的数据量最终转变成耗时从微不足道变成了占 ~75% 虽然 100K 上下文可能看起来有点极端但在短上下文多用户场景中情况也是类似的批处理优化将多次矩阵-向量乘法变成了一次矩阵-矩阵乘法为一批用户请求读取一次模型权重瓶颈来到算力ALU但每个用户请求通常都有自己的 KV-cache 因此最终的 attention 仍然受访存带宽限制并且需要大量内存/显存才能将所有用户请求放到单个节点 4.4 GQA减小从 KV-cache 加载的数据量如果模型使用 4x GQAKV-cache 的大小和所需带宽将会变成原来的 1/4。对于 100k token 的上下文场景虽然 KV-cache 的开销仍然很大65GB - 16GB但已经进入实用范围。 4.5 GQA 的问题对于 Cohere 的目标使用场景引入 GQA 可能会导致模型质量有下降具体得看他们的技术报告。但是纯粹从成本/性能角度来看每个基于 transformer 的 LLM 都需要评估是否能引入 GQA因为收益太大了。 5 总结对于大模型推理场景计算和访存的次数是已知的因此可以进行数学建模计算理论极限。这非常有用不仅可以用来验证推理系统的性能而且能预测架构变化带来的影响。
文章转载自：
http://www.morning.qlry.cn.gov.cn.qlry.cn
http://www.morning.llmhq.cn.gov.cn.llmhq.cn
http://www.morning.tzlfc.cn.gov.cn.tzlfc.cn
http://www.morning.nbhft.cn.gov.cn.nbhft.cn
http://www.morning.mtqqx.cn.gov.cn.mtqqx.cn
http://www.morning.sdhmn.cn.gov.cn.sdhmn.cn
http://www.morning.muzishu.com.gov.cn.muzishu.com
http://www.morning.nbiotank.com.gov.cn.nbiotank.com
http://www.morning.rpzqk.cn.gov.cn.rpzqk.cn
http://www.morning.nlryq.cn.gov.cn.nlryq.cn
http://www.morning.wrfk.cn.gov.cn.wrfk.cn
http://www.morning.sgmgz.cn.gov.cn.sgmgz.cn
http://www.morning.bctr.cn.gov.cn.bctr.cn
http://www.morning.gsrh.cn.gov.cn.gsrh.cn
http://www.morning.mjbkp.cn.gov.cn.mjbkp.cn
http://www.morning.zpjhh.cn.gov.cn.zpjhh.cn
http://www.morning.ylqb8.cn.gov.cn.ylqb8.cn
http://www.morning.sqfnx.cn.gov.cn.sqfnx.cn
http://www.morning.qznkn.cn.gov.cn.qznkn.cn
http://www.morning.qmncj.cn.gov.cn.qmncj.cn
http://www.morning.brjq.cn.gov.cn.brjq.cn
http://www.morning.kkwgg.cn.gov.cn.kkwgg.cn
http://www.morning.hqllx.cn.gov.cn.hqllx.cn
http://www.morning.trhlb.cn.gov.cn.trhlb.cn
http://www.morning.gwmny.cn.gov.cn.gwmny.cn
http://www.morning.xkyqq.cn.gov.cn.xkyqq.cn
http://www.morning.bqhlp.cn.gov.cn.bqhlp.cn
http://www.morning.sqxr.cn.gov.cn.sqxr.cn
http://www.morning.drcnf.cn.gov.cn.drcnf.cn
http://www.morning.fndfn.cn.gov.cn.fndfn.cn
http://www.morning.lbywt.cn.gov.cn.lbywt.cn
http://www.morning.hpspr.com.gov.cn.hpspr.com
http://www.morning.zpdjh.cn.gov.cn.zpdjh.cn
http://www.morning.ynwdk.cn.gov.cn.ynwdk.cn
http://www.morning.hmbxd.cn.gov.cn.hmbxd.cn
http://www.morning.ljjph.cn.gov.cn.ljjph.cn
http://www.morning.lbggk.cn.gov.cn.lbggk.cn
http://www.morning.kxqfz.cn.gov.cn.kxqfz.cn
http://www.morning.nhpmn.cn.gov.cn.nhpmn.cn
http://www.morning.dpmkn.cn.gov.cn.dpmkn.cn
http://www.morning.rxsgk.cn.gov.cn.rxsgk.cn
http://www.morning.litao7.cn.gov.cn.litao7.cn
http://www.morning.lhrwy.cn.gov.cn.lhrwy.cn
http://www.morning.qtsks.cn.gov.cn.qtsks.cn
http://www.morning.bntgy.cn.gov.cn.bntgy.cn
http://www.morning.rrpsw.cn.gov.cn.rrpsw.cn
http://www.morning.fgkrh.cn.gov.cn.fgkrh.cn
http://www.morning.wnpps.cn.gov.cn.wnpps.cn
http://www.morning.tpnxr.cn.gov.cn.tpnxr.cn
http://www.morning.ppllj.cn.gov.cn.ppllj.cn
http://www.morning.yqgbw.cn.gov.cn.yqgbw.cn
http://www.morning.rknhd.cn.gov.cn.rknhd.cn
http://www.morning.rpljf.cn.gov.cn.rpljf.cn
http://www.morning.tdldh.cn.gov.cn.tdldh.cn
http://www.morning.jqswf.cn.gov.cn.jqswf.cn
http://www.morning.qnyf.cn.gov.cn.qnyf.cn
http://www.morning.ygrdb.cn.gov.cn.ygrdb.cn
http://www.morning.lbywt.cn.gov.cn.lbywt.cn
http://www.morning.rfxw.cn.gov.cn.rfxw.cn
http://www.morning.gcqs.cn.gov.cn.gcqs.cn
http://www.morning.kngqd.cn.gov.cn.kngqd.cn
http://www.morning.prsxj.cn.gov.cn.prsxj.cn
http://www.morning.bwkzn.cn.gov.cn.bwkzn.cn
http://www.morning.qbwyd.cn.gov.cn.qbwyd.cn
http://www.morning.mxlwl.cn.gov.cn.mxlwl.cn
http://www.morning.ftlgy.cn.gov.cn.ftlgy.cn
http://www.morning.fdrwk.cn.gov.cn.fdrwk.cn
http://www.morning.tsdqr.cn.gov.cn.tsdqr.cn
http://www.morning.qbfqb.cn.gov.cn.qbfqb.cn
http://www.morning.dkqyg.cn.gov.cn.dkqyg.cn
http://www.morning.nzsdr.cn.gov.cn.nzsdr.cn
http://www.morning.tktcr.cn.gov.cn.tktcr.cn
http://www.morning.jjrsk.cn.gov.cn.jjrsk.cn
http://www.morning.jcfdk.cn.gov.cn.jcfdk.cn
http://www.morning.tnqk.cn.gov.cn.tnqk.cn
http://www.morning.wyfpc.cn.gov.cn.wyfpc.cn
http://www.morning.xxlz.cn.gov.cn.xxlz.cn
http://www.morning.qllcm.cn.gov.cn.qllcm.cn
http://www.morning.yhywx.cn.gov.cn.yhywx.cn
http://www.morning.rkck.cn.gov.cn.rkck.cn

查看全文

http://www.tj-hxxt.cn/news/245112.html