关于 K3 异构 AI Runtime 调度的一些调研和想法
这篇文档整理了我最近对 K3 异构 AI Runtime 的调研和一些实验想法。最后一部分是我对 SpineRuntime / X100 Runtime 调度相关源码的开放建议。
资料核对日期：2026 年 8 月 11 日。
我想研究什么
我目前在进迭时空 K3 平台上做异构 AI Runtime 和动态调度实验。目前最关心的问题是：
在沿用 K3 官方 Tile-SPMD / A100 Task 执行模型的前提下，Runtime 能不能结合 A100 的队列和资源状态、PMU / Trace 反馈、OS 提供的资源信息，为多模型、多进程 workload 更灵活地分配 A100 计算资源？
简单来说，我想看 Runtime 在“当前哪个核更空闲”之外，能否知道“当前哪个核更适合这个任务”。
AI workload
↓
SpineRuntime / X100 Runtime
↓
A100 计算资源
↑
Queue 状态 + PMU / Trace + OS 资源信息
当前困难
K3 AI 软件栈中与任务调度相关的实现和源码暂未公开。由于缺少 Task、Scheduler 和资源管理的内部接口，我在 StarryOS 上开展的工作暂时难以完整接入 K3 官方开发生态。
目前如果不公开的思路
我会继续使用自研算子库和 Runtime 推进实验，先跑通现有执行链路，再引入 PMU 数据，研究 queue-aware、PMU-aware 等动态调度策略。后续如果官方开放相关源码或扩展接口，再逐步适配 K3 官方 Runtime。
从公开资料里看到的 K3 Runtime
K3 论文里的调度方式
进迭时空的 K3 公开论文《SpacemiT K3: A RVA23 RISC-V AI CPU with 60 TOPS AI Compute》 对软件栈写得很清楚。ONNX Runtime 私有后端和 tile-based Triton 编译器最后会共用 Runtime、线程和内存优化体系。X100 Runtime 负责把产生的 tile-level task 送到 A100 执行。
论文公开版本里用了一个直观的策略：把 task 发给当前负载较低的 A100 cluster thread group。论文还提到了后续的 topology-aware scheduling。
这个策略可以作为我实验里的官方 baseline。它反映的是论文当时的实现。当前 libspert 里的算法可能已经有了变化，这一点还需要官方确认。
在 SpineRuntime / X100 Runtime 源码尚未公开的情况下，我准备先做一组黑盒实验，观察 Runtime 是怎样判断“核心负载”的。它可能只看自己的 workload 和队列深度，也可能会读取 Linux 报告的 CPU 利用率。更理想的情况是，Runtime 能识别计算型、内存型等任务特征，并结合 PMU 信息选择更合适的核心或 cluster。
| 编号 | 实验场景 | Runtime 内部负载 | 外部硬件负载 | 主要观察点 |
|---|---|---|---|---|
| E0 | Baseline：Runtime 和硬件都空闲 | 低 | 低 | 记录官方策略在无干扰时的基准行为 |
| E1 | External hog：用 Runtime 之外的任务占用硬件 | 低 | 高 | 看 Runtime 能否感知队列之外的实际硬件压力 |
| E2 | Runtime workload：通过 Runtime 提交并持续运行任务 | 高 | 高 | 看 Runtime 怎样记录已提交任务和实际 CPU 占用 |
| E3 | Waiting workload：在 Runtime 里堆积等待任务，尽量保持硬件空闲 | 高 | 低 | 看 Runtime 能否区分“队列很长”和“硬件很忙” |
目前已经知道SpineRuntime 已经公开了的能力
最新公开的 SpineRuntime 仓库和中文文档 已经给出了一套完整度很高的编程模型：
| 公开概念 | 我对它的理解 |
|---|---|
BackendHandle | 代表一个硬件 Backend，可以把 K3 和 generic/qemu 等环境分开 |
Stream | Runtime 分配多核资源和做资源隔离的主要单位 |
StreamConfig::core_ids | 应用可以提交偏好的物理核 ID |
Grid → Tiles | 把一次计算拆成多个 Tile 执行 |
Future | launch() 返回的异步完成标记 |
Barrier / Event / spawn / join / yield | Tile 可以等待、唤醒、创建子任务和协作式让出计算核 |
| Core Coordinator | 在多个 Stream 和多个进程之间分配计算核 |
runtime_stats() | 获取 Runtime 当前的资源快照，适合调试和测试 |
spert_abi.h | 给编译器、MLIR 等工具使用的 C ABI |
SpineRuntime 的资源竞争调度文档 还给了一个很具体的 FIFO 例子。一个先到的 4 核申请会继续等待，后到的 2 核申请即使碰巧有 2 个空闲核，也不会越过前面的申请。
如果试验确认除了非e3猜想再看看PMU是否能不能帮上忙(提供给我的数据能用到)
两组核的队列长度可能一样，实际压力却差得很多。例如，一组 workload 正在大量访问内存，另一组主要做计算。只看队列长度，Runtime 看不出这种差异。
我准备先让每类 task 单独运行，记下正常执行时间和可用的 PMU 数据。接着让不同 task 并发运行，看它们变慢了多少，同时观察 PMU 变化。如果这些信号确实能提前反映干扰，就可以尝试用它们预测任务执行时间，然后帮助 Runtime 选核。
已有工作中，Caladan 研究了微秒尺度的干扰检测和资源分配，OSML 使用 IPC、cache miss 和 memory footprint 等信息调整共置服务的资源。这些研究说明了这条路值得尝试，具体效果仍需要在 K3 上测出来。
PMU 数据也不能直接拿来就用。硬件 counter 数量有限，同时监测的事件太多时会发生 multiplexing。采样窗口太短也容易被 cache eviction 和 context switch 这类瞬时影响干扰。Linux perf_event_open(2) 专门提供了 time_enabled / time_running 来辅助估算 multiplexed event；OSDI 2025 的 Tintin 也专门讨论了计数器复用误差和数据归属的不确定性。
我会先把采样间隔、数据归一化、置信度和采样开销测清楚，避免用一次 PMU 差值直接决定任务去哪里执行。
K3 公开论文已经确认 X100 和 A100 都有独立的 RISC-V Trace encoder，支持 N-Trace 和 ownership event message。K3 / X100 的 Linux perf 目前也能读取部分 PMU 事件。不过，进迭论坛里的 PMU 事件映射讨论 显示，部分通用事件存在映射问题，详细 PMU 事件对照表也还没有对外提供。所以在实验前，需要先确认哪些 cache、memory、pipeline 或 vector event 真的可用。
X100 / A100 之间的迁移要考虑上下文兼容性
X100 和 A100 都属于 64-bit RISC-V 软件体系。这里主要需要处理 VLEN 和 ISA capability 差异。X100 的 VLEN 是 256，A100 的 VLEN 是 1024，它们对 Hypervisor 等扩展的支持也不完全相同。K3 论文明确提到，不同 VLEN 带来的 vector context 差异会限制跨核迁移。
RISC-V Vector 规范 也提到，带有 active vector state 的线程上下文，通常无法在 VLEN 或 ELEN 不同的 hart 之间执行中迁移。
我准备从约束更清楚的场景开始：
- 在 task / tile 开始前选好兼容的执行域；
- 调整尚未执行的 work descriptor 的位置；
- 在无活跃 vector state、显式 safe point 或 task boundary 上尝试跨域继续执行。
这样能先把 task placement 的基本问题测清楚，也可以避开 active RVV thread 直接迁移带来的硬件上下文限制。
希望进迭时空开放的内容
进迭时空团队您好：
我希望尽量在 K3 官方 task / runtime model 上做调度实验。这样可以直接复用已有的任务执行、同步和内存管理能力，也能让实验结果和官方软件栈保持兼容。
以下内容和 A100 Task 调度直接相关，对我的实验帮助最大：
libspert中spacemit-k3Backend 和 Runtime Scheduler 相关源码；- A100 Tile / Task 的 descriptor、内部状态和生命周期，包括 ready、running、waiting、completed 和 cancelled；
- Stream 创建、A100 compute-core grant / release，以及多 Stream / 多进程 Core Coordinator；
- Tile enqueue / dequeue、worker dispatch、core / resource selection、Future completion，以及 Barrier / Event /
spawn/join的调度逻辑； - Scheduler 用来判断 A100 load、availability、task placement 和公平性的状态与接口；
- 和安全调度有关的 scratchpad / TCM、memory dependency、AI-DMA 及其他资源约束接口；
- 如果条件允许，也希望公开 X100 / A100 上适合 Runtime profiling 和资源干扰分析的 PMU 事件定义、编码和已知限制；
- 让上述修改可以重新编译、链接和部署的必要源码、构建脚本、依赖接口和工具链说明。
最后这一项很重要。开放的调度代码需要形成可编译的闭环，这样才能把修改后的 Runtime 放回实验环境做真实验证。
完整 Runtime 如果暂时不方便开放，单独开放 spacemit-k3 Backend、Task model、Core Coordinator 和一个 reference scheduler，已经可以支持大部分调度实验。
我可以回馈哪些内容
实验主要会在 StarryOS 上完成，运行环境与 Linux / Bianbu 有差异。测试依然使用真实 K3 硬件和官方 Task 模型，可以为 Runtime 调度、PMU 观测和多 workload 竞争提供实机参考。结果中会清楚标注实验环境和适用范围。
我计划回馈以下内容：
- 可重现的 Benchmark、PMU / Trace 分析和调度策略对比；
- queue-aware、PMU-aware 等 Scheduler 原型和 StarryOS 适配经验；
- 可公开的实现、文档和实验结论。
相关成果会尽量回馈到进迭时空软件生态。同时，我也会将通用的 OS 机制、K3 适配和使用文档贡献给 StarryOS 社区。
最后
如果完整 Runtime 开源还需要时间，Scheduler extension point、Task / Resource headers、reference scheduler 和 PMU 事件定义中的任意一部分，都会对这项实验有很大帮助。
感谢阅读。