Roger-Lv's space

一句话结论：存储到计算的 I/O 路径走过四个阶段——从 read() 的 Page Cache 三次拷贝，到 Direct I/O + io_uring 绕缓存直传，再到 mmap 的按需缺页加载，最终由 GPUDirect Storage 把 NVMe 与 GPU HBM 之间压成一次 PCIe 直接 DMA。 每一代演进都在回答同一个问题：能不能少一次拷贝、少一次陷入、少一跳物理路径？ 核心驱动是让数据在物理上离计算单元越来越近、离 CPU 这个「搬运工」越来越远。 本文的内核路径描述逐条核对自 Linux 内核源码（torvalds/linux master）与 NVMe Base Spec 2.0d；GDS 部分核对自 NVIDIA 官方文档。核对中发现原稿有十余处需要更正，其中四处是事实错误、一段叙述查无实据，已在文中以 ⚠️ 标注。 一、Page Cache：Linux 缓冲 I/O 的物理真相 Page Cache 是内核对磁盘文件的内存级缓存，目的是弥合存储介质与 DRAM 之间的延迟差距——DRAM 命中约 100 ns，HDD 随机寻道约 10 ms，...

一句话结论：Device Plugin Pod 做不到、也不需要做到比 kubelet 先启动。Kubernetes 为这条链路设计的容错机制是「kubelet 兜底等待 + 插件自动重注册」——靠的是反方向的容错，而不是启动顺序的保证。 节点级组件的启动顺序靠 systemd 依赖图（kubelet 之前），Pod 级组件的顺序靠调度屏障 + 容错重试（kubelet 之后），而不是试图让后者插入前者。 这篇是 Device Plugin 的十年 的姊妹篇。那篇讲机制与问题域，这篇讲启动顺序与容错——也就是「这套机制解决了什么、又故意没解决什么」。 本文的行为描述逐条核对自 Kubernetes 官方文档与 release-1.34 源码。核对中发现原稿有五处需要更正，其中一处是把 capacity 与 allocatable 搞反了，已在文中以 ⚠️ 标注。 一、为什么顺序不能反 原因很直接：kubelet 每次启动都会删除 /var/lib/kubelet/device-plugins/ 目录下的所有既有 Unix socket，然后才重新创建自己的 kubelet....

一句话结论：Device Plugin 的本质，是把「让 Kubernetes 认识一种新硬件」这件事，从改内核代码降维成了写一个 gRPC 服务。而它的边界与局限——只能表达整数、调度决策黑盒、无拓扑感知、无故障协同——恰好勾勒出了大模型时代算力调度的完整问题域。 今天做 AI Infra，大概率不会从零写一个 device plugin，但一定会在这套机制的边界上做选型：训练集群选 Volcano 还是 KAI、推理集群选 HAMi 还是 MIG、要不要切 DRA、边缘具身用 KubeEdge 还是裸 K8s。 本文的机制描述逐条核对自 Kubernetes 官方文档与 proto 源码、NVIDIA/昇腾/HAMi/KubeEdge 各项目仓库。核对中发现原稿有十余处需要更正，其中两处是硬伤，已在文中以 ⚠️ 标注。 一、设计动机：为什么要有 Device Plugin Kubernetes 原生只认识 CPU、内存和本地存储。让每一种硬件的枚举、健康检查、分配逻辑都进 kubelet 主干，在工程上是不可持续的——每出一个新硬件就要改一次核心代码。 设计提案里说得很...

一句话结论：kubelet 不直接创建容器，它只通过 CRI（Container Runtime Interface）下达指令；真正干活的是高级运行时（containerd / CRI-O）和低级运行时（runc / kata-agent / runsc）。沙盒选型的本质，就是在决定「谁来接 kubelet 的 CRI 调用」以及「容器进程最终跑在什么隔离边界里」。对具身智能公司而言，仿真训练、Agent 工具调用、强隔离 VM、真机设备接入这四类负载对应完全不同的运行时组合——不存在一个「万能沙盒」能同时满足。 这篇是 具身智能仿真场景的沙盒选型 的下层视角。上篇回答「该选哪个沙盒」，这篇回答「沙盒插在运行时栈的哪一层、跟 kubelet 怎么耦合」。 本文的架构描述逐条核对自 Kubernetes 官方文档、containerd 源码与文档、Kata/gVisor/Firecracker 官方文档与仓库。核对中发现原稿有十余处需要更正，已在文中以 ⚠️ 标注。 一、先立骨架：kubelet 之下的运行时栈分层 Kubernetes 的容器运行时体系是明确的两层结构，这个...

一句话结论：K8s 把 GPU 当作 nvidia.com/gpu: 8 的整数资源来分配，但对 GPU 实际的 SM 占用、NVLink 拓扑、跨机 HCA 带宽一无所知。这种「只分配、不感知」的鸿沟贯穿调度、网络、存储、虚拟化、可观测性五个维度，是 AI 训练吞吐上不去的真正根因。 上一讲（K8s 很熟，为什么月薪卡在三万）讲的是怎么看——nvidia-smi topo -m 的六个缩写、NCCL 日志怎么读、AllReduce 的木桶效应。这一讲讲怎么修：五道鸿沟各自的工程解法。 本文对照 Volcano 源码、NVIDIA MIG User Guide、NCCL 官方文档与源码、JuiceFS 官方文档逐条核对过。核对中发现原稿有十余处需要更正，其中三处会导致读者照着配置失败，已在文中以 ⚠️ 标注。 五道鸿沟总览 维度 K8s 原生方案 AI 训练瓶颈 生产级方案 核心工具链 调度 kube-scheduler 逐 Pod 打分 部分 Pod 无法调度导致整组死锁 Gang 整组调度 + 多维配比 Volcano PodGroup 网络 TCP ...

一句话结论：对象存储（S3/OSS）以「扁平命名空间 + HTTP REST + 最终一致性」换取近乎无限的水平扩展与极低的单位容量成本；POSIX 并行文件系统（Lustre/GPFS/CephFS/JuiceFS）以「共享存储集群 + 元数据/数据分离 + 细粒度锁」换取微秒级延迟与聚合 TB/s 带宽。 这两套物理规律的碰撞，在大模型训练数百台机器同时写入 500GB Checkpoint 的瞬间被推向极限。 本文分两部分：上半场讲存储范式（对象存储原理 → 四类并行文件系统架构对比 → Checkpoint 风暴的成因与缓解），下半场落到工程（万卡集群如何设计异步保存，把对训练的影响压进 1%）。 所有架构描述核对自各系统官方文档与原始论文，性能数字核对自一手来源。核对中发现原稿有二十余处需要更正，其中两处是整段数字错误，已在文中以 ⚠️ 标注。 上半场：三种存储范式的物理学 一、对象存储：HTTP 语义构建的「无限货架」 1.1 扁平命名空间与 REST 接口 与文件系统「目录树 + inode」的层次化模型不同，对象存储把整个存储池抽象为 Bucket + Ob...

一句话结论：Agent 沙盒系统绕过 kubelet，不只是为了隔离——调度本身才是更根本的动机。当沙盒生命周期被压缩到毫秒级、当 pause/resume/fork 成为常规操作而非异常事件、当内存超卖成为设计目标而非运维事故，Kubernetes scheduler 那套为「秒级生命周期 Pod、删除是异常事件」设计的调度路径，就从基础设施变成了瓶颈。 AgentENV（kvcache-ai）和 CubeSandbox（腾讯云）给出了两个不同风格的答案：前者做减法，把调度器简化到只剩资源过滤 + 两种朴素策略；后者做分层，把控制面完全做成无状态、协调状态押在 Redis 上。 这是沙盒系列第三篇。前两篇分别回答「选哪个沙盒」和「沙盒插在运行时栈的哪一层」；这篇回答「为什么这两套系统连调度都要自己写」。 本文的组件名、RPC 清单、状态枚举、调度流程逐条核对自两个项目的源码与官方文档。核对中发现原稿有八处需要更正，其中一条数字查无出处已删除，已在文中以 ⚠️ 标注。 一、问题：Agent 沙盒负载对调度器提出了什么要求 先把矛盾摆清楚。传统 K8s 集群里，schedul...

一句话结论：Blackwell 和 Rubin 的硬件特性，直接决定了软件侧该往哪优化。双 die + 微缩放低精度 → FP8/FP4 成为训练推理主线；NVLink 大域 → 机架成为标准部署单元；HBM 带宽与算力的不对称 → prefill/decode 分离与专用 SKU（Rubin CPX）出现。 看清这三对因果，比记住任何单个规格数字都有用。 本文对照 NVIDIA 官方白皮书、产品页、GTC 主题演讲与相关论文逐条核对过数字。核对中发现原稿有七处需要更正，其中一处是时效性问题——NVIDIA 在 2026 年下半年下调了 Rubin 的多个规格，已在文中以 ⚠️ 标注。 一、全局视角：NVIDIA 数据中心 GPU 路线图 NVIDIA 的数据中心架构以科学家姓氏命名，并且已经从两年一代切换到一年一代。 架构 上市时间 代表产品 关键规格特征 Ampere 2020 A100 第一代 MIG、BF16/TF32 Hopper 2022（H100）/ 2023（H200） H100 / H200 第一代 Transformer Engine、...

一句话结论：GPU 是一台「用海量小计算单元换并发、用深存储层级换带宽」的吞吐机器。它所有构件——SM 内的调度器/寄存器/Shared Memory/Tensor Core、芯片级的 L2/内存控制器/HBM、系统级的 NVLink/NVSwitch——都在服务同一个目标：让 Tensor Core 永远有数据可吃、让数据永远在路上不空转。 本文以 H100（SXM5）为参考基准，对照 NVIDIA 官方白皮书逐条核对过数字。核对中发现原稿有六处需要更正，其中一处涉及 GEMM 数据流的核心步骤，已在文中以 ⚠️ 标注。 一、全景：从晶体管到集群的层级堆叠 以 H100 SXM5 为参考：8 个 GPC → 66 个 TPC → 132 个 SM（每 TPC 2 个）→ 每 SM 128 个 FP32 CUDA Core + 4 个第四代 Tensor Core，配 5 个 HBM3 堆栈、50 MB L2、3.35 TB/s 显存带宽、80 GB 容量。 ⚠️ SM 数量有三个版本，别混：H100 SXM5 = 132 SM、H100 PCIe = 114 SM、满配...

一句话结论：控制面决定「能不能跑」，数据面决定「跑多快」。K8s 的功夫全在控制面——把 Pod 调度起来、把副本数维持住；而大模型训练真正的痛点，是 GPU 之间、机器之间的数据流动快不快、堵不堵。kubectl get pods 全绿但 MFU 上不去，是典型的控制面看不见的数据面问题。 本文基于 B 站视频《K8s 很熟，为什么月薪卡在三万？大模型 AI Infra 第一讲：从控制面走到数据面》的内容框架整理，其中的技术细节我对照 NVIDIA 官方文档（nvidia-smi 拓扑定义、NCCL 环境变量文档）与相关论文做了核实与补全。核对过程中发现原稿有四处需要更正的地方，已在文中标注。 一、为什么 K8s 玩得溜，月薪却卡在三万 很多云原生工程师 K8s 炉火纯青：写 YAML、调 Deployment、写 Operator、排 Pod 故障、扩缩集群，整套控制面技术一气呵成，但薪资天花板死死卡在三万上下。而那些看起来「只是会跑 nccl-tests」的 AI Infra 同事，年薪轻松翻倍。 差距不在于会不会写 YAML，而在于是否看懂了 K8s 之下的数据面。...