引子

刚入门大模型的时候，由于线性代数、概率论和信息论等数学知识的短板，很容易迷失在诸多术语中：logprob（对数概率）、likelihood（似然）、NLL（Negative Log Likelihood，负对数似然）、cross entropy（交叉熵）、perplexity（困惑度）。它们常常出现在论文和文档的各种角落里，但都像点赞之交的朋友，频见其名，不解其意。

后来某天，在慢慢的补过一些最基础的数学知识后，在公司相关的上下文浸淫足够久后，终于在某次和 ChatGPT 的聊天中发现：上面一组概念本质上是同一件事的不同面向的侧写。从概率论的门摸进去叫 NLL，从信息论的门踏进去叫交叉熵，从 PyTorch 的门看进去叫 F.cross_entropy——殊途同归，本质上都是在试图刻画"模型当前输出离预期还有多远"。

“横看成岭侧成峰”，在大模型这种高维上下文的领域中，这种盲人摸象的感觉所在多有。不过我们这种三维生物，也只能靠长久的浸淫，才能靠着不同领域知识的交叉验证，才会突然有一天顿悟——嗷，原来这是同一座山。

本文想做的，就是想聊聊大模型领域中最基础概念——交叉熵这个损失函数的“一花各表”。

我是 2024 年初到一家大模型公司工作，之前一直在数据库、存储等 infra 行业工作，因此有些很粗浅的转行认知。很久没有在 b 站做分享了，这次靠直播强制开机，回答了大家一些问题，稍稍弥合一点信息差。本文对直播中提到的一些点的稍微规整一点的总结，并将一些我觉得不错的资料附在最后。

b 站直播：https://www.bilibili.com/video/BV1uckJBkEto

有明显的自我意识以来，从没有像今年这样和世界、和自己发生如此激烈的冲撞，但结果很神奇——反倒更加平和了。很多下意识的反应、很多习以为常的做法，向内挖时，竟然都能摸出如此久远的强化链路。正如史铁生说的——那颗年少时射出的子弹，在长到这个年纪的时候，正中眉心。

于是，不管是被迫地还是自发地，今年都开始难以避免地向内生长——如格物致知一般去观察和追溯自己细微的情绪变化源头，见天地、见众生，终是为了见自己。虽然以前惯性还会持续一段时间，但觉察的开始，便是塑造另外轨迹的种子。

Princeton COS 597R “Deep Dive into Large Language Models” 是普林斯顿大学的一门研究生课程，系统探讨了大语言模型原理、准备和训练、架构演进及其在多模态、对齐、工具使用等前沿方向中的应用与一些问题。注意，该课程侧重概念的理解上，而非工程的实现上。
我之前是在分布式系统和数据库内核方向，但这两年转到一家大模型公司做数据。本笔记主要是我对课程论文的梳理和精要。不同的是，我会结合在工作中解决实际问题的一些体感，给出一点转行人不同视角的思考，希望能对同样想从工程入门算法的同学一点帮助。

本文来自我的付费专栏《系统日知录》，欢迎订阅查看更多大模型解析文章，文末有优惠券信息。

本篇主要关注大模型的奠基之作——Transformer。

首先要明确问题域，Transformer 试图解决的是序列建问题，最主要的代表就是语言建模和机器翻译。其次，需要知道前驱方法—— RNN（循环神经网络）和 CNN（卷积神经网络）存在的一些问题，才能知道 Transformer 的创新之处。最后，Transformer 的解决要点的在于“多头注意力机制”和“位置编码”。

随着云基础设施的不断成熟，新兴的公司为了快速实现业务目标，一般都会让基础设施上云。而在云上进行开发与传统上直接使用物理机开发其实有很大不同。云上更强调共享和弹性，此外，规模变大又会带来隔离性。这些改变也倒逼我们在进行开发时做出一些改变。在云上进行大规模数据处理，我主要有一些 spark 和 ray 的经验，使用的语言主要是 python；从这些技术栈出发，谈谈一些还算行之有效开发实践。

使用 ray 在云上进行大规模数据处理，一个基本的思路是：构建最小可并行单元，进行功能测试和性能测试，然后再利用 ray.data （比如 map，map_batches ）进行 scale。使用 spark 时，会稍有不同；相比 ray，spark 虽然灵活性稍差一些，但抽象封装更好，可以从数据集整体的角度来考虑数据处理，spark 会通过你设置的分区数和并行度，自动地扩展和容错。

streamlit 是一款可以快速进行简单网页开发的 Python 库，其 slogan 是：

A faster way to build and share data apps

即“一种快速构建、分享数据应用的方法”。其在机器学习、数据科学，甚至当今大模型领域非常流行。其优点非常突出：

1. 使用上述领域开发者最喜欢的语言：Python。不用写前端，pip 安装就能用。
2. 简单几行代码就能快速攒出一个数据可视化、打标等小工具的网页。
3. 还支持丰富的第三方组件扩展，比如社区开发的 code_editor 。

当然，如果你还想要低延迟、高并发、深度定制等需求，那对不起，这是 streamlit 被 tradeoff 出去的那一部分。但对于面向内部少数人使用的小工具来说，streamlit 简直是利器。可以说这个小生态位被它卡的太好了，所以能在 2022 年以 8 亿美金卖给 Snowflake。

本文我们就一块来看看其基本设计哲学和一些简单实践。

设计哲学

其基本设计哲学可以概括为：

1. 用后端语言写前端
2. 收到新事件会重新构建
3. 支持会话级别的缓存

引子

在某些工作负载中，随着时间的推移，内存的使用会逐渐增长，直到 OOM。后面发现是内存碎片问题，而将系统默认的内存分配器（glibc malloc）换成 jemalloc ，能有效控制内存的增长上界。

为了解其背后原理，便找来 jemalloc 最初的论文：A Scalable Concurrent malloc(3) Implementation for FreeBSD 来一探究竟。当然，相比 2006 年论文发表时，当前的 jemalloc 可能已经发生了很大改变，因此本文只对当时论文内容负责。更多 jemalloc 机制，大家可以去其 github 仓库查看文档和源码。

背景

在探讨论文的主要思路之前，我们先简单回顾下内存分配器（memory allocator）的作用和边界。简言之：

1. 对下，向操作系统申请大块内存（使用 sbrk、mmap 等系统调用）
2. 对上，处理应用层的各种尺寸的内存申请请求（malloc(size)），并在应用层“表示”不用（free）后进行释放

往小了说，分配器的功能非常简单：分配和释放（malloc 和 free）。想象中，实现也应该很简单，只需利用一个表来记录所有已使用内存和未分配内存（ a bit of bookkeeping），然后：

1. malloc 请求来了，先去空闲表中找，不够的话就问操作系统要
2. free 请求来了，还回空闲表中，如果空的多了，就还给操作系统

Snowflake 由甲骨文的两位员工在 2012 年出来创办，一开始就瞄准云原生数仓，因此架构设计（在当时看来）非常“激进”。超前的视野带来超额的回报，Snowflake 在 2020 年正式上市，市值一度高达 700 亿美金，创造了史上规模最大的软件 IPO 记录。

本文我们综合两篇论文：The Snowflake Elastic Data Warehouse 和 Building An Elastic Query Engine on Disaggregated Storage 来大致聊聊其架构设计。

本文来自我的专栏《系统日知录》，如果你觉得文章还不错，欢迎订阅支持我。

这篇文章我早就想写了，但上次在看论文时卡住了——论文信息太多，地毯式的阅读，很快就淹没在细节中，当时也只看了三分之二，就搁置了。上周（20240707）在文章 Spark：如何在云上做缩容时提到了存算分离的 snowflake ，有读者要求写下，于是便重新捡起来。

相比上次 push 的方式，本次采用 pull 的方式：即不是被动的读论文，而是先思考，如果让我设计这么一个云原生数仓，我要怎么设计，会有哪些问题等等。带着这些问题，我再去从论文中找答案，发现效率一下高了很多，也便让这篇文章没有再次难产。

缘于某个播客提了一嘴，便找来书在通勤时听了。这版是傅雷翻在 1939 年译的版本，有一股淡淡的老式白话风。小书不长，几天便听完。我喜欢在走路的时候听东西，所听入耳、所观入眼，哲人的凝言练语、街头的风物百态，总能在心里发生奇妙的化学反应，偶在三伏天都一激灵。

最近心绪颇为起伏，在上下班踱步听这本书时，数次给我宽慰平和，书中指出的快乐和不快乐之因，都命中了我的某些缺点和特点，因此听完觉得还是要写点东西。

罗素《幸福之路》

人类从狩猎时代进入农耕时代后，虽获得了生活的相对安稳，却也失掉了向外的探索和冒险。到工业时代，城市化加剧，进一步脱离了自然的“蓝领白领”亦是如此。只有少数的企业家才仍然保持着丛林式的生活方式。

选择安稳意味着有大量的“烦闷”（Boredom）需要排遣。但多数人过度的将注意力集中在自己的身上，比如畏罪狂（纠结于行为不符合少时的成见或社会的规训）、自溺狂（过度期待外界称许的虚荣）、自大狂（过度的权力欲望），则使得这种烦闷愈加在幻想中野蛮式的生长，直至占满人们的内心。

ray.data 是基于 ray core 的一层封装。依赖 ray.data，用户用简单的代码，就可以实现数据大规模的异构处理（主要指同时使用 CPU 和 GPU）。一句话总结：很简单好用，同时也有很多坑。
在 上一篇中，我们从用户接口出发，浅浅地梳理了一下 ray.data 的主要接口。本篇，我们从宏观的角度，大概串一下 ray.data 的基本原理。之后，我们再用几篇，结合代码细节和使用经验，探讨下比较重要的几块内容：执行调度、数据格式和避坑指南。
本文来自我的专栏《系统日知录》，如果你觉得文章还不错，欢迎订阅支持我。

概述

从高层来理解，ray.data 的一次数据处理任务大致可以分成前后相继的三阶段：

1. 数据加载：将数据从系统外部读到 ray 的 Object Store 中 （如 read_parquet）
2. 数据变换：利用各种算子在 Object Store 中对数据进行变换（如 map/filter/repartition）
3. 数据写回：将 Object Store 中的数据写回外部存储（如 write_parquet）

由于对各种矩阵运算物理意义的理解总是跟不上，因此尽管多年多次尝试入门机器学习，却总是被拒之门外。偶然间同事推荐了 MIT 那门经典的线性代数公开课，听了几节，煞是过瘾，之前紧闭的大门竟有打开一丝的感觉。

因此，本系列会在每篇文章分享一些课程中有意思的点。为了避免晦涩，每章会尽可能去上下文、保持简短，请放心食用。也因此，本系列会牺牲一些精确性，且并无体系化，仅仅旨在唤起你一丢丢兴趣。注：例子都由 KimiChat 生成。

这是我在很早之前遇到的一个题，很有意思，所以到现在仍然记得。题意借用了 TCP 的上下文，要求实现 TCP 中一个“顺序组装”的关键逻辑：

1. 对于 TCP 层来说，IP 层的 packet 是乱序的收到。
2. 对于应用层来说，TCP 层交付的是顺序的数据。

这个题有意思的点在于，借用了 TCP 的上下文之后，就可以先和候选人讨论一些 TCP 的基础知识，然后话锋一转，引出这道题。这样既可以考察一些基础知识，也可以考察工程代码能力。

题目

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

struct Packet {
    size_t offset;
    size_t length;
    uint8_t *data;
};

// 实现一个“顺序交付”语义
class TCP {
  // 应用层调用：按顺序读取不超过 count 的字节数到 buf 中，并返回实际读到的字节数
  size_t read(void *buf, size_t count);
  // TCP 层回调：得到一些随机顺序的 IP 层封包
  void receive(Packet* p);
  // TCP 层回调：数据发完，连接关闭
  void finish();
};