CS Basics

计算机基础知识

操作系统 · 组成原理 · 网络 · Linux/容器 · 编程工程 · 分布式与 AI Infra

osarchitecturenetworkinglinuxcppdistributed

Module Switcher

计算机基础知识

系统与硬件2

网络与容器2

AI 视角与工程3

内容模块

操作系统基础

基础★☆☆⏱ 75 min

一句话结论

进程是资源隔离单位、线程是内核调度单位、协程是用户态调度的轻量执行单元——三者按「谁拥有资源、谁被内核调度、谁在用户态切换」分层，切换成本依次降低，隔离性依次减弱。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	概念类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

进程、线程、协程：资源边界和调度主体

操作系统面试里，进程、线程、协程不是三个孤立定义，而是三种不同层次的执行模型。核心问题是：谁拥有资源，谁被内核调度，谁在用户态切换。

概念	资源边界	调度者	切换成本	适合场景	典型风险
进程	独立虚拟地址空间、文件描述符、信号处理、资源限制	内核	最高	强隔离、多服务、多 worker、容器主进程	IPC 成本高，共享状态复杂
线程	共享进程地址空间，独立栈和寄存器上下文	内核	中等	CPU 并行、I/O 并发、推理 worker pool	锁竞争、数据竞争、死锁、false sharing
协程	运行在线程内，共享进程/线程资源	用户态 runtime	最低	高并发 I/O、异步 RPC、事件循环	阻塞调用会卡住调度线程，不能自动利用多核

一句话：进程是资源隔离单位，线程是内核调度单位，协程是用户态调度的轻量执行单元。

上下文切换到底切什么

切换类型	需要保存/恢复	代价来源	排查信号
进程切换	寄存器、内核栈、页表/地址空间、调度状态	TLB 失效、cache 污染、内核调度	`pidstat -w`、`vmstat cs`
线程切换	寄存器、线程栈、调度状态	内核调度、cache 污染、锁等待	`top -H`、`perf sched`
协程切换	用户态栈/状态机、少量寄存器	runtime 调度，通常无需内核态	runtime profiler、事件循环延迟

Q: 进程、线程、协程有什么区别？面试怎么回答？

回答思路：先按资源隔离、调度主体和切换成本三条线回答，再补适用场景。

进程

进程拥有独立地址空间和资源边界，隔离性最好，适合服务拆分和容器主进程，但跨进程通信成本较高。

线程

线程共享进程地址空间，是内核实际调度的执行实体，适合多核并行，但需要处理锁、数据竞争和死锁。

协程

协程是用户态调度的轻量执行单元，适合 I/O 密集和高并发，但单个线程内的协程不能自动利用多核，阻塞调用会影响整个调度线程。

面试口径：进程看隔离，线程看并行，协程看轻量异步；不要只背定义，要说出调度和资源边界。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

死锁是一组线程互相持有对方需要的资源、谁都无法继续，需要互斥、持有并等待、不可剥夺、循环等待四个条件同时成立，破坏任意一个即可预防。工程上最实用的是破坏循环等待——所有线程按统一顺序加锁，再用锁超时兜底，比背银行家算法更落地。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	概念类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

死锁：四个必要条件

死锁是指一组进程/线程互相持有对方需要的资源，谁都无法继续。下面四个条件同时满足才会发生，破坏任意一个即可预防。

条件	含义	破坏方式
互斥	资源同一时刻只能被一个持有	资源可共享化（多数难破坏）
持有并等待	持有资源的同时等待新资源	一次性申请全部资源
不可剥夺	资源不能被强行抢走	允许超时释放、可抢占
循环等待	存在环形等待链	按全局固定顺序加锁

工程上最常用、最实用的手段是破坏“循环等待”——所有线程按统一顺序加锁。

处理策略：预防 / 避免 / 检测 / 恢复

策略	做法	代价
预防	破坏四条件之一（如固定加锁顺序）	降低并发或资源利用率
避免	运行时判断是否进入不安全状态（银行家算法）	需预知最大需求，实际少用
检测	构建资源分配图找环	检测有开销
恢复	杀进程、回滚、抢占资源	有副作用，需可重试

大多数业务系统采用预防 + 超时：统一加锁顺序避免大部分死锁，再用锁超时（try_lock + 超时回退）兜底，而不是上线复杂的银行家算法。

经典死锁代码（加锁顺序不一致）


// 线程 A: lock(mutex1) -> lock(mutex2)
// 线程 B: lock(mutex2) -> lock(mutex1)   <-- 顺序相反，可能死锁

// 修复：所有线程统一按地址/ID 顺序加锁
std::lock(mutex1, mutex2);            // C++ 一次性获取，避免顺序问题
std::lock_guard g1(mutex1, std::adopt_lock);
std::lock_guard g2(mutex2, std::adopt_lock);

死锁排查与活锁/饥饿区分

现象	特征	排查/区分
死锁	线程互相等待，CPU 不忙但卡死	`gdb` / `pstack` 看线程栈都停在 lock；`jstack`（Java）能直接报 deadlock
活锁	线程不停重试却都没进展，CPU 很忙	加随机退避打破对称
饥饿	某线程长期抢不到资源	用公平锁、优先级 aging

和 AI Infra / 分布式的联系

死锁不只在单机锁里出现：① 分布式训练中，集合通信（如 NCCL all-reduce）要求所有 rank 都参与，如果某个 rank 因异常没进入通信原语，其他 rank 会一直等待，表现为整作业 hang（本质是分布式死锁/挂起）；② 资源调度中，多个大作业各占一部分 GPU 又都等不到完整资源，形成资源死锁，需靠 gang scheduling（要么全给要么不给）破解；③ 数据库/分布式锁跨服务加锁顺序不一致同样会死锁。排查训练 hang 常用 py-spy dump / 看各 rank 卡在哪一步。

Q: 如何预防死锁？工程上最实用的办法是什么？

理论上破坏四个必要条件之一即可，但互斥和不可剥夺往往难破坏。工程上最实用的是破坏循环等待：给所有锁定义全局顺序，任何线程都按同一顺序加锁，环就不可能形成。再辅以锁超时 + 可重试兜底，以及减小锁粒度、缩短临界区、能用无锁结构就用无锁。

面试口径：先说四条件，再落到“统一加锁顺序 + 超时回退”这种可落地的方案，比背银行家算法更有说服力。

Q: 分布式训练任务 hang 住了，可能和死锁有什么关系？

集合通信是同步屏障，要求所有 rank 一起到达。如果某个 rank 提前报错退出、走了不同的代码分支、或数据加载卡住没进入 all-reduce，其余 rank 会在通信原语上无限等待，整个作业 hang——这是一种分布式层面的“互相等待”。排查时用 py-spy/栈抓取看各 rank 卡在哪，常见根因是 rank 间逻辑分支不一致或某卡 OOM/异常。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

进程是资源分配单位、线程是执行调度单位、协程是用户态轻量执行流。AI Infra 里这套并发模型直接决定数据加载吞吐和推理服务并发：Python 数据预处理用多进程绕过 GIL，推理前后处理和网络收发用线程池或协程。线程过多反而会让 CPU 时间耗在上下文切换和锁竞争上。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	概念类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：进程、线程与并发模型

AI Infra 面试里，进程、线程和协程不是概念背诵题，而是资源隔离、调度成本、数据加载吞吐和推理服务并发模型的基础。

核心概念定义

概念	定义	面试重点
进程	操作系统分配资源的基本单位，有独立虚拟地址空间、文件描述符表、信号处理和权限上下文。	隔离性强，崩溃影响小；创建和切换成本高于线程。
线程	进程内的执行流，共享进程地址空间和打开文件，拥有独立栈、寄存器上下文和调度状态。	通信方便、切换较轻；需要处理锁竞争、数据竞争和内存安全。
协程	用户态轻量执行流，由语言运行时或框架调度，通常用于大量 I/O 等待型并发。	切换不必进入内核；阻塞系统调用会阻塞承载线程，必须配合非阻塞 I/O。
IPC	进程间通信机制，包括 pipe、socket、shared memory、message queue、signal。	共享内存最快但同步复杂；socket 通用但有拷贝和协议开销。
同步原语	mutex、rwlock、semaphore、condition variable、barrier 等。	要能说明互斥、通知、资源计数、阶段同步分别适合什么场景。

需要掌握

进程与线程的区别：地址空间、资源隔离、崩溃影响范围、上下文切换成本。
用户态线程与内核态线程的区别：用户态切换快，内核态线程可被 OS 真正调度到多核。
多进程、多线程在 CPU 密集型和 I/O 密集型任务中的适用场景。
线程池为什么存在：避免频繁创建销毁线程，限制并发度，保护下游资源。
协程为什么适合网络服务：大量连接多数时间在等待 I/O，用少量线程承载大量逻辑执行流。
死锁产生条件：互斥、占有且等待、不可剥夺、循环等待。

上下文切换成本来自哪里

上下文切换要保存和恢复寄存器、程序计数器、栈指针、调度状态。进程切换还可能切换地址空间和页表，破坏 TLB；线程切换虽然共享地址空间，但仍会破坏 cache locality。大量线程竞争锁或频繁阻塞唤醒，会导致 CPU 时间消耗在调度和内核态，而不是业务计算。

AI Infra 相关关注点

DataLoader 多进程加载数据可以绕过 Python GIL，但会引入进程间队列、pickle/IPC、shared memory 和 copy-on-write 成本。
Python GIL 会限制纯 Python CPU 密集型多线程并行，训练框架常用多进程、C++ 后端释放 GIL、CUDA 异步执行来绕过。
推理服务常用线程池处理 tokenizer、detokenizer、网络收发、日志和业务逻辑；线程过多会造成 context switch 和锁竞争。
CPU 线程数、NUMA 绑核、DataLoader worker 数量会影响 GPU feeding，CPU 准备 batch 不连续会让 GPU 周期性空转。
多 worker 数据预处理要关注队列深度、worker 异常退出、共享内存大小和主进程是否及时消费。

高频问题

Q: 进程和线程有什么区别？什么时候用多进程，什么时候用多线程？

进程是资源分配单位，线程是执行调度单位。进程有独立地址空间，隔离性强，适合强隔离、绕过 GIL、崩溃不互相影响的场景；线程共享地址空间，通信方便，适合 I/O 密集、共享状态多、延迟敏感的服务。AI Infra 中，Python 数据预处理常用多进程，推理服务前后处理和网络收发常用线程池或协程。

Q: mutex 和 semaphore 的区别是什么？

mutex 是互斥锁，用来保护临界区，一般强调谁加锁谁解锁；semaphore 是计数信号量，用来表示可用资源数量，可以允许多个执行流同时进入。连接池容量、GPU slot、队列容量更像 semaphore；共享 map、调度器状态更新更适合 mutex/rwlock。

Q: Python 多线程为什么不能很好利用多核 CPU？

CPython 有 GIL，同一时刻通常只有一个线程执行 Python bytecode，所以纯 Python CPU 密集型多线程不能真正并行利用多核。但 I/O 阻塞、C++ 扩展、CUDA kernel launch 等可能释放 GIL，因此训练框架常通过 C++/CUDA 后端、多进程 DataLoader 和异步 pipeline 提升吞吐。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

内存排查不能只看"容量够不够"，要同时看四个维度：容量（系统内存/cgroup limit/GPU 显存）、带宽（HBM/内存吞吐）、延迟（page fault/swap/远端 NUMA）和局部性（CPU/GPU/NIC 是否同 NUMA 域）。系统内存、cgroup 可用内存、本地 NUMA 内存、GPU 显存是四个不同的资源池，任何一个不够都可能 OOM 或变慢。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	机制类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

内存问题不是只看容量

内存排查要同时看系统内存、cgroup limit、GPU 显存、NUMA locality、page cache、swap、带宽和碎片。容量够不代表没有瓶颈。

内存问题基础模型

维度	看什么	典型问题	排查入口
容量	系统内存、cgroup、GPU 显存	OOMKilled、CUDA OOM	`free -h`、`memory.current`、`nvidia-smi`
带宽	内存/HBM 吞吐	容量够但吞吐低	`perf`、DCGM、Nsight
延迟	page fault、swap、远端 NUMA	P99 抖动	`vmstat`、`numastat`
局部性	CPU/GPU/NIC 是否同 NUMA 域	跨 socket 访问慢	`numactl -H`、`nvidia-smi topo -m`

OOM、CUDA OOM 和 cgroup OOM

类型	资源池	触发者	现象
系统 OOM	宿主机内存	Linux OOM killer	进程被 kill，dmesg 有记录
cgroup OOM	容器 memory limit	cgroup memory controller	Pod OOMKilled
CUDA OOM	GPU 显存	CUDA runtime / 框架 allocator	程序抛 CUDA out of memory

Q: NUMA 是什么？为什么机器内存没用完也可能 OOM 或变慢？

NUMA 是 Non-Uniform Memory Access。多 socket 机器上，每个 CPU socket 有本地内存控制器，访问本地内存快，访问远端内存慢。进程可能被 cpuset、membind、cgroup 或 hugepage 池限制，只能使用部分内存；即使宿主机总内存没用完，也可能因为本地 NUMA node 不足或碎片导致分配失败。

面试口径：机器总内存、当前 cgroup 可用内存、本地 NUMA 内存、GPU 显存是不同资源池。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

虚拟内存让每个进程都以为独占连续地址空间，CPU 访问虚拟地址、MMU 通过页表翻译成物理地址，带来隔离、超额使用和按需分配。一句最该记的话：虚拟内存是"承诺"，物理内存是"兑现"，兑现发生在第一次写入触发缺页时——所以 malloc 1GB 不会立刻占物理内存。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	机制类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

虚拟内存：每个进程一套“假地址”

虚拟内存让每个进程都以为自己独占一整块连续地址空间。CPU 访问的是虚拟地址，由 MMU 通过页表翻译成物理地址。这带来三个核心价值：进程间隔离、地址空间比物理内存大（靠换页）、按需分配与共享。

能力	机制	意义
隔离	每进程独立页表	一个进程访问不到另一个进程内存
超额使用	page fault + swap	虚拟空间可大于物理内存
按需/延迟	lazy allocation、COW	malloc 不立刻占物理页，fork 不立刻拷贝
共享	多进程映射同一物理页	共享库、共享内存

分页与地址翻译

内存被切成固定大小的页（通常 4KB），物理内存切成同样大小的页框。页表记录“虚拟页 → 物理页框”的映射。现代 64 位系统用多级页表（如 x86-64 四级）避免单级页表过大。

虚拟地址

拆成页号 + 页内偏移

查 TLB

命中则直接得到物理页框（快）

查页表

TLB miss 时逐级走页表（page walk）

物理地址

页框号 + 偏移，访问物理内存

TLB 是页表的缓存。TLB miss 要走多级页表，代价高；这也是大页（HugePage）能提速的原因——同样内存用更少的页表项，TLB 覆盖更大。

缺页中断（Page Fault）三种类型

类型	触发	处理	代价
Minor（软）	页在内存但未建立映射（如 COW、共享页）	内核补页表项	低
Major（硬）	页不在内存，需从磁盘/swap 读入	发起磁盘 I/O 换入	高（毫秒级）
Invalid	访问非法地址	发 SIGSEGV，进程崩溃	段错误

排查信号：vmstat 的 si/so 列、/proc/<pid>/stat 的 majflt、perf stat 的 page-faults。Major fault 暴涨通常意味着内存不足开始 swap，P99 会剧烈抖动。

页面置换算法

算法	思想	问题
FIFO	先进先出	可能换出热点页，有 Belady 异常
LRU	淘汰最久未使用	精确实现成本高
Clock / 近似 LRU	用访问位环形扫描近似 LRU	Linux 实际采用的近似方案

Linux 用基于 active/inactive 链表的近似 LRU（带 second chance），而不是教科书纯 LRU，因为纯 LRU 维护开销太大。

和 AI Infra 的联系

虚拟内存机制直接影响大模型系统：① pinned memory（页锁定内存）禁止换页，才能让 GPU DMA 安全直传，是 H2D/D2H 拷贝提速的关键；② mmap 加载权重用按需缺页避免一次性读入巨大文件；③ HugePage/THP 减少 TLB miss，对大块连续访问的训练/推理负载有收益；④ 避免 swap，训练进程一旦触发 major fault 换页，吞吐会断崖式下降，所以训练节点通常关 swap。

Q: malloc 申请了 1GB 内存，物理内存马上就被占用了吗？

不会。malloc 通常只是扩大虚拟地址空间（建立映射区），并不立刻分配物理页。只有当你真正写入某一页时，才触发缺页中断由内核分配物理页框（lazy allocation / demand paging）。所以 top 里 VIRT（虚拟）远大于 RES（实际驻留物理）是正常的。

面试口径：虚拟内存是“承诺”，物理内存是“兑现”，兑现发生在第一次写入触发缺页时。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

看内存别只看占用大小，要分清 VIRT 只是承诺、RES 才是真实物理占用、SHR 是共享页、page cache 看似占满但可回收。AI Infra 排查 OOM 和加载慢，关键是区分进程 RSS、page cache、cgroup limit，以及 major fault 这种要走磁盘 I/O 的缺页信号。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	机制类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：内存管理

AI Infra 的内存问题往往同时涉及虚拟内存、物理内存、page cache、cgroup limit、shared memory、NUMA locality 和 GPU pinned memory。面试回答要能把 Linux 内存机制和训练/推理场景联系起来。

需要掌握

虚拟内存、物理内存、地址空间：进程访问虚拟地址，MMU 通过页表翻译成物理地址。
分页、页表、TLB、缺页中断：页表保存映射，TLB 缓存地址翻译，缺页中断负责按需分配或换入。
mmap：把文件或匿名内存映射到进程虚拟地址空间，访问时按需触发 page fault。
copy-on-write：fork 后父子进程共享物理页，写入时才复制。
堆、栈、内存碎片、内存泄漏：堆用于动态分配，栈用于函数调用，泄漏会让 RSS 持续增长。
malloc/free 基本思路：用户态 allocator 管理空闲块，必要时通过 brk 或 mmap 向内核申请。
page cache 与 buffer cache：Linux 用空闲内存缓存文件内容，提高重复读取性能。
swap：内存压力下把匿名页换出到磁盘，但训练/推理任务触发 swap 通常会导致吞吐断崖式下降。
NUMA：本地内存访问快，远端内存访问延迟高、带宽低。

关键指标

指标	含义	排查意义
VIRT / VMS	虚拟地址空间大小	大不代表真实占用物理内存。
RES / RSS	实际驻留物理内存	判断进程真实内存压力的关键。
SHR	共享页	共享库、mmap 权重、shared memory 都会体现在这里。
Page Cache	文件缓存	看似占满内存，但通常可回收。
Major Fault	需要磁盘 I/O 的缺页	权重加载慢、训练抖动的重要信号。
Minor Fault	不需要磁盘 I/O 的缺页	匿名页分配、COW、已有页重新映射。

AI Infra 相关关注点

大模型训练中的 CPU 内存、GPU 显存、page cache 之间是联动的：CPU 数据准备慢会饿死 GPU，GPU 显存不足会 OOM，page cache 不足会让重复读数据变慢。
mmap 加载大模型权重可以避免一次性读取全文件，支持多进程共享 page cache，但访问时可能触发 page fault，导致启动抖动。
fork DataLoader 时，父进程中已有的大对象初始会 COW 共享；worker 一旦写入对象，物理内存会复制，RSS 可能突然增大。
OOM 定位要区分进程 RSS、VMS、shared memory、page cache、cgroup memory limit、宿主机 OOM 和容器 OOM。
NUMA 绑定不合理会让 CPU worker 访问远端内存，或者跨 socket 给 GPU 准备数据，导致吞吐下降。

Linux OOM 与容器 OOM

宿主机 OOM 是整机内存压力下由内核 OOM killer 选择进程杀掉；容器 OOM 是 cgroup memory limit 被突破，内核在该 cgroup 内杀进程。容器中 page cache、shared memory、DataLoader worker、日志 buffer、主进程 RSS 都可能共同顶满 limit。

高频问题

Q: 虚拟内存解决了什么问题？

虚拟内存提供进程隔离、连续地址空间、按需分配、换页、共享库和 mmap 能力。它让进程看到自己的虚拟地址空间，由 MMU 和页表映射到物理内存。代价是地址翻译需要 TLB/page table，缺页会进入内核，major fault 还会触发磁盘 I/O。

Q: malloc 后一定立刻占用物理内存吗？

不一定。malloc 可能只是分配虚拟地址或复用 allocator 的空闲块，物理页通常在第一次写入时通过缺页中断分配。可以概括为：虚拟内存是承诺，物理内存是触碰页面后兑现。

Q: page cache 为什么会让内存看起来“被占满”？

Linux 会尽量用空闲内存缓存文件页，提升后续读取性能，所以 free 看到的空闲内存可能很少。但 page cache 通常是可回收的，内存压力来时可以释放。排查时要看 available、cache、cgroup limit 和真正不可回收的 RSS。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

Signal 是内核投递给进程的异步事件，最该记住的是优雅退出这条线：SIGTERM 是可捕获的"协商退出"，给应用 flush 日志、保存状态、释放锁的机会；SIGKILL 不可捕获、是强制回收。K8s 删 Pod 就是先 SIGTERM、超过 grace period 再 SIGKILL。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	机制类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

Signal：进程控制的异步通知机制

Signal 是内核投递给进程的异步事件，可用于终止、暂停、恢复、用户中断、非法访问、定时器和子进程状态变化。

常见 Signal

Signal	含义	是否可捕获	典型场景
SIGTERM	请求进程优雅退出	是	K8s 删除 Pod、systemctl stop
SIGKILL	强制杀死	否	grace period 超时
SIGINT	用户中断	是	Ctrl-C
SIGSEGV	非法内存访问	可捕获但通常不恢复	C/C++ 指针错误
SIGCHLD	子进程退出	是	父进程回收子进程

stdin/stdout/stderr

通道	fd	用途	容器/K8s 含义
stdin	0	输入	交互式 exec 或管道输入
stdout	1	正常输出	容器日志采集主通道
stderr	2	错误和 warning	容器日志采集主通道

Q: K8s 删除 Pod 时为什么先 SIGTERM 后 SIGKILL？

先发 SIGTERM 是为了给应用优雅退出机会：停止接新请求、处理完存量请求、flush 日志、保存状态、释放锁。超过 terminationGracePeriodSeconds 仍未退出时，再发不可捕获的 SIGKILL 强制回收资源。

面试口径：SIGTERM 是协商退出，SIGKILL 是强制回收。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

I/O 多路复用让单线程用一次系统调用同时监听海量 fd、只处理就绪的连接，解决「连接多但大部分空闲」时一连接一线程会线程爆炸的问题；epoll 把 fd 注册一次常驻内核、epoll_wait 只返回就绪 fd，在 C10K/C100K 场景远胜每次都全量拷贝+遍历的 select/poll。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	机制类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

为什么需要 I/O 多路复用

核心矛盾：一个服务要同时处理成千上万条连接，但大部分连接在大部分时间是空闲的。如果“一连接一线程”，线程数会爆炸、上下文切换成本高；如果阻塞式单线程，一次只能服务一个连接。I/O 多路复用让单个线程用一次系统调用同时监听大量 fd，只在“就绪”时才去处理，是高并发服务器（Nginx、Redis、各类网关）的基石。

五种 I/O 模型（对比）

模型	阻塞点	特点
阻塞 I/O	read 一直等	最简单，一连接一线程
非阻塞 I/O	轮询返回 EAGAIN	忙等浪费 CPU
I/O 多路复用	阻塞在 select/poll/epoll	一个线程管多个 fd，主流方案
信号驱动 I/O	不阻塞，靠 SIGIO 通知	实际很少用
异步 I/O (AIO)	完全不阻塞，内核完成后通知	Linux io_uring 是现代代表

前四种都属于“同步 I/O”：数据从内核拷到用户态那一步仍由进程自己等。只有 AIO 是真正的异步。

select / poll / epoll 对比

维度	select	poll	epoll
fd 上限	FD_SETSIZE（通常 1024）	无硬上限	无硬上限
数据结构	位图 fd_set	pollfd 数组	内核红黑树 + 就绪链表
每次调用开销	O(n) 拷贝+遍历全部 fd	O(n) 拷贝+遍历全部 fd	O(1) 注册，O(就绪数) 返回
就绪通知	返回后需自己遍历找就绪	同 select	直接返回就绪 fd 列表
触发模式	仅水平触发(LT)	仅水平触发(LT)	支持 LT 和边缘触发(ET)

关键区别：select/poll 每次调用都要把全部 fd 从用户态拷到内核态并线性扫描；epoll 把 fd 注册一次常驻内核红黑树，事件就绪时由回调挂到就绪链表，epoll_wait 只返回就绪的 fd，因此在海量连接、少量活跃的场景下性能远超前两者。

epoll 三个核心系统调用

调用	作用
`epoll_create`	创建 epoll 实例，返回 epfd（内核里建红黑树 + 就绪链表）
`epoll_ctl`	对某个 fd 做 ADD / MOD / DEL，注册关心的事件
`epoll_wait`	阻塞等待，返回已就绪的 fd 列表

水平触发 LT vs 边缘触发 ET

维度	LT（水平触发）	ET（边缘触发）
通知时机	只要缓冲区还有数据就一直通知	仅在状态从无到有变化时通知一次
编程难度	简单，可以只读一部分	必须循环读到 EAGAIN，否则丢事件
性能	可能重复唤醒	唤醒次数少，配非阻塞 fd 用
典型用法	默认、上手快	Nginx 等高性能服务器

ET 必须搭配非阻塞 socket，并在每次事件里把数据一次性读干（直到 EAGAIN），否则剩余数据不会再被通知，连接“假死”。

Reactor 模式与 AI Infra 关联

Reactor 是基于 I/O 多路复用的事件驱动架构：一个事件循环（event loop）用 epoll 监听所有 fd，事件就绪后分发给对应 handler。这是 Netty、Redis、Nginx、各类 RPC 框架的通用骨架。

在 AI Infra 里这套模型同样无处不在：推理服务网关、参数服务器、KV 存储、调度器的 watch 机制，本质都是“少量线程 + epoll 事件循环”处理海量并发连接。理解 epoll 是看懂这些高性能组件的前提。io_uring 则进一步把网络/磁盘 I/O 改成真正的异步提交-完成队列，减少系统调用次数，是新一代高吞吐 I/O 的方向。

Q: epoll 为什么比 select/poll 高效？

三个关键：

避免重复拷贝

select/poll 每次调用都要把全部 fd 集合从用户态拷到内核态；epoll 用 epoll_ctl 注册一次，fd 常驻内核红黑树。

避免全量遍历

select/poll 返回后要 O(n) 扫描所有 fd 找就绪的；epoll 用回调把就绪 fd 挂到就绪链表，epoll_wait 直接返回就绪列表，复杂度只和活跃连接数相关。

支持 ET

边缘触发能减少无效唤醒。

面试口径：在“连接多、活跃少”的 C10K/C100K 场景下，epoll 的优势最明显；连接很少且都活跃时三者差距不大。

Q: epoll 一定比 select 快吗？

不一定。epoll 的优势来自“海量 fd 中只有少量活跃”。如果监听的 fd 很少（比如几十个），或者几乎所有 fd 每次都活跃，epoll 的红黑树维护和回调开销反而不一定占便宜，此时 select/poll 足够。选型要看连接规模和活跃比例。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

一次 read 的路径是：进入内核查 fd 和 page cache，命中就拷给用户 buffer，未命中就发起磁盘或网络存储 I/O 读入 cache 再拷贝。AI Infra 里这条路径决定训练数据加载、checkpoint 和权重加载吞吐，排障要拆到系统调用、page cache miss、磁盘/网络存储延迟、小文件 metadata 和解码这几层。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	机制类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：文件系统与 I/O

文件系统与 I/O 直接影响训练数据加载、checkpoint 保存、模型权重加载和推理服务吞吐。面试中要能从文件抽象讲到内核路径，再落到性能瓶颈定位。

需要掌握

inode、目录项、文件描述符：inode 保存文件元数据和数据块位置，目录项把文件名映射到 inode，fd 是进程打开文件后的句柄。
buffered I/O：read/write 经过 page cache，适合复用和小块读取。
direct I/O：绕过 page cache，适合应用自管缓存的大文件顺序读写，但要求 buffer、offset、size 对齐。
sync/async I/O：同步 I/O 调用方等待完成，异步 I/O 提交请求后由完成事件通知。
read/write、pread/pwrite、mmap：pread/pwrite 带 offset 且不改变文件偏移，适合多线程并发读写。
dirty page 与 fsync：写入先进入 page cache 形成脏页，fsync 强制落盘，可能很慢。
顺序读写与随机读写：顺序访问利用预读和连续带宽，随机访问受寻址、队列深度和 metadata 影响。
SSD/NVMe：延迟低、并发队列强，但小 I/O、同步刷盘、文件碎片仍可能成为瓶颈。
I/O 多路复用：select、poll、epoll 让少量线程管理大量 fd。
零拷贝：sendfile、splice、DMA、mmap 等减少用户态/内核态拷贝和上下文切换。

一次 read 的典型路径

应用调用 read 进入内核；内核检查 fd、文件偏移和 page cache；如果命中，把 page cache 内容拷贝到用户 buffer；如果未命中，提交磁盘或网络存储 I/O，把数据读入 page cache，再拷贝给用户。这个路径可能慢在系统调用、page cache miss、磁盘 I/O、metadata、CPU copy、网络存储或文件格式解码。

AI Infra 相关关注点

训练数据读取瓶颈要拆成：磁盘/对象存储带宽、网络存储延迟、文件数量和 metadata、解码、数据增强、CPU worker、batch queue 深度。
小文件过多会导致 open/stat/readdir metadata 开销高，即使总数据量不大也会拖慢 DataLoader。
checkpoint 保存慢可能来自序列化、CPU 到磁盘写入、网络文件系统、fsync、单文件过大、并发写冲突。
模型权重加载时，mmap、顺序读、预读、page cache 预热、并行 shard 加载都会影响启动时间。
推理服务要把网络 I/O、请求解析、排队、batching、GPU 执行和响应写回解耦。
高吞吐服务常用 epoll/事件循环/异步 I/O/零拷贝降低线程数和拷贝成本。

训练时 GPU 利用率低，I/O 层怎么排查

看 GPU 利用率是否周期性掉到 0，如果是，常见原因是 batch feeding 不连续。
看 DataLoader worker CPU 是否打满，队列是否为空，是否被图像解码或数据增强拖慢。
用 iostat 看磁盘 util、await、吞吐；用网络监控看远端存储带宽和延迟。
看文件数量和单文件大小，小文件多时优先考虑打包格式或顺序读。
看 page cache 命中和 major fault，判断是否频繁从磁盘或网络存储重新取数据。

高频问题

Q: 文件描述符和 inode 的关系是什么？

inode 是文件系统中的文件元数据对象，文件名通过目录项映射到 inode。进程 open 文件后得到 fd，fd 指向内核 open file description，其中包含文件偏移和打开模式。多个 fd 可以指向同一个 inode，也可以共享或不共享文件偏移。

Q: epoll 相比 select/poll 的优势是什么？

select/poll 每次都要传入 fd 集合并线性扫描，epoll 把关注的 fd 注册到内核对象里，就绪事件通过 ready list 返回，避免每次全量扫描，更适合大量连接但少量活跃的高并发服务。

Q: fsync 为什么可能很慢？

write 返回通常只表示数据进入 page cache，不代表落盘。fsync 要等待脏页写回、文件系统 journal、设备 flush、网络存储确认和其他 I/O 排队。checkpoint 或日志频繁 fsync 会显著影响吞吐和延迟。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

CPU 调度回答的是"下一个时间片给谁"。FIFO/SJF/RR/优先级/CFS 这套单机算法，会原样迁移到 K8s、HPC 和 AI 集群里：SJF 对应短任务优先，RR 对应租户轮转，优先级对应抢占，CFS 对应公平份额。记住 CFS 靠 vruntime 选"最没跑够"的任务，目标是公平和响应而非吞吐。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	概念类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

CPU 调度算法：从单机 OS 到集群调度的共同语言

CPU 调度回答“下一个时间片给谁”。这些算法也会迁移到 K8s、HPC 和 AI 集群里：FIFO 对应队列顺序，SJF 对应短任务优先，RR 对应租户轮转，优先级对应抢占，CFS 对应公平份额。

常见调度算法对比

算法	规则	是否抢占	优点	缺点	AI Infra 类比
FIFO / FCFS	先到先服务	通常非抢占	简单、按到达顺序公平	队头阻塞	训练队列按提交时间排队
SJF	运行时间短的先跑	通常非抢占	降低平均等待时间	需要预测，长任务可能饥饿	短实验优先、预测驱动调度
SRTF	剩余时间最短优先	抢占式	动态到达下等待时间更低	抢占成本高	checkpoint-aware preemption
Round Robin	按时间片轮转	抢占式	响应性好，避免独占	时间片难选，切换开销	队列/租户轮转
优先级调度	高优先级先运行	可抢占或非抢占	表达业务重要性	低优任务可能饥饿	PriorityClass、队列优先级
CFS	按虚拟运行时间公平分配 CPU	抢占式	兼顾公平和交互响应	不是硬实时	公平份额、quota、dominant share

抢占式调度 vs 非抢占式调度

维度	抢占式	非抢占式
定义	调度器可以打断正在运行的任务	任务主动阻塞、退出或让出 CPU 才切换
响应性	高，适合交互和高优任务	低，可能被长任务卡住
开销	上下文切换更频繁	切换少，实现简单
集群类比	抢占低优训练任务，可能回滚 checkpoint	不抢占更稳定，但高优任务等待更久

CFS 深挖：vruntime、权重和 runqueue

CFS（Completely Fair Scheduler）的核心思想是：不要只按固定时间片轮转，而是持续维护每个 runnable task 已经获得的“公平份额”。它用 vruntime 表示加权后的虚拟运行时间，倾向于选择 vruntime 最小的任务运行。

概念	含义	面试解释
`vruntime`	加权虚拟运行时间	越小表示相对越“没跑够”，越应该获得 CPU
nice / weight	优先级权重	权重越高，同样真实运行时间带来的 `vruntime` 增长越慢
runqueue	可运行任务队列	每个 CPU 有自己的可运行任务集合，CFS 按 `vruntime` 组织任务
抢占	打断当前任务	新唤醒任务或更小 `vruntime` 任务可能触发重新调度
上下文切换	保存/恢复执行状态	线程过多、频繁阻塞唤醒会让 CPU 时间浪费在切换上

CFS 的目标是公平和响应性，而不是让某一个任务吞吐最大。这个点和 GPU 的 warp/block 调度形成鲜明对比：GPU kernel 内部通常不追求每个 CUDA thread 的公平时间片，而是追求 SM 吞吐、occupancy 和隐藏内存延迟。

和 CUDA 调度的层次区别

Linux CFS 调度的是 OS task；CUDA Stream/Event 管的是 GPU 任务队列和依赖；CUDA block/warp 调度管的是 kernel 内部如何映射到 SM。这三层经常被混淆。

CFS

进程/线程共享 CPU 时间，强调公平和响应性

Stream/Event

组织 H2D、kernel、D2H 的异步顺序和依赖

Block → SM

GPU 把 grid 里的 block 分配到 SM 执行

Warp Scheduler

SM 选择 ready warp 发射指令，隐藏访存延迟

Q: 为什么 SJF 可以降低平均等待时间？有什么问题？

直觉：短任务放前面，只会让长任务多等一个短任务时间；长任务放前面，会让所有短任务都等一个长任务时间。因此短任务优先能降低平均等待。

问题

SJF 需要知道或预测运行时间，并且会让长任务饥饿。工程上通常用 aging、配额保障或最大等待时间兜底。

面试口径：说最优性时必须补前提和饥饿问题。

Q: Linux CFS 和 CUDA thread block 调度有什么区别？

CFS 是 CPU 上的操作系统调度器，调度对象是进程或线程，目标是公平性、响应性和 CPU 时间共享；CUDA thread block 调度是 GPU kernel 内部的硬件执行机制，调度对象是 grid 中的 block/CTA，目标是把 block 分配到 SM、让 warp scheduler 用 ready warp 隐藏访存延迟。CFS 通过 vruntime、权重、抢占和上下文切换决定哪个 task 运行；CUDA block 一旦驻留 SM 通常运行到完成，SM 内部以 warp 为单位发射指令，更强调吞吐而不是公平时间片。

一句话：CFS 管 OS task 的公平 CPU 时间，CUDA block/warp 调度管 kernel 内部的高吞吐并行执行。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

load average 高不等于 CPU 忙，因为 load 同时统计 runnable 和 D 状态不可中断睡眠任务，大量任务卡在磁盘或网络 I/O 也会推高 load。判断 CPU 瓶颈要同时看 load、utilization、run queue、iowait 和 context switch。AI Infra 里数据预处理、tokenizer、序列化和容器 CFS throttling 都可能让 CPU 成瓶颈、拖垮 GPU 喂数据。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	排障诊断类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：CPU 调度与性能分析

AI Infra 里 CPU 不是“辅助资源”。数据预处理、tokenizer、detokenizer、请求调度、网络协议栈、NCCL 辅助线程、checkpoint 序列化都可能让 CPU 成为瓶颈。

需要掌握

进程调度基本原理：内核从 runnable 队列中选择下一个任务运行。
时间片、优先级、抢占、上下文切换：调度器在公平性、响应时间和吞吐之间取舍。
CPU load average 与 CPU utilization：load 包含 runnable 和不可中断睡眠任务；utilization 表示 CPU 实际忙碌比例。
user、system、iowait、steal：分别代表用户态执行、内核态执行、等待 I/O、虚拟化环境被宿主抢占。
cache locality、CPU cache、false sharing：线程迁移和共享 cache line 会影响吞吐。
软中断、硬中断：硬中断来自设备，软中断常用于网络包处理等延后工作。
perf、top、htop、pidstat、vmstat、sar 等工具的基本使用。

AI Infra 相关关注点

GPU 训练时 CPU 数据准备不足会让 GPU 空转。
高 QPS 推理服务中，CPU 前处理、tokenizer、JSON 序列化、日志和网络协议栈可能成为瓶颈。
多线程服务中锁竞争、上下文切换过高、cache miss 过高会导致吞吐下降和 p99 抖动。
容器环境下 CPU quota、cpuset、CFS throttling 会让服务“看起来还有 CPU”，但实际被限流。

load high 不等于 CPU busy

Linux load average 会统计 runnable 任务和 D 状态不可中断睡眠任务。大量任务卡在磁盘或网络 I/O，也会推高 load，但 CPU utilization 可能不高。因此判断 CPU 瓶颈要同时看 load、utilization、run queue、iowait、context switch 和线程栈。

高频问题

Q: load average 高是否一定说明 CPU 忙？

不一定。load 包含 runnable 和不可中断睡眠任务。I/O 卡住、网络存储慢、D 状态进程多都可能让 load 很高。要结合 CPU utilization、iowait、run queue 和 D 状态进程判断。

Q: iowait 高说明什么？

iowait 表示 CPU 空闲但系统中有任务在等 I/O。它提示 I/O 可能拖慢任务，但还要结合 iostat 的 await、util、吞吐和应用访问模式判断。训练中 iowait 高常见于数据集读取、checkpoint 或网络存储。

Q: 如何用 perf 分析 CPU hotspot？

先用 perf top -p <pid> 在线看热点，再用 perf record -g -p <pid> -- sleep 30 采样调用栈，最后用 perf report 或火焰图分析热点是在业务函数、系统调用、锁、内核网络栈、内存拷贝还是调度函数。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

网络基础要能从 socket API 讲到 TCP 状态机，再落到连接池、超时、反压和 RDMA/NCCL 为什么存在。三次握手确认双方收发能力和初始序列号，TIME_WAIT 保证可靠关闭。AI Infra 里分布式训练通信慢要分应用、GPU 拓扑、网络和系统四层排查；RDMA/InfiniBand/NCCL 的存在就是为了绕过传统 TCP/IP 的内核协议栈、CPU copy 和延迟瓶颈。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	概念类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：网络基础与系统调用

网络基础连接分布式训练、推理服务、RPC、存储访问和控制面组件。面试回答要能从 socket API 讲到 TCP 状态，再扩展到连接池、超时、重试、反压和 RDMA/NCCL 为什么存在。

需要掌握

TCP/IP 基础：三次握手、四次挥手、拥塞控制、流量控制。
socket 编程流程：socket、bind、listen、accept、connect、read/write、close。
listen backlog、SYN queue、accept queue：半连接和全连接队列过小会导致连接失败或延迟升高。
TIME_WAIT、CLOSE_WAIT：TIME_WAIT 用于可靠关闭和旧报文消散；CLOSE_WAIT 常说明应用未 close。
TCP keepalive、Nagle、reuseaddr/reuseport：分别影响连接保活、小包聚合和端口复用。
网络收发包路径：网卡、DMA、硬中断/软中断、协议栈、socket buffer、用户态。
epoll 在网络服务中的使用。

AI Infra 相关关注点

分布式训练通信瓶颈可能来自带宽、延迟、拥塞、丢包、网卡队列、PCIe/NUMA 拓扑、NCCL 算法选择。
RDMA、InfiniBand、RoCE、NCCL 解决的是传统 TCP/IP 在内核协议栈、CPU copy、延迟和吞吐上的瓶颈。
推理服务要关注连接数、长连接、连接池、超时、重试、限流和熔断。
大模型服务中的流式输出需要处理慢客户端、发送缓冲区、反压和请求取消。

高频问题

Q: TCP 三次握手和四次挥手过程是什么？

三次握手是客户端 SYN、服务端 SYN+ACK、客户端 ACK，用于确认双方收发能力和初始序列号。四次挥手是主动关闭方 FIN、被动方 ACK，被动方处理完剩余数据后 FIN，主动方 ACK 并进入 TIME_WAIT。

Q: TIME_WAIT 为什么存在？过多怎么办？

TIME_WAIT 用于确保最后一个 ACK 能被对端收到，并让旧连接残留报文自然消失。过多时先判断是否短连接过多，可通过连接池、长连接、HTTP keepalive、端口范围调整和合理复用缓解，不能简单粗暴关闭安全机制。

Q: epoll 的 LT 和 ET 模式有什么区别？

LT 是水平触发，只要 fd 仍然可读/可写就会反复通知；ET 是边缘触发，只在状态变化时通知，要求非阻塞 fd 并一次读到 EAGAIN，否则可能遗漏事件。ET 通知少但编程要求更高。

Q: 分布式训练通信慢，可能从哪些层面排查？

从应用看 batch、梯度大小、通信算法、NCCL 日志；从 GPU 拓扑看 NVLink/PCIe、跨 NUMA、GPU affinity；从网络看带宽、丢包、拥塞、RoCE PFC/ECN、网卡错误；从系统看 CPU 辅助线程、软中断、IRQ 亲和和容器资源限制。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

namespace 管"看见什么"（PID、网络栈、挂载点、IPC），cgroup 管"能用多少"（CPU、内存、I/O、设备），容器隔离就是 namespace + cgroup + rootfs + capability/seccomp 组合出来的。AI Infra 几乎都跑在容器和 K8s 上，所以要能把 OS 知识映射到容器 OOM（exit 137）、CFS throttling、cgroup memory limit 和 /dev/shm 不足这些实际故障。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	机制类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：容器、cgroup 与 Linux 隔离机制

AI Infra 基本运行在容器和 Kubernetes 之上，因此操作系统知识必须能映射到 namespace、cgroup、device plugin、资源限制和容器内外观测差异。

需要掌握

namespace：pid、net、mnt、uts、ipc、user，负责隔离“看到什么”。
cgroup：CPU、memory、blkio/io、device、pids，负责限制和统计“能用多少”。
容器与虚拟机：容器共享宿主机内核，虚拟机有独立 guest kernel。
Docker 镜像层与 overlayfs：镜像是只读层叠加，可写层记录容器修改。
容器内看到的资源与宿主机资源关系：工具显示可能来自宿主机视角，但实际受 cgroup 限制。
OOM、CPU throttling、文件描述符限制在容器中的表现。

AI Infra 相关关注点

Kubernetes 训练任务的 CPU、内存、GPU 资源隔离由 request/limit、cgroup、device plugin 和调度器共同实现。
容器 OOM 与宿主机 OOM 不同：容器达到 memory limit 会在 cgroup 内 kill。
cgroup memory limit 会影响匿名内存、page cache、shared memory，可能出现 page cache 把容器 limit 顶满。
多卡训练容器通过 NVIDIA device plugin 暴露 GPU device、驱动库和 CUDA_VISIBLE_DEVICES。
/dev/shm 太小会导致 PyTorch DataLoader、共享内存队列或分布式训练异常。

namespace 和 cgroup 的区别

namespace 解决“看见什么”：PID、网络栈、挂载点、主机名、IPC 对象。cgroup 解决“能用多少”：CPU、内存、I/O、进程数和设备。容器隔离通常是 namespace + cgroup + rootfs + capability/seccomp 组合出来的。

高频问题

Q: Docker 容器是如何实现隔离的？

Docker 主要利用 Linux namespace 隔离进程视图、网络、挂载、IPC、用户等；利用 cgroup 限制和统计 CPU、内存、I/O、设备等资源；利用 overlayfs 提供镜像层和可写层；再配合 capability、seccomp、AppArmor/SELinux 限制权限和系统调用。

Q: 容器内进程被 OOM kill，如何排查？

先看 Pod 状态、exit code 137、events；再看 cgroup memory.current/memory.max、容器日志和 dmesg；区分主进程 RSS、DataLoader worker、/dev/shm、page cache、shared memory、内存泄漏和 batch size 是否异常。

Q: /dev/shm 不足会导致什么问题？

/dev/shm 是 tmpfs 共享内存。PyTorch DataLoader 多进程、共享内存队列、Ray、某些分布式通信都可能依赖它。空间不足会出现 bus error、worker 异常退出、进程 hang 或吞吐下降。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

GPU 利用率低不能只看一个数：要分层判断到底卡在哪。先看 SM utilization 判断计算单元是否真在工作（显存高只代表被占不代表在算），再看 PCIe/NVLink 吞吐排查 H2D/D2H 或通信瓶颈，再看 CPU worker 和 DataLoader queue 是否供给不足，最后看 NCCL 日志和网络指标。这正是区分 AI Infra 候选人和普通后端的关键。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	概念类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：GPU 训练/推理相关系统层知识

这部分是区分普通后端候选人和 AI Infra 候选人的关键。面试官通常关心你是否理解 CPU、内存、PCIe、GPU、驱动和 CUDA runtime 之间的数据路径，以及系统瓶颈如何影响 GPU 利用率。

需要掌握

CPU、内存、PCIe、GPU 之间的数据路径：数据通常从磁盘/网络进入 CPU 内存，再通过 PCIe/NVLink 进入 GPU HBM。
DMA：设备绕过 CPU 指令拷贝，直接在设备和内存之间传输数据。
pinned memory/page-locked memory：锁定物理页，避免换页，使 DMA 可以稳定访问。
CPU 到 GPU 数据拷贝瓶颈：可能来自 CPU 解码、内存带宽、PCIe 带宽、pageable memory staging、NUMA 跨 socket。
NUMA、PCIe topology、GPU affinity：GPU 挂在哪个 CPU socket/PCIe switch 下会影响数据路径。
GPU 进程、驱动、CUDA runtime：应用通过 CUDA runtime/driver 提交 kernel、内存分配和拷贝。
多进程使用 GPU 的资源竞争：显存、SM、显存带宽、copy engine、上下文和 MPS/MIG 隔离。

AI Infra 相关关注点

DataLoader 中 pin_memory=True 可以把 batch 放入 pinned memory，使 H2D 拷贝更高效，尤其配合 non_blocking copy 和 CUDA stream。
GPU 利用率低要判断是计算、通信、I/O、CPU 预处理、H2D 拷贝还是调度排队瓶颈。
多卡训练中 PCIe/NVLink 拓扑决定 GPU 间通信路径，跨 NUMA 或跨 PCIe switch 可能降低 all-reduce 性能。
推理服务中 batch、队列、CPU 前处理、GPU 执行、后处理、网络写回需要流水线化。

GPU 利用率低的分层判断

看 SM utilization / GPU-Util：低说明计算单元没持续工作。
看显存占用：高只代表资源被占，不代表计算忙。
看 PCIe/NVLink 吞吐：高可能是 H2D/D2H 或通信瓶颈。
看 CPU worker 和 DataLoader queue：CPU 供给不足会导致 GPU 等 batch。
看 NCCL 日志和网络指标：分布式训练可能卡在通信。

高频问题

Q: pinned memory 为什么能提升 H2D 拷贝性能？

普通 pageable memory 可能被 OS 换页，GPU DMA 不能直接安全访问，驱动通常需要先拷到 pinned staging buffer 再 DMA 到 GPU。pinned memory 锁定物理页，避免换页，使 DMA 可以直接传输，减少额外拷贝并支持异步 H2D。

Q: GPU 利用率低但显存占用高，可能是什么原因？

显存高可能只是模型权重、optimizer state、KV cache 或缓存 allocator 常驻，并不代表 GPU 正在计算。利用率低可能是 DataLoader 慢、CPU 前处理慢、H2D 拷贝没重叠、网络通信等待、batch 太小、请求不足或 kernel launch 间隙大。

Q: 多卡训练通信慢，可能和拓扑有什么关系？

GPU 之间可能通过 NVLink、NVSwitch、同一 PCIe switch、跨 PCIe root complex 或跨 NUMA socket 通信，路径不同带宽和延迟差异很大。rank 放置不匹配拓扑时，all-reduce 可能跨慢链路；NIC 和 GPU 不在同一 locality 时，RDMA/GPUDirect 效果也会变差。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

排障要体现分层思维：先界定现象（影响范围、开始时间、是否稳定复现、是 p99 还是吞吐还是 GPU 利用率变坏），再按链路分层拆（应用队列、CPU、内存、I/O、网络、GPU、容器限制、下游依赖），用指标和工具逐层验证假设，最后给优化方案。指标发现异常、日志解释语义、trace 串联请求链路，这套方法对 GPU 空转、p99 抖动、OOM 都通用。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	排障诊断类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

AI Infra 面试模块：系统可观测性与故障排查

AI Infra 面试经常问“线上问题怎么定位”。回答这类问题要体现分层思维：先界定现象，再看资源指标，再抓进程、系统调用、日志和 trace，最后形成假设并验证。

需要掌握

常用系统指标：CPU、内存、磁盘、网络、FD、线程数、上下文切换、系统调用耗时。
常用命令：top、htop、ps、free、vmstat、iostat、pidstat、sar、ss、lsof、strace、perf、dmesg。
日志、指标、trace 的定位思路：指标发现异常，日志解释语义，trace 串联请求链路。
系统调用耗时分析：strace 可以看到进程卡在 futex、read、write、poll、connect、fsync 等调用上。
core dump、gdb 基础：进程崩溃或卡死时查看调用栈、线程状态和锁等待。

AI Infra 相关关注点

训练任务卡住：看 GPU、CPU、DataLoader、NCCL 日志、网络、磁盘和进程栈。
吞吐下降：看 batch 时间拆分、CPU feeding、H2D、GPU compute、通信、checkpoint 和日志写入。
GPU 空转：看 DataLoader queue、CPU worker、I/O、网络存储、tokenizer、请求流量。
OOM：区分 CPU OOM、GPU OOM、容器 OOM、/dev/shm 不足和 allocator fragmentation。
checkpoint 慢：看序列化、磁盘吞吐、网络存储、fsync、并发写和 dirty page writeback。
推理 p99 抖动：拆成排队、batching、CPU 前后处理、GPU 执行、网络、锁竞争、GC、下游依赖。

训练任务 GPU 利用率突然下降如何排查

先确认影响范围：单卡、单机、多机，还是所有卡同时下降。
看 GPU 指标：SM utilization、显存、PCIe/NVLink、power、temperature、ECC。
看 CPU 和 DataLoader：worker 是否打满，队列是否为空，上下文切换是否高。
看 I/O：iostat、网络存储、数据集小文件、page fault、解码耗时。
看通信：NCCL 日志、网络丢包/拥塞、rank 是否 hang。
看应用日志和 trace：是否 checkpoint、eval、日志上报、数据增强异常。

高频问题

Q: 推理服务 p99 latency 突然升高，你如何定位？

先按请求链路拆分：入口排队、网络、鉴权/路由、tokenize、batch scheduler、GPU prefill/decode、detokenize、响应写回。再看资源：CPU、GPU、显存、队列长度、batch size、KV cache、网络连接、锁等待和 GC。最后用 trace 对比 p50/p99 请求，定位是哪一段变长。

Q: 进程卡住没有日志，如何分析？

先用 ps/top 看进程状态，是 R、S、D 还是 zombie；用 strace -p 看是否卡在 futex、read、poll、connect、fsync；用 pstack/gdb 看线程栈；用 lsof/ss 看 fd 和网络连接；用 dmesg 看 OOM、磁盘、驱动错误。

Q: 如何判断是 CPU 瓶颈、I/O 瓶颈还是网络瓶颈？

CPU 瓶颈通常表现为 CPU util 高、run queue 长、perf 热点明显；I/O 瓶颈表现为 iowait、磁盘 await/util 高、read/write 慢、major fault 多；网络瓶颈表现为吞吐接近上限、丢包/重传、RTT 增大、socket buffer 堆积。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

这页是 OS 模块的收束：准备分三层——概念准确（每个机制能说清解决什么问题、原理、性能代价、在训练/推理里怎么体现）、能结合场景分析（GPU 利用率低、DataLoader 慢、OOM、p99 抖动、通信慢怎么排查）、熟悉 top/iostat/perf/nvidia-smi 等工具链。系统排查题用固定模板回答：先界定现象，再分层拆链路，用指标验证假设，最后给优化方案。

复习定位

维度	内容
所属模块	操作系统基础
章节类型	面试收束类
解决问题	围绕进程线程、调度、虚拟内存、IO、多路复用、死锁、观测和 AI Infra OS 问题建立系统基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

准备方式与最小复习清单

这一页用于最后收束：怎样从概念走到场景分析，面试前最小需要覆盖哪些问题，以及常用工具链。

第一层：概念准确

每个模块至少能解释：这个机制解决什么问题；核心原理是什么；有什么性能代价；它在 AI 训练或推理场景中如何体现。

第二层：能结合场景分析

GPU 利用率低如何排查。
DataLoader 很慢如何优化。
训练任务 OOM 如何定位。
推理服务 p99 延迟升高如何分析。
分布式训练通信慢如何定位。
checkpoint 保存很慢如何优化。
容器内任务被 OOM kill 如何排查。

第三层：熟悉工具链

top / htop
ps
free
vmstat
iostat
pidstat
sar
ss
lsof
strace
perf
dmesg
nvidia-smi

如果面试偏 Infra 或性能优化，建议进一步了解：

numactl
numastat
ethtool
tcpdump
bcc / bpftrace
nsenter
cgget / systemd-cgtop

最小复习清单

进程、线程、协程的区别。
线程同步、死锁、锁竞争。
虚拟内存、分页、缺页中断、TLB。
mmap、page cache、copy-on-write。
Linux OOM 与容器 OOM。
read/write、mmap、direct I/O 的区别。
epoll 原理与使用场景。
CPU load、utilization、iowait、context switch 的含义。
TCP 三次握手、四次挥手、TIME_WAIT。
namespace、cgroup、容器资源限制。
pinned memory、NUMA、PCIe topology 对训练性能的影响。
GPU 利用率低、服务延迟高、训练 OOM 的排查路径。

系统排查题回答模板

先界定现象：影响范围、开始时间、是否稳定复现、p50/p99/吞吐/GPU 利用率哪个变坏。
再分层拆链路：应用队列、CPU、内存、I/O、网络、GPU、容器限制、下游依赖。
用指标验证假设：用 top、pidstat、iostat、ss、strace、perf、nvidia-smi、日志和 trace 逐层收敛。
最后给优化方案：调参数、改并发模型、减少拷贝、增加缓存、调整 NUMA/绑核、优化 I/O 格式、扩容或限流。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

内容模块

计算机组成原理

基础★☆☆⏱ 18 min

一句话结论

CPU 性能不只看核数，更取决于数据离 CPU 有多近：寄存器、L1/L2/L3、本地 DRAM、远端 NUMA 内存的延迟逐级放大，越往下带宽越低，所以很多“CPU 跑满但吞吐上不去”的问题本质是访存而非算力。

复习定位

维度	内容
所属模块	计算机组成基础
章节类型	机制类
解决问题	围绕 CPU、缓存、TLB、DMA、PCIe、NUMA 等 AI Infra 底层系统知识建立基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

CPU 与内存层次

程序性能不仅取决于 CPU core 数，还取决于数据是否在寄存器、L1/L2/L3 cache、内存还是远端 NUMA 内存中。越靠近 CPU，容量越小、延迟越低、带宽越高。

层次结构

层次	特点	性能影响
寄存器	CPU 内部，最快	编译器优化和指令级并行
L1/L2 Cache	每 core 或小范围共享	热数据命中时极快
L3 Cache	多 core 共享	跨线程共享数据常经过 L3
DRAM	容量大但延迟高	内存带宽瓶颈常见
远端 NUMA 内存	跨 socket 访问	延迟更高，带宽更低

Q: 为什么线程数增加后吞吐可能下降？

线程数增加会带来上下文切换、锁竞争、cache line 抖动、内存带宽竞争和 NUMA 远端访问。CPU core 变忙不代表有效吞吐提升。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

Cache 和 TLB 都是用「空间换时间」缓解访存慢的硬件：Cache 缓存数据、TLB 缓存地址翻译，两者命中率都依赖程序的访问局部性，所以高性能代码的本质是写出对 cache 和 TLB 友好的内存访问模式。

复习定位

维度	内容
所属模块	计算机组成基础
章节类型	概念类
解决问题	围绕 CPU、缓存、TLB、DMA、PCIe、NUMA 等 AI Infra 底层系统知识建立基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

Cache、TLB 和局部性

Cache 利用时间局部性和空间局部性减少内存访问；TLB 缓存虚拟地址到物理地址的页表翻译结果。Cache miss 和 TLB miss 都会显著拖慢程序。

False Sharing

多个线程修改不同变量，但这些变量落在同一 cache line 上，会导致 cache coherence 协议反复让 cache line 在 core 之间迁移。现象是 CPU 利用率高但吞吐低。

解决：padding、alignas、按线程分片计数、减少共享写。

面试排查入口

问题	现象	工具
Cache miss 高	CPU 等内存	`perf stat`、PMU
TLB miss 高	随机访问大内存慢	`perf stat`、hugepage
False sharing	多线程扩展性差	`perf c2c`、benchmark 对比

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

DMA、PCIe 和 NUMA 共同决定了数据在 CPU、GPU、NIC、NVMe 之间「怎么走、走多快」：DMA 让设备绕过 CPU 搬数据，PCIe 是设备互联的带宽上限，NUMA 决定设备和内存的亲和距离——AI Infra 里大量性能问题不是 GPU 不够快，而是数据到 GPU 的路径太差。

复习定位

维度	内容
所属模块	计算机组成基础
章节类型	机制类
解决问题	围绕 CPU、缓存、TLB、DMA、PCIe、NUMA 等 AI Infra 底层系统知识建立基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

DMA、PCIe 与 NUMA 拓扑

DMA 允许设备绕过 CPU 直接读写内存；PCIe 是 CPU、GPU、NIC、NVMe 等设备的主要互联；NUMA 决定 CPU、内存、GPU、NIC 之间的亲和关系。

AI Infra 为什么关心这些

概念	影响	典型场景
DMA	降低 CPU copy 开销	GPU copy、RDMA、NVMe 数据加载
PCIe	限制 host-device 带宽	CPU 到 GPU 数据搬运
NUMA locality	影响 CPU-GPU/NIC 距离	数据加载线程应靠近目标 GPU/NIC
GPU-NIC affinity	影响 RDMA/NCCL 性能	跨节点 AllReduce

设备路径怎么读

在一台多 Socket 服务器里，GPU、NIC、NVMe 通常挂在不同 PCIe switch 或 root complex 下。路径越短、越少跨 Socket，延迟越低、带宽越稳定。AI Infra 里常见的性能问题不是“GPU 不够快”，而是数据从 CPU、NIC 或另一张 GPU 到目标 GPU 的路径太差。

同 PCIe switch

GPU-GPU P2P 或 GPU-NIC 路径较短

同 Socket / 同 NUMA

CPU 线程、内存页、GPU、NIC 亲和性较好

跨 Socket

经过 CPU interconnect，延迟和抖动上升

Host staging

P2P/GDR 不可用时经 CPU pinned memory 中转，代价最高

Q: 为什么 GPU 训练要看 nvidia-smi topo -m？

它能显示 GPU-GPU、GPU-NIC、GPU-CPU 的拓扑关系。张量并行、NCCL、RDMA 和数据加载都受拓扑影响；同样 8 张 GPU，NVLink 内互联和跨 PCIe/跨节点性能差异很大。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

内容模块

计算机网络基础

基础★☆☆⏱ 20 min

一句话结论

TCP 不是「天生可靠」，而是用序列号+ACK+重传、滑动窗口（流控，接收方主导）、拥塞控制（cwnd，发送方主导）尽力提供可靠有序的字节流；它的代价是连接管理（三次握手/四次挥手/TIME_WAIT）和队头阻塞——后者正是 HTTP/3 改用 QUIC over UDP 想根治的问题。UDP 则用无连接、不保证可靠换低开销。

复习定位

维度	内容
所属模块	网络基础
章节类型	概念类
解决问题	围绕 TCP/UDP、HTTP/gRPC/RPC、RDMA 和 GPUDirect 建立 AI Infra 网络答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

TCP 与 UDP 的核心区别

维度	TCP	UDP
连接	面向连接	无连接
可靠性	重传、有序、流控、拥塞控制	不保证可靠和有序
延迟/开销	开销更高	开销更低
场景	HTTP/gRPC、数据库、可靠 RPC	DNS、实时音视频、QUIC 底层

面试重点

TCP 不是“永远可靠”，而是通过确认、重传、窗口、拥塞控制尽力提供可靠字节流。真实系统还要处理超时、半开连接、队头阻塞、连接池和重试风暴。

三次握手：建立连接

三次握手的本质是双方各确认一次对方的收发能力，并同步初始序列号（ISN）。少一次就无法保证双向通道都可用。

SYN

客户端发 SYN，seq=x，进入 SYN_SENT

SYN+ACK

服务端回 SYN+ACK，seq=y, ack=x+1，进入 SYN_RCVD

ACK

客户端回 ACK，ack=y+1，双方进入 ESTABLISHED

为什么不是两次：两次握手无法确认客户端的接收能力，且历史失效的 SYN 重复到达会导致服务端建立无效连接。

四次挥手与 TIME_WAIT

关闭连接需要四次，是因为 TCP 全双工，每个方向都要单独关闭：一方 FIN 只表示“我没有数据要发了”，但对端可能还有数据，所以 ACK 和对端 FIN 通常不能合并。

FIN

主动方发 FIN，进入 FIN_WAIT_1

ACK

被动方回 ACK，主动方进入 FIN_WAIT_2

FIN

被动方数据发完后发 FIN，进入 LAST_ACK

ACK

主动方回 ACK，进入 TIME_WAIT（2MSL）后关闭

TIME_WAIT 为什么存在 / 为什么有时危险

主动关闭方停留在 TIME_WAIT（默认 2MSL）有两个目的：① 保证最后一个 ACK 能可靠到达（丢了可重发）；② 让本连接的旧报文在网络中自然消亡，避免污染新连接。

风险：短连接高并发场景（如压测、未用连接池的 RPC 客户端）会堆积大量 TIME_WAIT，耗尽本地端口。工程上优先用长连接/连接池，而不是无脑开 tcp_tw_reuse。

可靠性与流量/拥塞控制

机制	解决什么	关键点
序列号 + ACK + 重传	丢包、乱序	超时重传 RTO、快速重传（3 个重复 ACK）
滑动窗口（流控）	接收方处理不过来	由接收方 rwnd 通告，防止打爆对端缓冲
拥塞控制	网络链路拥塞	由发送方 cwnd 控制，防止打爆网络

经典拥塞控制四阶段：慢启动（cwnd 指数增长）→ 拥塞避免（线性增长）→ 快速重传 → 快速恢复。现代内核默认多用 CUBIC，高带宽长肥管道（数据中心、跨洋）常用 BBR（基于带宽和 RTT 建模，而非纯丢包驱动）。

队头阻塞（HoL Blocking）

层次	队头阻塞原因	缓解
TCP 层	字节流有序交付，一个包丢了后续包都得等重传	无法在 TCP 内根治
HTTP/1.1	一条连接同一时刻只能处理一个请求	多连接、pipelining（受限）
HTTP/2	应用层多路复用，但仍跑在单条 TCP 上，丢包仍触发 TCP HoL	换底层传输
HTTP/3 (QUIC)	基于 UDP，流之间相互独立，单流丢包不阻塞其他流	根治应用层 HoL

HTTP 协议演进

版本	底层	关键改进	遗留问题
HTTP/1.1	TCP	长连接 keep-alive、分块传输	队头阻塞、并发靠多连接
HTTP/2	TCP + TLS	二进制分帧、多路复用、头部压缩(HPACK)、Server Push	TCP 层队头阻塞仍在
HTTP/3	QUIC(UDP) + TLS1.3	无 TCP HoL、0-RTT 连接、连接迁移	UDP 被中间设备限速/拦截

Q: 为什么 TCP 是三次握手、四次挥手？

三次握手：建立连接要双向确认收发能力并同步序列号。客户端 SYN → 服务端 SYN+ACK（一次合并）→ 客户端 ACK，共三次。两次无法确认客户端接收能力，且可能被历史重复 SYN 误导。

四次挥手：TCP 是全双工，关闭需要双向各自关闭。被动方收到 FIN 后通常还有数据要发，所以 ACK 和它自己的 FIN 不能合并，因此比握手多一次。

面试口径：握手次数由“双向同步序列号 + 确认收发能力”决定；挥手多一次是因为全双工要分别关闭两个方向。

Q: 流量控制和拥塞控制有什么区别？

流量控制（rwnd）由接收方主导，防止发送方发太快撑爆接收缓冲区，是端到端问题；拥塞控制（cwnd）由发送方主导，防止打爆中间网络链路，是全网共享资源问题。实际发送窗口取 min(rwnd, cwnd)。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

RPC 是远程调用的「语义抽象」（方法、参数、返回值、超时、重试、负载均衡），HTTP/gRPC 只是它的「承载方式」，两者不在一个层面；理解 RPC 要看清它的 CPU 开销分布——序列化、系统调用、协议栈、重试，每一块都有对应优化（Protobuf/零拷贝、batch/io_uring、内核调优/RDMA、deadline+幂等+退避）。

复习定位

维度	内容
所属模块	网络基础
章节类型	概念类
解决问题	围绕 TCP/UDP、HTTP/gRPC/RPC、RDMA 和 GPUDirect 建立 AI Infra 网络答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

HTTP、gRPC 与 RPC

RPC 是远程调用抽象，HTTP/gRPC 是常见承载方式。面试要区分“调用语义”和“网络协议”：RPC 关心方法、参数、返回值、超时、重试、负载均衡；底层可能走 HTTP/1.1、HTTP/2、TCP 或其他协议。

RPC 链路 CPU 开销

阶段	开销	优化
序列化/反序列化	CPU 与内存分配	Protobuf、对象复用、零拷贝 buffer
系统调用	用户态/内核态切换	batch、io_uring、连接复用
协议栈	TCP/IP 处理、中断	内核调优、RSS/RPS、RDMA
重试	放大流量	deadline、幂等、退避、熔断

Q: RPC 超时和重试怎么设计？

先设置端到端 deadline，再把预算分配给下游调用；重试必须要求幂等或有去重机制，并使用指数退避和 jitter，避免在故障时形成重试风暴。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

RDMA 让网卡直接 DMA 读写远端内存，绕过内核协议栈、省掉 CPU 参与和数据拷贝，换来低延迟高吞吐，代价是 QP、内存注册、驱动和拥塞控制的复杂度；在 AI 训练里它的终极形态是 GPUDirect RDMA——NIC 直接读写 GPU HBM 不经 CPU staging，一旦 GPU 与 NIC 跨 Socket 或 GDR 不可用，路径退化成走 CPU pinned memory，延迟和 NCCL 吞吐都会明显变差。

复习定位

维度	内容
所属模块	网络基础
章节类型	机制类
解决问题	围绕 TCP/UDP、HTTP/gRPC/RPC、RDMA 和 GPUDirect 建立 AI Infra 网络答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

RDMA：绕过内核协议栈的内存访问

RDMA 允许网卡直接读写远端主机内存，减少 CPU 参与、系统调用和数据拷贝，适合高吞吐、低延迟通信。AI 训练里的 NCCL、参数同步和高速存储访问都会受 RDMA 能力影响。

TCP RPC vs RDMA

维度	TCP RPC	RDMA
目标	可靠请求/响应、服务治理	低延迟、低 CPU、高吞吐内存搬运
CPU 参与	序列化、系统调用、协议栈	注册内存后由 NIC DMA
工程难点	超时、重试、负载均衡	QP、内存注册、驱动、拥塞控制

RC / UC / UD

模式	含义	特点	场景
RC	Reliable Connected	可靠、有序、连接态	分布式训练、存储
UC	Unreliable Connected	连接态但不可靠	少见，上层自处理可靠性
UD	Unreliable Datagram	无连接、不可靠、开销低	控制消息、发现、广播

GPUDirect RDMA 数据路径

AI 训练里最理想的跨机路径不是 GPU 先拷贝到 CPU 内存再发网络，而是 NIC 直接读写 GPU HBM。这样可以减少 host staging、CPU 内存带宽占用和额外拷贝。

源 GPU HBM

梯度、参数分片或激活值在 GPU 显存中

本机 PCIe 路径

GPU 到同 NUMA/同 PCIe root 下的 RDMA NIC

RDMA NIC

网卡直接从 GPU memory 发起 DMA

IB/RoCE 网络

经过交换机、拥塞控制和路由

远端 GPU HBM

远端 NIC 直接写入目标 GPU 显存

如果 GPU 和 NIC 跨 Socket，或者 GDR 不可用，路径可能退化成 GPU → CPU pinned memory → NIC → 网络 → CPU pinned memory → GPU。这会增加延迟、占用 CPU 内存带宽，并降低 NCCL 有效吞吐。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

内容模块

Linux 与容器基础

进阶★☆☆⏱ 30 min

一句话结论

环境变量是进程启动时继承的一份 key-value 快照，每个进程一份、不是全局状态。AI Infra 里大量「在我机器上能跑、容器里跑不了」的问题，本质是 PATH、LD_LIBRARY_PATH、CUDA_VISIBLE_DEVICES、代理这几个变量在容器和宿主机之间不一致。

复习定位

维度	内容
所属模块	Linux 与容器基础
章节类型	概念类
解决问题	围绕运行环境、namespace、cgroup、rootfs、Docker/K8S 资源模型建立容器基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

环境变量与运行环境

环境变量是进程启动时继承的一组 key-value，用于传递配置、路径、鉴权和运行模式。它不是全局状态，而是每个进程自己的环境快照。

常见变量

变量	作用	问题
PATH	查找可执行文件	命令找不到或执行了错误版本
LD_LIBRARY_PATH	动态库查找路径	缺库、ABI 不兼容
CUDA_VISIBLE_DEVICES	控制 GPU 可见性	容器内卡号和宿主机卡号映射混淆
HTTP_PROXY	网络代理	下载失败或访问内网异常

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

容器不是轻量虚拟机，而是 Linux 内核三种能力的组合：namespace 决定进程「能看见什么」、cgroup 决定「能用多少资源」、rootfs/镜像决定「文件系统长什么样」。理解这三件套，才能解释容器为什么共享宿主机内核、为什么资源限制最终落到 cgroup。

复习定位

维度	内容
所属模块	Linux 与容器基础
章节类型	机制类
解决问题	围绕运行环境、namespace、cgroup、rootfs、Docker/K8S 资源模型建立容器基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

容器隔离三件套

容器不是轻量 VM，而是 Linux 内核能力的组合：namespace 负责“看见什么”，cgroup 负责“能用多少”，rootfs/镜像负责“文件系统长什么样”。

namespace

类型	隔离内容
pid	进程号视图
net	网卡、路由、端口
mnt	挂载点
uts	hostname
ipc	共享内存、信号量
user	用户和权限映射

cgroup

cgroup 限制和统计 CPU、内存、IO、pids 等资源。K8s 的 requests/limits 最终会落到 cgroup 资源控制上。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

Docker/runtime 解决「单机怎么把一个容器跑起来、限住资源」，Kubernetes 解决「一堆容器怎么调度、恢复、发现、治理」。面试里别把两者职责混在一起：镜像和 cgroup 是 runtime 层，requests/limits、QoS、controller、Service 是 K8s 层。

复习定位

维度	内容
所属模块	Linux 与容器基础
章节类型	概念类
解决问题	围绕运行环境、namespace、cgroup、rootfs、Docker/K8S 资源模型建立容器基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

Docker 与 Kubernetes 的分工

问题	Docker/Runtime	Kubernetes
环境复现	镜像、rootfs	镜像版本、拉取策略
资源限制	写 cgroup	requests/limits、QoS、调度
失败恢复	单机重启策略	Deployment/Job/StatefulSet controller
服务发现	基本不解决	Service、DNS、EndpointSlice

QoS、RSS 和 Usage

RSS 是进程实际驻留物理内存；cgroup usage 是容器级内存统计，包括匿名页、page cache、部分内核内存等。Pod QoS 根据 requests/limits 分为 Guaranteed、Burstable、BestEffort，影响 OOM 和驱逐优先级。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

Infra 面试里的容器运行时问题，重点不是“Docker 命令怎么用”，而是要讲清 Kubelet 如何通过 CRI 调 containerd，containerd 如何管理镜像、snapshot、sandbox 和 task，runc 如何按 OCI spec 创建 Linux 容器，containerd-shim 为什么要把容器进程和 containerd daemon 解耦。排障时要能沿着 Pod Event -> kubelet -> CRI -> containerd -> shim/runc -> CNI/CSI/kernel 这条链路定位。

复习定位

维度	内容
所属模块	Linux 与容器基础
章节类型	机制 + 排障类
解决问题	补齐 containerd、CRI、OCI、runc、shim、pause 容器、镜像层和节点侧排障的 Infra 面试知识。
面试抓手	先讲组件边界，再讲 Pod 启动链路，最后讲 ImagePullBackOff / ContainerCreating / Runtime NotReady 的排障路径。

先把概念说清楚

容器运行时不等于 Docker

Docker 是面向用户的容器产品，包含 CLI、API、build、network、volume 等能力；containerd 是更底层的容器运行时，专注镜像、容器生命周期、snapshot 和 task 管理；runc 是更底层的 OCI runtime，真正调用 Linux kernel 能力创建容器进程。

概念	是什么	面试里怎么说
CRI	Kubernetes 定义的 Container Runtime Interface，kubelet 通过它调用运行时	CRI 是 kubelet 和 runtime 的标准 gRPC 接口，不是具体 runtime
containerd	高层容器运行时 daemon	管镜像、content store、snapshot、container metadata、task、CRI plugin
runc	OCI low-level runtime	根据 OCI runtime spec 调 Linux namespace、cgroup、mount 等创建容器
OCI	Open Container Initiative 规范集合	image spec 定义镜像格式，runtime spec 定义如何运行容器
containerd-shim	containerd 和容器进程之间的托管层	负责 stdio、exit status、事件上报，让 containerd 重启不杀容器
pause container	Pod sandbox 的基础容器	持有 Pod network namespace / Pod IP，让业务容器共享 Pod 网络身份
CNI	Container Network Interface	给 Pod sandbox 配网络，如 veth、IP、route、iptables/eBPF
CSI	Container Storage Interface	给 Pod 准备和挂载 volume

运行时链路图

Kubernetes 到 containerd、shim、runc 和 Linux kernel 的容器运行时链路 — 本站整理的节点侧运行时链路：kubelet 通过 CRI 调 containerd，containerd 管 sandbox、镜像、snapshot 和 task，shim 托管容器进程，runc 调 Linux kernel 创建容器。

containerd 官方 CRI plugin architecture — containerd 官方 CRI plugin 架构图。来源：containerd docs, Architecture of The CRI Plugin, CC-BY-4.0。

Pod 启动链路

调度完成

kube-scheduler 把 Pod 绑定到某个 Node

kubelet SyncPod

kubelet watch 到本节点 Pod，开始本地执行

准备存储

volume manager / CSI 挂载 volume

创建 sandbox

kubelet 通过 CRI 调 RunPodSandbox

配置网络

containerd CRI plugin 调 CNI，创建 Pod network namespace

拉镜像

PullImage 解析 manifest、下载 layer、校验 digest

准备 rootfs

snapshotter 基于镜像 layer 生成容器 rootfs

启动容器

containerd 创建 shim，shim 调 runc 创建并启动进程

状态回写

kubelet 收集 container status 并写回 API Server

关键点：

RunPodSandbox 先于业务容器启动，因为 Pod 需要先有网络 namespace 和 Pod IP。
PullImage 走 CRI ImageService，containerd 会维护 content store 和 snapshot。
CreateContainer 只是创建容器配置和 rootfs，StartContainer 才启动进程。
runc 通常不是常驻 daemon，它创建容器后退出；常驻托管进程是 shim。

containerd 内部对象

对象	解释	常见追问
Content	镜像 blob 内容，按 digest 存储	为什么 digest 比 tag 更可靠
Image	镜像元数据，指向 manifest / config / layer	tag 和 digest 的区别
Snapshot	rootfs 的可写层和只读层组合	overlayfs、copy-on-write
Container	containerd 的容器元数据，不等于正在运行的进程	container 和 task 区别
Task	正在运行的进程对象	start/kill/exec/wait 都是 task 操作
Sandbox	Pod 级运行环境	pause 容器、Pod namespace、Pod IP

Docker、containerd、runc 的关系

Docker CLI / API

面向用户，build/run/push/pull 等产品能力

Docker Engine

调 containerd 管理容器生命周期

containerd

管镜像、snapshot、container、task

containerd-shim

托管容器进程，解耦 daemon

runc

按 OCI spec 创建 Linux 容器

Linux kernel

namespace、cgroup、mount、capability、seccomp

面试要避免两种说法：

错误说法	正确说法
Kubernetes 不用 Docker 后，Docker 镜像不能跑了	错。dockershim 移除的是 kubelet 到 Docker Engine 的内置适配层，OCI/Docker 镜像格式仍兼容
containerd 直接 fork 出业务容器	不准确。containerd 通常启动 shim，shim 再调用 runc，容器进程由 shim 托管
runc 负责镜像拉取	错。runc 只负责按 OCI runtime spec 创建容器，镜像和 snapshot 是 containerd 负责
pause 容器没用	错。pause 是 Pod namespace 锚点，业务容器重启时 Pod 网络身份可以保持稳定

常用排障命令

# 看 kubelet 看到的 Pod / Container 状态
kubectl describe pod <pod> -n <ns>
kubectl get events -n <ns> --sort-by=.lastTimestamp

# 节点侧：用 CRI 视角看 runtime
crictl ps -a
crictl pods
crictl images
crictl inspect <container_id>
crictl inspectp <pod_sandbox_id>
crictl logs <container_id>
crictl pull <image>

# containerd 视角
ctr -n k8s.io containers list
ctr -n k8s.io tasks list
ctr -n k8s.io images list
ctr -n k8s.io snapshots list

# 日志和进程
journalctl -u kubelet -f
journalctl -u containerd -f
ps -ef | grep containerd-shim

# CNI / 网络
ip netns list
ip link
ip route
ls /etc/cni/net.d/

crictl 更适合 Kubernetes 节点排障，因为它走 CRI；ctr 是 containerd 自带低层调试工具，命名空间常用 k8s.io；nerdctl 更像 Docker CLI 体验，适合人工运行容器。

常见面试问题

Q: containerd、runc、containerd-shim 分别负责什么？

containerd 是高层 runtime daemon，负责镜像拉取、content store、snapshot、容器元数据、task 生命周期和 CRI 服务。runc 是 OCI low-level runtime，负责根据 OCI spec 调 Linux kernel 创建容器。containerd-shim 位于 containerd 和容器进程之间，负责托管容器进程、转发 stdio、收集 exit status 和上报事件。

一句话：containerd 管生命周期和镜像，runc 创建容器，shim 托管进程并解耦 daemon。

Q: 为什么需要 containerd-shim？containerd 不能直接管容器进程吗？

如果 containerd 直接成为所有容器进程的父进程，那么 containerd 重启或升级时会影响正在运行的容器。shim 把容器进程和 containerd daemon 解耦：containerd 可以重启，shim 继续托管容器；shim 还负责保留 stdio、等待容器退出、收集 exit code、上报事件和清理资源。

面试口径：shim 的核心价值是容器生命周期托管和 daemon 解耦。

Q: pause 容器是什么？为什么 Pod 需要它？

Pod 不是一个容器，而是一组共享网络等 namespace 的容器。pause 容器是 Pod sandbox 的基础容器，它先启动并持有 Pod 的 network namespace、Pod IP 和部分共享 namespace。业务容器启动时加入这个 sandbox。这样业务容器重启时，Pod 的网络身份仍然可以保持稳定。

面试口径：pause 容器是 Pod 的 namespace 锚点。

Q: Kubernetes 移除 dockershim 后，Docker 镜像还能跑吗？

能。dockershim 移除的是 kubelet 内置的 Docker Engine 适配层，不是移除 Docker 镜像格式。只要镜像符合 OCI / Docker image spec，containerd 和 CRI-O 都能拉取和运行。变化在节点链路：以前是 kubelet → dockershim → Docker Engine → containerd，现在是 kubelet → CRI → containerd。

面试口径：dockershim removed 不等于 Docker image 不能用；镜像格式兼容，运行时链路变了。

Q: ImagePullBackOff 怎么排查？

先看 Pod Events 里的错误类型：镜像名/tag 是否存在，registry 是否可达，imagePullSecret 是否正确，节点 DNS/代理/证书是否正常，是否触发 registry rate limit。然后到节点侧用 crictl pull 复现，用 journalctl -u containerd 看 runtime 具体错误。

kubectl describe pod  -n 
kubectl get secret -n 
crictl pull 
journalctl -u containerd -n 200

面试口径：ImagePullBackOff 是 kubelet 拉镜像失败后的退避状态，根因通常在镜像名、权限、网络、证书或 registry。

Q: ContainerCreating 卡住怎么排查？

ContainerCreating 表示 Pod 已经调度到节点，但节点侧执行还没完成。排查顺序是 Events、kubelet 日志、containerd 日志、CNI 日志/配置、CSI mount、镜像拉取和 sandbox 创建。常见原因包括 CNI 分配 IP 失败、CSI 挂载超时、sandbox 创建失败、镜像拉取慢、节点磁盘压力。

面试口径：Pending 偏调度侧；ContainerCreating 偏节点执行侧，重点查 kubelet、runtime、CNI、CSI。

Q: 容器镜像 layer、snapshot、overlayfs 是什么关系？

镜像由多层只读 layer 组成，containerd 把这些 layer 存在 content store 中。启动容器时，snapshotter 会基于这些只读层准备 rootfs，并给容器加一个可写层。overlayfs 常用于把多个只读 lowerdir 和一个 writable upperdir 合成一个统一视图。容器内写文件时触发 copy-on-write，不会修改原始镜像层。

面试口径：image layer 是内容，snapshot 是运行时 rootfs 视图，overlayfs 是常见实现。

Q: 容器资源限制最终落在哪里？

Kubernetes 的 requests 主要用于调度，limits 会通过 kubelet / runtime 写到 cgroup。CPU limit 常体现为 CFS quota，内存 limit 体现为 cgroup memory 上限，超过可能触发容器 OOMKilled。GPU 这类设备资源通常通过 device plugin 注入设备文件、环境变量或 runtime hook；GPU 显存本身不一定被 cgroup 原生限制，需要厂商 runtime 或平台策略配合。

面试口径：CPU/内存限制最终落到 cgroup；GPU 设备可见性由 device plugin/runtime 控制，显存限制要看厂商能力。

Infra 面试回答结构

如果面试官问“介绍一下容器运行时”：

先分层

Docker / containerd / runc / Linux kernel 边界

再讲接口

kubelet 通过 CRI 调 runtime，OCI 规范定义镜像和运行方式

再讲 Pod

sandbox / pause 容器先创建，业务容器加入共享 namespace

再讲镜像

manifest、layer、content store、snapshotter、overlayfs

最后排障

Events -> kubelet -> containerd -> CNI/CSI -> kernel

可以这样组织：

容器不是轻量 VM，本质是 Linux namespace、cgroup、rootfs、capability、seccomp 等能力的组合。
Kubernetes 不直接调用 Docker/containerd 私有 API，而是通过 CRI 调运行时。
containerd 是高层 runtime，负责镜像、snapshot、容器元数据和 task；runc 是 OCI runtime，负责创建 Linux 容器。
Pod 先创建 sandbox/pause 容器，持有 Pod 网络 namespace；业务容器再加入 sandbox。
节点侧问题要按链路排：调度是否完成、kubelet 是否 SyncPod、containerd 是否拉镜像/建 sandbox、CNI/CSI 是否成功、kernel cgroup/namespace 是否正常。

参考资料

containerd docs: Architecture of The CRI Plugin
containerd docs: Runtime v2
Kubernetes docs: Container Runtimes
Kubernetes blog: Dockershim Removal FAQ

关联模块

namespace / cgroup / rootfs：解释容器隔离和资源限制的 Linux 基础。
Docker 与 Kubernetes 资源模型：解释 requests/limits、QoS、OOMKilled。
Kubernetes 架构与 Pod 主链路：解释 Pod 从 API Server 到 kubelet 执行的完整路径。
Kubernetes 故障排查与稳定性：解释 Pending、ContainerCreating、CrashLoop、ImagePullBackOff 等排障入口。

内容模块

Linux 内核与大模型系统

精通★☆☆⏱ 22 min

一句话结论

NUMA 是多 Socket 服务器的非统一内存访问架构，每个 Socket 有自己直连的本地内存，访问本地内存延迟低带宽高，跨 Socket 访问要走 UPI/QPI/Infinity Fabric，延迟升高、带宽下降还会抢占互联链路。大模型训练不是 GPU 自己算，而是 CPU、内存、GPU、PCIe/NVLink、NIC 的协同，所以 NUMA 绑定的核心原则就是让一个 rank 的 CPU 线程、内存页、GPU 和 NIC 尽量落在同一个 NUMA domain，否则 DataLoader、H2D 拷贝和 RDMA 都可能跨 Socket 导致 GPU 等数据。

复习定位

维度	内容
所属模块	Linux Kernel for AI Infra
章节类型	机制类
解决问题	围绕 NUMA、cgroup、hugepage、THP、IO、zero-copy 等内核机制建立 AI Infra 系统答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

为什么大模型系统要关心 NUMA？

大模型训练和推理不是“GPU 自己算”这么简单，而是 CPU、内存、GPU、PCIe/NVLink、网卡、磁盘 I/O 的协同调度问题。GPU 算力很强，但如果 Linux 内核侧的 NUMA、CPU 绑核、内存分配和设备亲和性不合理，就会出现 GPU 等数据、CPU 争抢、远端内存访问、H2D 拷贝变慢、RDMA 抖动等问题。

NUMA 是 Non-Uniform Memory Access，非统一内存访问架构。在多 Socket 服务器中，每个 CPU Socket 通常有自己直连的内存控制器和本地内存。

Socket 0 ── 本地内存 0
Socket 1 ── 本地内存 1

CPU 访问自己 Socket 直连的内存，叫 local memory access；访问另一个 Socket 连接的内存，叫 remote memory access。

访问类型	延迟	带宽	额外影响
本地内存访问	低	高	不占用 Socket 间互联
远端内存访问	高	低	占用 UPI/QPI/Infinity Fabric 等 Socket 间链路

Socket 间通常通过 UPI、QPI、Infinity Fabric 等互联链路通信。这个链路的带宽和延迟通常弱于本地内存控制器，因此远端访问会带来明显性能损耗。

跨 Socket 访问会怎样？

假设一个训练进程的 CPU 线程绑定在 Socket 0：

CPU Thread → Socket 0

但它的大量内存页实际分配在 Socket 1：

Memory Pages → Socket 1

访问路径会变成：

Socket 0 CPU Core

训练线程或 DataLoader worker

Socket 间互联

UPI / QPI / Infinity Fabric

Socket 1 Memory Controller

远端内存控制器

Socket 1 DRAM

实际数据所在内存

后果包括：

内存访问延迟升高：CPU 每次访问远端内存都要跨 Socket。
有效内存带宽下降：本地 DRAM 带宽不能充分利用，访问受限于 Socket 间互联。
Socket 间链路拥塞：多个进程跨 Socket 访问会挤占 UPI/QPI/IF。
DataLoader 性能下降：解码、预处理、batch 拼接依赖 CPU 和内存带宽，远端访问会导致 GPU 等数据。
GPU-NIC 通信路径变差：GPU 或 NIC 挂在 Socket 0，但 buffer 在 Socket 1，会让 H2D、RDMA 或 staging 路径跨 Socket。

典型糟糕路径：

Socket 1 Memory

数据缓冲区实际在远端 NUMA node

Socket 间互联

跨 Socket 搬运

Socket 0 PCIe Root Complex

GPU / NIC 所在侧

GPU / NIC

H2D 拷贝或 RDMA 收发

这会影响 CPU 到 GPU 的 H2D 拷贝、GPU 到 CPU pinned memory 的 staging、RDMA 网卡收发、数据加载吞吐和多卡训练通信稳定性。

多卡机器上的 NUMA 绑定原则

核心原则是：

> 让 CPU 线程、内存、GPU、NIC 尽量落在同一个 NUMA domain / Socket 附近。

一台 8 卡服务器的拓扑可能类似：

Socket 0
  ├── CPU cores 0-63
  ├── Memory node 0
  ├── GPU 0, GPU 1, GPU 2, GPU 3
  └── NIC 0

Socket 1
  ├── CPU cores 64-127
  ├── Memory node 1
  ├── GPU 4, GPU 5, GPU 6, GPU 7
  └── NIC 1

比较好的绑定方式是：

rank 0 → GPU 0 → Socket 0 CPU cores → NUMA node 0 memory
rank 1 → GPU 1 → Socket 0 CPU cores → NUMA node 0 memory
rank 4 → GPU 4 → Socket 1 CPU cores → NUMA node 1 memory
rank 5 → GPU 5 → Socket 1 CPU cores → NUMA node 1 memory

要避免：

rank 0 → GPU 0 挂 Socket 0
CPU 线程 → Socket 1
内存页 → NUMA node 1

这种绑定会导致 CPU 数据处理、H2D 拷贝、GPU-NIC 通信都可能跨 Socket。

常用 NUMA 绑定方法

使用 numactl

将进程绑定到 NUMA node 0：

numactl --cpunodebind=0 --membind=0 python train.py

含义是：

CPU 尽量使用 node 0
内存也从 node 0 分配

如果是 8 卡机器，可以按 rank 或 GPU 分组：

CUDA_VISIBLE_DEVICES=0,1,2,3 numactl --cpunodebind=0 --membind=0 python train.py
CUDA_VISIBLE_DEVICES=4,5,6,7 numactl --cpunodebind=1 --membind=1 python train.py

结合 taskset

taskset 可以绑定 CPU core：

taskset -c 0-31 python train.py

但它只管 CPU affinity，不直接管内存分配。实际生产中常常组合使用：

numactl --membind=0 taskset -c 0-31 python train.py

容器中通过 cpuset + device 分配

在 Kubernetes 或容器环境中，通常通过这些能力保证拓扑接近：

CPU cpuset
memory NUMA policy
GPU device assignment
NVIDIA_VISIBLE_DEVICES
Topology Manager
Device Plugin

目标是让容器的 CPU cores、内存、GPU、NIC 在拓扑上接近。

排查和观测

目标	命令	看什么
查看 NUMA node	`numactl --hardware`	CPU core、内存 node 分布
查看 GPU/NIC 拓扑	`nvidia-smi topo -m`	GPU-GPU、GPU-NIC、GPU-CPU 亲和性
查看进程 NUMA 分布	`numastat -p <pid>`	进程内存页落在哪些 node
查看 CPU 亲和	`taskset -pc <pid>`	进程允许在哪些 CPU core 运行
查看系统拓扑	`lstopo`	CPU、PCIe、GPU、NIC 的完整层级

排查训练慢时，如果 GPU Util 周期性掉低，要同时看 CPU worker 是否跨 NUMA、page cache 是否抖动、H2D 是否跨 Socket、NIC 是否和 GPU 不亲和。

一句话结论

cgroups 是 Linux 内核限制、统计、隔离一组进程资源的机制，配合 namespace（看见什么）、capabilities/seccomp（能做什么）构成容器基础；v1 是多 controller 多层级、v2 是统一层级语义更一致。CPU 用 quota、weight、cpuset 控制，内存用 memory.max/high/swap.max 控制，I/O 用 io controller 做带宽和 IOPS。关键误区是 cgroups 原生并不理解 GPU 算力或显存配额，它只能通过 devices controller 控制容器能否访问 /dev/nvidia* 设备文件，真正的 GPU 注入和细粒度隔离要靠 NVIDIA Container Toolkit、Device Plugin、MIG/MPS 和上层调度器协同。

复习定位

维度	内容
所属模块	Linux Kernel for AI Infra
章节类型	机制类
解决问题	围绕 NUMA、cgroup、hugepage、THP、IO、zero-copy 等内核机制建立 AI Infra 系统答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

cgroups 是什么？

cgroups 是 Linux 内核提供的资源控制机制，全称是 control groups。它可以限制、统计、隔离一组进程的资源使用。

常见资源包括：

CPU
内存
I/O
进程数
设备访问权限
网络优先级

容器本质上大量依赖：

namespace + cgroups + capabilities + seccomp

其中：

namespace 负责“看见什么”。
cgroups 负责“能用多少”。
capabilities/seccomp 负责“能做什么”。

cgroups v1 与 v2

cgroups v1

cgroups v1 是多层级、多 controller 模型：

/sys/fs/cgroup/cpu/...
/sys/fs/cgroup/memory/...
/sys/fs/cgroup/blkio/...
/sys/fs/cgroup/devices/...

不同资源 controller 可以有不同的 cgroup 树。优点是灵活、历史兼容性好；缺点是层级复杂，不同 controller 行为不统一。

cgroups v2

cgroups v2 是统一层级模型：

/sys/fs/cgroup/...

所有 controller 在同一棵树上协同工作。它的接口更统一，语义更清晰，也更适合现代容器运行时和 systemd 管理。

维度	cgroups v1	cgroups v2
层级模型	多 hierarchy	统一 hierarchy
controller 行为	不同 controller 差异大	语义更统一
容器生态	历史兼容多	现代发行版逐步默认
AI Infra 关注	老集群常见	新集群、systemd、K8s 新版本更常见

CPU 限制：quota、weight、cpuset

CPU 资源常见控制方式包括三类。

CPU quota / period

限制一段周期内最多可用多少 CPU 时间。

例如 cgroups v2：

cpu.max = 200000 100000

含义可以理解为：

每 100ms 周期内最多使用 200ms CPU 时间

也就是最多约等于 2 个 CPU core。

CPU weight / shares

用于相对权重分配。多个 cgroup 竞争 CPU 时，权重高的获得更多 CPU 时间。它不是硬上限，而是竞争时的比例。

cpuset

限制进程只能运行在哪些 CPU core 上。

cpuset.cpus = 0-31

表示这个 cgroup 只能使用 0 到 31 号 CPU。在大模型训练中，cpuset 很重要，因为它可以配合 NUMA 绑定，让某个训练进程只使用靠近目标 GPU 的 CPU cores。

调度器分配 GPU

例如容器获得 GPU0

选择邻近 CPU cores

例如 Socket0 的 0-31 号 core

设置 cpuset

限制容器 CPU affinity

设置内存策略

尽量从同 NUMA node 分配内存

减少跨 Socket

DataLoader、H2D、RDMA 路径更稳定

内存限制：memory.max、memory.high、swap

内存 controller 可以限制：

最大内存使用量
swap 使用
内存压力
OOM 行为
page cache 使用

典型限制包括：

memory.max
memory.high
memory.swap.max

其中：

memory.max 是硬限制，超过后可能触发 OOM。
memory.high 是软限制，超过后会触发 reclaim 和 throttling。
memory.swap.max 控制 swap 使用。

在训练/推理场景中，如果容器内存限制过紧，可能出现：

DataLoader worker 被 OOM kill。
page cache 不够导致权重加载变慢。
频繁 reclaim 导致吞吐抖动。
pinned memory 分配失败。
推理服务 P99 因内存回收而升高。

I/O 限制：带宽、IOPS、权重

I/O controller 可以限制块设备读写，例如：

读带宽上限
写带宽上限
IOPS 上限
I/O 权重

典型场景：

一个推理服务正在加载 100GB 权重
另一个训练任务正在读取海量样本

如果没有 I/O 隔离，可能互相影响：

权重加载变慢。
训练数据读取抖动。
page cache 被冲掉。
延迟 P99 升高。

因此生产集群中经常需要对不同任务做 I/O QoS，例如训练任务、在线推理服务、模型分发服务、checkpoint 写入任务不能无约束地抢同一块盘或同一个网络存储。

cgroups 怎么感知 GPU？

严格说：

> Linux cgroups 原生并不知道“GPU 算力百分比”这种资源。

cgroups 对 GPU 的管理主要不是通过“限制 GPU SM 使用率”实现的，而是通过 设备访问控制 和 容器运行时注入 实现的。

路径一：devices controller

Linux 中 GPU 设备通常表现为字符设备文件：

/dev/nvidia0
/dev/nvidia1
/dev/nvidiactl
/dev/nvidia-uvm
/dev/nvidia-uvm-tools

cgroups 的 devices controller 可以控制进程是否允许访问这些设备。

例如，容器只被允许访问：

/dev/nvidia0
/dev/nvidiactl
/dev/nvidia-uvm

那么它就只能看到或使用 GPU 0。这种方式控制的是：

能不能打开某个 GPU 设备文件

不是直接控制：

GPU 算力使用 30%
GPU 显存最多 20GB
GPU HBM 带宽最多 50%

路径二：NVIDIA Container Toolkit

容器中使用 GPU 通常依赖 NVIDIA Container Toolkit。它会根据环境变量或容器配置，把对应 GPU 设备、驱动库、运行时依赖挂载到容器中。

常见控制变量包括：

NVIDIA_VISIBLE_DEVICES
NVIDIA_DRIVER_CAPABILITIES

例如：

docker run --gpus '"device=0,1"' ...

容器内通常只会看到指定 GPU。在 Kubernetes 中，通常通过：

NVIDIA Device Plugin
Kubelet
Container Runtime
NVIDIA Container Toolkit

协同实现 GPU 分配。

GPU 显存和算力怎么隔离？

cgroups 本身通常不直接精细限制 GPU SM、Tensor Core、HBM 带宽或显存容量；这些通常需要 GPU 驱动、MIG、MPS、容器运行时和上层调度器协同完成。

方案	隔离对象	优点	局限
整卡分配	一张或多张完整 GPU	简单、隔离相对好	资源利用率可能低
MIG	GPU 硬件实例	硬件级切分，显存/算力相对隔离	仅特定 GPU 支持，规格固定
MPS	多进程共享 GPU	降低上下文切换，提高小 kernel 并发	隔离弱于 MIG
time-slicing	时间片共享	简单，适合开发/低优任务	性能抖动明显
框架限制	进程级显存策略	易用，例如 PyTorch fraction	不是真正硬隔离
调度器记录	上层资源账本	能做配额和准入控制	依赖平台实现

一句话结论

虚拟内存给每个进程独立地址空间，MMU 把虚拟地址翻译成物理地址，TLB 缓存翻译结果；普通页 4KB，大页 2MB/1GB 能减少页表项、扩大 TLB 覆盖、降低 TLB miss 和 page table walk 开销。THP 是内核自动把普通页合并成大页的透明大页机制，用着方便但透明不等于免费——page fault 分配大页、khugepaged 合并、compaction 碎片整理和大页拆分都可能引入延迟抖动。所以大页是吞吐和延迟稳定性的权衡：稳定吞吐型任务可能受益，在线推理等 P99 敏感服务通常设为 never 或 madvise，到底开不开要 benchmark。

复习定位

维度	内容
所属模块	Linux Kernel for AI Infra
章节类型	机制类
解决问题	围绕 NUMA、cgroup、hugepage、THP、IO、zero-copy 等内核机制建立 AI Infra 系统答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

虚拟内存、物理内存和 MMU

虚拟内存 是操作系统给每个进程提供的独立地址空间。进程看到的是虚拟地址，不是直接的物理 DRAM 地址。

虚拟内存带来的好处包括：

隔离性：进程 A 不能随便访问进程 B 的内存。
地址空间连续：进程以为自己拥有连续地址，但底层物理页可以是离散的。
按需分配：malloc 后不一定马上分配物理内存，可能等第一次访问时触发 page fault。
支持 mmap、共享内存、文件映射：文件可以映射到进程地址空间。

物理内存 就是真实 DRAM。操作系统把物理内存切成页，常见页大小是：

4KB

虚拟地址到物理地址的映射关系由页表维护。

MMU 是 Memory Management Unit，内存管理单元。它负责把 CPU 发出的虚拟地址转换成物理地址：

Virtual Address

CPU 发出的虚拟地址

MMU

内存管理单元处理地址翻译

Page Table Walk

查询页表，找到映射关系

Physical Address

得到真实 DRAM 地址

为了加速地址转换，CPU 里有 TLB，即 Translation Lookaside Buffer，可以理解为页表转换缓存。

情况	代价
TLB hit	虚拟地址到物理地址转换很快
TLB miss	需要 page table walk，开销更高

Huge Pages 为什么有用？

普通页通常是 4KB。Huge Page 可以是：

2MB
1GB

使用大页的好处是：

同样大小的内存，需要更少页表项。
TLB 覆盖范围更大。
TLB miss 更少。
page table walk 开销更低。

例如映射 1GB 内存：

页大小	需要页数量
4KB page	262144 个页
2MB huge page	512 个页
1GB huge page	1 个页

对大模型训练/推理，动辄几十 GB 到几百 GB 的 host memory、KV cache staging、权重加载缓存、数据集缓存，大页可能减少 TLB 压力。

THP：透明大页

Transparent Huge Pages，THP 是 Linux 的透明大页机制。它的目标是：

应用程序不显式申请 huge page
内核自动尝试把普通 4KB 页合并成 2MB 大页

THP 的优点是使用方便，应用无需修改代码。但它的问题是：透明不等于免费。

内核可能在运行时做：

page fault 时分配大页；
后台 khugepaged 合并页面；
内存碎片整理 compaction；
页面拆分 split。

这些操作可能引入延迟抖动。

为什么深度学习系统中经常建议关闭 THP？

很多在线服务、数据库、低延迟推理系统会建议关闭 THP，原因不是“大页一定不好”，而是 THP 的自动行为可能不稳定。

THP 可能导致延迟尖刺

当内核尝试分配 2MB 连续物理内存时，如果内存碎片严重，可能触发 compaction。

这会导致：

请求延迟突然升高；
DataLoader 卡顿；
推理 P99/P999 抖动。

THP 的收益不稳定

深度学习系统里有大量内存分配模式：

小对象；
临时 buffer；
pinned memory；
DataLoader batch；
mmap 权重；
CUDA runtime 内存；
通信 buffer。

不一定都适合自动大页。

可能影响内存回收

大页拆分、合并、回收比普通 4KB 页复杂，内存压力大时可能加剧抖动。

可能影响 fork / copy-on-write

某些数据加载或服务启动模式中，如果进程使用 fork，THP 可能让 copy-on-write 的粒度变大，造成额外内存开销。

THP 一定要关闭吗？

不是。更准确的说法是：

> 吞吐型、长时间运行、内存访问模式稳定的任务可能从大页受益；低延迟、强稳定性、容易受内存碎片影响的在线服务通常倾向关闭 THP 或设为 madvise。

常见策略：

always   ：尽量对所有匿名内存使用 THP
madvise  ：只有应用显式 madvise 时才使用 THP
never    ：禁用 THP

在深度学习系统中，可以这样理解：

场景	常见策略	原因
在线推理服务	`never` 或 `madvise`	更关注 P99/P999 稳定性
离线训练任务	benchmark 后决定	可能收益来自 TLB miss 降低，也可能收益不明显
数据库/参数服务	通常 `never` 或 `madvise`	避免 compaction 和回收抖动
大规模 CPU 内存扫描	可能受益	访问模式稳定、TLB 压力大

如果某个训练任务主要瓶颈是 TLB miss 或大规模 CPU 内存扫描，THP 可能有收益；如果主要瓶颈是 GPU 计算或 I/O，THP 收益可能不明显，反而可能带来抖动。

显式 HugeTLB 与 THP

还有一种方式是显式 HugeTLB：

提前预留 huge pages
应用显式使用
行为更可控

机制	使用方式	优点	缺点
普通 4KB 页	默认	稳定、灵活	TLB 覆盖范围小
THP	内核自动	应用无感，可能提升吞吐	可能引入延迟抖动
HugeTLB	显式预留/使用	可控、稳定	配置复杂，灵活性差

和大模型训练/推理的关系

大模型系统里，Linux 内存管理会影响：

权重加载时的 page cache 行为；
mmap 权重文件的 page fault；
DataLoader worker 的内存分配；
pinned memory 是否能稳定分配；
容器 memory limit 下的 reclaim；
THP compaction 对 P99 的影响；
NUMA node 本地内存是否足够；
fork + copy-on-write 的额外内存开销。

模型权重 / batch 数据

文件、网络或对象存储进入 CPU 侧

虚拟内存映射

malloc / mmap / page cache

MMU + TLB

地址翻译影响 CPU 侧访问效率

THP / HugeTLB

可能降低 TLB miss，也可能引入抖动

Pinned Memory

H2D DMA 前的关键缓冲区

GPU HBM

最终进入模型计算路径

一句话结论

大模型权重加载是典型系统瓶颈：权重几十到几百 GB 要穿过磁盘、page cache、用户态 buffer、反序列化、CPU 内存、pinned memory 再到 GPU HBM，路径不合理 GPU 就一直空等。优化围绕减少拷贝展开——mmap 省掉 page cache 到用户态的拷贝、Direct I/O 绕过 page cache 避免污染、sendfile 做文件到网络的零拷贝，落地还要叠加并行 shard、pinned memory 和 NUMA-aware 加载。

复习定位

维度	内容
所属模块	Linux Kernel for AI Infra
章节类型	机制类
解决问题	围绕 NUMA、cgroup、hugepage、THP、IO、zero-copy 等内核机制建立 AI Infra 系统答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

大模型权重加载为什么是系统瓶颈？

大模型权重可能是几十 GB、几百 GB，甚至 TB 级分片。加载路径涉及：

磁盘 / 网络存储
文件系统
page cache
用户态 buffer
反序列化
CPU 内存
pinned memory
GPU HBM

如果路径不合理，GPU 会一直等待权重或 batch 数据。典型问题包括：

page cache 抖动；
CPU 拷贝过多；
上下文切换频繁；
小 I/O 太多；
反序列化慢；
NUMA 不匹配；
PCIe 拷贝慢。

传统 read/write 路径

以从磁盘读取权重到用户态为例：

read(fd, user_buffer, size);

典型路径是：

磁盘 / SSD

权重或数据集 shard

DMA

存储设备把数据搬到内核

Kernel Page Cache

内核页缓存

CPU copy

从 page cache 拷贝到用户态

User Buffer

应用自己的 buffer

至少涉及：

1 次 DMA：磁盘 → 内核 page cache
1 次 CPU copy：page cache → 用户态 buffer

如果之后还要拷贝到 GPU：

User Buffer

CPU 内存中的 tensor buffer

cudaMemcpyAsync

H2D 拷贝

GPU HBM

进入 GPU 显存

整体可以理解为：

磁盘 → page cache → user buffer → GPU HBM

其中：

磁盘 → page cache：DMA。
page cache → user buffer：CPU 拷贝。
user buffer → GPU HBM：DMA，经 PCIe/NVLink 相关路径。

read/write 的上下文切换

以阻塞 read() 为例，典型过程是：

用户态调用 read()

应用进入 syscall

陷入内核态

内核检查 fd、page cache、权限等

发起 I/O 或拷贝

cache miss 时发起磁盘 I/O

进程 sleep

数据未就绪时被调度出去

I/O 完成唤醒

中断或 completion 唤醒进程

返回用户态

read 返回给应用

从用户进程视角，至少有：

用户态 → 内核态
内核态 → 用户态

如果 I/O 阻塞，还会有：

进程调度出去
I/O 完成后再调度回来

对于大量小文件、小 read，系统调用和上下文切换开销会非常明显。

传统 write() 类似：

User Buffer

应用待写数据

CPU copy

拷贝进入内核

Kernel Page Cache

写入页缓存

DMA

后台刷盘

Disk / SSD

持久化存储

如果写网络 socket：

User Buffer → Kernel Socket Buffer → NIC DMA → Network

传统路径的主要问题是用户态和内核态之间多次拷贝、系统调用次数多、上下文切换多、page cache 可能污染。

mmap：把文件映射到地址空间

mmap 可以把文件映射到进程虚拟地址空间。

传统 read：

read(fd, user_buffer, size)

mmap：

ptr = mmap(file)
直接访问 ptr[i]

访问路径变成：

文件

权重文件或 shard

Page Cache

内核缓存文件页

用户虚拟地址映射

应用像访问内存一样访问文件内容

相比 read() 的：

磁盘 → page cache → user buffer

mmap() 可以避免：

page cache → user buffer 的显式 CPU 拷贝

因为用户态虚拟地址直接映射到 page cache 对应的物理页。

这对大权重文件有价值：

不用一次性 read 到用户 buffer。
可以按需 page fault 加载。
多个进程可以共享同一份 page cache。
减少用户态额外内存副本。

mmap 的代价

mmap 不是万能的，它的问题包括：

page fault 开销：第一次访问页面时，如果页面不在内存中，会触发 page fault。
随机访问可能导致大量缺页：访问模式很随机时可能造成 page fault 风暴。
预取策略需要调优：可以配合 madvise。
仍然要拷贝到 GPU：mmap 优化文件到 CPU 地址空间，不代表权重自动进入 GPU HBM。

加载模型时仍然可能需要：

mmap file
  → CPU 解析 tensor metadata
  → cudaMemcpyAsync
  → GPU HBM

mmap 适合什么？

适合：

大文件；
只读权重；
多个 worker / 进程共享；
按需加载；
随机访问部分权重；
减少用户态 buffer 副本。

不适合：

极端顺序大吞吐且希望绕过 page cache；
对 page fault 抖动极敏感；
访问模式不可预测；
文件生命周期很短。

Direct I/O：绕过 page cache

Direct I/O 通常指使用 O_DIRECT 绕过 page cache。

传统 buffered I/O：

Disk → Page Cache → User Buffer

Direct I/O：

Disk → User Buffer

它主要优化三点：

避免 page cache 污染：大模型权重文件巨大，一次加载可能把 page cache 塞满，挤掉其他服务热数据。
减少一层缓存管理：不经过 page cache，可以减少内核缓存管理开销。
让应用自己控制缓存：高性能推理引擎或存储系统可以自己管理 buffer、预取、对齐和生命周期。

Direct I/O 的代价是要求更严格：

buffer 地址对齐；
I/O size 对齐；
file offset 对齐；
通常需要较大的 I/O 粒度；
绕过 page cache 后重复读取不会自动命中缓存；
应用自己要做缓存；
小 I/O 性能可能更差。

适合：

大文件顺序读取；
应用自己做缓存；
不希望污染 page cache；
权重只加载一次；
存储吞吐很高。

不适合：

大量小随机 I/O；
希望依赖 page cache 加速重复访问；
应用不想处理对齐和 buffer 管理。

sendfile 与零拷贝

sendfile() 用于在两个文件描述符之间传输数据，典型是：

文件 fd → socket fd

传统用户态转发：

read(file_fd, user_buffer)
write(socket_fd, user_buffer)

路径是：

Disk

文件数据

Kernel Page Cache

内核缓存

User Buffer

进入用户态

Kernel Socket Buffer

再回内核 socket buffer

NIC

发送网络

sendfile() 优化后，路径可以接近：

Disk

文件数据

Kernel Page Cache

内核页缓存

Socket Buffer / NIC

直接进入网络发送路径

Network

发给远端节点

它主要减少：

内核态 → 用户态的数据拷贝；
用户态 → 内核态的数据拷贝；
系统调用次数；
上下文切换；
CPU cache 污染。

适合：

文件服务器；
模型权重分发服务；
HTTP 静态文件下载；
节点间传输 checkpoint / shard。

sendfile 对 GPU 加载的最终一步不是主要路径。GPU 加载通常是：

Disk → CPU memory/page cache → GPU HBM

而 sendfile 更适合：

Disk/File → Network Socket

所以它更适合模型分发链路，而不是单机内权重进入 GPU HBM 的最终一步。

四种 I/O 方式对比

方式	数据路径	优点	缺点	适合场景
read/write	Disk → Page Cache → User Buffer	简单、通用、兼容性好	多一次用户态拷贝，syscall 开销明显	普通文件读取、小中型文件
mmap	Disk → Page Cache → 用户虚拟地址映射	少一次用户态拷贝，按需加载，多进程共享 page cache	page fault 抖动，访问模式影响大	大权重文件、只读模型、按需访问
Direct I/O	Disk → User Buffer	绕过 page cache，避免缓存污染，应用可控	对齐要求高，小 I/O 不友好，需自管缓存	大文件顺序读、高性能存储、一次性加载
sendfile	Disk/Page Cache → Socket/NIC	避免数据进用户态，减少拷贝和 syscall	主要用于文件到网络，不适合复杂解析	模型分发、文件服务、checkpoint 传输

大模型权重加载优化思路

以推理服务加载大模型为例，典型链路是：

NVMe / Network Storage

本地盘、远端盘、对象存储或分布式文件系统

File System

文件系统和内核 I/O 路径

Page Cache 或 Direct I/O Buffer

buffered I/O 或 O_DIRECT

User-space Runtime

推理框架或模型加载器

Tensor Metadata Parsing

解析 safetensors / checkpoint metadata

CPU Tensor Buffer / Pinned Memory

准备 H2D 的 CPU 侧 buffer

GPU HBM

最终进入 GPU 显存

优化目标是：

减少拷贝；
减少 page fault 抖动；
提高 I/O 并行度；
匹配 NUMA；
避免 page cache 污染；
让 GPU 尽早拿到可用权重。

常见手段：

相比复杂 pickle 反序列化，结构化、连续、可 mmap 的权重格式更容易做按需加载和并行加载。

使用 safetensors 等更易 mmap 的格式。

大模型通常有多个 shard，可以多线程并行读取，但不要超过磁盘队列和 CPU 解码能力，不要造成 page cache 抖动，不要跨 NUMA 搬运数据。

并行加载 shard。

CPU 到 GPU 拷贝建议使用 pinned memory，这样 DMA 更高效，也更容易与计算 overlap。

使用 pinned memory 加速 H2D。

GPU 0-3 挂 Socket 0，GPU 4-7 挂 Socket 1 时，权重加载线程也应该分组，避免 Socket 1 读入内存再跨 Socket 给 GPU 0。

做 NUMA-aware loading。

权重只加载一次，可以考虑 Direct I/O、posix_fadvise(DONTNEED)、madvise(DONTNEED)；权重会反复加载或多个进程共享，则 mmap + page cache 可能更合适。

控制 page cache。

面试综合回答模板

I/O 方面，传统 read 路径通常是磁盘 DMA 到 page cache，再 CPU copy 到用户 buffer，如果再加载到 GPU，还要从 CPU buffer 拷贝到 GPU HBM。mmap 可以把文件映射到进程地址空间，减少 page cache 到 user buffer 的一次拷贝，但可能引入 page fault 抖动。Direct I/O 绕过 page cache，适合大文件顺序读和不希望污染 page cache 的场景，但需要处理对齐和缓存管理。sendfile 则适合文件到网络 socket 的零拷贝传输，例如模型权重分发，减少数据进入用户态带来的拷贝和上下文切换。对于大模型权重加载，实际优化要结合 mmap/Direct I/O、并行 shard 加载、pinned memory、NUMA-aware loading 和 page cache 控制综合设计。

Q: mmap、Direct I/O、sendfile 在大模型系统中分别适合哪里？

mmap 适合只读大权重文件、按需加载和多进程共享 page cache；Direct I/O 适合大文件顺序读取、应用自己做缓存且不希望污染 page cache 的场景；sendfile 适合模型权重分发、checkpoint 文件传输或静态文件服务，因为它优化的是文件到 socket 的路径。真正把权重加载进 GPU HBM 时，通常还需要 CPU 侧解析和 H2D 拷贝，sendfile 不是最终一步的主要优化。

面试口径：mmap 优化文件到地址空间，Direct I/O 优化缓存控制，sendfile 优化文件到网络。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

内容模块

分布式与 AI Infra 基础

精通★☆☆⏱ 20 min

一句话结论

Role、Replica、Rank 是分布式训练里三套不同的身份坐标：role 是「干什么活」（worker/ps/chief），replica 是「同一角色的第几个副本」，rank 是「通信世界里的全局编号」。三者不是一回事，把 Pod 名、rank 和业务角色混在一起是排查 hang 和通信错误时最常见的坑。

复习定位

维度	内容
所属模块	分布式 AI 基础
章节类型	概念类
解决问题	围绕 role/replica/rank、通信存储、GPU/NPU 可观测性建立分布式训练和推理基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

Role、Replica、Rank

分布式训练里，role 描述职责，replica 描述副本编号，rank 描述通信世界中的全局身份。不要把 Pod 名称、rank 和业务角色混为一谈。

概念	含义	例子
Role	任务角色	worker、ps、chief、evaluator
Replica	同一角色下的副本	worker-0、worker-1
Global Rank	通信全局编号	DDP world 中 rank 0..N-1
Local Rank	节点内编号	一台 8 卡机器 local_rank 0..7

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

分布式训练有三条不同的数据通路：控制面走 RPC 传任务和状态、训练数据面走 NCCL/RDMA 传梯度和参数、存储数据面走对象存储/分布式 FS 传样本和 checkpoint。三者的瓶颈和优化手段完全不同，排查性能问题时要先判断卡在哪条面上，别用一套思路套全部。

复习定位

维度	内容
所属模块	分布式 AI 基础
章节类型	机制类
解决问题	围绕 role/replica/rank、通信存储、GPU/NPU 可观测性建立分布式训练和推理基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

控制面、训练数据面、存储数据面

链路	技术	传输内容	核心指标	瓶颈
控制面	HTTP/gRPC/Thrift	任务提交、状态、心跳	延迟、可用性	超时、重试、限流
训练数据面	NCCL、RDMA、NVLink	梯度、参数、激活值	带宽、同步耗时	拓扑差、拥塞、慢 rank
存储数据面	对象存储、分布式 FS、NVMe	样本、checkpoint、权重	吞吐、IOPS、元数据性能	小文件、启动风暴、并发写

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

GPU-Util 只说明采样窗口内 GPU「有没有在忙」，不等于算力用满、更不等于吞吐高。真正判断 GPU 是否高效，要同时看显存、SM Active、Tensor Core 利用率、HBM 带宽、NCCL 通信占比和端到端吞吐——只盯 GPU-Util 是最常见的误判。

复习定位

维度	内容
所属模块	分布式 AI 基础
章节类型	排障诊断类
解决问题	围绕 role/replica/rank、通信存储、GPU/NPU 可观测性建立分布式训练和推理基础答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

GPU 观测不要只看 GPU-Util

GPU-Util 表示采样窗口内 GPU 是否忙，不等于 Tensor Core 用满，也不等于模型吞吐高。排查要同时看显存、拓扑、SM Active、HBM、NCCL、数据加载和端到端吞吐。

目标	看什么	工具
设备可见性	GPU 数量、型号、UUID	`nvidia-smi -L`
显存	used/free、进程占用	`nvidia-smi`、框架 summary
拓扑	GPU-GPU、GPU-NIC	`nvidia-smi topo -m`
计算效率	SM Active、Tensor Core、MFU	DCGM、Nsight、Profiler

Q: GPU-Util 100% 但训练很慢，可能是什么原因？

可能是小 kernel 连续运行但算力利用低，或通信 kernel 占比高，或 HBM/PCIe/NVLink 瓶颈，或数据加载间歇造成 pipeline 不稳。应看 timeline、SM Active、Tensor Core 利用率、NCCL 时间和端到端吞吐。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

内容模块

编程语言与工程基础

进阶★★☆⏱ 30 min

一句话结论

一份源码要变成能跑的进程，要走预处理、编译、汇编、链接、加载五个阶段，每个阶段产物和典型报错都不同；AI Infra 里最常踩的坑是链接和加载阶段的「符号找不到」「缺动态库」，定位口诀是 ldd 看依赖、nm/readelf 看符号、strace 看加载。

复习定位

维度	内容
所属模块	编程与系统工程基础
章节类型	概念类
解决问题	围绕编译链接、C++、内存、智能指针、调试和工程排障建立系统编程答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

从源码到进程

阶段	输入	输出	常见问题	工具
预处理	源码、头文件、宏	.i	宏/头文件错误	`gcc -E`
编译	预处理结果	汇编	优化导致行为变化	`gcc -S`
汇编	汇编	.o	指令集不兼容	`objdump`
链接	.o 和库	ELF/.so	符号找不到	`ldd`、`nm`、`readelf`
加载	ELF	进程	缺动态库、权限错误	`strace`

Q: 程序在本机能跑，容器里报缺库，怎么排查？

先用 ldd binary 看动态库依赖，再检查容器内是否存在对应 .so 和版本；检查 LD_LIBRARY_PATH、基础镜像、glibc/libstdc++ 版本和 CUDA/cuDNN/NCCL 版本。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

编译四阶段是预处理、编译、汇编、链接，分别产出 .i/.s/.o 和可执行文件；配套要记三件事——静态库整体复制进可执行文件、动态库运行时加载且多进程共享，智能指针 unique/shared/weak 分别对应独占/共享/打破循环引用，多线程卡死用 gdb attach 后 info threads + bt 看各线程卡在哪个锁。

复习定位

维度	内容
所属模块	编程与系统工程基础
章节类型	机制类
解决问题	围绕编译链接、C++、内存、智能指针、调试和工程排障建立系统编程答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

源码到可执行文件：编译四阶段

阶段	做什么	命令	产物
预处理	宏替换、头文件展开、条件编译、移除注释	`g++ -E source.cpp -o source.i`	.i
编译	语法分析（生成 AST）、语义分析、中间代码生成、优化、生成汇编	`g++ -S source.i -o source.s`	.s
汇编	把汇编指令转成机器指令，生成目标文件（代码+数据的二进制）	`g++ -c source.s -o source.o`	.o
链接	符号解析（引用关联到定义）、重定位（符号引用替换为实际地址）	`g++ source.o -o source`	可执行文件 / 库

打包静态库：ar rcs libxxx.a a.o b.o；生成动态库：g++ -shared -o libxxx.so a.o b.o。

静态库 vs 动态库

维度	静态库 .a	动态库 .so
链接时机	编译链接时整体复制进可执行文件	运行时动态加载
可执行文件体积	变大（含库代码）	较小（不含库代码）
运行依赖	不依赖外部库	运行时需要找到对应 .so
更新维护	库更新要重新编译链接	替换 .so 即可，多进程共享一份

AI Infra 场景：CUDA / cuDNN / NCCL 多以动态库分发，常见报错是运行时找不到 .so 或版本不匹配，用 ldd 排查依赖、检查 LD_LIBRARY_PATH。

智能指针需要包含哪些要素

类型	语义	用途
unique_ptr	独占式，同一时间只有一个指针指向对象	明确单一所有权，零开销
shared_ptr	共享式，多个指针共享同一对象，引用计数	共享所有权
weak_ptr	弱引用，不增加引用计数	解决 shared_ptr 循环引用导致的内存无法释放

自己实现一个引用计数智能指针，要包含的要素：

原始指针：指向被管理对象。
计数器：跟踪引用计数。
拷贝构造函数：增加引用计数。
赋值运算符重载：增加新对象引用计数，并减少旧指针的引用计数。
析构函数：引用计数减到 0 时释放资源。

gdb 调试多线程卡死 / 死锁

一个 C++ 多线程程序执行到中间卡住，定位流程：

步骤	命令	作用
1	`gdb attach <pid>`	关联到发生死锁/卡死的进程
2	`info threads`	查看所有线程信息和部分堆栈，找出可疑线程
3	`thread <id>`	切换到具体线程
4	`bt`	查看该线程堆栈，看卡在哪个锁/调用

典型死锁特征：多个线程的 bt 都停在 lock / pthread_mutex_lock 且互相等待。Python 侧大模型训练 hang 常用 py-spy dump 看各线程/各 rank 卡点。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

封装管「隐藏」、继承管「复用」、多态管「同名不同行为」；C++ 的多态分编译期（重载/模板）和运行期（虚函数），运行期靠 vtable 实现——每个含虚函数的类一张虚函数表，对象最前面存一个 vptr 指向它，调用时取 vptr 按固定偏移间接跳转，这也是为什么基类析构必须声明 virtual。

复习定位

维度	内容
所属模块	编程与系统工程基础
章节类型	概念类
解决问题	围绕编译链接、C++、内存、智能指针、调试和工程排障建立系统编程答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

面向对象三大特性：封装、继承、多态

特性	含义	一句话
封装	隐藏实现细节，把数据和操作数据的函数包在一起，对外只暴露接口	对不可信的调用方做信息隐藏，使代码模块化
继承	子类派生自父类，复用父类属性和方法，也可以重写父类方法	实现代码复用和扩展
多态	同一个函数名有多种实现形式	覆盖（重写虚函数）+ 重载（同名不同参）

面试口径：封装管"隐藏"，继承管"复用"，多态管"同名不同行为"。多态在 C++ 里又分编译期多态（重载/模板）和运行期多态（虚函数）。

public / protected / private 访问范围

修饰符	本类成员函数 / 友元	子类成员函数	类的对象（外部）
private	可访问	不可访问	不可访问
protected	可访问	可访问	不可访问
public	可访问	可访问	可访问

注意 private 即使是该类自己的对象也不能直接访问（只能通过成员函数/友元）。

三种继承方式与属性变化

继承方式	父类成员在子类中的属性变化
private 继承	父类的所有方法在子类中变为 private
protected 继承	父类的 protected 和 public 方法在子类中变为 protected，private 不变
public 继承	父类中的方法属性不发生改变（最常用，表达 "is-a" 关系）

虚函数与虚函数表

虚函数：C++ 中虚函数的作用主要是实现运行期多态。用父类型别的指针指向其子类实例，然后通过父类指针调用，实际会调用子类重写的成员函数。

虚函数表（vtable）：每个包含虚函数的类都存在一个函数地址数组。当用父类指针操作子类对象时，这张虚函数表指明实际应调用的函数。C++ 编译器保证虚函数表指针（vptr）位于对象实例最前面的位置，这样通过对象地址就能拿到 vtable，遍历其中函数指针并调用相应函数。

class Base {
public:
  virtual void run() { /* ... */ }   // 虚函数
  virtual ~Base() {}                  // 基类析构通常要声明 virtual
};

class Derived : public Base {
public:
  void run() override { /* 子类实现 */ }
};

Base* p = new Derived();
p->run();        // 运行期通过 vtable 调用 Derived::run
delete p;        // 因为 ~Base 是 virtual，能正确调用 Derived 析构

面试常追问：vptr 在对象内存布局最前面；每个类一张 vtable，对象实例只存一个 vptr 指向它；基类析构不声明 virtual，用基类指针 delete 子类对象会导致子类析构不被调用，造成资源泄漏。

Q: 虚函数调用是怎么在运行期确定实际函数的？

编译器为每个含虚函数的类生成一张虚函数表（vtable），表里是该类各虚函数的实际地址。每个对象实例最前面存一个虚指针（vptr）指向所属类的 vtable。通过基类指针调用虚函数时，编译器生成的代码会先取对象的 vptr，再到 vtable 中按固定偏移找到函数地址间接调用，从而在运行期分派到正确的实现。

Q: 重载（overload）和重写（override）的区别？

重载是同一作用域内多个同名函数，参数表不同，编译期根据实参类型静态决议，属于编译期多态。重写是子类重新定义父类的虚函数，函数签名相同，运行期通过 vtable 动态分派，属于运行期多态。还有一个 hiding（隐藏）：子类定义了同名非虚函数会隐藏父类同名函数，与重写不同。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

进程地址空间从高到低是栈、mmap 区、堆、.bss、.data、.text，栈向下、堆向上、中间是动态映射区；理解这套布局能解释三件高频考点——为什么 mmap 能高效加载几十 GB 大模型权重（按需分页+减少拷贝）、为什么数组越界有时立即 core 有时「带病运行」（取决于越界地址是否触发页错误）、以及怎么用 ASan/Valgrind 配合 RAII 防住内存泄漏。

复习定位

维度	内容
所属模块	编程与系统工程基础
章节类型	机制类
解决问题	围绕编译链接、C++、内存、智能指针、调试和工程排障建立系统编程答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

程序内存分布（从高地址到低地址）

区域	内容	特点
命令行参数 / 环境变量	argv、environ	最高地址
栈 stack	函数局部变量、调用帧、返回地址	向下增长，自动分配/释放，容量有限
↓ ... ↑（中间空洞）	mmap 区域常落在这里	栈向下、堆向上，中间是动态映射区
堆 heap	malloc / new 动态分配	向上增长，手动管理，易泄漏
.bss	未初始化的全局/静态变量	运行时清零，不占文件体积
.data	已初始化的全局/静态变量	程序运行自动加载
.text（常量区 + 代码区）	只读数据、机器指令	最低地址，只读，写入会段错误

mmap 内存映射：加载大模型权重的关键

mmap 把一个文件映射到进程地址空间，使文件内容直接成为进程内存的一部分，可以用指针操作而不需要显式 read/write。加载大模型权重（动辄几十 GB）时优势明显：

按字节随机访问：对权重等二进制数据的随机访问更直观，用指针偏移代替复杂的文件偏移量管理。
按需分页加载：mmap 不是一次性把整个文件读入内存，而是根据访问位置分块（逐页）加载，因此能在有限内存里处理远大于内存的模型文件。
减少数据拷贝：传统 read 要把数据从内核缓冲区拷到用户缓冲区；mmap 直接把文件页映射进地址空间，省掉这一次拷贝，提升访问速度。

面试口径：mmap = 文件直接映射进地址空间 + 按需分页 + 减少拷贝，是 llama.cpp 等推理框架快速加载大权重的常用手段。

数组越界：为什么有时立即 core dump、有时过一会才崩

段错误（Segmentation Fault）是虚拟内存管理系统在检测到非法内存访问时触发的。是否立即崩溃，取决于越界落到的地址是否是"非法地址"：

访问不存在的内存空间（进程地址空间以外的未映射页）→ 立即触发段错误。
访问没有权限的内存空间（如内核地址）→ 立即段错误。
写入只读内存段（如 .text 代码段）→ 立即段错误。
但如果越界后访问的地址仍落在已映射的合法页内（例如同一页里相邻的堆数据、缓冲区溢出但没跨页），硬件不会报错，程序会"带病运行"，直到后续某次访问真正踩到非法页或破坏的数据导致逻辑崩溃，才"过一会儿"core dump。

所以越界是否立即崩溃，本质是"越界地址是否触发了内存页错误/段错误"，而不是"是否越界"。这也是越界 bug 难定位的原因——崩溃点往往不是真正出错的地方。

内存泄漏检测：工具与原理

工具	平台	原理	开销
Valgrind	Linux / macOS	动态二进制插桩：在虚拟 CPU 上运行程序，把每条指令翻译并插入检查逻辑，跟踪每次分配/释放/访问，检测越界、未初始化读、重复释放、泄漏	慢 10–20×
AddressSanitizer (ASan)	GCC / Clang	编译期插桩 + 影子内存（shadow memory）：编译时在内存访问前插入检查，用影子内存标记每个字节是否可访问	慢 2–3×（远低于 Valgrind）
VS CRT 调试	Windows	`_CrtDumpMemoryLeaks` 在程序结束时报告泄漏	低

# Valgrind
valgrind --leak-check=yes ./your_program

# AddressSanitizer：编译时加 flag
g++ -fsanitize=address -g main.cpp -o main

如何避免内存泄漏：①用智能指针（unique_ptr / shared_ptr）让内存随作用域自动释放；②异常安全，用 RAII 把资源生命周期绑定到对象生命周期，异常时析构自动释放，避免 try-catch 里手动 free 遗漏。

Q: Valgrind 和 AddressSanitizer 的核心区别是什么？

Valgrind 是运行时动态二进制插桩，不需要重新编译，把程序跑在自带虚拟 CPU 上逐指令检查，覆盖全但慢 10–20×。ASan 是编译期插桩，需要加 -fsanitize=address 重新编译，靠影子内存在访问前快速判定，开销只有 2–3×，更适合在 CI 和日常开发中常态化开启。

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。

一句话结论

C++ 在 AI Infra 里占据 Python 之下的性能关键路径——训练框架、推理引擎、通信库、算子 runtime 都靠它扛吞吐，所以面试 C++ 的考点也都围绕这条路径：RAII/智能指针管资源、move/allocator 抠内存性能、mutex/atomic 做并发、动态库/ABI 处理链接加载、perf/gdb/sanitizer 做性能排障。

复习定位

维度	内容
所属模块	编程与系统工程基础
章节类型	概念类
解决问题	围绕编译链接、C++、内存、智能指针、调试和工程排障建立系统编程答案。
面试抓手	先讲定义，再讲链路，最后讲 AI Infra 中如何使用或排障。

C++ 在 AI Infra 中为什么重要

训练框架、推理引擎、通信库、算子 runtime 和高性能服务里，C++ 常处在 Python 之下的性能关键路径。

高频考点

方向	基础概念	AI Infra 场景
资源管理	RAII、析构、智能指针	CUDA stream、buffer、socket 自动释放
内存性能	move、拷贝、省略、allocator	减少 tensor metadata 拷贝
并发同步	mutex、atomic、condition_variable	调度队列、异步回调
链接加载	动态库、符号、ABI	CUDA/NCCL 插件加载失败
性能排查	perf、gdb、sanitizer	CPU hotspot、死锁、越界、泄漏

关联模块

GPU 硬件与资源共享：提供硬件、显存、互联和利用率诊断基础。
LLM 推理系统 / 分布式训练：提供大模型系统中的实际落点。
Kubernetes / 调度与集群：提供平台、资源和多租户治理语境。
专题综合题 / 论文工作：把基础知识组织成可复述的方案和项目叙事。