Roger-Lv's space

mmap 能映射什么：一张全景图 引言 mmap 本质上是一种**"把任意字节序列对象映射进进程虚拟地址空间"的通用机制**——它的作用域取决于 fd 指向什么。 fd 可以是普通文件、tmpfs 文件、字符设备、GPU 节点、VFIO 组，甚至完全不要 fd（MAP_ANONYMOUS）。内核为每次 mmap 创建一个 vm_area_struct（VMA），并绑定对应的文件操作表 f_op->mmap。 所以真正决定"能不能映射、映射出来是什么"的，从来不是 mmap 这个系统调用本身，而是 fd 背后的 file_operations 实现。 123456789mmap(addr, len, prot, flags, fd, offset) │ ├─ 无 fd ──────────────► 匿名内存（零页 + COW） └─ 有 fd │ ├─ 通用路径 do_mmap() → 新建 VMA └─ f_op->mmap(fil...

Agent 沙盒基础设施实践：从 DSec 与 AgentENV 看调度层的选型与落地 引言 随着 Agentic RL 训练规模的爆发，如何为成千上万个并行 Agent 提供隔离、可复用、可快速调度的沙盒执行环境，已经成为基础设施团队绕不开的课题。 团队调度侧近期的工作重心正是这个方向——目标是对齐 DeepSeek 的 DSec 论文（arXiv:2609.22978）所描述的"调度层支持 FnCall、Container、VM 等多级运行时应对异构工作负载"的能力。目前我们的路径是：镜像分发加速在做，运行时已经落成了一套四模板形态（见 §3.12），网络和内核隔离在规划中。 平台的形态是：控制面统一编排云上 GPU 训练集群与边缘侧的机器人、传感器、摄像头，从 RL/LLM 训练一路打通到边缘部署。边缘侧通过 Kubernetes Device Plugin 把机械臂、摄像头暴露成可调度资源（资源名形如 rlinf.io/device-franka），让训练任务里的仿真环境和真机环境能用同一套声明式抽象描述。 "具身"这个定语给沙盒基...

具身智能训练存储与数据管线:JuiceFS + Lance 深度实践 具身智能的存储问题,难点不在"存得下",而在"读得随机、写得突发、流得动"——一段双臂叠衣 episode 里藏着 3 路 30Hz 相机视频、100Hz 关节状态、未来 50 步的 action chunk,训练时 DataLoader 要从数万条 episode 里随机抽 timestep 并把这几路异频流对齐成同一行。 招商局狮岩 AI Lab 的实测给出了量化答案:用 Lance 把长视频切成 GOP 尺度 blob 后,随机读吞吐相对 LeRobot 提升 1.7–6×、存储降低 42%;而地瓜机器人的集群数据则验证了另一端:JuiceFS 多云 + 分布式缓存把训练任务启动从 20 分钟压到 3 分钟、缓存命中率从 45% 提到 92%。本文把这两套栈拼成具身训练的完整存储底座。 一、具身训练的 I/O 画像:与 LLM/CV 根本不是一回事 先明确负载形态,后面所有选型推理都从这里出发。 具身数据的最小单元是 episode,不是 token,也不是单张图...

Queue Quota 深度解析:从 Volcano 三级模型到 MiniMax 级 AI 集群的调度治理实践 Queue Quota 的本质一句话就能说清:它是队列级别的资源记账单元,声明"这个队列能用多少资源、必须保多少资源、最多借多少资源、愿意借出多少资源"——区别于 namespace 级的 ResourceQuota,它的作用域是队列而不是命名空间,并且支持跨队列的借用与回收。 而 MiniMax 这类大模型公司的实际做法,是基于 Volcano 二次开发批调度器,把 Quota 建模从单纯的 CPU/内存扩展到 GPU 卡数、卡型、NVLink 域、IB 域、CPU 沙盒等多个维度,队列树直接对齐业务组织结构,配合夜间潮汐复用把 ETTR(有效训练时间比例)做到 97% 这个业界最高档位。 以下分两个层面展开:先把 Queue Quota 的理论语义讲透,再切到一线调度器研发的真实工作。 一、Queue Quota 的完整语义 1.1 为什么不能只用 ResourceQuota 原生 Kubernetes 的 ResourceQuota 工作在 ...

AI Infra 全景复盘:GPU 性能、分布式训练与调度层深度解析 本文以一次 AI Infra 岗位一面为线索,围绕 GPU 性能分析、分布式训练、RayJob 弹性伸缩、GPU 混部与调度可行性判断五大模块展开;再把面试中经常被追问的调度层作为独立章节补齐——抢占、队列、调度器框架、DRF、调度器与 Node 的解耦关系、多调度器冲突、backfill/preempt/reclaim 的跨队列语义,一次讲透。 核心观点先抛出来:Infra 面试考的不是名词背诵,而是"瓶颈定位 → 决策依据 → 工程权衡"这条完整链路的推理能力。调度层的所有机制,本质上都在"分布式一致性"和"资源效率"之间做权衡。 一、GPU 性能与分布式训练:Nsight 与并行策略 1.1 Nsight 是什么、怎么用 Nsight 是 NVIDIA 提供的 GPU 性能分析工具套件,其中最核心的是两把"不同倍率的放大镜": 工具 定位 分析粒度 典型命令 Nsight Systems (nsys) 全系统时间...

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 直接把同一块物理显存重新映射回来,数据从...

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

从零搞懂 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)三个分量,使可靠性导致的生产力损失可以被归因到生...

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 生...