• 快速Transformer（续）
  • Dual Chunk FlashAttention
  • Differential FlashAttention
  • 参考
• LLM Inference
  • PD分离
  • vLLM
• LLM System
  • RAG
  • 向量数据库
  • Accumulate Gradients

快速Transformer（续）

Dual Chunk FlashAttention

超长文本（论文、代码库、百万token级对话）在原始预训练窗口外直接推理会严重掉精度。

纯FlashAttention虽然节省显存，但序列长度N增加后仍然O(N²)地吃显存，单卡80 GB也很快就OOM。

DCFA把长序列切成≤预训练长度的chunk，先算chunk内注意力（intra-chunk），再算chunk间注意力（inter-chunk），把显存复杂度压到O(chunk_size²)，理论上可以无限外推长度。

Differential FlashAttention

传统Transformer在长上下文时会把大量注意力权重放到“噪声 token”上，产生幻觉和上下文丢失。

Differential Transformer：

\[\text{DiffAttn}(X) = \underbrace{\vphantom{\lambda}\operatorname{softmax}\!\left(\frac{Q_{1}K_{1}^{\!\top}}{\sqrt{d_{k}}}\right)V}_{\text{主注意力}} - \lambda\,\underbrace{\vphantom{\lambda}\operatorname{softmax}\!\left(\frac{Q_{2}K_{2}^{\!\top}}{\sqrt{d_{k}}}\right)V}_{\text{噪声注意力}}\] \[\lambda = \exp(\lambda_{q1}\!\cdot\!\lambda_{k1}) - \exp(\lambda_{q2}\!\cdot\!\lambda_{k2}) + \lambda_{\text{init}}\]

相当于让第二个分支专门学“噪声模式”，然后显式减掉。

但这样就带来两倍KV Cache + 两次FlashAttention计算的开销。于是作者直接写了一个“一次kernel launch里跑两路”的专用 CUDA kernel，起名叫Differential FlashAttention。

参考

https://mp.weixin.qq.com/s/1R_plHqxTLE-Fw3TjYnlJQ

GPU BERT上线性能不合格，看看微信AI的PPoPP论文

https://mp.weixin.qq.com/s/OgTQ3O_6lvOG07U-tjpTDA

如何让Transformer在GPU上跑得更快？快手：需要GPU底层优化

https://zhuanlan.zhihu.com/p/638468472

从FlashAttention到PagedAttention, 如何进一步优化Attention性能

https://blog.csdn.net/v_JULY_v/article/details/144218958

一文通透vLLM与其核心技术PagedAttention：减少KV Cache碎片、提高GPU显存利用率(推理加速利器)

LLM Inference

A Survey on Efficient Inference for Large Language Models

---

https://zhuanlan.zhihu.com/p/653352979

LLM七种推理服务框架总结

https://zhuanlan.zhihu.com/p/671347964

大模型(LLM)推理框架汇总

https://zhuanlan.zhihu.com/p/642412124

LLM的推理优化技术纵览

https://github.com/DefTruth/Awesome-LLM-Inference

Awesome LLM Inference

---

https://www.zhihu.com/tardis/zm/art/647813179

大模型文本生成——解码策略（Top-k & Top-p & Temperature）

https://b23.tv/OfdfBnz

如何设置大模型推理参数，top_k，top_p, temperature, num_beams

https://blog.csdn.net/HUSTHY/article/details/125990877

Contrastive Search Decoding——一种对比搜索解码文本生成算法

https://zhuanlan.zhihu.com/p/656707466

DoLa：层对比解码改善LLM的真实性

---

Speculative Decoding：先用一个轻量级“提议器”快速生成K个候选token，再用主模型并行打分，能少跑很多步主模型。

《Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads》提出：

不额外训练完整草稿模型，而是在原模型最后一层隐藏状态上挂3-5个轻量级前馈头（Medusa Heads），每个头负责预测第2,3,…,K+1位置的token。这些头与原模型共享KV缓存，因此几乎不占额外显存。

EagleProposer复用主模型的Embedding与LMHead，只额外训练一个轻量的Auto-regression Head，接受率显著高于Medusa/普通小草稿模型。

https://zhuanlan.zhihu.com/p/651359908

大模型推理妙招—投机采样（Speculative Decoding）

---

LLM Inference的性能评估主要有以下几个方面：

• Time To First Token (TTFT)
• Time Per Output Token (TPOT)：解码阶段总耗时 / 生成token数
• Latency：模型为用户生成完整响应所需的总时间。latency = (TTFT) + (TPOT) * (the number of tokens to be generated)
• Throughput：一个推理服务器每秒可以为所有用户和请求生成的输出token数量。
• TBT（Time Between Tokens）：第i+1个token时间戳 − 第i个token时间戳。流式/对话场景（逐token吐字）更关心TBT。

https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices

LLM Inference Performance Engineering: Best Practices

PD分离

一次用户请求，实际上既包含prefill，也包含decode。一个是计算密集型，一个是访存密集型。

prefill（用户输入）和decode（模型输出）的token量在不同场景下也是不一样的。如果是简单对话场景，通常模型的decode输出会更多一些，而如果是超长上下文场景，用户先上传一本几十万字的书再进行问答，这本书的prefill会直接起飞。在Agent场景下，大量预设的prompt也会占据非常多的prefill，不过prompt的prefill有不少机会可以提前算好KV而无需每个用户请求单独重复计算。

当整个推理系统服务几千万用户时，一个batch的几十个用户请求只是开胃菜。每个用户会不间断地和大模型进行交互，发出大量请求，但这些请求的间隔时间短则几秒，长则几分钟几小时。考虑人机交互的频率，一个用户请求结束后，对应的KV-cache继续常驻在高速内存中实际意义不大。

---

这个从今年年中开始，各家都陆续上了PD分离方案（如MoonCake）。

Prefilling阶段是计算密集型，少量Query就可以打满GPU，大量Query反而会增加首token延迟；Decoding阶段是访存密集型，必须依赖大量Query提高GPU计算利用率。因此可以通过多台机器处理Prefilling、单台机器处理Decoding的PD分离方案，实现综合效率最大化、首token延迟（TTFT）最低、DecodeSpeed（TPS）最高。

---

Rubin CPX，是专门为推理阶段prefill准备的低成本卡。prefill阶段所需带宽较小，配置“瘦带宽”而“肥容量”的GDDR7，显然更为合适。

https://www.zhihu.com/question/1949040585416636414

如何看待英伟达最新发布的Rubin CPX及相应的上下文理解/生成分离设计?

vLLM

https://docs.vllm.ai/en/latest/

Easy, fast, and cheap LLM serving for everyone

Piecewise CUDA Graph是vLLM中用于解决传统CUDA Graph在动态场景下局限性的一种优化策略。

标准CUDA Graph要求输入tensor的shape、地址、类型完全固定，否则会报错。

在LLM推理中，batch size、seq len、KV cache布局经常变化，导致整张图无法复用。

因此，vLLM将模型按“稳定区域”切成多个片段，每个片段内部仍满足CUDA Graph的静态要求。

LLM System

RAG

Retrieval Augmented Generation（检索增强生成）：通过检索获取相关的知识并将其融入Prompt，让大模型能够参考相应的知识从而给出合理回答。因此，可以将RAG的核心理解为“检索+生成”，前者主要是利用向量数据库的高效存储和检索能力，召回目标知识；后者则是利用大模型和Prompt工程，将召回的知识合理利用，生成目标答案。

https://zhuanlan.zhihu.com/p/668082024

一文搞懂大模型RAG应用

https://blog.csdn.net/v_JULY_v/article/details/137711599

RAG进阶之通用文档处理：从RAGFlow、TextMonkey到mPLUG-DocOwl 1.5

https://zhuanlan.zhihu.com/p/695299235

RAG路线图： Reliable, Adaptable, and Attributable Language Models with Retrieval

---

Pooling models是一类把可变长度序列“压缩”成固定长度向量的模型，也常被称为sentence embedding模型。

它们的核心动作就是pooling：先把输入文本用Transformer编码成一系列token向量，然后对这些向量做一次pool操作，得到一个整体表征（embedding），用来做下游的检索、聚类、分类、重排等任务，是RAG、向量数据库、语义搜索的基石。

---

假设有一个10w的外部数据，我们的原始输入Prompt长度为100，长度限制为4k，通过查询-检索的方式，我们能将最有效的信息提取集中在这4k的长度中，与Prompt一起送给大模型，从而让大模型得到更多的信息。此外，还能通过多轮对话的方式不断提纯外部数据，达到在有限的输入长度限制下，传达更多的信息给大模型。

https://blog.csdn.net/qq_40491305/article/details/130898052

一文看懂LlamaIndex用法，为LLMs学习私有知识

向量数据库

向量搜索在搜索、推荐、NLP等众多应用领域被广泛的使用，典型的互联网业务，包括电商、出行、点评、地图等都大量使用相关技术。随着ChatGPT带来的AI技术应用新热潮，向量数据库又一次地获得了更多的关注。它可以解决LLM不长记性（Memory，记忆）的问题。

普遍认为LLM+Vector Search+API pool会变成复杂AI场景的标准解决方案。

类似Pinecone，Weaviate，Qdrant，Chroma这样的专用向量数据库最初是为了解决ChatGPT的记忆能力不足而出现的Workaround。

最发布的ChatGPT 3.5的上下文窗口只有4K Token，也就是不到两千个汉字。然而当下GPT 4的上下文窗口已经发展到了128K，扩大了32倍，足够塞进一整篇小说了。而且未来还会更大。这时候，用作临时周转的垫脚石——向量数据库SaaS就处在一个尴尬的位置上了。

https://www.zhihu.com/question/603117242

为什么各大VC最近都在投向量数据库？

https://zhuanlan.zhihu.com/p/668509885

向量数据库凉了吗？

Accumulate Gradients

gradient_accumulation_steps用于处理当模型的参数数量超过GPU内存容量时的情况。在训练大型模型时，尤其是在使用较小的GPU进行训练时，可能会遇到内存不足的问题。这时，可以使用梯度累积来分割批次，从而使得每个小批次的计算都在GPU的内存限制范围内。

如果设置了gradient_accumulation_steps=N，那么模型会先对N个批次的数据进行前向和反向传播，将这些批次的梯度累积起来，然后才进行一次权重更新。这样，实际上的批次大小相当于per_device_train_batch_size * N。