阿甘的博客 | Arganzheng's Blog

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

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。前面几篇讨论的都是一张卡内部的事：调度器决定这一轮算哪些 token，KV Cache 决定状态放在哪里，GPU 执行决定每个 token 算多快。但模型很快就会大到一张卡装不下，或者一张卡的吞吐远远不够。这时模型、状态和通信都要在多张 GPU 之间重新分配。本篇的核心问题是：一张卡装不下、或者一张卡不够快时，模型、KV 状态和通信应该怎样在多张 GPU 之间切分？每种切法的代价是什么，通信又该如何优化？一、总览：分布式推理的混合并行策略 1...

Posted by arganzheng | August 22, 2026

大模型推理系统揭秘（07）：解码的扩展：采样、投机解码与结构化输出

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。上一篇把一轮 batch 送进 GPU，跑完 forward，拿到 logits，采样出 token——到这里，”下一个 token”似乎就是一次 argmax 或一次 multinomial。但在真实的服务里，这一步几乎从来不是那么干净的：一个请求要 top_p=0.9 加 repetition_penalty=1.1，另一个请求要求输出必须是合法的 JSON，服务本身又开着投机解码想把 300 步 decode 压成 120 步。这三件事看起来风马牛不相及...

Posted by arganzheng | August 21, 2026

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

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。前面几篇解决的是”这一轮算哪些 token”（Scheduler）和”它们的状态放在哪里”（KV Cache）。这一篇的问题是：这些已经确定要算的 token，怎么算得更快？一、总览：四种浪费与一笔账 1. GPU 上的四种浪费形态 Decode 偏 memory-bound、Prefill 偏 compute-bound，但落到 GPU 上，浪费其实只有四种形态：浪费形态症状对策 ...

Posted by arganzheng | August 19, 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 18, 2026

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

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。上一篇的全景图里已经出现了一个关键事实：KV Cache 不再是一整块连续显存，而是按 Block 动态分配和回收的资源（PagedAttention），不同请求因此可以灵活共享 GPU 显存——它的管理细节留到第五篇。有了”显存可以按块调配”这个前提，一个更直接的问题就浮上来了： GPU 这一轮到底给谁用？每个请求这一轮应该推进多少？这正是 Scheduler 要解决的问题。传统深度学习推理通常以固定 Batch 为基本调度单位： Batch...

Posted by arganzheng | August 16, 2026

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

NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。前两篇分别定义了问题（LLM Serving 为什么难）和尺子（用什么指标衡量）。在深入调度、KV Cache、GPU 执行等单个战场之前，需要先有一张全景图：一个请求进入 vLLM 之后，会经过哪些模块，以什么形式被传递，最后如何变成 token 返回给用户。本篇的核心问题是：一个请求如何穿过 vLLM 的整个推理系统——哪个模块负责决策、哪个模块负责执行，它们之间传递的到底是什么？一、总览：静态拓扑、动态生命周期与数据流 1. 三个视角看...

Posted by arganzheng | August 15, 2026

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

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

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 执行、解码的扩展（采样、投机解码与结构化输出）、多卡并行、模型适配、请求形态的扩展（multi-LoRA 与多模态）、硬件抽象、Prefill/Decode 分离与集群化部署，共十四篇。本系列不局限于算子优化，也不止于源码解读，而是试图回答一个更完整的问题：一个文本生成请求，为什么会逐渐演化成一个涉及计算、显存、调度、通信与状态管理的复杂系统？在这个视角下，LLM Serving 不再只是“把模型跑...

Posted by arganzheng | August 11, 2026

大规模训练工程（08）：长时训练的可观测与运维——从指标到 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

Arganzheng's Blog