2025-12-28 23:28:46

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

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

2025-09-10 21:45:26

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

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

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

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

2025-06-04 23:35:51

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

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

2025-03-18 20:07:31

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. 支持会话级别的缓存

2024-10-27 22:32:37

引子

在某些工作负载中，随着时间的推移，内存的使用会逐渐增长，直到 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 请求来了，还回空闲表中，如果空的多了，就还给操作系统

2024-08-25 14:41:07

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

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

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

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

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