7 月 9 日至 11 日，以“智算无界，范式跃迁”为主题的光合组织 2026 智能计算应用大会在郑州举办。大会通过主会、39 场专题论坛和生态展区，将 AI 大模型、操作系统、智能计算基础设施放在同一张产业协作图中。openKylin 与海光所强调的“全栈原生智算底座”，值得关注之处不只是让软件能够启动，而是推动处理器、操作系统、驱动、计算框架和应用形成可测试、可部署、可维护的完整链路。
“原生”不只是完成一次兼容认证
传统适配经常停留在“安装成功”和“程序能跑”两个节点。智算集群的真实交付则要面对更多变量：内核与固件组合、NUMA 拓扑、容器运行时、计算设备插件、框架版本，以及模型服务在高负载下的稳定性。
因此，一套全栈原生底座至少需要打通四层能力：
- 硬件层：处理器、内存、存储和加速设备能够被系统正确识别，并暴露稳定的拓扑信息。
- 操作系统层：内核、软件源、编译工具链和安全更新具备一致的生命周期管理。
- 计算平台层：容器、集群调度、通信库和 AI 框架可以按标准方式安装和升级。
- 应用层：训练、推理及行业软件拥有明确的版本矩阵、性能基线和故障定位路径。
这也是操作系统与芯片平台协同的实际价值：把分散在不同厂商和项目中的兼容问题，提前收敛到一套可以重复验证的工程基线中。
智算底座必须回答三个交付问题
第一，环境是否可复现。节点不能依靠工程师临时执行的一串命令维持运行，而应使用镜像、软件仓库、配置管理或集群声明文件固化状态。
第二，能力是否可调度。调度系统需要知道哪些节点属于目标处理器平台、具备多少计算资源，以及哪些工作负载允许落到这些节点上。仅在资产表中记录服务器型号，无法约束实际调度行为。
第三，结果是否可度量。验证范围不能只有模型输出正确性，还应覆盖冷启动时间、吞吐量、尾延迟、内存占用、设备利用率和长时间运行的错误率。没有基线数据，“兼容”就很难转化为可执行的验收条件。
可以这样实践：建立节点识别与调度基线
下面是一个可改造的 Kubernetes 示例。假设集群已经安装 openKylin 节点，并完成 Kubernetes 与所需设备驱动的部署。先检查操作系统、内核、CPU 架构和 NUMA 信息：
set -euo pipefail
printf '%s\n' '== OS =='
cat /etc/os-release
printf '%s\n' '== Kernel =='
uname -a
printf '%s\n' '== CPU and NUMA =='
lscpu
printf '%s\n' '== Kubernetes node =='
kubectl get nodes -o wide
确认目标节点后，为它添加受控标签。运行前将 worker-01 替换为真实节点名；标签值应以团队实际验收结果为准：
kubectl label node worker-01 \
platform.example.com/os=openkylin \
platform.example.com/cpu=hygon \
platform.example.com/ai-ready=true \
--overwrite
kubectl get node worker-01 --show-labels
随后可以使用节点亲和性约束测试任务。下面的 YAML 不依赖特定 AI 框架，用于验证镜像拉取、容器启动、节点选择和基础 CPU 信息是否正常：
apiVersion: batch/v1
kind: Job
metadata:
name: openkylin-hygon-smoke-test
spec:
backoffLimit: 1
template:
metadata:
labels:
app: platform-smoke-test
spec:
restartPolicy: Never
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: platform.example.com/os
operator: In
values: [openkylin]
- key: platform.example.com/cpu
operator: In
values: [hygon]
- key: platform.example.com/ai-ready
operator: In
values: ["true"]
containers:
- name: probe
image: ubuntu:24.04
command:
- /bin/bash
- -lc
- |
set -euo pipefail
uname -a
lscpu
grep -E 'model name|processor' /proc/cpuinfo | head -20
将内容保存为 smoke-test.yaml 后执行：
kubectl apply -f smoke-test.yaml
kubectl wait --for=condition=complete job/openkylin-hygon-smoke-test --timeout=120s
kubectl logs job/openkylin-hygon-smoke-test
kubectl delete job openkylin-hygon-smoke-test
这只是基础冒烟测试。进入生产验收前，还应替换为团队实际采用的框架镜像，并加入矩阵运算、模型加载、设备可见性、通信性能和连续运行测试。涉及专用计算设备时，设备资源名称、运行时配置和检测命令必须依据实际驱动与平台文档调整，不能直接从其他硬件平台照搬。
从大会展示走向生产集群
全栈协同的难点通常不在单个组件，而在版本组合和责任边界。建议采用小规模节点池开始验证，并保留以下交付物：
- 固化操作系统、内核、固件、驱动、容器运行时和 AI 框架的版本矩阵。
- 为每次升级运行同一套冒烟、性能、稳定性和安全测试。
- 使用节点标签、污点和资源配额隔离尚未完成认证的环境。
- 记录性能基线及测试条件，避免只比较缺少上下文的单个吞吐数字。
- 明确操作系统、硬件、驱动、框架与应用团队之间的故障归属和升级窗口。
openKylin 与海光所代表的协同方向，本质上是在缩短国产智算平台从硬件可用到业务可交付的距离。对采用方而言，判断底座是否成熟的标准也应落到工程结果上：能否自动部署、能否稳定调度、能否量化验收，以及升级失败后能否快速定位和回退。