【nano-vllm 学习】05 - 自顶向下的模型执行源码学习
2026-03-21 3.6k 字 16 分钟

【nano-vllm 学习】05 - 自顶向下的模型执行源码学习

立志写出让纯夏都能看懂的教程讲解 终于来到了 model runner 的学习，在学习了 PageAttention 的基础管理和调度逻辑后，我们终于准备窥见模型推理计算的“真面目”了，ModelRunner 层负责了模型的加载、推理执行和多 GPU 调度，是连接 Scheduler 和底层 CUDA 算子的中间层。 简单来说， 1234Scheduler → ModelRunner.run(seqs, is_prefill) → Model → Sampler → token_ids ├── prepare_prefill / prepare_d
【nano-vllm 学习】04 - 自顶向下的引擎调度层源码学习2
2026-03-14 5.4k 字 22 分钟

【nano-vllm 学习】04 - 自顶向下的引擎调度层源码学习2

立志写出让纯夏都能看懂的教程讲解 Scheduler 我们继续来解析“引擎调度层”的另一个重要角色：调度器 scheduler (废话，调度器能不重要)。 简单来说，scheduler 的功能是：在每一次 step() 推理时，决定让哪些 sequence 进入 GPU 执行计算，并且在显存不足时执行抢占功能。 从代码实现来看，scheduler 的思路很简单直接： 维护两个队列： waiting 队列：存储等待被执行 prefill 的 Sequence； running 队列：存储已经拿到 Block Cache 后续需要 decode 的 Sequence。 123456
【nano-vllm 学习】番外 - KV Cache 大学习
2026-03-14 864 字 4 分钟

【nano-vllm 学习】番外 - KV Cache 大学习

立志写出让呆呆兽都能看懂的教程讲解 KV-Cache … 是什么？ 在回答这个问题之前，让我们先简单回顾下 transformer 的 decoder 中 attention 的计算 $$Attention(Q,K,V)=softmax(\frac{QK^T}{\sqrt{d_k}})V $$其中， $Q=XW_Q,\quad K=XW_K,\quad V+XW_V$，分别是输入序列对权重矩阵的线性投影。 如果各位还记得，在 decoder 架构中，我们引入了 causal mask 因果掩码 来 “隔断” 未来信息对过去信息的影响。 换句话说，模型在 t
【nano-vllm 学习】03 - 自顶向下的引擎调度层源码学习1
2026-03-09 2.1k 字 9 分钟

【nano-vllm 学习】03 - 自顶向下的引擎调度层源码学习1

立志写出让纯夏都能看懂的教程讲解 我们依然将按照“自顶向下”的顺序逐层解析 nano-vllm 的实现细节。进入到引擎调度层后，代码开始稍微有些复杂了，因此这一层我打算做多篇来写，也方便各位阅读理解。在本节，我们将重点解析 llm_engine.py 以及 sequence.py 的主要思路，并辅助以部分调度器 scheduler.py 的代码。 我们在本节的目标很简单：从整体上了解引擎调度和执行工作的设计思路，对于细节的实现暂且放在下回分解。 在上篇文章中，我们抽象出了用户接口层应当实现的 4 个步骤，并具体解析了其中的第 1 和 4 点，我们将在这篇文章对其中的2、3点解析补完。具体
【nano-vllm 学习】02 - 自顶向下的用户接口层源码学习
2026-03-06 2.6k 字 11 分钟

【nano-vllm 学习】02 - 自顶向下的用户接口层源码学习

我们以“自顶向下”的顺序，逐层解析 nano-vllm 的实现细节，这一节将详细解析 用户接口层 的实现细节。 example.py 我们从使用体验出发，先主动思考下，如果是你来做一个推理引擎，当输入 prompts 后，应当发生些什么： prompts 转为可用的 tokens：首先当然是把 List[String] 结构化并分词后，转化为 token 对应的 List[Ids]； tokens 加入引擎调度器的任务队列：既然有了 tokens ，自然是准备开始推理了，做一个任务队列接受所有需要完成的任务是基础的设计思路； 引擎逐步驱动执行推理：只要任务队列还有任务，那引擎就应该在 wh
【nano-vllm 学习】01 - 框架整体概览
2026-03-05 689 字 3 分钟

【nano-vllm 学习】01 - 框架整体概览

立志写出纯夏都能看懂的 nano-vllm 学习。 在这一章，我们将简单归纳 nano-vllm 的架构，给出一个整体的框架图，使得各位有个基础的概念，后续再逐层输入学习解析。 分层概览 我们将整个 nano-vllm 大致分为下面五层： 用户接口层：这一层用户可以使用 LLM 提供的接口，设置并传入 prompts 和采样参数，获得相应的生成的结果； example.py ：接口使用的示例； llm.py ：对引擎调度器的简单封装； sampling_params.py ：控制采样行为（temperature、max_tokens）； config.py ：管理全局配置（bl
【nano-vllm 学习】00 - 基础环境配置
2026-03-04 772 字 4 分钟

【nano-vllm 学习】00 - 基础环境配置

立志写出纯夏都能看懂的 nano-vllm 学习。 0. 环境配置 本篇作为 nano-vllm 学习讲解第 0 节，首先当然得把代码跑起来，不然纯粹白忙活。 我们选择使用 uv 作为环境搭建，uv 的安装就不多费口舌了，跟随官网文档很快搞定。 uv 配置搭建环境 1git clone git@github.com:GeeeekExplorer/nano-vllm.git 先把代码 git clone 下来，uv 创建虚拟环境 1uv venv --python 3.10 然后先不要着急 uv sync ，注意下 pyproject.toml 文件，里面依赖了 flash-attn
【CUDA学习】09-GPU 流异步并行
2026-03-03 6 字 1 分钟

【CUDA学习】09-GPU 流异步并行

9. 流异步并行
【CUDA学习】08-GPU 共享内存
2026-03-03 974 字 4 分钟

【CUDA学习】08-GPU 共享内存

8. 共享内存 基础概念 Bank conflict —— 以矩阵转置为例 其实之所以会有所谓的冲突与解决方法，和 硬件实现 是息息相关的。 硬件层面的 Bank Conflict 是如何发生的？ 硬件上，这一大块共享内存，被切分成了 32 个独立的小 SRAM 模块，这就是 Bank。 独立工作： 这 32 个 Bank 拥有各自独立的地址解码器和数据总线。它们可以同时响应各自的读取/写入请求。 交叉编址： 内存地址被像发扑克牌一样，轮流分配给这 32 个 Bank（即地址 0 在 Bank 0，地址 1 在 Bank 1… 循环往复）。 在线程和这 32 个 Bank 之间
【CUDA学习】07-GPU 内存访问 —— 矩阵转置思考
2026-03-03 971 字 5 分钟

【CUDA学习】07-GPU 内存访问 —— 矩阵转置思考

7. 内存访问 —— 矩阵转置思考 矩阵转置，究竟是 “行优先存储” 快，还是 “列优先存储” 快，取决于矩阵大小 💡 如果输入矩阵很大： 硬件内存控制器按 32 字节或 128 字节的缓存行（Cache Line）从全局内存抓取数据。由于是跨步读取，每个缓存行中只有 1 个有效浮点数被物理线程消耗，其余数十个字节的数据被强制载入 L1/L2 缓存后即刻失效。那么自然是 行优先 快。 如果输入矩阵很小： 自然是 列优先快，因为缓存读到的缓存行足以覆盖整个矩阵，而不用浪费带宽在跨步的写上。 1234567891011121314151617181920212223242526272829