Roger-Lv's space

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

一句话结论：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 ...

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

一句话结论：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 主干，在工程上是不可持续的——每出一个新硬件就要改一次核心代码。 设计提案里说得很...

一句话结论：把 RoCEv2 网络配成无损只是让集群「能跑起来」，真正吃掉算力的在后面——几万张卡在几个月里不停地出故障、掉速、Hang 住，而你要在没有用户配合、看不到业务代码的情况下，判断这一次的锅是硬件、是网络还是调度。 这篇给一套可执行的方法：四个监控平面分工排查、五类故障定性定位、RoCE 三种典型病的判据、三板斧的调优顺序，最后落一份巡检清单。 开场先看一个真实场景。 某集群上一个 2048 卡预训练任务，MFU 长期在 38% 上下波动。团队查了两周网络：PFC 计数正常、ECN 标记率正常、交换机上零丢包、ib_write_bw 端到端带宽也达标。 最后在 DCGM 的 SM Clock 指标上发现问题——256 台机器里有一台的 8 张卡，SM 时钟长期跑在 1.1GHz，其他机器都是 1.9GHz。这台机器是慢节点，它在每一个 AllReduce 里拖后腿，整条 ring 都要等它。换掉之后 MFU 回到 45%，而且不再波动。 这类问题在交换机上永远查不到，因为网络侧所有计数都是干净的。 边界说明：文中命令以 NVIDIA DCGM 与 nvidia-...

一句话结论：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....

一句话结论：存储到计算的 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，...

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

一句话结论：agentgateway 的对外说法是「一个进程统一 HTTP/gRPC、LLM、MCP、A2A」。但逐文件读完 v1.7.0 的实现后，我认为它真正值得学的有两点，都不在营销词里：一是它清楚自己不该做什么（推理端点选择委托给 EPP、语义缓存委托给 vSR），二是它把 Agent 的会话与身份当成一等公民（会话状态塞进自包含加密令牌、身份栈深到 SPIFFE 和 ID-JAG）。至于「AI 原生」，代码层面的含义比宣传语具体得多。 这篇文章基于对本地仓库（git describe = v1.7.0-71-g134897e1）的逐文件核对写成。凡是能验的我都验了，验不了的会明确标注来源。文末单列一节讲宣传与实现对不上的地方——这不是挑刺，而是因为一个正在快速迭代的项目，官方口径与实际行为的差距本身就是选型时要评估的风险项。 一、问题背景：传统网关为什么接不住 Agent 流量 传统 API 网关（Envoy、Kong、Nginx）的底层假设是短生命周期、无状态、一问一答。这套模型在微服务时代运转良好，但 Agent 流量有三个地方对不上： MCP 是有状态的长会...

一句话结论：这门课不教学生训大模型，教学生在大模型训练系统里做工程判断——用一个 4—8 卡的小集群，完整走一遍万卡规模下的工程决策链，并且每一步都要留下可复核的证据。 最近受老师邀请，给北大本科生排一门面向大模型 Infra 的课，方向偏训练。从零设计到成稿改了几轮，中间被问得最多的是「32 学时塞得下吗」「算力从哪来」这两个问题。这篇文章把整套设计摊开讲，包括 16 周结构、大作业形态、以及几个我认为值得复用的具体做法，希望能给准备开同类课的老师省点事。 一、定位：本科阶段教不了「训大模型」，但教得了「做工程判断」 第一个要回答的问题是：本科生不可能真的训一个千亿模型，那这门课到底教什么？ 我的答案是——教决策链，不教规模。一次大规模训练里真正难的从来不是「按下启动键」，而是一连串判断： 这个模型在这几张卡上，显存够不够？不够的话该切什么？ 切完之后通信代价是多少？瓶颈在计算、通信还是显存？ 换个框架、换个并行度，结论会不会变？ 训练挂了，怎么知道是数据、通信、存储还是代码的问题？ 这些判断的形状在小集群和万卡集群上是同一套，只是量级不同。所以课程把「规模」当作可控...