Roger-Lv's space

Linux 内核模块程序结构:五要素、宏展开,以及教程里常见的四个错误 写完第一个 “Hello World” 内核模块之后,大多数人会卡在同一个地方:代码能跑,但不知道为什么能跑。module_init 是怎么让内核找到入口的?__init 到底省了什么?MODULE_LICENSE 不写会怎样? 这篇笔记做两件事: 把内核模块的程序结构拆成六个部分,每个部分讲清楚它是什么、内核拿它做什么; 往下钻一层——这些宏展开成什么代码、在 .ko 里落到哪个 ELF 段。 另外,我在整理过程中发现有几个说法在中文教程里流传很广但是错的,其中一个(init 失败会自动调用 exit)直接关系到资源泄漏。文末有一份订正清单,赶时间可以直接跳到第十节。 一、最小骨架:一个模块的五要素 先看一个能正常编译加载的最小模块: 12345678910111213141516171819#include <linux/init.h> // __init / __exit,以及初始化相关宏#include <linux/module.h> // module_i...

RDMATracer 拆解:13 个 eBPF 探针如何补上 AI 集群的内核盲区 2026 年 8 月 17 日,SIGCOMM 2026 在丹佛开会的第一天,第三届 Networks for AI Computing workshop(NAIC '26)上出现了一篇只有 6 页的论文:《RDMATracer: A scalable eBPF-based framework for tracing RDMA syscalls》。作者名单几乎全是 Meta 的生产工程师与网络研究员——Prankur Gupta、Miao Xu、Maxim Samoylov、Prashanth Kannan、Rajiv Krishnamurthy,加上 CMU 的 Theophilus A. Benson。 论文标题很平实,讲的是一个已经在线上连续运行多年的 eBPF 工具。但它要回答的问题一点都不平实:当十万卡规模的 AI 训练集群任务崩溃时,为什么有一类故障在所有现成的监控系统里都看不到? 这篇文章是我读完论文和配套的 LPC 2025、FOSDEM 2026 演讲材料之后的拆解笔记。我最感兴...

RDMA 全链路拆解:从 ibv_reg_mr 到硬件,再到 AI 训练平台的实战落点 RDMA 这套东西之所以让人望而生畏,不是因为哪个概念特别难,而是因为它把三个本来独立的知识域压进了同一条调用链:Linux 内核系统调用机制、内存管理、网络硬件。单独看每个术语都不复杂,叠在一起才显得信息量爆炸。 这篇文章分三大块: 调用链——从 ibv_reg_mr 一路走到 HCA 硬件,每一层在做什么; 术语地图——把所有黑话按类别拆开,每个只给一句人话; 实战落点——AI 训练云平台上,这条链路到底体现在哪些日常工作里。 先正一个名。 中文社区里偶尔能看到 “ubverbs” 这个写法,它不是标准名称。内核里承接用户态 verbs 请求的模块叫 ib_uverbs(Userspace Verbs),源码在 drivers/infiniband/core/uverbs*.c。本文统一用 ib_uverbs。 关联阅读: 这条链路上的故障怎么观测,我在 《RDMATracer 拆解:13 个 eBPF 探针如何补上 AI 集群的内核盲区》 里写过。那篇讲的是"怎么看见...

Kthena 实战解析:让 Kubernetes 真正理解 Prefill、Decode 和 KV Cache 如果想在 Kubernetes 中运行一个 Qwen 模型,只需准备好模型文件和 vLLM 镜像,写一个 vLLM 的 Deployment,申请 GPU,再配一个 Service,很快就能拿到 OpenAI 的 /v1/chat/completions 接口。 但当模型从一个变成一组、GPU 从一张变成多机多卡,问题就不再是"Pod 能否启动"了。Kthena 可以在 Kubernetes 上解决这些问题:vLLM 继续负责把模型跑快,Kubernetes 继续管理 Pod 和 Service,Kthena 则将 LLM 的角色、组、GPU 位置、KV Cache 和 Token 负载带进调度、路由与扩缩容过程。 本文基于微信公众号文章《Kthena:让 Kubernetes 真正理解 Prefill、Decode 和 KV Cache》整理,保留了全部实验数据与 YAML 配置。 一、为什么要有 Kthena:模型在 K8s 部署的痛点 D...

云多租户网络隔离全景:从 Hypervisor 到 VNI,一层层看懂租户是怎么被隔开的 多租户是云计算的立身之本——成千上万个互不信任的租户共享同一批物理机、同一批交换机、同一批存储盘,却要求彼此"看不见、摸不着"。这篇文章从计算、网络、数据、管理面四个维度拆解隔离体系,然后聚焦最核心也最容易被误解的一环:VPC 逻辑隔离为什么真的能隔离。我们会用一个"故意撞 IP、故意共宿主机"的例子逐跳追踪报文,再回答两个高频疑问:subnet 能不能做租户隔离?subnet 在路由表和交换机里的真实拓扑长什么样? 一、多租户隔离体系总览 隔离的本质命题是:在共享物理资源的前提下,为每个租户构建一个"逻辑上独立、必要时可物理隔离"的运行环境,同时兼顾安全性与资源利用率。 不同云服务模型的隔离锚点不同:IaaS 靠 Hypervisor 和网络虚拟化,PaaS 靠容器沙箱与命名空间,SaaS 靠应用层的 Tenant-ID 与数据权限策略。 隔离维度 共享程度 核心实现机制 典型技术/产品 计算隔离 共享硬件,独立内...

构建高可用云原生架构:从云基础组件到 K8s 控制平面的全景指南(含架构图详解) 在当今的云原生时代,无论是后端开发者、运维工程师还是架构师,每天都会被各种眼花缭乱的技术名词包围:ECS、SLB、mTLS、Service Mesh、Kube-OVN、声明式 API…… 这些概念看似分散在各个领域,但实际上它们共同拼图成了现代高可用、高并发应用的基础设施骨架。本文将通过一张张架构图,带你从底层的云服务器,一路漫游到 Kubernetes 的控制平面大脑。 第一层:云上的"砖块"与"门卫"——ECS 与 SLB 所有云上架构的起点,都离不开计算与流量分发。在阿里云等公有云体系中,最基础的黄金组合就是 ECS(弹性计算服务,即虚拟机)与 SLB(负载均衡)。 经典组合架构全景图 123456789101112131415 公网用户 │ ▼ ┌─── [EIP / SLB] ───┐ ← 接入层:流量分发、健康检查、SSL 卸载 │ ...

RLark 深度解析:跨集群具身智能云原生平台的全栈架构 具身智能有个硬约束:训练在云上 GPU 集群跑,部署在边缘的机械臂/相机/传感器上——两者物理上分布在不同的网络、不同的集群、甚至不同的安全域。现有平台要么只管云训练(K8s/Volcano),要么只管边缘设备(ROS),中间那条"云到边、跨集群、带鉴权"的路没人铺。 RLark(github.com/RLinf/RLark,2026/08 开源,Apache 2.0)就是来铺这条路的——一个跨集群具身智能云原生平台:用 kcp 做轻量控制面,统一管理云 GPU 集群和边缘设备,通过 Domain/Node/Job/Task/Workflow 一套 CRD 把"训练→部署"全链路声明式化,再用 TUN+gVisor+SSH 隧道让跨集群 Pod 直接通信,最后用 Device Plugin 把 ROS 机器人和相机接进 K8s 调度。 本文基于源码深挖,把 RLark 拆成四层:CRD 模型、kcp 控制面、跨集群 Pod 网络、具身运行时。 关联阅读:具身智能训练栈与数据管线见 ...

大模型容错训练系统设计:从故障检测、原地恢复到 TLA+ 形式化验证 本文基于一个真实落地的容错训练系统(下称 Aegis)的设计文档与源码整理,隐去了公司与内部组件信息,聚焦技术方案本身。 大模型训练的稳定性问题,是所有大规模训练团队的共同痛点。本文拆解 Aegis 的完整设计:为什么在调度平台层做容错、gRPC+NATS 双通道怎么配合、Master-Worker 状态机怎么流转、容错计数怎么算、故障节点怎么隔离,以及最有意思的一环——用 TLA+ 形式化验证状态机的安全性。 关联阅读:训练侧并行与通信见 图解 Megatron 的 SP/CP/EP、分布式训练核心技术:从 FSDP 到 All-Reduce。容错是这些训练技术之下的"稳定性底座"。 一、为什么需要专门的容错系统:三大痛点 1.1 训练频繁中断是常态 大模型分布式训练几乎都是同步方式(DDP/MPI):所有进程共同构建一个通信拓扑,任何一个进程出错,其他进程都会相继退出。而训练任务动辄跨数百个 GPU 节点,数小时到数天内大概率出各种问题: OPT 175B 训练的 LogBo...

一文搞懂 AI 推理部署:算子融合、TVM、TensorRT 与 ONNX Runtime 写给刚接触 AI Infra 的你:为什么模型训练完不能直接上线?中间那一堆"编译器""运行时"到底是什么关系?这篇文章带你从头理清。 引言:一个模型的上岗之路 假设你用 PyTorch 训好了一个图像分类模型,准确率不错。现在老板说:“把它部署到线上服务,要求单次推理延迟低于 10ms。” 你兴冲冲地把模型加载进 Flask 接口,一压测——延迟 50ms,GPU 利用率才 30%。问题出在哪? 原来,训练好的模型和"能高效跑在生产环境的模型"之间,隔着一整个优化世界。这个世界的主角,就是本文要讲的几个概念:算子融合(Operator Fusion)、TVM、TensorRT、ONNX Runtime。 在展开之前,先记住一张全景图,后文会反复回到它: 1234567891011121314151617181920┌─────────────────────────────────────────────┐│ 训练框架层:P...

具身智能数据平台三大件:清洗、数据集管理与评测分析怎么落地 本文是 具身智能的数据地基:从传感器带宽到湖仓、清洗、评测与回流闭环 的落地实操篇——那篇讲全景与选型,这篇把三大件怎么写代码、怎么衔接拆透。 具身智能的数据工程,说到底就是三件事:把脏数据洗干净(Spark + Daft)、把干净数据管起来(Iceberg + LeRobotDataset)、让数据可查可分析(Doris / StarRocks)。这三个环节分别对应数据生命周期的不同阶段,解决的是完全不同性质的问题——如果混淆了层次,很容易在选型上踩坑:比如试图用 Spark 直接管理数据集版本,或者让 OLAP 引擎承担数据清洗的重活。 这篇文章把这三个模块逐一拆开,讲清楚每个工具在具身场景下的定位、用法和它们之间的衔接方式。 一、Spark + Daft:具身数据清洗管线怎么写 1.1 为什么需要 Daft,Spark 自己不够吗 Spark 擅长海量结构化数据的 ETL,但具身智能的数据主体是多模态非结构化数据——视频、图像、点云、张量。用原生 Spark 处理视频,你需要自己写 UDF 管理解码器、处理分...