用于 LLM 的公开的数值数据

本文涉及的产品
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 用于 LLM 的公开的数值数据

用于 LLM 的公开的数值数据

这个存储库包含了用于训练 OpenAI 的大型语言模型的一部分公开的数值数据。这些数据已经被处理成符合 OpenAI 的数据管道格式。此外,我们还提供了一个 Python 脚本,用于将原始的表格数据转换成适合训练的格式。

数据来源

这些数据来自于以下公开的来源:

数据格式

数据被存储为 JSON 文件,每个 JSON 文件包括一个名为 data 的数组。数组中的每个元素都是一个包含两个键的字典:

  • input: 用于训练模型的输入文本。输入文本通常包括一个问题或描述。
  • output: 模型的预期输出。这通常是一个简短的回答或数值。
{
    "data": [
        {
            "input": "What was the average price of a gallon of regular gasoline in the United States in 2019?",
            "output": "2.60"
        },
        {
            "input": "What is the distance from Earth to Mars in kilometers?",
            "output": "225,000,000"
        },
        ...
    ]
}

如何使用这些数据

要使用这些数据训练您的模型,您需要将它们处理成适合您的训练框架的格式。我们提供了一个 Python 脚本,用于将原始的表格数据转换成适合训练的格式。您可以参考这个脚本来了解如何处理数据,以及如何根据您的需求修改它。

LLM 开发者应知的数字

在谷歌,传奇工程师杰夫·迪恩(Jeff Dean)整理了一份名为“每位工程师都应该知道的数字”的文档。对于大型语言模型(LLM)开发者来说,拥有一套可用于粗略计算的类似数字非常有用。在这里,我们分享 Anyscale 使用的一些特定数字,说明这些数字的重要性以及如何将其用于您的优势。

内容列表

  • CPU 时钟周期
  • 内存访问延迟
  • 磁盘延迟
  • 网络延迟
  • FLOPs 和 AI 训练

CPU 时钟周期

  • 一个 CPU 时钟周期大约需要 0.4 纳秒(ns)。

CPU 时钟周期是衡量 CPU 性能的关键指标。了解 CPU 时钟周期的长度有助于在设计和优化算法时更好地理解性能瓶颈。

内存访问延迟

  • 从 L1 缓存中读取数据大约需要 0.5 纳秒。
  • 从 L2 缓存中读取数据大约需要 7 纳秒。
  • 从 L3 缓存中读取数据大约需要 100 纳秒。
  • 从主内存中读取数据大约需要 100 纳秒。

当 CPU 需要访问数据时,它首先检查各级缓存(L1、L2 和 L3)。如果所需数据不在缓存中,CPU 则需要访问主内存。了解访问各级缓存和主内存的延迟对于识别和优化算法性能至关重要。

磁盘延迟

  • 从固态硬盘(SSD)读取数据大约需要 20-100 微秒(µs)。
  • 从传统硬盘驱动器(HDD)读取数据大约需要 1-10 毫秒(ms)。

磁盘延迟是指从磁盘中读取或写入数据所需的时间。了解磁盘延迟有助于在处理大量数据时了解存储系统的性能瓶颈。

网络延迟

  • 同一数据中心内的往返延迟(RTT)大约为 0.5 毫秒。
  • 跨洲际光缆的往返延迟大约为 150 毫秒。

网络延迟是指数据在网络中传输所需的时间。了解网络延迟有助于在开发分布式系统和优化网络通信时预测性能。

FLOPs 和 AI 训练

  • 一个 NVIDIA A100 GPU(英伟达A100图形处理器)可以提供每秒约 312 万亿次浮点运算(TFLOPs)。
  • 训练 GPT-3 模型需要约 3.14 * 10^23 次浮点运算。

FLOPs(每秒浮点运算次数)是衡量处理器性能的一个常用指标,特别是在 AI 训练和高性能计算领域。了解处理器的 FLOPs 数量和训练模型所需的 FLOPs 数量有助于评估训练时间和硬件需求。

许可

这些数据遵循 CC0 1.0 协议。您可以自由地复制、修改、发布和使用这些数据,无需获取许可或支付费用。然而,我们鼓励您在使用这些数据时,引用这个存储库以便其他人可以找到这些资源。

项目地址

https://github.com/ray-project/llm-numbers

目录
相关文章
|
1月前
|
人工智能 安全 机器人
LLM对齐数据全自动合成!UW华人博士生提出Magpie方法,Macbook Air即可运行
【8月更文挑战第11天】在AI领域,大型语言模型(LLM)的行为对齐一直是个挑战。华盛顿大学研究人员提出名为Magpie的新方法,能自动高效生成高质量指令数据,减少人工干预,提升LLM的对齐效果。通过输入模板,Magpie利用已对齐LLM生成能力自动生成指令数据,仅需少量GPU资源即可创建大规模数据集。实验显示,使用Magpie数据集微调的模型性能媲美传统监督方法。尽管如此,Magpie仍需进一步优化以生成特定领域指令并确保数据安全性。[论文](https://arxiv.org/abs/2406.08464)
135 60
|
19天前
|
数据采集 自然语言处理 测试技术
CMU&清华新作:让LLM自己合成数据来学习,特定任务性能同样大幅提升
【8月更文挑战第24天】近期研究提出SELF-GUIDE,一种创新方法,旨在通过大型语言模型(LLMs)自动生成特定任务数据并用于自我微调,以克服其在特定任务上的性能局限。SELF-GUIDE分为三个阶段:数据合成、模型微调及性能评估。通过向目标LLM提供适当提示生成高质量合成数据,并用于微调以提升特定任务表现。实验证明,该方法在Natural Instructions V2等多个基准测试中显著提升了分类与生成任务性能。SELF-GUIDE不仅有效提高性能,还具备高数据效率,减少对外部数据依赖。然而,生成数据质量受限于LLM能力,且并非适用于所有任务。
31 4
|
3月前
|
机器学习/深度学习 人工智能 算法
Scaling Law触礁数据墙?Epoch AI发文预测LLM到2028年耗尽所有文本数据
【6月更文挑战第23天】Epoch AI警告,大语言模型(LLM)可能在2026-2032年间面临“数据墙”,因人类生成文本数据耗尽。论文探讨LLM扩展限制,提出合成数据、迁移学习和提高数据效率作为应对策略,但也引发数据隐私和伦理问题。研究敦促平衡模型发展与数据资源管理[[1](https://arxiv.org/abs/2211.04325)]。
57 6
|
4月前
|
机器学习/深度学习 自然语言处理 算法
【大模型】关于减轻 LLM 训练数据和算法中偏差的研究
【5月更文挑战第6天】【大模型】关于减轻 LLM 训练数据和算法中偏差的研究
|
存储 SQL Cloud Native
LlamaIndex 联合创始人下场揭秘:如何使用私有数据提升 LLM 的能力?
如何使用私有数据最大化发挥 LLM 的能力?LlamaIndex 可以解决这一问题。LlamaIndex 是一个简单、灵活、集中的接口,可用于连接外部数据和 LLMs。
438 0
|
1月前
|
人工智能 自然语言处理
公理训练让LLM学会因果推理:6700万参数模型比肩万亿参数级GPT-4
【8月更文挑战第3天】新论文提出“公理训练”法,使仅有6700万参数的语言模型掌握因果推理,性能媲美万亿级GPT-4。研究通过大量合成数据示例教授模型因果公理,实现有效推理并泛化至复杂图结构。尽管面临合成数据需求大及复杂关系处理限制,此法仍为语言模型的因果理解开辟新途径。[链接: https://arxiv.org/pdf/2407.07612]
38 1
|
2月前
|
人工智能 JSON 自然语言处理
国内大模型LLM选择以及主流大模型快速使用教程[GLM4/Qwen/Baichuan/Coze/Kimi]
【7月更文挑战第7天】国内大模型LLM选择以及主流大模型快速使用教程[GLM4/Qwen/Baichuan/Coze/Kimi]
151 10
国内大模型LLM选择以及主流大模型快速使用教程[GLM4/Qwen/Baichuan/Coze/Kimi]
|
2月前
|
自然语言处理 API 开发工具
初识langchain:LLM大模型+Langchain实战[qwen2.1、GLM-4]+Prompt工程
【7月更文挑战第6天】初识langchain:LLM大模型+Langchain实战[qwen2.1、GLM-4]+Prompt工程
初识langchain:LLM大模型+Langchain实战[qwen2.1、GLM-4]+Prompt工程
|
2月前
|
搜索推荐 人工智能
人工智能LLM问题之大模型特殊能力如何解决
人工智能LLM问题之大模型特殊能力如何解决
|
2月前
|
存储 人工智能 前端开发
基于LLM大模型Agent的适用范围和困境
基于LLM大模型Agent的适用范围和困境