想象你是一家连锁餐厅的创始人，目标是让全球每一家分店的厨房都完全一致——同样的灶台、同样的燃气管线、同样的锅具摆放。这样，无论顾客走进哪家店，吃到的菜味道都一模一样。AI 训练环境自动配置，做的就是这件事：让每一台 GPU 服务器，都变成规格完全相同的“AI 厨房”。 要训练大模型，就像厨师要开火做菜：先有灶台（GPU 驱动），再通燃气（CUDA），然后备锅具（深度学习框架），三者还必须互相匹配。过去这些全靠在行的工程师手工一台台装——慢、容易出错、换个人就配得不一样。现在，我们用“蓝图 + 检查清单 + 预制模块”这套方法，把环境配置变成代码：谁执行、何时执行、装成什么样，全部可见、可回滚、可复现。 本文就用这条“连锁厨房”的故事线，带你理解基础设施即代码、Ansible 与 Terraform 的分工、版本兼容管理、一致性保障、快速复现和镜像构建最佳实践。

岗位关联

对 AI 从业者而言，把“调环境”从最耗时的苦差变成可版本化、可审计、可复现的代码资产，是从“能跑通模型”走向“能规模化交付模型”的分水岭，也是 MLOps 与 SRE 方向的核心竞争力。

目录
  1. 可视化演示
  2. 基础设施即代码
  3. Ansible 配置管理
  4. Terraform 资源编排
  5. 版本兼容管理
  6. 一致性保障
  7. 快速复现方案
  8. 镜像构建实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示声明式配置加幂等执行的环境构建流程、容器化与虚拟环境方案对比，以及Dockerfile分层镜像构建与缓存复用。

本节配有交互动效（进入视口后自动加载，约 3KB）。

声明式配置与幂等执行 声明期望状态+幂等执行 声明→执行→状态 确保环境可复现、可版本化。

基础设施即代码

你开了一家连锁餐厅，发现每家分店的厨房都不一样——有的灶台型号老，有的燃气管接口不匹配。光靠店长在电话里口头描述“上次是怎么装的”，永远装不出两间相同的厨房。于是总部做了一件事：把“一间标准厨房长什么样”画成图纸，发给每一家分店。图纸上清清楚楚画着灶台型号、燃气管线、锅具清单，谁来了都能照图施工。

这就是“基础设施即代码”（Infrastructure as Code，IaC）的本质：把 AI 训练环境从“老师傅的手艺”变成“一份可读的代码蓝图”。GPU 驱动、CUDA、框架依赖都被写进文本文件，提交到 Git，经过评审、打标签、留历史；任何一台新机器上线，配置引擎照着蓝图把系统改造成目标状态，而不是依赖某个人的记忆。

IaC 有三个支柱。第一是声明式配置：你只声明“要什么”，不写“怎么执行”，引擎自己决定步骤；第二是版本化管理：每次环境变更都有 commit、tag、diff，出问题可以回滚，比“谁改过这台机器”的追问高效一万倍；第三是自动执行引擎：持续对账，发现系统偏离蓝图就自动拉回目标状态。

把环境配置变成图纸，分店开业就不再依赖某个老师傅的记忆。环境从“手艺”变成“资产”，这正是所有自动化流程的起点。

St+1=Apply(St,Config),lim⁡t→∞St=S∗\displaystyle S_{t+1} = \text{Apply}(S_t, \text{Config}), \quad \lim_{t \to \infty} S_t = S^*
这个公式描述“配置收敛”：反复把配置蓝图作用到系统上，系统状态最终稳定在蓝图定义的目标状态 $S^*$。
  1. 系统状态 $S_t$把一台服务器看作一个状态对象，$S_t$ 表示第 $t$ 次操作后的系统实况，例如已装的驱动、已配置的 CUDA 版本。
    StS_t
  2. 执行动作 ApplyConfig 是代码声明的蓝图，Apply 表示配置引擎按蓝图对系统做一次变更。
    Apply(St,Config)\text{Apply}(S_t, \text{Config})
  3. 收敛终点 $S^*$反复 Apply 后系统状态不再变化，即到达蓝图定义的理想状态。
    lim⁡t→∞St=S∗\lim_{t \to \infty} S_t = S^*

Ansible 配置管理

图纸有了，还得有人拿着检查清单逐项落实。Ansible 就是那位严谨的餐厅经理，它手里有两样东西：一份“哪些分店要查”的名单（Inventory 清单），和一本“每间厨房该装什么”的检查手册（Playbook 剧本）。

Ansible 通过 SSH 连上各台服务器，把 Playbook 里的任务逐条执行：装驱动、配 CUDA、装框架、写环境变量。它的特别之处在于“复查逻辑”：先看这一项是不是已经满足，满足了就跳过，不满足才动手。所以同一本手册不管跑多少遍，结果都完全一样——这就是它和“一次性脚本”最本质的区别。

这种“重复执行结果不变”的性质叫幂等（Idempotent）。比如“确保 GPU 驱动已安装”这条任务，第一次会安装，第二次检查到已装就不做任何事。幂等让运维敢放心地反复执行，即使某次执行到一半失败，重跑一遍也能接着完成，而不会把系统搞乱。

就像晚餐前的厨房巡检——经理一遍遍核对清单，装好的打个勾，绝不重复搬动灶台。Ansible 把“体力活”变成了可重复、可审计的例行检查。

f(f(x))=f(x)\displaystyle f(f(x)) = f(x)
幂等是“复查清单”的数学模型：对已经配置好的系统再执行一次同样的任务，系统状态保持不变。
  1. 当前状态 $x$$x$ 表示一台服务器的当前配置状态。
    xx
  2. 一次执行 $f(x)$$f$ 表示执行某条配置任务，得到一个新状态。
    f(x)f(x)
  3. 重复执行 $f(f(x))$再执行一遍，理想结果仍是 $f(x)$，即系统不会因为重复执行而偏离。
    f(f(x))=f(x)f(f(x)) = f(x)

Terraform 资源编排

餐厅经理负责厨房内部，但“这家分店开在哪、租多大的场地、接什么样的水电”得由建筑师先定。Terraform 就是这位建筑师，它负责在云平台上申请 GPU 实例、磁盘、网络、安全组——这些是训练环境赖以生存的“场地资源”。

建筑师拿到设计图（Terraform 配置）后，先画一张“现状图”：当前已经有哪些资源。然后对比设计图，算出哪些要新增、哪些要变更、哪些要删除，这个计划叫 plan。确认无误后执行 apply，真正在云平台上创建或修改资源。

Terraform 的关键在于状态管理：它把当前资源记录在一个 state 文件中。因为云资源是实打实扣钱的，没有状态文件就可能在下次执行时对同样的资源重复创建，凭空多出一堆账单。Ansible 管“机器里装什么”，Terraform 管“机器是否存在”，两者互补，并不冲突。

建筑师管场地、经理管装备，各司其职。成熟团队总是 Terraform 开头、Ansible 收尾，把“场地”和“厨房”都变成可审阅的代码。

Plan=Sdesired−Scurrent\displaystyle \text{Plan} = S_{\text{desired}} - S_{\text{current}}
Plan 的本质是“期望资源集合减去当前资源集合”，剩下的就是要动手的差异。
  1. 当前资源 $S_{\text{current}}$从 Terraform 状态文件中读取的现有资源集合。
    ScurrentS_{\text{current}}
  2. 期望资源 $S_{\text{desired}}$代码中声明的目标资源集合，如 200 台 GPU 实例。
    SdesiredS_{\text{desired}}
  3. 求差得到 Plan两者相减得到“新增、变更、删除”清单，执行器只动差异部分。
    Plan=Sdesired−Scurrent\text{Plan} = S_{\text{desired}} - S_{\text{current}}

版本兼容管理

厨房里最怕的不是缺工具，而是工具之间不配套：新买的燃气灶挺好，但老锅的锅底太薄；新到的烤箱很高级，店里却只有旧模具。AI 环境也是如此——GPU 驱动、CUDA、深度学习框架三个版本必须形成一张“搭配表”。

这张搭配表就是兼容矩阵：驱动版本 $d$ 决定能否加载某个版本的 CUDA 工具包，CUDA 版本 $c$ 又决定框架 $f$ 能否调起 GPU 算子。三者关系必须逐项核对，一个不匹配，训练时就会报出“找不到 cudnn.so”之类让人抓狂的错误。

实践中，团队把兼容矩阵写进代码仓库，用脚本自动做“版本体检”：装环境前先校验一轮，不合格直接拒绝开工。同时用框架依赖锁（如 pip freeze、requirements 锁定文件）把关键包版本固化，杜绝依赖“飘走”。

就像餐厅把“面粉—烤箱—模具”搭配表贴在墙上，新厨师入职先读表。版本兼容管理把这张表变成自动化检查，从源头消灭“环境玄学”。

Compat(d,c,f)=DriverOK(d,c)∧FrameworkOK(c,f)\displaystyle \text{Compat}(d, c, f) = \text{DriverOK}(d, c) \land \text{FrameworkOK}(c, f)
版本组合可用的条件是“驱动支持 CUDA”与“CUDA 支持框架”同时成立，缺一不可。
  1. 驱动与 CUDA 匹配 DriverOK驱动版本 $d$ 必须满足 CUDA 版本 $c$ 的最低要求。
    DriverOK(d,c)\text{DriverOK}(d, c)
  2. CUDA 与框架匹配 FrameworkOKCUDA 版本 $c$ 必须在框架 $f$ 的官方支持列表内。
    FrameworkOK(c,f)\text{FrameworkOK}(c, f)
  3. 逻辑与判定两者同时为真时 Compat 为真，这个版本组合才可投入使用。
    Compat=DriverOK∧FrameworkOK\text{Compat} = \text{DriverOK} \land \text{FrameworkOK}

一致性保障

即便每家分店都按图纸装修，厨师也可能偷偷换掉酱油瓶、把普通面粉换成其他牌子。AI 环境同样会“漂移”：包被手动升级、库被脚本误删、配置文件被临时改动。总店需要定期派品控来对账，这就是一致性保障。

一致性保障有三件套。第一是黄金镜像（Golden Image）：把验证过的环境做成标准快照，作为唯一权威参照，就像总部拍下的“标准厨房照片”；第二是校验清单：对每台机器核对驱动版本、CUDA 版本、关键包版本；第三是漂移检测：定时任务自动扫描，发现偏差立即告警，甚至自动修复。

黄金镜像一旦发布就不可轻易改动，所有变更必须走“改代码 → 重建镜像 → 重新验证”的流程。校验清单用哈希做量化对比，让“感觉不太对”变成“第 i 项不一致”的具体数字，漂移检测因此可以被自动化。

品控拿着“标准厨房照片”逐格比对，哪格不一样立刻揪出来。一致性保障就是 AI 环境的品控体系，让每一间“厨房”始终长得一模一样。

Drift=∑i=1n1[fi(x)≠fi(x∗)]\displaystyle \text{Drift} = \sum_{i=1}^{n} \mathbb{1}\left[f_i(x) \ne f_i(x^*)\right]
漂移量等于“实际环境与黄金环境不一致的检查项个数”，为 0 就代表完全一致。
  1. 黄金环境 $x^*$被反复验证过的标准环境快照，一切对账的基准。
    x∗x^*
  2. 单项指标 $f_i$第 $i$ 个检查项（如 CUDA 版本）的实测值。
    fi(x)f_i(x)
  3. 漂移计数逐一比较，累加所有与黄金环境不一致的检查项。
    Drift=∑i=1n1[不一致]\text{Drift} = \sum_{i=1}^{n} \mathbb{1}[\text{不一致}]

快速复现方案

开新店最怕的是从头砌灶，所以高明的连锁品牌都做“预制厨柜”：工厂里把整套厨房模块化生产，现场吊装、接水接电就能开业。AI 环境复现的终极目标也是如此——拿到一个模板，几分钟生成可用环境。

快速复现有三板斧：一键部署脚本（一条命令拉起全部环境）、环境快照（把当前状态固化成模板）、标准化模板（预置好驱动、CUDA、框架的基础镜像）。需要新实验环境？直接从模板“分叉”一个，就像从模板厨房复制出一间新厨房。

复现时间 = 拉取模板 + 实例化，远小于手工安装的时间。模型训练出问题要换环境？删除、重建、拉模板，成本极低。这让人人抱怨的“实验不可复现”从口号变成日常：同事之间分享一个镜像标签，就能得到一模一样的训练环境，训练曲线可以逐点对齐。

预制厨柜省下的不只是时间，还有大量决策成本——不用再纠结“装哪个版本”，模板都替你决定了。团队因此敢频繁创建、销毁环境，算力利用率也随之提升。

Treproduce=tpull+tinstantiate≪Tmanual\displaystyle T_{\text{reproduce}} = t_{\text{pull}} + t_{\text{instantiate}} \ll T_{\text{manual}}
从模板复现环境的耗时，远小于手工逐项安装的耗时，这就是“预制厨柜”的威力。
  1. 拉取耗时 $t_{\text{pull}}$从镜像仓库拉取标准模板的网络时间。
    tpullt_{\text{pull}}
  2. 实例化耗时 $t_{\text{instantiate}}$从模板启动并生成可用环境的时间。
    tinstantiatet_{\text{instantiate}}
  3. 远小于手工配置相比人工逐项安装，复现时间能压缩一个数量级以上。
    Treproduce≪TmanualT_{\text{reproduce}} \ll T_{\text{manual}}

镜像构建实践

预制厨柜不能一整块运输——太笨重、太脆。聪明的做法是分成若干层：基层是柜体结构，中间层是水管电路，表层是台面和把手。每层单独生产、单独缓存、按需组装。Docker 镜像正是这个思路。

镜像由一条条构建指令叠加成层。构建时如果某层内容与上次完全相同，就命中缓存直接复用，只有变更的层才重新构建。因此最重要的分层原则是：把频繁变化的依赖放在后面，把稳定的底座放在前面。比如系统镜像 → CUDA → 框架 → 业务代码，越靠前越少变动，缓存命中率越高。

镜像构建的最佳实践还包括：用精简基础镜像（如 python:slim）减小体积和攻击面；合并多条 RUN 指令减少层数；固定所有版本号；避免交互式安装；敏感信息用构建参数传入，而不是写死在镜像里。这样构建出的镜像，又快、又小、又安全。

就像厨房模块按“底座—管线—台面”分层生产，每层可复用、可替换。镜像构建的分层缓存，让“又快、又省、又安全”不再互相矛盾。

Tbuild=tbase+∑i=1nti⋅(1−cachei)\displaystyle T_{\text{build}} = t_{\text{base}} + \sum_{i=1}^{n} t_i \cdot (1 - \text{cache}_i)
总构建时间 = 基础层耗时 + 所有“未命中缓存”的层耗时之和，命中缓存的层直接跳过。
  1. 层 $i$ 与耗时 $t_i$镜像按构建指令分层，每一层都有独立的构建时间。
    tit_i
  2. 缓存命中 cache$_i$该层内容与上次一致时命中缓存，跳过重建。
    cachei∈{0,1}\text{cache}_i \in \{0, 1\}
  3. 总构建时间只累加基础层与未命中层的耗时，得到整体构建开销。
    Tbuild=tbase+∑i=1nti⋅(1−cachei)T_{\text{build}} = t_{\text{base}} + \sum_{i=1}^{n} t_i \cdot (1 - \text{cache}_i)

AI 应用场景

训练集群的批量交付

阶段：环境准备与资源配置

解决的问题：手动给 200 台 GPU 服务器装驱动、配 CUDA、装框架至少要 3 天，还经常出现版本不匹配；用 Terraform 声明式申请云主机、Ansible 幂等安装后，2 小时即可交付，且环境完全一致。

具体案例：某自动驾驶公司新模型训练排期紧急，MLOps 团队把“集群交付”做成流水线：terraform apply 批量申请 200 台 A100 实例，Ansible Playbook 自动安装 CUDA 12.1 与 PyTorch，最后用校验清单逐台核对，全部通过才交接给算法组。

论文实验的精确复现

阶段：实验管理与模型训练

解决的问题：换台机器、同样的代码却跑不出同样的结果，根源通常是训练环境不一致；用黄金镜像加版本标签，可以实现“一次构建、处处复现”。

具体案例：算法研究团队发布模型时，同时发布镜像标签（如 ai-env-3f2a1c）。协作者拉取该标签，就能得到与论文完全一致的 CUDA、框架与依赖版本，训练曲线可以逐点对齐，审稿人也能复现结果。

版本升级的安全回滚

阶段：运维保障与版本管理

解决的问题：CUDA 升级后框架不兼容、训练精度异常，人工排查往往耗时数天；通过兼容矩阵预检加环境快照回滚，可以把事故控制在分钟级。

具体案例：某公司 SRE 计划将 CUDA 从 11.4 升到 12.1，先跑兼容矩阵校验，发现内部工具链尚不支持，立即阻止上线；另一次升级后确有异常，团队直接一键回滚环境快照，训练作业 5 分钟内恢复。

Python 演示

python50 行
# -*- coding: utf-8 -*-"""AI训练环境自动配置:兼容校验+生成Ansible剧本+一致性检查"""import hashlibimport json GROUP_MATRIX = {    ("470", "11.4"): ["tensorflow", "pytorch"],    ("525", "12.1"): ["tensorflow", "pytorch"],    ("535", "12.2"): ["pytorch"],}  def is_compatible(driver, cuda, framework):    for d, c in GROUP_MATRIX:        if d == driver and c == cuda and framework in GROUP_MATRIX[(d, c)]:            return True    return False  def build_playbook(driver, cuda, framework):    return {        "name": "AI训练环境自动配置",        "hosts": "gpu_servers",        "become": True,        "tasks": [            {"name": "安装GPU驱动", "apt": {"name": "nvidia-driver-" + driver, "state": "present"}},            {"name": "安装CUDA", "shell": "apt-get install -y cuda-toolkit-" + cuda},            {"name": "安装训练框架", "pip": {"name": framework, "state": "present"}},        ],    }  def env_hash(spec):    raw = json.dumps(spec, sort_keys=True)    return hashlib.sha256(raw.encode("utf-8")).hexdigest()[:12]  def main():    spec = {"driver": "525", "cuda": "12.1", "framework": "pytorch"}    if not is_compatible(**spec):        raise SystemExit("版本不兼容, 请参考兼容矩阵调整")    playbook = build_playbook(**spec)    tag = env_hash(spec)    print("生成剧本: ai-env-" + tag + ".yml")    print(json.dumps(playbook, ensure_ascii=False, indent=2))    print("一致性标签: " + tag)  if __name__ == "__main__":    main()
目的：模拟 MLOps 工具链的核心逻辑——先查兼容矩阵做版本体检，再生成可直接交给 Ansible 执行的配置剧本，最后用哈希为环境打上可复核的一致性标签。
  1. GROUP_MATRIX = {兼容矩阵，相当于厨房墙上那张“食材搭配表”，写死了驱动、CUDA、框架的合法组合。
  2. for d, c in GROUP_MATRIX:遍历所有“驱动—CUDA”组合，逐个比对当前版本是否在表内。
  3. "nvidia-driver-" + driver把驱动版本拼进 apt 包名，实现“参数化安装”，换版本不用改逻辑。
  4. def env_hash(spec):对配置字典做摘要，得到一个 12 位的环境指纹，用于一致性对账。
  5. raise SystemExit("版本不兼容, 请参考兼容矩阵调整")版本不匹配立即终止，拒绝“带病开工”，就像大厨拒绝用不配套的锅。
  6. json.dumps(playbook, ensure_ascii=False, indent=2)把 Python 字典输出为美观的 JSON 剧本，可直接喂给 ansible-playbook 执行。

常见误区

误区环境配置好之后就不会再坏了，之后可以完全不用管，出问题一定是硬件故障。

正解环境会持续“漂移”——工程师手动改包、脚本误升级、新节点缺件，都会让机器悄悄偏离标准。就像厨师隔三差五就换一种酱油，厨房会慢慢变得和照片上不一样。所以必须有校验清单和漂移检测，定期“对账”。

为何常见：手动配置的世界里变化很慢，容易让人误以为“环境是静态的”；而多人协作、自动更新的云环境里，漂移才是常态。

误区CUDA、驱动、框架当然是装最新版最好，旧版本显得过时。

正解关键不是新旧，而是兼容矩阵。新版本可能不被当前框架支持，就像新式燃气灶装不进老厨房的管线。生产环境应当以“经过验证的组合”为准，而不是盲目追新。

为何常见：消费电子产品的“追新”思维被套用到基础设施上，忽略了 AI 工具链互相依赖的复杂性。

误区把 CUDA、conda、各种库一次性全塞进一个镜像，以后什么都不缺，省心。

正解大而全的镜像构建慢、拉取慢、攻击面大，而且难以定位问题。正确做法是分层构建、精简基础镜像、固定版本，让每一层都可以独立缓存和复用。

为何常见：人在图省事时倾向“一次装全”，却没计算构建时间、存储成本和安全隐患这些长期代价。

误区反正都是自动化，有了 Terraform 就不需要 Ansible，或者反过来。

正解两者分工不同：Terraform 管“机器是否存在”（申请云资源），Ansible 管“机器里装成什么样”（安装配置）。就像建筑师负责场地，餐厅经理负责厨房内部，缺一不可，标准流程是 Terraform 开头、Ansible 收尾。

为何常见：两者名字都带“自动化”，看起来很像；但资源编排与配置管理是两层不同的问题，混为一谈容易选错工具。

面试题

Q1. 基础设施即代码（IaC）的核心思想是什么？

单选题 · easy

  • A.用一次性脚本执行安装命令
  • B.用代码声明目标状态并自动收敛← 正确答案
  • C.所有操作必须经过人工审批
  • D.每次部署前删除旧环境重建

答案：B。IaC 的核心是“声明目标状态，由引擎自动收敛”，就像画好厨房蓝图让施工队照图施工。A 是一次性脚本，不具备声明与收敛能力；C 是流程规定，与 IaC 无关；D 是粗暴重建，不是 IaC 的思路。

Q2. Ansible“幂等性”的含义是什么？

单选题 · easy

  • A.同一任务执行多次结果完全一致← 正确答案
  • B.执行速度快并且占用资源较少
  • C.任务失败后能够自动重新执行
  • D.可同时对多台机器并行执行

答案：A。幂等指同一条任务重复执行多次结果完全一致，像经理复查清单，装好的打个勾、绝不重复搬动灶台。B 说的是性能，C 是重试机制，D 是并行能力，都不是幂等的定义。

Q3. Terraform 的“状态文件”主要作用是什么？

单选题 · easy

  • A.存放服务器上的运行日志
  • B.记录当前资源并与期望求差← 正确答案
  • C.保存云平台的账号与密码
  • D.缓存容器镜像的图层备份

答案：B。状态文件记录“当前已经创建了哪些资源”，Terraform 拿它与期望状态求差，才能生成精准的新增、变更、删除计划，避免重复创建资源产生账单。A、C、D 都与状态文件的作用无关。

Q4. 下列哪些属于版本兼容性管理的必要动作？

多选题 · mid

  • A.核对驱动与 CUDA 的匹配度← 正确答案
  • B.核对 CUDA 与框架的匹配度← 正确答案
  • C.锁定关键依赖的具体版本← 正确答案
  • D.使用最新版本且无需核对

答案：ABC。版本兼容管理要同时核对驱动与 CUDA、CUDA 与框架的匹配关系，并锁定关键依赖版本，正如厨房里的“食材搭配表”必须严格执行；D 盲目追新正是环境事故的常见来源。

Q5. 黄金镜像与普通环境的本质区别是什么？

单选题 · mid

  • A.经过校验的标准化环境快照← 正确答案
  • B.体积更小的精简训练环境
  • C.仅用于测试的临时性环境
  • D.价格更低的商业云环境

答案：A。黄金镜像是经过反复验证、不可轻易改动的标准环境快照，是漂移检测的参照基准。B、C、D 描述的“更小、更临时、更便宜”都不是黄金镜像的本质属性。

Q6. 漂移检测能够发现哪些问题？

多选题 · mid

  • A.工程师手动改动了系统库版本← 正确答案
  • B.某节点 CUDA 被脚本误降级← 正确答案
  • C.新开通的节点缺少 GPU 驱动← 正确答案
  • D.网络带宽出现轻微的波动

答案：ABC。漂移指实际系统状态偏离黄金基线，包括手动改库、脚本误降级、新节点缺件；D 网络波动属于运行时故障而非配置漂移，就像电源跳闸不等于厨具被换。

Q7. Docker 镜像分层的主要好处是什么？

单选题 · mid

  • A.命中缓存的层可以跳过重建← 正确答案
  • B.镜像完全不需要重新构建
  • C.容器运行速度成倍得到提升
  • D.无需再安装任何运行依赖

答案：A。镜像分层最大的价值是缓存复用——某层内容没变就跳过重建，像预制厨柜的柜体模块可跨店复用。B 过于绝对，C 分层不直接提升运行速度，D 分层恰恰仍需在层内安装依赖。

Q8. 设计 AI 训练环境自动配置方案时，哪些做法是正确的？

多选题 · hard

  • A.用 Terraform 申请 GPU 实例← 正确答案
  • B.用 Ansible 安装驱动和框架← 正确答案
  • C.版本组合写入兼容矩阵← 正确答案
  • D.每次构建都重装全部依赖

答案：ABC。标准方案是 Terraform 负责申请 GPU 实例（资源编排），Ansible 负责装驱动与框架（配置管理），版本组合写进兼容矩阵统一校验；D 每次全量重装依赖违背分层缓存与快速复现原则。

Q9. 某集群发现 3 台机器训练框架版本不一致，最可能的原因是什么？

单选题 · hard

  • A.手动变更导致了配置漂移← 正确答案
  • B.镜像构建耗时过长所致
  • C.状态文件缺失导致重建
  • D.GPU 硬件出现物理故障

答案：A。多台机器版本不一致，最常见的原因是有人绕过自动化流程手动改动，造成配置漂移，这正是漂移检测要抓的场景。B、C、D 都无法解释“部分节点不一致”的现象。

Q10. Terraform 在 apply 之前先执行 plan 的目的是什么？

单选题 · extreme

  • A.生成资源变更差异供审阅确认← 正确答案
  • B.提前下载全部云资源的镜像
  • C.删除账号下的所有旧资源
  • D.让云平台完成性能基准测试

答案：A。apply 前先 plan，是为了生成一份“资源变更差异清单”供人审阅确认，相当于建筑师出图后由业主确认再施工；B、C、D 都不是 plan 的目的。