阿甘的博客 | Arganzheng's Blog

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

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

本文是《AI 平台工程：资源层与交付层》系列的第 6 篇（共八篇）。上一篇：网络与存储：RDMA 进容器、并行文件系统与 checkpoint I/O；下一篇：模型网关与多租户：路由、配额与灰度。一个常见的事故是这样的：某个 70B 模型的推理服务用 Deployment 部署了 2 个副本，每个副本 TP=4 占一台 4 卡机器，HPA 按 CPU 利用率 70% 扩容。晚高峰到来，用户侧 TTFT 从 1 秒涨到 20 秒，kubectl get hpa 却显示 CPU 只有 12%——vLLM 的 CPU 几乎全在等 GPU，KV cache 早已占满、几百个请求在引擎内部的等待队列里排队，而 K8s 对此一无所知。值班同学手动把副本改成 6，新 ...

Posted by arganzheng | September 7, 2026

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

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

本文是《AI 平台工程：资源层与交付层》系列的第 5 篇（共八篇）。上一篇：GPU 共享与切分：MIG、时间片、MPS 与 HAMi；下一篇：Serving 平台：从 InferenceService 到 llm-d。一个 8 节点 64 卡的训练任务在裸机上跑通了，all_reduce_perf 的大消息 busbw 接近网卡的标称值。同一个镜像、同一套 NCCL 环境变量搬到 Kubernetes 上，Pod 全部 Running，任务也在正常推进，只是 step time 慢了两倍多。再跑一次 all_reduce_perf，busbw 只剩裸机的三分之一。日志里没有报错，nvidia-smi 显示八张卡都在，ibstat 在宿主机上也一切正常。 ...

Posted by arganzheng | September 6, 2026

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

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

本文是《AI 平台工程：资源层与交付层》系列的第 4 篇（共八篇）。上一篇：AI 任务调度：gang scheduling、队列与拓扑感知　下一篇：网络与存储：RDMA 进容器、并行文件系统与 checkpoint I/O 月底看账单，推理平台上一张 80 GB 的 H100 每小时几美元，一个月跑满是四位数。再看 DCGM 的曲线：这张卡上唯一的服务是一个 7B 模型的 vLLM 副本，DCGM_FI_DEV_FB_USED 常年 22 GB 左右，DCGM_FI_PROF_SM_ACTIVE 白天峰值不到 30%，夜里几乎是零。也就是说，这张卡四分之三的显存和七成以上的算力在付费但没有产出。集群里这样的卡有几十张：每个团队的每个小模型都要”一张卡”，因...

Posted by arganzheng | September 5, 2026

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

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

本文是《AI 平台工程：资源层与交付层》系列的第 3 篇（共八篇）。上一篇：容器里的 GPU：驱动、CUDA、device plugin 与镜像　下一篇：GPU 共享与切分：MIG、时间片、MPS 与 HAMi 周一早上，集群里有 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 张...

Posted by arganzheng | September 4, 2026

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

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

本文是《AI 平台工程：资源层与交付层》系列的第 2 篇（共八篇）。上一篇：引擎的需求清单与平台的整体架构　下一篇：AI 任务调度：gang scheduling、队列与拓扑感知上一篇结束在一个 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...

Posted by arganzheng | September 3, 2026

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

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

本文是《AI 平台工程：资源层与交付层》系列的第 1 篇（共八篇）。下一篇：容器里的 GPU：驱动、CUDA、device plugin 与镜像。一个刚装好的 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 在宿主机上能看到，调度器却说”不够”。这一行事件是本系列的起点，因为它精确地...

Posted by arganzheng | September 2, 2026

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

AI Platform Engineering: the Resource Layer and the Delivery Layer

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

Posted by arganzheng | September 1, 2026

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

本文是《大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术》系列的第 14 篇（共十四篇）。上一篇：Serving Infra 的下一站：从模型执行器到分布式智能操作系统 NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。前十三篇回答了「是什么」和「为什么」，这一篇回答「怎么实现」。现在你已经知道 Scheduler 为什么要按 token 预算调度、KV Cache 为什么要分块、Attention Backend 为什么要按 batch 形态分派。带着这些...

Posted by arganzheng | August 31, 2026

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

本文是《大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术》系列的第 13 篇（共十四篇）。上一篇：PD 分离：从资源混部走向计算解耦；下一篇：回到源码：一次请求在 vLLM 内部的真实旅程 NOTE 本文基于 vLLM v0.27.1（tag 6e448d0, 2026-08-11）源码剖析。文中文件路径、类名和函数名均以该版本为准；vLLM 迭代很快，阅读时请以你手上的版本对照。在前面各篇中，我们围绕 vLLM 的核心机制展开了讨论：模型如何加载，算子如何执行，请求如何调度，以及 KV Cache 如何管理。这些机制解决的是一个核心问题：如何让一次模型推理更高效？但在真实生产环境中，请求正...

Posted by arganzheng | August 30, 2026

大模型推理系统揭秘（12）：PD 分离：从资源混部走向计算解耦

本文是《大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术》系列的第 12 篇（共十四篇）。上一篇：硬件解耦：如何不让芯片差异污染 Serving 核心？；下一篇：Serving Infra 的下一站：从模型执行器到分布式智能操作系统版本说明：实现分析以 vLLM v0.27.1（tag 6e448d0）为准，重点走读 NIXL pull + 示例 Proxy 的交接路径。通用架构、其他 Connector 的选择和系统设计建议会分别说明，不把一种实现视为 PD 分离的唯一路径。文中算例均为注明假设的理论估算，不是本地 GPU 或网络实测。前面几篇已经解释了，一个推理实例如何通过 Scheduler、KV Ca...

Posted by arganzheng | August 28, 2026

Arganzheng's Blog