分工和协作

协作项目

本项目与关于我编程然后运行这件事 / project3136859 进行合作。两个项目关注 K3 异构系统中的不同部分：合作项目主要负责 K3 上 RT 核实时任务、通用大核 X100 的大部分控制路径以及核间通信；本项目主要负责 K3/K3x 上 AI 算力的调度、A100/X100 AI 执行路径探索，以及 StarryOS 的 K3 板级适配和驱动工作。

这两个方向是互相依赖的。我的工作解决“AI 算力如何被组织、提交、调度和执行”的问题；合作项目解决“这些 AI 算力在现实系统中如何被用好”的问题。以机器人、无人设备、实时控制系统这类场景为例，AI 推理结果必须被低延迟触发、传递和接入 RT/X100 的控制闭环，才能真正转化为动作、决策和控制效果。AI 算力如果没有 RT 核实时任务、X100 控制路径和核间低延迟通信支撑，对外界的输出就只能停留在离线计算或单点 demo；实时控制系统如果没有可调度的 AI 算力，也难以承接更复杂的感知、推理和决策任务。因此两部分缺一不可。

合作项目中的 ovchannel 原本主要服务于 K3 多核心之间的通信。本项目在此基础上进行了复用和场景扩展：将 ovchannel 作为 AI DAG 任务的提交通道和 completion 回传通道，用于连接用户态 AI runtime、/dev/k3_airunner 内核驱动和内核侧 graph scheduler。

我的负责内容

我主要负责 K3 平台上的 AI 算力调度方向，目标是把 K3/K3x 上的 AI 算力发挥出来，并探索新异构模式下的调度方式和可能性。

本项目提供的是 AI 算力组织和调度能力，而这些算力要在真实系统里发挥作用，必须依赖合作项目负责的 RT 核实时任务、X100 控制路径和低延迟核间通信，把推理结果接入机器人等实际系统的控制流程。换句话说，我负责把算力调出来，合作项目负责让这些算力在现实任务中被用好。

具体工作包括：

设计用户态 AI runtime、UAPI、graph blob、tensor desc、kernel desc 和 backend candidate 的接口边界。
设计并实现内核侧 AI graph scheduler，把用户态提交的 DAG 解析成可调度任务链。
接入 CPU fallback、A100 IME MatMul 探针和后续 X100/A100 backend 的调度入口。
实现 /proc/set_ai_thread 等 AI 线程控制路径，用于处理 X100/A100 核心类型和向量宽度差异。
补齐 RISC-V V 扩展上下文保存恢复，使 IME 指令能够在多任务环境中安全运行。
完成 StarryOS 在 K3 真板上的板级适配和驱动工作，包括 UFS 启动路径、DMA cache 同步问题定位和相关驱动调试。

合作项目负责内容

合作项目侧主要负责 K3 异构系统中实时控制和通用计算控制相关的基础能力：

RT 核实时任务路径，用于承接对确定性和低延迟要求更高的控制任务，并让本项目提供的 AI 算力调度能力进入机器人、无人设备等现实系统的控制闭环。
通用大核 X100 的大部分控制逻辑，包括普通任务运行、调度控制和系统侧执行环境。
K3 多核心之间的通信机制，为不同核心之间传递任务、状态和控制消息提供基础设施。
ovchannel 等核间通信组件，为本项目后续复用为 AI DAG 任务通道提供了基础。

`ovchannel` 的复用方式

合作项目中的 ovchannel 解决的是 K3 多核心之间的通信问题。本项目也涉及多核之间、用户态和内核态之间的任务传递，因此将它复用为 AI runtime 的基础通信组件。

在本项目中，ovchannel 的使用方式是：

用户态 k3_aiRuntime 建立共享 channel。
/dev/k3_airunner 驱动校验并保活共享内存。
用户态通过 channel 发送 AiGraphSubmitEntry。
内核侧 scheduler 接收 DAG 任务并放入 ready queue。
graph 执行完成后，内核通过 channel 回传 completion token。

这样做的好处是可以复用已经验证过的共享内存通信模型，减少重新设计 ring/channel 的成本，同时也让 AI DAG 提交天然具备向多核任务通信扩展的空间。实际测试中，这条通道在 graph 提交、共享区保活和 completion 回传场景下表现稳定。

协作方式

对多核通信、共享内存和 channel 设计保持接口层面的复用，避免两边重复造类似的通信组件。
RT 核实时任务、X100 通用大核控制和核间通信由合作项目侧推进；K3 板级适配、AI 算力调度、UAPI 和 backend 接入由本项目侧推进。
本项目的 AI 算力调度依赖合作项目提供的低延迟控制和核间通信能力，才能进入机器人等现实实时任务场景；合作项目的实时任务和控制闭环也可以把本项目提供的 AI 算力作为可调用、可调度的计算资源。
对涉及 StarryOS 的问题，通过真板日志、QEMU 验证和最小测试程序交叉确认，避免只停留在接口设计层面。

比赛收获

对 K3 异构 AI 调度的理解

这次比赛最重要的收获，是认识到 K3/K3x 不能简单按“CPU + 外挂 NPU”的模式来处理。X100、A100、CPU fallback、IME、DMA、TCM 和实时控制路径共同构成了一个更复杂的异构系统。

因此 AI runtime 的核心不只是把某个算子跑快，而是要回答任务什么时候留在 X100，什么时候进入 A100，什么时候回退到 CPU，以及这些选择如何不影响系统中的实时任务。

对系统边界的理解

用户态应该理解算子语义，内核态应该负责资源裁决和执行秩序。这个边界在项目推进中越来越清晰：

用户态负责 graph 构建、tensor 描述、算子属性和 backend candidate。
内核态负责 DAG 调度、共享内存校验、线程核心类型、completion 和错误返回。
backend 负责在 CPU/X100/A100 路径上完成具体计算。

这个分层让后续接入 llama.cpp、A100 IME backend 和多核心负载均衡时有比较清楚的扩展方向。

k3x-HERA-RT