Update README.md
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 调度优化机制，至少完成一种） a.结合 CPU affinity 与 cgroup cpuset 策略，将推理服务的工作线程池统一绑定至指定核心集合（llama.cpp 可通过 –cpu-mask / –cpu-range 配合 -t / -tb 参数进行线程与 CPU 绑定控制），降低线程迁移与抢占导致的 V 状态保存/恢复频率（入门级方案，同等有效）； b.基于 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 硬件。
可选完成项 c.探索用户态-内核调度提示接口设计（如通过 sched_setattr 扩展 flag 或自定义 ioctl），允许推理框架向调度器声明计算阶段，不限定接口形式； d.与 x86（AVX2/AVX-512）平台进行横向对比，定量分析 RVV VLA 设计在V 状态切换问题上的特殊性； e.向 llama.cpp 或 Linux 内核上游社区提交相关补丁或 RFC，附上链接。
项目代码（40 分） a)代码功能实现度 ·实现 V 状态上下文切换开销的量化分析工具，能够统计 V 状态保存/恢复次数、相关内核路径（如 riscv_vstate_save）调用频次或 dirty V线程被抢占事件，并量化其开销（10 分） ·实现至少一种 V 状态感知调度优化策略，功能完整、可正常运行（15 分） b)代码实现正确性与性能 ·在不少于 2 种并发场景下，推理吞吐（TPS）、平均 TTFT 或 P95 TTFT 相比统一基线有稳定、可重复的改善；吞吐略降但尾延迟显著改善者可酌情给分（10 分） c)代码质量与风格 ·代码结构清晰，关键逻辑有注释，提供完整的构建与运行说明（5 分）
技术报告（40 分） a)设计方案：V 状态切换问题分析准确，调度优化方案设计清晰，能够说明与现有 Linux 调度机制（CFS、lazy save）的关系（10 分） b)实现方案：实现细节描述完整，包含系统架构图或关键流程图，对已有相关工作（sched_ext、RVV 推理优化等）有准确调研与引用（10 分） c)运行效果/测试结果：测试数据规范（含测试环境描述、统一基线配置说明、均值与标准差、各并发档位结果），实验可复现，提供演示视频（3–5 分钟）；正式性能评分所采用的数据须来自真实 RVV 1.0 硬件，QEMU 数据如提供，仅作为功能验证或补充分析材料，需与真实硬件数据分开呈现，不计入性能收益得分（10 分） d)特色创新：方案是否提出新的调度原语、用户态-内核协同机制，或对问题有更深层次的分析与拓展（10 分）
开发过程（20 分） e)代码提交情况：Git 提交历史规范，工作量分布合理，提交信息清晰，体现迭代过程（15 分） f)团队协作情况：成员分工明确，协作有效（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
版权所有：中国计算机学会技术支持：开源发展技术委员会 京ICP备13000930号-9 京公网安备 11010802047560号
赛题题目：面向 RISC-V Vector 扩展的大语言模型推理并发调度优化（高校赛题）
赛题说明：
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 调度优化机制，至少完成一种） a.结合 CPU affinity 与 cgroup cpuset 策略，将推理服务的工作线程池统一绑定至指定核心集合（llama.cpp 可通过 –cpu-mask / –cpu-range 配合 -t / -tb 参数进行线程与 CPU 绑定控制），降低线程迁移与抢占导致的 V 状态保存/恢复频率（入门级方案，同等有效）； b.基于 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 硬件。
可选完成项 c.探索用户态-内核调度提示接口设计（如通过 sched_setattr 扩展 flag 或自定义 ioctl），允许推理框架向调度器声明计算阶段，不限定接口形式； d.与 x86（AVX2/AVX-512）平台进行横向对比，定量分析 RVV VLA 设计在V 状态切换问题上的特殊性； e.向 llama.cpp 或 Linux 内核上游社区提交相关补丁或 RFC，附上链接。
评分细则（明确评审角度、标准和分值范围）：
项目代码（40 分） a)代码功能实现度 ·实现 V 状态上下文切换开销的量化分析工具，能够统计 V 状态保存/恢复次数、相关内核路径（如 riscv_vstate_save）调用频次或 dirty V线程被抢占事件，并量化其开销（10 分） ·实现至少一种 V 状态感知调度优化策略，功能完整、可正常运行（15 分） b)代码实现正确性与性能 ·在不少于 2 种并发场景下，推理吞吐（TPS）、平均 TTFT 或 P95 TTFT 相比统一基线有稳定、可重复的改善；吞吐略降但尾延迟显著改善者可酌情给分（10 分） c)代码质量与风格 ·代码结构清晰，关键逻辑有注释，提供完整的构建与运行说明（5 分）
技术报告（40 分） a)设计方案：V 状态切换问题分析准确，调度优化方案设计清晰，能够说明与现有 Linux 调度机制（CFS、lazy save）的关系（10 分） b)实现方案：实现细节描述完整，包含系统架构图或关键流程图，对已有相关工作（sched_ext、RVV 推理优化等）有准确调研与引用（10 分） c)运行效果/测试结果：测试数据规范（含测试环境描述、统一基线配置说明、均值与标准差、各并发档位结果），实验可复现，提供演示视频（3–5 分钟）；正式性能评分所采用的数据须来自真实 RVV 1.0 硬件，QEMU 数据如提供，仅作为功能验证或补充分析材料，需与真实硬件数据分开呈现，不计入性能收益得分（10 分） d)特色创新：方案是否提出新的调度原语、用户态-内核协同机制，或对问题有更深层次的分析与拓展（10 分）
开发过程（20 分） e)代码提交情况：Git 提交历史规范，工作量分布合理，提交信息清晰，体现迭代过程（15 分） f)团队协作情况：成员分工明确，协作有效（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