Ansible playbook编写：批量配置数百台AI训练服务器
Ansible playbook编写：批量配置数百台AI训练服务器
在当今大模型和多模态技术飞速发展的背景下，构建稳定、高效且一致的AI训练集群已成为企业与科研机构的核心竞争力之一。一个典型的AI训练环境往往由数百台搭载NVIDIA A100/H100或国产昇腾NPU的服务器组成，每台机器都需要部署复杂的软件栈——从CUDA驱动、PyTorch版本到特定框架依赖，稍有偏差就可能导致“这台能跑，那台报错”的尴尬局面。
面对这种挑战，手动逐台配置显然不可持续。我们曾亲眼见证过团队花三天时间完成600台GPU节点的基础搭建，结果因为两台节点漏装NCCL导致整个分布式训练任务失败。这样的教训促使我们转向基础设施即代码（IaC） 的工程实践，而 Ansible Playbook 正是实现这一目标的理想工具。
为什么选择 Ansible？
相比SaltStack、Puppet等传统配置管理工具，Ansible 最大的优势在于其 无代理架构（agentless） 和 声明式YAML语法。它通过SSH连接目标主机，直接执行模块化任务，无需在被控节点安装任何额外服务，极大降低了系统侵入性和运维负担。
更重要的是，Ansible 具备天然的幂等性：无论你执行一次还是十次，只要系统已处于期望状态，就不会产生副作用。这一点对于大规模部署尤为关键——你可以放心重试失败的任务，而不必担心引发连锁问题。
以我们实际使用的 playbook 为例：
---
- name: 配置AI训练服务器集群
hosts: ai_nodes
become: yes
vars:
cuda_version: "12.1"
python_version: "3.10"
swift_repo: "https://github.com/modelscope/ms-swift.git"
model_dir: "/data/models"
user: "aistudent"
pre_tasks:
- name: 更新APT包索引（Ubuntu）
apt:
update_cache: yes
when: ansible_os_family == "Debian"
- name: 安装基础依赖
package:
name:
- python3-pip
- git
- wget
- nvidia-driver-{{ cuda_version }}
- cuda-toolkit-{{ cuda_version }}
state: present
tasks:
- name: 创建模型存储目录
file:
path: "{{ model_dir }}"
state: directory
owner: "{{ user }}"
group: "{{ user }}"
mode: '0755'
- name: 安装Python虚拟环境工具
pip:
name: virtualenv
executable: pip3
- name: 为ms-swift创建独立虚拟环境
pip:
virtualenv: /opt/envs/ms-swift
virtualenv_python: python{{ python_version }}
requirements: "{{ swift_repo }}/requirements.txt"
environment:
PIP_INDEX_URL: https://pypi.tuna.tsinghua.edu.cn/simple
- name: 克隆ms-swift源码
git:
repo: "{{ swift_repo }}"
dest: "/opt/ms-swift"
version: main
clone: yes
update: yes
- name: 设置全局环境变量
lineinfile:
path: /etc/environment
line: "PATH=/opt/envs/ms-swift/bin:{{ lookup('file', '/etc/environment') | regex_replace('.*PATH=(.*)', '') }}"
- name: 下载启动脚本 yichuidingyin.sh
get_url:
url: "https://gitcode.com/aistudent/ai-mirror-list/raw/master/scripts/yichuidingyin.sh"
dest: "/root/yichuidingyin.sh"
mode: '0755'
force: yes
- name: 重启NVIDIA驱动服务
systemd:
name: nvidia-persistenced
state: restarted
enabled: yes
when: ansible_devices is defined and "'nvidia' in ansible_devices.keys()"
handlers:
- name: 重启docker
service:
name: docker
state: restarted
这个 playbook 看似简单，却解决了多个现实痛点：
- 利用
when条件判断操作系统类型，确保在混合使用Ubuntu/CentOS的环境中也能兼容运行； - 通过指定清华镜像源加速 pip 安装，避免因国外网络波动导致超时；
- 使用
lineinfile动态修改环境变量，而非粗暴覆盖文件内容，减少误操作风险； handlers实现事件驱动式服务重启，只有真正发生变更时才会触发，提升执行效率。
配合如下 inventory 文件：
[ai_nodes]
gpu-node-[001:600].cluster.local ansible_user=aistudent ansible_ssh_private_key_file=~/.ssh/id_rsa
一条命令即可完成600台服务器的并行初始化：
ansible-playbook -i inventory.ini configure_ai_servers.yml
实测在千兆内网环境下，全量执行耗时约2小时，相比人工操作提速超过90%。
与 ms-swift 框架深度集成
如果说 Ansible 解决了“底座一致性”问题，那么 ms-swift 则打通了从环境到应用的最后一公里。
作为魔搭社区推出的开源大模型全生命周期管理框架，ms-swift 支持超过600个纯文本模型和300个多模态模型，涵盖预训练、微调、推理、评测、量化等完整链路。它的设计哲学非常清晰：让研究人员专注算法创新，而不是陷入环境配置的泥潭。
我们在 playbook 中自动部署的 /root/yichuidingyin.sh 脚本，正是基于 ms-swift CLI 封装的一键式交互工具。用户登录任意节点后，只需运行该脚本，就能引导式完成以下操作：
- 模型下载：自动从ModelScope拉取指定模型，并缓存至共享目录；
- 微调任务：支持LoRA、QLoRA、DoRA等多种轻量微调方式，显存占用可降低至原来的1/10；
- 推理部署：一键启动vLLM或SGLang服务，暴露OpenAI兼容API；
- 自动评测：接入EvalScope平台，对MMLU、C-Eval等主流基准进行自动化打分。
更值得一提的是，ms-swift 对硬件异构性的支持极为友好。无论是NVIDIA GPU（RTX/T4/V100/A100/H100）、昇腾NPU，还是Apple Silicon（M1/M2），都能自动识别并启用最优执行后端。例如，在A100上默认使用vLLM + FlashAttention，在CPU-only节点则切换为PyTorch原生推理。
它还内置了多种前沿训练技术：
| 方法 | 显存节省 | 特点说明 |
|---|---|---|
| LoRA | ~70% | 低秩适配，适合中小规模微调 |
| QLoRA | ~90% | 4-bit量化+LoRA，可在单卡运行70B模型 |
| GaLore | ~80% | 梯度低秩投影，适用于长序列训练 |
| Liger-Kernel | ~40%推理延迟下降 | 内核级优化，显著提升吞吐 |
这些功能都可以通过简单的YAML配置启用：
lora_rank: 64
lora_alpha: 16
lora_dropout: 0.05
target_modules: ["q_proj", "v_proj"]
无需修改一行代码，即可享受最先进的效率优化。
架构落地与最佳实践
我们的整体架构采用“中心控制 + 分布执行”模式：
+----------------------------+
| Ansible Control Node |
| （运行Playbook控制器） |
+-------------+--------------+
|
| SSH
v
+---------------------------------------------------+
| AI Training Cluster |
| [Node-001] [Node-002] ... [Node-600] |
| - CUDA驱动 - CUDA驱动 - CUDA驱动 |
| - Python环境 - Python环境 - Python环境 |
| - ms-swift框架 - ms-swift框架 - ms-swift框架 |
| - 模型缓存目录 - 模型缓存目录 - 模型缓存目录 |
+---------------------------------------------------+
|
| 统一访问入口
v
+---------------------+
| 用户操作终端 |
| /root/yichuidingyin.sh|
+---------------------+
在实际部署过程中，我们总结出几条关键经验：
1. 分批执行，避免连接风暴
尽管Ansible支持并发执行，默认forks=5可能太慢。但若一次性开启600个SSH连接，极易压垮控制节点或交换机。建议设置合理的并发数（如50），并通过分组策略按机架或可用区逐步推进：
[ai_nodes_rack1]
gpu-node-[001:050].cluster.local
[ai_nodes_rack2]
gpu-node-[051:100].cluster.local
然后逐组执行：
ansible-playbook -i inventory.ini configure_ai_servers.yml --limit ai_nodes_rack1
2. 集中管理模型缓存
为了避免重复下载浪费带宽，我们将 /data/models 目录挂载为NFS共享存储，所有节点共用同一份模型缓存。结合 ms-swift 的智能缓存机制，首次下载后其余节点几乎无需等待。
3. 引入AWX/AWX简化运维
虽然命令行足够强大，但对于非技术背景的研究员来说仍有一定门槛。我们后续引入了 AWX（Ansible Web UI），将常用操作封装为可视化模板：
- “初始化新一批GPU节点”
- “升级ms-swift至最新版”
- “批量重启推理服务”
配合RBAC权限控制，不同角色只能看到自己有权操作的任务，既保障安全又提升易用性。
4. 日志审计与版本追踪
每次 playbook 执行都记录日志到ELK体系，并与Git仓库联动。一旦发现异常，可以快速回溯是哪次变更引入的问题。同时，playbook本身也纳入CI/CD流程，确保每次更新都经过测试验证。
真实场景中的价值体现
这套组合拳已在多个高校实验室和企业AI平台落地，支撑了包括千亿参数MoE模型训练、视频理解系统构建在内的复杂项目。
某客户曾面临这样一个难题：他们需要在两周内部署一个包含200台H100的训练集群，用于微调一个多模态对话模型。如果沿用旧流程，仅环境配置就需要三名工程师连续工作五天以上，还不包括调试时间。
我们采用上述方案后，第一天上午完成Ansible部署，中午开始批量执行playbook，下午已有半数节点就绪；第二天全员即可上手使用统一脚本启动训练任务。最终整个集群提前一天投入使用，且未出现因环境差异导致的失败案例。
更重要的是，当后续需要扩容或更换硬件时，只需调整inventory文件和少量变量，原有playbook几乎无需改动。这种可复用性，才是真正意义上的“工业化AI生产”。
写在最后
Ansible + ms-swift 的组合，本质上是在推动AI工程范式的转变：从“靠人肉保证正确性”的作坊模式，走向“靠代码保障一致性”的现代DevOps实践。
它不仅提升了部署效率，更重要的是建立了可追溯、可审计、可复制的工作流。无论是新人入职、故障排查，还是跨团队协作，都有据可依。
未来，随着更多国产芯片（如昇腾、寒武纪）和新型训练算法（如Mixture-of-Depths）的接入，这套自动化体系将持续演进。我们可以预见，下一代AI基础设施将不再是零散的脚本集合，而是由一系列标准化、模块化、可编排的自动化单元构成的有机整体。
而这，正是我们正在构建的方向。
