111qqz

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

最近在从传统模型 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 上。

上一篇 MoE 笔记把架构家族理了一遍——稀疏、稠密、Soft MoE，gate 在前还是在后，决定了算力形态和适用场景。 但那篇有一段伪代码一直让我不太舒服： 1for prob, idx in zip(topk_probs.unbind(1), topk_idx.unbind(1)): 2 out += prob.unsqueeze(1) * self.experts[idx](x) 逻辑上没问题。但想象一下真实场景：一个 batch 有几千个 token，每个 token 选 2 个 expert，就是上万个 token-expert 计算任务。用 Python for loop 逐个调 expert 的 forward，GPU 利用率会低得离谱。

前两篇写 Bid-Ask Spread 和 Adverse Selection 以及执行感知回测的时候，讨论的核心问题是"预测对了方向，为什么交易还可能亏钱"。结论是执行成本、成交概率和 Adverse Selection 都会侵蚀预测收益。

上一篇 TP 写完之后，我对 Megatron 的 Column Parallel + Row Parallel 已经比较清楚了：前一层按输出特征切分，后一层按输入特征切分，两层之间不需要 AllGather，只在最后做一次 AllReduce 把部分和加起来。

最近在看 MIT 6.S191 Lecture 9 讲 Context Parallelism 的时候，碰到了一个词：Causal Attention。 我对 Self-Attention 的公式并不陌生——之前那篇已经把 QKV 和 routing score table 拆得比较清楚了。但 Causal Attention 这个概念我一直没有认真想过。回头看，我写 Attention 公式、写 Multi-Head、写 FlashAttention 的时候，脑子里跑的都是"所有 token 都能看到所有 token"的 Full Self-Attention。

起因 # 最近在过 MIT 6.S191 和分布式训练相关的材料，各种 Norm 反复出现。LayerNorm 在写 Transformer Block 那篇时已经接触过，BatchNorm 在做 CV 的那几年天天调，RMSNorm 在看 LLM 代码时到处都是。单独看每个都不算陌生。