Llama2跟进：GPU硬件要求、微调注意事项等【202307】

在过去几天里关注Llama 2 的所有新闻已经超出了全职工作的范围。 信息网络确实充满了拍摄、实验和更新。 至少还要再过一周，但已经有一些关键点了。

推荐：用 NSDT设计器 快速搭建可编程3D场景。

在这篇文章中，我将澄清我对原始帖子中有关 Llama 2 的所有内容所做的一些更正，然后我将继续我的分析。 文章的前半部分将是迄今为止模型中存在争议和/或受到质疑的部分，最后，我将包括我的其余技术笔记（关于进一步的强化学习细节和新的上下文管理方法 Ghost Attention） 。

首先，两个快速更正：

• 它是开源的吗？ 我原来的标题中错误地包含了“开源”一词。 从技术上讲，该模型不是开源的，因为它的开发和使用并未完全向全体公众开放。 它对于开源社区仍然有用，但它只是一个开放发布/开放创新[这里有更多内容，我很快就会重新讨论这一点]。
• 偏好数据的成本：我曾指出，为训练而收集的偏好数据大约花费 2000 万美元，但我错过了提示与回合的划分因素（每个提示有 4 个回合），所以我预计他们支付了大约 800 万美元的费用。 尽管如此，我预计该项目的总成本将在 2000-4500 万美元之间。

1、通过无害来逃避

人们发现 Llama-2-chat 的安全过滤器表现出喜欢触发的行为。 要求一些无辜的东西，例如如何制作辛辣的蛋黄酱或如何杀死一个进程，会导致模型疯狂地声明它无法做到这一点。 以下是当今领先的开源人工智能工程师 Anton 的一个例子：

我不需要因为这件事有多烦人而大吵大闹。 这用起来非常烦人。

关于为什么会出现这种情况，有很多流行的理论——大多数都指出使用 RLHF Hammer的时间太长。 这一缺陷的原因说明了当今大型语言模型的大趋势。 对于 RLHF，训练期间使用的主要性能指标是偏好模型奖励的单调增加。 这遇到了两个直接问题：a）我们使用的奖励模型不完整，b）我们错过了中间训练技术的有用评估技术。

只要我们仅在验证集上训练的奖励模型能够达到 65-75% 的准确率（因为训练数据是不同人类偏好的嘈杂集合，很难建模），那么你的模型就会出现 RLHF 过长的情况。 当一个模型对奖励模型采取太多优化步骤时，它就会过度索引该模型喜欢的行为，即使对模型的更全面的评估会表明情况并非如此。

目前还没有立即彻底的解决方案，但我的团队正在尝试在 MT Bench 和其他自动 NLP 评估上为 RL 训练的每个时期调度运行。 目前的LLM培训，至少在聊天领域，与用户的期望极不相符。

与往常一样，附录中隐藏了有关此内容的详细信息。 最终，Meta 的评估表明，聊天模型在评估中可能存在两个潜在的致命弱点：

• 该模型被发现拒绝回答高达 27% 的临界问题！ 这与 Anthropic 的工作思路密切相关，他们建议首先开发一个有用的语言模型，然后开发一个无害的语言模型，因为同时这样做会导致回避行为。 事实上，这已经在论文中出现并且众所周知，这意味着 Meta 肯定正在努力解决这个问题。

这种有益与有害的权衡是开源社区面临的一个基本问题。 训练和发布仅有用的模型对那些希望以 Meta 不希望且无法真正执行的方式使用这些模型的负面行为者有利。 如果我们不能发布这些内容，我们最终会陷入困境，就像有些人查看Llama 2一样。期待继续关注这件事的进展。

下图显示了“边界数据集”模型拒绝的疯狂增加。

• 奖励模型集成技术存在一个问题，即存在高度分歧的区域，即当有用性高且安全性低时该怎么办，反之亦然。 他们利用这个集成的方法显然需要做一些工作，即使我发现这是一项了不起的技术创新。

下图显示了这一点。 我主要包含它，因为它是我几个月来在 ML 中看到的最酷的可视化之一！

尽管这些模型存在一些粗糙的缺陷，但我们可以预见，一家大公司会因过于谨慎而犯错。 我们还从论文中缺乏训练数据细节中看到了这一点。 这篇论文虽然有近 40 页，但缺少大量关键细节。 这是考虑到 Meta 因原始 LLaMA 中的数据而被起诉，但如果 Meta 说的是“公开可用数据”以外的其他内容，那就太好了。 如今，人工智能中的公众概念被严重滥用。 公共广场上对于信息的讨论太多，互联网上的数据也是公开的。 Meta 无法明确说明他们是否像许多闭源合作伙伴一样犯下了可疑的版权或服务条款违规行为，但 Meta 可以在数据访问和文档使用的分类法方面做得更好。

关于安全的最后一点也许我错过了。 为了安全起见，Meta 是否真的没有对其基本模型进行大量的人类和模型评估？ 我觉得这很奇怪，因为这些模型现在将成为大量微调实验的起点。 由于 RLHF 模型没有通过很多人的嗅探测试，它们几乎变得更加重要。

2、推理和Llama

在不实际操作的情况下建立直觉的最困难的事情之一是了解各种模型大小和吞吐量要求的 GPU 要求。 有很多优秀的人分享了针对不同用例的最小可行计算机。

以下是用于理解推理和微调（主要是PEFT-参数高效指令调整）的资源集合。

2.1 推理注意事项

似乎有很多路径可以在大多数 GPU 上适配 7b 或 13b 模型。 这些很快就会在 iPhone 上运行。

70b 变体有点棘手。 例如，一项讨论展示了 70b 变体在以 4 位量化加载时如何使用 36-38GB VRAM。 如果将量化加倍为 8 位 (float16)，则可以预期内存会按比例变化。 在任何单个 GPU 上使用完整的非量化模型都非常困难。

HuggingFace 对一些下游用户在文本生成推理方面的一致建议如下（不那么关注量化）：

• 对于 7B 模型，我们建议你选择“GPU [中] - 1x Nvidia A10G”。
• 对于 13B 模型，我们建议你选择“GPU [xlarge] - 1x Nvidia A100”。
• 对于 70B 模型，我们建议你选择“GPU [xxxlarge] - 8x Nvidia A100”。

另一个例子是，社区成员重写了 HuggingFace Transformers 的一部分，以便仅针对 Llama 模型提高内存效率。 可以在此处查看 ExLlama 或在此处查看其速度摘要。 结果非常快（并且支持通过 RoPE 缩放扩展上下文长度）：

llama-2 70b seq 长度 4096 的速度为 10.5~ tokens/sec。没有 oom，也尝试了 seq length 8192，没有 go oom 计时为 8 tokens/sec。 70b 原始模型的输出非常出色，是我从原始预训练模型中看到的最佳输出

2.2 微调注意事项

微调示例很快就会出现——我找到它们并不容易，但我已经看到了更多。 TRL 已经可以非常轻松地运行有监督微调，你可以在 Google Colab 上免费获得的 T4 GPU 上训练 Llama 2 7B，甚至在单个 A100 上训练 70B 模型”。 这显然是一个有偏见的 HuggingFace 观点，但它表明它是相当容易理解的。 大多数消费级 GPU 可以微调 7B 或 13B 变体。

RLHF 则不同，你需要在内存中存储更多的梯度计算。 这些数字可能会在下周陆续公布。

有关高效部署大型模型的更多信息，我喜欢 Finbarr 的这篇文章。

3、其他值得关注的事情

这里还有很多事情要介绍。 我将做一个快速部分，并期望将来听到更多关于这些的信息：

• Open LLM 排行榜的顶部仍然是从 LLaMAv1 微调的模型，这是为什么？ 有一些内部讨论，这似乎是由于排行榜上没有足够的评估类型（很快就会改变）的结果：很容易在评估集（或接近它的东西）上微调模型并获得更高的分数 表现。 顶级模型不仅注重结果，而且处于边缘状态。 随着时间的推移，这种情况将会变得平滑，并且 Llama 2 上的相同数据集几乎肯定会更高。
• 工具使用出现：“Llama 2-Chat 能够仅通过语义理解工具的应用程序和 API 参数，尽管从未接受过使用工具的培训。” 正如我在 LLM 代理帖子中所写，LLM-for-tools 非常有前途。 为了看到这个爆炸，我们需要一些标准环境来进行评估。
• 提示问题：我和其他一些人想知道提示是否是导致回避行为的问题。 其中，我想知道系统提示是否在论文中，是否在A.3.7人工评估中列出。 我会密切关注这个故事，因为 LLaMA 1 评估的不一致结果有很大的推动作用。
• 尽管 Yann Lecun 在帖子中暗示他们可能会发布代码，但代码微调的机会还是非常高的。 本着这种精神，我希望看到特定领域的奖励模型，例如代码。 Llama 2 的代码还不够好，我的大多数观众都无法使用它来代替 ChatGPT，但竞争压力是存在的，而且这种情况会很快改变。
• Miles 有一个很好的主题，讨论了 Meta 围绕模型的开放版本缺乏直接表达价值观的问题。 如果Meta直接说出他们的观点就更好了，这样我们就不用去推测了。 不管怎样，下一个问题是：如何通过微调来解除安全限制？ Llama 2 正在开辟一个新的研究方向。
• 许可证太搞笑了 它指出，发布时活跃用户超过 7 亿的公司不能将该模型用于商业用途。 真是太小气了 另外，我喜欢这种模式对苹果的帮助（就像他们集成了稳定扩散），但这两家公司如果尝试的话就不可能成为朋友。 能够与AppleGPT在同一周进行是非常光荣的。
  

4、附加技术说明

这些是我从原来的文章中得到的，但在过去几天里，通过与 声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop博客】