Roger-Lv's space

从零搞懂 GPU 集群调度:K8s、万卡治理、资源池化、弹性伸缩到 vLLM/SGLang/Slurm 实战 这篇长文写给算法工程师和平台工程师,从最基础的"一张 GPU 卡怎么被 K8s 认识"讲起,到"一万张卡怎么不崩",再到"大模型服务怎么在集群上跑起来",最后聊 Slurm。六大主题:K8s GPU 调度原理、万卡集群治理、资源池化、弹性伸缩、vLLM/SGLang 集群化部署、Slurm 实战。 一、开篇:为什么 GPU 调度比 CPU 调度难十倍 如果你做过 K8s 的 CPU/内存调度,可能觉得资源调度就是"分配数字资源,加个 request/limit 完事"。但当资源变成 GPU 之后,画风完全变了,原因有五个: 1. GPU 不可分割(默认情况下)。 CPU 可以按 0.1 核这样细粒度分配,内存可以按 MB 分配,但一张物理 GPU 卡,默认情况下,K8s 只能把它当作一个"整数资源"分配给一个容器——要么给你一整张卡,要么不给。这就导致一个尴尬场景:推理服...

拆解那 11.9%:大规模训练集群的生产力损失度量与自动化治理 ——解读 ASE '26 论文《Characterizing and Mitigating Productivity Loss in Large-Scale Model Training: An Empirical Study》 论文:Xue et al., Characterizing and Mitigating Productivity Loss in Large-Scale Model Training: An Empirical Study, ASE '26(第 41 届 IEEE/ACM 自动化软件工程国际会议),DOI: 10.1145/3832783.3834462 作者团队来自北京航空航天大学与快手科技,实证数据基于快手生产训练集群。 TL;DR 这篇论文做了三件事: 提出 ETPR(Effective Training Productivity Ratio):把端到端训练生产力分解为调度好put(SG)× 占空比(DC)× 生产力质量(QoP)三个分量,使可靠性导致的生产力损失可以被归因到生...

VPC 与 Cilium ClusterMesh:多集群组网的地基与上层建筑 VPC 是公有云上通过逻辑隔离为你划出的一块"私有网段+自管路由"的虚拟网络,而 Cilium ClusterMesh 解决的是多个 Kubernetes 集群之间的 Pod IP 直连、跨集群服务发现、跨集群 NetworkPolicy 与负载均衡问题;跨集群通信通常通过 VPC Peering/专线打通底层网络后,由 Cilium ClusterMesh、Submariner 等方案组网;集群与机房并非一一对应,常见是"单机房多集群(隔离/灰度)""多机房单集群(同城双活)"和"多机房多集群(异地容灾)"三种模式按容灾等级选择;混合云场景下则建议用"专线 + VPN 主备链路 + 路由器统一打通 CIDR"的思路,把公有云 VPC 与私有化机房做成一张可路由的大内网。 先看两个概念在定位上的差异: 维度 VPC Cilium ClusterMesh 层级 IaaS 层的逻辑网络 Kube...

Anchor 论文精读:解耦 GPU 内存所有权,让"浅层中断"不再付出全量恢复的代价 论文:Anchor: Mitigating GPU Shallow Disruptions with Decoupled Memory 作者:Haoyi Ma、Shiwei Gao、Youmin Chen、Junrong Huang、Youyou Lu、Jiwu Shu(清华大学 & 上海交通大学) 发表:SOSP '26(ACM SIGOPS 第 32 届操作系统原理研讨会) TL;DR 大规模 LLM 集群中的绝大多数故障其实是"浅层中断"——进程崩了,但 GPU 硬件和 OS 内核毫发无损。现有恢复机制对此一视同仁:checkpoint → 重启 → 全量重载,哪怕数据本来就还完好在显存里。 Anchor 的核心主张是:内存所有权不应与进程生命周期绑定。它用一个 daemon 进程持有 GPU 内存,worker 通过 GPU IPC 机制零开销地映射访问;worker 崩溃后,新 worker 直接把同一块物理显存重新映射回来,数据从...

Spiderpool 多网卡 IPAM 深度解析:Underlay 网络缺的那块拼图 Macvlan、ipvlan、SR-IOV 这几个 CNI 有个共同特点:数据面很漂亮,管理面近乎空白。它们能把 Pod 直接挂到物理网络上,省掉隧道封装的开销,但你问它"这个 IP 能不能跟着 Pod 漂移到别的节点"、“Pod 崩了 IP 怎么收回来”、“两张网卡的回包怎么别走错路由”,它们基本答不上来。 Spiderpool 要补的就是这块。它不是又一个新 CNI——它不碰数据面,而是给这些原生 Underlay CNI 配一套企业级的 IPAM、路由协调和连通性增强,让它们从"能跑"变成"能生产"。 这篇文章分四块: 为什么 Underlay 需要专门的 IPAM——Overlay 和 Underlay 对 IPAM 的需求差在哪; 架构与 CRD 体系——controller-agent 怎么分工,六个 CRD 各管什么; 多网卡 IPAM 全流程——从网卡划分、池选择到策略路由协调、垃圾回收; 实战与坑——部署示例,以及几...

IPoIB 与 pkey 子接口:InfiniBand 世界里的"IP 网卡 + VLAN" IPoIB(IP over InfiniBand)接口是运行在 InfiniBand 物理网络之上的"IP 网卡",pkey 子接口则是在这张 IP 网卡上按"分区键"虚拟出的子接口——两者的组合,就是 InfiniBand 世界里对"IP 网卡 + VLAN 子接口"的对应物。 之所以需要它们,根源在于 InfiniBand 与以太网是两套截然不同的 L2 体系。 一、前提:InfiniBand 不是以太网 理解 IPoIB + pkey,必须先放下以太网的思维惯性。InfiniBand 是一套独立的链路层协议,从硬件寻址开始就和以太网不同: 维度 以太网 InfiniBand 硬件地址 48 位 MAC 地址,烧录在网卡里 无 MAC;由 GUID(端口全局唯一 ID)+ LID(子网内本地 ID,由子网管理器动态分配)标识 单播地址概念 MAC GID(128 位,基于 GUID 生...

浅谈大规模集群的高性能网络容器化建设:从机器内通信到容器化 RDMA 计算机硬件的通信方式大体分为两种类型:机器内通信和机器间通信。大模型训练把这两条路径都压到了极限——GPU 之间在机器内要全速交换分片权重,跨机器要跑 all-reduce 梯度洪流。这篇文章沿着这两条路径往下走:先看机器内 NVLink/GPUDirect 那套硬件互联,再看机器间 RDMA 的三种网络与无损组网,最后落到平台侧真正要回答的问题——如何把这些高性能网络以容器的方式交付给用户。 一、机器内通信技术 1.1 共享内存 狭义上的共享内存通信,指的是在 CPU 的内存上开辟一段空间,让不同进程都能访问到。具体形式可以是某种"句柄",让数据的存在可以借助此句柄跨进程引用这片内存。在容器里我们通常说的是 /dev/shm 这个目录,不同进程直接访问,做到 zero copy。 广义上的节点内 GPU 通信走共享内存,是指支持 GPU 与第三方 PCIe 设备(网卡、存储等)通过共享 pin 住的 host memory 实现共享内存访问,从而加速通信——这就是 GPUDirect S...

Macvlan 在大模型训练中的角色:为 Pod 提供共享 RDMA 通道 在大模型分布式训练的 Kubernetes 集群里,macvlan 会被用到,但角色非常特定:它作为辅助网络为 Pod 提供访问高性能 RDMA 网络的"共享"通道,而不是承担集群默认网络的职责。 默认网络(控制面通信、Service 访问)通常由 Calico/Cilium/OVN 等标准 CNI 负责,macvlan 网卡通过 Multus 附加,专门承载 GPU 之间的训练数据流。 一、为什么大模型训练需要独立的 RDMA 网络 理解 macvlan 的定位,先要理解训练流量对网络的压力。在 PyTorch FSDP 或 DeepSpeed ZeRO 的分片训练中,每一层前向/反向传播前都要在全量 GPU 间 gather 分片权重,mini-batch 结束后要 all-reduce 梯度——这些集合通信在集群规模上可达数十 Gbit/s 的峰值流量。 如果这些流量走默认的 Overlay 网络(如 OVN-Kubernetes),内核协议栈的封解包、netfilter 处理...

深入理解 macvlan:从父子接口到内核实现 在容器网络和 Kubernetes Underlay 场景中,macvlan 是被广泛使用的高性能网络方案。但很多人对它的理解停留在"配置能跑通"的层面,对它最核心的设计——父接口与子接口的关系——缺乏深入认识。 理解这个父子关系,是理解 macvlan 一切行为(包括它的性能优势、通信限制、以及为什么需要 Spiderpool 这类方案来补齐能力)的钥匙。 macvlan 的本质是:在一个真实/下层网络接口上,虚拟出多个拥有独立 MAC 的接口。 所以必须有一个"被依附"的接口来提供物理链路,这个接口就是父接口;虚拟出来的那些接口就是子接口。 1234物理网卡 eth0(父接口) ├── macvlan0(子接口,给 Pod A) ├── macvlan1(子接口,给 Pod B) └── macvlan2(子接口,给 Pod C) 一、核心概念:父接口与子接口 1.1 父接口的作用:提供二层出口 父接口通常是宿主机上的物理网卡,也可以是 bond、bridge、VLAN 接口等。它负责真...

AI Infra课程学习 AI Infra 工程师面经（305 题版，思维导图） https://riddlego.github.io/ai-infra-interview-305/