OLMo 数据集构建指南从原始文本到 MemMap 训练数据的完整流程【免费下载链接】OLMoModeling, training, eval, and inference code for OLMo项目地址: https://gitcode.com/GitHub_Trending/ol/OLMo预训练语料通常是一堆分散的.json.gz分片文件散落、格式不一、体积动辄数 TB。直接拿这种原始文本喂给训练循环I/O 会成为头号瓶颈——每个 epoch 都要反复解压、解码 JSON内存里塞不下全部数据随机抽样更是无从谈起。OLMo 的做法是把文本在训练之前一次性烧成二进制用固定令牌器把每篇文档编码成整数序列再连续写入 NumPy 内存映射MemMapmemory-mapped文件。训练时不再解压、不再解析只按字节区间从磁盘抓取令牌数据准备与训练彻底解耦。数据在流水线里经历哪几种形态形态输入输出作用原始文本压缩包内的 JSON Lines 分片每行一个带text字段的文档承载真实语料来源可以是 C4 等公开数据集令牌序列文档字符串整数 ID 列表含句末 EOS 标记把任意文本翻译成词表内的编号供模型直接消费MemMap 二进制令牌序列.npy分片如part-000-00000.npy固定宽度连续存储支持随机读、可跨多个文件拼接三种形态各自只干一件事。原始文本负责有什么语料令牌序列负责怎么数MemMap 负责怎么放。链路里任何一环出错都会在训练时以难以定位的方式暴露。数据准备的关键步骤原始文本该按什么格式准备脚本约定每个输入都是 gz 压缩的 JSON Lines 文件每行一个 JSON 对象其中text字段存放单篇文档。解码用的是 msgspec 而不是标准库 json——实测快近 5 倍对大规模数据这是实打实的提速。空白文档会在读取时直接跳过不需要预先清洗。文件按目录递归收集后打乱顺序再分配目的很直接让各个并行进程拿到的负载尽量均衡避免某个进程早早跑完、其他进程还在啃大文件。令牌器选择要注意什么令牌器 ID 决定整条链路的词表。默认值allenai/eleuther-ai-gpt-neox-20b-pii-special是 OLMo 自己的 PII 变体仓库里对应olmo_data/tokenizers/下的 JSON 文件。这里有个硬约束准备数据时用的令牌器必须和训练配置里的tokenizer.identifier完全一致。词表一旦错位训练读到的每个 ID 都是错的而且不会报错只会让模型学出垃圾。编码时会给每篇文档加上特殊标记句末的 EOS 令牌不是装饰——后面的文档长度统计和重复校验都依赖它。另外令牌器对象无法跨进程序列化所以每个并行工作进程都会独立加载一份这是脚本内部已经处理好的细节不需要使用者操心。MemMap 文件如何生成核心脚本是scripts/prepare_memmap_dataset.py入口函数fill_memmap负责单个输入文件到.npy的转换流式解码、编码、写入当前文件写满就自动截断并按五位数编号开新文件xxx_00000.npy、xxx_00001.npy……每写 1 万篇文档主动 flush 一次以稳定进程文件关闭时还会把实际未写满的空间裁掉避免留下 1GB 的空占位。几个关键参数--max-tokens单个.npy的令牌上限默认 512Muint16 存储下正好约 1GB。-j并行进程数实际取 min(指定值, CPU 核数, 文件数)。--sample-rate以固定随机种子按概率丢弃文档用于快速试跑小语料。--dtype元素宽度默认 uint16它必须与词表大小匹配。一个提醒该脚本开头已打印弃用警告正式生产建议改用 Allen AI Dolma 工具包的令牌化模块思路完全一致。训练配置里该写哪些路径接入训练出奇地简单。YAML 里只需要data.paths列出所有.npy文件chunk_size会自动等于model.max_sequence_length——也就是每个训练样本的长度不需要单独配置。读取走get_bytes_range支持本地路径和 S3 远程路径文件多少个都没压力。data.paths和data.datasets二选一前者是扁平文件列表后者按数据源标签分组并给每个样本带上来源元数据方便按来源统计学习进度。质量校验脏数据如何被拦下来重复内容过滤。网页语料里难免有点击点击点击……这类病态重复。MemMapDataset在配置了instance_filter后会扫描每个块内的周期性序列周期长度落在repetition_min_period到repetition_max_period默认 1 到 13之间、且重复次数达到repetition_max_count默认 32的块会被标记为无效。注意它是标记而不是删除——数据文件保持不动损失计算时跳过这些块这样过滤规则改了也不用重新准备数据。令牌数与文档数双向核对。脚本的--validate模式会重新令牌化全部原始文本再逐文件读回.npy原始令牌总数减去文件中令牌总数应为 0原始文档数减去文件中 EOS 计数应为 0同时校验每个 ID 都在词表范围内。它验证的不是大概对而是逐令牌级别的精确一致任何采样遗漏或截断错误都会被断言直接拦下。实用工作流从零跑通一次数据准备准备输入。得到一组.json.gz。仓库自带test_fixtures/c4-sample.01.json.gz等小样本可以先拿它们验证整条链路。生成 MemMap 文件。运行python scripts/prepare_memmap_dataset.py test_fixtures/*.json.gz \ -o /tmp/olmo-memmap --validate --ack-deprecated -j 4-o是输出目录--validate做上述逐令牌核对--ack-deprecated用来跳过弃用提示的交互确认缺了它脚本会停下来等你按 y。写训练配置。最小数据段如下data: paths: - /tmp/olmo-memmap/*.npy num_workers: 8 pin_memory: true instance_filter: repetition_max_count: 32端到端冒烟。用test_fixtures/train_tiny.yaml这类小模型配置跑几百步确认数据通路无误后再放大规模。参数选型建议令牌器与训练配置严格对齐是第一优先级建议把令牌器 ID 随数据集一起归档换机器重建环境时不会拿错。--max-tokens默认 512M约 1GB对多数场景够用对象存储场景可以适当放大以减少请求数但受单机临时磁盘限制不宜盲目调大。--dtype词表小于 65536 时保持 uint16确实需要 uint32 时训练侧memmap_dtype必须同步修改否则读取会直接解析出错。-j进程数上限取 CPU 核数与输入文件数的较小值只有几个大文件时堆再多进程也白搭考虑--paths-per-worker把多个文件绑给同一进程。--validate首次生产准备务必开启代价是多一遍令牌化后续若数据源不变可依赖重复过滤在训练期持续兜底。最后一条容易被忽略MemMapDataset 按固定 chunk 切块块边界会直接跨文档不会自动补 EOS。文档边界信息完全依赖准备阶段写入的 EOS 令牌一旦某个来源的编码漏掉了句末标记按 EOS 统计文档长度的逻辑就会失真。把编码时加特殊标记当成硬性步骤而不是可选项。【免费下载链接】OLMoModeling, training, eval, and inference code for OLMo项目地址: https://gitcode.com/GitHub_Trending/ol/OLMo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OLMo 数据集构建指南：从原始文本到 MemMap 训练数据的完整流程
OLMo 数据集构建指南从原始文本到 MemMap 训练数据的完整流程【免费下载链接】OLMoModeling, training, eval, and inference code for OLMo项目地址: https://gitcode.com/GitHub_Trending/ol/OLMo预训练语料通常是一堆分散的.json.gz分片文件散落、格式不一、体积动辄数 TB。直接拿这种原始文本喂给训练循环I/O 会成为头号瓶颈——每个 epoch 都要反复解压、解码 JSON内存里塞不下全部数据随机抽样更是无从谈起。OLMo 的做法是把文本在训练之前一次性烧成二进制用固定令牌器把每篇文档编码成整数序列再连续写入 NumPy 内存映射MemMapmemory-mapped文件。训练时不再解压、不再解析只按字节区间从磁盘抓取令牌数据准备与训练彻底解耦。数据在流水线里经历哪几种形态形态输入输出作用原始文本压缩包内的 JSON Lines 分片每行一个带text字段的文档承载真实语料来源可以是 C4 等公开数据集令牌序列文档字符串整数 ID 列表含句末 EOS 标记把任意文本翻译成词表内的编号供模型直接消费MemMap 二进制令牌序列.npy分片如part-000-00000.npy固定宽度连续存储支持随机读、可跨多个文件拼接三种形态各自只干一件事。原始文本负责有什么语料令牌序列负责怎么数MemMap 负责怎么放。链路里任何一环出错都会在训练时以难以定位的方式暴露。数据准备的关键步骤原始文本该按什么格式准备脚本约定每个输入都是 gz 压缩的 JSON Lines 文件每行一个 JSON 对象其中text字段存放单篇文档。解码用的是 msgspec 而不是标准库 json——实测快近 5 倍对大规模数据这是实打实的提速。空白文档会在读取时直接跳过不需要预先清洗。文件按目录递归收集后打乱顺序再分配目的很直接让各个并行进程拿到的负载尽量均衡避免某个进程早早跑完、其他进程还在啃大文件。令牌器选择要注意什么令牌器 ID 决定整条链路的词表。默认值allenai/eleuther-ai-gpt-neox-20b-pii-special是 OLMo 自己的 PII 变体仓库里对应olmo_data/tokenizers/下的 JSON 文件。这里有个硬约束准备数据时用的令牌器必须和训练配置里的tokenizer.identifier完全一致。词表一旦错位训练读到的每个 ID 都是错的而且不会报错只会让模型学出垃圾。编码时会给每篇文档加上特殊标记句末的 EOS 令牌不是装饰——后面的文档长度统计和重复校验都依赖它。另外令牌器对象无法跨进程序列化所以每个并行工作进程都会独立加载一份这是脚本内部已经处理好的细节不需要使用者操心。MemMap 文件如何生成核心脚本是scripts/prepare_memmap_dataset.py入口函数fill_memmap负责单个输入文件到.npy的转换流式解码、编码、写入当前文件写满就自动截断并按五位数编号开新文件xxx_00000.npy、xxx_00001.npy……每写 1 万篇文档主动 flush 一次以稳定进程文件关闭时还会把实际未写满的空间裁掉避免留下 1GB 的空占位。几个关键参数--max-tokens单个.npy的令牌上限默认 512Muint16 存储下正好约 1GB。-j并行进程数实际取 min(指定值, CPU 核数, 文件数)。--sample-rate以固定随机种子按概率丢弃文档用于快速试跑小语料。--dtype元素宽度默认 uint16它必须与词表大小匹配。一个提醒该脚本开头已打印弃用警告正式生产建议改用 Allen AI Dolma 工具包的令牌化模块思路完全一致。训练配置里该写哪些路径接入训练出奇地简单。YAML 里只需要data.paths列出所有.npy文件chunk_size会自动等于model.max_sequence_length——也就是每个训练样本的长度不需要单独配置。读取走get_bytes_range支持本地路径和 S3 远程路径文件多少个都没压力。data.paths和data.datasets二选一前者是扁平文件列表后者按数据源标签分组并给每个样本带上来源元数据方便按来源统计学习进度。质量校验脏数据如何被拦下来重复内容过滤。网页语料里难免有点击点击点击……这类病态重复。MemMapDataset在配置了instance_filter后会扫描每个块内的周期性序列周期长度落在repetition_min_period到repetition_max_period默认 1 到 13之间、且重复次数达到repetition_max_count默认 32的块会被标记为无效。注意它是标记而不是删除——数据文件保持不动损失计算时跳过这些块这样过滤规则改了也不用重新准备数据。令牌数与文档数双向核对。脚本的--validate模式会重新令牌化全部原始文本再逐文件读回.npy原始令牌总数减去文件中令牌总数应为 0原始文档数减去文件中 EOS 计数应为 0同时校验每个 ID 都在词表范围内。它验证的不是大概对而是逐令牌级别的精确一致任何采样遗漏或截断错误都会被断言直接拦下。实用工作流从零跑通一次数据准备准备输入。得到一组.json.gz。仓库自带test_fixtures/c4-sample.01.json.gz等小样本可以先拿它们验证整条链路。生成 MemMap 文件。运行python scripts/prepare_memmap_dataset.py test_fixtures/*.json.gz \ -o /tmp/olmo-memmap --validate --ack-deprecated -j 4-o是输出目录--validate做上述逐令牌核对--ack-deprecated用来跳过弃用提示的交互确认缺了它脚本会停下来等你按 y。写训练配置。最小数据段如下data: paths: - /tmp/olmo-memmap/*.npy num_workers: 8 pin_memory: true instance_filter: repetition_max_count: 32端到端冒烟。用test_fixtures/train_tiny.yaml这类小模型配置跑几百步确认数据通路无误后再放大规模。参数选型建议令牌器与训练配置严格对齐是第一优先级建议把令牌器 ID 随数据集一起归档换机器重建环境时不会拿错。--max-tokens默认 512M约 1GB对多数场景够用对象存储场景可以适当放大以减少请求数但受单机临时磁盘限制不宜盲目调大。--dtype词表小于 65536 时保持 uint16确实需要 uint32 时训练侧memmap_dtype必须同步修改否则读取会直接解析出错。-j进程数上限取 CPU 核数与输入文件数的较小值只有几个大文件时堆再多进程也白搭考虑--paths-per-worker把多个文件绑给同一进程。--validate首次生产准备务必开启代价是多一遍令牌化后续若数据源不变可依赖重复过滤在训练期持续兜底。最后一条容易被忽略MemMapDataset 按固定 chunk 切块块边界会直接跨文档不会自动补 EOS。文档边界信息完全依赖准备阶段写入的 EOS 令牌一旦某个来源的编码漏掉了句末标记按 EOS 统计文档长度的逻辑就会失真。把编码时加特殊标记当成硬性步骤而不是可选项。【免费下载链接】OLMoModeling, training, eval, and inference code for OLMo项目地址: https://gitcode.com/GitHub_Trending/ol/OLMo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考