CS336

最近在系统学习 Search 和 Information Retrieval 的知识。在看倒排索引（Inverted Index）的时候，我越看越觉得这个结构非常眼熟。直到我想起前段时间写 CS336 作业里 BPE（Byte-Pair Encoding）分词算法的优化逻辑，我才突然意识到：原来这些看似完全不同领域的系统，底层其实都在共享同一种 pattern。

起因 # 最近在继续 CS336 和 MIT 6.S191。 之前那篇写了 BPE tokenizer——从训练到编解码，关注的是 raw text 怎么变成 token，token 怎么映射成 token ID。做完之后，对这条链路的前半段算是搞清楚了：

推理任务能放下，为什么训练任务放不下 # 上一篇讨论了模型调度中的 Capacity Constraint：一组模型到底能不能同时放进一张 GPU。

起因 # 这是 CS336 系列的又一篇。 之前那篇讨论了 FLOPs 到 Latency 之间的鸿沟：FLOPs 相同的两个 GEMM，latency 可能差几倍甚至十几倍。那篇文章的核心结论是 FLOPs 是 workload metric，不是 performance metric，并且引入了 Arithmetic Intensity 和 Roofline Model 作为分析工具。

起因 # 最近在做 CS336（Language Modeling from Scratch）的 Transformer 实现，代码里反复出现这种写法：

最近在做 Stanford CS336（Language Modeling from Scratch）的 Assignment 1，实现了一个 BPE Tokenizer。最初的 trainer 跑 TinyStories 要约 8 分钟，改完后降到约 36 秒。 耗时主要花在 merge 循环里。要判断哪些工作可以省，得先弄清每次 merge 改变了哪些统计量。下面先交代 BPE 的表示和合并规则，再回到这段实现。

起因 # 上一篇讨论了模型调度中的 Performance Constraint：一个模型放到 GPU 上以后，到底跑多快？

起因 # 最近在做 CS336（Language Modeling from Scratch）的 resource accounting 作业，里面要求逐个列出 Transformer forward pass 中所有的 matmul，然后按 \(2MKN\) 计算 FLOPs。

起因 # 最近在学 Stanford CS336（Language Modeling from Scratch），做 tokenizer 作业时，第一次在测试代码里见到了 pytest.mark.xfail。