nanoGPT OpenWebText 数据管线拆解801 万篇网页如何变成 90 亿个 token【免费下载链接】nanoGPTThe simplest, fastest repository for training/finetuning medium-sized GPTs.项目地址: https://gitcode.com/GitHub_Trending/na/nanoGPT8,013,769 篇网页变成 9,035,582,198 个 token却只占约 17GB。nanoGPT 的 OpenWebText 管线把整份语料压成 train.bin 与 val.bin 两个文件——90 亿 token 如何缩到 2 字节一个训练又怎么用 memmap 零拷贝读这个大文件为什么需要这条 nanoGPT OpenWebText 数据管线OpenWebText 是 GPT-2 论文所用 WebText 语料的社区复刻版。OpenAI 从未公开原始数据社区用爬取加过滤的流水线拼出约 800 万篇网页文档脚本注释给出的总数是 8,013,769 篇作为最接近的公开替代品。上游来源就是 Hugging Face datasets 生态里的 openwebtextload_dataset一次拉取后缓存在本地磁盘。在 nanoGPT 里这份语料承担两个角色。其一是从零训练默认配置 config/train_gpt2.py 用它从头训练 GPT-2124M目标是把验证损失压到约 2.85其二是基线评测eval_gpt2.py 系列配置直接加载 OpenAI 官方权重在同一份数据的 val 集上打分README 基线表里 gpt2 124M 的 train/val 约 3.11/3.12。说白了它既是GPT-2 复现训练数据也是衡量官方 checkpoint 的标尺。这两个 .bin 文件缺位时代价很直接train.py 的 get_batch 按 data/openwebtext/ 相对路径去读 train.bin 与 val.bin从零训练和基线评测两条链路都会在第一步卡死。换个类比这条管线像做饭前的备菜——把食材切好、称重、装进统一容器厨房GPU 训练循环不在乎食材来自哪只认袋子上写着 uint16 整数、能按把抓。跳过备菜直接端上 800 万篇原始文本训练每次取数据都会耗在解析上而不是矩阵乘法上。管线全景四步把网页变成二进制prepare.py 的主流程一句话概括load_dataset 下载缓存 → train_test_split 切出小验证集 → tiktoken 按 GPT-2 BPE 分词成整数 → np.memmap 顺序落盘。没有数据库没有序列化框架产出就是两个裸字节文件。下面四步各回答三个问题做了什么、关键参数是什么、为什么这么选。第一步 下载缓存800 万文档从哪来它调用load_dataset(openwebtext)拉取语料默认只有 train 一个 split。关键参数是num_proc_load_dataset默认 8控制下载加载阶段的多进程数。为什么这么选原始数据没有现成的验证集后续切分只能自己来脚本注释提示这一阶段的较优进程数还受网络带宽约束通常大于 1 更好所以应与分词阶段的进程数分开调。附带代价是 Hugging Face 缓存占用约 54GB脚本注释但重复运行不用重新下载。第二步 切分验证集为什么只取 0.05%用train_test_split从 train 里切一小片参数是test_size0.0005、seed2357、shuffleTrue随后把 test 改名 val。源码注释记录了结果train 8,009,762 篇val 4,007 篇。为什么比例这么小验证集只需足够稳定地估计损失4 千篇对应约 440 万 token 完全够用留多了反而浪费训练数据。为什么先 shuffle 再切、还锁死随机数种子为了让任何人在任何机器上跑这个脚本得到同一份划分、同一批 .bin结果可以对账。第三步 GPT-2 BPE 分词50256 是什么两个 split 的文本都过 tiktoken 的 gpt2 编码三个细节决定了数据最终形态。用encode_ordinary而不是常见的encode前者忽略特殊 token原始文本被纯 BPE 编成整数序列。每篇文档编码后追加一个 eot_tokenGPT-2 BPE 中为 50256长流里的文档边界全靠它分隔。这里有个细节源码注释自己留了个疑问——名叫 end of text 的 token 实际是追加而不是前置这是作者留给读者做消融实验的开放点。再往后map 调用以 num_proc8 并行分词remove_columns[text]在分词后立刻丢弃原文只留 ids 与 len 两列省缓存。直接后果所有 token id 的最大值只有 50256源码原话 enc.max_token_value 50256 2**162 字节恰好装得下——这是下一步 uint16 二进制存储的前提。第四步 memmap 落盘90 亿整数怎么不爆内存对每个 split先用 uint64 精度把所有文档长度求和得到总长度9,035,582,198 这个数字就是这么算出来的再用np.memmap以 w 模式建文件把整份文件映射进地址空间。写入切成 1024 个连续分片每片np.concatenate拼成一整块再写入对应区间最后arr.flush()强制落盘。为什么不一口气读进内存90 亿 token 一次放不下memmap 把写文件变成写映射内存由操作系统管页面换入换出。为什么按 1024 批源码注释写得很直白批量拼起来一起写磁盘吞吐更高。产出的是一条连续的 token id 流——无头部、无 padding、无元数据这就是 train.bin 格式约定的全部。三个值得留意的工程决策决策一一个 token 用 uint16 存而不是 uint32。动机GPT-2 BPE 的最大 token 值 50256 落在 uint16 上限 65536 以内恰好装得下。对下游的影响train.bin 是 17GB 而不是 34GB 起步训练端读出来 astype 成 int64 即可全程没有任何格式解析。决策二get_batch 每次调用都重建 np.memmap而不是持有全局对象。动机源码注释指向 numpy memmap 长迭代中内存持续占用的经典问题。对下游的影响600,000 轮全量训练不泄漏内存代价是每批多一次映射相对 GPU 耗时可以忽略这也是 17GB 大文件按需零拷贝读法能长期稳定的前提。决策三随机种子固定 2357先 shuffle 再切分。动机让数据划分本身可复现。对下游的影响任何人产出的 .bin 都对得上训练损失曲线才有复现二字可言。产出物一览train.bin 的格式约定文件大小token 数dtypetrain.bin~17GB9,035,582,198uint16val.bin~8.5MB4,434,897uint16两个文件都是单条连续 token id 流文档之间靠 50256 分隔裸字节存储没有头部与 padding。正因为格式这么裸任何语言用 memmap/mmap 按相同 dtype 都能直接映射读取。最小验证方式在 data/openwebtext/ 目录下import numpy as np m np.memmap(train.bin, dtypenp.uint16, moder) print(len(m)) # 9035582198 print(m[:32])跑通它需要多久、占多少盘✅ 装依赖pip install numpy tiktoken datasets tqdm若接着跑训练再按 README 补 torch、transformers、wandb 等✅ 执行python data/openwebtext/prepare.pytrain.bin 与 val.bin 生成在脚本同目录预期耗时仓库未给预处理阶段的固定耗时实际取决于网络带宽与 CPU 核数下游 8×A100 全量训练约 4 天README 口径磁盘预算~54GB HF 缓存 17GB train.bin 8.5MB val.bin合计按 75GB 预留进程数建议num_proc 默认 8源码注释建议取 CPU 核数的一半左右下载阶段单独调训练启动可选torchrun --standalone --nproc_per_node8 train.py config/train_gpt2.py600,000 轮按配置注释合计约 300B token踩坑速查进程数直接拉满 CPU 核数反而更慢 → 取核数的一半左右源码注释原话是 ~cores//2下载与分词共用同一组进程数 → 分开调下载侧还受网络带宽约束分词侧只看 CPU长训练内存持续上涨 → 别把同一个 memmap 对象握到底train.py 每批都重建磁盘中途写爆 → 54GB 缓存与 17GB train.bin 并存先查剩余空间再开跑想做 EOT 位置消融 → 源码注释已标注 eot 该前置还是追加是开放问题改了 process() 后要重跑 prepare.py 重新生成 .bin90 亿个 2 字节整数最终是两个文件。下一步可以换 train.py 里的 dataset 指向自己的 .bin、调小 block_size 做快速实验或者先跑一遍 eval_gpt2.py 把 3.11 的基线坐实。【免费下载链接】nanoGPTThe simplest, fastest repository for training/finetuning medium-sized GPTs.项目地址: https://gitcode.com/GitHub_Trending/na/nanoGPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考