一文贯通LLM推理相关知识【上下文长度、量化、模型大小】

最新推荐文章于 2025-03-18 21:42:50 发布
最新推荐文章于 2025-03-18 21:42:50 发布
阅读量1.7k 收藏 6
点赞数 5
文章标签： 人工智能 大模型 大模型推理
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq874455953/article/details/141460042
版权

1 不同参数量LLM推理需要多少显存？

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

2 Batch Size，量化对所需显存有什么影响？

要点：

  • BatchSize增加，显存占用也会增加。
  • 量化可以节省显存：通过下表中的数据可以看到，6B模型在float16时占用12G显存，8bit量化占用7G，4bit量化只需要4G显存。
    在这里插入图片描述

3 上下文长度对所需显存和推理速度的影响有多大？

  • 上下文越长，推理速度就会越慢 （0-6K前的输入速度差不多）
  • 显存占用也会跟着增加。 在这里插入图片描述

4 量化对推理速度的影响如何？

  • 量化后推理速度会变慢或者持平
  • 当量化影响到GPU使用量时，比如从多张GPU降低到单GPU，推理速度会明显变快

Qwen2模型的测试结果如下：

  • Qwen2-0.5B模型：量化模型速度变慢
  • Qwen2-1.5B模型：量化与fb16相比速度持平
  • Qwen2-7B模型： 稍微变慢，使用vLLM时，量化版本更快
  • Qwen2-72B模型：速度变快（尤其是Int4量化后，从2GPU变为1GPU后推理速度变快明显），但是当使用长context时（120k），量化版本推理速度变慢
    详细结果请访问：https://qwen.readthedocs.io/en/latest/benchmark/speed_benchmark.html

5. 参数量对推理速度的影响？

反直觉： 0.5B推理速度仅仅只快了4倍
在这里插入图片描述

6 vLLM，DeepSeed，CTranslate2等工具推理速度如何？

  • 与Transformers相比，使用vLLM，DeepSeed等工具加速，推理速度可以提升2到5倍。
  • DeepSeed， vLLM， Ctranslate2 三个加速工具中 CTranslate2 的表现更好，尤其是batch size为1时。

个人建议：
vllm最方便使用 适合操作

在这里插入图片描述

7 量化对模型性能的影响如何？

Int8量化模型性能与float16格式差别不大
在这里插入图片描述
Int4量化模型与float16模型相比，精度损失在 1 - 2 个百分点左右。（Yi模型与Baichuan2模型有类似的结论）

8 常见LLM用GPU参考
在这里插入图片描述

参考资料
http://www.wcpdoc.com/webdoc/view/Pub2c94830b8ff1a26a0190456d28f50961.html

AI测试入门：理解 LLM 的上下文长度（context length）
blues_C的博客
10-12 1151
在 LLM 处理信息时，文本被分解成一系列的标记（tokens），这个过程称为标记化（tokenization）。然后给模型提供每个标记在原始文本中的位置信息，这个过程称为位置编码（position encoding）。经过标记化和位置编码后，模型会处理这些结构化信息。
LLM上下文长度再升级
AI大模型应用之禅
02-18 406
LLM上下文长度再升级 1. 背景介绍 近年来，随着Transformer及其衍生模型在自然语言处理(NLP)领域取得巨大突破，大语言模型(LLMs)如BERT、GPT等逐渐成为研究与应用的焦点。这些模型在处理长序列和复杂任务上表现优异，但它们的上下文长度限制了其应用范围。本文将从背景介绍、核心概念
DeepSeek部署需要多少GPU资源？一文搞懂如何计算MoE模型显存占用（附自动计算工具）
Code1994的博客
02-08 3607
DeepSeek 采用 MoE 架构，相较于传统 Transformer，在推理阶段大幅降低了显存需求。显存消耗主要受 模型参数量、KV Cache、激活值存储 以及 并发 影响，同时不同精度格式（如 FP16、INT8）也会影响显存占用。由于 MoE 模型包含 MoE 层与非 MoE 层，两者的 KV Cache 和激活值计算方式有所不同，导致计算相对复杂。为方便大家使用，笔者整理了一份 Excel 计算表，并附上常见 NVIDIA GPU 参数供参考。
大模型到底需要消耗多少GPU显存？公式和工具全都有
m0_59164304的博客
08-21 5754
如何计算大模型到底需要多少显存，是常常被问起的问题。现从实用角度介绍一个简单公式和一个工具方便大家工作中使用。1）估算公式（该公式来自于Sam Stoelinga简化[1]）注意：该公式只是为了简化计算的估计，并未包含kvcache所需显存以及context大小的影响。下面以运行16位精度的 Llama 70B 模型所需的 GPU 内存为例套用公式：该模型有 700 亿参数。由此可见，模型所需的 GPU 内存相当大。
LongRoPE2：让大模型“记忆”更长，还不掉链子！
hh051020的博客
03-03 274
想象你读一本小说，翻到第100页却忘了前面99页讲了啥，尴尬不？上下文长度就是大模型能“记住”的历史信息量。简单说，它决定了模型一次能看多长的文本。比如给它一本《哈利·波特》，如果记性只有几页，那问它“伏地魔为啥这么坏”，它可能一脸懵逼。
大模型GPU显存占用计算
weixin_44532170的博客
12-03 6803
以参数量13B大模型为例，其中B是Billion，代表十亿参数，13B就是130亿参数其中每个参数全精度是fp32，也就是float32，占用32位bit，也就是4byte字节。那么全精度13B模型占用。
一文了解：LLM 的上下文长度（context length)
qianggezhishen的专栏
10-10 2763
想象一下，如果LLM的上下文窗口变大了，它们就能在回答我们之前，考虑更多的信息，这样它们的回答就会更准确，内容也会更丰富。总的来说，上下文窗口对于LLM来说就像是它们的视野，视野越宽，它们能做的事情就越多，但同时也需要更多的资源。想象一下，你有一个超级聪明的助手，它能写文章、回答问题，但有时候它需要更多的信息来给出最好的答案。但是，如果上下文窗口变大了，LLM就需要更多的脑力和记忆空间来工作，这就有点像是我们的电脑需要更多的内存和处理器一样。它们让模型不仅能处理更多的信息，还能在需要的时候去找更多的资料。
一文读懂大模型显存需求：从0.5B到70B，你的显卡够用吗？
2401_85373691的博客
02-05 2万+
最小推荐内存基于相应精度计算，包含工作内存和系统预留 **最小推荐内存(FP32)基于全量参数计算，包含工作内存和系统预留。
大模型实践第五节课笔记
weixin_46239415的博客
03-11 1587
首先我们需要明白一点，服务部署和量化是没有直接关联的，量化的最主要目的是降低显存占用，主要包括两方面的显存：模型参数和中间过程计算结果。接下来我们切换到刚刚的终端（就是上图右边的那个「bash」，下面的「watch」就是监控的终端），创建部署和量化需要的环境。目录下的环境是官方未大家准备好的基础环境，因为该目录是共享只读的，而我们后面需要在此基础上安装新的软件包，所以需要复制到我们自己的 conda 环境（该环境下我们是可写的）。值得说明的是，以上的划分是一个相对完整的模型，但在实际中这并不是绝对的。
【大模型】如何正确评估DeepSeek-R1各版本所需推理显存？KV Cache原理和显存计算解析
兴趣使然的创作者
03-18 1840
本文主要回答以下几个问题：1. 本地部署大模型时，如何快速判断所需显存量？ 2. 大模型推理所需显存由哪几部分构成？ 3. KV Cache是什么，为什么只有KV Cache而没有Q Cache？ 4. KV Cache显存如何进行计算？ 5. 大模型为什么会出现失忆现象，本质原因是什么？ 6. Ollama中，如何修改上下文长度？
记录一下 cuda、torchinfo、gpustat 相关知识
木尧大兄弟
08-23 1096
记录一下关于 cuda 显存分配、使用 torchinfo 查看模型参数量，以及使用 gpustat 查看显存占用及进程信息等知识。
模型训练和推理过程中的显存占用问题
Alex
03-19 4341
我有两个GPT2的模型，只有1亿参数，并以16位浮点数存储，也就是250MB左右，有35亿参数，同样以16位浮点数存储，也就是7GB左右。我以为推理的时候加载模型到显存中后占用的空间应该也是差不多的大小，但是1亿参数的模型加载到TorchServe中后却占用了957MB，不知道为什么多出来700多MB。
ByteScale：使用超过12,000个GPU进行具有2048K上下文长度的LLM训练的有效扩展
03-03
ByteScale使用超过12,000个GPU进行具有2048K上下文长度的LLM训练，通过有效地扩展，它解决了现有技术面对长上下文训练时内存消耗高、通信量大、负载不均衡等问题，显著提高了长上下文语言模型的训练效率。...
LazyLLM：长上下文场景下提高LLM推理效率
程序员小麦的博客
08-06 1464
文章提出了LazyLLM技术，这是一种针对长上下文场景下提高大型语言模型(LLM)推理效率的方法，它通过动态选择性计算关键token来加速预填充阶段，同时保持推理性能，无需额外的模型微调。并且，LazyLLM可以无缝集成到现有的基于Transformer的LLM中，提高推理速度。
大模型LLM 在线量化；GPTQ\AWQ量化及推理
weixin_42357472的博客
11-19 2004
参考:https://github.com/casper-hansen/AutoAWQ/blob/87350fefb9081dadec111cea9b315d009d877a87/examples/quant_custom_data.py。参考：https://vllm.readthedocs.io/en/latest/quantization/auto_awq.html。参考：https://github.com/vllm-project/vllm/issues/1538。应该是vllm暂时还不支持。
llama2模型部署方案的简单调研-GPU显存占用(2023年7月25日版)
热门推荐
我祝你身体健康～一千遍——也～不够～～～～够！！！
07-25 4万+
llama2显存占用，本地部署，本地推理
vLLM模型推理引擎参数大全
洛阳泰山的博客
03-19 3394
llm ai对话大语言模型推理服务框架引擎 参数 大全
vllm常用参数总结
baiyipiao的博客
09-05 1万+
具体参数：OpenAI 兼容服务器 — vLLM引擎参数 — vLLM常用参数： 2. 终端分析 2.1 查看终端内容 2.2 /metircs接口 请求： curl http://localhost:8000/metircs输出结果较长，主要分析vllm:采用的框架为vllm，部署的Qwen72B是选择环境0.4.3部署的Llama70B选择的环境是0.5.3vllm低版本无法适配Llama模型，在vllm0.5.3修复了该问题Issue：[Model] Meta Llama 3.1
大语言模型LLM基础：推理/不同模型/量化对显存、推理速度和性能的影响
sagima_sdu的博客
06-29 6962
本文内容和测试数据主要来自Qwen，零一万物，Nvidia等官方材料（相关文档请查看参考资料部分）。
sglang压力测试
最新发布
04-01
<think>好的，我现在需要处理用户关于sglang压力测试工具和方法的请求。首先，用户提到他们想进行sglang相关的压力测试，所以我要先确认sglang本身的压测工具以及推荐的第三方工具。根据系统指令中的引用[^1]，用户已经提到了sglang自带的bench_serving工具，还有Locust和EvalScope。我需要详细整理这些工具的使用步骤和注意事项。 接下来，我需要确保回答符合用户的要求，结构清晰，分步骤说明。可能需要分点列出每个工具的具体使用方法，比如安装命令、测试脚本示例、执行命令等。同时，用户可能关心如何分析结果和优化性能，这部分也需要包含进去，比如监控哪些指标，如何调整参数。 还要注意用户提到的系统级指令，比如数学公式的正确使用，不过这个问题可能不涉及数学内容，所以可能不需要处理。另外，生成相关的问题部分，我需要考虑用户可能进一步会问的问题，比如压测参数如何设置，结果如何解读，优化建议等。 需要验证每个工具的使用方法是否正确，例如sglang的bench_serving是否真的需要编写YAML配置文件，以及Locust的测试脚本结构是否正确。可能需要参考sglang的官方文档或相关资源来确保信息的准确性。如果有不确定的地方，应该提醒用户查阅官方文档或社区支持。 此外，用户可能希望了解不同工具之间的优缺点，比如sglang自带的工具和第三方工具的区别，适用场景等，这部分也需要简要说明。最后，要确保所有引用正确标注，比如Locust部分末尾添加[^1]的引用标识。 总结一下，回答的结构应该是：首先介绍sglang自带的压测工具，然后介绍第三方工具如Locust和EvalScope，接着给出优化建议，最后列出相关问题。需要确保步骤详细，代码示例正确，并且语言简洁明了，符合中文表达习惯。</think>### SGLang 压力测试工具与方法指南 #### 一、SGLang 原生压测工具 SGLang 内置的 `sglang.bench_serving` 工具可直接测试推理服务性能，支持并发请求模拟： ```bash # 安装工具包 pip install sglang[all] # 编写测试配置文件 benchmark.yaml model: deepseek-r1 concurrency_levels: [10, 20, 50] request_rate: 100 prompt_length: 512 # 执行压测 sglang.bench_serving --config benchmark.yaml ``` 测试结果包含：$$ \text{Throughput} = \frac{\text{Total Requests}}{\text{Test Duration}} $$ 和 $P95$ 延迟指标[^1]。 #### 二、第三方工具集成 1. **Locust 分布式压测** ```python # locustfile.py from locust import HttpUser, task class SGLangUser(HttpUser): @task def generate(self): self.client.post("/generate", json={ "prompt": "压力测试样例文本...", "max_tokens": 128 }) ``` 执行命令：`locust -f locustfile.py --headless -u 1000 -r 100 --run-time 1h`[^1] 2. **EvalScope 专业测试** ```bash evalscope run --target=http://sglang-server:3000 \ --scenario=burst-load \ --metrics=latency,throughput \ --duration=3600s ``` #### 三、关键优化参数 - 并发梯度测试：$C = \{10,20,50,100\}$ - 上下文长度测试：$L \in [256, 4096]$ - 批处理大小调整：$B_{max}= \lfloor \frac{GPU\_MEM}{2.5 \times L} \rfloor$ #### 四、结果分析维度 1. 吞吐量下降拐点检测 2. 延迟分布直方图分析 3. GPU利用率与显存占用曲线
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值