系统创新
面向openEuler的自适应资源管控Agent（社区赛题）
基于eBPF的系统异常观测与根因定位工具（社区赛题）
面向openKylin的智能体记忆提取与精准遗忘机制（社区赛题）
openKylin操作系统启动性能分析与优化（社区赛题）
面向多智能体的操作系统级执行时（Agent Runtime）（高校赛题）
面向 RISC-V Vector 扩展的大语言模型推理并发调度优化（高校赛题）
基于跨机互联总线的高性能 RPC 系统（高校赛题）
面向智能机器人的AIOS（高校赛题）
基于大模型 Coding Agent 的复杂移动应用自动迁移与评测（社区赛题）
应用创新
一种面向多智能体协作的低开销通信、状态传递与共享记忆机制（社区赛题）
基于openvela的新平台适配与AI Agent智能应用开发（社区赛题）
基于OpenHarmony的多模态智能体工业现场多端协同作业系统（社区赛题）
研究创新
面向开源操作系统的大语言模型PD分离容器化推理系统设计与优化（高校赛题）
MaaS平台中模型混部的资源编排与性能优化（高校赛题）
面向智能体的内存管理系统设计与实现（高校赛题）
基于深度强化学习的云-边-端异构计算资源管理调度方法（高校赛题）
面向开放环境的具身操作系统韧性增强技术 

RISC-V Vector 扩展（RVV 1.0）已被纳入 RVA23 Profile 强制规范（2024 年 10 月批准），正在成为 RISC-V 处理器的标准配置。2025 年初，llama.cpp 等主流大语言模型（LLM）推理框架完成了 RVV 1.0 适配，使得在 RISC-V 设备上运行 LLM 成为现实。

然而，RVV 的引入带来了值得单独研究的操作系统调度挑战。x86 AVX-512 与 ARM SVE 等架构同样存在扩展状态上下文管理问题，但 RVV 的变长寄存器（VLEN 由实现定义，最大可达数千 bit）与 Vector Length Agnostic（VLA）设计使其系统代价与管理复杂度显著不同。在RISC-V 架构中，每个 hart 拥有 32 个向量寄存器（v0–v31），单次完整 V 状态保存需要512 字节至 1024 字节以上的内存写入。Linux 通过 VS 状态位配合惰性上下文管理策略（lazy save / restore）降低不必要的状态切换开销，但在多向量密集型线程并发运行时，当向量状态为 dirty 的线程被抢占，仍会触发 V 寄存器组的完整保存，在 LLM 推理这类高强度持续向量计算场景下积累出不可忽视的调度开销。

LLM 推理是典型的高强度持续向量计算场景：prefill 阶段执行大规模矩阵乘（GEMM），decode阶段执行矩阵向量乘（GEMV），两个阶段均需长时间持续占用向量寄存器。在推理服务器同时处理多个并发请求时，Linux 默认调度策略（CFS）对向量密集型推理线程与普通线程一视同仁，导致推理线程在计算关键路径上被频繁抢占，积累的 V 状态切换开销造成整体吞吐下降与尾延迟（P99 TTFT）恶化。

目前，学术界和工业界均缺乏专门针对 RISC-V V 状态感知的 LLM 推理调度策略，这是一个兼具理论价值与工程意义的开放问题。本赛题以 RISC-V Vector 扩展为实验平台，其核心关注点——具有高代价扩展状态的处理器在 AI 推理负载下的 OS 调度协同——同样适用于 x86 AMX/AVX-512、ARM SVE2 等架构，参赛成果具备向其他平台迁移的理论基础。

赛题要求：

基于 openEuler、openKylin、OpenHarmony 等至少一个国内主流开源操作系统开发，鼓励在更多Linux发行版上编译、运行和测试。
问题量化（必须完成）
在 RISC-V RVV 1.0 环境下，可采用内核 tracepoint、kprobe、eBPF 程序、perf/PMU 或其他等价、可复现的系统观测手段，对 V 状态保存/恢复路径插桩（如挂载内核函数 riscv_vstate_save），量化多并发 LLM 推理场景下 V状态上下文切换的实际开销，建立其与并发请求数、模型规模之间的量化关系，分析该开销对推理吞吐与延迟的影响。若实验平台 PMU 支持相关硬件事件，可作为辅助验证手段，但非必要。
调度优化实现（必须完成，以下策略为推荐参考路径，允许使用其他等价的OS 调度优化机制，至少完成一种）
结合 CPU affinity 与 cgroup cpuset 策略，将推理服务的工作线程池统一绑定至指定核心集合（llama.cpp 可通过 --cpu-mask / --cpu-range 配合 -t / -tb 参数进行线程与 CPU 绑定控制），降低线程迁移与抢占导致的 V 状态保存/恢复频率（入门级方案，同等有效）；
基于 sched_ext（Linux 6.12+ 的 BPF 可扩展调度框架）实现 V 状态感知调度器，或基于 sched_setattr / affinity / cpuset 等现有接口对持有dirty V 状态的推理线程进行调度提示与放置优化，减少同一时间窗口内的 V 状态切换次数（进阶方案）；
性能评测（必须完成）
以 llama.cpp server 模式为基准，使用不超过 3B 参数量的量化模型（如Llama-3.2-1B/3B Q4_K_M），在 2、4、8 并发请求场景下，采用统一基线配置（相同模型与量化版本、相同 --threads 参数、相同输入长度分布、CPU频率策略固定为 performance governor），每组配置至少重复 3 次，报告均值与标准差，对比优化前后的推理吞吐（TPS）、平均 TTFT 与 P95 TTFT（毫秒）。性能评测数据须来自真实 RVV 1.0 硬件。
可选完成项
探索用户态-内核调度提示接口设计（如通过 sched_setattr 扩展 flag 或自定义 ioctl），允许推理框架向调度器声明计算阶段，不限定接口形式；
与 x86（AVX2/AVX-512）平台进行横向对比，定量分析 RVV VLA 设计在V 状态切换问题上的特殊性；
向 llama.cpp 或 Linux 内核上游社区提交相关补丁或 RFC，附上链接。
评分细则（明确评审角度、标准和分值范围）：

项目代码（40 分）
代码功能实现度
实现 V 状态上下文切换开销的量化分析工具，能够统计 V 状态保存/恢复次数、相关内核路径（如 riscv_vstate_save）调用频次或 dirty V线程被抢占事件，并量化其开销（10 分）
实现至少一种 V 状态感知调度优化策略，功能完整、可正常运行（15 分）
代码实现正确性与性能
在不少于 2 种并发场景下，推理吞吐（TPS）、平均 TTFT 或 P95 TTFT 相比统一基线有稳定、可重复的改善；吞吐略降但尾延迟显著改善者可酌情给分（10 分）
代码质量与风格
代码结构清晰，关键逻辑有注释，提供完整的构建与运行说明（5 分）
技术报告（40 分）
设计方案：V 状态切换问题分析准确，调度优化方案设计清晰，能够说明与现有 Linux 调度机制（CFS、lazy save）的关系（10 分）
实现方案：实现细节描述完整，包含系统架构图或关键流程图，对已有相关工作（sched_ext、RVV 推理优化等）有准确调研与引用（10 分）
运行效果/测试结果：测试数据规范（含测试环境描述、统一基线配置说明、均值与标准差、各并发档位结果），实验可复现，提供演示视频（3–5 分钟）；正式性能评分所采用的数据须来自真实 RVV 1.0 硬件，QEMU 数据如提供，仅作为功能验证或补充分析材料，需与真实硬件数据分开呈现，不计入性能收益得分（10 分）
特色创新：方案是否提出新的调度原语、用户态-内核协同机制，或对问题有更深层次的分析与拓展（10 分）
开发过程（20 分）
代码提交情况：Git 提交历史规范，工作量分布合理，提交信息清晰，体现迭代过程（15 分）
团队协作情况：成员分工明确，协作有效（5 分）
赛题联系人：

薛老师 xueruini@uestc.edu.cn 

参考资料：

RISC-V Vector Extension Specification v1.0 https://github.com/riscv/riscv-v-spec
Linux Kernel: Vector Extension Support for RISC-V. https://docs.kernel.org/arch/riscv/vector.html
Linux sched_ext Documentation (Linux 6.12+). https://docs.kernel.org/scheduler/sched-ext.html
llama.cpp RVV 1.0 k-quant kernels (PR #12530, merged 2025-03). https://github.com/ggml-org/llama.cpp/pull/12530
V-Seek: Efficient LLM Inference on 64-core RISC-V Platform. https://arxiv.org/abs/2503.17422
参赛资源支持：

说明：以下内容仅为帮助参赛队评估实现可行性的参考配置与资源示例，原则上由参赛队自行准备；除大赛组委会后续另行明确通知外，不表示主办方统一、免费或默认提供相关硬件、模型、开发环境与运行条件。

功能验证平台（调度策略逻辑与 eBPF 程序正确性验证）：QEMU 9.x 仿真：-cpu rv64,v=true,vlen=256（或 vlen=512），无需实体硬件，可完成必做项 1、2 的功能实现与验证。
性能评测平台（TTFT、TPS 数据须来自此类环境）需采用实际硬件环境，如SpacemiT K1（BananaPi BPI-F3 / Milk-V Jupiter）：RVV 1.0，VLEN=256
报名要求
（一）系统创新赛道

本赛道重点围绕项目代码、开发过程数据、技术报告等几个方面对作品进行评审，现场答辩还将进一步考察报告情况及问题回答情况等。

（1）项目代码：主要从代码功能实现度、代码实现正确性与性能、代码质量与风格等方面进行评审；

（2）开发过程：主要从代码提交情况、团队协作情况等方面进行考查；

（3）技术报告：对参赛作品技术报告包括作品链接、设计方案、实现方案、运行效果/测试结果、演示视频、特色创新等内容进行评审。

作品要求
详见主页《初赛作品提交说明》。 

┌────────────────────────────────────────────────────────────────────────┐
│                   面向 RISC-V Vector 的 LLM 推理调度优化                 │
└────────────────────────────────────────────────────────────────────────┘
       │
       ├─► [40分] 项目代码
       │     ├─ 量化工具实现度 (10分) ──► 统计 V 状态切换/抢占事件及开销
       │     ├─ 调度优化功能性 (15分) ──► 至少实现一种机制且运行完整
       │     ├─ 正确性与性能益 (10分) ──► 吞吐或尾延迟有稳定、可重复改善
       │     └─ 代码质量与风格 ( 5分) ──► 结构清晰、注释完整、有构建说明
       │
       ├─► [40分] 技术报告
       │     ├─ 设计方案合理性 (10分) ──► 问题分析准确，阐明与 CFS/lazy save 关系
       │     ├─ 实现方案详实度 (10分) ──► 系统架构/流程图清晰，相关调研充分
       │     ├─ 测试结果可复现 (10分) ──► 规范的数据（含标准差）、真机数据、3-5分钟视频
       │     └─ 特色创新与拓展 (10分) ──► 新调度原语、深层次分析或软硬协同提示
       │
       └─► [20分] 开发过程
             ├─ Git 提交规范性 (15分) ──► 提交历史清晰，体现迭代过程与工作量
             └─ 团队协作有效性 ( 5分) ──► 成员分工明确，协作顺畅