阿甘的博客 | Arganzheng's Blog

置顶致读者的一封信

这个博客写什么、有哪些好玩的功能、怎么用——以及一份 FAQ

你好，欢迎来到这里。这封信不长，讲三件事：这个博客写什么、页面上那些不太常见的小功能是干什么的、以及你可能会问的几个问题。每个功能都可以在本文里直接试——这封信本身就是演示场地，随便划、随便点，不会弄坏什么。一、这里写什么主要是技术分享，近两年集中在 AI Infra：GPU、通信、大规模训练、推理系统、平台工程。为了让整个知识成为体系而不是零散的知识点，文章按系列组织——比如《大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术》十四篇、《GPU Kernel 工程：从 CUDA 执行模型到 FlashAttention》十篇、《通信与互联：从 NCCL 到 RDMA》八篇……每个系列有一篇总览，每篇文章的开头会告诉你它是...

Posted by arganzheng | August 3, 2026

置顶AI 全栈学习地图：造模型、跑模型、用模型的三张图

One System, Three Roles — an Overview of the Three AI Learning Roadmaps

内容简介这个博客的技术文章围绕三张学习地图组织：《AI 算法工程师学习地图》、《AI-Infra 工程师学习地图》、《AI 应用工程师学习地图》。每张地图把一个方向的知识分层，说明每层回答什么问题、按什么顺序学、哪些已经写成了系列。本文是三张地图之上的一页总览，回答的是三张地图各自不回答的问题：为什么是三张而不是一张？三张地图之间怎么分工、在哪里交汇？一个人该从哪一张进入，读到哪里该换到另一张？三张地图对应的是同一个系统里的三种角色。一个大模型从数据到用户手里，要被造出来（预训练、后训练、评测）、被跑起来（引擎、集群、平台）、被用起来（检索、工具、编排、产品）。三件事用同一批名词——Python、PyTorch、Transformer、KV ca...

Posted by arganzheng | January 1, 2026

AI 平台工程（02）：容器里的 GPU——驱动、CUDA、device plugin 与镜像

GPUs in Containers: Driver, CUDA, Device Plugin, DRA and Images

上一篇结束在一个 Pending 的 Pod 上：resources.limits 里写了 nvidia.com/gpu: 1，kubectl describe 里是 0/3 nodes are available: 3 Insufficient nvidia.com/gpu。原因很直接——没有任何组件告诉 kubelet 这台机器上有 GPU。但把 device plugin 装上、Pod 调度成功之后，故障并没有结束，只是换了地方：Pod Running，torch.cuda.is_available() 返回 False，日志里一行 CUDA driver version is insufficient for CUDA runtime version；或者容...

Posted by arganzheng | September 16, 2026

AI 平台工程（01）：引擎的需求清单与平台的整体架构

What Engines Demand from the Platform, and the Platform's Two Layers

一个刚装好的 Kubernetes 集群，三台 worker 每台插着一张 GPU。提交一个只有十几行的 Pod，resources.limits 里写 nvidia.com/gpu: 1，它一直 Pending。kubectl describe pod 的 Events 里只有一行：0/4 nodes are available: 3 Insufficient nvidia.com/gpu。三张卡明明在那里，nvidia-smi 在宿主机上能看到，调度器却说”不够”。这一行事件是本系列的起点，因为它精确地暴露了原生 Kubernetes 与 AI 负载之间的第一道缝：调度器不知道什么是 GPU。它只知道节点的 status.allocatable 里有没有一个...

Posted by arganzheng | September 15, 2026

扩散模型推理基础设施（10）：系列总结与通关自测

Diffusion Model Inference Infrastructure: Series Recap and Final Self-Test

九篇正文回答了一个问题：图像与视频生成这种 compute-bound 的负载，推理系统该长什么样，为什么 vLLM 的那一套在它身上大半用不上。第一篇算清一次生成三段的 FLOPs、字节与秒，第二篇在单卡上换 MFU，第三篇利用相邻步的冗余改有效步数，第四篇算视频的 \(N^2\) 与稀疏化，第五篇用通信换墙钟，第六篇看步数被蒸馏掉之后系统怎样变、KV cache 怎样回来，第七篇把这些放进一个服务，第八篇走一遍三个引擎，第九篇变成配置、评测与排障。九篇合起来，是《大模型推理系统揭秘》那条推理主线的另一半。本文不讲新内容，做三件事：把九篇压成一张表与九段回顾，把贯穿九篇的几条线拎出来，然后给一套三段式的通关自测——判断与计算、跨篇综合、面试题。各篇末尾的自测检...

Posted by arganzheng | September 14, 2026

AI 平台工程：资源层与交付层（总纲）

AI Platform Engineering: the Resource Layer and the Delivery Layer

内容简介《AI 平台工程：资源层与交付层》是一组共八篇的系列文章，面向已经跑过训练任务或推理服务、准备把它们放到一个多人共用的 GPU 集群上运行和交付的工程师，系统讲解引擎之下和引擎之侧的两层基础设施：资源层把 GPU、网络、存储组织成可调度的资源池，承载引擎运行；交付层把引擎包装成有 SLA、有配额、有账单、可观测的服务。它回答的问题是：一个 GPU 集群如何被切分、调度和喂饱？一个训好的模型如何变成一个可运维的服务？站在引擎的层面看，平台是一个”给我八张卡、一个 RDMA 网口和一个能读 checkpoint 的路径，剩下的我自己来”的黑盒。这个视角是对的，但它掩盖了一件事：平台的每一个设计决定，都是被引擎的某个需求推出来的。 ...

Posted by arganzheng | September 14, 2026

扩散模型推理基础设施（09）：配置、评测与排障——从一张卡的推导到一条伪影的排查

Configuration, Evaluation and Troubleshooting for Diffusion Inference (with Series Summary)

前八篇给出了机制与它们在账上的位置。最后一篇把它们变成两件日常工作：上线前——给定模型、分辨率、步数、GPU 与 SLO，按什么顺序推出配置，怎样证明每一项优化的性能收益是真的、质量代价是可接受的；上线后——看什么指标，p99 抬升、图片出伪影、半夜 OOM 各先查什么。扩散推理的评测有一个 LLM serving 没有的维度：多数优化是有损的（第二篇的 FP8 / INT4 / 8-bit attention、第三篇的跨步缓存、第四篇的稀疏 attention、第六篇的少步），而”损了多少”没有困惑度那样的单一数字——要对基线图算 PSNR / LPIPS、要在 prompt 集上算 ImageReward / GenEval、要人看。所以配置推导的每一步都带...

Posted by arganzheng | September 13, 2026

扩散模型推理基础设施（08）：三个引擎的对照导读——同一张图的请求在 SGLang Diffusion、vLLM-Omni 与 xDiT 里各走过什么

Three Engines Compared: One Request Through SGLang Diffusion, vLLM-Omni and xDiT

前七篇每篇末尾有一张对照表，指向三个引擎里实现同一机制的文件与类。这一篇把这些点连成线：一个”生成一张 FLUX 1024² 的图”的请求，在 SGLang Diffusion、vLLM-Omni 与 xDiT 里各自从哪里进来、经过哪些进程、哪些类、哪些函数，到哪里出去。三条线走完，三个引擎的取向就清楚了：SGLang Diffusion 把扩散塞进了 LLM serving 的结构（scheduler、worker、kernel 栈、warmup、CUDA graph 都复用），vLLM-Omni 为全模态模型设计了 stage 流水线（一个请求可以经过 LLM → DiT → TTS，扩散是其中一种 stage），xDiT 只做并行（把 diffusers 的...

Posted by arganzheng | September 12, 2026

扩散模型推理基础设施（07）：serving 形态——请求、批、三段分离、附件、异步任务与成本

Serving Diffusion Models: Request Shapes, Batching, Disaggregation, Add-ons, Async Jobs and Cost

前六篇的机制都在一个请求内部。这一篇把它们放进一个对外的服务：请求从 HTTP 进来、排队、被分到一组卡、跑三段、把图片或视频交回去、记一笔钱。LLM serving 的这一层（08 系列第三、四篇）围绕两件事组织——请求时长不可预测、memory-bound 下 batch 提吞吐——所以有连续批处理、抢占、KV 驻留。扩散的这一层围绕相反的两件事：请求时长在收到它时就完全确定（分辨率 × 步数 × CFG），batch 几乎不提吞吐（compute-bound）。于是调度像批处理系统而不像流处理系统：按时长排队、按形状分池、多实例横向扩，抢占只在步边界有意义。另外三个 LLM serving 没有的问题：三段的资源需求不同（文本编码器小且一次、DiT 重、V...

Posted by arganzheng | September 11, 2026

扩散模型推理基础设施（06）：少步与自回归——把步数变成系统参数

Few-Step and Autoregressive Generation: When the Step Count Becomes a System Parameter

前五篇都在一个前提下做交换：28 步、50 步，每步一次完整前向。步数 \(T\) 是第一篇账上最大的可调乘数，但前五篇没有动它——因为它不是系统能改的，是算法侧的：换更好的采样器（50 → 20 步）、步数蒸馏（→ 4 步、1 步）、guidance 蒸馏（去掉 CFG 的 ×2）。这一篇不讨论这些方法怎么做（在算法地图 L7 第六篇），只讨论它们做成之后系统怎么变：当 FLUX.1-dev 的 28 步变成 FLUX.1-schnell 的 4 步、一张图从 4.3 s 变成 0.7 s，前五篇的结论哪些失效、哪些不变、哪些新问题出现。然后是一个更大的变化。视频模型一直是”一次前向处理整段视频的全部 token、重复几十步”——双向 attention，生成...

Posted by arganzheng | September 10, 2026

扩散模型推理基础设施（05）：多卡并行——序列并行、CFG 并行与 PipeFusion，为什么不是张量并行

Multi-GPU Diffusion Inference: Sequence Parallelism, CFG Parallelism and PipeFusion

LLM serving 用多卡有两个理由：权重放不下（70B 的 140 GB 要切到几张卡上）、每步读权重的时间要切短（memory-bound，TP 让每张卡只读 1/p）。扩散推理的多卡理由不同：FLUX 的 22 GiB 一张卡放得下；单请求已经 compute-bound，多卡的目标是把一个请求的 FLOPs 分到 p 张卡上、让墙钟缩短 p 倍——而视频再加一个：14 GiB 的激活与几分钟的单卡时间让单卡本身不可接受。目标不同，切法就不同。切一个 DiT 前向有四种刀法：切序列（每张卡持有 \(N/p\) 个 token，attention 时交换 K / V 或交换 head——Ulysses、Ring、USP）、切 CFG 分支（条件与无条件各...

Posted by arganzheng | September 9, 2026

keynote 布局演示：给一份幻灯片配上讲稿

上面是可以翻页的幻灯片，下面是文字稿、参考资料和评论区

你现在看到的这一页就是 keynote 布局：头部不是标题图，而是一份嵌进来的在线幻灯片（方向键或点右下角箭头翻页，F 全屏，S 演讲者视图），往下滚就是这篇文章的正文——讲稿、补充说明、参考资料，文末照常有评论区、投票和阅读数。它解决的问题很具体：做完一次分享，幻灯片本身信息密度低，光放幻灯片没人看得懂；只写文章又丢了幻灯片的节奏。keynote 把两者放在一页：想快速过一遍看上面，想看细节读下面，想讨论去文末。一、怎么写三步。 1. 先有一份幻灯片。本站的幻灯片是 slides/ 目录下的 Markdown 文件，layout: slides，reveal.js 渲染，URL 是 /slides/<名字>.html——上面嵌的就是 s...