Arganzheng's Blog

stay hungry, stay foolish

大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术（总纲）

内容简介 《大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术》以 vLLM v0.27.1 为主要分析对象，从 LLM Serving 的问题本质出发，系统讲解请求生命周期、性能指标、调度、KV Cache、GPU 执行、多卡并行、模型适配、硬件抽象、Prefill/Decode 分离与集群化部署。 本书不局限于算子优化，也不止于源码解读，而是试图回答一个更完整的问题： 一个文本生成请求，为什么会逐渐演化成一个涉及计算、显存、调度、通信与状态管理的复杂系统？ 在这个视角下，LLM Serving 不再只是“把模型跑起来”，而是一个持续协调请求、Token、计算资源、中间状态和网络通信的动态系统。 文章将按照以下主线...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（12）：回到源码：一次请求在 vLLM 内部的真实旅程

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 前九章回答了「是什么」和「为什么」，这一章回答「怎么实现」。 现在你已经知道 Scheduler 为什么要按 token 预算调度、KV Cache 为什么要分块、Attention Backend 为什么要按 batch 形态分派。带着这些「为什么」回头看数据结构，它们就不再是需要背的字段列表，而是每一个都能对应到一个设计约束。 这一章刻意放在最后：如果它出现在第二章，你只会看到一堆 class；出现在这里，你会看到设计决策留下的痕迹。 1....

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（11）：Serving Infra 的下一站：从模型执行器到分布式智能操作系统

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 在前面的章节中，我们围绕 vLLM 的核心机制展开了讨论：模型如何加载，算子如何执行，请求如何调度，以及 KV Cache 如何管理。 这些机制解决的是一个核心问题： 如何让一次模型推理更高效？ 但在真实生产环境中，请求正在变得越来越复杂。一个请求可能包含超长上下文、多轮对话、工具调用、Session 状态，以及图像、音频或视频输入。它不再是一次短暂的函数调用，而可能是一个持续数分钟甚至数小时的分布式任务。 因此，Serving 系统需要管理...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（10）：PD 分离：从单机 Serving 走向集群 Serving

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 本章把前面讨论的四个问题从单机推向集群：当 Prefill 和 Decode 不再共享同一批 GPU，调度、KV Cache、路由和故障恢复都需要重新设计。 前九章主要讨论的是： 如何在一台机器或一组共享设备上，把请求高效地运行起来？ 这一章进一步追问： 如果 Prefill 和 Decode 不再共享同一批 GPU， 它们如何协作完成同一个请求？ 这就是 PD 分离，也就是 Prefill/Decode Disaggregation。...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（09）：硬件解耦：如何不让芯片差异污染 Serving 核心？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 上一章讨论了模型适配：面对不断变化的模型结构，Serving 框架如何通过统一接口、模型注册和模块化执行路径，降低新模型接入成本。 但模型只是变化来源之一。 在真实部署环境中，硬件同样在快速变化。GPU 不再是唯一选择，AMD ROCm、华为昇腾 Ascend、Intel XPU、Google TPU 以及各种专用加速器，都在参与大模型推理基础设施的竞争。 这就带来一个更棘手的问题： 如何让同一套 Serving 逻辑运行在不同芯片上，同时避免...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（08）：模型适配：如何跟上变化极快的模型世界？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 1. 痛点：为什么推理引擎必须持续适配新模型？ 1.1 模型算法同质化与工程实现异构化 LLM 模型在算法上高度同质，都是基于 Transformer模型，围绕以下组件构建： Embedding； Transformer Block； Attention； Feed-Forward Network； Normalization； LM Head。 但模型的工程实现上却是高度异构化： 维度 ...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（07）：Multi-GPU：一张卡不够时如何扩展？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 1. 分布式推理的混合并行策略 分布式推理的混合并行策略： 遇到的问题 该用的策略 切的是什么 单张卡放不下一个 Linear 层 TP 层内的矩阵，按行/列切 单层放得下，但整个模型太大 PP 按层切，分段流水 MoE 的 Expert 太多 ...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（06）：GPU 执行：如何让每个 Token 算得更快？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 这一章的问题是：这些已经确定要算的 token，怎么算得更快。 Decode 偏 memory-bound、Prefill 偏 compute-bound，但落到 GPU 上，浪费其实只有四种形态： 浪费形态 症状 对策 GPU 在等 CPU 发指令 kernel 之间有气泡 CUDA Graph GP...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（05）：KV Cache：LLM Serving 的第一号内存问题

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 设想一个场景： 你有一张 80 GB 的卡，同时来了 100 个请求。第一个请求最后只生成了 300 个 token，第二个生成了 3000 个，第三个一路写到 20K。问题在于：这三个数字，你在请求到达的那一刻一个都不知道。 如果按传统做法，给每个请求划一块连续显存来放它的 KV Cache，那你只能按”最坏情况”预留——按模型支持的最大长度划。于是那个只生成 300 token 的请求，占着一块够装 32K token 的地。100 个请求这么一摊，...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（04）：Scheduler：GPU 这一轮到底给谁用？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码深度剖析。文中所有文件路径、类名和行号均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。 前面我们已经解决了一个重要问题： KV Cache 如何管理？ PagedAttention 将 KV Cache 从连续的大块显存变成可以按 Block 动态分配和回收的资源，使得不同请求可以灵活共享 GPU 显存。 但有了 KV Cache 之后，还有一个更直接的问题： GPU 这一轮到底给谁用？每个请求这一轮应该推进多少？ 这正是 Scheduler 要解决的问题。 传统深度学习推理通常以固定 Batch 为基本调度单位： ...

Posted by arganzheng | August 15, 2026

ABOUT ME

天造之才，皆有其用。
振翅高飞，无须在梦中。

HOT TAGS
RECOMMEND
×