阿甘的博客 | 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 平台工程（07）：模型网关与多租户——路由、配额与灰度

The Model Gateway: KV-Aware Routing, Multi-Tenancy, Quotas and Canaries

上一篇结束时，一个 70B 模型的 4 个副本已经跑在集群里，KEDA 会按 vllm:num_requests_waiting 把它扩到 6 个。把它们暴露出去最省事的做法是一个 Service 加一个 Ingress：kube-proxy 在 4 个 Pod 之间轮询，客户端拿到一个 URL，POST /v1/chat/completions，完事。这套东西跑起来没有任何报错，但第一周的监控会出现一个反直觉的图形：4 个副本的 vllm:kv_cache_usage_perc 长期不齐——一个在 95% 上下抖、两个在 60%、一个 30%；TTFT 的 p50 在 400 ms，p99 却到了 6 s；而 nvidia-smi 看总算力只用了一半。请求没有多到...

Posted by arganzheng | September 21, 2026

AI 平台工程（06）：Serving 平台——从 InferenceService 到 llm-d

Serving Platforms: KServe, Triton, Ray Serve, LeaderWorkerSet and llm-d

一个常见的事故是这样的：某个 70B 模型的推理服务用 Deployment 部署了 2 个副本，每个副本 TP=4 占一台 4 卡机器，HPA 按 CPU 利用率 70% 扩容。晚高峰到来，用户侧 TTFT 从 1 秒涨到 20 秒，kubectl get hpa 却显示 CPU 只有 12%——vLLM 的 CPU 几乎全在等 GPU，KV cache 早已占满、几百个请求在引擎内部的等待队列里排队，而 K8s 对此一无所知。值班同学手动把副本改成 6，新 Pod 调度、拉镜像、从对象存储拉 140 GB 权重、加载到显存、做 CUDA graph 捕获，8 分钟后第一个新副本才开始接流量，此时高峰已经过去一半。第二天有人把副本常驻改成 6，于是 16 张 H1...

Posted by arganzheng | September 20, 2026

AI 平台工程（05）：网络与存储——RDMA 进容器、并行文件系统与 checkpoint I/O

Networking and Storage: RDMA in Containers, Parallel File Systems and Checkpoint I/O

一个 8 节点 64 卡的训练任务在裸机上跑通了，all_reduce_perf 的大消息 busbw 接近网卡的标称值。同一个镜像、同一套 NCCL 环境变量搬到 Kubernetes 上，Pod 全部 Running，任务也在正常推进，只是 step time 慢了两倍多。再跑一次 all_reduce_perf，busbw 只剩裸机的三分之一。日志里没有报错，nvidia-smi 显示八张卡都在，ibstat 在宿主机上也一切正常。这种”没有错误、只是慢”的故障在平台层非常典型，因为它不是某个组件坏了，而是引擎想走的那条路平台没有铺。NCCL 需要直接打开 /dev/infiniband/uverbs*、在网卡上注册显存、通过 RDMA 网卡的 IP 完成...

Posted by arganzheng | September 19, 2026

AI 平台工程（04）：GPU 共享与切分——MIG、时间片、MPS 与 HAMi

Sharing and Partitioning GPUs: MIG, Time-Slicing, MPS and HAMi

月底看账单，推理平台上一张 80 GB 的 H100 每小时几美元，一个月跑满是四位数。再看 DCGM 的曲线：这张卡上唯一的服务是一个 7B 模型的 vLLM 副本，DCGM_FI_DEV_FB_USED 常年 22 GB 左右，DCGM_FI_PROF_SM_ACTIVE 白天峰值不到 30%，夜里几乎是零。也就是说，这张卡四分之三的显存和七成以上的算力在付费但没有产出。集群里这样的卡有几十张：每个团队的每个小模型都要”一张卡”，因为 nvidia.com/gpu: 1 是 device plugin 唯一听得懂的请求。于是有人把两个服务塞到同一张卡上——直接在 Pod 里不声明 GPU、用 hostPath 挂上 /dev/nvidia*。省了一半的钱，也...

Posted by arganzheng | September 18, 2026

AI 平台工程（03）：AI 任务调度——gang scheduling、队列与拓扑感知

Scheduling AI Jobs: Gang Scheduling, Queues, Quotas and Topology Awareness

周一早上，集群里有 40 张空闲的 GPU。算法团队提交了一个 4 节点 32 卡的预训练任务，kubectl get pods 显示 30 个 Pod Running、2 个 Pending。describe 那两个 Pending 的 Pod，事件是 0/12 nodes are available: 12 Insufficient nvidia.com/gpu——剩下的 8 张卡分散在四台机器上，每台两张，而这个任务的每个 Pod 要 8 张。30 个已经起来的 Pod 在 torchrun 的 rendezvous 里等那两个永远不会来的同伴，占着 30 张卡什么也不算。另一个团队的 8 卡任务也在 Pending：它要的 8 张卡本来在，现在被这 30 个...

Posted by arganzheng | September 17, 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

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

AI Platform Engineering: the Resource Layer and the Delivery Layer

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

Posted by arganzheng | September 14, 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 13, 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、要人看。所以配置推导的每一步都带...