LogoCookLLM文档
LogoCookLLM文档
首页CookLLM

原理精讲

词元化
Tokenization 基础BPE 算法详解GPT 系列 TokenizerBPE 训练工程化
模型架构
Transformer LM
从 token ids 到 logitsEmbedding 与 LM Head
Attention 机制
Self-Attention 到 GQAAttention Sink
位置编码
位置编码基础RoPE 数学推导RoPE 代码实现长度外推
GPU 编程基础
GPU 架构基础张量布局Triton 入门:向量加法
FlashAttention
Flash Attention 原理详解从朴素实现到 Auto-TuningBlock Pointer 与多维支持Causal Masking 优化Grouped Query Attention反向传播实现
分布式训练
数据并行ZeRO 优化器全分片数据并行张量并行流水线并行多维混合并行
推理优化
KV CacheContinuous BatchingPagedAttention

动手训练

概述
预训练
预训练数据Tokenizer 训练模型架构数据流水线训练循环监控与验证
X (Twitter)
基础知识词元化

BPE 训练工程化

会员专享

从玩具数据到真实语料:内存优化、并行预分词、增量更新与时间-空间权衡

在权益中心获取代码

真实数据训练

在第二章,我们实现了基础 BPE 算法;在第三章,我们学习了 GPT 系列的预分词机制。现在,让我们把它们结合起来,在真实数据上训练一个 tokenizer。

从玩具数据换成真实语料,变的不只是数据量。第二章那份实现每合并一次就重新统计一遍全部字节对,在几百字节的示例上察觉不到,放到 2GB 语料上就是灾难:训练 32K 词表需要约 3 万次合并,每次都全量扫描,总代价是 O(V×N)O(V \times N)O(V×N)。按 2GB 语料估算,单机跑完要以天计。

更麻烦的是内存。把整个语料按 word 展开成频次表,Python 的 dict 和 tuple 开销会让 2GB 文本膨胀到十几 GB 常驻内存,很多机器直接 OOM,根本走不到慢的那一步。

所以这一章的重点不是"再写一遍 BPE",而是把一份能跑的实现改造成能在真实规模下跑完的实现。我们会先建 baseline、让它在真实数据上暴露问题,再逐项优化:

  1. 构建 baseline:结合第二章的 BPE 算法和第三章的预分词,支持文件输入
  2. 在 TinyStories 上测试:2GB 数据,32K 词表,看看 baseline 能否胜任
  3. 分析瓶颈:当数据量增大时,哪里会出问题?
  4. 逐步优化:分块预分词、增量更新、低频剪枝、检查点机制

登录以继续阅读

这是一篇付费内容,请登录您的账户以访问完整内容。

GPT 系列 Tokenizer

GPT-2/GPT-4 的 Tokenization 方案,Regex 预处理与 tiktoken 库

Architecture(模型架构)

从 Transformer LM 主干到 Attention、RoPE 与现代组件,理解语言模型架构

目录

真实数据训练
1.1 Baseline 实现
数据结构变化
频率加权
Baseline 训练函数
1.2 Baseline 性能测试
1.3 问题引出:为什么会 OOM?
内存瓶颈分析
解决思路
2.1 预分词与 chunk 边界
为什么需要分块
边界选择:不能随意切
并行预分词
2.2 低频序列剪枝
为什么可以剪枝?
剪枝策略
剪枝的影响
2.3 增量更新 vs 全量重算
问题:merge 后怎么更新统计?
方案一:全量重算
方案二:增量更新
索引结构的作用
增量更新的步骤
数据变化示例
如何选择?
2.4 检查点机制
2.5 性能对比
关键优化效果
总结