最近文章

gemm和alltoall通算融合

1. 总体思想这次做的是单机八卡 H200、NVLink、Ulysses CP 下的 GEMM 和 AllToAll 融合。先把 forward 写清楚： A2A → QKV projection → QK → PV → A2A 需要接起来的主边界有两个。输入侧是 A2A→QKV projection，通信先把各个 peer 的输入 tile 搬到本地最终 …

LLM System: SGLang 01 - 共享专家融合

这篇笔记把 SGLang 共享专家融合的计算语义、权重布局和执行路径压缩成六张结构图。图中的实现判断以 2026-07-29 的 SGLang main 分支为准；正文只补充图中容易误读的部分。从双路径到一次 MoE GEMM 融合不是让 Router 在 Shared Expert 与 Routed Expert 之间做选择。Shared Expert …

LLM System: DeepEP v2 弹性通信架构图解

这篇笔记把 DeepEP v2 的对象、内存、同步和数据路径压缩成五张结构图。正文只补充图中不适合展开的语义边界。架构总览 ElasticBuffer 管理 Dispatch / Combine 所需的通信与 Buffer 资源；EPHandle 保存一次 EP 数据传输的元数据，包括确定性模式、Dispatch 缓存和 GroupGEMM 的 …

LLM Theory: MuP 03 - 为什么MoE模型训练起来有难度？MuP视角

众所周知MoE有一个Router，也就是门控单元，基于topk选择路由到的专家。训练稳定的基本思想是希望随着宽度d增大，模型的activation、grad、delta loss、delta weight变化都比较小。 \[ \operatorname{RMS}(h_l)=\Theta(1),\quad \operatorname{RMS}(\Delta …

为什么 vLLM 和 SGLang 在生成式搜推场景如此废柴？

workload的区别推理的类型是非常多的，RL rollout，在线服务，推荐……这些workload都不一样，虽然说推理框架这一层原则上是一个runtime的workload调度层，但是随着不断的发展，每个推理框架也并不能做到对任意的workload都有一套好的runtime策略，最终这几个框架的优化还是固化到了某几个场景，比如高贵的RL后训练，比如最 …

LLM System: 通信计算融合算子实现 01 - sm80GEMM + ReduceScatter

flux实现：sm80 gemm+rs 看flux的论文来说，原理并不难，修改的是ffn的第二个gemm的epi阶段，让epi阶段的写回操作变成写入reducescatter的通信buffer，相当于做了一次零拷贝。几个关键的点：1. 如何用cutlass自定义epi阶段。2. 用了什么ptx。3. 清零？ cutlass自定义epilogue–sm80 …

工程踩坑：torch.empty 和 torch.zeros 的性能区别

torch.empty() torch.zeros()语义区别区别很简单，是否初始化。性能上，empty后的tensor分页操作是lazy的，lazy模式不总是好的。 lazy（empty）严重劣化的case–RDMA（或其他需要pinned mem场景）如果是empty，内核给torch操作所在进程分配page是lazy的。如果没有真的分配地址，相当 …

工程踩坑：用 Ray 分布式启动 NCCL 的巨额冷启动开销问题

单机八卡，Ray启动训练任务发现启动很慢，具体慢在torchdist的barrier()，然后做了几组对比实验。分别是经典torch.run，torch.run(virtual_visible)，Ray。发现torchrun是正常速度，但是后两者firstbarrier有几秒的时间。 Ray为了资源隔离，设计的进程模型是只能看到一张卡的形态。认为是这个设定 …