JeremyGuo

vLLM 的 KV cache 管理有两个核心映射层：BlockTable 解决 request 到 KV block id 的映射，slot_mapping 解决本次 forward 中每个 token 到物理 KV slot 的映射。前者是请求级、长期维护的数据结构；后者是 step 级、临时生成的 GPU 工作区。 1. KV cache group 的含义KV cache group 表

GPUWorker.execute_model() 是 EngineCore 广播 execute_model RPC 之后，单个 worker rank 上进入 GPU 执行链路的顶层入口。它承接上一节的 EngineCore -> Worker 控制面，把一次 SchedulerOutput 转交给 GPUModelRunner，同时处理 pipeline parallelism 的边界

EngineCore 到 Worker 是 vLLM 推理控制面的核心路径。请求进入 EngineCore 以后，会先经过 scheduler 和 KV cache manager 做调度与逻辑 block 分配，再由 executor 把本轮 SchedulerOutput 广播给 worker，最终触发 GPU 上的模型执行。 这条链路的关键结论是：EngineCore 是调度和控制中心，Wo

Ray 在 vLLM 里的定位更接近分布式控制面，而不是推理数据面。它负责把一组长期运行的 Python actor 放到合适的节点和 GPU 上，并管理这些 actor 的生命周期。 在 vLLM 的服务链路里，Ray 的边界可以先概括成： 1234567Ray in vLLM: 负责启动 actor、放置 GPU rank、管理跨节点资源和生命周期not Ray in vLLM: 不负责每

引子vLLM API Server 和 EngineCore 的跨进程通信里，一个非常值得停下来看的点是这段代码： 123456789msg = (self.core_engine, request_type.value, *self.encoder.encode(request))if len(msg) <= 3: # No auxiliary buffers => no te

引子理解 vLLM 的在线服务，需要先把注意力从模型本身移到服务进程的组织方式上。 如果只从 /v1/chat/completions 或 /v1/responses 看，很容易觉得 vLLM 就是一个 FastAPI server 加一层模型调用。但真正读进去以后会发现，vLLM 把 HTTP 协议适配、请求状态管理、核心调度、GPU 执行拆成了多个层级。API Server 进程不直接跑 sc

123$ ethtool -S veth2_3 | grep xdp_tx$ ip netns exec ns3 ip link set dev veth3_2 xdp obj xdp_pass.o sec xdp$ ping 10.0.0.3 这篇文章整理一个很容易误判的 veth + XDP 现象：XDP 程序确实收到了包，也确实执行到了 return XDP_TX;，但包没有被发回去，et

这篇文章记录本博客的写作约定：如何写可维护的技术笔记，以及如何在 Hexo 文章中使用 Mermaid、Plotly、数学公式和本地发布流程。

EasyLocalDav 是一个 macOS 菜单栏工具，用 rclone serve webdav 把本地文件夹包装成 Zotero 可用的 WebDAV 服务，并把同步交给本机云盘客户端。

这篇文章说明博客的写作、生成和部署链路：本地 Hexo 生成静态页面，OneDrive 同步到云端，服务器定时拉取 public 目录并由 Nginx 直接服务。