vllm-GDN-forward简单记录一下vllm对于GDN模型的优化，下边这里是来自Qwen3-Next模型的GDN部分的结构： QKV-Proj和nano-vllm中qkv的行为一直，可以看到图中的hidden_state分别经过了6个linear，这里也采用了一个增加吞吐量的手段，即这几个linear层被合并成了一个，去看模型safetensors文件发现他是这样保存的。 12model.

vllm的kv_cache_manager allocate_slots()在先前的schedule()中执行请求的踢出/加入前，kv_cache_manager首先根据request的new_tokens信息尝试分配新的显存block，本节主要看一下这个kv_cache_manager都做了什么事情。 12345new_blocks = self.kv_cache_manager.al

vllm的scheduler经过前面LLM启动流程源码阅读，知道了实际的token处理是在EngineCore的scheduler中被一个个调度的，今天来看一下Scheduler.schedule方法的具体逻辑。 Scheduler在process_engine_step()中，内部调用了scheduler的schedule()方法，schedule()中处理了一个个实际的request，在sch

FA2与Flash Decoding在学习LLM Infer的时候，总是会提到FLash_Decoding这个概念，这里对比一下FA2和Flash_Decoding(FD)的一点区别。 FlashAttention2在学习了Flash Attention V1的过程中，FA的矩阵遍历顺序是外层遍历KV， 内部依次遍历Q tile，那么这样会带来一个问题，在计算Attention的时候，最后其实是要

vllm的启动流程记录一下阅读源码时发现的问题 GPUModelRunner.py“FIXME(woosuk): Fix warmup for LoRA.”现在似乎这个model runner还没有对LoRA Adapter做Graph Capture 1. LLMEngine的初始化从一个/root/autodl-tmp/vllm/examples/basic/offline_inferen

vllm的model_executor经过前面scheduler一部分代码的解读，了解到scheduler会对当前的batch_requests打包成一整个SchedulerOutput传递给Engine中的ModelExecutor，本节我们继续沿着EngineCore中的step()方法进入模型推理阶段。 1future = self.model_executor.execute_model(

store-node阅读笔记在看store-node的源码之前，首先需要知道这个包是做什么的： 这个包主要启动了Raft的节点服务，负责节点生命周期的管理、分区/Raft任务的提交(主要)、扫描/聚合查询流水线、TTL 清理任务、以及 RocksDB/JRaft/系统层指标采集等能力。 向外提供了grpc(供内部组件使用)和一些Rest API(用户来管理

hg-store-core 重构代码阅读这个模块主要是增删改查一些功能的实现方法，属于在RocksDB的上层封装。 graph LR B[hg-store-rocksdb] -->|封装| A[RocksDB] C[hg-store-core] -->|封装| B /bussiness 增删改查的主要实现新增了很多iterator定义，都实现了ScanIte

CompletableFuture 学习笔记文章链接：https://tech.meituan.com/2022/05/12/principles-and-practices-of-completablefuture.html 利用java8的CompletableFuture 12345678910111213141516171819202122import java.util.concurre

GPT2/Qwen2 模型架构Transformer在介绍GPT2与Qwen2的模型架构前，首先需要简单的回顾一下Transformer架构，这里就默认读者已经基本了解Transformer了，贴出一个图。 左侧是Encoder部分而右侧是Decoder部分。至于为什么需要将Encoder的输出输入到Decoder当中，以一个机器翻译任务举例。我爱你 -> I love you 首