戴昊光-优快云博客

原创大模型推理 & memory bandwidth bound (5) - Medusa

上一篇我们对工作《Fast Inference from Transformers via Speculative Decoding》进行了讲解，对大模型推理加速范式有了基本的认识。尽管上述工作设计简洁，但在实际场景中有如下问题需要克服：1）需要额外训练一个，且尽可能保持其输出分布与一致；2）将一同集成到分布式系统中具有挑战性。对于1）补充说明一下：尽管开源模型系列通常包含不同尺寸的模型，且它们的分布相近，但这并不意味着其中必然存在一个合适的小模型作为。以LLaMA2。

2025-05-24 15:14:42 1021

原创大模型推理 & memory bandwidth bound (4) - Speculative Decoding

前面两篇，我们分析了MQA和MLA对于大模型推理加速的贡献，其通过压缩KV Cache，增加算数强度的方式，缓解了大模型增量推理时的问题。本篇我们来探究另一种流行的推理加速范式，其使用小号的模型draft model去做自回归采样，而后使用目标模型target model对其进行验证和纠错。在论文《Fast Inference from Transformers via Speculative Decoding》中，作者通过实现了2X-3X的解码加速，且不改变输出分布。

2025-05-24 15:14:01 936

原创大模型推理 & memory bandwidth bound (3) - MLA

在上一篇，我们解读了《Fast Transformer Decoding: One Write-Head is All You Need》这篇文章，确认了MHA在Decode阶段的问题，分析了MQA方法带来的优化。具体来说，MQA的KV Cache压缩成了原来1hh1hhh为注意力头的个数），增加了计算强度，缓解了问题；同时，KV Cache的减少意味着可以增加batch size，也即可以同时处理更多的requests。今天要讨论的是，它是另一种极致压缩KV Cache的方法，在。

2025-03-16 19:09:11 525

原创大模型推理 & memory bandwidth bound (2) - Multi-Query Attention

经过上一篇关于的铺垫，本篇来讲一下《Fast Transformer Decoding: One Write-Head is All You Need》这篇论文。其在摘要部分的这句表述（如上所示）就强调了大模型在增量推理，也即Decode阶段由于导致的推理效率低下的问题。作者提出了技术，加速了大模型推理。是的变体，本篇跟随论文的思路，分析对比和的性能，最后根据一个demo实测一下效果。关于注意力机制的前置知识本文不再赘述，如有需要可参考之前写的。通过分析计算复杂度和内存访问复杂度的方式，确认了在。

2024-11-11 16:26:21 1181

原创大模型推理 & memory bandwidth bound (1) - 性能瓶颈与优化概述

随着大模型参数量的增加，其推理加速成为一个重要的研究方向。比如我们在vLLM系列中有讲到，vLLM在内存（显存）管理上使用了技术，再结合的调度策略，大大提高了在面对多个请求时GPU的使用率，这种系统层级上的优化提高了吞吐，降低了延迟。大模型推理之所以低效，主要是因为自回归解码过程受到内存带宽限制（在解码阶段，模型需要频繁从内存中读取和写入数据，而内存带宽又比较有限，因此有较高的延迟。为了突破该性能瓶颈，出现了各种有意思的工作，比如系列、以及MEDUSA等等。

2024-11-11 16:24:26 3796

原创 OCR Fusion: EasyOCR/Tesseract/PaddleOCR/TrOCR/GOT

OCR，光学字符识别）是指对包含文本内容的图像或视频进行处理和识别，并提取其中所包含的的文字及排版信息的过程（摘自维基百科）。根据其应用场景可分为印刷文本识别、手写文本识别、公式文本识别、场景文本识别以及古籍文本识别。举一个实用的例子：想阅读一本电子书，但该书是扫描版的 PDF 文档，具有文件体积大、文字不可选、无法编辑和可读性差的缺点；我们可以借助OCR将文档识别并转换成轻量的 EPUB 格式，并提升阅读体验。有意义的应用场景还有很多，此处不一一列举。最近由于实际需求，对之前和时下流行的OCR。

2024-09-28 21:18:59 3871

原创 vLLM (6) - Scheduler & BlockSpaceManager

前面两篇展开讲解了LLMEngine，涉及了Worker和Scheduler等核心组件，相信大家对其工作原理与流程已经有了相对清晰的认识。受限于篇幅，上一篇我们没有对Scheduler彻底展开，这将会是本篇的重点。回想一下vLLM等大模型推理框架解决的问题是什么？当大模型开放给用户的时候，会面对大量请求，因此推理框架的目标就是通过高效利用现有资源（比如显存）等方式来增大吞吐量，降低延迟，以便快速给到用户响应。在vLLM中，通过Scheduler合理的调度方式，以及优化的GPU使用率，完成了上述目标。

2024-09-28 19:17:14 2698

原创 vLLM (5) - LLMEngine下篇

前面一篇已经讲了LLM和LLMEngine的初始化阶段，包括设备初始化，模型加载和cache初始化等等，本篇来讲解LLMEngine的生成阶段，功能包括请求的调度以及模型的推理，初步分析调度器Scheduler是怎么工作的，也就是下图的Scheduler部分。本篇介绍了和这两个方法。尤其是后者，其中调度器Scheduler扮演了非常重要的角色，在调度预算和显存限制下，按照指定策略调度了用户请求，进行推理。由于篇幅关系，对Scheduler更加细致的分析会在下一篇展开。

2024-09-07 17:14:18 3095

原创 vLLM (4) - LLMEngine上篇

经过前面两篇的铺垫，终于来到了解析LLMEngine的篇章。如下图所示，LLMEngine主要有两部分构成，右边部分包括Worker和等重要的类，它们在LLMEngine的初始化阶段就会用到，工作内容包括模型加载，KV Cache初始化等等，这是本文中重点；左边部分包括Scheduler和，用于调度用户请求，并在过程中管理显存和内存，这部分发生在LLMEngine的（generate）生成阶段，将放到后续文章中。本篇主要介绍了LLMEngine初始化部分的内容，涉及了Worker和。

2024-09-07 16:41:27 3855

原创 vLLM (3) - Sequence & SequenceGroup

一个request请求通常对应一个或者多个序列，在vllm中，使用Sequence来表达一个序列，同一个请求中的所有序列构成了一个序列组，用来表达。尽管它们本身并不难懂，但是涉及到了序列的状态标记（是WAITING还是FINISHED）、所处阶段（是Prefill还是Decode）以及对应的逻辑块等等。理解它们，对后续分析vllm调度以及block的分配等问题有着重要作用。另外，本系列之前没有对（过程如下图所示）和KV Cache做出过比较正式或者深入的介绍。如果对他们不了解或者还有困惑，非常建议查看。

2024-08-25 09:27:09 2406

原创 GLM-4 (6) - KV Cache / Prefill & Decode

KV Cache是一种为大模型量身定制的推理加速技术。为什么？因为大模型推理的逻辑是：根据当前轮输入tokens预测并输出下一个token，这两者拼接就得到了下一轮的输入，每一轮只比上一轮增加了一个token。这意味着当前轮包含了上一轮的部分计算。上一轮中每一层的key和value被当前轮复用，而不是重新计算，就能加速推理过程，这就是KV Cache的作用。随着KV Cache的广泛使用，大模型的推理被分为了Prefill和Decode两个阶段。简单来说，Prefill阶段将prompt。

2024-08-25 08:43:10 6748 5

原创 vLLM (2) - 架构总览

上一篇通过Qwen2的vllm推理和部署，对vllm有了简单直观的了解，但是我们尚未涉及到它的工作原理。接下来我们将以vllm源码为基础，逐步解析。本篇主要是对vllm架构的总览。本篇通过原理简述、架构图和项目结构展示这几个部分对vllm原理和架构做了解析，相信大家对vllm有了更深入的认识，也为后续源码分析清楚了一些障碍。

2024-08-17 18:19:31 6353

原创 vLLM (1) - Qwen2推理&部署

vllm是一个优秀的大模型推理框架，它具备如下优点：易于使用，且具有最先进的服务吞吐量、高效的注意力键值内存管理（通过实现）、连续批处理输入请求、优化的CUDA内核等功能（摘自qwen使用手册为了深刻的理解vllm，我将写系列文章来解析，内容包括：1）小试牛刀，使用vllm来推理和部署一种大模型；2）深入理解，源码解析。因为Qwen2在同期的大模型中效果确实不错，并且有相应的使用手册（前面已给出），本篇尝试使用vllm来推理和部署Qwen2vllm源码解析放在后续文章中。还有一些其他的vllm。

2024-08-17 18:05:10 5726 2

原创 GLM-4 (5) - API & Function Calling

我们之前解析了GLM-4模型相关的部分，这有助于我们对理解和使用开源大模型。然后，有一些场景对于大模型的性能（比如某个任务的推理准确率）有较高的要求，10B以下参数的模型很可能无法胜任。那么就有两条路可以选择：1）收集与任务相关的数据，微调该模型；2）直接使用商业化的API服务。由于第一条路收集数据工作量较大，所以调用API是个不错的选择，也是本篇要讲述的内容。大模型并不是万能的，推理的时候也会出错，比如近期的热搜就是大模型比较9.11和9.8大小的时候变成弱智。但是，大模型有。

2024-07-30 21:14:45 1799

原创 GLM-4 (4) - SelfAttention

Attention是架构核心。刚开始使用的一般是，本质上是希望在维度上进行切分，效果类似于CNN中多个通道。如果头的个数是n_head，那么querykeyvalue都被切分成n_head份，分别做操作，最后将结果拼接。后面又开发出了，也就是说query还是和之前一样，但是会在多个头之间共享。实验结果表明，大大提升了解码速度；同时考虑到kv_cache缓存，大大减小了存储每个头的键和值所需的内存开销。根据上图，我们很容易理解3种注意力的区别。

2024-07-16 22:01:06 1200

原创 GLM-4 (3) - GLMBlock

前两篇文章分别讲了GLM-4推理+概览，以及旋转位置编码，这一篇主要来看一下模型架构/组件。我们知道现在的大模型都是基于的，它又是由若干层组成。在GLM-4代码中，对应了部分，而GLMBlock就对应着。我们主要就来看这两部分。本篇我们围绕GLM-4核心组件和GLMBlock来分析，并对一些细节做出了解释。下一篇将会对attention部分进行讲解。

2024-07-16 21:31:32 936

原创 GLM-4 (2) - RoPE

上一篇对GLM-4模型推理等做了一些记录，但是未涉及网络模型部分的细节。本篇分析一下旋转位置编码RoPE。网上关于理论部分的博客较多，因此本篇不会在理论部分花太大的篇幅，主要还是从代码入手。原始论文在此，目前更关心理论部分的可移步其他教学博客。首先我们对RoPE做一个简单概述；然后，为了更好的理解glm系列的位置编码实现，我们先分析chatglm-6b源码，然后转到上来，因为两者之间一脉相承，又有一些区别。这部分摘自labmlai。以query为例，说明RoPE是如何为它添加位置编码的。假设query。

2024-07-13 10:09:38 1096 2

daihaoguang的博客