Roger-Lv's space

一句话结论：从 IOMMU（硬件地址翻译与 DMA 隔离）→ VFIO（设备直通框架）→ SR-IOV（PCIe 级切分）→ MIG（硅片级硬切分）→ vGPU（软件时间片调度）这条链路，构成了 GPU 虚拟化的完整技术栈。「IOMMU 划边界、VFIO 做移交」这条直通链路，是所有 GPU 沙盒和具身仿真基础设施绕不开的地基。 本文按「技术原理 → 两大落地场景 → 一个真实落地案例 → 决策树」四层展开，并把各技术支持的功能以表格汇总。 所有技术描述核对自 Linux 内核文档、NVIDIA 官方文档、Intel/AMD 官方文档与各项目仓库。核对中发现原稿有二十余处需要更正，其中三处是实质性错误，已在文中以 ⚠️ 标注。 一、技术原理层：从 IOMMU 到 vGPU 1.1 IOMMU：硬件级安全边界 IOMMU 是提供地址翻译与设备隔离的硬件单元：对设备发出的 DMA 做 IOVA → HPA 翻译与访问保护，并提供中断重映射；隔离以 IOMMU group 为粒度。Intel 侧叫 VT-d，AMD 侧叫 AMD-Vi。 Linux VFIO 内核文档原文： ...

一句话结论：Ubuntu 镜像里根本没有内核。 它不是一个「完整的 Linux 系统」，只是一份 rootfs——打包好的用户态二进制和库文件。容器里的进程发起的每一个 syscall 都直接打到宿主机内核上，namespace 只是给进程一个「看起来像独立系统」的视图，不是真的给它装了一个内核。 而 Kata 和 Firecracker 之所以「有自己的内核」，是因为它们在容器外多加了一层 VM，VM 里需要一份 guest kernel 来承载上面的容器——整个链路里只发生了一次虚拟化，不是嵌套。 本文的机制描述与实测数据核对自 Docker Registry 实际镜像内容、Linux 内核文档与 man pages、glibc 与 kmod 源码、Kata Containers 与 Firecracker 官方文档。核对中发现原稿有十余处需要更正，其中一处是流传很广的机制错误，已在文中以 ⚠️ 标注。 一、把「Linux 系统」拆开看：内核和用户态是两件事 日常说「Ubuntu 22.04」这个概念，其实打包了两个完全独立的东西： 组成部分 具体内容 来源 放在...

从微信记录到蒸馏自己：蒸馏工作流全教程 1. Target 本文是关于从MAC/Windows电脑上通过各种使用痕迹（尤其是微信）蒸馏出自己完整人格/习惯的教程 你可以直接让claude code读这个网页链接，让它告诉你该怎么一步步操作，包括后续如果遇到问题也可以问claude code 2. Process 其中微信提取聊天记录这部分网上的相关工具基本上已经下架（🐧的法务你是知道的） 需要用到的工具包括： claude code / codex等本地Agent工具 用于提取微信聊天记录的工具： weflow未删减版：用于获取密钥（这个网盘中有对应教程，这个网盘随时可能会删） 点击链接：https://pan.baidu.com/s/1UUr-w-a2taGbQKDDon0hzQ 提取码：sqhh 这一步如果顺利是可以拿到聊天记录的，就不用考虑2.2这一步了；如果在最后一步有问题，记得把提取出来的密钥保存下来，后续2.2 有用 另外网上也有其他教程，可以自己探索下如何拿到密钥 https://github.com/Roger-Lv/wechat-extract...

一句话结论：重庆不是我的退路，是我的解馋点。这两件事我花了很久才分清。 一、卤鹅 2025 年 4 月，我老家荣昌突然出名了。 起因是一个被叫作「卤鹅哥」的人，追着来中国的外国网红投喂卤鹅。事情本身很荒诞，效果很实在——那阵子荣昌的卤鹅店销量翻了 4000%，五一还没到我就在猜人流量要爆。 我当时在外地。看到消息的第一反应不是自豪，是困惑。因为我发现自己跟卤鹅哥是小学校友。这条信息对我没有任何用处，但那天我盯着屏幕看了很久。 荣昌是个什么样的地方？在 2025 年之前，它的名片是猪。荣昌猪，中国三大地方猪种之一，我从小听这个词听到麻木。卤鹅当然也吃，但说实话，我从来没觉得它是我们那儿最值得说出口的东西——因为它太不家常了。家常的是猪油、是腊肉、是外婆坛子里的东西。卤鹅是要专门去买的，是逢年过节、有人从老家来、或者自己馋得受不了的时候，才会想起来的那一类。 结果它火了。 那之后我每次回家，行李箱里都要塞两只。北京的朋友吃过一次之后开始点名要。我后来总结出一句：提个卤鹅堪比偷渡——真空包装、冰袋、泡沫箱，过安检的时候总觉得会有人拦我。 二、解馋 我给重庆下过一个很刻薄的判断：重庆...

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

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