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

龙岗区布吉街道防控措施优化大师的使用方法

wzjs 2025/8/15 2:40:52

龙岗区布吉街道防控措施,优化大师的使用方法,免费下载模板的网站,微信广告推广如何收费文章目录 🦥 降低90%的VRAM用于长上下文🦥 Unsloth 高效的GRPO算法💡 GRPO 的数学问题及发现的问题📈 全局日志记录功能🖥️ vLLM 推理选项✨ 其他更新🦥 使用 vLLM 直接运行 Unsloth Dynamic 4-bit&#x…

文章目录

- 🦥 降低90%的VRAM用于长上下文
- 🦥 Unsloth 高效的GRPO算法
- 💡 GRPO 的数学问题及发现的问题
- 📈 全局日志记录功能
- 🖥️ vLLM 推理选项
- ✨ 其他更新
- - 🦥 使用 vLLM 直接运行 Unsloth Dynamic 4-bit
  - 🚀 运行 Perplexity 的 R1-1776
  - 🐱 GitHub Universe 采访

本文翻译整理自：Long-context GRPO (Feb 20, 2025 • By Daniel & Michael
https://unsloth.ai/blog/grpo

您现在只需 5GB VRAM 就可以训练自己的推理模型，适用于 Qwen2.5 (1.5B) - 比我们两周前的上一个 GRPO 发布版中的 7GB 低！
当前，实现更长的上下文长度是GRPO最大的挑战之一。我们新推导的Unsloth Efficient GRPO算法使

使用TRL + FA2的GRPO设置，Llama 3.1（8B）在20K上下文长度下的训练需要510.8GB的VRAM。

然而，Unsloth的90% VRAM减少将需求降低到仅54.3GB的相同设置中。

尝试我们的免费GRPO笔记本，拥有10倍更长的上下文：Llama 3.1 (8B) on Colab

我们强烈推荐阅读我们的指南以了解有关GRPO + 奖励函数/验证器的所有内容。

查看我们的GRPO笔记本，其中包含其他模型，如Phi-4 此处。

🦥 降低90%的VRAM用于长上下文

当你使用Unsloth进行GRPO时，我们通过多种技巧智能地减少了VRAM的使用，与使用Flash Attention 2的标准实现相比，VRAM使用量降低了超过90%！例如，在20K的上下文长度中，每个提示有8代的情况下，Unsloth仅使用54.3GB的VRAM用于Llama 3.1 8B，而标准实现则需要510.8GB（Unsloth减少了90%）。

1、我们新的GRPO内存高效线性算法将内存使用量减少了8倍或更多
这减少了68.5GB的内存，同时通过torch.compile的帮助，num_generations=8 和 20K上下文长度实际上更快。

2、我们利用我们的 Unsloth gradient checkpointing 我们不久前发布的算法。
它智能地将中间激活异步卸载到系统RAM，同时只慢1%。
这会减少高达372GB的VRAM，因为我们需要num_generations=8。我们可以通过中间梯度累积进一步减少这种内存使用。

3、与其他软件包中的实现不同，Unloth还使用与底层推理引擎（vLLM）相同的GPU/CUDA内存空间这会减少16GB的VRAM。

指标	🦥 Unsloth	TRL + FA2
训练内存成本 (GB)	42GB	414GB
GRPO 内存成本 (GB)	9.8GB	78.3GB
推理成本（GB）	0GB	16GB
推理 KV Cache for 20K 上下文 (GB)	2.5GB	2.5GB
总内存使用	54.3GB (90% less)	510.8GB

在典型的标准GRPO实现中，您需要创建2个大小为(8, 20K)的logits来计算GRPO损失。
这需要 2 * 2字节 * 8（生成次数）* 20K（上下文长度）* 128256（词汇量）= 78.3GB 的VRAM。
Unsloth 为长上下文 GRPO 削减了 8 倍的内存使用量，因此我们只需要额外的 9.8GB VRAM 来支持 20K 的上下文长度！

我们还需要从16位的KV缓存中获取。Llama 3.1 8B有32层，K和V的大小都是1024。所以20K上下文长度的内存使用量为 = 2 * 2字节 * 32层 * 20K上下文长度 * 1024 = 每个批次2.5GB。我们本可以设置vLLM的批次大小为8，但为了节省VRAM，我们将它保持在1。否则，您将需要20GB的KV缓存。

🦥 Unsloth 高效的GRPO算法

我们从Horace的线性交叉熵实现中获得了灵感，并成功使其适用于GRPO！实际上，我们发现了一些令人惊讶的点：
1、参考GRPO实现使用的是反向KL散度，而不是正向KL散度。

2、朴素地实现线性交叉熵在float16混合精度（以及float8）上，如果没有正确处理，将会因为自动混合精度缩放机制而崩溃。

3、我们在GRPO损失的实现方面发现了其他怪癖 - 主要是在反向KL散度的公式化方面。

💡 GRPO 的数学问题及发现的问题

GRPO 首次在 DeepSeek 的 Math 论文中介绍的时间是 2024 年 2 月至 4 月。随后，DeepSeek 在他们的论文中提到了他们利用 GRPO 算法创建了 DeepSeek R1。
我们利用了 Hugging Face 的 TRL GRPO 实现这里。我们看到 TRL 实现执行了：

在这里插入图片描述

这里我们使用reverse KL divergence（而不是正向KL散度）。
Beta是一个设置为0.04的缩放因子，A是在考虑了所有奖励函数后获得的优点。Q是新的训练模型，P是原始参考模型。
我们注意到，有趣的是，该实现计算了反向KL散度，如下所示：

在这里插入图片描述

但是这实际上正确吗？我们首先尝试推导它，并收集同类项：

在这里插入图片描述

所以这意味着实现可能缺少了乘以Q（新的分布项）的操作？但是，正如在介绍GRPO的DeepSeek Math论文中看到的，这似乎是正确的，该论文首次在第14页介绍了GRPO。同样，John Schulman的博客也提到，对于反向KL项的无偏估计实际上不需要额外的Q项。我们在博客中看到：

在这里插入图片描述

我们还发现了一个有趣的现象：torch.exp(q - q.detach()) * advantages.unsqueeze(1) 被使用，这应该被评估为1，对吧？
我们实际上发现这是必要的——似乎自动微分引擎可能没有正确传播梯度。

所以我们进行了4个实验：

通过参考实现（红色线条）进行常规GRPO
移除分离代码（蓝色线条）
全反向KL散度，附加一个之前讨论过的项（黄色线条）
前向 KL 散度（绿色线）

在这里插入图片描述

通常情况下，移除detached肯定会导致所有训练中断，所以我们必须保留它 - 这可能需要更多的调查。看起来其他所有实现似乎都很相似？我们可能需要运行模型更长的时间来观察不同的效果。

在所有实现中，我们同样也利用了logsumexp技巧：

在这里插入图片描述

📈 全局日志记录功能

我们也为所有奖励函数现在提供完整的日志细节！之前我们只显示了总聚合的奖励函数本身。

在这里插入图片描述

您也不再需要调用函数来修补GRPO了！即：从顶部删除此内容（我们会自动完成）：

from unsloth import PatchFastRL
PatchFastRL("GRPO", FastLanguageModel)

🖥️ vLLM 推理选项

我们也现在允许您为 vLLM 使用 FP8 KV 缓存，这允许在较新的 GPU（RTX 3090、A100 及更新的型号）上使用 2 倍更少的 KV 缓存空间。

model, tokenizer = FastLanguageModel.from_pretrained(model_name = "meta-llama/meta-Llama-3.1-8B-Instruct",max_seq_length = max_seq_length,load_in_4bit = True, # False for LoRA 16bitfast_inference = True, # Enable vLLM fast inferencemax_lora_rank = lora_rank,gpu_memory_utilization = 0.6, # Reduce if out of memoryfloat8_kv_cache = True, # Enable float8 KV cache
)

如果您想使用 min_p = 0.1 或其他采样参数在 vLLM 中，我们也支持在 vLLM 的 SamplingParams 参数中传递任何内容！

max_prompt_length = 256
from trl import GRPOConfig, GRPOTrainer
from unsloth import vLLMSamplingParams
vllm_sampling_params = vLLMSamplingParams(min_p = 0.1,seed = 3407,...
)
training_args = GRPOConfig(...vllm_sampling_params = vllm_sampling_params,temperature = 1.5,
)