智算基础设施正在快速膨胀,但一个被反复忽略的事实是——每换一颗 AI 芯片,运维和开发团队就要重新适配一整套驱动、编译器、运行时和调度工具。这不是小麻烦,是结构性成本。2026 年 5 月,openKylin 社区技术委员会审议通过,由上海苦芽科技有限公司发起的 FlagOS SIG 正式成立,目标很明确:基于 openKylin 操作系统,构建面向多元 AI 芯片的统一开源系统软件栈,把"换芯即换栈"的困局逐步收拢。
碎片化从哪里来
当前国内智算中心里,GPU、NPU、DSA 加速器并存已是常态。每家芯片厂商各自维护一套闭源或半闭源的驱动栈和 SDK,带来的问题层层叠加:
- 部署侧:同一集群混插不同芯片时,操作系统镜像、内核模块、固件版本必须分叉维护,节点升级变成逐台手工操作。
- 开发侧:模型训练脚本在不同芯片上需要切换不同的推理引擎和算子库,移植成本远超模型本身。
- 调度侧:资源管理器缺乏统一的加速器抽象,任务排队策略只能硬编码芯片类型。
碎片化不是某一家芯片的问题,而是整个生态缺少一个横跨多芯的"底层公约"。
FlagOS 的核心思路
FlagOS SIG 的定位不是再造一个操作系统,而是在 openKylin(本身基于 Linux 内核、面向桌面与服务器的成熟发行版)之上,补齐一层跨芯统一软件栈。从公开信息看,它要解决的关键环节包括:
- 统一驱动与固件管理——把不同 AI 芯片的内核驱动、固件更新纳入同一包管理框架,做到一条命令查询全集群加速器状态。
- 统一运行时与编译器接口——提供标准化的加速器抽象层,让上层推理引擎和算子库不必为每颗芯片单独适配。
- 统一调度与资源视图——让 Slurm、Kubernetes 等调度器通过同一套设备插件发现和管理异构加速器。
换句话说,FlagOS 想让"换芯"这件事对上层应用透明——至少在系统软件层面,不再需要重写部署脚本。
实践:在 openKylin 上搭建多芯节点的配置思路
FlagOS 的完整软件栈仍在建设中,但基于 openKylin 的包管理体系和 Linux 内核的设备模型,现在就可以用以下方式为多芯集群建立统一管理框架。下面给出一个可直接改造的示例。
1. 用 YAML 描述集群加速器拓扑
创建 /etc/flagos/accelerator-topology.yaml,声明节点上的加速器类型与数量,供调度器和监控组件读取:
# /etc/flagos/accelerator-topology.yaml
# 描述本节点的加速器资源配置,FlagOS 调度插件会读取此文件
node_name: compute-node-01
accelerators:
- type: gpu
vendor: vendor-a
model: xa100
count: 4
driver_version: "2.3.1"
firmware_version: "1.0.8"
memory_mb: 32768
device_path: /dev/vendor-a-accel
- type: npu
vendor: vendor-b
model: nb200
count: 2
driver_version: "5.0.0"
firmware_version: "3.2.1"
memory_mb: 65536
device_path: /dev/vendor-b-npu
runtime_defaults:
compute_backend: flagos-rt # FlagOS 统一运行时
compiler_backend: flagos-cc # FlagOS 统一编译器
运行前需要根据实际芯片型号修改
vendor、model、device_path等字段。文件路径遵循 FlagOS 的约定目录/etc/flagos/。
2. 一键查询全节点加速器状态
写一个轻量脚本,汇总内核设备节点与 YAML 拓扑信息,快速排查驱动加载情况:
#!/usr/bin/env bash
# flagos-accel-check.sh — 检查本节点加速器驱动与设备节点状态
set -euo pipefail
TOPOLOGY_FILE="/etc/flagos/accelerator-topology.yaml"
if [[ ! -f "$TOPOLOGY_FILE" ]]; then
echo "错误:拓扑文件 $TOPOLOGY_FILE 不存在,请先配置"
exit 1
fi
echo "=== FlagOS 加速器状态检查 ==="
echo "节点:$(hostname)"
echo ""
# 从 YAML 中提取 device_path 字段(依赖 yq 工具)
if command -v yq &>/dev/null; then
DEVICES=$(yq '.accelerators[].device_path' "$TOPOLOGY_FILE")
for dev in $DEVICES; do
if [[ -c "$dev" ]]; then
echo "✅ $dev — 设备节点存在(字符设备)"
elif [[ -e "$dev" ]]; then
echo "⚠️ $dev — 节点存在但类型异常"
else
echo "❌ $dev — 设备节点缺失,驱动可能未加载"
fi
done
else
echo "提示:安装 yq 可自动解析 YAML(pip install yq 或下载二进制)"
echo "手动检查:ls /dev/vendor-* 确认设备节点"
ls /dev/vendor-* 2>/dev/null || echo "未发现 /dev/vendor-* 设备节点"
fi
echo ""
echo "=== 内核模块加载情况 ==="
lsmod | grep -E 'accel|npu|gpu' || echo "无加速器相关内核模块"
使用方式:
# 安装 yq(可选,用于 YAML 解析)
pip install yq # 或从 https://github.com/mikefarah/yq 下载 Go 版本
# 运行检查
chmod +x flagos-accel-check.sh
./flagos-accel-check.sh
3. 为 Kubernetes 集群注册异构加速器设备插件
FlagOS 的调度抽象层最终会提供统一设备插件,当前可以先用自定义 DevicePlugin 框架对接不同芯片。下面是一个最小化部署清单:
# flagos-device-plugin-deploy.yaml
# 在 Kubernetes 集群中为每种加速器部署 DevicePlugin DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: flagos-accel-device-plugin
namespace: flagos-system
spec:
selector:
matchLabels:
app: flagos-device-plugin
template:
metadata:
labels:
app: flagos-device-plugin
spec:
containers:
- name: device-plugin
image: flagos/device-plugin:0.1.0 # FlagOS 官方镜像,后续发布
securityContext:
privileged: true
volumeMounts:
- name: device-plugin
mountPath: /var/lib/kubelet/device-plugins
- name: dev
mountPath: /dev
- name: config
mountPath: /etc/flagos
volumes:
- name: device-plugin
hostPath: /var/lib/kubelet/device-plugins
- name: dev
hostPath: /dev
- name: config
hostPath: /etc/flagos
# 创建命名空间并部署
kubectl create namespace flagos-system
kubectl apply -f flagos-device-plugin-deploy.yaml
# 验证设备插件注册
kubectl get nodes -o wide
kubectl describe node compute-node-01 | grep -A5 Capacity
镜像
flagos/device-plugin:0.1.0为示例名称,FlagOS SIG 正式发布后替换为实际镜像地址。
加入 SIG 与路线展望
FlagOS SIG 刚成立,软件栈的各层组件仍在规划和开发中。对于正在做异构智算集群适配的团队,现在参与有实际价值:
- 早期贡献驱动适配:如果你正在某款国产 AI 芯片上做内核驱动或运行时封装,可以把适配经验提交到 SIG,帮助统一抽象层覆盖更多硬件。
- 共建调度与监控规范:加速器拓扑 YAML、设备插件接口等规范需要来自真实集群的反馈,不是闭门设计能完成的。
- 测试与反馈:openKylin 的包管理体系和内核版本策略直接影响驱动兼容性,一线运维遇到的升级冲突是最有价值的 issue。
加入方式:通过 openKylin 社区官网提交 SIG 加入申请,或在 FlagOS 仓库提交 PR/Issue。具体入口随 SIG 运营逐步开放。
需要留意的边界
FlagOS 解决的是系统软件栈层面的统一,但有几条线它不会替你画完:
- 算子级兼容:不同芯片的算子实现差异仍然需要推理引擎(如 ONNX Runtime、自研引擎)做适配,FlagOS 提供运行时接口,不替代算子库。
- 性能调优:统一栈意味着"都能跑",不意味着"都跑得最快"。每颗芯片的专属调优参数仍需在栈的上层单独配置。
- 闭源固件:部分芯片的固件更新工具仍由厂商闭源提供,FlagOS 可以统一触发流程,但固件本身不在开源范围内。
一句话总结:FlagOS SIG 的成立,是把"每颗芯片各建一套栈"的重复劳动,收拢成"一套栈适配多颗芯"的公共工程。这件事的难度不在技术,在于有多少芯片厂商愿意把驱动和运行时接口放进同一个开源框架。现在 SIG 刚起步,正是需要一线团队拿真实集群需求去塑形的时候。