openKylin FlagOS SIG 成立:给多元 AI 芯片搭一套统一软件栈

2026-06-01 19 预计阅读时间:1 分钟
来源:oschina.net AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:11 分钟

智算基础设施正在快速膨胀,但一个被反复忽略的事实是——每换一颗 AI 芯片,运维和开发团队就要重新适配一整套驱动、编译器、运行时和调度工具。这不是小麻烦,是结构性成本。2026 年 5 月,openKylin 社区技术委员会审议通过,由上海苦芽科技有限公司发起的 FlagOS SIG 正式成立,目标很明确:基于 openKylin 操作系统,构建面向多元 AI 芯片的统一开源系统软件栈,把"换芯即换栈"的困局逐步收拢。

碎片化从哪里来

当前国内智算中心里,GPU、NPU、DSA 加速器并存已是常态。每家芯片厂商各自维护一套闭源或半闭源的驱动栈和 SDK,带来的问题层层叠加:

  • 部署侧:同一集群混插不同芯片时,操作系统镜像、内核模块、固件版本必须分叉维护,节点升级变成逐台手工操作。
  • 开发侧:模型训练脚本在不同芯片上需要切换不同的推理引擎和算子库,移植成本远超模型本身。
  • 调度侧:资源管理器缺乏统一的加速器抽象,任务排队策略只能硬编码芯片类型。

碎片化不是某一家芯片的问题,而是整个生态缺少一个横跨多芯的"底层公约"。

FlagOS 的核心思路

FlagOS SIG 的定位不是再造一个操作系统,而是在 openKylin(本身基于 Linux 内核、面向桌面与服务器的成熟发行版)之上,补齐一层跨芯统一软件栈。从公开信息看,它要解决的关键环节包括:

  1. 统一驱动与固件管理——把不同 AI 芯片的内核驱动、固件更新纳入同一包管理框架,做到一条命令查询全集群加速器状态。
  2. 统一运行时与编译器接口——提供标准化的加速器抽象层,让上层推理引擎和算子库不必为每颗芯片单独适配。
  3. 统一调度与资源视图——让 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 统一编译器

运行前需要根据实际芯片型号修改 vendormodeldevice_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 刚起步,正是需要一线团队拿真实集群需求去塑形的时候。


相关推荐