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 实现，代码里反复出现这种写法： 1rearrange(X, "... seq (heads d) -> ... heads seq d", heads=self.num_heads) 第一次看到时，它甚至比 x.view(...).transpose(...) 更加陌生——至少后者你知道它是 PyTorch 原生 API。

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

起因 # 上一篇讨论了模型调度中的 Performance Constraint：一个模型放到 GPU 上以后，到底跑多快？ 这一篇讨论另一个最基础的约束：Capacity Constraint。

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

起因 # 最近在学 Stanford CS336（Language Modeling from Scratch），做 tokenizer 作业时，第一次在测试代码里见到了 pytest.mark.xfail。 具体是这段： 1@pytest.mark.xfail( 2 reason="Tokenizer.encode is expected to take more memory than allotted (1MB)." 3) 4def test_encode_memory_usage(): 5 """ 6 We expect this test to fail, since Tokenizer.encode is not expected to be memory efficient. 7 """ 8 tokenizer = get_tokenizer_from_vocab_merges_path( 9 vocab_path=VOCAB_PATH, 10 merges_path=MERGES_PATH, 11 ) 12 with open(FIXTURES_PATH / "tinystories_sample_5M.txt") as f: 13 contents = f.read() 14 _ = _encode(tokenizer, contents) 我当时第一反应是困惑：既然作者明确知道 encode 会超过 1MB，为什么不直接写成 assert memory > 1MB？或者干脆删掉？为什么要提交一个「预期会失败」的测试？