111qqz

caffe做部署是YYDS! blob layer net 激活函数 卷积 reshape slice loss function reduce eltwise argmax

上一篇从高斯消元推到了低秩分解，最后用 LoRA 举了个例子——\(\Delta W = BA\)。当时想清楚的是数学层面为什么两个小矩阵可以代替一个大矩阵，但 LoRA 本身没有展开。

最近在看 LoRA（Low-Rank Adaptation）的时候，碰到了一个公式： $$ \Delta W = BA $$其中 \(B \in \mathbb{R}^{m \times r}\)，\(A \in \mathbb{R}^{r \times n}\)，中间那个维度 \(r\) 被称为 Rank。 我对 Rank 这个词并不陌生——以前在 ACM-ICPC 里写高斯消元的时候，算自由变量个数就用到了矩阵的秩。但当时的关注点全在怎么求解、怎么判断无解多解、怎么把实际问题转化成线性方程组。至于 Rank 本身代表什么数学结构、跟低秩分解有什么关系，说实话没有认真想过。

PagedAttention 那篇写完之后，我觉得 KV Cache 的内存管理问题算是理清了——分页、按需分配、Block Table 映射，思路很干净。末尾我提到下一步要看 Continuous Batching 和 Chunked Prefill，也就是在多个并发请求之间怎么调度 GPU 的计算资源。

上一篇理清了 Prefill 和 Decode 的因果链之后，我开始翻 Decode 阶段的加速方案。结论已经很清楚了：在单请求、小 Batch 的典型场景下，Decode 阶段是 memory-bound 的——每生成一个 token 就要把整个模型权重从显存搬一遍，计算单元大部分时间在等数据（Batch 较大或模型结构不同时，瓶颈也可能转向 compute-bound，但单次请求的延迟优化场景下 memory-bound 是常态）。

前一篇写完之后，KV Cache 在我脑子里的形象已经变了——它不再是一次 forward 里的临时中间量，而是一个跨多轮存活、随 Decode 持续增长、每个请求各自独立的状态。 但"知道它是有状态的"和"知道怎么管它"是两件事。当我开始想具体的内存管理问题的时候，发现事情比想象的复杂。

最近在从传统模型 Serving 转向 LLM Inference，一个让我停下来想了很久的问题是：为什么 LLM 的推理系统看起来和我之前熟悉的那套完全不一样？ 我之前做推荐模型和 CV 模型的部署，排序模型的 Serving 架构虽然在工程上也有不少复杂性（远程 embedding 读取、稀疏参数缓存等），但核心计算模式不难概括：一个请求进来，跑一次 forward，返回结果。LLM Serving 里冒出来一大堆新概念——推理要分成 Prefill 和 Decode 两个阶段，中间要维护 KV Cache，请求调度要做 Continuous Batching，显存管理要用 PagedAttention——我花了些时间才把它们背后的因果链串起来。

写完 Multi-Head Attention 和 Causal Attention 之后，我一直觉得 Attention 这条线已经差不多了——公式拆过了，routing space 的 factorization 也想明白了，Causal Mask 的因果约束也理清了。 直到最近看 Llama 2 的模型配置，发现一行让我停下来的参数：

最近学习 MIT 6.S191 Lecture 9，陆续把 DDP、ZeRO、FSDP2、Tensor Parallelism、Pipeline Parallelism、Sequence Parallelism、Context Parallelism，以及 Expert Parallelism 过了一遍。

上一篇把单个 MoE Layer 的执行流走了一遍：Router 选 Expert、Token Dispatch 按 Expert 重排、Grouped GEMM 统一调度、Combine 加权合回原始 Token 顺序。整条链路假设所有 Expert 都在同一张 GPU 上。