原文链接: https://zhuanlan.zhihu.com/p/2013987217081644893

DeepEP Issue：https://github.com/deepseek-ai/DeepEP/issues/589

背景

前几天同事在跑实验，发现某些场景下 EP 通信方式用 DeepEP 会导致梯度变成 nan，通信方式改成 allgather 就好了。组里大哥们一起尝试复现了一下，发现了几点：

• 可以把网络规模缩小的很小，单机就可以复现
• 开启 CUDA_LAUNCH_BLOCKING=1 后问题消失
• 有时候添加打印或者同步，问题又不复现
• EP 越小越容易复现

顿时觉得头皮发麻，很显然是一种复杂的时序问题，不清楚是 megatron 的问题还是 DeepEP 的问题，也可能是在某种神秘场景，联合作用下导致的 bug。而 DeepEP 我又不怎么精通，感觉 debug 会非常困难。

vibe debug 流水账

本周三临睡前，准备试一下用 cc (Claude Code) 去定位这个问题，因为我有个稳定的复现脚本（agent 可以直接观察他是不是 nan，信号很明确），各种源码也都有（agent 能拿到所有的上下文），理论上非常适合 vibe。把复现脚本、megatron 代码、DeepEP 代码都给 claude 准备好，不过我们还没什么项目 skills，cc 的领域知识只能从源码获取，只告诉 cc 这个脚本有 bug，去研究一下为什么。yolo 一开直接睡觉。

周四感觉 vibe 情况不是非常乐观，cc 给出了几个错误的猜想都被我否定了，就开始自暴自弃，说什么问题很难定位不出来。我准备换个思路，让他先定界是 megatron 的问题还是 DeepEP 的问题，尝试把这个网络的 DeepEP 相关业务逻辑抠出来，脱离 megatron 进行复现。

周四周五公司有活动，大部分时间都在坐飞机/吃饭/喝酒/吹牛逼/听别人吹牛逼，只能每隔几个小时去看一下 cc 的 debug 情况，我和同事戏称为“收菜”。但实际上 cc 的定位进度还是堪忧，脱离 megatron 也没法复现，而且特别容易放弃，只能反复让他尝试。

复现到了周五晚上也没什么进展，准备再换个思路，不尝试脱离 megatron 复现，而是让他简化 megatron，一步步的把没用的组件剥离出去，yolo 一开继续睡觉。

周六一早，发现很牛逼，直接和我说复现出来了，我自己一跑发现确实如此，脚本的现象是这样的：

• torch 开启 deterministic + DeepEP 有 nan
• torch 关闭 deterministic + DeepEP 没有 nan
• torch 开启 deterministic + DeepEP + CUDA_LAUNCH_BLOCKING 没有 nan

需要 deterministic + DeepEP + cpu 异步同时满足，非常神秘啊。yolo 一开，继续让 cc 找一下问题根因。

周六吃喝玩乐一天，晚上回家发现已经搞定了，根因如下：

• 同事为了对精度，开了 torch.use_deterministic_algorithms(True)
• 开启确定性之后，torch 会自动把新分配出来的显存写成 nan，参考 torch.utils.deterministic.fill_uninitialized_memory
• 而 DeepEP 的业务逻辑是这样的：

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

// Step 1: stream_wait synchronizes comm_stream with compute_stream
//         comm_stream will wait for everything *currently* enqueued on compute_stream
stream_wait(comm_stream, compute_stream);

// Step 2: torch::empty() allocates tensors AFTER the sync point
//         When fill_uninitialized_memory=True, this launches a NaN-fill kernel
//         on compute_stream — which comm_stream does NOT wait for
auto recv_x = torch::empty({num_recv_tokens, hidden}, x.options());

// Step 3: communication kernel runs on comm_stream, writing to recv_x
intranode::combine(..., recv_x.data_ptr(), ..., comm_stream, ...);

• DeepEP 分配一块 empty 当输出，本来只有通信流在写数据，现在主流也会往里面写 nan，导致两个写操作并发了，制造了时序问题。这个问题的复现频率与 EP 执行速度、算子下发速度都有关系，所以看起来很复杂。
• 本质是 torch 框架在 deterministic 的场景下破坏了约定，在 empty 的时候有写操作。但很难说是 bug 还是 feature。

思考

claude debug 成功之后，我是非常震撼的，因为这不是一个很简单的 bug，涉及到很多功能的交叉。各位 ai infra 程序员可以扪心自问一下，直接面对这个问题，大家要花几个工作日能定位出来，定位过程中心态会不会出现问题。但现在，我只是在娱乐过程中随便 prompt 了几下，claude 就全搞定了。

当然整个 vibe debug 过程没有这么顺利，如果公司没有活动，是正常的工作日，我可能对 claude 也没有这么多的耐心。这说明我们还是需要 agent 工程、需要 skills。但模型的智能已经够了，我觉得我不算很菜的程序员，但 opus 4.6 比我要强。

如何把智能充分发挥出来只是个时间问题，tipping point 已经来临了。

原文链接: https://zhuanlan.zhihu.com/p/2011494527026894039

本文主要参考资料：

One Kernel for All Your GPUs

https://github.com/HazyResearch/ThunderKittens

部分写作 powered by Kimi K2.5，学习过程 powered by Claude opus 4.6。

Ulysses 的基本思路

Transformer 里除了 Attention 都是 element-wise 的操作，这些部分切序列长度 N 很方便。但 Attention 切 N 比较麻烦，切 head 才顺手。

Ulysses 的做法是在进出 Attention 的时候做"切 N"到"切 head"的转换，用 all-to-all 通信来做这个分布式转置。

实际 PyTorch 代码里，Ulysses 需要在通信前后做数据重排：

1
2
3
4
5
6
7
8
9
10

# 通信前（切的是 N， HEAD 是完整的）
input_t = input.view(B, N_per_rank, world_size, H_per_rank, D) \
               .permute(2, 1, 0, 3, 4).contiguous()   # 一次完整拷贝

# 通信
torch.distributed.all_to_all_single(output_t, input_t)

# 通信后 （切的是 HEAD，N 是完整的）
output.copy_(output_t.permute(2, 0, 1, 3, 4)
                      .reshape(B, N, H_per_rank, D))   # 又一次拷贝

all to all 要求输入必须连续，那两个 contiguous() 导致 all to all 的带宽根本没法跑满。用 https://github.com/HazyResearch/ThunderKittens/blob/main/kernels/parallel/all_to_all/benchmark.py 在 8p H20 上面跑，NCCL 的 Ulysses 方案只能跑到 155 GB/s，而不考虑拷贝，纯 all to all 能跑到 285 GB/s。

ParallelKittens

ParallelKittens: Simple and Fast Multi-GPU AI Kernels

ParallelKittens 是 ThunderKittens 的多 GPU 扩展版本，也是 ThunderKittens 2.0 的一部分。通过 ParallelKittens 做 Ulysses 能在 8p H20 上做到 344 GB/s 的带宽。

核心思路

PK 的做法很直接：kernel 内部通过坐标计算直接确定每个 tile 该去哪，不需要显式的数据重排。

1
2
3
4
5
6

每个 GPU 跑同一个 kernel，每个 block 1 个线程，处理 1 个 tile：

GPU_i 的 block_j:
  1. TMA load:  本 GPU HBM → SMEM（硬件 DMA）
  2. 索引计算:  确定目标 GPU 和目标位置
  3. TMA store: SMEM → 目标 GPU HBM（通过 NVLink）

kernel 也没几行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

template <int SCATTER_AXIS, int GATHER_AXIS>
__device__ inline void kernel(const globals &G) {
    static_assert(0 <= SCATTER_AXIS && SCATTER_AXIS < 4 && 0 <= GATHER_AXIS && GATHER_AXIS < 4, 
        "Scatter and gather axes must be 0, 1, 2, or 3");
    static_assert(SCATTER_AXIS != GATHER_AXIS, "Scatter and gather axes must be different");

    extern __shared__ int __shm[];
    tma_swizzle_allocator allocator((int*)&__shm[0]);
    globals::shared_tile &tile = allocator.allocate<globals::shared_tile>();

    // Calculate the input indices
    int task_idx = blockIdx.x;
    int batch_idx = task_idx / (G.input.depth() * (G.input.rows() / globals::ROW_BLOCK_SIZE) * (G.input.cols() / globals::COL_BLOCK_SIZE));
    task_idx %= (G.input.depth() * (G.input.rows() / globals::ROW_BLOCK_SIZE) * (G.input.cols() / globals::COL_BLOCK_SIZE));
    int depth_idx = task_idx / (G.input.rows() / globals::ROW_BLOCK_SIZE * (G.input.cols() / globals::COL_BLOCK_SIZE));
    task_idx %= (G.input.rows() / globals::ROW_BLOCK_SIZE * (G.input.cols() / globals::COL_BLOCK_SIZE));
    int row_block_idx = task_idx / (G.input.cols() / globals::COL_BLOCK_SIZE);
    task_idx %= (G.input.cols() / globals::COL_BLOCK_SIZE);
    int col_block_idx = task_idx;

    // Load input data (assume a single-threaded block)
    __shared__ semaphore arrived;
    init_semaphore(arrived, 0, 1);
    tma::expect_bytes(arrived, sizeof(tile));
    tma::load_async(tile, G.input[G.dev_idx], {batch_idx, depth_idx, row_block_idx, col_block_idx}, arrived);

    // Calculate the output indices
    int dst_dev_idx;

    if constexpr (SCATTER_AXIS == 0) {
        dst_dev_idx = batch_idx / G.output.batch();
        batch_idx %= G.output.batch();
    } else if constexpr (SCATTER_AXIS == 1) {
        dst_dev_idx = depth_idx / G.output.depth();
        depth_idx %= G.output.depth();
    } else if constexpr (SCATTER_AXIS == 2) {
        dst_dev_idx = row_block_idx / (G.output.rows() / globals::ROW_BLOCK_SIZE);
        row_block_idx %= (G.output.rows() / globals::ROW_BLOCK_SIZE);
    } else {
        dst_dev_idx = col_block_idx / (G.output.cols() / globals::COL_BLOCK_SIZE);
        col_block_idx %= (G.output.cols() / globals::COL_BLOCK_SIZE);
    }

    if constexpr (GATHER_AXIS == 0) {
        batch_idx += G.input.batch() * G.dev_idx;
    } else if constexpr (GATHER_AXIS == 1) {
        depth_idx += G.input.depth() * G.dev_idx;
    } else if constexpr (GATHER_AXIS == 2) {
        row_block_idx += (G.input.rows() / globals::ROW_BLOCK_SIZE) * G.dev_idx;
    } else {
        col_block_idx += (G.input.cols() / globals::COL_BLOCK_SIZE) * G.dev_idx;
    }

    // Wait for inputs to arrive and store data to destination device
    wait(arrived, 0);
    tma::store_async(G.output[dst_dev_idx], tile, 
        {batch_idx, depth_idx, row_block_idx, col_block_idx});
}

怎么做到的

1. 跨 GPU 内存访问（IPC + VMM）

要让 GPU 直接写别的 GPU 显存，先用 CUDA 的 Virtual Memory Management API：

1
2
3

1. VMM 分配 (cuMemCreate + cuMemMap + cuMemSetAccess)
2. 交换 IPC handle（Unix Domain Socket）
3. 映射远端内存（cuMemImportFromShareableHandle + cuMemMap）

最后每个 GPU 都能通过本地指针访问其他 7 个 GPU 的显存。博客里面有个图：

2. PGL（Parallel Global Layout）

TK 搞了个 pgl 结构管理跨 GPU tensor：

1
2
3
4
5

template<GL, NUM_DEVICES=8>
struct pgl {
    GL gls[NUM_DEVICES];  // 8 个 GL，每个包含 raw_ptr 和 TMA 描述符
};

G.output[dst_dev_idx] 返回目标 GPU 的 GL，其 TMA 描述符指向远端显存。

3. Kernel 逻辑

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

__device__ void kernel(const globals &G) {
    // 从 blockIdx.x 解码 4D 坐标
    (batch_idx, depth_idx, row_block_idx, col_block_idx) ← blockIdx.x

    // TMA load: 本 GPU HBM → SMEM
    tma::load_async(tile, G.input[G.dev_idx], coords, semaphore);

    // 计算目标 GPU 和目标坐标
    dst_dev_idx = ...;
    output_coords = ...;

    // TMA store 到远端
    wait(semaphore, 0);
    tma::store_async(G.output[dst_dev_idx], tile, output_coords);
}

关键就是索引重映射替代了显式 permute。kernel 里算好坐标，数据直接搬到目标位置。

4. TMA（Tensor Memory Accelerator）

用的 PTX 指令：

1
2
3
4
5

# Load: HBM → SMEM（异步，硬件 DMA）
cp.async.bulk.tensor.4d.shared::cluster.global.tile.mbarrier::complete_tx::bytes

# Store: SMEM → HBM（异步，可写远端）
cp.async.bulk.tensor.5d.global.shared::cta.tile.bulk_group

TMA 是硬件 DMA，不占用 SM 计算资源，1 个线程就能驱动。目标地址是 IPC 映射的远端指针时，TMA 自动走 NVLink 传输。

一些限制

主要限制在于跨 GPU 内存访问，只能在一个 NVLink 域内通信。

还有一点是对于超节点 （例如 GB200 NVL72， 一个容器只能拿到四个卡），没法通过单机进程通信交换 handle。不过 NV 对此早有考虑 ，CUDA 12.4+ 有 CU_MEM_HANDLE_TYPE_FABRIC，配合 nvidia-imex daemon 可以跨节点交换 handle。只是 TK 还没支持这个场景，能拿到超节点的大哥可以试试看效果。

原文链接: https://zhuanlan.zhihu.com/p/1919814348047623458

深度学习框架中的虚拟显存

CUDA和AscendCL都支持虚拟内存管理。两个硬件的API也基本是对齐的，以AscendCL为例，大概需要这么几个API：

CUDA和AscendCL的对应关系如下图：

核心就是解耦了虚拟内存和实际的物理内存，实际的物理内存被搞成handle，可以map到提前预留好的虚拟地址，也可以从现成的虚拟地址上面unmap掉。有了这些接口，就可以很方便的实现碎片整理等功能。

具体而言，例如这样的场景，我们需要申请一个连续的2G的显存，但是显存池中只有两块不连续的1G的显存，在没有虚拟内存这一套接口的时候，只能抛出来OOM（Out Of Memory）这样的报错。

但有了虚拟内存这一套接口，我们就可以让两个1G的虚拟地址对应的handle从这两个虚拟地址上面unmap掉，然后map到一个连续的2G的虚拟地址。

这就是碎片整理，而且不需要框架层做类似传统碎片整理那样的搬运操作。torch里面的expandable_segments，mindspore的VMM，都是这个原理。缺点在于unmap和map这个过程有点慢，而且需要做流同步，需要打断device和host的流水。

除了碎片整理，其实虚拟内存在显存管理上还有很多帮助。例如现代的深度学习框架，为了方便多个进程使用同一张卡，显存都是慢慢拓展出来的，那最后的显存就会是这种形式：

很显然，不论是cudaMalloc还是aclrtMalloc，都没法保证多次malloc出来的显存是连续的，这就会因为显存的不连续导致碎片。

而虚拟内存就能做到，提前预留好一大块物理地址，不断的申请handle map到当前的物理地址上，这样不管怎么拓展显存，都是一个连续的大块显存。

当然如果有多池子的显存优化（大小显存池、param单独分池子），虚拟显存也可以做到用多少占用多少，不需要提前约定好每个池子占用的大小。而且经过一次碎片整理，不同池子的显存互相复用也会比较方便。（只要不在乎性能）

对于深度学习框架来说，虚拟内存比较好用的点就是这些。其实虚拟内存还有个很大的好处是他可以在虚拟地址（或者叫上层感知到的地址）完全不变的情况下，在底层做一些特殊操作。例如Graph Engine和CUDA Graph这种硬件底层的图调度对于地址使用都有些不可变的约束，如果能够结合虚拟内存，就能玩一些花活。但因为map/unmap这种操作确实代价有点大，一直没有想到一个比较好的整活场景。

vllm sleep mode

最近研究了一下vllm sleep mode的实现，发现他通过虚拟内存的特性，在底层深度学习框架不感知的情况下完成了kvcache/weights的卸载/加载功能。

sleep mode主要是在强化学习共部署的场景下，做完推理之后，得把推理的显存都释放出来给训练用。在没有这个功能的时候，适配强化学习共部署，想卸载kvcache，都是通过objgraph等方式找到所有挂kvcache的python对象，然后一个个把持有kvcache的python对象都干掉，让python对象析构去触发框架显存的释放。跑推理之前还要一个个恢复回来，维护成本很高，每次升级vllm版本还要重新来。

vllm实现sleep mode这个功能，首先是在csrc/cumem_allocator.cpp里面实现了一个简易的显存申请释放的接口，但都是通过虚拟内存的方式进行的。也就是说cumem_allocator里面每申请一块显存，都会包含虚拟地址和底层对应的handle两个信息。这些信息会通过callback记录到python层。

然后在sleep的时候，就申请一个cpu的tensor，把显存里面的内容都拷贝过去。虚拟地址不变，但是虚拟地址下面的handle都unmap并且释放掉。

同理wake up的时候，就申请新的handle map到虚拟地址上，然后再把cpu里面的内容拷贝上来。

那怎么让torch的显存申请走到cumem_allocator里面呢？vllm的大佬利用了torch外挂显存池的能力，如果在cumem定义的context中，就会自动走到对应cumem_allocator的显存申请流程：

这样只要做好context管理就行了，总比管理python对象的引用关系方便很多：

下面来分析，为什么这个东西非常的巧妙。先考虑我如果想实现这个功能会怎么搞？首先做好python对象的管理，然后基于python对象析构去触发显存释放是比较恶心的，也很容易出bug；还有一种方式是能不能把需要释放的tensor都调用一下to('cpu')？但pytorch的tensor to语义不是inplace的。如果想要释放显存需要类似a=a.to('cpu')这样的书写方式，那就和第一种做好python对象的管理一模一样了，没有解决根本的问题。

那我们自己管理显存呢？虽然torch做了外挂显存池的功能，但malloc和free接口都是torch框架来触发的。tensor.data_ptr()可以获取tensor的物理地址，但外部不能修改他。这也很好理解，如果外部能随便改data_ptr，框架的显存管理要怎么做呢？

这时候，虚拟内存的好处就来了。刚刚说虚拟内存还有个很大的好处是他可以在虚拟地址（或者叫上层感知到的地址）完全不变的情况下，在底层做一些特殊操作。vllm sleep mode通过在torch框架完全不感知的情况下，完成了对handle的卸载/加载。torch还以为自己的显存管理的好好的，殊不知在底层已经被偷偷的unmap掉了。vllm社区的大佬水平确实高，这个方案完美结合了torch/虚拟内存的底层各种机制，做到了vllm和torch的解耦。

当然，这套方案也不是完全没缺点，一个主要的缺点就是，因为是对torch框架的隐瞒，torch只要在sleep之后做了任何对这些tensor的读写操作，都会直接触发底层的ERROR，因为虚拟地址并没有映射到对应的物理地址。python的灵活性这么高，这个报错或者校验在vllm层是没法做的。

一个可能的完美解决方案是让torch框架提供inplace to/原地offload这样的语义，这样也不需要做任何python对象的管理，推理框架适配起来也很轻松，报错也能做的非常清晰。问题就是这个语义可能对框架的冲击比较大，对于成图更是重量级：）

从代码注释上看，这个方案也踩中了torch框架的一堆bug，蛮不容易的。比较令人在意的是这个：

用这个就不能用torch的expandable_segments了，而强化学习场景的load/offload又特别频繁，碎片会比较严重，长稳训练可能会出现一些问题。

原文链接: https://zhuanlan.zhihu.com/p/27172237359

工作需要，最近在入门强化学习。这个笔记面向工程老哥们，知道老哥们看不懂数学（因为我就不懂），忽略了大量推导，意会为主。其中可能有些理解错误，望大家多多指正。

LLM中的强化学习定义

• 智能体（Agent）: 经过预训练和SFT的LLM，可以对外界的输入做出回应，有一定的智能。
• 环境（Environment）: 其实是整个物理世界。如果是写算法题的话那就是leetcode平台，如果是RLHF的话，就是人类本身。
• 状态（State）: 环境的状态，这个东西在LLM RL里面有点模糊，不像游戏AI那么清晰；可以认为LLM之前的所有输出作为环境的状态吗？
• 动作（Action) : 对于LLM来说，就是decode过程中输出的每一个token。
• 奖励（Reward）: 就是环境的反馈，比如人类喜不喜欢这个回答或者生成的代码能不能通过leetcode的评测，这里是搞头比较大的地方。

强化学习的基础做法

基础的强化学习分成两个角色，actor \(\pi\) 和critic \(V_{\pi}\) 。其中actor代表的就是agent，基于环境的状态和奖励能够做出决策；critic类似教师，基于当前的环境状态和actor的水平，判断一下这个状态的价值。有一点很关键，critic是『因材施教』的，critic的输出一定是针对当前的actor而言的。

既然有两个概念，根据二进制，就有三种对应的做法：

1. 只有critic的实体。如果critic能学的很好的话，很明显，actor只需要看看他的每一个决策critic的反应是什么，选critic反应最好的决策就行（假设action是离散的）。这个方法就叫做value-based，比较典型的是Q-learning。

2. 只有actor的实体。人教人教不会，事教人一下就会。有时候不需要critic，actor只需要和环境做互动，从环境拿反馈就行。这种方法叫做policy-based，就是一般的policy gradient方法。

3. 两个实体都有，两个模型可以互相迭代。critic的学习可能是有偏的，连续的action不好处理（value-based），而直接从环境拿反馈可能方差太大，训练不稳定（policy-based）。所以两个模型互相迭代的方法被广为采用，叫做actor-critic。

actor-critic

数据来源

RL是在LLM的后训练环节，数据是从actor \(\pi\) 采样出来的。因为actor就是要训练的LLM本身，所以这个过程就是给一些prompt，decode出一些回答，基于回答的反馈去更新LLM。

actor的优化

我们先用SFT来理解。如果我们把所有的输入用来做SFT，那所有样本对于LLM都是要学习的。 先写个SFT的梯度：

\[SFT_{\nabla}=\frac{1}{N}\sum_{i=1}^{n}\sum_{t=1}^{T_n-1}\nabla_{\theta}\pi_{\theta}(o_t|q,o_{<t})\]

其中 nn 代表seq数量， \(T_n\) 代表seq长度。这个就是很经典的预测next token的loss。 那强化学习里面要怎么优化actor呢？很简单，就是在每个梯度前面乘上一个reward。

\[Actor_{\nabla}=\frac{1}{N}\sum_{i=1}^{n}\sum_{t=1}^{T_n-1}R(\tau_n)\nabla_{\theta}\pi_{\theta}(o_t|q,o_{<t})\]

其中 \(R(\tau_n)\) 代表的是每个seq对应的reward，这个东西怎么算先按下不表。感性理解就是reward越大，我越希望拟合这个seq；reward是负的，就需要极力避免这个seq。 写成强化学习的符号，就是：

\[Actor_{\nabla}=\frac{1}{N}\sum_{i=1}^{n}\sum_{t=1}^{T_n-1}R(\tau_n)\nabla_{\theta}\pi_{\theta}(a_t|s_t)\]

其中 \(a_t\) 代表action， \(s_t\) 代表状态。就是基于此，我猜想LLM RL中的状态就是之前输出的token，但这个定义其实很古怪，随着交互环境的复杂，后面应该会有变化。

更加泛化一点， \(R(\tau_n)\) 可以定义为 \(A_{\pi}(s_t, a_t)\) ，因为这个奖励和actor本身、当前状态、当前动作都有关系。在很多资料中，这个也被叫做优势函数。

\[Actor_{\nabla}=\frac{1}{N}\sum_{i=1}^{n}\sum_{t=1}^{T_n-1}A_{\pi}(s_t, a_t)\nabla_{\theta}\pi_{\theta}(a_t|s_t)\]

优势函数

\(A_{\pi}(s_t, a_t)\) 怎么算？这个推导涉及到Q-learning，虽然这个推导不算难，但看完感觉工程同学根本没啥学的必要。只需要知道他是通过critic计算出来的：

\[A_{\pi}(s_t, a_t)=r_t+\gamma V_{\pi}(s_{t+1})-V_{\pi}(s_t)\]

其中 \(r_t\) 是当前步骤的反馈，一般是通过reward model计算得来； \(V_{\pi}\) 就是critic模型； \(s_{t+1}\) 是从 \(s_t\) 基于 \(a_t\) 这个东西转移过来的。这个公式其实很直观，我们想一下，怎么让actor满足crtiic的需求？当然就是找到一个 \(a_t\) ，使得转移过去的 \(s_{t+1}\) 尽可能的好。

critic的优化

接上面的逻辑，对于一个完美的 \(V_{\pi}\) ，他的递推式子就应该是（但和上面的东西结合起来有点怪异，actor需要讨好critic，但是critic又要尽量客观）：

\[V_{\pi}(s_t)=r_t+\gamma V_{\pi}(s_{t+1})\]

为什么有个 \(\gamma\) ，因为后续状态对前面的影响应该是越来越小的，这个也比较直观。 那critic的loss就天然应该是一个MSE：

\[Critic_{loss}=(r_t+\gamma V_{\pi}(s_{t+1})-V_{\pi}(s_t))^2\]

PPO

actor-critic的主要问题是，每次需要actor \(\pi\) 去做采样，然后再回头更新出新的 \(\pi^*\) ，再用 \(\pi^*\) 去采样，循环往复。这个方法叫做on-policy。

采样后要计算reward function、要计算ref model，这些都挺慢的。很容易就想到能不能采一次样，后面多迭代几轮，利用好之前的采样信息。这种方法就叫做off-policy。

重要性采样

off-policy的核心问题是，之前采样的 \(\pi\) 和训练的 \(\pi^*\) 分布是不同的，数学原理上难以保证训练的有效性。从某个分布采样的数据对另一个分布做训练，有个解决方法叫做重要性采样。数学原理很多地方都有，这里就不加赘述了，直接给出带重要性采样的更新公式，只是给之前的actor梯度加了一项：

\[Actor_{\nabla}=\frac{1}{N}\sum_{i=1}^{n}\sum_{t=1}^{T_n-1}\frac{\pi_{\theta}(a_t|s_t)}{\pi_{\theta old}(a_t|s_t)}A_{\pi}(s_t, a_t)\nabla_{\theta}\pi_{\theta}(a_t|s_t)\]

GAE

再回头看优势函数，我们之前的优势函数 \(A_{\pi}(s_t, a_t)\) 是完全依赖 \(V_{\pi}\) 的，但训练的初期 \(V_{\pi}\) 一定是非常不准的。 \(A^{GAE}_{\pi}(s_t, a_t)\) 就是平衡了 \(V_{\pi}\) 的重要性和之后所有 \(r_t\) 的重要性：

\[A^{GAE}_{\pi}(s_t, a_t)=\sum_{l=0}^{\infty}(\gamma\lambda)^l\delta_{t+l}\]

其中：

\[\delta_{t}=r_t+\gamma V_{\pi}(s_{t+1})-V_{\pi}(s_t)\]

可以很容易看出来 \(\lambda=0\) 就是原来的 \(A_{\pi}(s_t, a_t)\) 。如果 \(\lambda=1\) ，那就是 \(-V_{\pi}(s_t)+\sum_{l=0}^{\infty}\gamma^lr_{t+l}\) （可以展开几项写一写）。 \(\lambda\) 的取值代表有多少后续的 \(r_{t+l}\) 对优势函数产生了影响。

裁切设计

上面的两个内容都不难理解，结合起来，actor的梯度应该是：

\[Actor_{\nabla}=\frac{1}{N}\sum_{i=1}^{n}\sum_{t=1}^{T_n-1}\frac{\pi_{\theta}(a_t|s_t)}{\pi_{\theta old}(a_t|s_t)}A^{GAE}_{\pi}(s_t, a_t)\nabla_{\theta}\pi_{\theta}(a_t|s_t)\]

但通常来讲，PPO的loss形式都看起来很复杂，这是因为在更新的时候 \(\pi_{\theta}\) 和 \(\pi_{\theta old}\) 的差距不能太大，需要各种方式去限制两个分布的差异。效果最好的是对梯度进行裁切，如果两个分布偏差过大的话，直接加个裁切，不让他们更新的太远：

\[Actor_{\nabla}=\frac{1}{N}\sum_{i=1}^{n}\sum_{t=1}^{T_n-1}min[\frac{\pi_{\theta}(a_t|s_t)}{\pi_{\theta old}(a_t|s_t)}A^{GAE}_{\pi}(s_t, a_t), clip(\frac{\pi_{\theta}(a_t|s_t)}{\pi_{\theta old}(a_t|s_t)}, 1 - \epsilon, 1 + \epsilon)A^{GAE}_{\pi}(s_t, a_t)]\nabla_{\theta}\pi_{\theta}(a_t|s_t)\]

对于这个裁切的理解，下面的参考资料里面（李宏毅老师公开课和猛猿大神的文章）有基于折线图的很出色的解释，可以参考一下。

上面说critic是『因材施教』的，critic的输出一定是针对当前的actor而言的，所以在actor更新的过程中，critic也要跟着更新。回忆一下之前的critic loss：

\[Critic_{loss}=(r_t+\gamma V_{\pi}(s_{t+1})-V_{\pi}(s_t))^2\]

在PPO中，给这地方增加了一项：

\[Critic_{loss}=(r_t+\gamma V_{\pi}(s_{t+1})+\gamma\lambda A^{GAE}_{t+1}-V_{\pi}(s_t))^2\]

我没怎么明白为什么，可能是为了增大 \(r_t\) 的影响力。左边的 \(r_t+\gamma V_{\pi}(s_{t+1})+\gamma\lambda A^{GAE}_{t+1}\) 我们简写为 \(R_t\) ，这里 \(R_t\) 都是提前算好的，所以用的 \(V_{\pi}\) 都是 \(V_{\pi}^{old}\) 。类似的，PPO也不希望 \(V_{\pi}^{new}\) 和 \(V_{\pi}^{old}\) 离得太远，所以最后也加了个裁切：

\[Critic_{loss}=max([(V^{new}_{\pi}-R_t)^2, (clip(V^{new}_{\pi}, V^{old}_{\pi}-\epsilon, V^{old}_{\pi}+\epsilon)-R_t)^2])\]

ref model

在LLM RL中，ref model是一个有点特殊的设计，之前RL提的不怎么多。主要目的是不让actor跑的太偏，依然保留一些之前预训练获得的能力。ref model和actor的初始化权重相同，一般训练很多步再更新一下权重或者根本不更新。在计算actor loss的时候，增加一项（比如KL散度），不让ref model和actor偏离的太远。

GRPO

GRPO因为deepseek成为了现在最火爆的强化学习算法。AIQL大神的回答里有个神图：

GRPO最核心的点有两个：

1. 干掉了critic model，直接通过一条prompt rollout一堆回复来采样数据集。通过增大采样来抵消方差。

2. reward model也做了改动。对于很多问题，token level的奖励是不够合理的，DeepSeekMath引入了过程监督。DeepSeek-r1更是直接改成了rule-base。

GRPO是对PPO算法的简化。之前的PPO训练模型中有actor推理、actor训练、critic、ref、reward 5个模型（因为训练和推理需要用不同的框架来加速，策略一般也不同）。GRPO一下子把critic和reward全干掉了，大力出奇迹。其实很多人在复现GRPO的过程中表示和ref model的对齐会影响效果，去掉ref model反而出来深度思考的过程了。那是不是可以幻想一下，以后只需要actor推理、actor训练，actor就和环境做互动就行了？大道至简。

下一篇文章会分析一下当前业界比较优秀的RL框架（openrlhf/verl/chatlearn），结合代码再深入理解一下LLM RL的细节。

参考

1. B站首推！李宏毅大佬花一周讲完！2023公认最通俗易懂的【强化学习教程】小白也能信手拈来（人工智能|机器学习|深度学习|强化学习）_哔哩哔哩_bilibili

2. [2402.03300] DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models

3. 【LLM】PPO理论推导+代码实战 - 知乎

4. 【LLM】GRPO：改进PPO增强推理能力 - 知乎

5. 人人都能看懂的RL-PPO理论知识 - 知乎

6. DeepSeek的GRPO算法是什么？ - 知乎

7. GRPO简化Tricks, 性能暴涨10%, 只改一个参数? - 知乎

原文链接: https://zhuanlan.zhihu.com/p/1887098218866794901

个人学习记录。这三个东西本质的原理都差不多，就是attention怎么沿着序列维度切。

online softmax

回顾一下最初的attention：

\(O=softmax(QK^T)V\)

先不考虑融合算子，对于原始的数学公式来说就是两次matmul+一次softmax。matul是最容易优化的，因为良好的数学定义，这个东西可以横着切也可以竖着切也可以分成一小块一小块的，无论是算子优化还是做分布式切分（其实算子优化就是在device内做并行，分布式切分就是在device间做并行），都非常方便。

但是softmax就比较麻烦：

\[softmax(x_i)=\frac{e^{x_i-m}}{\sum^{N}_{j=1}e^{x_j-m}},m=\underset{1\leq i \leq N}{\max}(x_j)\]

如果用最naive的方式去算softmax，需要遍历三遍。第一次遍历求一下m，第二次遍历把分母求出来，第三次把每个元素求出来。如果基于这个计算模式去做分布式，整个的效率会特别的低。因为每次遍历都需要拿到整个N^2大小的矩阵，对于算子来说会频繁的做IO，对于分布式就是频繁的通信。

但指数函数有个很棒的性质，可以只遍历一次数据，就同时得到m和分母：

\[e^{x_j-m_{i-1}}e^{m_{i-1}-m_i}=e^{x_j-m_{i-1}+m_{i-1}-m_i}=e^{x_j-m_i}\]

通过上面的式子，不停的基于新元素，更新分母和m即可。

不仅如此，我们也基于这个性质把softmax分成两块去计算，用到的符号如下：

\(A_l\) 左边一半的softmax分子，\(A_r\) 右边一半的softmax分子，都是个向量

\(B_l\) 左边一半的softmax分母，\(B_r\) 右边一半的softmax分母，都是个数值

\(m_l\) 左边一半的最大 xx ，\(m_r\) 右边一半的最大 xx，很容易得到全局 xx 的最大值 mm

\[softmax_{全局}=\frac{A_{全局}}{B_{全局}}=\frac{[e^{m_l-m}A_l,e^{m_r-m}A_r]}{e^{m_l-m}B_l+e^{m_r-m}B_r}\]

通过这种方式，打开了softmax的并行空间。

online attention

再回头看attention的公式，实际上他的物理意义在于基于QK矩阵乘的值，对V的每一列做一下线性组合。

\[O=softmax(QK^T)V\]

把线性组合展开一下，对于O的每一行来说：

\[o=\sum_{i=1}^{N}(\frac{e^{x_i-m}}{\sum^{N}_{j=1}e^{x_j-m}} \times v_i)\]

把这一步也分成两块：

\[o_l=\frac{A_l\cdot v_l}{B_l},o_r=\frac{A_r \cdot v_r}{B_r}\]

左右两边合并的方式如下，符号含义和softmax的合并一致：

\[o=\frac{B_le^{m_l-m}o_l+B_re^{m_r-m}o_r}{B_le^{m_l-m}+B_re^{m_r-m}}\]

结合上面softmax的并行方式，整个attention的计算也可以像matmul一样做纵向的切分了。

再对着图理解一下，切Q的话，相对容易：

切KV，经过我们上面的推导，也是可以合并起来的：

RingAttention/FlashAttention正是基于上面的机制，实现了attention算子的device内并行和device间并行:

1. device间的并行可以减少N（seq长度）对于训练的限制，将训练拓展到更长的序列上去。对于RA来说，不同设备分别做一下seq切分后的attention，然后通过send/recv，在下一个卡上完成对上一个attention的合并。

2. 对于FA来说，就是利用切块去减小仿存，从而拿到融合算子的性能收益。

这里突然想到一个手撕代码题，用线段树做区间softmax/attention，想用的大哥找我交一下版权费:)

序列并行

说混合序列并行前，需要先了解一下Megatron和DeepSpeed两大巨头最开始是怎么做序列并行的。

Megatron最开始的seq并行相对来说比较简单，transformer没切tp的地方都是element wise的。所以可以把tp的allreduce改成reducescatter，直接把N分到不同的卡上去做element wise的操作。序列并行转tensor并行的时候需要allgather，tensor并行转序列并行的时候需要reducescatter。这个方法的优点就是简单，缺点就是通信量比较大，而且序列并行的通信域被TP域的限制住，拓展不了特别大。

DeepSpeed采用的方式叫做deepspeed ulysses。核心点就是除了attention之外的部分（rmsnorm、matmul）切N都比较方便，只有attention不好切N，切head比较方便。那就是在进出attention的时候做一下切N和切head的转换，这里转换的方式使用了alltoall的通信源语，就是个分布式转置：

deepspeed ulysses的优点是通信量，成比例增加序列长度和device数量的时候，可以维持一个稳定的通信量。但和megatron的方式类似，切分数量被head num限制住，没法把序列切的特别小。

混合序列并行

实际上megatron sp和deepspeed ulysses都可以叠加ring-attention，把attention做进一步细分。megatron官网给了一个tp2cp2的例子，cp和tp共用四张卡，可以发现同一个序列的attention被切到两个部分了，这里的合并就是借助ring-attention的方式：

和deepspeed ulysses的结合思路也类似，在attention部分进一步切分。这样就可以解除head num对deepspeed ulysses的约束，可以把序列进一步细分。

后面遇到其他并行优化，比如seqpp之类的，就知道attention部分是怎么切分，需要处理些什么了。当然想实现最好的性能还需要非常多的细节。

参考

DefTruth：[Attention优化][2w字] 原理篇: 从Online-Softmax到FlashAttention V1/V2/V3

朱小霖：ring attention + flash attention：超长上下文之路

方佳瑞：序列并行做大模型训练，你需要知道的六件事

猛猿：图解大模型训练系列：序列并行2，DeepSpeed Ulysses

方佳瑞：大模型训练之序列并行双雄：DeepSpeed Ulysses & Ring-Attention

猛猿：图解大模型训练系列：序列并行4，Megatron Context Parallel

DeepSpeed/blogs/deepspeed-ulysses/chinese/README.md at master · deepspeedai/DeepSpeed

USP: A Unified Sequence Parallelism Approach for Long Context Generative AI

Reducing Activation Recomputation in Large Transformer Models

Ring Attention with Blockwise Transformers for Near-Infinite Context

context_parallel package

原文链接: https://zhuanlan.zhihu.com/p/29046833667

OpenRLHF

SPMD（单程序多数据）

https://github.com/OpenRLHF/OpenRLHF/blob/main/openrlhf/cli/train_ppo.py

用SPMD做LLM RL不需要太复杂的系统设计，因为当前深度学习最广泛使用的分布式范式就是SPMD，遵循大部分算法框架的设计方式就好了。OpenRLHF SPMD ppo的系统架构很简单：

基于各种配置项初始化出对应的模型后，将这些模型传入PPOTrainer中。PPOTrainer负责整个PPO算法的控制逻辑。此时，不同的模型在同一组卡和同一组进程上按照不同的时间片运行SPMD。这些共享同一组计算资源并按时间交替使用的模型被称为colocate models。

MPMD（多程序多数据）

https://github.com/OpenRLHF/OpenRLHF/blob/main/openrlhf/cli/train_ppo_ray.py

SPMD虽然实现简单，但它要求不同的模型只能串行执行，即使没有数据依赖的模型也难以实现并发。由于强化学习涉及的模型数量较多，如果某些模型不需要占用全部计算卡，就会导致部分计算资源的闲置。此外，SPMD需要将多个模型的参数同时加载到一张计算卡上，如果不结合offload等技术，很容易引发显存OOM问题。

所以，OpenRLHF还支持使用ray进行拉起。使用ray的好处是可以通过配置placement group，让模型绑定到不同的卡上，并通过ray完成不同进程的数据交换。这里参考train_ppo_ray.py，画一下critic和actor-ref分离部署的场景示意图：

其实能很明显的看出来，OpenRLHF的ray流程基本上就是在SPMD流程上硬改过来的，并不像下面的verl一样，是基于ray的原生系统设计。有两点比较别扭：

1. PPORayActorGroup都在主进程（或者叫driver process）实例化，但是算法的控制逻辑不在主进程上，而是在Actor对应的PPORayActorGroup里面（ActorPPOTrainer）。不同的PPORayActorGroup在逻辑上不是对等的，Actor所在PPORayActorGroup需要把RL算法中的所有组件串起来。当然了，这样实现Trainer的逻辑不需要大改，只需要从SPMD的PPOTrainer继承出来一个ActorPPOTrainer就行了，仅仅是架构概念上不太符合单一职责原则，真的要去理解流程还是比较清晰易懂的。
2. colocate的模型不能放在同一个进程。参考上面的图，actor和ref共部署在相同的placement group上，但因为主体控制逻辑在ActorPPOTrainer里面，他也不知道ref是不是和他共部署，所以critic和ref都只能通过.remote的方式去调用。最后的效果就是，ref虽然和actor跑在一张卡上，但是二者不在同一个进程里面。这个设计会影响很多优化的开展，之前讲了深度学习最广泛使用的分布式范式就是SPMD，从深度学习框架到底层的device，都认为大部分场景（或者极致性能的场景）下device和process是一对一的，通信、显存资源都按照process级别去做共享。以显存为例，把用过的显存缓存下来是最基本的性能优化手段，但colocate的模型不在同一个进程上，就需要频繁的empty_cache来释放显存给卡上的另一个进程。老调重弹，对于国产芯片和框架，这种设计对架构更是巨大冲撞。

当然，好处就是系统设计的很清晰，相比verl的层层封装，OpenRLHF想动手改点东西是很简单的，算法工程师们也可以轻松理解。

OpenRLHF的简洁设计有一个很重要的前提，就是模型基本都是dp分片的（vllm里面有tp分片），训练基于FSDP或者deepspeed，分布式优化靠的都是zero系列。这种设计的好处是数据流通起来很方便，就算RL框架里面最复杂的actor推理训练权重同步，在OpenRLHF里面也只需要一个broadcast（因为vllm只会再多个TP分片）。因为都是dp分片，不同rank是完全对等的，不同模型的调度可以直接轮询。但正是这种选择，导致OpenRLHF在大集群上训练超大规模的网络很难用，只用dp是没法跑满血的deepseek v3的。

verl

verl的论文写了single controller/multi-controller、zero redundancy model resharding之类的贡献点。但我这里直接恶意揣测一下，verl最核心的动机以及设计上最漂亮的点是colocate模型的共进程，这一点对系统优化非常关键，但是不好发论文吹牛，所以包装了几个点出来发论文。

https://github.com/volcengine/verl/blob/main/verl/trainer/main_ppo.py

https://github.com/volcengine/verl/blob/main/verl/trainer/ppo/ray_trainer.py

上面OpenRLHF的ray流程最大缺点就是colocate模型没法共进程。想一下，要实现共进程这个特性，得让colocate的不同模型共享同一个ray remote实例。为了达成这个目的，并且让上层的编程接口尽量干净，verl做了巨复杂的封装，我上面画了个图，展示了层层封装之后最终的调用形态。

用户需要编写的是ActorRolloutRefWorker或CriticWorker等worker，并将这些worker传入RayPPOTrainer中。verl会自动将colocate的模型集中到一个WorkerDict中，并通过setattr为每个worker设置所需的方法，从而实现worker层面的任务分发。最终，系统会为每个worker生成一个RayWorkerGroup，这些RayWorkerGroup的对外接口与其对应的worker完全一致，但经过了多次转发。colocate的RayWorkerGroup的成员方法会转发到同一个WorkerDict中，以此实现共进程的执行机制。

此外，verl支持FSDP/Megatron等多种后端，也支持3D并行策略的配置，这样数据流动的方式就会很复杂。为了实现这个功能，verl搞了一套协议，自动在函数的前后插上对应并行方式的dispatch/collect方法。反正都把函数调用搞成这么复杂的闭包了，ray相关的操作（ray.gets/.remote）也可以隐藏在闭包里面（OpenRLHF要直接写在脚本上），主体逻辑就看起来很简洁。

这个封装合不合适，见仁见智，对verl可能大部分人会有个螺旋上升的认识过程。首先看到fit函数这么简洁，肯定觉得很舒服；但后来发现每个函数怎么都点不进去，各种调用怎么一层套一层，就觉得这又是大公司开源狗屎给大家；最后明白了verl的设计理念，感叹人类的智慧。当然，如果不用大集群，7B/30B这种规模做做RL，还想自己改改东西，无脑推荐OpenRLHF。

One more thing：ray真的很重要吗？

回归前提，上一篇文章我猜RL算法的演进会越来越简洁，GRPO干掉了reward和critic。按照历史经验来看，RL需要的算力会越来越大，各种算法设计需要在大算力下充分验证。这一定会让RL走向力大砖飞的方向，各种小技巧会越来越少。在RL过程中，actor的推理和训练会越来越重，二者的系统差异也会越来越大，这两模块会吃掉所有的算力。为了达成更好的MFU，如果还是这种训练模式，actor训推共部署是必然的选择。在这个前提下，ray很可能是伪需求，最后还是回归到SPMD的怀抱。

参考

https://github.com/OpenRLHF/OpenRLHF

https://github.com/volcengine/verl

OpenRLHF: An Easy-to-use, Scalable and High-performance RLHF Framework

arXiv reCAPTCHA

低级炼丹师：强化学习从零到RLHF（八）一图拆解RLHF中的PPO

不关岳岳的事：[AI Infra] VeRL 框架入门&代码带读

杨远航：基于 Ray 的分离式架构：veRL、OpenRLHF 工程设计

猛猿：图解OpenRLHF中基于Ray的分布式训练流程

HybridFlow Programming Guide

原文链接: https://zhuanlan.zhihu.com/p/22879442357

作者使用纯Python实现了一个名为DeZero的深度学习框架，其编程风格与PyTorch类似。通过结合代码实现，由浅入深地拆解了深度学习框架的前端功能，包括自动微分、Layer、Optimizer、DataLoader等模块。

深度学习入门2book.douban.com/subject/36303408/这本书在国内比较冷门，但是我读过的最好的关于深度学习框架的书籍。这里所说的“好”，并不是指内容面面俱到，而是因为它的逻辑非常清晰，对入门十分友好。同时又不算很粗浅，像高阶微分这样的深度话题也有探讨。

本书的作者是Chainer的核心开发者Koki Saitoh。Chainer可能是最早在Python实现的define by run的深度学习框架（更常见的叫法是动态图），非常具有前瞻性，可惜在2019年的时候母公司（Preferred Networks）转投了PyTorch，项目停止了维护[1]。

这个母公司Preferred Networks也值得聊一聊。从主页来看啥都搞，AI外包公司，像是日本的商汤科技。

Projects - Preferred Networks, Inc.www.preferred.jp/en/projects/创始人兼CEO叫Toru Nishikawa，代表东京大学参加了2006年ACM ICPC世界总决赛，荣获第19名。

比较有意思的一点是前一年（2005）的ACM ICPC世界总决赛冠军是戴文渊大神，后来创建了第四范式，也是个AI外包公司。大神们的水平都不需要质疑，但最后都成为了AI外包公司，可能这就是这代人的宿命吧。。。

Preferred Networks还有个很出名的项目叫CuPy[2]，相当于numpy在cuda上的实现，也为书里的DeZero框架提供了GPU能力（不过这个前后端解耦设计其实不怎么合理，后端能拿到的前端信息太少了）。这个项目现在还活着，而且还在发版本。从产出来看，Preferred Networks确实聚集了一批日本AI仙人，做出了一些很有前瞻性的且很有影响力的软件，希望该公司业务蒸蒸日上。

再说一下书的内容，有几点我觉得是写的非常出色的：

1. 每一章都基于代码讲解，接着上一章的代码一步步从简单到复杂，阅读体验很流畅。而且看DeZero的代码实现能学到很多技巧（对于我这种没怎么写过Python的人来说），例如Layer这一节通过重写__setattr__的魔术方法实现了每个深度学习层的Parameter自动统计。
2. 概念的逐步引入。DeZero不是一股脑给一堆概念，对着概念一顿实现就完事了，而是一步步的基于功能的需要引入这些概念。比如实现自动微分的时候为什么需要引入Variable和Function；为什么要进行运算符重载、Layer/Module/Optimizer/DataLoader的封装，通过这些方式能把代码优化到什么程度。这种写作方式类似OSTEP，围绕着虚拟化、并发和持久性，一层一层的展示每个功能为什么要做，做完的好处是什么。一个好教材甚至于说一个好项目都应该是这样的，不应该有太多无用的概念，每一层的抽象都得有明确的目的。
3. 组合的力量。看高阶微分这一章的时候让我想起了SICP，SICP的很多细节我早就忘得一干二净了，唯一剩下的就是对组合力量的深刻印象。

组合其实就是通过简单的、模块化的组件组合，构建出复杂且强大的系统。这里的高阶微分就是一个例子。从一阶微分到高阶微分，通过完善的抽象设计，核心改动只需要将反向实现从调用numpy接口变成调用DeZero的运算符重载。后面的Layer设计其实也是组合的力量，从一个玩具框架最后组合出了rnn、cnn等网络，到真正的加载vgg的预训练模型，这些组合的力量让人印象深刻。

从这几点来看，我觉得这本书不仅是一个深度学习框架入门书籍，还是个极好的第二本Python书籍，适合学习完基本语法之后来看。他实现的是一个实打实的项目，肯定比实现什么算法之类的有意思多了，并且在实现该项目的同时，触及了一些计算机科学的本质。

最后说一下Chainer为什么消亡。其实我在网上没搜到太多对于Chainer缺点的评论，在reddit上有一些关于Chainer为什么打不过PyTorch的讨论[3] [4] [5]。

从讨论来看，基本输给了生态。从易用性上Chainer没理由比PyTorch要差，只是日本的计算机圈子还是太小了，Preferred Networks比不上FB财大气粗。而且有人说大量的资料都是日语，导致Chainer更像是日本计算机小圈子的自娱自乐。Chainer的失败对国内的基础软件走向世界还是有很大启发的，虽然国内公司的深度学习基础软件看起来还没有Chainer成功。。。

参考

1. ^Chainer/CuPy v7 release and Future of Chainer https://chainer.org/announcement/2019/12/05/released-v7.html
2. ^https://cupy.dev/
3. ^https://www.reddit.com/r/MachineLearning/comments/e0pir2/dwhy_isnt_chainer_more_useddiscussed/
4. ^https://www.reddit.com/r/MachineLearning/comments/e6dd7x/d_preferred_networks_creators_of_chainer/
5. ^https://www.reddit.com/r/MachineLearning/comments/7lb5n1/d_chainer_vs_pytorch/

原文链接: https://zhuanlan.zhihu.com/p/21525151726

DualPipe是DeepSeek V3里面infra部分的重头戏，既能减少bubble还能做到通信掩盖，整个编排方式看起来神乎其技。而且对于一些国产芯片复现DeepSeek V3（FP8很难用起来、也没法用SM去控制网卡），DualPipe几乎是论文里面infra部分唯一能参考的优化点。我用我半吊子的大模型并行知识，猜想一下这个东西是怎么构造出来的，以及落地上可能遇到的难度。

动机猜想

对于DeepSeek V3，性能的最大瓶颈就是正反向里面巨大的AllToAll通信，根据论文里面的说法，计算和通信大概是1:1的水平。而且整体拓扑关系是attention->alltoall->mlp->alltoall这样的顺序，前后有严格的依赖，根本没什么掩盖空间。

对于这种类型的通信，比较常见的做法是bs或者seq维度切一切，把1层拆成两个没有数据依赖的小层，互相做掩盖，类似下图：

但是每个micro的bs为了省activation的显存，基本都是1；切seq的话，MLP会被切小，可能导致算子本身性能下降，都不算是最好的做法。

这是两个正向或者两个反向互相做掩盖的场景，如果这个不好搞的话，就可能会想到，一个正向和一个反向能不能做掩盖，因为对于1f1b的调度来说，一定有正反向交替的阶段：

画一画，会发现不怎么对劲，如果强行掩盖相邻部分的正反向通信，会导致bubble变的巨大：

那现在的问题就是，需要一个合适的pipeline排布，既可以正反向做掩盖，bubble也不会增大。估计DeepSeek的大神们很快想到了Chimera，因为这个是双向的pp，上面rank灌进来的micro和下面rank灌进来的micro，相互之间的依赖关系没有这么重，如果相邻的正反向是不同方向的micro，是可以掩盖起来的，而且不会增大bubble：

结合上zero bubble的优化点，把dw拆出来，最后就形成了DualPipe：

一些问题

DualPipe的编排相比最常用的pp或者vpp甚至zero bubble，都复杂许多，想在工程落地会有很多问题：

• 实现逻辑的就很复杂。我不确定他们这个20micro的排布是基于策略写出来的还是基于一套算法搜出来的，想泛化感觉很不容易。
• 因为pp的编排复杂，会导致在超大集群下类似精度对比（需要沿着stage往上找输入）、快慢卡识别（会沿着pp传递）、首报错节点识别（要分析通信关系）都变的复杂很多。可能DeepSeek V3用的是2048卡，还不够大，这些问题还没那么重要，上了万卡规模，这些东西定位起来都很痛苦。
• 因为是双向的pp，需要每个rank放两个stage，导致param要翻个两倍。这个对于国产芯片可能很致命，显存没有那么多不说，暂时还不能用fp8训练，雪上加霜。

抛砖引玉

虽然普通的pp不行，但是对于vpp来说，很多地方都是可以做掩盖的：

红框标注的地方都可以掩盖，而且这个方式相比普通的vpp显存没有任何增加，实现逻辑也比DualPipe简单多了，感觉是个比较靠谱的落地方向。

或者更本质的，能不能用类似FLUX: Fast Software-based Communication Overlap On GPUs Through Kernel Fusion的思路搞一个AllToAll MLP AllToAll的融合算子，这样对上层业务来说是最轻松的。但这个领域不太熟，不确定能不能做到。

一个比较好的参考资料。

首先按照tools配环境，因为我用的是Ubuntu 18的虚拟机，所以需要自己手动去编译riscv-gnu-toolchain，编译的过程其实非常简单，但是下载的过程非常痛苦。这边有个老哥直接把riscv-gnu-toolchain放到百度云盘上了，这样下载就会快很多而且不容易中断。

Lab-1 Utilities

Lab1其实就是实现一些shell指令，做实验前一定要把xv6 book的第一章通读一遍，非常关键！！！

sleep & pingpong

相对简单，略过。这个pingpong我是用两个pipe从两个方向传输的。

primes

一个非常风骚的多进程筛法。主要流程如下图：

其实就是每个素数开一个进程，多个进程形成一个pipeline。按顺序输入数字，如果一个数被前面所有进程漏掉，那他显然是一个素数，就再开一个进程进入pipeline。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

#include "kernel/types.h"
#include "kernel/stat.h"
#include "user/user.h"

int p[36][2];

void prime_fork(int last, int from) {
    if (fork() == 0) {
        int prime, now;
        now = -1; prime = -1;
        if (last != -1) {
            close(p[last][0]);
        }
        close(p[from][1]);
        while (read(p[from][0], &now, 4)) {
            if (prime == -1) {
                prime = now;
                pipe(p[prime]);
                prime_fork(from, prime);
                close(p[prime][0]);
                printf("prime %d\n", prime);
                continue;
            } else {
                if (now % prime == 0) {
                    continue;
                } else {
                    write(p[prime][1], &now, 4);
                }
            }
        }
        if (prime != -1) {
            close(p[prime][1]);
            wait(0);
        }
        exit(0);
    }
    return;
}

int main() {
    pipe(p[1]);
    prime_fork(-1, 1);
    close(p[1][0]);
    for (int i = 2; i <= 35; i++) {
        write(p[1][1], &i, 4);
    }
    close(p[1][1]);
    wait(0);
    exit(0);
}

我直接暴力的用了一个p数组，代表每个进程向下传输所需要的pipe。一个素数的进程的pipe就直接使用p[素数]的数组就好了。因为fd空间不够35以内的素数开满，所以要管理fd，这个地方要小心处理，我因为close了一些回收过的fd错了好几次。

一个值得注意的地方是read前的close(p[from][1])，这个bug我也卡了一小会儿，这里直接引用xv6 book中的原文：

If no data is available, a read on a pipe waits for either data to be written or for all file descriptors referring to the write end to be closed.

没错，是all file descriptors都要close才行，不然read就会一直挂在那里，导致死循环。

find

这个本身其实挺复杂的，幸好ls指令已经写好了，所以直接抄就完事儿了。

xargs

这个理论上其实很简单，就是解析标准读入进来的字符串，先按照'\n' split一下，再按照' ' split一下，最后拼成argv就好了。但是有个地方非常坑爹，我最开始的时候，从标准读入读字符串，简单写成了这样：

1
2

buf_size = read(0, buf, (sizeof buf))
do something with buf...

这么写完之后，make grade大概五次会错一次，非常诡异。一般来说这种情况都是多进程出了问题，这时再掏出xv6 book的原文：

The child process creates a pipe to connect the left end of the pipeline with the right end. Then it calls fork and runcmd for the left end of the pipeline and fork and runcmd for the right end, and waits for both to finish.

一个pipe的左右指令是多进程，所以当左边指令输出，右边指令输入的时候，应该写成阻塞式：

1
2
3
4

while ((buf_size = read(0, buf + offset, (sizeof buf) - offset)) != 0) {
    offset += buf_size;
}
buf_size = offset;

我跑了十次，全都通过了testcase。

Lab-2 System calls

这次实验是实现两个系统调用trace和sysinfo，感觉在实现上没什么好说的，两个任务都比较简单。这里想重点总结一下整个xv6的boot和system call的流程。

首先讲讲boot的整个流程。我们的整个实验环境是搭建在RISC-V上面的，在RISC-V中，CPU运行的指令分成三种模式：machine mode, supervisor mode和user mode。最开始的时候，CPU是处于machine mode的。开机后，CPU运行boot loader中的指令，把整个kernel都给load进来。然后进入entry.S：

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

_entry:
# set up a stack for C.
        # stack0 is declared in start.c,
        # with a 4096-byte stack per CPU.
        # sp = stack0 + (hartid * 4096)
        la sp, stack0
        li a0, 1024*4
csrr a1, mhartid
        addi a1, a1, 1
        mul a0, a0, a1
        add sp, sp, a0
# jump to start() in start.c
        call start

entry.S的任务就是初始化stack，然后开始call start.c:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

void
start()
{
  // set M Previous Privilege mode to Supervisor, for mret.
  unsigned long x = r_mstatus();
  x &= ~MSTATUS_MPP_MASK;
  x |= MSTATUS_MPP_S;
  w_mstatus(x);

  // set M Exception Program Counter to main, for mret.
  // requires gcc -mcmodel=medany
  w_mepc((uint64)main);

  // disable paging for now.
  w_satp(0);

  // delegate all interrupts and exceptions to supervisor mode.
  w_medeleg(0xffff);
  w_mideleg(0xffff);
  w_sie(r_sie() | SIE_SEIE | SIE_STIE | SIE_SSIE);

  // ask for clock interrupts.
  timerinit();

  // keep each CPU's hartid in its tp register, for cpuid().
  int id = r_mhartid();
  w_tp(id);

  // switch to supervisor mode and jump to main().
  asm volatile("mret");
}

在RISC-V中，mret、sret和uret分别用于从machine、supervisor和user模式中的trap返回。这里调用的是mret，其实就是从machine mode返回到supervisor mode。

在main.c中，userinit函数首先allocproc()出来第一个用户进程，然后执行initcode.S中的指令，这个指令其实就是调用SYS_exec执行init.c：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

.globl start
start:
        la a0, init
        la a1, argv
        li a7, SYS_exec
        ecall

# for(;;) exit();
exit:
        li a7, SYS_exit
        ecall
        jal exit

# char init[] = "/init\0";
init:
  .string "/init\0"

# char *argv[] = { init, 0 };
.p2align 2
argv:
  .long init
  .long 0

在init.c中，系统生成一个名为"console"的device，并重载标准输出跟标准错误输出到这个device上，之后启动sh.c，shell启动，正式进入操作系统。

然后再讲讲整个system call的流程。这里我们可以用作业中的Sysinfo作为例子。

Sysinfo的功能是统计一下当前系统的剩余内存和已经使用的进程数量，并把这两个参数组装成一个结构体，传回给用户。这里就要分为三步，首先在user mode进行system call，进入supervisor mode，然后统计两个信息，最后system call return需要的信息回来。

我们要在user mode中调用这个sysinfo函数，但是因为这是一个系统调用，肯定不能在user mode里面实现，所以需要一个user mode的函数与supervisor mode的system call的绑定。具体到代码中，其实就是user/usys.pl中会有个entry("sysinfo")，这个语句会生成一段汇编代码：

1
2
3
4

sysinfo:
 li a7, SYS_sysinfo
 ecall
 ret

这个ecall指令会让我们进入supervisor mode并运行SYS_sysinfo函数。那么问题来了，我们看到系统调用的参数都是(void)的，并且我们当前user mode的各种寄存器要怎么保存呢？要解决这个问题，首先要知道ecall指令到底干了什么，在xv6 book中，是这样说的：

The ecall instruction traps into the kernel and executes uservec, usertrap, and then syscall, as we saw above.

uservec是一段汇编，主要是保护当前的user mode现场，将user进程中的寄存器数据放到TRAPFRAME中，同时加载kernel的页表。然后调用trap.c/usertrap()。

在trap.c/usertrap()会进入syscall(void)函数，syscall(void)会根据a7寄存器中的值调用对应的system call，system call参数的传递通过TRAPFRAME中的a0-a5寄存器，运行过后的返回值放到p->trapframe->a0寄存器中。

然后调用userret，也是一段汇编代码。userret会恢复user mode的页表，并且从TRAPFRAME中恢复过去的寄存器，这样就完成了一次系统调用。但是我们发现，system call并没有传递任何值给user mode，其实system call的返回值要通过copyout函数，直接写入该进程在user mode能使用的地址中。

Lab-3 Page tables

这个实验相对复杂，要比较清晰的理解页表才能顺利的完成。

首先，我们要了解页表是个什么东西。其实页表就是个(key, value)的pair集合，key是虚拟地址，value是物理地址，在程序使用的地址跟计算机实际运行的内存地址之间产生一层隔离关系。

这种隔离关系的好处是，不同进程之间无法直接访问对方的变量，恶意程序也无法破坏整个操作系统，只能破坏自己的进程。

其次，还可以使得物理上不连续的、不从0开始的物理地址变成连续的、从0开始的虚拟地址，方便内核做统一的内存管理，而不是每个进程自己乱管理。

Print a page table

完成打印页表的任务，只需要理解这个三级页表的架构就好了。从图片可以轻松了解这个数据结构，但是作为一个kv系统，为什么要这么设计呢？

其实很简单，如果页表只有一级，那就是空间换时间，一个巨大的桶存着页表。如果页表级数特别多，那访问时间就会很慢。三级页表就是个设计上的trade-off，而且这么设计，每一级页表就是一个page的大小，我觉得代码会更加规整。

判断一个页表的内容是否合法，其实就是对应一些掩码的位置，核心逻辑如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

void
_vmprint(pagetable_t pagetable, int level)
{
  // there are 2^9 = 512 PTEs in a page table.
  for(int i = 0; i < 512; i++) {
    pte_t pte = pagetable[i];
    if (pte & PTE_V) {
        uint64 child = PTE2PA(pte);
        for (int j = 0; j < level; j++) {
            printf("..");
            if (j + 1 != level) printf(" ");
        }
        printf("%d: pte %p pa %p\n", i, pte, child);
        if ((pte & (PTE_R|PTE_W|PTE_X)) == 0) {
            _vmprint((pagetable_t)child, level + 1);
        }
    }
  }
}

A kernel page table per process

这个环节又涉及到一个新的问题：用户级页表和内核级页表。

在上个环节我们已经知道，页表的主要功能是为了控制访问权限。那么理论上来说，每个用户级进程都要有自己的页表，从而只能访问自己的地址，不能访问别人的地址。内核既然是随便访问，那么用一个固定不变的内核页表就好了。所以在用户级进程与系统调用之间涉及到一个页表切换的问题。

kernel page table per process要求我们实现一个新功能，内核页表不再是全局的，而是每个进程独立的。这个任务分成两步：建立每个进程自己的内核页表、实现页表切换。

首先看一下内核页表在哪里进行了改动，我只发现了两个地方，一个是kvminit()，将低地址的IO device和trampoline映射到页表中。第二个是procinit()，这里声明了进程池中每个进程的栈空间，并跟内核页表进行绑定，方便内核从每个进程的栈中获取参数之类的。

那这个建立每个进程自己的内核页表就很简单的，先把kvminit()里面的东西都映射到每个进程的内核页表中，再绑定自己进程的栈就可以了。

实现页表切换分为两步，将页表写入satp寄存器，然后用sfence.vma刷新TLB，所以页表命中是完全靠硬件，页表缺失会引起中断，需要操作系统跟硬件的配合。在scheduler()中就可以进行页表的切换，需要注意的是，进程的内核部分运行结束后要立刻把页表切换成全局的内核页表。

Simplify copyin/copyinstr

经过上一轮的准备之后，我们可以简化copyin/copyinstr的流程。copyin是一个系统调用，要把进程中内存的一些东西copy到内核中，这里的问题在于，系统调用传入的地址是一个虚拟地址，在没有进程中的用户页表的情况下，我们无从得知该虚拟地址对应的物理地址的位置。所以在xv6中，copyin的函数签名为：

1

int copyin(pagetable_t pagetable, char *dst, uint64 srcva, uint64 len)

这里问题的关键是，因为内核页表是全局的，我们无法修改内核页表，让硬件帮助我们完成虚拟地址到物理地址的转换，所以要先进行一步软件层面的转换，然后通过内核页表的直接映射的性质去完成系统调用。当然，我们在上一个环节实现了每个进程自己维护的内核页表，所以我们可以将虚拟地址的映射加入到自己维护的内核页表中。

这里为了保持一致性，要小心的修改，在fork(), exec()和sbrk()的函数中，都有对虚拟地址映射的修改，主要增加或是改变对应内存大小。

这里其实有个问题，就是内核页表是采用直接映射的方式。也就是在映射用户的虚拟地址之前，低位其实已经映射一些内容了，这就会导致remap。一方面要调整我们的函数去忽略remap，另一方面lab指导中告诉我们，PLIC寄存器之前的空间都可以随便映射。

Lab-4 Traps

该实验系统的总结了trap的流程，其中大致的流程我们在上一篇文章lab2中都已经叙述过了，通过lab4，我们会对整个流程理解的更加深刻。

trap来自三种情况：syscall对ecall的调用、程序运行的错误、设备中断（比如时钟）。当中断发生时，我们会自动运行一段运行好的程序，当然，kernel中断跟user中断运行的程序应该是不同的，所以要用一个寄存器储存这段程序的位置。user中断的过程会相对复杂，因为user process会发生各种事情，所以我们就从user中断讲起。user中断运行的位置就是trampoline中的uservec。

uservec的功能我们lab2中已经分析过了，主要是切换页表跟保护现场两个功能。因为要使得切换页表后，trampoline中的程序在用户态和内核态都能运行，所以trampoline在内核页表和用户页表中要完全相同。

之后在usertrap中判断trap的类型，systemcall就去准备systemcall，时钟中断就去修改process的状态，错误就直接kill整个process，之后再调用userret将之前保护的现场还原回去以及将页表改回用户页表。

内核的trap跟用户的trap原理相似，但是一个很重要也很繁琐的细节就是，当user trap进入内核态的时候，内核也有可能继续trap。这就要求我们在进入user trap的时候，要准备好所有kernel trap可能用到的东西，以及保存kernel trap可能破坏的位置，方便kernel trap结束后进行恢复。

RISC-V assembly

作业让我们熟悉一下RISC-V，群里大佬们推荐了一本包云岗翻译的RISC-V的教材，可以用来查询。

询问了一些简单的RISC-V的问题，但是要注意，他的编译器是默认开优化的，比如第一问：

Which registers contain arguments to functions? For example, which register holds 13 in main's call to printf?

1
2
3
4
5

  printf("%d %d\n", f(8)+1, 13);
24:4635                lia2,13
26:45b1                lia1,12
28:00000517          auipca0,0x0
2c:7b050513          addia0,a0,1968 # 7d8 <malloc

看指令，这个13可以理解是什么，但是这个12是哪来的。再一看f跟g函数，估计是太简单被直接常量折叠了，那我们就把编译选项加上-O0再来一遍。

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

printf("%d %d\n", f(8)+1, 13);
4c:4521                lia0,8
4e:00000097          auipcra,0x0
52:fce080e7          jalr-50(ra) # 1c <f>
56:87aa                mva5,a0
58:2785                addiwa5,a5,1
5a:2781                sext.wa5,a5
5c:4635                lia2,13
5e:85be                mva1,a5
60:00001517          auipca0,0x1
64:d0850513          addia0,a0,-760 # d68 <malloc+0x13e>
68:00001097          auipcra,0x1
6c:9d0080e7          jalr-1584(ra) # a38 <printf>

可以比较清楚的看出来，第一个f(8)+1在a1寄存器中，第二个13在a2寄存器中。

Backtrace

这个任务就是输出调用栈信息，这些任务都存在stack中，stack结构在slide中可以看到：

其中初始的frame-pointer值，实验指导已经给出了代码。那问题就在于什么时候停止往前回溯。其实只要frame-pointer等于PGROUNDUP(fp)就可以跳出循环了。因为最浅层的那个调用既没有frame-pointer，也没有return address。

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

void
backtrace(void)
{
  printf("backtrace:\n");
  uint64 fp = r_fp();
  uint64 upper_bound = PGROUNDUP(fp);
  uint64 ra;
  while (1)
  {
    ra = *((uint64*)(fp - 8));
    printf("%p\n", ra);
    fp = *((uint64*)(fp - 16));
    if (fp == upper_bound) break;
  }
}

Alarm

这个实验难度较大，让我们实现一个syscall，可以监控cpu在该进程上的运行时间。单独监控运行时间其实比较简单，大致思路就是在process里面加个变量，当产生时间片中断时，就把这个变量++，然后输出。但问题是，实验让我们完成的函数是sigalarm(int ticks, void (*handler)())这种形式的。每次经过ticks时间片，就调用一下handler函数。

我们根据实验材料中的提示，可以简单得到这样一个思路：

1
2
3
4
5
6
7
8
9
10

// give up the CPU if this is a timer interrupt.
if(which_dev == 2)
{
p->timer ++;
if (p->timer == p->ticks) {
    p->timer = 0;
    p->trapframe->epc = (uint64)p->handler;
}
yield();
}

这样当调用usertrapret()之后，会自动运行handler位置的程序。但是当我们运行test程序之后，发现第一次监控输出之后，后面的程序会发生混乱。

简单分析一下，可以发现，我们回到handler之后，并没有再回到原本process运行的位置。这样就会产生补救的思路，先把trapframe存起来，然后当handler运行结束后，通过另一个系统调用，将trapframe恢复：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

p->timer ++;
if (p->timer == p->ticks) {
    p->timer = 0;
    if (p->ishandle == 0)
    {
        p->ishandle = 1;
        memmove(p->dump_trapframe, p->trapframe, sizeof(struct trapframe));
        p->trapframe->epc = (uint64)p->handler;
    }
}

uint64
sys_sigreturn(void)
{
  struct proc *p = myproc();
  p->ishandle = 0;
  memmove(p->trapframe, p->dump_trapframe, sizeof(struct trapframe));
  return 0;  
}

因为有个slow_handler()测试点，暗示我们handler运行的过程中，计时功能应该关闭，所以我们要加一个p->ishandle变量来把门。

Lab-5 Lazy Page Allocation

该实验主要是对sbrk的修改，就是当一个process要求操作系统分配更多内存给他的时候，并不直接进行分配，而是当process真的访问到该内存的时候，再进行分配，整个过程都是由缺页中断进行驱动的。

Eliminate allocation from sbrk()

非常简单，只要修改p->sz就行了，不需要进行任何其他操作。

Lazy allocation

通过这个case其实也非常简单，我感觉怎么写都能过，我在写这个的时候错了好几个地方，都成功通过echo hi了。

原理也比较简单，就是在缺页中断的时候调用一下mappages。

Lazytests and Usertests

这个任务要求我们通过修改上一个任务的代码，从而通过两个非常复杂的程序。这里我遇到了两个非常坑爹的地方。

首先是lazytests里面的oom，我总是在oom之前就发生p->sz整数溢出。发现p->sz是uint64类型的，理论不应该溢出才是。

观察一下原有的sbrk的写法：

1
2
3
4
5
6
7
8

int addr;
int n;
if(argint(0, &n) < 0)
    return -1;
addr = myproc()->sz;
if(growproc(n) < 0)
    return -1;
return addr;

这里，大部分人第一次都会去用myproc()->sz=addr+n来修改sbrk，然而这个位置会导致整形溢出，也就是他默认的数据类型会溢出，非常坑爹！

还有一个地方，更加恶心。就是usertests的sbrkargs，我跑了所有其他case都能通过，就这个case无法通过。

经过细致的排查，发现sbrkarg的特殊之处在于，他是在copyin这个函数里面软查找页表的时候产生缺页的，不会产生缺页中断，但是会导致写入失败。所以要在walkaddr里面也处理一下lazy alloc的情况。

也就是说，不是所有缺页都是通过缺页中断驱动的，真是令人作呕的设计啊...

Lab-6 Copy-on-Write Fork for xv6

下面是页表的最后一个实验，实现xv6 fork的COW机制。

超级恶心，写了我整整一天，各种坑点非常多，而且难以debug。这里建议先从给页表进行引用计数下手，一个显而易见的思路是，将kmem改成如下这样：

1
2
3
4
5

struct {
  struct spinlock lock;
  int ref_cnt[PHYSTOP / PGSIZE];
  struct run *freelist;
} kmem;

可能有人会疑惑这个引用数组到底开到了RAM的什么地方？其实这个数组会在link的时候开到RAM上，并通过linker算出extern char end[]的位置，所以只要不是太大，并不会影响到整个程序的运行。这个其实就相当于一个无碰撞的hash表，如果想节省内存，还可以搞点复杂的hash表动态扩容啥的，然而嫌麻烦，就没有搞。然后这个freelist记录的就是所有引用计数为0的page了。

后面就需要注意uvmcopy以及缺页中断的情况了。在实验的提示中，他说可以利用RISC-V的RSW位，然而我并没有用这个东西，最后也成功通过了所有的case，核心函数如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

int
fix_cow(pagetable_t pagetable, uint64 va)
{
  uint64 pa;
  if ((pa = walkaddr(pagetable, va)) == 0) {
    return -1;
  }
  char *mem;
  if ((mem = kalloc()) == 0) {
    return -1;
  }
  memmove(mem, (char*)pa, PGSIZE);
  uvmunmap(pagetable, va, 1, 1);
  if(mappages(pagetable, va, PGSIZE, (uint64)mem, PTE_W|PTE_X|PTE_R|PTE_U) != 0){
    kfree(mem);
    return -1;
  }
  return 0;
}

我最开始的时候把前两个if写反了，导致countfree怎么都通过不了，非常坚硬，研究了半天。要小心谨慎的维护page，基本所有错误都是page的alloc和free导致的。

Lab-7 Multithreading

教材这一部分有点难读，大量内容都在解释有关xv6内部内核线程同步的代码，有些烧脑。幸好作业部分非常简单，完成的非常顺利。

Uthread: switching between threads

这个任务是给xv6添加用户线程，其实跟内核线程的添加方式几乎完全相同，因为没有让我们实现锁机制，所以整体的思路非常简单。

最核心的地方就是切换thread运行的context，这个地方采用跟内核线程一样的方式，只要保存返回地址、栈指针、callee-saved就可以了。

通过阅读xv6教材，我的理解是，其实内核没有进程的概念，只有用户有进程的概念。只是用户进程trap进入内核态之后，有个内核线程与该进程绑定而已。

Using threads

这个任务也非常简单，给一个最简单的开散列hash表加锁，并稍微优化一下性能。

最简单的思路就是每个bucket都加个锁，恰好能达到要求的1.25x的加速：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

static 
void put(int key, int value)
{
  int i = key % NBUCKET;

  // is the key already present?
  struct entry *e = 0;
  pthread_mutex_lock(&lock[i]);       // acquire lock
  for (e = table[i]; e != 0; e = e->next) {
    if (e->key == key)
      break;
  }
  if(e){
    // update the existing key.
    e->value = value;
  } else {
    // the new is new.
    insert(key, value, &table[i], table[i]);
  }
  pthread_mutex_unlock(&lock[i]);     // release lock
}

Barrier

barrier指的就是所有线程都执行到此步之后，在进行后续的程序执行。实际上是对xv6的sleep和wakeup机制的复习。

整体思路也比较简单，只要加锁就好了：

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

static void 
barrier()
{
  pthread_mutex_lock(&bstate.barrier_mutex);
  bstate.nthread ++;
  if (bstate.nthread != nthread) {
      pthread_cond_wait(&bstate.barrier_cond, &bstate.barrier_mutex);
  } else {
      bstate.nthread = 0;
      bstate.round ++;
      pthread_cond_broadcast(&bstate.barrier_cond);
  }
  pthread_mutex_unlock(&bstate.barrier_mutex);
}

Lab-8 Locks

教材中主要讲解了xv6系统中各种锁的设计理念。在xv6中，内部锁是由_sync_语句来保证原子性的，感觉这种思路确实相对比较简单。

因为CPU会进行乱序发射之类的指令顺序的优化，所以在很多情况下，需要显式的加上__sync_synchronize()，防止CPU进行跨越该语句的乱序发射。

两个任务具有一定的相似性，一个是优化buffer cache的锁，一个是优化kalloc的锁。我采用的方案也比较相似，在kalloc中，每个CPU弄一个独立的链表，在buffer cache中，每个blockbnum的hash值弄一个独立的链表。

在刚刚开始进行kalloc实验的时候，我走进了一个误区，以为freerange是在每个CPU上面执行的，这里保留一下学习群里的聊天记录，感谢群里的老哥们：

Lab-9 File System

感觉教材阅读起来比较困难，因为整个 File System 是分成 7 层层层抽象来构建的，我边参考代码边读了差不多三四遍，才完全把整个结构理解。整个层级图如下图所示：

Large files

这个任务的难度不是太大，正常的文件 innode 结构是这样的：

这样的二级结构使得每个文件只能支持 12+256 个 block，可以变成三级结构，使得整个文件能达到 11+256+256*256 个 block。只要小心的修改 itrunc 和 bmap 函数就可以了。

Symbolic links

这个任务的难点在于要清晰的了解他想让你实现的 Symbolic links 行为到底是什么样子的。当 open 不带有 O_NOFOLLOW 标记时，需要一直向下找到 hard link 的位置。整个 symbolic link 的内容都要放在对应的 inode 上面，实际上只需要自己去将文件路径和路径长度保存在 inode 里面就可以了。

open 的修改部分：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

if((omode & O_NOFOLLOW) == 0){
    char s[MAXPATH];
    int cnt = 0, length;
    while(cnt < 10 && ip->type == T_SYMLINK){
        cnt ++;
        readi(ip, 0, (uint64)&length, 0, 4);
        readi(ip, 0, (uint64)s, 4, length);
        s[length] = 0;
        iunlockput(ip);
        if((ip = namei(s)) == 0){
            end_op();
            return -1;
        }
        ilock(ip);
    }
    if(cnt >= 10 && ip->type == T_SYMLINK){
        iunlockput(ip);
        end_op();
        return -1;
    }
}

sym_link:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

int
len(char *s)
{
    int cnt;
    for(cnt = 0; cnt < MAXPATH; cnt ++){
        if(s[cnt] == 0) break;
    }
    return cnt;
}

uint64
sys_symlink(void)
{
    char target[MAXPATH], path[MAXPATH];
    struct inode *ip;

    if(argstr(0, target, MAXPATH) < 0 || argstr(1, path, MAXPATH) < 0)
        return -1;

    begin_op();
    if((ip = create(path, T_SYMLINK, 0, 0)) == 0){
        end_op();
        return -1;
    }
    int length = len(target);
    writei(ip, 0, (uint64)&length, 0, 4);
    writei(ip, 0, (uint64)target, 4, length + 1);
    iunlockput(ip);
    end_op();
    return 0;
}

Lab-10 Mmap

这个实验的难点在于，mmap 要实现成 lazy alloc 的形式，所以要对页表进行大量的操作，然而做到 lab-10 可能前面页表的细节已经完全忘干净了（

不过缺点也在于测试样例过于简单，感觉覆盖的场景非常不完全。

对于这个 lazy alloc 的处理，我选择了一种比较取巧的方式，就是在开始的时候完全按照 lazy alloc 的那个方式来写，在最后判断的时候，多加一个 mmap 的判断：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

void
mmaplazyalloc(int va)
{
  struct proc *p = myproc();
  int found = 0, i = 0;
  for (i = 0; i < 16; i++) {
    if (p->mmaps[i].used) {
      uint64 start = p->mmaps[i].addr;
      uint64 end = p->mmaps[i].addr + p->mmaps[i].length;
      if (va >= start && va < end) {
        found = 1;
        break;
      }
    }
  }
  if (found == 0)
    return;
  
  struct file *f = p->mmaps[i].f;
  int offset = p->mmaps[i].offset;
  uint64 off = offset + va - p->mmaps[i].addr;

  begin_op();
  ilock(f->ip);
  if (readi(f->ip, 1, va, off, PGSIZE) < 0) {
    panic("lazyalloc read.");
  }
  iunlock(f->ip);
  end_op();
}

......
  } else if((which_dev = devintr()) != 0){
    // ok
  } else if (r_scause() == 13 || r_scause() == 15) {
    uint64 va = r_stval();
    va = PGROUNDDOWN(va);
    if (va >= p->sz || va < PGROUNDUP(p->trapframe->sp)) {
      p->killed = 1;
    } else if (walkaddr(p->pagetable, va) == 0) {
      p->killed = 1;
    }
    mmaplazyalloc(va);
  } else {
    printf("usertrap(): unexpected scause %p pid=%d\n", r_scause(), p->pid);
    printf("            sepc=%p stval=%p\n", r_sepc(), r_stval());
    p->killed = 1;
  }

另一个比较麻烦的地方就是对 munmap 的处理，因为题目保证了 munmap 要么截断前面，要么截断后面，不会截断中间，所以要对这几种情况进行调整：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

uint64
sys_mmap(void)
{
  uint64 addr;
  int length, prot, flags, fd, offset;
  struct file* f;
  if (argaddr(0, &addr) < 0 ||
    argint(1, &length) < 0 ||
    argint(2, &prot) < 0 ||
    argint(3, &flags) < 0 ||
    argfd(4, &fd, &f)  < 0 ||
    argint(5, &offset) < 0) {
    return -1;
  }
  if((prot & PROT_WRITE) && !f->writable && flags == MAP_SHARED)
    return -1UL;
  struct proc *p = myproc();
  for (int i = 0; i < 16; i ++) {
    if (!p->mmaps[i].used) {
      struct vma* v = &p->mmaps[i];
      v->addr = p->sz;
      v->length = length;
      v->f = f;
      v->prot = prot;
      v->used = 1;
      v->flags = flags;
      v->offset = offset;
      p->sz = p->sz + length;
      filedup(f);
      return v->addr;
    }
  }
  return -1;
}

uint64
sys_munmap(void)
{
  uint64 addr;
  int length;
  int found = 0, i = 0;
  if (argaddr(0, &addr) < 0 ||
    argint(1, &length) < 0) {
    return -1;
  }
  struct proc *p = myproc();
  struct vma* v = 0;
  for (i = 0; i < 16; i++) {
    if (p->mmaps[i].used) {
      uint64 start = p->mmaps[i].addr;
      uint64 end = p->mmaps[i].addr + p->mmaps[i].length;
      if (addr >= start && addr < end) {
        found = 1;
        v = &p->mmaps[i];
        break;
      }
    }
  }
  if (found == 0)
    return -1;
  
  for (int offset = 0; offset < length; offset += PGSIZE) {
    uint64 a = addr + offset;
    if (p->mmaps[i].flags & MAP_SHARED) {
        pte_t *pte = walk(p->pagetable, a, 0);
        if (pte != 0 && (*pte & PTE_V) != 0) {
            begin_op();
            ilock(v->f->ip);
            writei(v->f->ip, 1, a, a - v->addr + v->offset, PGSIZE);
            iunlock(v->f->ip);
            end_op();
        }
    }
    uvmunmap(p->pagetable, a, 1, 1);
  }
  
  if (addr == v->addr) {
    if (length == v->length) {
      v->used = 0;
      fileclose(v->f);
    } else if (addr + length > v->addr + v->length) {
      panic("munmap: wrong");
    } else {
      v->addr = addr + length;
      v->offset = v->offset + length;
      v->length -= length;
    }
  } else {
    if (addr + length == v->addr + v->length) {
      v->length = addr - v->addr;
    } else {
      panic("munmap: wrong");
    }
  }
  return 0;
}

需要注意的是，我们在 writei 的时候，截断的 offset 要补入 p->mmaps[i] 的 offset 中，这样才能找到正确的 offset。

Lab-11 Networking

最后一个实验了，非常简单，就是让我们实现 e1000_transmit 和 e1000_recv 这两个函数。看起来仿佛非常复杂，实际上按照 hint 模拟就好了。

但是有个地方需要注意，在 hint 中， e1000_recv 实现方式如下：

Some hints for implementing e1000_recv: First ask the E1000 for the ring index at which the next waiting received packet (if any) is located, by fetching the E1000_RDT control register and adding one modulo RX_RING_SIZE. Then check if a new packet is available by checking for the E1000_RXD_STAT_DD bit in the status portion of the descriptor. If not, stop. Otherwise, update the mbuf's m->len to the length reported in the descriptor. Deliver the mbuf to the network stack using net_rx(). Then allocate a new mbuf using mbufalloc() to replace the one just given to net_rx(). Program its data pointer (m->head) into the descriptor. Clear the descriptor's status bits to zero. Finally, update the E1000_RDT register to be the index of the last ring descriptor processed. e1000_init() initializes the RX ring with mbufs, and you'll want to look at how it does that and perhaps borrow code. At some point the total number of packets that have ever arrived will exceed the ring size (16); make sure your code can handle that.

但是在实际实现中，net_rx要先release锁之后才能去运行，不然就会panic：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

static void
e1000_recv(void)
{
  while (1) {
    acquire(&e1000_lock);
    uint32 idx = (regs[E1000_RDT] + 1) % RX_RING_SIZE;
    struct rx_desc *desc = &rx_ring[idx];
    if (!(desc->status & E1000_RXD_STAT_DD)) {
        release(&e1000_lock);
        break;
    }
    rx_mbufs[idx]->len = desc->length;
    struct mbuf *m = rx_mbufs[idx];
    rx_mbufs[idx] = mbufalloc(0);
    desc->addr = (uint64) rx_mbufs[idx]->head;
    desc->status = 0;
    regs[E1000_RDT] = idx;
    release(&e1000_lock);
    net_rx(m);
  }
}

Graph Matching Networks for Learning the Similarity of Graph Structured Objects. ICML 2019 就是一个利用 GNN 解决二进制函数相似性问题的工作。这个问题也是 Source Code Modeling 领域的经典问题之一。 二进制函数相似性是一个在信息安全领域应用很广泛的问题。因为很多软件都是不开源的，放在用户电脑上的只能是一些二进制代码。因为编译器、编译选项以及平台的不同，同一个函数的二进制代码也经常是不同的。如果一个函数被检查出了安全漏洞，那这个函数所编译出的所有二进制代码也会有安全漏洞。这些二进制代码放在成千上万用户的电脑上，造成非常大的安全隐患，所以及时找到这些代码是非常重要的。因为二进制代码本身会有一个 Control-flow-graph，所以利用 GNN 解决二进制函数相似性就成为 GNN 的一个应用。

论文中给出两种方式来解决这个问题。第一种是输入一个图输出一个 embedding，通过优化这个 embedding 使得两个相似的图的 embedding 会离得更近。第二种更加直接，输入两个图，输出他们的相似性。这两种方式都是在 GNN 的基础上做的。

第一种方法计算 embedding 的过程没啥好说的，就是输入\((G_1, G_2)\)输出\((h_{G_1},h_{G_2})\)。重点在于最后的 loss 设计，因为跟第二种可以共用相同的 loss，所以放到一起最后讲。 对于第二种方法，大多数步骤跟 GNN 都是一样的。主要区别在于在聚合邻居信息的时候，也要聚合另一张图的信息 \(\mu\)：

其中\(\mu\)的计算方式如下，上面的\(f_s\)和下面的\(s_h\)都是可以替换的向量相似度计算方式：

观察公式\((11)\)可以发现，attention 值越大，两个点越相似。所以这个\(\Sigma\mu\)其实就是该点的 embedding 跟另一张图最相似的点的 embedding 的差。如果两个图完全一样，那这个\(\Sigma\mu\)就会一直是\(0\)。所以这个 GMN 的优势就是通过一个图的表示可以更改另一个图的表示，从而捕捉两个图的不相似程度。 下面是两种方法的 loss。论文定义了两种 label，第一种是\((G_1,G_2,t)\)，两个图相似\(t=1\)，不相似\(t=-1\)。第二种是\((G_1,G_2,G_3)\)，其中\(G_1\)跟\(G_2\)更加相似。如果向量相似性用欧拉距离来度量，那可以用一种类似合页 loss 的方式来进行优化：

公式\((12)\)可以看做当两个图相似的时候，距离应该小于\(1-\gamma\)，当两个图不相似的时候，距离应该大于\(1+\gamma\)。 公式\((13)\)可以看做\(d(G_1,G_2)\lt d(G_1,G_3)-\gamma\)。

也可以按照上面的公式，用 Hamming 相似度来算，这样的好处是向量里面每一维度都是\([1,-1]\)，容易在大型数据库中快速的查询。

可以看到，效果有一定的提升。这里的 baseline 是 Google 的一个二进制代码查询工具，利用手工构造的图 hash 来寻找相同的代码。

Open Vocabulary Learning on Source Code with a Graph-Structured Cache. ICML 2019 这篇文章就致力于解决代码中的 open vocabulary 问题，而且是通过 GNN 来解决，与我们的主题十分契合。 整个建图过程跟之前的工作非常类似，只是多了 Graph-Structured Cache Node：

其实也是先分词，然后相同的词搞一个节点而已。初始的特征是节点名字特征跟Cache节点类型本身有个特征进行拼接。节点名字特征用 CharCNN 来计算。 建图层面还是比较简单的，这篇文章主要的贡献之处在于利用 GSC 节点来解决 open vocabulary 的问题。解决的方法在于修改 GNN 最后一步\(y=g(\{h_v^t\})\)中\(g\)的计算方式，灵感来自于 Pointer Network。为了方便之后理解，先简单叙述一下啥是 Pointer Network。 这个 Pointer Network 本来是做组合优化的，最开始用来解决凸包问题。凸包问题我们都知道，输入一个点集，输出一个凸包。但是这个输出的范围其实是跟输入相关的。Pointer Network 用了很简单的机制解决了这个问题：

在传统的 attention 中，都是 encoder 和 decoder 的 hidden layer 算个权重，然后组合一下 encoder 的所有权重输入到 decoder 中。这里的输出就直接把 attention 的最大权重作为其中一步的输出，并且输入到 encoder 中继续形成新的 hidden layer。 下面就看看如何利用 GSC 解决 VARMISUSE 的问题。在前一篇文章中，这个 VARMISUSE 问题解决起来其实还是比较复杂的。这篇文章用 Java 项目作为数据集。因为 Java 跟垃圾语言 Python 不一样，是一个要先声明后调用的语言。所以对单独语法槽的预测，都可以变成一个 Pointer Network 问题，指向现存的变量节点。对于 GGNN 来说，简单按照\(y=\sigma(f_1(h_v^t,h_v^0)\odot f_2(h_v^t))\)来计算一下 attention 权重（其实我不太懂这个 attention 为什么跟槽的 embedding 无关，可能是因为 GGNN 论文里面的 readout attention 就是这么做的），挑其中最大的几个作为输出即可。

可以看到，加上 GSC 之后效果有一定的提升。 解决 VARNAMING 的思路跟 Pointer Sentinel Mixture Model 非常相似。Pointer Sentinel Mixture Model 就是把纯 attention 求出来的 open vocabulary 分布和正常 attention 求出来的 close vocabulary 分布加到一起，来预测要产生的序列：

这个 open vocabulary 和 close vocabulary 组合的权重利用一个名为 sentinel 的虚拟输入的 attention 值来计算。 对于 VARNAMING 来说，也是按照上一篇文章的方法建图，对于所有要命名的变量 embedding 取一个平均值，然后作为输入放到 GRU 中。close vocabulary 的分布按照正常的方式产生，Pointer Network 的 attention 权重就是把每个 GSC 或者 sentinel 的 embedding 输入到一个线性层，然后跟 hidden layer 点积一下接一个 softmax。最后的公式就是：\[P(w|h)=P_{graph}(s|h)P_{graph}(w|h)+(1-P_{graph}(s|h))P_{vocab}(w|h)\]

可以看出，实验效果提升巨大。可能看起来还是不怎么样，但是要考虑到这个问题的难度，做成这样就不错了。

Learning to Represent Programs with Graphs. ICLR 2018 是 GNN 在 Source Code 中运用的比较早的工作，质量也蛮高。 首先定义一下这篇文章要解决的两个问题： 第一个问题叫做 VARNAMING，就是在一段代码中有个匿名的变量，然后要通过这个变量在代码中的行为来对这个变量命名。 第二个问题叫做 VARMISUSE，类似于程序填空，预测一个程序中空缺的 token 是什么。通过这个任务，可以发现代码中一些 misuse 性质的 bug，举例如下：

当然，对于第二个任务来说，合法的解可能有好几个，就跟考试的程序填空中有好多正确答案一样。 根据文章的标题，可以想象文章的内容就是把 program 建成一个图，然后在图上面跑 GNN。文章中所采取的的 GNN 是 GGNN (Gated Graph Neural Networks)，可能是因为这个 GGNN 比较适合 program 建的图，所以很多后续工作采用的也是这个方法。 图定义为\(G=(V,E,X)\)，其中\(V\)是节点、\(X\)是特征，\(E=(E_1,...,E_k)\)是边的集合，边有\(k\)种。 每个节点状态为\(h^{(v)}\)，初始状态就是\(x^{v}\)。跟传统的 GNN 一样，每个节点会向外发送\(k\)的类型的消息\(m_k^{(v)}=f_k(h^{v})\)，然后每个节点聚合邻居的消息\(\widetilde{m}^{(v)}=g(\{m_k^{(u)}\}\mid{(u,v,k)\in E})\)。 特殊之处在于更新\(h^{(v)}\)的方式，GGNN 用的是 GRU 单元来更新特征向量。\(h^{(v)}=GRU(\widetilde{m}^{(v)},h^{v})\)。这样可以捕捉到一些较远的点对该点的影响。 在该论文中，\(f_k\)是一个线性函数，\(g\)是个简单的求和。 这篇论文中比较炫酷的部分是建图。首先一个程序，自然对应一个 AST，这个 AST 的叶子节点是程序中的 token，中间节点对应着 BNF 的中间节点。因为 GNN 捕捉不了树的儿子的顺序，所以要加一个 NextToken 边来把 token 都串起来：

另一方面，我们要捕捉程序的 Data-flow 信息。对于每个变量来说，上一次 read 的位置，连接一个 LastRead 边，因为有分支结构存在，这种边可能有多条。同样，上一次 write 的位置，连接一个 LastWrite 边。有赋值语句存在的时候，左右两边的语句要连接一个 ComputedFrom 边：

作者还加了很多乱七八糟的边，比如用 LastLexicalUse 来把所有同一个变量的调用都串起来。return 后面接的变量也会通过 ReturnTo 边连接到方法的声明上。对于形如 Foo(bar) 和 Foo(InputStream Stream) 这样的方法调用与声明，bar 也会连接到 stream 上。最后，对于 if(x>y){...x...}else{...y...} 这样的语句，x 向条件节点连一个 GuardedBy 边，y 向条件节点连接一个 GuardedByNegation 的边。 最后再把所有反向边都加入，也就是形成一个无向图。这个图就处理好了。 这篇文章做实验用的是 C# 的一些项目。跟 Python 这种垃圾语言不一样，C# 每个变量是有固定的类型信息的，这种类型信息显然是可以运用的。作为一个高贵的 OOP 语言，C# 的类型还是有层级的。对于一个类型\(\tau\)，有一个 embedding 函数 \(r(\tau)\)。因为这个类型具有层次结构，所以可以搞一个集合\(\tau^{*}(v)\)，里面具有\(v\)本身的类型和\(v\)所有的父类型的 embedding，然后对这个集合每一维度取个最大值，作为变量\(v\)的类型特征。可以用类似 dropout 的方法来进行优化。 变量\(v\)还具有变量名，可以把变量\(v\)的变量名进行分词，分出来一堆 subtoken。这些 subtoken 的表示取一个平均作为变量名的特征。把变量名特征跟类型特征连接起来，得到每个节点的最初表示。 整个网络的结构有了，下面就是用这个网络来解决 VARNAMING 跟 VARMISUSE 了。 对于 VARNAMING 来说，可以把要命名的变量名替换为 SLOT token。然后跑一遍 GNN，对于每一处变量的表示取个平均值。这个值作为一个 GRU 的输入，来生成一堆 subtoken 作为变量名。这样就转变为一个 GraphToSeq 的问题。 VARMISUSE 的问题会相对复杂一点。首先也是把目标位置\(c(t)\)替换为一个匿名的 SLOT 变量。正常连边的时候，变量相关的变量应该都不会连接到 SLOT 变量上。然后将候选集中的每个变量\(v_{t,v}\)加入到这个图中，并连接好变量相关的边。在这个图上跑 GNN，可以得到\(h^{SLOT}\)和\(h^{v_{t,v}}\)。最后通过\(argmax_v W[h^{SLOT}, h^{v_{t,v}}]\)来找到正确的变量。

相比一些简单的 baseline，这个方法效果提升巨大。值得注意的是，加入的各种边和节点的 embedding 也非常的 make sense，对最后的效果很有帮助。

整个过程不是很复杂，这个强化学习其实就是用来代替模拟退火的。迭代数次 Policy Network，输入是一个当前算子的 config，也就是之前说的 schedule，输出是对 config 的上下调整。强化学习要从环境里面获取代价，这个代价其实就是从 cost model 里面预测出来的每个 config 的运行时间，再用 PPO 的方式去训练 Policy Network，这个强化学习套路感觉非常的强行，最后效果也一般般。 然后对所有的 config 进行自适应采样，只对采样出来的 config 在硬件上测试实际的运行时间，然后将采样出来的 config 用于 cost model 的训练。这个所谓的自适应采样其实非常简单，就是对所有 config 做一个 k-means，然后采样每个centroid。

从上面两个图可以看出，第二步自适应采样的动机还是比较强的。因为对于 AutoTVM 来说，大量的时间都用于在硬件上测试算子的运行时间，而且相似的算子 config 确实很多，所以通过聚类然后采样的想法确实比较直接。最后的加速效果也不错：

通过结果可以看出来，虽然最后的加速效果很不错，但是对于结果的优化程度几乎没什么变化。说明第二步自适应采样很有效，但是第一步强化学习其实没什么用。讽刺的是这个进的还是 RL4RealLife Workshop... 对于 AutoTVM 来说，目前最主要的问题还是 tuning 的时间过慢。所以 AutoTVM 只能用于 inference，不能用于 training。因为你 tuning 的时间很有可能就比 training 的时间长了...

从上面的图中可以看到，tuning 一次 MobileNet，在 V100 上面都要花差不多 19 个小时，非常缓慢。在我们实验室这种显卡上面，大概就要两到三天了。

在 2019 年 12 月 5 日结束的第二届TVM与深度学习编译器会议上面，也有一个思路类似的 talk。是来自 AWS 的 Improving AutoTVM Efficiency by Schedule Sharing。跟上面的那篇文章非常类似，也是用聚类去优化 AutoTVM。 从上面的图中可以看出，对于每个从模型中抽取的 task，都要进行 turning。这个工作的动机是，如果一个 schedule 在一个 conv2d 上面效果良好，那他在另一个 conv2d 上面的效果应该也还不错。这意味着可以利用一些有代表性的任务来 turning，然后把该任务的 schedule 直接迁移到相似的任务上面去。这里的距离计算方式是 turning space 的重叠比率，然后利用这个距离来聚类。

从上面这个图中可以看出，Schedule Sharing 可以在平均 28% 的调整时间里获得 84% 的加速效果。相关讨论和 PR 在 github issue 上面可以找到。 新的搜索方法，还有一篇 Compiler-Level Matrix Multiplication Optimization for Deep Learning, arXiv。这篇文章只把问题限制在了调 MM 的 tile size 上面，整个搜索空间与问题范围缩小了很多，而且去掉了 cost model，直接用强化学习来指导搜索，其实就相当于有一个很慢但是很准确的 cost model，跟前面讲的第一篇非常相似。（虽然这个 cost model 可能比 XGB 慢了差不多 1000 倍吧 XD） 总结一下上面的几个工作，几乎都是采取了一些很简单的做法，就对 AutoTVM 的整个 turning 时间起到了巨大的提升。说明这方面研究的潜力还是非常大的，如果能压缩到五分钟 turning 完一个网络，说不定就可以用 AutoTVM 来帮助 training。（当然现在来看还都是空谈，因为最好的工作也就是四到五倍的压缩效率，从两天变成半天）

说完了对搜索方法和训练采样方法的一些魔改方法之后，下面应该要说一些对于 AutoTVM 的核心 cost model 的魔改方法了。 目前对于 cost model 的研究集中于 GNN 上面，第二届TVM与深度学习编译器会议上面有一个 UW 的 Talk，题目是 Graph Convolutional Cost Models for TVM ，还有一篇 Simulating Execution Time of Tensor Programs using Graph Neural Networks，ICLR 2019 workshop at Representation Learning on Graphs and Manifolds。这两个工作基本是一样的，都是用 GCN 去优化 cost model。然而怪异的是两个工作的结果都是跟 XGB 在一个类似于估计运行时间的数据集上面的对比，没有最后 end-to-end 的效果提升。 两个工作都是用 AST 建图，大概长这样：

然后用 GCN 求一下 embedding，然后把所有 embedding 都平均一下，然后接个 MLP...

然后没了。

这效果看起来其实也就那样，而且还没测 end-to-end 的性能，估计是实在不能看。

问题定义

上一篇文章讲了 AutoTVM 的大致问题，现在给出数学上面的描述。 首先有一个 \(\mathcal{E}\) 代表所有可能的计算，\(e\in\mathcal{E}\) 就是我们要去优化的计算。对于这个 \(e\) 来说，有一个合法的 schedule space 叫 \(\mathcal{S}_e\)，其中每个合法的 schedule 就叫 \(s\in\mathcal{S}_e\)。\(x=g(e,s)\) 是 \(e\) 跟 \(s\) 通过编译器 \(g\) 生成的 low-level code，\(f(x)\) 为这个 \(x\) 在硬件上面实际运行的时间，那么该问题的定义则变成：\[\underset{s\in\mathcal{S}_e}{\operatorname{argmin}}f(g(e,s))\]

这个问题跟现在很多人研究的 hyper-parameter optimization 非常相似，然而 paper 的作者认为，该问题跟传统的 hyper-parameter optimization 有以下几个区别： 第一个区别就是 tensor optimization 比传统的 hyper-parameter optimization 要快很多。因为超参数搜索优化的目标是神经网络的效果，所以训练一次其实是非常慢的，所以超参数搜索可以尝试很多很复杂的方法来进行优化。（比如 GP-UCB 这种，一次 GP kernel regression 要对一个协方差矩阵求逆，实际上是非常慢的，在为什么基于贝叶斯优化的自动调参没有大范围使用？上面有一定的讨论）而 tensor optimization 这个问题，其实你把真的 tensor 程序放到机器上面跑，最慢其实也就几秒。结果你搞了个复杂的方法，要好久才能预测出来结果，那我还不如真的把程序直接放在机器上面跑呢。不过这样的好处是我们可以获得比超参数搜索多得多的数据。 第二个重大的区别是，对于 hyper-parameter optimization 来说，神经网络就是个黑盒子，我们只能根据一些概率的理论去乱调。而对于 tensor optimization 来说，我们有 AST，这是一个非常有力的信息，因为一切运算的秘密其实都隐藏在 AST 里面。 第三个区别是，tensor optimization 的任务之间其实都是相似的，可以进行 transfer learning。 在上一篇文章中我们看到，其实可能去调整的参数还是很多的，这些参数乘起来会变成非常巨大的搜索空间 \(\mathcal{S}_e\)。我们的目的就是在这个巨大的搜索空间中找到最好的 \(s\)。

搜索框架

paper 作者提出的框架是，先搞一个 cost model \(\hat{f}(x)\)，然后用这个 \(\hat{f}(x)\) 去指导搜索出 \(s_i\)，再把 \((e_i, s_i)\) 放到机器上面跑造出 \(c_i\)，然后再去更新 \(\hat{f}(x)\)。

对于这个 cost model，作者搞了两种实现。第一种是陈天奇的传统艺能——XGBoost，第二种是 TreeGRU。（顾名思义，以前的 GRU 或者 LSTM 都是一个输入，这个有多个输入，然后公式小变了一下，其实都大差不差）因为在实际的运用中，TreeGRU 实在是速度有点不行，所以根本都没有 merge 到 master 上面去，在 github 上面版本其实只有 XGBoost。 很显然，这个 cost model 的输出应该是一个预测该程序在硬件上运行的时间。对于最后的 loss，作者也实现了两种方式，第一种是传统的 regression loss：\[\sum_i(\hat{f}(x_i)-c_i)^2\]

第二种则是只考虑他们的相对快慢：\[\sum_{i,j}log(1+e^{-sign(c_i-c_j)(\hat{f}(x_i)-\hat{f}(x_j))})\]

实验表明，两种 loss 效果差不多。 因为这个搜索空间 \(\mathcal{S}_e\) 很大，我们不能枚举整个空间。这里作者使用的方法是，先在 cost model 的指导下通过模拟退火搞出一个候选集，然后再选出来一个相对比较优的集合在硬件上面进行测试，最后更新 cost model。 那么要如何定义一个相对比较优的集合呢？这个集合要同时兼顾 quality 和 diversity。作者给出的最大化式子是这样的：\[L(S)=-\sum_{s\in\mathcal{S}}\hat{f}(g(e,s))+\alpha\sum_{j=1}^m\left|{\cup_{s\in\mathcal{S}}\{s_j\}}\right|\]

这个东西如果不看代码，其实很难知道他到底在干什么东西。看过代码就知道这个 \(s\) 其实已经经过特征抽取，被平铺为一个向量了，然后 \(m\) 就是把这个平铺的向量切成 \(m\) 段。这个式子的意义就是，使得每个子段都尽可能的不一样，并且运行速度还要尽量小。 为什么这个式子要设计成这个样子，看起来不是非常奇怪吗？而且这个式子要怎么优化呢？其实原因就在于如何优化这个式子上面，这个式子是一个 submodular function，可以通过贪心求一个还算凑合的近似解，具体可以看怎么理解次模函数 submodular function？ 整个算法的大致过程如下：

贝叶斯优化

对于超参数搜索来说，最广为应用的方式就是贝叶斯优化。那么这个问题能不能套贝叶斯优化呢？在文章中，作者通过 bootstrap 搞出好几个 GBDT，然后通过在多个 GBDT 上面输出的预测值来采取 EI 或者 UCB 等函数，再通过上面的那种过程搜索函数的最值。虽然看起来有些奇怪（GP-UCB 那种其实是可以求出 UCB 的解析解），但总体来说其实还是符合贝叶斯优化的精神的。但是实验效果表明，用不用贝叶斯优化，效果其实都差不太多。

迁移学习

他这个迁移学习模块，我觉得写的其实有点奇怪。后面做的实验也不过是对于不同 size 的卷积进行了迁移学习。然而实际上卷积运算的形式是固定的，cost model 测试的也是同一台机器上面的运算速度，所以其实相当于用的就是同一个 cost model，这个东西本身就是通用的。从这个角度看，把 AST 抽取成一个固定长度的特征就是自然而然的。

对于 XGB 来说，就是简单的抽取 AST 中循环变量所代表的 touched memory 和 outer loop length，在文章中这个叫做 context feature。然而问题在于不同的算子循环变量的数量都有可能是不同的，于是在 transfer learning 中，在代码中使用了一种叫 curve sample 的技术，实际上就是采样 context features 变成一个长度固定的 context relation feature。然而为什么这样就可以提高 transfer learning 的效果，其实我也搞的不太清楚。 在 TreeGRU 中，采取的方式是将循环变量的 context feature 通过 TreeGRU fold 起来，从而得到整个 AST 的 embedding。

实验效果

中间那些不同方式的对比实验就不拿出来贴了，反正最后 state of art 是采用 rank loss 的 XGB。这里贴一个端到端的结果：

从结果可以看出，优化效果非常强劲，而且越是那种非 benchmark 的网络（如 DQN），优化效果越好。 当然，这个方法并不是完美的，下一篇文章将陈述一些该方法的问题，并讲解几个 AutoTVM 方向最新的文章与成果。

从 TVM 开始

TVM: an automated end-to-end optimizing compiler for deep learning. OSDI`18 AutoTVM 其实是 TVM 的一个组件，那么先要搞清楚 TVM 是个啥。

Apache TVM (incubating) is a compiler stack for deep learning systems. It is designed to close the gap between the productivity-focused deep learning frameworks, and the performance- and efficiency-focused hardware backends. TVM works with deep learning frameworks to provide end to end compilation to different backends.

简单来说，这是一个深度学习编译器。输入是 high-level DL program (Pytorch TensorFlow etc.) 输出是 low-level optimized code。

本文章的主题其实就是图里面蓝色的那个 Machine Learning-Based Automated Optimizer。 不过在进入主题之前先谈一谈这个 TVM 的意义吧，通过 TVM 的意义其实我们就可以自然的了解到为什么我们需要 AutoTVM。这些内容其实在之前的两篇文章里面都有谈过。 在之前很多厂商都搞过深度学习编译器，比如 TensorFlow XLA、NVIDIA TensorRT 等等。之前的搞法通常都是先把这些乱七八糟深度学习框架前端统一成一个 Graph IR，再对这个 Graph IR 进行一些例如 Operator Fusion 和 Constant Folding 之类的优化，然后将 Graph IR 映射到 XLA 算子或者 cuDNN 中，这些算子很多是由专业的工程师进行手工优化，效果拔群，通过这个过程实现神经网络的高效。 问题在于，你的模型需要在一大坨设备上面跑（比如手机、树莓派、GPU、CPU...）这些设备的运算能力和优化方式都有所不同，那么就需要每个设备都搞一个编译框架，然后由很多很多工程师去实现很多高效的算子用来映射。一个更夸张的发展趋势是，很多 AI 芯片厂商会把一些常用算子（如卷积层）直接设计一个硬件模块去加速，这样会导致只要出一个牛逼网络，那 AI 芯片就会多做一个模块去对网络的某些公共运算进行加速，然后工程师也会设计相关的算子，不停加班，永不失业。 还有个问题就是，比如 Operator Fusion 这种优化，有一些算子（如卷积+池化+relu）的融合模块已经在 cuDNN 中写好了，那么 Operator Fusion 的时候就可以直接对应过去。但是随着 DL 的发展，越来越多算子都可能进行融合，但是因为底层的实现还没做好，导致在图级别的优化会出现捉襟见肘的情况。很多时候优化会倾向于使用成熟的算子，避免那些还没有优化很好的融合方式。 以及一个在 learning 领域广泛出现的问题——长尾分布。对于那些通用的优化来说，优化一下可以产生很大的性能提升，但是对于那些长尾的优化来说，优化一次的代价过高，产生的利益也没有那么丰厚。 显然，解决问题的核心就在于如何对不同的硬件和不同的算子进行一波通用的优化。

AutoTVM 初探

对于上面这个问题，TVM 给我们的答案是 AutoTVM，一个 Automating Optimization。 在谈论这个问题之前，我们还要再复习一下体系结构的内容。其实这个在前两篇文章中也讲过很多。

一个简单的 CPU 架构可以概括为上面这样，这个 CPU 有两个核心，每个核心都有自己 L12 cache，然后也支持 SIMD，也就是 fetch 一个指令可以在两个 PU 上面运算。当然现在很多处理器都支持超线程，也就是说一个核心有两个硬件线程，每个核心在操作系统中其实是两个核心。然后现在最厉害的 SIMD 指令叫做 AVX-512，可以在每个 cycle 同时对 16 个 float32 进行运算。 所以对于 CPU 而言，最为常用的优化其实就是三种：Parallelization（多核并行）、Vectorization（SIMD）、Cache。还有一些诸如是否进行循环展开之类的优化。 下面用 TVM 实现一个最简单的矩阵乘法，程序来自于 AutoTVM 教程

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

def matmul_v0(N, L, M, dtype):
    A = tvm.placeholder((N, L), name='A', dtype=dtype)
    B = tvm.placeholder((L, M), name='B', dtype=dtype)

    k = tvm.reduce_axis((0, L), name='k')
    C = tvm.compute((N, M), lambda i, j: tvm.sum(A[i, k] * B[k, j], axis=k), name='C')
    s = tvm.create_schedule(C.op)

    # schedule
    y, x = s[C].op.axis
    k = s[C].op.reduce_axis[0]

    yo, yi = s[C].split(y, 8)
    xo, xi = s[C].split(x, 8)

    s[C].reorder(yo, xo, k, yi, xi)

    return s, [A, B, C]

上面的程序只包括了 Cache 优化，方式就是常见的矩阵乘法循环变量 reorder 和矩阵分块。注意，这里矩阵分块的 magic number 是 8, 也就是说把这个矩阵分成 8*8 的小块，使得 cache 的 hit rate 更高。 但是对于这样的 magic number，没有经验的人是很难找到最优的数值的。而且这个数值跟很多硬件因素都有关系，很多时候我们不能对硬件的所有因素都产生全面的了解，这个时候就需要 AutoTVM 的帮助了。 用起来也很简单，其实就是指名一下哪些参数需要搜索。比如下面的程序就是指明要搜索 tile size：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

@autotvm.template
def matmul(N, L, M, dtype):
    A = tvm.placeholder((N, L), name='A', dtype=dtype)
    B = tvm.placeholder((L, M), name='B', dtype=dtype)

    k = tvm.reduce_axis((0, L), name='k')
    C = tvm.compute((N, M), lambda i, j: tvm.sum(A[i, k] * B[k, j], axis=k), name='C')
    s = tvm.create_schedule(C.op)

    # schedule
    y, x = s[C].op.axis
    k = s[C].op.reduce_axis[0]

    ##### define space begin #####
    cfg = autotvm.get_config()
    cfg.define_split("tile_y", y, num_outputs=2)
    cfg.define_split("tile_x", x, num_outputs=2)
    ##### define space end #####

    # schedule according to config
    yo, yi = cfg["tile_y"].apply(s, C, y)
    xo, xi = cfg["tile_x"].apply(s, C, x)

    s[C].reorder(yo, xo, k, yi, xi)

    return s, [A, B, C]

这其实也是系统设计的艺术，首先 TVM 把运算与 schedule 进行解耦，然后一部分 schedule 由用户进行实现，一部分需要精细调整的内容由一个 ML 算法进行搜索，从而达到一个易用性和性能的 trade-off。相对应的是 Facebook 做的 Tensor Comprehension，要解决的问题跟 TVM 是类似的，但是选择的是利用 polyhedra model 进行一个类似端到端的优化过程，但是优化的空间其实比 TVM 这种 schedule space 模型要差一些，所以效果也会打些折扣。一些相关的讨论可以在如何看待Tensor Comprehensions？与TVM有何异同？上面看到。 对于 GPU 来说，由于架构跟 CPU 存在区别，所以优化的方式也不太一样：

可以看到，相对 CPU 来说，GPU 多了很多可以向量化的计算单元，甚至还有 Tensor Core 可以对计算进行张量化。而且 L1 cache 可以由程序员来进行主动的控制，作为线程之间的缓存，提供了很大的自由性。 在 GPU 里面还有线程与线程块的概念。几个 thread 会统一放到一个 block 中。同一个 block 中的线程会共享同一个 L1 cache 或者 shared memory，合理的分配 shared memory 会显著减少读写时间。 在 GPU 上面优化矩阵乘法，我们可以这样写，代码来自 Dive in DL Compiler：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

def matmul_gpu(n):
    A, B, C = d2ltvm.matmul(n, n, n)
    s = tvm.create_schedule(C.op)
    # Create caches
    A_shared = s.cache_read(A, "shared", [C])
    A_local  = s.cache_read(A_shared, "local", [C])
    B_shared = s.cache_read(B, "shared", [C])
    B_local  = s.cache_read(B_shared, "local", [C])
    C_local = s.cache_write(C, "local")
    # Split each axis into block axis, thread axis, and inner axis
    x, y = s[C].op.axis
    xb, xo, xi = split(s[C], x, (block_size, tx))
    yb, yo, yi = split(s[C], y, (block_size, ty))
    s[C].reorder(xb, yb, xo, yo, xi, yi)
    # Note that we bind yb to blockIdx.x instead of blockIdx.y
    bind_thread(s[C], (yb, xb, yo, xo),
                ("blockIdx.x", "blockIdx.y", "threadIdx.x", "threadIdx.y"))
    # Schedule C_local
    s[C_local].compute_at(s[C], yo)
    yi, xi = s[C_local].op.axis
    k, = s[C_local].op.reduce_axis
    ko, ki = s[C_local].split(k, tk)
    s[C_local].reorder(ko, ki, yi, xi)
    # Optimize read caches of A and B with cooperative fetching
    def optimize_read_cache(shared, local):
        s[shared].compute_at(s[C_local], ko)
        s[local].compute_at(s[C_local], ki)
        y, x = s[shared].op.axis
        # Note that we must split into block_size parts to reuse
        # the previous axis threads
        yo, yi = s[shared].split(y, nparts=block_size)
        xo, xi = s[shared].split(x, nparts=block_size)
        s[shared].reorder(yo, xo, yi, xi)
        bind_thread(s[shared], (yo, xo), ("threadIdx.y", "threadIdx.x"))
    optimize_read_cache(A_shared, A_local)
    optimize_read_cache(B_shared, B_local)
    return s, (A, B, C)

看起来有点复杂，其实就是 shared memory 的一些分配。从代码中可以看到，有很多 split 的操作，事实上对于缺乏经验的工程师来说，确定这些 split size 是非常困难的。 在 AutoTVM 教程中我们可以找到一个相对通用的模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

@autotvm.template
def conv2d_no_batching(N, H, W, CO, CI, KH, KW, stride, padding):
    assert N == 1, "Only consider batch_size = 1 in this template"

    data = tvm.placeholder((N, CI, H, W), name='data')
    kernel = tvm.placeholder((CO, CI, KH, KW), name='kernel')
    conv = topi.nn.conv2d_nchw(data, kernel, stride, padding, dilation=1, out_dtype='float32')
    s = tvm.create_schedule([conv.op])

    ##### space definition begin #####
    n, f, y, x = s[conv].op.axis
    rc, ry, rx = s[conv].op.reduce_axis

    cfg = autotvm.get_config()
    cfg.define_split("tile_f", f, num_outputs=4)
    cfg.define_split("tile_y", y, num_outputs=4)
    cfg.define_split("tile_x", x, num_outputs=4)
    cfg.define_split("tile_rc", rc, num_outputs=3)
    cfg.define_split("tile_ry", ry, num_outputs=3)
    cfg.define_split("tile_rx", rx, num_outputs=3)
    cfg.define_knob("auto_unroll_max_step", [0, 512, 1500])
    cfg.define_knob("unroll_explicit", [0, 1])
    ##### space definition end #####

    # inline padding
    pad_data = s[conv].op.input_tensors[0]
    s[pad_data].compute_inline()
    data, raw_data = pad_data, data

    output = conv
    OL = s.cache_write(conv, 'local')

    # create cache stage
    AA = s.cache_read(data, 'shared', [OL])
    WW = s.cache_read(kernel, 'shared', [OL])
    AL = s.cache_read(AA, 'local', [OL])
    WL = s.cache_read(WW, 'local', [OL])

    # tile and bind spatial axes
    n, f, y, x = s[output].op.axis
    bf, vf, tf, fi = cfg["tile_f"].apply(s, output, f)
    by, vy, ty, yi = cfg["tile_y"].apply(s, output, y)
    bx, vx, tx, xi = cfg["tile_x"].apply(s, output, x)
    kernel_scope = n  # this is the scope to attach global config inside this kernel

    s[output].bind(bf, tvm.thread_axis("blockIdx.z"))
    s[output].bind(by, tvm.thread_axis("blockIdx.y"))
    s[output].bind(bx, tvm.thread_axis("blockIdx.x"))
    s[output].bind(vf, tvm.thread_axis("vthread"))
    s[output].bind(vy, tvm.thread_axis("vthread"))
    s[output].bind(vx, tvm.thread_axis("vthread"))
    s[output].bind(tf, tvm.thread_axis("threadIdx.z"))
    s[output].bind(ty, tvm.thread_axis("threadIdx.y"))
    s[output].bind(tx, tvm.thread_axis("threadIdx.x"))
    s[output].reorder(n, bf, by, bx, vf, vy, vx, tf, ty, tx, fi, yi, xi)
    s[OL].compute_at(s[output], tx)

    # tile reduction axes
    n, f, y, x = s[OL].op.axis
    rc, ry, rx = s[OL].op.reduce_axis
    rco, rcm, rci = cfg['tile_rc'].apply(s, OL, rc)
    ryo, rym, ryi = cfg['tile_rx'].apply(s, OL, ry)
    rxo, rxm, rxi = cfg['tile_ry'].apply(s, OL, rx)
    s[OL].reorder(rco, ryo, rxo, rcm, rym, rxm, rci, ryi, rxi, n, f, y, x)

    s[AA].compute_at(s[OL], rxo)
    s[WW].compute_at(s[OL], rxo)
    s[AL].compute_at(s[OL], rxm)
    s[WL].compute_at(s[OL], rxm)

    # cooperative fetching
    for load in [AA, WW]:
        n, f, y, x = s[load].op.axis
        fused = s[load].fuse(n, f, y, x)
        tz, fused = s[load].split(fused, nparts=cfg["tile_f"].size[2])
        ty, fused = s[load].split(fused, nparts=cfg["tile_y"].size[2])
        tx, fused = s[load].split(fused, nparts=cfg["tile_x"].size[2])
        s[load].bind(tz, tvm.thread_axis("threadIdx.z"))
        s[load].bind(ty, tvm.thread_axis("threadIdx.y"))
        s[load].bind(tx, tvm.thread_axis("threadIdx.x"))

    # tune unroll
    s[output].pragma(kernel_scope, 'auto_unroll_max_step', cfg['auto_unroll_max_step'].val)
    s[output].pragma(kernel_scope, 'unroll_explicit', cfg['unroll_explicit'].val)

    return s, [raw_data, kernel, conv]

对于这些 knob，有个简单进行解释的图表：

好了，现在对 AutoTVM 已经有了一些感性的理解了。不过这个开头写的有点多，以上内容先算一篇，下一篇我们讲 AutoTVM 的具体实现。

Lecture 7: Automatic Code Generation - TVM Stack

现在深度学习的框架非常多，而这些乱七八糟框架写出来的代码通常又跑在乱七八糟的设备上。这其中最为关键的问题就是：如何让深度学习代码在不同的设备上都跑出最好的效果。 众所周知，如果软件架构出现了什么难以解决的问题，那就加个中间层，看看能不能解决。如果还不能解决，那就再加个中间层（ 目前各家（比如 TensorFlow XLA、NVIDIA TensorRT 等）采用的设计思路就是将各个框架写出来的网络转换成一种统一的表示形式，也就是所谓的 Graph IR。

当然了，最后 IR 如果想要运行，那你还是要把 IR 变成机器码才可以。对于不同的硬件平台、数据格式、精度、线程结构都要写一堆不同的代码生成规则和优化规则。 这个问题是 TVM 的技术背景了。前面说了，如果还解决不了问题，那就再加个中间层。TVM 加的中间层就是所谓的 Tensor Expression Language 表示方法。这个 idea 来自于 Halide，核心在于把代码的计算和调度分开。

举个具体的例子，最简单的一个向量相加，用 TVM 实现起来长这样：

1
2

C = tvm.compute((n,), lambda i: A[i] + B[i])
s = tvm.create_schedule(C.op)

得到的 C 代码是：

1
2
3
4

for (int i = 0; i < n; ++i)
{
    C[i] = A[i] + B[i];
}

加上一些额外的循环控制（就是上篇文章中讲的 cache 优化）

1
2
3

C = tvm.compute((n,), lambda i: A[i] + B[i])
s = tvm.create_schedule(C.op)
xo, xi = s[C].split(s[C].axis[0], factor=32)

生成的代码就变成了：

1
2
3
4
5
6
7
8
9
10
11

for (int xo = 0; xo < ceil(n / 32); ++xo)
{
    for (int xi = 0; xi < 32; ++xi)
    {
        int i = xo * 32 + xi;
        if (i < n)
        {
            C[i] = A[i] + B[i];
        }
    }
}

甚至可以绑定特定的变量：

1
2
3
4
5
6

C = tvm.compute((n,), lambda i: A[i] + B[i])
s = tvm.create_schedule(C.op)
xo, xi = s[C].split(s[C].axis[0], factor=32)
s[C].recorder(xi, xo)
s[C].bind(xo, tvm.thread_axis(“blockIdx.x”)
s[C].bind(xi, tvm.thread_axis(“threadIdx.x”)

这样就出来一个 CUDA kernel 代码：

1
2
3
4
5

int i = threadIdx.x * 32 + blockIdx.x;
if (i < n)
{
    C[i] = A[i] + B[i];
}

TVM 的核心就是一些调度原语，比如下图这些：

还有 TVM 最有趣的部分 AutoTVM，可以用 learning 的方式对代码进行自动优化，不过这个东西在课程中并不是重点，所以只是简单的提及了一下。

在我理解，TVM 就是一个 Graph IR 的优化框架，或者说是底层算子的高阶表示。

Lecture 8: Hardware Specialization in Deep Learning

这一讲主要介绍 TVM 技术栈中的重要部分 VTA。对于硬件我不是特别熟悉，也不是特别感兴趣，所以这章就随便看看了。 VTA: 开源AI芯片栈 Tianqi 的这篇文章概括性的讲述了 VTA 的意义。 总体来说，就是根据 RISC 的思想，设计了一套硬件架构。TVM 充当编译器，VTA 充当底层计算硬件，两者配合达到良好的效果。

Lecture 9: Memory Optimization

这一讲我觉得还蛮有意思的，讲的是深度学习的内存优化。 主要内容来自于这篇论文：Training Deep Nets with Sublinear Memory Cost 这一讲的核心问题在于，为什么我们要用 autograd 来形成计算图，而不是直接使用 BP？

这个问题的答案其实就本节课的标题：Memory Optimization。我们要优化内存的使用，所以要用计算图。 假如只有前向传播的话，我们其实可以通过计算图的层次结构来复用内存：

这个内存复用有两个原则：Inplace 和 Normal Sharing。 所谓 Inplace 就是输出的内容直接存到输入内存的地方。Normal Sharing 则是重复使用那些不被需要的内存。 显然 Inplace 也有一些失效的时候，当输入的内容还被其他输出依赖时，我们之前的输出就不能使用这块内存。

回到我们最开始的问题，为什么我们要用 autograd 的计算图来代替 BP？

这个问题其实没有在 slides 中说清楚。看了看其他人的理解，都是觉得 BP 要存中间结果，所以比较费内存。但是计算图也要存中间结果啊？所以有点费解。我的理解是，计算图可以更好的捕获变量之间的依赖性，就像上面这个图一样。如果用 BP，每一步中间结果都要存起来，但是如果用 autograd，就可以全程 Inplace。 后面讲了一些利用两个原则优化内存的例子，都不是很难理解。但是问题在于，不管我们怎么复用，整体的空间复杂度仍然是线性增长的。

这时候有个牛逼做法就是保存 \(\sqrt{N}\) 个中间节点，每次需要反向传播的时候，就从这个中间节点往下算 \(\sqrt{N}\) 步。这样内存就是 \(O(\sqrt{N})\) 级别了，是不是跟 ICPC 竞赛里面常见的分块算法一模一样？ 感觉内存优化这部分还是有些东西不太清楚，需要回头看一下论文。看完论文补充一下这部分的内容。 接下来是 assignment 2。 这次作业感觉工作量还是很大的，首先是要满足作业的第一个要求，把 test_tvm_op.py 里面的所有测试都跑通：

这一步主要要参考 TVM Documentation 的写法，把这些算子都补齐。其中一些算子的作用还是比较迷惑的，要看测试才知道是什么意思。TVM 的写法有些地方也比较古怪，要自己慢慢尝试。 然后是满足第二个要求，跑通 mnist 的两个方法：

这一步是要把 autodiff 的内容补全，其实很简单，但是有些地方可能不太清楚他到底想让你写什么东西，仔细看看调用代码，然后把函数补全就好了。 从上面的截图可以看出，我们自己写的算子效果非常垃圾，跑一遍 mlp 要 80s，下面就是如何优化矩阵乘法算子了：

主要思路还是来自于 Lecture 6，只要简单的把矩阵分一下块，调整一下循环顺序，然后再并行一下，就可以得到 20x 的优化效果。

1
2
3
4
5
6
7

s = tvm.create_schedule(C.op)
xo, yo, xi, yi = s[C].tile(C.op.axis[0], C.op.axis[1], x_factor=32, y_factor=64)
xk, yk = s[C].split(k, factor=8)
s[C].reorder(xo, yo, xk, xi, yi, yk)
s[C].parallel(xo)
s[C].unroll(yk)
f = tvm.build(s, [A, B, C], tgt, target_host=tgt_host, name=func_name)

更多精细的优化在 如何利用TVM快速实现超越Numpy的GEMM 这篇文章中可以找到，非常牛逼。

Lecture 10: Parallel Scheduling

在内存分配之后，第10讲讲的是并行调度的问题。 首先讲了一下 Model Parallel 和 Data Parallel 的模式，比较基础。

因为现实的运算中存在着各种复杂的同步关系，所以我们需要一个自动调度器。 这个自动调度器需要调度各种各样的资源，包括数据、随机数生成器、网络通信等等；也要调度各种各样的操作。 对于深度学习来说，基于计算图的调度就非常自然。因为计算图是一个 DAG，各种依赖复用关系都非常明显。但是基于计算图的这种调度对于一些什么写后读、读后写的问题可能不是特别敏感，所以还增加需要 mutation aware 这种调度方式。

后面给了一个很简单的队列调度的例子，看看就能懂。

Lecture 11: Distributed Training and Communication Protocols

这一讲讲的主要是参数的 Synchronization 问题。 首先介绍了一种叫做 Allreduce 的操作，感觉就是在中间把分布式程序拦了一下：

然后讲了几种网络拓扑对 Allreduce 操作的影响，看起来比较简单。 之后介绍了 Parameter Server，这个在实习的时候接触的蛮多，其实就是个 KV，用 PS 去更新和获取参数，他们内部甚至搞了个无锁 hash 表...

Lecture 12: Model Serving

终于到了最后一讲，这一讲主要讲的是模型部署在现实应用中的问题。

主要分为模型压缩和服务系统两个部分来进行讲解。 模型压缩的第一个部分是矩阵/向量分解，这个矩阵分解套路很简单很常见，向量分解没见过，也没太看懂，有空可以仔细研究一下。大概是把一个 cnn 分解成几个 cnn，但是能达到相似的效果。 然后网络剪枝，其中一个思路是 prune the connections。想法很简单，每次增加前向传播的 theshold，减少连通性。 第二个思路是 weight sharing，首先对参数进行聚类，相似的参数就看做一个参数，再对他们进行统一的更新。 模型的低比特量化也是一个很有趣的思路，通过降低模型数据存储的精度，来压缩模型并且尽量保持精度。 还有知识蒸馏，用一个大模型去训练一个小模型。上周末实验室讲座有个大哥讲的就是这个内容，但是我因为家里有急事所以没听到，不过获得了 PPT，之后自己补一补吧。 第二个部分就是服务系统了，服务系统的目标是编写程序的灵活性、GPU 上面的高效率以及延迟满足 SLA（service-level agreement）。 然后讲了一个叫 Nexus 的系统，看起来有些难以理解，先略过吧~

Chenfan Blog——CSE 599W： Systems for ML

知乎专栏：SysML/DL机器学习系统

手把手带你遨游TVM

不过上面这两个参考资料，第一个有点过于简略，第二个虽然写的很好但是已经五个月没有更新了...可能是坑了，所以后面的内容还是要靠自己慢慢研究了... 第三篇是蓝色大大的 TVM 入门文章，写的非常赞，可以清晰的理解 TVM 存在的意义与解决的问题。

Lecture 1-2

介绍了一波深度学习的基本概念，常见的各种 CNN、RNN、激活函数、BatchNormal、梯度消失与梯度爆炸都用一节课介绍了一通。因为我之前学过 Ng 在 coursera 上面的 Deep learing 专项，所以对这些都很了解了，而且这些内容的资源满大街都是，就不在这里继续介绍了。 第二讲是一个实验课，用 mxnet 搭建一个基础的网络，虽然我之前系统看过沐神的《动手深度学习》，但是我看的是 github 上面的 pytorch 魔改版，mxnet 只在上半年的华为软挑的时候用过一下，不是特别了解。但是这个 gluon api 似乎跟 pytorch 大同小异，这里也不多废话了，有兴趣自己看看原版《动手深度学习》就好了。

Lecture 3: Overview of Deep Learning System

学习过什么是 Deep Learning 了，那么啥是 Deep Learning System 呢？ 在我的理解其实就是从调包到真正计算出结果的全过程，就是 Deep Learning System，也就是通常所说的算法的真正落地。 在这个课程中，Deep Learning System 从高层到底层分成了三个部分：

第一部分就是调包的封装 API，第二部分表示调完包后对调包代码的优化与 Scheduling，第三部分就是最下面的一些高效的 GPU kernel 实现、不同硬件后端的部署等等。 那么一个 Deep Learning 框架在 API 层需要包括什么内容呢？为什么大家要用框架而不是自己从头写呢？ 下面这个图就回答了这个问题，现在的模型越来越大，实现起来需要注意的内容也就越来越多，如果每步都由我们自己来进行链式求导算梯度的话，可能就没有这么多转行深度学习的大哥了（

计算图是一个 Deep Learning 框架的基本概念，节点表示运算操作，边表示数据依赖，这里展示了一个最简单的 Logistic Regression 计算图实例： 首先是计算 loss 之前的前向传播，其实就是一个最简单的矩阵乘法加一个 softmax：

然后是将 softmax 输出的东西搞一个交叉熵作为 loss，相当于最大化 liklihood:

然后是自动微分：

最后通过 SGD 来更新梯度：

结合上面的所有步骤，我们就得到了一个计算图：

最上层的 API 做了最简单的介绍，下面就是中间的 System 部分，讲的是对计算图的优化和对计算的调度。 计算优化最简单的一种就是 memory 优化，比如增加 cache 利用率之类的。因为我们的代码通常跑在多个线程甚至多个计算设备上面，所以并行调度也是非常重要的。最简单的一种并行调度如下图，这是一个 mxnet 代码，因为计算 C 和计算 B 是完全独立的，所以这两个部分可以并行化。

然后简单介绍一下最底层的情况，我们训练完了 model，要部署到不同的设备上。想必大家也都听过各种各样的厂商搞出过各种各样的部署方法，为了产生更好的模型性能：

TVM 就是为了解决这样的问题而诞生的，只要我们都搞成中间代码，全栈自动编译优化，这样 model 就可以非常简单的部署到不同的设备上了：

这门课将在接下来详细介绍 Deep Learning System 的三个部分。

Lecture 4: Backpropagation and Automatic Differentiation

第四节课讲的是 Deep Learning 中的求导方式——Auto-Diff. 首先我们要了解现代计算机实现求导通常有哪些方式。 第一种叫做 Symbolic Differentiation，如图所示：

通过程序来维护整个求导的式子，然后把变量带入就得到最终的导数。这种做法的缺点在于表达式是一个很难维护的东西，最后要维护的东西就会越来越多。正常 Deep Learning 框架显然不应该选择这种求导方式... 第二种叫做 Numerical Differentiation，这种求导形式非常简单，看起来很适合计算机：

但是有个很关键的问题是，这种求导方法要进行两次正向传播，跑起来很慢，而且误差会比较大。但是因为其实现方式的简单，所以这是一个非常好的 grad check 工具。Ng 在 DL 专项里面也是用这种方式去进行 grad check 的。 第三种叫做 Backpropagation，现代 Deep Learning 的核心：

虽然这种做法很适合计算机，效率也不错。但有一个关键的问题，我们在做正向传播的时候要记录中间结果，这样才能在后面进行反向传播，内存耗费很大。而且难以形成计算图，无法进行通用的并行化。 这时候就需要掏出第四种方法，叫做 Automatic Differentiation：

其实思路非常简单，看伪代码就看的出来。这种方法就是通过反拓扑序去生成一个反向的计算图，因为是计算图所以不用保存任何中间变量；也因为是计算图，所以可以进行通用的并行化与代码优化，两全其美！ 接下来就是 Auto-diff 的具体实现，也就是 assignment 1。这次作业的难度不是太大，前面就是一些算子的简单实现，后面有两段重要的代码：

1
2
3
4
5
6
7
8

for node in topo_order:
    if isinstance(node.op, PlaceholderOp):
        continue
    input_vals = [node_to_val_map[x] for x in node.inputs]
    res = node.op.compute(node, input_vals)
    if isinstance(res, np.ndarray) == False:
        res = np.array(res)
    node_to_val_map[node] = res

这段是前向传播的部分，记录每个节点计算出来的结果。前向传播需要正向拓扑序。

1
2
3
4
5
6
7

for node in reverse_topo_order:
    grad = sum_node_list(node_to_output_grads_list[node])
    node_to_output_grad[node] = grad
    input_grads = node.op.gradient(node, grad)
    for i in range(len(node.inputs)):
        node_to_output_grads_list[node.inputs[i]] = node_to_output_grads_list.get(node.inputs[i], [])
        node_to_output_grads_list[node.inputs[i]].append(input_grads[i])

这段是反向形成 Auto-diff 计算图的过程，跟伪代码很像。进一步解释一下：按照反拓扑序来遍历节点，计算到这个节点就代表着所有相关的梯度都计算完了。现在需要把相关的梯度都加起来，然后加起来的梯度作为这个节点向后面传播的梯度。整个过程很容易理解。

Lecture 5: GPU Programming

这一讲涉及到的部分比较底层，虽然浙大本科的硬件三连质量非常高，但是对于 GPU 架构接触还是非常少的，又没有视频，只能尽力看一看了... 首先讲的是 CPU 的架构，很容易理解，CPU 跟内存有关的操作都很慢，所以才有各种指令预测、cache 优化算法之类的折磨着一代有一代的计算机学子：

而 GPU 则是给 CPU 加了一大堆计算资源，比普通的指令向量化更加强劲：

从这个图可以看出来，GPU 的寄存器数量非常大，所以他可以开很多线程去并行计算，但是从这个图也可以看出来，GPU 的 cache 小的可怜，所以 GPU 适用于那种轻内存读写、重计算的任务，也就是大量的并行计算任务。

然后讲了 CUDA Programming Model，因为我完全不懂 CUDA 编程，所以后面的东西都是我瞎理解的，不一定对。 这个叫做 SIMT 的 Model 就是把几个 thread group 成一个 block，再把几个 block group 成一个 grid，block 可以以任何顺序在 GPU 上面调度。

然后是个最简单的 cuda 程序——vector add。过程非常简单，跟操作系统里面查页表差不多，这里通过 block 下标和 thread 下标可以得到向量加法的下标，然后每个线程都执行一样的代码就可以了。

后面讲了一个窗口 sum 的例子，因为他图画的不太好，所以有点难以理解，我尽力理解了一下：

最简单的实现方式是这样的：

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

#define RADIUS 3
__global__ void windowSumNaiveKernel(const float* A, float* B, int n) 
{    
    int out_index = blockDim.x * blockIdx.x + threadIdx.x;    
    int in_index = out_index + RADIUS;    
    if (out_index < n) {
        float sum = 0.;
        for (int i = -RADIUS; i <= RADIUS; ++i) {
            sum += A[in_index + i];        
        }
        B[out_index] = sum;
    }
}

为什么说他图画的不太好，因为他的图跟代码的下标其实是对应不上的。B[0] 的结果应该是从 A[0] 到 A[6] 的和才对，这样下标就和代码完全对应上了。 这个实现非常简单，所以有很大的优化空间。其中最脑残的地方就是每个线程都读了 7 次 A，这样对 GPU 这种小 cache 来说是非常残忍的。

所以一个非常简单的优化就是从一个线程读 7 次 A，变成一个 block (假设有四个线程) 读 9 次 A。

那么下面的实现就很好理解了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

__global__ void windowSumKernel(const float* A, float* B, int n) {
    __shared__ float temp[THREADS_PER_BLOCK + 2 * RADIUS];
    int out_index = blockDim.x * blockIdx.x + threadIdx.x;
    int in_index = out_index + RADIUS;
    int local_index = threadIdx.x + RADIUS;
    if (out_index < n) {
        temp[local_index] = A[in_index];
        if (threadIdx.x < RADIUS) {
            temp[local_index - RADIUS] = A[in_index - RADIUS];
            temp[local_index + THREADS_PER_BLOCK] = A[in_index+THREADS_PER_BLOCK];
        }
        __syncthreads();
        float sum = 0.;
        for (int i = -RADIUS; i <= RADIUS; ++i) {
            sum += temp[local_index + i];
        }        
        B[out_index] = sum;    
    }
}

其中比较奥妙的地方是 if (threadIdx.x < RADIUS) 这个语法块，其实也不难理解，就是把两边的 RADIUS 部分充满。最后是一个简单的矩阵乘法程序：

Lecture 6: Optimize for Hardware Backends

这一讲处于计算图和硬件之间。 首先讲了一些体系结构的基本知识，比如多级 cache 之类的，然后讲了矩阵乘法的 cache 优化，非常基础。 最简单的矩阵乘法如下图所示：

像上面这样直接做矩阵乘法，其实对 cache 的利用率并不高，更好的方式是把矩阵分成很多个小块：

分块的方法可以缩小从下级 cache 到寄存器的 cost，有人想那我直接把 v1、v2 高的大一点，这样不就可以优化更多了吗？ 但是通常来说，寄存器非常小，很难存下一整列或者一整行，所幸 CPU 的 cache 通常比较大，也许可以存下：

把对寄存器的优化和 L1 cache 的优化相结合，就得到了下面这种比较复杂的优化方式：

对于 CPU 来说，代码优化可能集中于 Reuse memory 上面，而 GPU 的优化则是集中于 Reuse among threads 上。（这段其实不太懂，我理解就是跟前一讲的那个 window sum 一样，优化复用不同线程的内存）

对于计算图的代码优化，其实套路千变万化：

为了解决这样的优化问题，我们就需要本门课的核心内容——TVM 了！

看上去傻傻的 AdaBoost

对于普通的集成学习来说，其实最后的结果就是不同方法的线性组合，以二分类问题（1，-1）为例，最后的结果在数学上可以表示为： \[G=sign(\sum_{t=1}^T\alpha_t g_t(x_n))\]

上面的 \(g_t\) 就代表不同的学习方法，而 \(\alpha_t\) 代表着每个学习方法的权重。 在 AdaBoost 中，最关键的一点就是对于错误函数的修改。AdaBoost 使用的是带权重的错误函数，\(u_n\) 代表着每个样本点犯错误的权重： \[E_{in}^u(h)=\frac1N\sum_{n=1}^N u_n\cdot err(y_n,h(x_n))\]

我们就是要使用不同的 \(u_n\) 来的得到不同的方法 \(g_t\)。显然，全都差不多的 \(g_t\) 最后集成学习出来的效果肯定很垃圾。从参数上面思考可以看出，模型 \(g_t\) 是通过参数 \(u_n^t\) 生成的，而模型 \(g_{t+1}\) 则是通过参数 \(u_n^{t+1}\) 来生成的。我们想让 \(g_t\) 和 \(g_{t+1}\) 产生足够大的差距，其实就是让 \(u_n^{t+1}\) 对应的 error 在 \(g_t\) 上表现很差就好了。 什么叫表现的差呢？对于分类预测来说，最差的结果其实就是扔硬币，也就是说达到百分之 \(50\) 的错误率，这个结果已经是最差的了。我们就是要通过构造 \(u_n^{t+1}\) 使得 \(g_t\) 在这个 error 上的错误率接近 \(0.5\)。

AdaBoost 的做法很简单，如果 \(g_t\) 的错误率为 \(\epsilon_t\) 的话，那么构造一个尺度因子： \[\diamond t=\sqrt{\frac{1-\epsilon_t}{\epsilon_t}}\]

对于正确的 \(u_n^t\) 可以乘上 \(\diamond t\)，对于错误的 \(u_n^t\)，可以除上 \(\diamond t\)。这样就会使得正确的和错误的参数 \(u_{n+1}^t\) 达到平衡，从而达到放大错误、缩小正确的目的，使得 \(g_t\) 在新 error 上面的错误率等于 \(0.5\)。 现在有了生成每个 \(g_t\) 的方法，那每个方法的参数 \(\alpha_t\) 应该是什么呢？一个直观的想法是：生成完方法之后，再对这些方法进行线性组合的优化，然后来求出 \(\alpha_t\)。这样固然是可以的，但是其实我们可以通过数学推导，来直接算出这个 \(\alpha_t\)。这里先下结论，一会儿再进行数学推导： \[\alpha_t=ln(\diamond t)\]

最简单的一种 AdaBoost 方法叫做 AdaBoost-Stump。在 AdaBoost-Stump 中，每个小方法都只能在某个维度上面画直线来对训练集进行分类。但就是这样简单的方法，可以通过 Boost 组合的方式达到非常好的效果，这就是 AdaBoost 的神奇之处。 现在我们想利用 AdaBoost 把决策树来组合起来。但是问题来了，首先是 error 函数如何参与决策树的分支操作，这个参与起来会比较麻烦。比较简单的做法是直接对决策树屏蔽了 \(u_n\) 参数。然后通过 \(u_n\) 参数来对训练集进行采样，来达到不同 error 函数的效果。这样决策树就是原来的决策树，不需要进行任何的修改。 另一个问题就是，很多决策树都是直接把叶子剖分到单个结点或者单个类别。这样的做法必然会导致这个决策树在测试集上面的错误率 \(\epsilon_t\) 等于 \(0\)。这样我们就没有办法通过 \(\diamond t\) 来产生下一个垃圾方法了。当然解决这个问题的方法也很简单，对决策树进行剪枝和采样数据不全部采样都是可以尝试的做法。这个方法叫做 AdaBoost-DTree。值得注意的一点是：如果我们的决策树的高度限制为 \(1\)，也就是说只能做一次划分，那么这个方法就跟 AdaBoost-Stump 没有任何区别啦。也就是说 AdaBoost-Stump 是 AdaBoost-DTree 的退化。

奥妙重重的 AdaBoost

还记得上面的 \(\alpha_t\) 吗？下面就是通过推导 \(\alpha_t\) 来发现 AdaBoost 的奥妙之处了。当然过程中其实涉及到一些高深的数学知识，但是因为我都不会，所以很多地方可能会讲的很“民科”。 上面说过 \(u_n^{t+1}\) 的求法：对于正确的 \(u_n^t\) 可以乘上 \(\diamond t\)，对于错误的 \(u_n^t\)，可以除上 \(\diamond t\)。通过数学式子其实可以将他们归纳成一个规律： \[u_n^{(t+1)}=u_n^{(t)}\cdot \diamond_t^{-y_ng_t(x_n)}=u_n^{(t)}\cdot exp(-y_n\alpha_tg_t(x_n))\]

如果初始值 \(u_n^{(1)}=\frac1N\) 的话，就有： \[u_n^{(T+1)}=u_n^{(1)}\cdot \prod_{t=1}^Texp(-y_n\alpha_tg_t(x_n))=\frac1N\cdot exp(-y_n\sum_{t=1}^T\alpha_tg_t(x_n))\]

通过上面的式子可以发现一个很显然的事情：\(u_n^{(T+1)}\) 与 \(exp(-y_n\sum_{t=1}^T\alpha_tg_t(x_n))\) 成正比。 将 \(\sum_{t=1}^T\alpha_tg_t(x_n)\) 从另外一个角度来看，可以发现这个其实是一个对 \(x_n\) 特征转换的线性组合，跟 SVM 中的那个完全一致。其实这个式子就是没有进行正则化的分界距离，跟 \(y_n\) 相乘的话，可以感性的理解成跟 SVM 一样，这个距离越大越好。 使得 \(y_n\sum_{t=1}^T\alpha_tg_t(x_n)\) 越大越好，那么显然 \(exp(-y_n\sum_{t=1}^T\alpha_tg_t(x_n))\) 越小越好，于是 \(u_n^{(T+1)}\) 也就越小越好。 我们的目标就变成了最小化： \[\sum_{n=1}^Nu_n^{(T+1)}=\frac1N\sum_{n=1}^Nexp(-y_n\sum_{t=1}^T\alpha_tg_t(x_n))\]

因为 \(\sum_{t=1}^T\alpha_tg_t(x_n)\) 是我们的预测项，所以这个最小化其实也是另一种错误函数，而且这个错误函数显然是 0/1 error 的上界，这个错误函数一般叫做 \(\hat{err}_{ADA}\)。 有个优化函数，下面的问题就是如何求出这个优化函数 \(\sum_{n=1}^Nu_n^{(T+1)}\) 的最小值了。 思考梯度下降的过程，我们通过泰勒展开发现梯度的反方向是要求下降的最好方向，当然梯度下降的方向是一个向量。但是我们这里的“梯度”其实是一个函数，函数跟向量其实并没有多大的区别，只是一个下标是连续的一个下标是离散的（因为数学不好，只能这么理解了）。 接下来对要最小化的式子进行推导： \[\frac1N\sum_{n=1}^Nexp(-y_n(\sum_{t=1}^T\alpha_tg_t(x_n)+\eta h(x_n)))=\sum_{n=1}^Nu_n^Texp(-y_n\eta h(x_n))\]

对这个式子进行最简单的一阶泰勒展开可以得到：\[\sum_{n=1}^Nu_n^Texp(-y_n\eta h(x_n))=\sum_{n=1}^Nu_n^t(1-y_n\eta h(x_n))=\sum_{n=1}^Nu_n^t-\eta\sum_{n=1}^Nu_n^ty_nh(x_n)\]

先忽略掉步长 \(\eta\)，我们的目标就变成了找到一个好的 \(h(x_n)\) 来最小化 \(\sum_{n=1}^Nu_n^{(t)}(-y_nh(x_n))\)。 对于二分类问题，\(-y_nh(x_n)\) 的值要么是 \(-1\) 要么是 \(1\)。当 \(y_n = h(x_n)\) 时，\(\sum_{n=1}^Nu_n^{(t)}(-y_nh(x_n)) = -\sum_{n=1}^Nu_n^{(t)}\)，当 \(y_n \neq h(x_n)\) 时，\(\sum_{n=1}^Nu_n^{(t)}(-y_nh(x_n)) = \sum_{n=1}^Nu_n^{(t)}\)。将这个结果稍微平移并且统一一下，可以发现一件神奇的事情：\(\sum_{n=1}^Nu_n^{(t)}(-y_nh(x_n)) = -\sum_{n=1}^Nu_n^{(t)}+2E_{in}^{u_n^{(t)}}\cdot N\)。 太有趣了。让原来的 \(\sum_{n=1}^Nu_n^{(t)}(-y_nh(x_n))\) 竟然最优的 \(h(x_n)\) 就是让 \(E_{in}^{u_n^{(t)}}\) 最小的 \(h(x_n)\)，也就是我们的 AdaBoost 过程中求出的 \(g_t\)！ 在之前梯度下降的时候，我们选择的是自己随便设置一个步长，但是在 AdaBoost 里面，因为我们要组合各个方法以达到最好的效果，所以这个步长其实就是最后预测式中的 \(\alpha_t\)。这个步长也就是在最佳方向上的最大步进长度，先把要求最佳步长的表达式写下来： \[\check{E}_{ADA}=\sum_{n=1}^Nu_n^{(t)}exp(-y_n\eta g_t(x_n))\]

有两种情况需要我们考虑，分别是预测正确：\(u_n^{(t)}exp(-\eta)\)，和预测错误：\(u_n^{(t)}exp(+\eta)\)。 之前我们将错误率以符号 \(\epsilon_t\) 来表示，经过简单推导统一，可以得到： \[\check{E}_{ADA}=(\sum_{n=1}^Nu_n^{(t)})\cdot ((1-\epsilon_t)exp(-\eta)+\epsilon_t\ exp(+\eta))\]

求导，\(\frac{\partial \check{E}_{ADA}}{\partial \eta}=0\) 得到： \[\eta_t=ln\sqrt{\frac{1-\epsilon_t}{\epsilon_t}}=\alpha_t\]

这就是 \(\alpha_t = ln\sqrt{\frac{1-\epsilon_t}{\epsilon_t}}\) 的原因啦！

从 AdaBoost 到 Gradient Boosting

总结一下之前 AdaBoost 的求解过程，其实就是去优化以下式子： \[min_{\eta}min_h\frac1N\sum_{n=1}^Nexp(-y_n(\sum_{t=1}^T\alpha_tg_t(x_n)+\eta h(x_n)))\]

之前说了，这个 \(exp\) 函数其实只是错误函数的一种形式，我们也可以换成其他类型的 error 函数，比如这样： \[min_{\eta}min_h\frac1N\sum_{n=1}^Nerr(\sum_{t=1}^T\alpha_tg_t(x_n)+\eta h(x_n), y_n)\]

这个公式就是一种通用的 Gradient Boosting 啦！ 接下来，我们就使用普通的 regression 错误（\(err(s,y)=(s-y)^2\)）来看看 regression 情况下的 Gradient Boosting 是怎么回事吧~ 我们将 \(\sum_{t=1}^T\alpha_tg_t(x_n)\) 看做 \(s_n\)，那么原式通过泰勒展开之后就等于： \[min_h\frac1N\sum_{n=1}^Nerr(s_n,y_n)+\frac1N\sum_{n=1}^N\eta h(x_n)\frac{\partial err(s,y_n)}{\partial s}\]

其中的一阶导数\(\frac{\partial err(s,y_n)}{\partial s}=2(s_n-y_n)\)。 去除一堆常数项和常数因子，其实我们只需要最小化\(h(x_n)\cdot 2(s_n-y_n)\)就好了。所以只要令\(h(x_n)\)是梯度\(2(s_n-y_n)\)的反方向就好了，但是这个反方向究竟要取多大呢？回想一下我们之前的梯度下降，其实梯度只代表一个方向，多大并没有什么关系。为了防止这个梯度取到无穷大，我们需要对梯度的大小进行一下限制。参考之前的正则化思路，我们也可以通过加上一个惩罚项\(h^2(x_n)\)来得到新的优化式子，经过添加常数进行整理，可以得到我们最后关心的优化式子： \[min\sum_{n=1}^N((h(x_n)-(y_n-s_n))^2)\]

也就是说，我们利用我们的基础 regression 方法使得 \(h(x_n)\) 更加接近 \(y_n-s_n\) 就可以了。简单的来说就是对所有 \(N\) 个点 \((x_n, y_n-s_n)\) 做 regression，得到的回归方程就是我们要求的 \(g_t(x_n)\) 啦！ 其中一个很重要的概念就是 \(y_n-s_n\)，很多博客会把这个东西叫做残差。也就是这些残差来决定 \(g_t\)。 现在需要求出步长 \(\eta\)。这个步骤非常简单，把我们之前求出来的 \(g_t\) 代回到原来的优化式子中们可以得到： \[min_{\eta}\frac1N\sum_{n=1}^N(s_n+\eta g_t(x_n)-y_n)^2 = \frac1N\sum_{n=1}^N((y_n-s_n)-\eta g_t(x_n))^2\]

可以发现，这里又是对残差进行拟合。不过这个拟合只有一个变量，非常简单，只需要简单求个导数就可以得到我们需要的 \(\eta\) 啦！ 这个 Gradient Boosting 最出名的利用方法就是我们标题中提到的大名鼎鼎的 Gradient Boosted Decision Tree(GBDT) 啦！不过我们整个推导过程中好像并没有用过决策树啊？这个决策树要在哪里使用呢？ 很简单，就是我们通过决策树来做每一步的 regression 就好啦！有一个细节是，因为我们在求第一棵决策树的时候并没有残差这个东西，所以直接对各个 \((x_n, y_n)\) 做拟合就好了，从第二棵决策树开始对残差做拟合。

从线性分割说起

在《机器学习基石》课程中讲了一个基于迭代的简单线性分类算法 PLA，但是对一个二分类的数据集，合法的分类线普遍是无数条。对于这无数条线我们应该选择哪条线作为我们最终分类的结果才比较好呢？

从上图来看，显然最右边这一列是比较合理的分割方法。也就说，离分类线的最近的点要尽可能的远，这样对各种噪音误差的兼容性是最好的。 用数学的定义来说就是： \[max_{w}min_{n=1...N}distance(x_n, w)\]

对于每个点来说都必须存在\(y_nw^Tx_n>0\)（如果一定要每个点都没有分割错误的话）。 在计算距离的时候，bias 显然是不应该参与进来的，所以需要把 bias 从矩阵中拆出来，变成\(h(x)=sign(w^Tx+b)\)的形式，距离就从\(distance(x,w)\)变成了\(distance(x,b,w)\)。 下面要计算点\(x\)到超平面\(w^Tx+b\)的距离，这个就是一个简单的投影，得到 \[distance(x,b,w)=\frac{|w^Tx+b|}{||w||}\]

因为上面有对于每个点来说都必须存在\(y_n(w^Tx_n+b)>0\)的条件，所以分子里面这个麻烦的绝对值式子可以直接用\(y_n(w^Tx_n+b)\)来代替（反正\(y_n\)要么是\(1\)要么是\(-1\)，不会对结果有任何影响），所以得到以下式子： \[distance(x,b,w)=\frac{y_n(w^Tx_n+b)}{||w||}\]

又因为\(w^Tx_n+b\)这个东西是可以加常数放缩的，也就是说\(w^Tx_n+b\)跟\(3w^Tx_n+3b\)所代表的平面是完全一致的，所以我们完全可以通过放缩使得最小的平面求出来的值等于\(1\)，这样的好处是，最小的 distance 一定是 \(\frac{1}{||w||}\)。这样做我们要求的数学式子就变为： \[max_{w}\frac{1}{||w||}min_{n=1...N}y_n(w^Tx_n+b)=1\]

但是接下来有个奇怪的问题，如果我们限制的条件是所有的\(y_n(w^Tx_n+b)\ge 1\)，那一定会有一个\(w\)使得\(y_n(w^Tx_n+b)=1\)吗？ 这个证明其实很简单，如果最优的\(w\)使得\(y_n(w^Tx_n+b)=1.126\)，那么我们只要取\((b/1.126, w/1.126)\)这样一组解，就会比之前的\(w\)更优了。 现在优化目标已经很明显了，为了之后陈述方便，我们将最大化\(\frac{1}{||w||}\)变成最小化\(w^Tw\)。为了后续的推导方便，加了一个\(\frac{1}{2}\)的放缩。于是我们的优化函数就变成了下面这样： \[min_{w}\frac{1}{2}w^Tw\]\[min_{n=1...N}y_n(w^Tx_n+b)\ge 1\]

现在有了优化函数，如何求解呢？可以很简单的发现，这是一个非常经典的二次规划问题！给出一堆\(w\)的限制，求解一个\(w\)二次项的最优解！ 对于非线性的情况，我们只要把线性的映射到非线性情况就行了，非常的 easy，真是太爽了！

为什么我们需要对偶问题

不是都爽了吗？还要搞啥呢？ 真的爽吗？我们想一下，线性的情况确实蛮爽的，但是非线性的情况，当我们要将低维的特征映射的高维的时候，将\(x_n\)映射到\(z_n\)，这个代价是非常巨大的。比如一个\(x_n=(x1, x2)\)特征，映射到二维就需要\(z_n=(1, x1, x2, x1^2, x2^2, x1x2)\)这么多东西，更高的维度需要的代价会更大。 为了解决这个问题，我们首先需要了解一个叫做 Lagrange Mulitipliers 的东西。这个东西在正则化的时候，我们其实已经了解过了，大致是这个形式： \[min_wE_{in}(w), w^Tw\le C \cong min_w(E_{aug}(w)=E_{in}(w)+\frac{\lambda}{N}w^Tw)\]

既然\(w^Tw\le C\)我们可以通过在后面加一个\(\frac{\lambda}{N}w^Tw\)来获得等价问题，那么\(y_n(w^Tz_n+b)\ge 1\)这个条件我们显然也可以如法炮制，大致是这个形式： \[L(b,w,a)=\frac{1}{2}w^Tw+\sum_{n=1}^N\alpha_n(1-y_n(w^Tz_n+b))\]\[\min_{b,w}(max_{\alpha_n\ge 0}L(b,w,\alpha))\]我们保证\(\alpha_n\ge 0\)这样的条件，这样就可以使得所有\(1-y_n(w^Tz_n+b)\)都符合不超过\(0\)的要求。因为如果有一个\(1-y_n(w^Tz_n+b)ge 0\)，那就可以让对应的\(\alpha_n\)为无穷，优化的 max 就是无穷大了。 但是这个东西我们还是不会优化，这时候就需要引入一个叫做拉格朗日对偶问题的东西，这个东西通过一系列的证明，表示在我们这个优化形式下，这两个问题是完全等价的： \[min_{b,w}(max_{a_n\ge 0}L(b,w,\alpha))\cong max_{a_n\ge0}(min_{b,w}L(b,w,\alpha))\]

展开来写的话就是： \[max_{a_n\ge0}(min_{b,w}\frac{1}{2}w^Tw+\sum_{n=1}^N\alpha_n(1-y_n(w^Tz_n+b)))\]

下面开始魔法时刻~

如果里面的那个最小值优化是一个最值的话，那么对于每一个参数的偏导都应该是\(0\)。基于这一点，我们就可以做一些有趣的事情了。 首先对里面的\(L(b,w,\alpha)\)求\(b\)的偏导，可以得到如下式子： \[\frac{\partial L(b,w,\alpha)}{\partial b}=-\sum_{n=1}^N\alpha_ny_n=0\]

这个结论其实就有点神奇了，但是更神奇的地方在于，我们把\(L(b,w,\alpha)\)展开，发现\(b\)的系数恰好就是这个\(-\sum_{n=1}^N\alpha_ny_n\)！也就说\(b\)这一项直接就可以消掉！

继续我们的魔法之旅，下面对\(L(b,w,\alpha)\)求\(w_i\)的偏导： \[\frac{\partial L(b,w,\alpha)}{\partial w_i}=w_i-\sum_{n=1}^N\alpha_ny_nz_{n,i}=0\]

这样就得到了一个有趣的结论，\(w=\sum_{n=1}^N\alpha_ny_nz_n\)。 将这个结论带入回原来的式子，可以得到： \[max(\frac{1}{2}||\sum_{n=1}^N\alpha_ny_nz_n||+\sum_{n=1}^N\alpha_n)\\ a_n\ge0, \sum_{n=1}^N\alpha_ny_n=0, w=\sum_{n=1}^N\alpha_ny_nz_n\]

所谓的 KKT 条件，其实也就是上面式子的几个条件了，还有一个原来定义中的条件\(y_n(w^Tx_n+b)\ge1\)，当然还有一个最有趣的 KKT 条件就是\(\alpha_n(1-y_n(w^Tz_n+b))=0\)，因为在优化的过程中，我们要求最后结果的最大值，而两个非负数相乘最后想要结果最大的话，必须其中一个为\(0\)，那么上面这个条件就必须成立。 通过取负数将优化最大值变成优化最小值，然后展开可以得到： \[min_{\alpha}\frac{1}{2}\sum_{n=1}^N\sum_{m=1}^N\alpha_n\alpha_my_ny_mz_n^Tz_m-\sum_{n=1}^N\alpha_n\\ a_n\ge0, \sum_{n=1}^N\alpha_ny_n=0\]

诶，这个东西的形式是不是有点眼熟？没错，就是二次规划，太爽了，对偶问题我们现在也会求解了！ 求解出\(\alpha\)之后，就可以通过\(w=\sum_{n=1}^N\alpha_ny_nz_n\)求出\(w\)。那我们的 bias 呢？还记得\(\alpha_n(1-y_n(w^Tz_n+b))=0\)这个 KKT 条件吗？在\(\alpha_n>0\)的时候，我们就可以求出对应的 bias 了，而那些\(\alpha_n>0\)所对应的\(n\)，其实就是所谓的支持向量！ 当然了，这个时候聪明的读者就会发现，你这个不还是有一个\(z_n^Tz_m\)吗？复杂度并没有降低啊？

久等了，核方法！

核方法其实跟 SVM 的推导并没有什么直接关系，但是在 SVM 的使用中却是大放异彩的。 所谓的核方法，其实就是一些神奇的\(z_n^Tz_m\)求法，这些核方法可以完成很好的空间变换功能，甚至将原来的特征空间变换到无限维，正是核方法的出现，才使得 SVM 在某一个历史时期“一统江湖”的。 比如我们有一个垃圾特征空间变换，将\(x_n=(x_1, x_2, x_3, ..., x_d)\)变换到\(\phi_n=(1, x_1, x_2, ..., x_d, x_1x_2, ..., x_1x_d, x_2x_1, x_2^2, ..., x_2x_d, ..., x_d^2)\)。 现在我们想知道\(\phi_n(x)^T\phi_n(x^*)\)，直接乘起来的话复杂度是\(O(d^2)\)。我们通过观察式子，进行一定程度的优化可以发现\(\phi_n(x)^T\phi_n(x)=1+x^Tx^*+(x^Tx^*)(x^Tx^*)\)。这样复杂度就是\(O(d)\)了，是不是很棒？ 当然了，还有很多例如 RBF 之类的比较复杂的核方法，这里就不加赘述了，在实际应用中通常将\(z_n^Tz_m\)换成\(K(x_n, x_m)\)就代表核方法啦。

虚假的 SVM 和真正的 SVM

其实上面讲的 SVM 跟实际使用的 SVM 并不完全一致，主要问题出现在大前提上，就是\(y_n(w^Tx_n+b)\ge1\)这个定义。这个定义要求我们每个点都不能分割错误，过于严格，因为有一些噪音的结果是不需要考虑的。我们的 SVM 需要容忍一些分割错误。 我们将原来的 SVM 扩展一下，形式如下： \[min_{b,w,\xi}\frac{1}{2}w^Tw+C\sum_{n=1}^N\xi_n\\ y_n(w^Tz_n+b)\ge1-\xi_n, \xi_n\ge0\]

其中参数\(C\)就是用来 trade-off 容错率和分割线的鲁棒性的，参数\(\xi_n\)就是表示这个点到底犯了多少错。 用 Lagrange Mulitipliers 重写这个优化式子，形式是这样： \[L(b,w,\xi,\alpha,\beta)=\frac{1}{2}w^Tw+C\sum_{n=1}^N\xi_n+\sum_{n=1}^N\alpha_n(1-\xi_n-y_n(w^Tz_n+b))+\sum_{n=1}^N\beta_n(-\xi_n)\]

\[max_{\alpha_n\ge0, \beta_n\ge0}(min_{b,w,\xi}L(b,w,\xi,\alpha,\beta))\]

跟原来一样，通过求\(\xi_n\)的偏导可以发现： \[\frac{\partial L(b,w,\xi,\alpha,\beta)}{\partial \xi_n}=C-\alpha_n-\beta_n=0\] 跟之前的 bias 一样，我们将式子展开之后，发现\(\xi_n\)的系数就是上面这个等于\(0\)的式子，所以\(\xi_n\)这一项就没了。但是需要多一个\(0\le\alpha_n\le C\)的条件。很神奇，这一项没了之后，我们的式子又开始变得眼熟起来： \[max_{0\le\alpha_n\le C}(min_{b,w}\frac{1}{2}w^Tw+\sum_{n=1}^N\alpha_n(1-y_n(w^Tz_n+b)))\]

后面的事情就很显而易见了，前面都推导过了，这里也就不加赘述了。

• 2016 浙江大学程序设计竞赛 一等奖
• 2016 浙江省程序设计竞赛 三等奖

2016 rkmxtxwd 热裤暮夏天下无敌

• 2016 ACM/ICPC 大连 银牌  36th place.
• 2016 ACM/ICPC 北京 银牌  29th place.

2017 LeatherClub 广东老乡

• 2017 ACM/ICPC 西安 金牌  17th place.
• 2017 CCPC 杭州 金牌  10th place.
• 2017 ACM/ICPC 南宁 金牌  9th place.
• 2017 ACM/ICPC 上海 ECL-final 铜牌  128th place.

虽然很想继续...但是明年还要找工作（or 保研？？？），还要为了生计奔波，感觉自己除了竞赛什么都不会...其实竞赛也始终没有变成很强的选手...所以只能说再见了吧...

GoodBye ICPC