Personal blog
What I learn and write for a living.
问题描述 CuTe DSL 允许使用 Python 对象保存 kernel 的静态配置，例如 tile shape、pipeline stage 数量、寄存器分配，以及不同 warp role 对应的 device function。 以 FlashAttention 的 warp specialization 为例，一个 CTA 中： producer warps 执行 load()； consumer warps 执行 mma()； 具体角色由运行期的 warpidx 决定； FlashAttention 实例本身则是编译期构造的策略对象。 实际代码可以抽象为： 这里有两种完全不同的值： 1. warpidx、tensor 和 storage 中的地址是运行期值，需要 lower 为 MLIR； 2. fa
Read note突然想起了幼儿园的时候，忘了在哪个教室里面，我坐在一个小板凳上，窗外的阳光非常好看，窗外还有树。这大概是春夏之交，那种阳光带一点绿色，又有微风的感觉让我难忘。我记得在这个教室里拨毛豆，拨出了一只毛毛虫。我记得幼儿园还是小学，也有可能是梦中，
Read note近期遇见了很多人，了解了很多事情，也是时候想想AI时代下，CS学生的出路了。我这几个星期遇到了一群做开源的伙伴，我也开始想在开源社区做一些贡献，虽然我很大程度上是功利的，只是为了把这些写进简历。多的就不说了，我就讲一些结论性的东西吧。 connection是非常重要的，现在AI帮人丰富简历，各种虚的经验，各种包装让面试的人已经无法区分真正有实力的人和纸上谈兵的人了。因此在自身实力硬之外，需要多多找人合作。这有几个主要途径：1）开源社区 2）做research assistant 3）做intern。只有真正做过人家才认识你，现在最厉害的公司最厉害的组很多都是看熟人推荐的，如果没有合作经历要找一个好工作确实越来越难了。 读代码的能力越来越重要。现在大家都不需要写代码了，但是读代码的工作任务越来越大。对于优秀的工程师而言，不仅要读自己AI生成的屎，还要读别人pr交上来的屎，现在的开源社区技术强的读代码专家太少了，但是能产生屎的人太多了。如何识别出好的代码和垃圾代码已经不是看语法的事情了。因为AI写的代码语法都很准确格式都很对，我们需要去真正读一行一行的逻辑。因此开源社区现在基本都是要认识的人帮忙找人merge，自己交上去已经几乎没有人理你了。 我想，后续我的发展可能应该朝着下面几个方向： 1. 每天至少读两个小时代码。 2. 多参加各种技术社群，增加connection的同时了解一些行业内部的新动态。 实验室给了我打下了很好的基础，zhuobin师兄带着我从CUDA一直学到最前沿的LLM框架，在我接触社区前有了一定的积累。当我第一次接触到社区的时候，我的实力已经比一些乌合之众强了。然而我的实操经验是缺失的，必须要静下心来对着一些事情仔细研究才行。
Read note假设hiddenstate为4096维 h(1\4096)变成Q(1\4096)之后会被切成Q(32\128)，然后每个Q后续只需要和自己匹配的KV进行运算，优点是我们能够对Q的每个地方特化expression。这里自己匹配的KV也可以分成很多份。共享KV会有损失。 | 结构 | Attention 表达能力 | 单个token KV Cache | | | | | | MHA | 32 套权重，KV也独立 | 32\128\2 | | GQA | 32 套权重，部分共享KV （例如共享四套KV Cache） | 4\128\2 | | MQA | 32 套权重，完全共享KV | 1128\2 | | MLA | 32 套权重，完全共享KV，且KV可以由同一个L变出来 | 1\128 |
Read noteLLM 推理通常包含两个阶段： Prefill：一次处理大量 prompt token，矩阵规模大，通常偏 computebound。 Decode：每个 request 每轮只产生一个 token，计算规模小，但需要读取模型权重和大量 KV Cache，通常偏 memorybound。 这会造成一个很直接的问题： Prefill 很容易把 GPU 算力吃满，而 decode 即使延迟很重要，却经常无法充分利用 GPU。 Chunked Prefill 的核心思想，就是把一个很长的 prefill 拆成多个小块，然后让这些 prefill chunk 和正在运行的 decode request 一起执行，尽量增加GPU的利用率。 1. Chunked Prefill 要解决什么问题？ 假设来了一个 4096token prompt。 传统做法可能是： 这个大 prefill 会占用 GPU 很长时间。 正在 decode 的 request 必须等待，因此会出现明显的
Read noteCUPTI（CUDA Profiling Tools Interface）是 NVIDIA 提供的底层 profiling 接口。Nsight Systems、Nsight Compute 等工具底层都会使用 CUPTI 获取 CUDA 程序的执行信息。 对于 tracing 来说，最核心的两套机制是： Activity API：异步记录执行过程中发生了什么。 Callback API：在某个 CUDA API 正在执行时同步插入 callback，在某个事件触发前/后进入这个callback function 1. Activity API Activity API 用于收集执行 trace，例如： 它的整体流程只有四步： 1.1 cuptiActivityRegisterCallbacks 首先需要注册两个 buffer callback： 这个函数本身不决定记录什么事件。 它只是告诉 CUPTI： 因此两个 callback 分工非常明确。 bufferRequested CUPTI 需要一块新的空 buffer
Read note0. 先统一概念 投机解码（Speculative Decoding）的共同框架是： 1. 用一个更便宜的过程先提出一段候选 token，记作长度为 K 的 draft block。 2. Target model 对整段候选做一次并行验证。 3. 从左到右接受通过验证的最长前缀；遇到第一个不通过的位置就停止接受，并按相应规则采样修正 token。 下文中： Target：最终负责保证输出正确性的目标大模型。 Drafter：负责廉价提出候选的模块或方法。 AR：autoregressive，自回归；后一个 draft token 依赖前一个已经生成的 draft token。 K：一次尝试生成并验证的候选 token 数。 1. 总览 | 方法 | Draft 信息来源 | K 个候选如何产生 | 是否显式依赖前一个 draft token | 主要计算形态 | | | |
Read note