阿甘的博客 | Arganzheng's Blog

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

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。版本提示 @2026-11-12：v0.29.0（2026-09-09）起，Model Runner V2（vllm/v1/worker/gpu/）成为所有模型的默认实现，V1 的 GPUModelRunner（vllm/v1/worker/gpu_model_runner.py）被宣布弃用，只在 V2 尚不支持的配置下作为回退。本文 CUDA Graph 与投机解码两章的源码讲的是 V1 路径：V2 有自己的 CUDA Graph 管理（cudagraph_u...

Posted by arganzheng | August 17, 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 16, 2026

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

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。第三篇的全景图把几个核心问题放在一张图里。先从调度开始：这一轮 GPU 给谁用，每个请求推进多少 token？KV Cache 会随生成 token 增长，Scheduler 按 block 申请空间；详细管理留到第五篇。 GPU 这一轮到底给谁用？1 每个请求这一轮应该推进多少？2 这正是 Scheduler 要解决的问题。传统深度学习推理通常以固定 Batch 为基本调度单位： %% 图：传统深度学习里的 Batch：一组请求进、一组结果出 ...

Posted by arganzheng | August 15, 2026

大模型推理系统揭秘（03）：鸟瞰 vLLM：一个请求如何穿过整个推理系统？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0，commit 6e448d0ea9bf3d88d898b65449ca6dc2aec170ac，2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。文中的 V1 指引擎架构及其源码包 vllm/v1/，不是一个可选的版本：旧的 V0 引擎在 v0.11.0（2025-10-02）中被整体移除，release notes 原话是 “V1 is the only engine in the codebase now”，所以 v0.27.1 里只有这一套引擎，没有 “V2 引擎”。名字里带 V2 的只是两个组件——模型执行层的新...

Posted by arganzheng | August 14, 2026

大模型推理系统揭秘（02）：如何衡量一个 LLM Serving 系统？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。上一篇说明了 LLM Serving 为什么难：服务对象变成了持续生成过程，Prefill 与 Decode 是两种不同的 Workload，吞吐与时延无法同时最优。在动手优化之前，还需要先回答一个更基本的问题——系统到底好不好、问题出在哪一段。 LLM Serving 的性能不能只看单一指标：延迟、吞吐、效率与服务质量四个维度各自暴露不同阶段、不同资源的瓶颈。本篇的核心问题是：应该用哪些指标衡量一个 LLM Serving 系统？1 指标异常时，如何...

Posted by arganzheng | August 13, 2026

大模型推理系统揭秘（01）：为什么 LLM Serving 比传统 DL 推理难？

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。传统深度学习推理通常围绕一个相对稳定的计算过程展开：输入一批形状相近的数据，执行一次前向传播，然后返回结果。 LLM Serving 则完全不同。一个请求可能携带几十个，也可能携带数万个输入 token；模型还需要逐个生成长度未知的输出 token。在这个过程中，系统必须动态管理请求、显存、KV Cache、批次和 GPU 计算资源。因此，LLM Serving 的难点并不只是“模型更大”或“参数更多”，而是它改变了推理服务的基本执行模型：从一次性...

Posted by arganzheng | August 12, 2026

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

内容简介《大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术》以 vLLM v0.27.1 为主要分析对象，从 LLM Serving 的问题本质出发，系统讲解请求生命周期、性能指标、调度、KV Cache、GPU 执行（含投机解码）、多卡并行、Prefill/Decode 分离，引擎如何承受输入（multi-LoRA 与多模态）、输出（采样参数与结构化输出）、模型与硬件四种变化，Serving Infra 的演进方向与源码走读，以及对照 SGLang 的同题比较，共十五篇正文加一篇总结自测。本系列不局限于算子优化，也不止于源码解读，而是试图回答一个更完整的问题：一个文本生成请求，为什么会逐渐演化成一个涉及计算、显存...

Posted by arganzheng | August 11, 2026

大规模训练工程（12）：系列总结与通关自测

Large-Scale Training Engineering: Series Recap and Final Self-Test

十一篇正文回答了一个问题：一个千卡训练任务，怎么配、怎么跑满、怎么跑一个月不倒。前七篇是静态与稳态——第一篇算一张卡上四种状态的字节数与 FLOP，第二篇把每种并行写成”切哪种状态、付哪种通信”，第三至五篇各追一个 bf16 参数在 Megatron-LM、DeepSpeed、torchtitan 里的一生，第六篇把三者放在一起对比，第七篇从模型与集群规格推出 70B / 1024 卡的配置并拆解 MFU 损失；后四篇是长时——第八篇把状态写到磁盘并允许换布局读回，第九篇算故障之后每一秒去了哪里，第十篇让数值不跑飞、数据可回放，第十一篇把任务当作服务来运维。十一篇合起来，是《大规模训练工程：从并行策略到容错恢复》总纲里”训练引擎这一层”的全部。本文不讲新内容，做...

Posted by arganzheng | July 29, 2026

大规模训练工程（11）：长时训练的可观测与运维——从指标到 hang 排查

Observability and Operations for Long-Running Training

更新 @2026-09-06：本文 torchtitan 部分基于 v0.3.0 刷新；其余源码引用仍以 PyTorch 2.13.0 / Megatron Core 0.18.0 为准。前七篇把一个千卡训练任务从”配出来”讲到”跑满”再讲到”不倒”：显存账、并行策略、三个框架、MFU 拆解、checkpoint、容错、稳定性与数据。每一篇都在回答”出了某件事该怎么办”。本篇回答的是前面那半句——怎么知道出了事，以及知道之后的十分钟里该看哪里、该叫谁、该按什么顺序查。这不是一个附加题。Llama 3 论文（Dubey et al. 2024）报告的 54 天里 419 次意外中断，平均每三小时一次；同一篇论文说他们只有 3 次需要显著的人工介入，有效...

Posted by arganzheng | July 29, 2026

大规模训练工程（10）：训练稳定性与数据管线——loss spike、梯度范数、数据混合与流式加载

Training Stability and the Data Pipeline

更新 @2026-09-06：本文 torchtitan 部分基于 v0.3.0 刷新；其余源码引用仍以 PyTorch 2.13.0 / Megatron Core 0.18.0 / DeepSpeed 0.19.2 为准。前两篇处理的敌人是硬件：卡会坏、网会断、算出来的结果会悄悄错。这一篇的敌人不报错、不掉卡、不超时——任务好好地跑着，第 137,000 步 loss 从 2.1 跳到 4.8，梯度范数从 0.3 蹿到 40，然后要么在几百步后慢慢爬回来，要么再也回不来。PaLM 论文（Chowdhery et al. 2022）报告 540B 模型的训练中出现了大约 20 次这样的 spike；OLMo 2 的技术报告用了整整一节讲他们怎么把它压下...

Posted by arganzheng | July 27, 2026

Arganzheng's Blog