AI Infra 学习指南（面试与工业运维版）

一、总体结论（招聘市场真实能力模型）

这些 JD 本质指向一个统一岗位形态： Cloud Native Infrastructure Engineer for AI / LLM platform 核心职责：

运行超大规模 Kubernetes 集群
管理 GPU / HPC 资源
构建自动化交付与运维体系
优化 AI 训练与推理基础设施
做性能调优与可靠性工程
平台工程 + 调度 + 系统优化换句话说：


Kubernetes platform engineer
+ SRE
+ distributed systems
+ GPU cluster infra
+ performance engineer

二、技术能力频率排序（最真实市场权重）

按出现频率从高到低。

第一层（必须掌握，所有岗位共同核心）

1️⃣ Kubernetes（绝对核心中的核心）

几乎 100% 岗位要求。企业级真实要求远不止 “会用”。

架构与核心机制

control plane 组件
kube-apiserver
etcd
scheduler
controller-manager
node runtime
kubelet
container runtime (containerd)
调度流程
controller reconciliation loop

工作负载模型

Pod lifecycle
Deployment / StatefulSet
DaemonSet
Job / CronJob

网络

CNI 原理
Overlay vs Underlay
Service / kube-proxy
Ingress / Gateway
网络策略

存储

CSI
PV / PVC
分布式存储接入（Ceph 等）

集群运维

多集群管理
HA 部署
滚动升级
容量规划
故障排查

高级能力（招聘强烈偏好）

Operator / CRD 开发
scheduler 扩展
kubelet 调优
control plane 性能优化
集群网络调优
GPU 调度
GitOps (ArgoCD / Flux)

平台工程

多租户
quota
RBAC
policy engine (Kyverno / Gatekeeper)

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 Kubernetes 的调度流程，以及如何扩展调度器？	调度流程：1. Pod 创建后进入调度队列；2. Scheduler 通过 API Server 获取待调度 Pod；3. 过滤节点（Predicate）；4. 节点打分（Priority）；5. 绑定 Pod 到最优节点。扩展调度器：使用 Scheduler Framework，开发自定义的 Filter、Score 插件，或者使用 Extender 进行外部扩展。
面试题	如何排查 Pod 处于 CrashLoopBackOff 状态的问题？	1. 查看 Pod 日志：`kubectl logs <pod-name> --previous`；2. 查看 Pod 事件：`kubectl describe pod <pod-name>`；3. 检查资源限制：确认 CPU / 内存配额是否足够；4. 检查健康探针配置：确认 liveness/readiness 探针的配置是否合理；5. 检查容器启动命令：确认启动脚本或命令是否存在错误。
运维故障	Pod 镜像拉取失败（ImagePullBackOff）	1. 检查镜像名称和标签是否正确；2. 验证私有仓库认证：检查 Secret 是否配置正确，使用`kubectl get secret regcred -o yaml`查看；3. 测试节点网络连通性：在节点上手动拉取镜像`docker pull <image-name>`；4. 检查镜像仓库是否可访问：使用`curl`测试仓库 API 端点。
运维故障	DNS 解析失败，Pod 无法通过 Service 名称访问服务	1. 检查 CoreDNS Pod 状态：`kubectl get pods -n kube-system	grep coredns`；2. 检查Pod内的resolv.conf配置：`kubectl exec -- cat /etc/resolv.conf`；3. 检查网络策略：确认是否有NetworkPolicy阻止了对DNS服务的访问；4. 测试DNS解析：`kubectl exec -- nslookup kubernetes.default`；5. 查看CoreDNS日志：`kubectl logs -n kube-system `。
运维故障	节点状态变为 NotReady	1. 检查 kubelet 状态：`systemctl status kubelet`；2. 查看 kubelet 日志：`journalctl -u kubelet -f`；3. 检查节点资源：`kubectl describe node <node-name>`查看内存、磁盘压力；4. 检查容器运行时：确认 containerd 或 docker 是否正常运行；5. 重启 kubelet：`systemctl restart kubelet`。

2️⃣ Linux 系统基础（深度要求）

不是 “会命令”，是内核级理解。

必须掌握

进程模型
内存管理
文件系统
TCP/IP 栈
namespace
cgroup
system call
网络调试
性能分析

常用诊断工具


strace
gdb
perf
tcpdump
wireshark
ebpf

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 Linux 的启动过程	1. 加电自检：BIOS/UEFI 进行硬件检查；2. 引导加载程序：GRUB2 等被加载，显示启动菜单；3. 加载内核：引导程序加载内核和`initramfs`到内存，并解压初始化；4. 初始化进程：内核启动第一个用户空间进程`systemd`（或旧的`init`）；5. 执行目标：`systemd`根据默认 target（如`multi-user.target`或`graphical.target`）启动相应的服务和单元；6. 登录界面：启动 getty 或显示管理器，等待用户登录。
面试题	如何排查 CPU 负载过高的问题？	1. 确认现象：使用`top`或`htop`命令确认整体负载情况，观察`load average`三个值，以及`%Cpu(s)`行，看是用户态高还是内核态高；2. 定位进程：在`top`中按`P`按 CPU 使用率排序，找到最耗 CPU 的进程；使用 `ps aux --sort=-% cpu	head -10`列出前10个最耗CPU的进程；3. 分析进程内部：如果是Java应用，使用`jstack `打印线程栈，或者结合`top -H -p `找到耗CPU的线程，再将线程ID转换为16进制，在`jstack`的输出中搜索；如果是C/C++程序，使用`perf top`或`strace -p `跟踪系统调用和函数调用；4. 结合其他指标：使用`vmstat 1`查看上下文切换次数，用`iostat -x 1` 查看是否因为等待 I/O 导致 CPU 空闲。
运维故障	磁盘空间已满，但找不到大文件	1. 查看已删除但仍被进程占用的文件：`lsof +L1	grep deleted`；2. 清理这些文件对应的进程，或者清空文件内容：`echo "" > /path/to/file`；3. 检查inode是否耗尽：`df -i`，如果inode耗尽，清理大量小文件；4. 清理系统日志：`journalctl --vacuum-size=1G`。
运维故障	内存泄漏，系统内存持续上涨	1. 使用`free -h`查看内存使用情况，`available`字段反映实际可用内存；2. 使用`top`或`htop`查看内存占用高的进程；3. 对于 Java 应用，使用`jmap -histo:live <pid>`查看堆内存使用情况，使用`jstat -gc <pid> 1s`查看 GC 情况；4. 对于 C/C++ 应用，使用`valgrind --leak-check=full ./program`进行内存泄漏检测；5. 内核内存泄漏可以使用`slabtop`查看 slab 分配情况。
运维故障	网络连接超时，无法访问外部服务	1. 检查网络连通性：`ping <ip-address>`；2. 检查端口是否开放：`telnet <ip-address> <port>`或`nc -zv <ip-address> <port>`；3. 检查防火墙规则：`iptables -L -n`或`firewall-cmd --list-all`；4. 检查路由表：`ip route show`；5. 检查 DNS 解析：`nslookup <domain-name>`。

3️⃣ Container 技术

必须理解底层实现：

namespace 隔离
cgroup 资源控制
image layering
runtime (runc / containerd)

企业级要求

镜像安全扫描
镜像仓库管理
容器启动性能
runtime 调优

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 Docker 的架构组成，以及 Docker Daemon、Containerd 和 RunC 之间的关系	Docker Client：用户与 Docker 交互的界面，接收用户命令并通过 REST API 发送给 Docker Daemon；Docker Daemon：常驻后台的进程，负责管理 Docker 对象（镜像、容器、网络、卷），并处理客户端的 API 请求，现代的`dockerd`将容器生命周期管理的工作下放给`containerd`；Containerd：行业标准的容器运行时，负责容器的创建、启动、停止、暂停、销毁等核心操作，通过`containerd-shim`管理每个容器的生命周期，即使`containerd`重启，容器也不会受到影响；RunC：轻量级的符合 OCI 标准的容器运行时工具，负责根据 OCI 规范真正创建和运行容器，`containerd`在需要启动容器时会调用`runc`命令。
面试题	如何优化 Docker 镜像的大小？	1. 使用多阶段构建：分离开发依赖与生产代码，只将生产需要的文件复制到最终镜像；2. 使用轻量级基础镜像：如`alpine`替代`ubuntu`；3. 减少镜像层数：合并`RUN`命令，清理包管理器缓存；4. 使用`.dockerignore`文件：排除不需要的文件和目录；5. 镜像分层复用：利用 Docker 的镜像缓存机制，将变化少的层放在前面。
运维故障	容器启动后立即退出（Exited (1)）	1. 查看容器日志：`docker logs <container-id>`；2. 检查容器启动命令：确认`CMD`或`ENTRYPOINT`配置是否正确；3. 检查端口冲突：确认容器要使用的端口是否被宿主机或其他容器占用；4. 检查资源限制：确认容器的 CPU / 内存限制是否足够；5. 以交互模式启动容器调试：`docker run -it <image-name> sh`。
运维故障	容器间无法通信	1. 检查容器是否在同一个网络：`docker network ls`，`docker network inspect <network-name>`；2. 检查容器的 IP 地址：`docker inspect	grep IPAddress`；3. 测试容器间的连通性：在一个容器中`ping `；4. 检查防火墙规则：确认宿主机的防火墙是否阻止了容器间的通信；5. 检查 CNI 插件：如果是 Kubernetes 环境，检查 CNI 插件（如 Calico、Flannel）是否正常运行。
运维故障	Docker 内存泄漏，宿主机内存持续上涨	1. 查看容器资源使用情况：`docker stats`；2. 检查容器内的进程：`docker exec <container-id> ps aux`；3. 对于 Java 应用，设置合理的 JVM 参数：`-Xms`和`-Xmx`，并使用`-XX:+UseContainerSupport`让 JVM 感知容器的内存限制；4. 限制容器的内存使用：`docker run -m 512m <image-name>`；5. 清理未使用的容器、镜像和卷：`docker system prune -a`。

4️⃣ DevOps / CI/CD / Platform Engineering

企业全部要求自动化交付。

必须掌握

pipeline 设计
artifact 管理
GitOps
环境管理

常见工具


Jenkins
GitLab CI
ArgoCD
Tekton
Helm
Kustomize
Terraform
Ansible

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 CI/CD 的流程，以及如何设计一个高可用的 CI/CD 流水线	CI/CD 流程：1. 开发人员提交代码到 Git 仓库；2. 触发 CI 流水线：自动构建代码、运行单元测试、构建镜像；3. 镜像扫描：扫描镜像中的漏洞；4. 部署到测试环境：自动部署到测试环境进行集成测试；5. 手动或自动批准后部署到生产环境：使用蓝绿部署、金丝雀部署等策略。高可用流水线设计：1. 多区域部署流水线组件，避免单点故障；2. 使用分布式构建节点，提高构建能力；3. 缓存依赖，减少构建时间；4. 实现流水线的监控和告警，及时发现失败的流水线；5. 实现回滚机制，当部署失败时可以快速回滚到上一个稳定版本。
面试题	什么是 GitOps，它的优势是什么？	GitOps 是一种基于 Git 的运维方法，将基础设施和应用的配置存储在 Git 仓库中，通过 Git 的版本控制和 PR 流程来管理基础设施和应用的变更。优势：1. 审计追踪：所有的变更都有记录，可以追溯到具体的提交和人员；2. 回滚简单：如果变更出现问题，可以快速回滚到上一个稳定的版本；3. 协作性好：开发人员可以通过 PR 流程参与基础设施的变更；4. 一致性：确保所有环境的配置都是一致的，避免配置漂移。
运维故障	Jenkins 构建失败，提示依赖拉取超时	1. 检查网络连通性：确认 Jenkins 节点可以访问依赖仓库；2. 配置镜像源：将依赖仓库替换为国内镜像源，如 Maven 的阿里云镜像源；3. 配置依赖缓存：在 Jenkins 中配置本地缓存，或者使用代理缓存依赖；4. 增加构建超时时间：在 Jenkins 的构建配置中增加超时时间；5. 检查依赖仓库的状态：确认依赖仓库是否正常运行。
运维故障	部署到 Kubernetes 时，Pod 一直处于 Pending 状态	1. 查看 Pod 事件：`kubectl describe pod <pod-name>`，确认是否是资源不足、调度失败或 PVC 绑定失败；2. 检查节点资源：`kubectl describe node <node-name>`，查看节点的 CPU、内存和存储资源是否充足；3. 检查 PVC 状态：`kubectl get pvc <pvc-name>`，确认 PVC 是否已经绑定到 PV；4. 检查调度策略：确认 Pod 的 nodeSelector、affinity 等调度策略是否匹配节点的标签；5. 检查污点和容忍：`kubectl describe node	grep Taint`，确认 Pod 是否有对应的容忍。
运维故障	Terraform apply 失败，提示资源已存在	1. 检查 Terraform 状态文件：`terraform state list`，确认资源是否已经在状态文件中；2. 导入已存在的资源：`terraform import <resource-type> <resource-id>`，将已存在的资源导入到 Terraform 的状态文件中；3. 清理状态文件：如果资源已经不存在，可以使用`terraform state rm <resource-type> <resource-id>`从状态文件中移除；4. 检查 Terraform 配置：确认配置文件中的资源名称和参数是否正确。

5️⃣ Observability / SRE 体系

所有岗位强调稳定性。

三大信号

metrics
logs
tracing

体系设计

SLI / SLO / SLA
alerting
capacity planning
incident response
RCA

常用组件


Prometheus
Grafana
ELK
OpenTelemetry
Alertmanager

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 SLI、SLO 和 SLA 的区别，以及如何为一个 API 服务设计 SLI 和 SLO	SLI（服务水平指标）：衡量服务性能的具体指标，如 API 的响应时间、成功率；SLO（服务水平目标）：对 SLI 的目标值，如 API 的 99% 请求响应时间小于 200ms，成功率大于 99.9%；SLA（服务水平协议）：与客户签订的协议，包含 SLO 的承诺以及未达到承诺的赔偿条款。API 服务的 SLI 和 SLO 设计：1. 选择关键的 SLI：如请求成功率、P99 响应时间、可用性；2. 设置合理的 SLO：根据历史数据和业务需求，设置可实现的目标，如成功率 SLO 为 99.9%，P99 响应时间 SLO 为 200ms；3. 监控 SLI：使用 Prometheus 等工具收集 SLI 数据；4. 告警：当 SLI 接近 SLO 阈值时触发告警，及时处理问题。
面试题	如何排查一个间歇性的 API 超时问题，传统监控无法发现问题	1. 启用分布式追踪：使用 OpenTelemetry 等工具对 API 请求进行全链路追踪，查看请求在每个环节的耗时；2. 增加日志粒度：在 API 的关键环节增加日志，记录请求的参数、耗时和返回结果；3. 分析基础设施指标：查看服务器的 CPU、内存、磁盘 I/O 和网络指标，是否存在资源瓶颈；4. 进行压力测试：模拟高并发场景，重现问题；5. 使用 eBPF 工具：如`bpftrace`，跟踪系统调用和内核事件，发现潜在的问题。
运维故障	告警风暴，大量告警导致关键告警被淹没	1. 告警分级：将告警分为 P0（紧急）、P1（高）、P2（中）、P3（低），不同级别的告警使用不同的通知方式；2. 告警聚合：将相关的告警合并为一个根因告警，避免重复告警；3. 调整告警阈值：根据历史数据调整告警阈值，减少误报；4. 告警降噪：过滤掉不必要的告警，如测试环境的告警；5. 实现自动化处理：对于常见的告警，实现自动化处理脚本，自动恢复服务。
运维故障	日志聚合系统（ELK）性能下降，查询缓慢	1. 检查 Elasticsearch 的资源使用情况：查看 CPU、内存和磁盘 I/O，是否存在资源瓶颈；2. 优化索引策略：设置合理的索引生命周期，定期删除旧的索引；3. 优化查询语句：避免使用通配符开头的查询，使用过滤条件减少查询的数据量；4. 增加 Elasticsearch 节点：横向扩展 Elasticsearch 集群，提高处理能力；5. 优化分片和副本数量：根据数据量调整分片和副本的数量，提高查询性能。
运维故障	分布式追踪系统无法追踪到完整的请求链路	1. 检查追踪工具的配置：确认 OpenTelemetry 等工具是否正确配置，是否在所有服务中都启用了追踪；2. 检查 Trace ID 的传递：确认 Trace ID 在服务间的传递是否正确，是否在 HTTP 头、消息队列中传递了 Trace ID；3. 检查采样率：确认采样率是否设置过低，导致部分请求没有被追踪；4. 检查服务的日志：确认服务的日志中是否包含 Trace ID，以便关联日志和追踪数据；5. 检查网络连通性：确认追踪数据可以正常发送到追踪后端。

6️⃣ 编程能力（平台开发级别）

最常见：

Go（云原生首选）
Python（自动化）
Shell（运维）

高级岗位要求

控制器开发
调度器插件
infra 工具开发

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 Go 语言的 goroutine 和 channel 的工作原理，以及如何避免 goroutine 泄漏	goroutine 是 Go 语言的轻量级线程，由 Go 运行时管理，goroutine 的调度由 Go 的调度器完成，使用 M-P-G 模型。channel 是 goroutine 之间的通信机制，用于在 goroutine 之间传递数据。避免 goroutine 泄漏：1. 使用`context.Context`控制 goroutine 的生命周期，当 context 取消时，goroutine 可以退出；2. 确保 channel 的发送和接收操作不会阻塞，使用带缓冲的 channel 或者`select`语句处理超时；3. 监控 goroutine 的数量：使用`runtime.NumGoroutine()`查看 goroutine 的数量，及时发现泄漏；4. 避免在 goroutine 中执行无限循环，确保有退出条件。
面试题	如何优化 Python 脚本的性能	1. 使用更高效的数据结构：如使用`set`替代`list`进行成员检查；2. 避免使用全局变量：全局变量的访问速度比局部变量慢；3. 使用生成器：使用生成器表达式替代列表推导式，减少内存占用；4. 并行处理：使用`multiprocessing`或`asyncio`进行并行处理，提高处理速度；5. 使用 C 扩展：对于性能敏感的部分，使用 Cython 或 C 扩展来提高性能；6. 避免循环嵌套：减少循环的嵌套层数，降低时间复杂度。
运维故障	Go 服务 CPU 使用率 100%，无法正常处理请求	1. 使用`pprof`工具分析 CPU 使用情况：`go tool pprof http://<service-ip>:6060/debug/pprof/profile`，查看占用 CPU 高的函数；2. 检查是否存在死循环：查看代码中是否有无限循环的逻辑；3. 检查锁竞争：使用`pprof`查看是否存在锁竞争，使用`sync.Map`替代`map`减少锁竞争，或者使用分片锁；4. 检查 GC 压力：使用`pprof`查看 GC 的情况，减少短生命周期对象的创建，使用`sync.Pool`复用对象；5. 优化代码逻辑：减少不必要的计算和内存分配。
运维故障	Python 脚本内存泄漏，内存占用持续上涨	1. 使用`memory_profiler`工具分析内存使用情况：给函数添加`@profile`装饰器，运行脚本查看内存变化；2. 检查是否有未释放的资源：如文件、网络连接、数据库连接，使用`with`语句自动释放资源；3. 检查是否有全局变量持有大量数据：避免使用全局变量存储大量数据，及时清理不再使用的变量；4. 检查是否有循环引用：使用`gc`模块查看循环引用，手动打破循环引用；5. 使用生成器替代列表：减少内存占用。
运维故障	Shell 脚本执行失败，提示权限不足	1. 检查脚本的权限：`ls -l <script-name>`，确认脚本是否有执行权限；2. 添加执行权限：`chmod +x <script-name>`；3. 检查脚本中的命令是否有足够的权限：确认脚本中执行的命令是否需要 sudo 权限，如果需要，在脚本中添加 sudo 或者以 root 用户运行脚本；4. 检查文件路径：确认脚本中引用的文件路径是否正确，是否有访问权限。

第二层（AI infra 关键能力）

这是你目标方向的分水岭。

7️⃣ GPU / HPC 集群基础设施

招聘非常集中。

必须掌握

GPU 资源管理
多 GPU 通信
集群拓扑
分布式训练架构

关键技术


CUDA
NCCL
RDMA
InfiniBand
RoCE
parallel filesystem

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 NCCL 的工作原理，以及如何排查 NCCL 通信超时的问题	NCCL（NVIDIA Collective Communications Library）是 NVIDIA 的集体通信库，用于在多 GPU 之间进行高效的数据通信，支持 allreduce、allgather、broadcast 等操作。NCCL 使用环形拓扑或树形拓扑进行数据通信，以提高通信效率。排查 NCCL 通信超时：1. 检查网络连接：使用`ibstatus`检查 InfiniBand 网络状态，使用`ping`测试节点间的网络连通性；2. 检查 GPU 驱动版本：确认所有节点的 GPU 驱动版本一致；3. 检查 NCCL 配置：设置`NCCL_DEBUG=INFO`，查看 NCCL 的日志，定位问题；4. 检查资源使用情况：确认节点的 CPU、内存和网络带宽是否充足；5. 调整 NCCL 参数：如设置`NCCL_TIMEOUT`增加超时时间，使用`NCCL_IB_DISABLE=1`禁用 InfiniBand，使用 TCP 通信。
面试题	如何管理大规模 GPU 集群的资源，提高 GPU 的利用率	1. 使用集群调度器：如 Slurm、Kubernetes，合理分配 GPU 资源；2. 实现资源共享：使用`nvidia-cuda-mps`实现多进程共享 GPU 资源；3. 动态资源调整：根据任务的需求动态调整 GPU 资源，如使用弹性训练框架，自动调整 worker 数量；4. 监控 GPU 使用情况：使用 DCGM（Data Center GPU Manager）监控 GPU 的使用率、温度、显存使用情况；5. 资源隔离：使用 cgroup 或容器技术隔离 GPU 资源，避免不同任务之间的干扰。
运维故障	GPU 掉卡，系统无法识别 GPU	1. 检查 GPU 物理连接：关机后重新插拔 GPU 卡，确认金手指无氧化；2. 检查电源供电：使用万用表检测 GPU 专用供电接口电压（通常为 12V/8Pin），确认电源功率是否足够；3. 检查 GPU 驱动：使用`nvidia-smi`查看驱动状态，重新安装 GPU 驱动；4. 检查系统日志：`dmesg	grep NVRM` 查看 GPU 相关的日志，定位问题；5. 检查硬件故障：如果以上方法都无法解决，可能是 GPU 硬件故障，需要更换 GPU。
运维故障	GPU 温度过高，触发降频保护	1. 检查散热系统：清理 GPU 风扇和散热器的灰尘，确认风扇是否正常运转；2. 检查机房温度：确认机房的空调是否正常工作，机房温度是否在合理范围内；3. 调整 GPU 功耗：使用`nvidia-smi -pl <power-limit>`降低 GPU 的功耗，减少热量产生；4. 优化任务负载：减少 GPU 的负载，避免长时间满负荷运行；5. 更换散热硅脂：如果散热硅脂干涸，更换新的散热硅脂，提高散热效果。
运维故障	分布式训练任务卡住，无错误日志	1. 检查网络连接：确认节点间的网络连通性，使用`ibping`测试 InfiniBand 网络；2. 检查 GPU 状态：使用`nvidia-smi`查看 GPU 的状态，确认 GPU 是否正常工作；3. 检查 NCCL 日志：设置`NCCL_DEBUG=INFO`，查看 NCCL 的日志，定位通信问题；4. 检查任务配置：确认分布式训练的配置是否正确，如`world_size`、`rank`等参数是否正确；5. 检查节点资源：确认节点的 CPU、内存和磁盘空间是否充足。

8️⃣ AI 训练与推理架构（infra 视角）

不是算法工程，而是系统工程。

训练并行策略

data parallel
tensor parallel
pipeline parallel
expert parallel (MoE)

推理优化

batching
memory 管理
latency 优化

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述数据并行、张量并行和流水线并行的区别，以及它们的适用场景	数据并行：将数据分成多个批次，每个 GPU 处理一个批次的数据，计算梯度后进行梯度聚合，适用于模型较小，数据量较大的场景；张量并行：将模型的参数分成多个部分，每个 GPU 负责一部分参数的计算，适用于模型较大，单 GPU 无法容纳整个模型的场景；流水线并行：将模型的层分成多个阶段，每个 GPU 负责一个阶段的计算，数据在 GPU 之间流水线式传递，适用于模型非常大，层数很多的场景。
面试题	如何优化大模型推理的性能，降低延迟和提高吞吐量	1. 使用 KV Cache：缓存已计算的 Key 和 Value 矩阵，避免重复计算，减少计算量；2. 使用量化：将模型参数从 FP16 量化为 INT8 或 FP8，减少显存占用和计算量；3. 使用连续批处理（Continuous Batching）：动态调整批处理大小，提高 GPU 的利用率；4. 使用推理引擎：如 vLLM、TensorRT-LLM，优化推理性能；5. 模型压缩：使用剪枝、蒸馏等方法压缩模型，减少模型大小和计算量；6. 优化内存管理：使用 PagedAttention 等技术，减少显存碎片化，提高显存利用率。
运维故障	大模型推理时显存不足（OOM）	1. 使用量化：将模型参数量化为更低精度，如 INT8，减少显存占用；2. 减少批处理大小：降低推理的 batch size，减少显存使用；3. 使用 KV Cache 优化：使用 PagedAttention 等技术，减少 KV Cache 的显存占用；4. 模型并行：将模型分成多个部分，在多个 GPU 上进行推理；5. 优化推理引擎：使用 vLLM 等推理引擎，优化显存管理。
运维故障	大模型推理延迟过高，响应缓慢	1. 使用连续批处理：使用 vLLM 等推理引擎的连续批处理技术，提高 GPU 的利用率；2. 优化 KV Cache：使用 KV Cache 的压缩技术，减少 KV Cache 的显存占用，提高访问速度；3. 减少上下文长度：限制推理的上下文长度，减少计算量；4. 使用更快的硬件：使用更高性能的 GPU，如 H100，提高推理速度；5. 优化模型结构：使用更高效的模型结构，如 Flash Attention，减少计算量。
运维故障	训练过程中 Loss 值出现 NaN	1. 检查数据：确认训练数据中是否有异常值，如 NaN、无穷大等，清理异常数据；2. 调整学习率：学习率过高可能导致梯度爆炸，出现 NaN，降低学习率；3. 梯度裁剪：使用梯度裁剪，限制梯度的范围，避免梯度爆炸；4. 检查模型参数：确认模型参数是否有异常值，如 NaN；5. 混合精度训练：使用混合精度训练时，检查是否有溢出问题，调整`amp`的配置。

9️⃣ 推理引擎与缓存机制

JD 中明确出现。

KVCache（重点）

本质： Transformer 推理中缓存 attention key/value 避免重复计算作用：


降低计算量
降低延迟
提升吞吐

企业级优化关注

cache memory layout
eviction 策略
GPU 显存管理
prefix sharing
paged KVCache

典型场景


vLLM
TensorRT-LLM
SGLang

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述 KV Cache 的工作原理，以及为什么缓存的是 K 和 V 而不是 Q	KV Cache 是在大模型推理时，缓存已计算的 Key 和 Value 矩阵，避免在生成每个新 token 时重复计算所有历史 token 的 K 和 V。在自回归生成过程中，生成第 t 个 token 时，只需要当前 token 的 Q，以及所有历史 token 的 K 和 V，因此缓存 K 和 V 可以避免重复计算，将计算复杂度从 O (n²) 降低到 O (n)。不需要缓存 Q 是因为每个 token 的 Q 只在生成该 token 时使用，后续生成新 token 时不需要使用之前的 Q。
面试题	如何优化 KV Cache 的显存占用	1. 使用 PagedAttention：将 KV Cache 切分成固定大小的块，按需分配显存，减少显存碎片化；2. 使用量化：将 KV Cache 量化为更低精度，如 INT8，减少显存占用；3. 使用前缀共享：对于相同的前缀，共享 KV Cache，避免重复缓存；4. 使用滑动窗口：只缓存最近的 N 个 token 的 KV Cache，丢弃更早的 KV Cache，限制显存占用；5. 使用 MQA/GQA：让多个 Query Head 共享同一组 Key/Value Head，减少 KV Cache 的显存占用。
运维故障	KV Cache 导致显存碎片化，无法容纳更多的请求	1. 使用 PagedAttention 技术：如 vLLM 中的 PagedAttention，将 KV Cache 切分成块，按需分配显存，减少碎片化；2. 清理无用的 KV Cache：及时清理不再使用的 KV Cache，释放显存；3. 调整块大小：根据请求的长度调整 KV Cache 的块大小，减少内部碎片；4. 使用显存压缩：对 KV Cache 进行压缩，减少显存占用；5. 增加 GPU 显存：升级 GPU，使用更大显存的 GPU。
运维故障	推理时 KV Cache 命中率低，推理速度慢	1. 优化请求调度：将具有相同前缀的请求放在一起处理，提高前缀共享的命中率；2. 调整缓存策略：使用更高效的缓存淘汰策略，如 LRU，提高缓存命中率；3. 增加缓存大小：增加 KV Cache 的大小，缓存更多的历史数据；4. 优化模型结构：使用支持前缀共享的模型结构，提高缓存命中率；5. 减少请求的上下文长度：限制请求的上下文长度，减少 KV Cache 的大小，提高命中率。
运维故障	推理服务的吞吐量低，无法满足大量请求	1. 使用连续批处理：使用 vLLM 等推理引擎的连续批处理技术，动态调整批处理大小，提高 GPU 的利用率；2. 优化 KV Cache：使用 PagedAttention 和量化技术，减少 KV Cache 的显存占用，同时处理更多的请求；3. 水平扩展：增加推理服务的实例数量，处理更多的请求；4. 负载均衡：使用负载均衡器，将请求均匀分配到多个推理实例；5. 优化请求队列：使用高效的请求队列，减少请求的等待时间。

🔟 向量数据库 / RAG 基础设施

频繁出现：


Milvus
Elasticsearch
pgvector

infra 职责

部署
扩展
查询性能调优

高频面试题与工业运维故障

类型	问题 / 故障	解决思路 / 参考答案
面试题	请描述向量数据库的工作原理，以及如何优化向量数据库的查询性能	向量数据库用于存储和查询高维向量数据，通过向量相似度匹配来查找相似的向量。工作原理：1. 向量索引：将向量数据构建成索引，如 IVF、HNSW 等，提高查询效率；2. 向量检索：根据查询向量，在索引中查找相似的向量；3. 结果排序：根据相似度对结果进行排序，返回最相似的向量。优化查询性能：1. 选择合适的索引：根据向量的维度和数据量选择合适的索引，如 HNSW 适合高维向量，IVF 适合大规模数据；2. 调整索引参数：调整索引的参数，如`nlist`、`efConstruction`等，提高索引的质量；3. 量化向量：将向量量化为更低精度，减少存储和计算量；4. 分布式部署：使用分布式向量数据库，如 Milvus 的分布式版本，提高查询性能；5. 缓存查询结果：缓存频繁查询的结果，减少查询时间。
面试题	如何构建一个高可用的 RAG 系统，提高检索的准确性和性能	1. 数据预处理：对文档进行分块、向量化，提高检索的准确性；2. 选择合适的向量数据库：如 Milvus、Elasticsearch，存储向量数据；3. 优化检索策略：使用混合检索，如关键词检索 + 向量检索，提高检索的准确性；4. 缓存检索结果：缓存频繁检索的结果，减少检索时间；5. 监控和告警：监控 RAG 系统的性能和准确性，及时发现问题；6. 动态调整：根据用户的反馈和检索结果，动态调整检索策略和模型参数。
运维故障	向量数据库查询缓慢，响应时间长	1. 检查索引状态：确认向量数据库的索引是否正常，是否需要重新构建索引；2. 调整查询参数：调整查询的参数，如`ef`、`nprobe`等，提高查询的速度；3. 检查资源使用情况：确认向量数据库的 CPU、内存和磁盘 I/O 是否充足，是否存在资源瓶颈；4. 分布式部署：将向量数据库部署在多个节点上，提高查询性能；5. 优化向量数据：对向量数据进行量化、压缩，减少存储和计算量。
运维故障	RAG 系统检索结果不准确，无法找到相关的文档	1. 检查数据预处理：确认文档的分块和向量化是否正确，是否有遗漏的文档；2. 调整检索策略：调整检索的参数，如相似度阈值、检索数量等，提高检索的准确性；3. 优化向量模型：使用更合适的向量模型，如 BERT、Sentence-BERT，提高向量的质量；4. 增加数据多样性：增加更多的文档数据，提高检索的覆盖率；5. 人工审核：对检索结果进行人工审核，调整检索策略和模型参数。
运维故障	向量数据库无法扩容，无法存储更多的向量数据	1. 检查存储容量：确认向量数据库的存储容量是否充足，是否需要扩容存储；2. 分布式部署：将向量数据库部署在多个节点上，分布式存储向量数据；3. 数据归档：将旧的向量数据归档，减少存储压力；4. 优化存储策略：使用压缩、量化等技术，减少向量数据的存储占用；5. 升级硬件：升级向量数据库的硬件，使用更大容量的存储设备。

第三层（高级 infra specialization）

用于进入顶级 AI infra 团队。

11️⃣ Kubernetes 深度扩展

scheduler framework
custom resource orchestration
batch scheduler (Volcano / Kueue)
multi-tenant GPU scheduling

12️⃣ 虚拟化与容器融合

常见：


KVM
QEMU
KubeVirt

目标：统一 VM + container 调度。

13️⃣ 高性能网络

必须理解：


SR-IOV
RDMA
eBPF
DPDK
VXLAN

14️⃣ 分布式存储

常见：


Ceph
Lustre
BeeGFS
Weka

优化重点：

IO 吞吐
metadata 性能
GPU direct storage

15️⃣ FinOps / Resource efficiency

企业极度重视：

GPU 利用率
成本优化
capacity modeling

三、学习优先级路线图（严格推荐顺序）

这是从招聘真实路径反推的。

Phase 1 基础设施底座（必须）

1 Linux internals 2 网络基础 TCP/IP 3 container runtime 4 Kubernetes cluster 运维

Phase 2 平台工程能力

5 CI/CD 6 Observability 7 IaC 8 automation scripting

Phase 3 云原生深水区

9 Kubernetes internal architecture 10 Operator 开发 11 scheduler 机制

Phase 4 AI 集群基础设施

12 GPU 架构 13 distributed training topology 14 HPC network 15 distributed storage

Phase 5 LLM infra specialization

16 inference engine 17 KVCache 优化 18 memory scheduling 19 serving architecture

Phase 6 顶级平台工程

20 cluster scheduling algorithms 21 performance modeling 22 reliability engineering 23 cost optimization

四、精简版能力模型（面试导向）

如果压缩成一句话：


Linux system engineer
+ Kubernetes platform engineer
+ distributed systems engineer
+ GPU cluster engineer
+ LLM inference infrastructure engineer

五、你真正应该先学什么（最关键建议）

如果目标： AI 超大规模集群 infra 正确顺序： 1 Kubernetes 内部原理 2 Linux 内核与网络 3 cluster 调度机制 4 GPU 通信架构 5 LLM 推理引擎 6 KVCache 与 memory 优化很多人顺序是反的。

六、行业真实技术栈（最常出现组合）

典型生产环境：


Kubernetes
+
GPU cluster
+
RDMA network
+
Ceph storage
+
Prometheus observability
+
ArgoCD GitOps
+
vLLM inference

七、你这份 JD 的本质技术方向分类

我帮你归纳为 5 大方向： 1 Cloud Native Platform Engineering 2 AI Compute Infrastructure 3 Distributed System Scheduling 4 Performance Engineering 5 Reliability Engineering

八、如果你想进入顶级 AI infra 团队（真实门槛）

必须具备：

Kubernetes 源码级理解
GPU 集群调优经验
分布式训练架构理解
推理性能优化经验
大规模生产系统运维经验

（注：文档部分内容可能由 AI 生成）

FilesExpand file tree

大模型时代运维找工作指北.md

Latest commit

History

大模型时代运维找工作指北.md

File metadata and controls

AI Infra 学习指南（面试与工业运维版）

一、总体结论（招聘市场真实能力模型）

二、技术能力频率排序（最真实市场权重）

第一层（必须掌握，所有岗位共同核心）

1️⃣ Kubernetes（绝对核心中的核心）

架构与核心机制

工作负载模型

网络

存储

集群运维

高级能力（招聘强烈偏好）

平台工程

高频面试题与工业运维故障

2️⃣ Linux 系统基础（深度要求）

必须掌握

常用诊断工具

高频面试题与工业运维故障

3️⃣ Container 技术

企业级要求

高频面试题与工业运维故障

4️⃣ DevOps / CI/CD / Platform Engineering

必须掌握

常见工具

高频面试题与工业运维故障

5️⃣ Observability / SRE 体系

三大信号

体系设计

常用组件

高频面试题与工业运维故障

6️⃣ 编程能力（平台开发级别）

高级岗位要求

高频面试题与工业运维故障

第二层（AI infra 关键能力）

7️⃣ GPU / HPC 集群基础设施

必须掌握

关键技术

高频面试题与工业运维故障

8️⃣ AI 训练与推理架构（infra 视角）

训练并行策略

推理优化

高频面试题与工业运维故障

9️⃣ 推理引擎与缓存机制

KVCache（重点）

企业级优化关注

典型场景

高频面试题与工业运维故障

🔟 向量数据库 / RAG 基础设施

infra 职责

高频面试题与工业运维故障

第三层（高级 infra specialization）

11️⃣ Kubernetes 深度扩展

12️⃣ 虚拟化与容器融合

13️⃣ 高性能网络

14️⃣ 分布式存储

15️⃣ FinOps / Resource efficiency

三、学习优先级路线图（严格推荐顺序）

Phase 1 基础设施底座（必须）

Phase 2 平台工程能力

Phase 3 云原生深水区

Phase 4 AI 集群基础设施

Phase 5 LLM infra specialization

Phase 6 顶级平台工程

四、精简版能力模型（面试导向）

五、你真正应该先学什么（最关键建议）

六、行业真实技术栈（最常出现组合）

七、你这份 JD 的本质技术方向分类

八、如果你想进入顶级 AI infra 团队（真实门槛）