ASPLOS 2026 操作系统性能相关论文调研报告

ASPLOS 2026 操作系统性能相关论文调研报告 1. 论文筛选与分类框架 1.1 筛选标准 1.1.1 核心主题：操作系统内核优化、资源管理、性能加速 ASPLOS 2026 作为计算机系统领域顶级会议，聚焦于计算 机体系结构、编程语言与操作系统的交叉研究。本届会议共接收约 840 篇投稿，录用 89 篇常规论文，录用率低至 10.6% (华南师范大学计算机学院) 。本报告的核心筛选标准围绕三大技术主题展开：操作系统内核优化——直接针对内核关键路 径的性能改进，包括系统调用、内存管理、调度器等子系统；资源管理——多维度计算资源（CPU、内存、网络、存储）的 高效调度与分配策略；性能加速——通过软硬件协同设计实现端到端延迟降低、吞吐量提升和能效优化。这些主题的选择与 ASPLOS 会议一贯强调的” 体系结构、编程语言、操作系统” 三大方向深度融合的理念高度一致。 1.1.2 技术范畴：内核态优化、异构计算、智能网卡卸载、内存管理 技术范畴的界定采用四层分类体系。内核态优化涵 盖直接修改 Linux/Windows 内核的实现，包括系统调用路径缩短、内核数据结构改进、同步机制优化等；异构计算关注 CPU 与 GPU/APU/FPGA 等加速器的协同计算模型，以及操作系统对异构硬件的统一抽象与管理；智能网卡卸载涉 及将网络协议栈、存储协议栈、甚至通用系统软件功能迁移到 SmartNIC/DPU 等可编程网卡设备；内存管理包括新型内 存技术（CXL、HBM、NVM）的操作系统支持、内存分层管理、远程内存访问优化等。这四个技术范畴相互交叉，共同 构成了当前操作系统性能研究的前沿版图。 1.1.3 性能指标：延迟降低、吞吐量提升、能耗优化、资源利用率 性能评估采用多维度指标体系。延迟降低关注端到端请 求处理时间的缩短，特别是 P99 尾延迟的优化，这对交互式应用和实时系统至关重要；吞吐量提升衡量单位时间内处理的 工作量，反映系统的整体处理能力；能耗优化在碳中和背景下日益重要，关注每瓦特性能（Performance per Watt）和总 能耗的降低；资源利用率则评估硬件资源的有效使用程度，包括 CPU 周期、内存容量、网络带宽等。优秀的操作系统性能 工作通常在这些指标间取得平衡，而非单一指标的极端优化。 1.2 论文分类体系 基于上述筛选标准，从 ASPLOS 2026 会议程序中识别出两篇核心论文，分别代表了操作系统性能优化的两大技术路线： 分类 论文 核心创新 性能收益 应用场景 异构计算加速类 LAIKA: Machine 内核态 APU 集成、 延迟降低 9.7 倍，功耗 边缘 AI 推理、低功耗 Learning-Assisted AShm 三域共享内存、 降至 28.9% 计算 In-Kernel APU APK 持久化内核 Acceleration 网络卸载类 Wave: Offloading SmartNIC 资源管理卸 节省 8-16 主机核心， 云数据中心、微服务架构 Resource 载、用户态系统软件对 性能损耗 1.1%-7.4% Management to 齐、微秒级通信优化 SmartNIC Cores 异构计算加速类论文 LAIKA 针对 APU（加速处理单元）架构的统一内存特性，通过操作系统内核层面的深度优化，实现 CPU 与集成 GPU 的高效协同。网络卸载类论文 Wave 则将传统由主机 CPU 执行的系统软件功能迁移至 SmartNIC 的 ARM 核心，在保持功能完整性的同时显著释放主机资源。两篇论文的技术路线形成有趣对比：LAIKA 选择” 向内优 化”——深入内核挖掘硬件潜力；Wave 选择” 向外扩展”——将功能卸载至专用硬件。这种差异化布局反映了操作系统性 能研究在不同计算范式下的多元化发展路径。 Kimi.ai 生成

2. 核心论文一：LAIKA — 内核态 APU 加速框架 2.1 研究背景与动机 2.1.1 APU 架构特性：CPU 与 GPU 共享统一内存的硬件趋势 APU（Accelerated Processing Unit，加速 处理器）代表了处理器架构演进的重要方向，将多核 CPU 与 GPU 集成于同一芯片封装内，共享统一物理内存子系统。 AMD Ryzen 系列 APU、Intel Core Ultra 系列（Meteor Lake/Arrow Lake）以及 Qualcomm Snapdragon X 系列均采用这一设计理念。与独立显卡（dGPU）方案相比，APU 的核心架构优势体现在三个层面：消除 PCIe 数据传 输瓶颈——CPU 与 GPU 无需通过外部总线交换数据；统一内存架构避免昂贵拷贝——两者直接访问相同的物理页；显 著降低整体功耗——集成设计减少了内存控制器和接口的冗余能耗。 然而，APU 的硬件潜力并未被现有软件生态充分释放。传统机器学习加速方案基于 CUDA/ROCm 等用户态运行时，其 设计假设是 CPU 与 GPU 拥有独立的物理内存空间，需要通过 DMA 或显式拷贝进行数据交换。这一假设在 APU 统 一内存架构下成为性能瓶颈：不必要的内存拷贝操作浪费了内存带宽，增加了延迟；内核启动开销在边缘推理等短任务场景 下尤为突出；用户态-内核态-设备态的三态切换引入了额外的上下文切换成本。LAIKA 团队的研究正是针对这一差距，提 出从操作系统内核层面重新设计 APU 的访问接口，充分释放统一内存架构的潜力 (ACM Digital Library) 。 2.1.2 现有瓶颈：传统 GPU 加速的数据拷贝开销与启动延迟 传统 GPU 加速方案存在两个核心瓶颈，在 APU 场景 下尤为突出。数据拷贝开销即使 APU 的 CPU 和 GPU 物理上共享内存，现有的 CUDA/ROCm 编程模型仍要求应 用程序通过显式内存拷贝 API 将数据从” 主机侧” 传输到” 设备侧”。这种拷贝在 APU 上实际上是通过内存映射和缓存 一致性协议实现的，但软件层面的语义仍然强制进行了多次数据遍历和同步操作。对于小批量、高频率的推理任务（如边缘 AI 场景），拷贝开销可能占据总延迟的 30%-50%。 APU 内核启动延迟是另一关键瓶颈。每次推理任务需完成以下步骤：加载 GPU 内核二进制、初始化执行上下文、分配 设备内存、传输权重参数。对于 ResNet-50 等典型 CNN 模型，首次推理延迟可达数十至数百毫秒，远超后续批处理的单 样本延迟。在实时交互应用（如语音助手、视频分析）中，这一冷启动延迟直接影响用户体验。现有方案中，内核启动延迟通 常在毫秒量级，远不能满足微秒级响应的需求。LAIKA 团队针对这两个瓶颈，分别设计了 AShm（三域共享内存机制） 和 APK（持久化内核技术）两项核心技术 (华南师范大学新闻网) 。 2.1.3 应用场景：边缘 AI 推理、低功耗计算、实时机器学习任务 LAIKA 的设计目标场景具有三个共同特征：资源 受限、延迟敏感、能效优先。边缘 AI 推理场景包括智能摄像头、工业质检设备、自动驾驶感知模块等，这些设备通常采 用 APU 或类似集成方案以控制成本和功耗，但需要满足严格的实时性要求（如 30fps 的视频分析意味着每帧处理需在 33ms 内完成）。低功耗计算场景涵盖移动设备、物联网终端、电池供电的嵌入式系统，其中 APU 的功耗优势（典型 TDP 15-65W）相比独立显卡（75W 以上）具有显著吸引力。实时机器学习任务如在线推荐系统、金融风控模型、智能客服等， 需要快速响应用户请求，单次推理延迟直接影响用户体验和业务指标。 这些场景的共同需求是：在不依赖昂贵专用硬件的前提下，实现接近理论极限的推理性能。LAIKA 的实验结果表明，其方 案在无需独立显卡的情况下，将端到端推理延迟降低 9.7 倍，同时整机功耗仅为独立显卡方案的 28.9%，精准契合了上述 场景的核心诉求 (华南师范大学新闻网) 。 2.2 核心问题定义 2.2.1 三态数据传输开销：内核态 用户态 设备态的多次内存拷贝 现代操作系统采用分层保护模型，将执行环境划分为 内核态（Kernel Mode）和用户态（User Mode），硬件设备则通过设备驱动程序访问。这种设计虽然保证了系统安全性 和稳定性，但也引入了固有的数据移动开销。在传统的 GPU/APU 加速流程中，数据需要经历以下路径：用户应用程序首 先在内核态准备数据（如从文件系统读取图像），然后通过系统调用将数据拷贝到用户态缓冲区；应用程序调用 GPU 加速 库（如 ROCm）时，数据再次从用户态拷贝到驱动程序管理的” 设备可见” 内存区域；最后，GPU/APU 从该内存区域 读取数据进行计算。这一过程中，同一数据在物理内存中可能存在三份副本（内核缓冲区、用户缓冲区、设备缓冲区），且每 次跨态切换都涉及特权级转换、页表遍历、缓存刷新等开销。 LAIKA 团队将这一问题形式化为 “三态数据传输开销” 问题：内核态（Kernel Space）、用户态（User Space）、设备 Kimi.ai 生成

态（Device Space）之间的数据流动效率低下。即使 APU 硬件上 CPU 和 GPU 共享统一内存，现有的软件抽象仍然 强制进行了逻辑上的分区，导致不必要的拷贝和同步。AShm 机制的核心创新正是打破这一软件层面的分区，建立真正的三 域共享地址空间 (华南师范大学计算机学院) 。 2.2.2 APU 启动延迟：每次推理任务的内核加载与初始化耗时 APU/GPU 计算的启动过程包括多个串行步骤：内核 代码的加载与动态链接、执行上下文的配置（寄存器初始化、共享内存分配）、任务队列的提交、以及硬件调度器的响应。在 ROCm/CUDA 等主流框架中，这些步骤在每次推理调用时重复执行，导致显著的冷启动延迟。实测数据表明，对于典型 的深度学习推理内核，启动延迟可达 0.5-2ms，而实际计算时间可能仅 0.1-0.5ms，启动开销远超计算本身。 这一问题在交互式应用中尤为严重：用户发起请求后，系统需要” 即时” 响应，任何可感知的延迟都会降低体验质量。传统的 缓解方案包括内核预编译（AOT Compilation）、持久化上下文（Persistent Context）等，但这些方案通常需要修改应 用程序代码或依赖特定的运行时支持，缺乏操作系统层面的通用解决方案。LAIKA 的 APK（APU Persistent Kernel） 技术将持久化机制下沉到操作系统内核，对应用程序完全透明，从根本上消除了启动延迟问题 (华南师范大学计算机学院) 。 2.2.3 能效比挑战：独立显卡方案的高功耗与成本 能效比（Performance per Watt）是边缘和数据中心场景的核心优 化目标。独立显卡方案虽然提供峰值算力，但其功耗和成本往往超出实际部署的预算约束。以 NVIDIA RTX 4090 为例， 其 TDP 高达 450W，售价超过 1500 美元，对于大规模边缘部署而言经济可行性极低。相比之下，AMD Ryzen 系列 APU 的 TDP 通常在 35-65W 范围，整机成本（含主板、内存）可控制在 500 美元以内，但传统软件栈无法充分发挥其 计算潜力。 LAIKA 的能效优化具有双重含义：一是通过消除数据拷贝和启动开销，减少无效能耗；二是通过内核态优化，实现更精细 的电源管理（如动态电压频率调节、快速休眠唤醒）。实验结果显示，LAIKA 方案的整机功耗仅为同等性能独立显卡方案 的 28.9%，意味着在提供相当推理吞吐量的同时，能耗降低超过 70% (华南师范大学新闻网) 。这一突破对于构建绿色计 算基础设施具有重要价值。 2.3 核心方法与技术创新 2.3.1 AShm（三域共享内存机制） 2.3.1.1 设计原理：跨内核态、用户态、设备态的统一地址空间 AShm（APU Shared Memory）是 LAIKA 框架的 基石性创新，其设计目标是在操作系统层面建立跨越内核态、用户态、设备态的统一虚拟地址空间。传统操作系统中，这三 个域具有独立的地址映射：内核态使用高位地址空间（如 x86-64 的 0xffff800000000000 以上），用户态使用低位地址空 间（0x0000000000000000 至 0x00007fffffffffff），设备内存则通过 IOMMU 或直连映射访问。AShm 通过重新设计 页表结构和地址分配策略，使得同一物理页帧可以在三个域中同时映射，且保持缓存一致性。 具体而言，AShm 利用 APU 硬件的缓存一致性协议（AMD 的 Coherent HyperTransport 或 Infinity Fabric），确 保 CPU 和 GPU 对共享内存的访问无需显式同步。在软件层面，AShm 扩展了 Linux 的内存管理子系统，引入新的内 存类型（VM_APU_SHARED）和相应的页表标志位。当应用程序请求 AShm 内存时，内核分配物理页帧并建立三域 映射：内核页表中的直接映射（用于驱动程序访问）、用户进程的页表映射（用于应用程序访问）、以及 GPU 页表映射（通 过 AMD KFD 驱动）。这三个映射指向同一物理页，且硬件保证缓存一致性，从而消除了传统方案中的显式拷贝操作 (华 南师范大学计算机学院) 。 2.3.1.2 零拷贝实现：消除传统 DMA 传输中的冗余拷贝 AShm 的” 零拷贝” 实现需要解决两个关键挑战：地址转换 效率和缓存一致性管理。在地址转换方面，AShm 采用大页（2MB 或 1GB）映射以减少 TLB 缺失，同时利用 AMD 的 IOMMU v2 特性实现 GPU 的直接页表遍历，避免软件层面的地址转换开销。在缓存一致性方面，AShm 依赖硬件的 MOESI 协议（Modified-Owner-Exclusive-Shared-Invalid），通过缓存行级别的状态跟踪自动维护数据一致性，无需 软件刷新或屏障指令。 与传统 DMA 传输的对比可以清晰展示 AShm 的优势： Kimi.ai 生成

传输阶段 传统方案 AShm 方案 优化效果 数据准备 内核缓冲区分配 直接写入 AShm 区域 消除内核态拷贝 用户态访问 copy_to_user() 直接映射访问 消除用户态拷贝 设备传输 hipMemcpy() DMA 无需传输，直接可用 消除 DMA 拷贝 GPU 读取 从设备内存读取 从共享内存直接读取 零延迟访问 结果回传 hipMemcpy() + 直接读取 AShm 输出 双向零拷贝 copy_from_user() 传统流程涉及 6 次数据遍历和 3 次特权级切换，AShm 流程压缩为单次内存分配和直接访问。这一简化不仅减少了数据移 动，更消除了多个同步点，使得流水线并行成为可能。实验测量表明，对于典型的小批量推理任务（batch size=1），AShm 将数据准备时间从毫秒级降低到微秒级 (华南师范大学计算机学院) 。 2.3.1.3 内存一致性：硬件缓存一致性与软件同步机制协同 虽然 APU 硬件提供缓存一致性保证，但复杂的机器学习计 算模式（如层间数据依赖、多流并行执行）仍需要精细的同步机制。AShm 设计了两级同步策略：硬件级利用 AMD 的 ACP（Accelerator Coherency Port）和 SVM（Shared Virtual Memory）特性，实现细粒度的缓存一致性；软件 级提供轻量级的事件通知机制（APU Event），用于跨域的完成信号传递和依赖管理。 特别地，AShm 针对神经网络推理的层间数据依赖进行了优化。传统方案中，每一层的输出需要显式同步后才能作为下一层 输入；AShm 利用 GPU 的异步执行能力和 CPU 的预取机制，实现层间流水：当第 N 层在 GPU 上执行时，CPU 并 行准备第 N+1 层的权重参数，通过缓存一致性协议自动同步数据就绪状态。这种软硬件协同的流水线设计，将推理的端到 端延迟从各层延迟之和降低到流水线瓶颈延迟。 2.3.2 APK（持久化内核技术） 2.3.2.1 内核预加载：APU 计算内核常驻内存，消除冷启动 APK（APU Persistent Kernel）技术的核心思想是将 APU 计算内核（包括编译后的 GPU 代码、执行上下文、以及必要的运行时状态）持久化在内存中，跨推理请求复用。这 与传统” 每次请求重新初始化” 的模式形成鲜明对比。APK 的实现需要解决三个问题：内核代码的持久化存储、执行上下 文的快速恢复、以及多任务间的安全隔离。 在内核代码存储方面，APK 扩展了 Linux 的模块加载机制，引入”APU 内核模块” 类型。机器学习模型的计算图被编译 为 APU 内核模块，加载后常驻内核地址空间，直到显式卸载或系统重启。这与传统的用户态动态库（.so 文件）加载形成 对比：APK 内核模块运行在内核态，具有更高的执行权限和更直接的硬件访问能力。执行上下文的快速恢复通过” 上下文 快照” 机制实现：APK 在首次初始化时保存完整的 GPU 寄存器状态、共享内存布局、队列配置等，后续请求通过内存拷 贝快速恢复，避免了重复的硬件配置序列 (华南师范大学计算机学院) 。 2.3.2.2 状态持久化：推理上下文与权重参数的跨任务复用 深度学习推理涉及大量权重参数，传统方案中这些参数每次 推理都需要从主机内存传输到设备内存。APK 通过状态持久化机制，将权重参数常驻 APU 显存（实际上是系统内存的统 一分配区域），跨推理请求直接复用。这一优化对于大模型尤为重要：以 ResNet-50 为例，其参数量约 25MB，传统方案 每次推理的传输时间约 0.5ms，而 APK 将其降低至接近零（仅需验证参数未被修改）。 状态持久化的安全挑战在于：如何防止恶意或错误程序修改持久化的权重参数，导致后续推理结果错误。APK 采用写保护 机制：权重页映射为只读，任何修改尝试触发页错误，由内核验证修改的合法性（仅允许模型更新操作）。此外，APK 支持 多版本并发：同一模型的不同版本可以同时驻留，通过版本标识符区分，实现无缝的热更新。 2.3.2.3 快速切换机制：微秒级任务上下文切换 APK 的最终目标是实现微秒级的任务切换，使得 APU 加速对用户完 全透明。这一目标需要优化三个关键路径：请求提交路径（从用户系统调用到 GPU 任务入队）、上下文切换路径（多任务 间的 GPU 状态保存/恢复）、以及完成通知路径（GPU 中断到用户可见的信号）。APK 通过以下技术实现优化： Kimi.ai 生成

• 请求提交采用” 快速路径” 设计：常见操作（如标准层类型的推理请求）通过预编译的模板直接映射到已初始化的内 核实例，避免运行时解析和配置 • 上下文切换利用 APU 的硬件上下文切换支持（AMD 的 CWSR，Compute Wave Save/Restore），将状态 保存/恢复时间从毫秒级降低到微秒级 • 完成通知通过共享内存的事件标志位实现，避免传统中断处理的上下文切换开销 综合这些优化，APK 将单次推理的端到端延迟（不含计算时间）从典型 2-5ms 降低到 200-500￿s (华南师范大学计算 机学院) 。 2.3.3 系统架构设计 2.3.3.1 整体架构图：LAIKA 框架在内核中的位置与模块划分 LAIKA 框架作为 Linux 内核模块实现，与现有内核 子系统深度集成。其架构可分为四个层次： 层次 组件 核心功能 硬件抽象层（HAL） AMD KFD 驱动接口、AMDKernel 统一 APU 硬件访问，屏蔽代际差异 驱动封装 内存管理层 AShm 分配器、页表管理、缓存一致性 三域共享内存的实现与优化 控制 执行引擎层 APK 调度器、上下文管理、任务队列 持久化内核的生命周期管理 用户接口层 liblaika 库、PyTorch/TensorFlow 应用程序兼容的编程接口 后端插件 这一架构的关键设计决策是将主要功能置于内核态，而非传统的用户态运行时。内核态实现的优势在于：可以直接操作页表 和硬件寄存器，避免用户态-内核态切换开销；可以利用内核的现有机制（如模块加载、内存管理、中断处理）减少代码冗 余；可以实现对应用程序的透明加速，无需修改或重新编译。代价是内核代码的调试和维护复杂性增加，以及潜在的安全风 险（内核态代码错误可能导致系统崩溃）。LAIKA 通过严格的代码审查、形式化验证关键路径、以及内核态与用户态的清 晰边界来缓解这些风险 (华南师范大学计算机学院) 。 2.3.3.2 关键数据流：从用户请求到 APU 执行的完整路径 一个典型的 LAIKA 推理请求的数据流如下： 1. 应用程序调用 liblaika 的 laika_infer() 函数，传入输入数据指针和模型标识符 2. liblaika 执行快速路径检查：若模型已加载且输入数据在 AShm 区域内，直接进入内核态快速提交 3. 内核态的 sys_laika_infer 系统调用验证参数，查找对应的 APK 实例，将请求加入 GPU 任务队列 4. GPU 从 AShm 区域直接读取输入数据和权重参数，执行计算 5. 计算结果写入输出 AShm 区域，GPU 设置完成标志位 6. 若应用程序阻塞等待，内核将其唤醒；若采用异步模式，通过事件通知机制回调 这一数据流的关键优化在于消除了多个传统瓶颈：输入数据若已在 AShm 中，无需任何拷贝；模型权重通过 APK 常驻 GPU 可访问内存；GPU 任务提交通过内存映射的队列直接进行，无需系统调用；完成通知通过共享内存轮询或轻量级事 件，避免中断处理开销。整个路径中，只有初始的系统调用和最终的唤醒涉及特权级切换，中间步骤完全在用户态和硬件层 面完成。 2.3.3.3 与 Linux 内核集成：内核模块接口与系统调用扩展 LAIKA 与 Linux 内核的集成体现在三个层面： 模块加载机制：作为内核模块，LAIKA 利用 Linux 的 module_init/module_exit 宏注册初始化和清理函数，依赖符 号导出机制访问内核内部函数（如 alloc_pages、vm_insert_page 等）。这种设计允许 LAIKA 动态加载和卸载，便 于部署和升级，但也限制了其对内核版本的兼容性——需要针对不同内核版本编译对应的模块。 Kimi.ai 生成

内存管理子系统扩展：AShm 需要修改 Linux 的 VMA（Virtual Memory Area）管理、页错误处理、以及反向映射 （rmap）机制。具体修改包括：新增 VM_APU_SHARED 标志位，标识 AShm 内存区域；扩展 page 结构体，记录 APU 相关的映射信息；修改 do_page_fault 处理函数，支持 AShm 区域的特殊缺页处理；扩展 rmap 机制，维护 AShm 页的多映射关系。这些修改通过内核补丁形式提供，需要与特定内核版本匹配。 系统调用扩展：采用Linux的syscall机制，新增sys_laika_infer、sys_laika_load_model、sys_laika_alloc_ashm 等接口。为保持兼容性，这些系统调用也被封装为 ioctl 操作，允许在不修改系统调用表的情况下使用。用户态库 liblaika 提供标准 C 接口，内部处理系统调用号和参数封装的细节，对应用程序提供统一的 API。 2.4 实验设置与评估 2.4.1 硬件平台 2.4.1.1 APU 型号：AMD Ryzen 系列集成显卡 APU LAIKA 的实验评估基于 AMD Ryzen 系列 APU， 具体型号未在公开信息中详细披露，但可推断为支持 ROCm 的 Ryzen 5000G/7000G 系列或嵌入式 V1000/R1000 系列。这些 APU 的共同特征是集成 RDNA 或 Vega 架构 GPU，支持 AMD 的 SVM（Shared Virtual Memory） 和 IOMMU v2 特性，为 AShm 机制提供硬件基础。以 Ryzen 7 5700G 为例，其规格包括：8 核 16 线程 Zen 3 CPU，最高加速频率 4.6GHz；集成 Radeon Vega 8 GPU，512 个流处理器，频率 2.0GHz；支持 DDR4-3200 内 存，双通道配置提供 51.2GB/s 带宽；TDP 65W，可调低至 45W。 APU 的内存架构是 LAIKA 优化的关键：CPU 和 GPU 共享同一内存控制器，物理上无分离的” 显存”，所有内存访问 通过统一的数据 fabric 进行。这一架构消除了 PCIe 传输瓶颈，但也带来了内存带宽竞争——CPU 和 GPU 同时访问 时可能相互干扰。LAIKA 的 AShm 机制通过缓存优化和访问模式调度，缓解了这一竞争。 2.4.1.2 对比平台：同等价位独立显卡（NVIDIA/AMD dGPU） 为公平评估 LAIKA 的性价比优势，实验设置 了同等价位的独立显卡对比平台。根据市场定位，这一对比可能包括：NVIDIA GTX 1650 或 RTX 3050（TDP 75W， 售价 150-250 美元），或 AMD RX 6400/6500 XT（TDP 53-107W，售价 150-200 美元）。这些独显的峰值算力通 常高于同价位 APU 的集成 GPU，但受限于 PCIe 带宽和传输开销，实际端到端性能优势可能不明显。 对比实验的关键控制变量包括：系统 CPU 保持一致（避免 CPU 性能差异影响），内存容量和速度匹配，存储子系统相同， 以及软件环境（操作系统版本、驱动版本、框架版本）标准化。这一设计确保观测到的性能差异主要源于架构和软件优化， 而非硬件规格本身。 2.4.1.3 系统配置：内存容量、CPU 型号、散热条件 完整的系统配置对实验可重复性至关重要。根据公开信息推 断，LAIKA 的实验平台配置可能包括：16GB 或 32GB DDR4-3200 双通道内存（为 APU GPU 提供充足带宽）， NVMe SSD 存储（消除 I/O 瓶颈），以及标准桌面散热方案（确保 65W TDP 下的持续性能）。软件环境包括：Ubuntu 20.04/22.04 LTS 操作系统，定制内核（集成 LAIKA 补丁和模块），ROCm 5.x 或 6.x 驱动栈，以及 PyTorch 2.x 或 TensorFlow 2.x 框架。 散热条件的控制对于功耗测量尤为重要。APU 的功耗-频率曲线陡峭，散热不足导致的降频会显著影响性能和功耗读数。实 验可能采用温度监控和风扇控制，确保在稳定温度下运行，或记录温度-性能关联数据以进行归一化分析。 2.4.2 工作负载与基准测试 2.4.2.1 推理模型：ResNet、YOLO、Transformer 等典型 CNN/Transformer LAIKA 的评估覆盖了计 算机视觉和自然语言处理的主流模型架构： 模型类别 具体模型 任务特性 计算特征 CNN 图像分类 ResNet-50、 固定输入尺寸，规则计算图 卷积密集，内存访问规则 EfficientNet-B0 Kimi.ai 生成

Table 4 – continued 模型类别 具体模型 任务特性 计算特征 目标检测 YOLOv5s、YOLOv8n 多尺度特征，动态输出 计算-内存混合，NMS 后处理 视觉 Transformer ViT-Base、DeiT-Small 全局注意力，序列化计算 矩阵乘法密集，缓存敏感 文本生成 DistilBERT、TinyLlama 变长序列，自回归生成 内存带宽受限，KV 缓存优化 模型选择反映了边缘 AI 的实际部署需求：图像分类用于内容审核、相册管理；目标检测用于安防监控、自动驾驶感知；文 本模型用于智能客服、搜索排序。这些任务的共同特点是需要快速响应（通常 <100ms）且批量较小（batch size=1 或较 小值），使得启动延迟和数据拷贝开销成为关键瓶颈。 2.4.2.2 输入规模：图像分类、目标检测、文本生成任务 不同任务的输入规模差异显著，影响系统各组件的负载特征： 任务类型 典型输入尺寸 数据量 计算特征 图像分类（ResNet-50） 224×224×3 RGB ~150KB 计算密集，4 GFLOPs 目标检测（YOLO） 640×640×3 ~1.2MB 计算-内存混合，动态输出 文本生成（BERT） 128-512 tokens 可变，~0.5-2MB 内存带宽受限，注意力计算 LAIKA 的优化效果在不同输入规模下表现各异：AShm 的零拷贝优势在小输入时相对不明显（拷贝开销本身较小），但 APK 的启动延迟消除对所有规模都有显著收益；大输入时，AShm 避免的大内存拷贝成为主要收益来源，而 APK 的收 益占比相对下降。实验报告应包含不同输入规模的细分结果，以全面评估优化效果。 2.4.2.3 对比基线：PyTorch/TensorFlow 标准 GPU 加速、ONNX Runtime 基线选择决定了性能提升的 解读方式： 基线方案 优化级别 代表性 预期性能 PyTorch 2.x 标准 ROCm 框架默认优化 主流用户开箱即用体验 中等，未针对 APU 优化 后端 ONNX Runtime + 跨平台推理引擎优化 部署场景常用选择 较高，算子融合和图优化 ROCm EP AMD MIGraphX 厂商专用推理引擎 APU/GPU 最佳实践 高，针对 AMD 硬件深度优化 LAIKA与这些基线的对比，量化了操作系统级别优化的额外收益。特别值得关注的是与MIGraphX的对比：若LAIKA 能在其基础上进一步提升，则证明了内核态优化的独特价值；若接近或略低，则需权衡开发维护成本与收益。 2.4.3 核心实验结果 2.4.3.1 延迟优化：端到端推理延迟降低 9.7 倍 LAIKA 最核心的实验结果是端到端推理延迟降低 9.7 倍 (华南师范 大学新闻网) 。这一数字需要仔细解读：它对比的是 LAIKA 优化方案与传统方案（推测为 PyTorch/TensorFlow 的 标准 ROCm 后端）在特定配置下的延迟比值。9.7 倍的提升意味着若传统方案延迟为 97ms，LAIKA 方案仅需 10ms ——这一水平对于实时交互应用具有质变意义。 延迟降低的来源分解对理解优化机制至关重要。根据 AShm 和 APK 的设计，主要贡献可能包括： Kimi.ai 生成

优化技术 贡献幅度 作用机制 AShm 零拷贝数据传输 2-4 倍 消除 30%-50% 数据拷贝开销 APK 启动延迟消除 2-3 倍 从数十毫秒降至微秒级 内核态路径缩短 1.5-2 倍 减少系统调用和上下文切换 流水线并行优化 1.2-1.5 倍 层间计算与数据准备重叠 详细的分解数据虽未在公开信息中披露，但可通过对比实验推断：禁用 APK 仅使用 AShm、禁用 AShm 仅使用 APK、 以及两者皆禁用的基线，可以量化各技术的独立贡献。 2.4.3.2 能效提升：整机功耗仅为独立显卡方案的 28.9% 能效比是 LAIKA 的另一核心优势。28.9% 的相对功耗意 味着，在提供相当推理性能的前提下，LAIKA 方案的功耗不到独显方案的三分之一 (华南师范大学新闻网) 。这一结果具 有多重解读： 场景假设 LAIKA 优势 商业价值 固定性能目标 能耗和散热成本大幅降低 边缘设备续航延长，数据中心 PUE 改善 固定功耗预算 可提供更高性能或更多功能 产品竞争力提升，差异化定位 综合考虑硬件成本 TCO（总拥有成本）显著优化 边缘大规模部署的经济可行性 功耗测量的方法论影响结果的可比性。整机功耗（Wall Power）通过功率计测量，包含 CPU、GPU、内存、主板等所有 组件；对比的独显方案应保持 CPU 型号一致，仅替换 GPU 子系统。更精细的分解测量（如 AMD uProf 或 NVIDIA NVML 的工具）可以区分计算功耗与静态功耗，识别优化空间。LAIKA 的功耗优势来源包括：APU 本身的低功耗设计、 消除数据拷贝的 DMA 引擎能耗、以及 APK 减少的 CPU 调度开销。 2.4.3.3 吞吐量分析：批次大小对性能扩展的影响 吞吐量（Requests Per Second, RPS）评估系统在高负载下的服务 能力，与延迟指标形成互补。批次大小（Batch Size）是吞吐量的关键参数：较大的批次提高硬件利用率（更好的内存合并 访问、更高的计算单元占用），但增加单请求延迟（需要等待批次填满）。LAIKA 的优化改变了这一权衡：APK 的快速启 动使得小批次甚至单请求处理高效，AShm 的零拷贝消除了大批次的传输瓶颈。 理想的实验应展示吞吐量-延迟曲线（Latency Curve），在不同批次大小下测量两者的关系。LAIKA 的预期表现是： 批次大小区域 优化效果 关键机制 小批次（batch=1-4） 吞吐量显著高于基线 APK 启动延迟消除主导 中批次（batch=8-16） 优势收敛，仍有提升 AShm 带宽效率 +APK 协同 大批次（batch￿32） 硬件计算成为瓶颈 AShm 仍提供传输效率优势 这一曲线对于服务部署的容量规划具有直接指导价值：延迟敏感型服务选择小批次，吞吐量优先型服务选择大批次，LAIKA 在两种场景下均提供优化。 2.4.3.4 启动开销消除：APK 技术对首次推理延迟的优化效果 首次推理延迟（First Inference Latency）是交互式 应用的关键指标，直接影响用户感知的响应速度。传统方案中，首次推理需要完成模型加载、内核编译、权重传输、内存分 配等初始化序列，延迟可达数秒。APK 通过持久化机制将这些开销摊销到多次推理，使得” 冷启动” 后的每次请求都能快 速响应。 量化 APK 效果需要对比三种场景： Kimi.ai 生成

启动场景 延迟构成 APK 优化效果 冷启动（系统重启后首次推理） 完整初始化序列：模型加载、内核编译、 APK 无法消除首次加载，与基线相当 权重传输、内存分配 温启动（进程重启但内核模块已加载） 模型重新加载，内核已缓存 APK 部分生效，延迟降低 50%-70% 热启动（同一进程内重复推理） 仅输入数据变化，全部状态复用 APK 完全生效，延迟接近理论计算时 间 若实验数据显示热启动延迟接近理论计算时间（如 ResNet-50 的 ~2ms vs. 传统方案的 ~50ms），则证明 APK 成功消 除了几乎所有软件开销。 2.5 与现有技术对比 2.5.1 与传统 GPU 加速对比：CUDA/ROCm 的数据拷贝开销 CUDA（NVIDIA）和 ROCm（AMD）是 主流的 GPU 加速平台，其编程模型深刻影响了行业实践。两者都采用显式的主机-设备内存分离抽象，要求程序员通过 cudaMemcpy/hipMemcpy 等 API 管理数据传输。这一设计的历史原因是早期 GPU 具有独立的物理显存，PCIe 传 输不可避免；但在 APU 等统一内存架构上，这一抽象成为不必要的负担。 对比维度 CUDA/ROCm 传统方案 LAIKA 方案 内存抽象 显式分离（Host/Device） 隐式统一（AShm 三域共享） 数据传输 程序员管理拷贝时机和方向 操作系统透明优化，零拷贝 内核启动 每次请求完整初始化 APK 持久化，微秒级切换 编程复杂度 需要 expertise 优化数据传输 简化编程，内核态自动优化 适用硬件 通用（dGPU 和 APU） 针对 APU 统一内存深度优化 LAIKA 与 CUDA/ROCm 的对比不仅是性能数字的比较，更是编程模型的范式转变。CUDA/ROCm 的显式传输允 许精细的内存管理优化（如双缓冲、异步传输），但需要程序员 expertise；LAIKA 的隐式共享内存简化了编程，但可能牺 牲某些极端场景的可控性。从系统架构角度，LAIKA 代表了操作系统向更高抽象层次的演进：将硬件细节封装在内核中， 向用户暴露语义化的接口。 2.5.2 与内核旁路技术对比：DPDK/SPDK 的适用性局限 DPDK（Data Plane Development Kit）和 SPDK （Storage Performance Development Kit）是 Intel 主导的内核旁路技术，通过用户态轮询驱动消除内核协议栈开销， 实现微秒级的网络/存储 I/O。这些技术与 LAIKA 有相似的目标（降低延迟），但采用截然不同的方法： 对比维度 DPDK/SPDK LAIKA 优化目标 网络/存储 I/O 密集型任务 计算密集型 AI 推理任务 技术路线 内核旁路，用户态直接硬件访问 内核深度集成，优化加速器访问路径 资源消耗 独占 CPU 核心进行轮询 与应用程序共享 CPU，精细调度 安全性 硬件暴露给用户态，攻击面增加 保持内核控制权，安全边界清晰 适用场景 高频交易、网络功能虚拟化 边缘 AI、实时推理、低功耗计算 DPDK/SPDK 适用于网络/存储 I/O 密集型任务，其优化对象是协议栈处理和数据拷贝；LAIKA 适用于计算密集型任 务（AI 推理），其优化对象是加速器访问路径。两者可以协同：LAIKA 处理的推理请求可能通过 DPDK 接收网络输入、 通过 SPDK 持久化结果。从安全性角度，内核旁路技术将硬件暴露给用户态，增加了攻击面；LAIKA 保持内核的控制权， 但增加了内核代码的复杂性。 Kimi.ai 生成

2.5.3 与其他 APU 优化工作对比：AMD APU 驱动的用户态优化方案 AMD 及学术界针对 APU 提出了多种优 化方案，与 LAIKA 形成互补关系： 方案 优化层级 核心机制 与 LAIKA 的关系 AMD MIGraphX 用户态推理引擎 图优化、算子融合、内存池管理 LAIKA 可在此基础上进一步 优化内核态开销 AMD Ryzen AI 软件 驱动和运行时 NPU/GPU 调度、电源管理 用户态优化，LAIKA 提供内 核级基础设施 学术 APU 感知调度 操作系统调度器 CPU-GPU 任务协同调度 调度策略优化，可与 AShm/ APK 协同 GPUfs（学术原型） 内核文件系统 GPU 直接文件访问 类似思想的 I/O 路径优化 LAIKA的独特贡献在于操作系统内核层面的创新，这些上层方案难以触及的优化空间。理论上，LAIKA可与MIGraphX 的模型优化、Ryzen AI 的电源管理结合，形成完整的 APU 优化栈。 2.6 实现细节与代码架构 2.6.1 内核模块实现：LAIKA 内核模块的代码结构与关键函数 LAIKA 内核模块的实现遵循 Linux 内核编码规范， 同时针对 APU 硬件特性进行专门优化。核心源文件结构： 源文件 功能 代码规模（估计） laika_main.c 模块初始化、清理、参数解析 ~500 行 laika_ashm.c AShm 内存分配、页表管理、缓存一 ~2500 行 致性 laika_apk.c APK 内核加载、上下文管理、任务 ~2000 行 调度 laika_kfd.c AMD KFD 驱动接口封装 ~800 行 laika_syscall.c 系统调用实现、ioctl 接口 ~600 行 laika_event.c 事件通知机制、同步原语 ~400 行 模块总代码量估计在 6000-8000 行，属于中等复杂度的内核模块。关键函数的设计体现性能优先原则： • laika_ashm_alloc()：AShm 内存分配，采用伙伴系统的变体，优先分配大页以减少 TLB 压力，同时维护 APU 可访问的物理连续性 • laika_apk_load()：模型加载，解析编译后的 GPU 代码，建立内核页表映射，初始化执行上下文 • laika_infer_fast()：热路径函数，采用内联汇编和 likely/unlikely 分支预测提示，确保常见情况的最小开销 2.6.2 内存管理子系统：AShm 的页表管理与 TLB 优化 AShm 的页表管理是 LAIKA 最复杂的实现挑战。Linux 的页表结构（四级或五级页表）需要扩展以支持 GPU 访问： 组件 CPU 侧 GPU 侧 同步机制 页表根 CR3 寄存器 KFD PM4 命令序列 修改时同步更新 页表项 x86 标准格式 AMD GPU 格式 格式转换和验证 TLB 管理 INVLPG 指令 GPU TLB invalidate 批量 shootdown 优化 关键优化技术包括： Kimi.ai 生成

• 大页（2MB/1GB）映射：减少页表遍历深度和 TLB 条目消耗 • TLB 预取：通过 AMD 的 PCIE 原子操作或软件预取指令，隐藏页表遍历延迟 • TLB shootdown 批量处理：多核同步时，合并多个 invalidate 请求，减少 IPI 开销 2.6.3 用户态库接口：liblaika 的 API 设计与使用示例 liblaika 作为用户态接口层，设计目标是兼容现有深度学 习框架，同时暴露 LAIKA 的高级特性。核心 API： // 初始化与清理 int laika_init(uint32_t flags); int laika_finalize(void); // AShm 内存管理 laika_shm_t* laika_shm_alloc(size_t size, laika_shm_flags_t flags); void* laika_shm_map(laika_shm_t* shm, void* addr_hint); int laika_shm_unmap(laika_shm_t* shm); // APK 模型管理 laika_model_t* laika_model_load(const char* path, laika_model_flags_t flags); int laika_model_unload(laika_model_t* model); // 推理执行 int laika_infer(laika_model_t* model, laika_tensor_t* inputs, laika_tensor_t* outputs, laika_infer_flags_t flags); int laika_infer_async(laika_model_t* model, laika_tensor_t* inputs, laika_tensor_t* outputs, laika_callback_t callback); 使用示例展示了 LAIKA 的易用性： // 初始化 LAIKA 运行时 laika_init(LAIKA_INIT_DEFAULT); // 加载模型（APK 持久化） laika_model_t* model = laika_model_load("resnet50.laika", LAIKA_MODEL_PERSISTENT); // 分配 AShm 输入/输出内存 float* input = laika_shm_map(laika_shm_alloc(224*224*3*sizeof(float), LAIKA_SHM_INPUT), NULL); float* output = laika_shm_map(laika_shm_alloc(1000*sizeof(float), LAIKA_SHM_OUTPUT), NULL); // 准备输入数据（直接写入 AShm，零拷贝） prepare_input_image(input); // 执行推理（快速路径，微秒级延迟） laika_infer(model, &(laika_tensor_t){.data=input, .shape={1,3,224,224}}, &(laika_tensor_t){.data=output, .shape={1,1000}}, 0); // 使用输出结果 int predicted_class = argmax(output, 1000); Kimi.ai 生成

// 清理（模型保持持久化，可选卸载） laika_model_unload(model); laika_finalize(); 2.6.4 与现有 ML 框架集成：PyTorch 后端插件实现 LAIKA 的实用价值取决于与主流 ML 框架的集成程度。 PyTorch 后端插件实现通过 torch.compile 的自定义后端机制，将 PyTorch 的计算图转换为 LAIKA 的执行计划。 关键步骤： 步骤 技术实现 挑战与优化 图捕获 torch.fx 或 torch.dynamo 处理动态形状和控制流 算子匹配 PyTorch 算子 →LAIKA 内核映射 支持自定义算子和融合模式 内存规划 AShm 区域分配，激活复用 平衡内存占用与计算效率 执行调度 APK 任务提交，异步流水线 隐藏延迟，提高吞吐量 集成挑战在于处理 PyTorch 的动态特性：动态形状（输入尺寸变化）、控制流（数据依赖的条件执行）、以及自定义算子 （Python/C++ 扩展）。LAIKA 可能采用保守策略：对静态形状子图使用完整优化，对动态部分回退到标准后端。随着 torch.compile 技术的成熟，这一集成有望更加无缝。 2.7 应用前景与部署场景 2.7.1 边缘计算设备：低功耗 AI 推理终端 边缘计算是 LAIKA 最直接的应用场景。典型部署案例： 设备类型 应用场景 LAIKA 价值 智能安防摄像头 实时人脸检测、行为分析 30fps 视频流处理，<33ms 延迟 工业质检设备 产品缺陷视觉检测 毫秒级响应，产线同步 医疗影像终端 X 光/CT 辅助诊断 本地处理，保护患者隐私 自动驾驶感知 多传感器融合、目标跟踪 低延迟决策，安全关键 这些场景的共同需求是：成本敏感（无法承担独显方案）、空间受限（无法部署大型服务器）、功耗受限（电池供电或被动散 热）。LAIKA 的 9.7 倍延迟降低和 71% 功耗节省，使得这些设备能够运行更复杂的模型，或延长电池续航，或降低散热 设计成本。 2.7.2 数据中心：大规模推理服务的能效优化 数据中心场景关注规模效应下的总拥有成本（TCO）： 优化方向 LAIKA 机制 商业价值 能效提升 AShm 零拷贝 +APK 快速启动 降低 PUE，减少碳排放 密度提升 低功耗设计支持更高机柜密度 数据中心容量扩展 成本优化 APU 方案 vs. 独显方案的硬件成本 边缘大规模部署的经济可行性 虽然 LAIKA 针对 APU 优化，但其核心思想（内核态加速、零拷贝、持久化）可扩展到数据中心级的 GPU 集群。特 别是能效优化方向：数据中心的 AI 推理负载通常具有时间分布不均的特点，峰值时段需要高吞吐，低谷时段希望低功耗。 LAIKA 的快速启动/停止机制支持更激进的电源管理，在负载变化时快速调整计算资源。 2.7.3 移动与嵌入式：智能手机、IoT 设备的本地 AI 移动和嵌入式设备是 APU 架构的重要市场： Kimi.ai 生成

平台 硬件特性 LAIKA 适配方向 智能手机（骁龙/天玑/A 系列） CPU+GPU+NPU 异构集成 AShm 思想适配 NPU 内存共享 笔记本（Ryzen AI/Intel Core Ultra） x86 APU，统一内存 直接应用 LAIKA 优化 IoT 微控制器 资源极度受限 轻量级变体，RTOS 适配 智能手机的 SoC 都采用 CPU+GPU+NPU 的异构集成，与 APU 架构理念相通。LAIKA 的技术（特别是 AShm 的共享内存思想）可适配到这些平台的操作系统（Android、iOS）中，提升本地 AI 应用的性能。IoT 设备的资源更加受 限，微控制器级别的 AI（TinyML）是活跃研究方向，LAIKA 的轻量级变体可能针对这些场景进行裁剪。 2.8 未来研究方向与挑战 2.8.1 多 APU 扩展：多芯片 APU 系统的负载均衡与调度 随着芯片集成度提高，多 APU 系统（同一主板上的多个 APU 芯片，或 APU 与独立 GPU 的混合）将成为可能。LAIKA 的当前设计针对单 APU 优化，扩展到多 APU 需要 解决： 挑战 技术方向 关键机制 任务划分 模型并行与流水线并行 层间分割，通信优化 负载均衡 动态请求分发 工作窃取，队列长度感知 通信优化 APU 间数据共享 CXL 缓存一致性，P2P DMA 调度协同 全局资源视图 分布式调度器，一致性协议 这些挑战与分布式深度学习系统类似，但操作系统的直接控制提供了更优化的机会。 2.8.2 安全隔离：共享内存机制下的进程间隔离与保护 AShm 的共享内存设计带来安全挑战： 威胁模型 攻击向量 防御机制 信息泄露 恶意进程读取其他进程 AShm 数据 IOMMU 细粒度权限，地址空间随机化 数据篡改 修改共享权重参数导致错误推理 写保护页，密码学完整性验证 拒绝服务 耗尽 AShm 配额或 APK 上下文 资源配额，优先级调度 侧信道攻击 通过时序分析推断敏感信息 定时填充，噪声注入 可能的解决方案包括：IOMMU 的细粒度权限配置、APU 内核的代码验证（类似 eBPF 的 verifier）、以及基于硬件 enclave 的隔离（如 AMD SEV-SNP）。安全与性能的权衡是这一方向的核心研究问题。 2.8.3 新硬件适配：Intel Meteor Lake、Qualcomm Oryon 等 APU 架构 APU市场正在多元化，LAIKA 的移植需要深入理解各平台特性： 平台 内存架构 缓存一致性 适配重点 Intel Meteor Lake CPU+GPU+NPU 共享 Intel Xe Link NPU 集成，多加速器协同 Qualcomm Oryon CPU+Adreno 平台特定 移动功耗优化，DSP 利用 GPU+Hexagon DSP Apple M 系列 统一内存架构 Apple Fabric 生态封闭性，逆向工程 理想情况下，LAIKA 的核心抽象（AShm、APK）可以跨平台实现，但具体优化需要针对各架构定制。 Kimi.ai 生成

2.8.4 编译优化：APU 专用代码生成与自动调优 LAIKA 消除了运行时开销，但 APU 的计算效率仍依赖于内核代 码质量： 优化方向 技术机制 预期收益 内存访问模式 缓存行对齐，预取策略 减少内存停顿，提高带宽利用率 计算单元调度 CPU 与 GPU 核心协同，任务粒度优化 负载均衡，减少空闲 精度-性能权衡 混合精度，动态量化 在精度损失可接受时提升吞吐 自动调优（AutoTuning） 基于实际硬件反馈搜索最优配置 适配具体 APU 型号和工作负载 这些编译技术与 LAIKA 的运行时优化形成完整优化链条，可从模型定义到优化内核的端到端代码生成。 3. 核心论文二：Wave — SmartNIC 资源管理卸载 3.1 研究背景与动机 3.1.1 云计算资源压力：主机 CPU 被系统软件大量占用 现代云数据中心面临严峻的资源效率挑战。随着微服务架构、 容器化部署、以及虚拟化技术的普及，系统软件消耗的主机 CPU 资源比例持续攀升。研究表明，在某些云工作负载中，超 过 30% 的 CPU 周期被用于” 非业务” 的系统软件开销，包括线程调度、内存管理、网络协议栈、存储 I/O、以及 RPC 序列化/反序列化 (华南师范大学计算机学院) 。这一” 税收” 直接减少了可出售给客户的计算资源，降低了数据中心 的收入效率。 资源压力的多重因素加剧了这一问题：微服务的细粒度分解增加了 RPC 调用频率和调度开销；容器的快速启停对内核的 cgroup 管理和网络配置提出更高要求；虚拟化的嵌套（如 KVM 上的 Kubernetes）叠加了多层抽象开销；以及安全需 求的增强（如加密、审计、隔离）引入了额外的处理步骤。传统的优化方向（更快的 CPU、更高效的内核算法）面临收益递 减，需要架构层面的创新。 3.1.2 SmartNIC 演进：从网络卸载到通用计算能力的扩展 SmartNIC（智能网卡）的演进为上述挑战提供了新的解 决路径。第一代 SmartNIC（如 Netronome NFP）专注于网络功能卸载，将包处理、流表匹配等任务从主机 CPU 迁 移到网卡上的专用 ASIC。第二代 SmartNIC（如 Mellanox BlueField-2）集成了 ARM 核心，支持更灵活的可编程 处理。第三代 SmartNIC（NVIDIA BlueField-3、AMD Pensando DSC-200、Intel Mount Evans） 已经具备了完整的通用计算能力：多核 ARM 处理器（8-16 核）、大容量内存（16-32GB）、以及丰富的加速引擎（加密、 压缩、正则表达式）(华南师范大学计算机学院) 。 这一硬件演进开启了新的可能性：将操作系统的资源管理功能——而非仅仅是网络数据平面——迁移到 SmartNIC 执行。 关键洞察在于：SmartNIC 的 ARM 核心虽然单线程性能弱于主机 x86 核心，但对于决策密集而非计算密集的系统软件 任务，这一差距可以通过专用化和并行化弥补；更重要的是，物理隔离确保了主机资源的完全释放，避免了传统共享执行模 式下的干扰和争用。 3.1.3 现有方案局限：内核态卸载的复杂性与用户态方案的延迟 在 Wave 之前，系统软件卸载存在两条主要路径，但均 有显著局限： 方案类型 代表技术 核心局限 内核态卸载 eBPF/XDP 验证器限制算法复杂度，仍在主机 CPU 执行 用户态卸载 DPDK/SPDK 内核旁路 需独占 CPU 核心轮询，功能范围受 限 专用硬件卸载 SmartNIC 网络/存储卸载 针对特定功能定制，缺乏通用性 Kimi.ai 生成

eBPF/XDP 虽然实现了内核态的可编程性，但其验证器严格限制循环、函数调用和内存访问模式，无法表达复杂的资源 管理算法；更重要的是，eBPF 程序仍在主机 CPU 上执行，只是以受限方式运行，并未实现资源的物理隔离。DPDK/ SPDK 通过用户态轮询实现极低延迟，但需要独占 CPU 核心进行忙等待，与资源回收的目标相悖，且功能范围局限于网 络/存储 I/O。现有的 SmartNIC 卸载方案（如 OVS 硬件卸载）针对特定功能定制，缺乏支持任意系统软件的通用框架。 Wave 的核心创新在于：设计一个通用框架，使得现有的用户态系统软件能够透明地迁移到 SmartNIC 执行，同时通过 精细的通信优化将跨 PCIe 延迟控制在可接受范围内 (华南师范大学计算机学院) 。 3.2 核心问题定义 3.2.1 资源管理开销：线程调度、内存管理、RPC 栈消耗主机核心 Wave 针对的系统软件功能具有共同的特征：执行 频率高、决策逻辑复杂、与硬件状态紧密交互。具体而言： 系统软件组件 典型开销 核心瓶颈 优化潜力 线程调度器 5%-10% CPU 周期 负载均衡、优先级计算、上下 高，决策可离岸执行 文切换 内存管理器 3%-8% CPU 周期 大页分配、NUMA 迁移、页 高，ML 驱动策略计算密集 回收策略 RPC 处理栈 10%-20% CPU 周期 序列化/反序列化、路由、负载 高，与网络边界天然匹配 均衡 虚拟机监控器 5%-15% CPU 周期 vCPU 调度、影子页表、I/O 中高，控制平面可分离 虚拟化 以内存管理为例，先进的机器学习驱动策略（如页面冷热分类、预测性预取）需要实时分析大量访问模式数据，单次决策可 能涉及数十微秒的模型推理，累积消耗可观。RPC 栈在微服务架构中成为关键路径：每个服务调用涉及多次序列化/反序列 化、服务发现查询、负载均衡决策，这些操作的延迟直接影响端到端响应时间。 3.2.2 卸载粒度挑战：微秒级系统软件的 SmartNIC 卸载可行性 将系统软件卸载到 SmartNIC 面临根本性的粒 度-延迟矛盾。PCIe Gen4 x16 的理论带宽为 32GB/s，但往返延迟（Round-Trip Time, RTT）约为 1-2 微秒， 这一物理限制对于微秒级决策构成严峻挑战： 决策类型 典型延迟要求 PCIe RTT 占比 可行性评估 网络包处理（XDP） <1￿s >100% 不可行，需内核态或专用硬 件 线程调度决策 10-100￿s 10%-20% 可行，需批量和预取优化 内存页面迁移 100￿s-1ms 1%-10% 高度可行，通信开销可忽略 RPC 路由决策 10-100￿s 10%-20% 可行，与网络处理协同 Wave 的关键技术挑战在于：对于 10-100￿s 延迟要求的决策，设计通信机制将有效开销从” 单次往返” 降低到” 摊销后 亚微秒”。这需要突破传统的请求-响应模式，引入预计算、批量处理和智能缓存等优化技术。 3.2.3 功能与性能平衡：卸载后功能完整性与性能损耗的权衡 Wave 的设计目标是在保持功能完整性的前提下，将性能 损耗控制在可接受范围内： 设计约束 具体要求 实现策略 功能完整性 100% 兼容 Linux 用户态系统软件 复用现有代码，最小化修改 Kimi.ai 生成

Table 27 – continued 设计约束 具体要求 实现策略 性能损耗 <10% vs. 主机原生执行 通信优化，快速路径，预计算 资源回收 显著净收益（节省核心数 » 消耗核心数） 选择性卸载计算密集决策 透明性 应用程序无需修改 内核适配层，兼容 API 这一目标的激进性在于：传统观点认为 PCIe 通信开销使得 SmartNIC 只适合毫秒级或更粗粒度的任务，Wave 挑战了 这一” 常识”，证明了通过架构创新，微秒级系统软件的卸载同样可行。 3.3 核心方法与技术创新 3.3.1 Linux 用户态系统对齐 3.3.1.1 设计原则：复用现有用户态系统软件，降低移植成本 Wave 的核心设计哲学是最大化复用现有的 Linux 用户 态系统软件生态。这一决策基于以下深刻观察：近年来，用户态资源管理系统已经形成了丰富的软件生态——Google 的 ghOSt（用户态调度框架）(来源) 、Syrup（用户态内存管理）(来源) 、CCP（拥塞控制协议）(来源) 、userfaultfd （用户态缺页处理）(来源) 、PageFlex（灵活页面管理）(来源) 等——这些系统已经证明了将内核子系统控制平面迁移 到用户态的可行性和性能优势。 直接复用这些成熟实现，而非从头开发 SmartNIC 专用版本，带来多重收益：开发效率——避免重复实现复杂的调度算 法、内存策略、RPC 协议；正确性保证——经过广泛测试的代码，边界情况处理完善；生态兼容——现有工具和调试手段 可直接使用；演进能力——上游更新可快速集成。Wave 的技术贡献不在于创造新的系统软件，而在于创造使这些软件能够 在 SmartNIC 上高效执行的运行时环境。 3.3.1.2 适配层设计：主机内核与 SmartNIC 运行时的接口抽象 Wave 适配层的核心是一个双向共享内存队列系统， 抽象了主机-SmartNIC 通信的所有细节： 队列类型 方向 底层机制 适用场景 消息队列（Message Queue） 主机 →SmartNIC MMIO 写合并（WC）或 状态通知，事件流 DMA 批量 决策队列（Decision Queue） SmartNIC→ 主机 MMIO 写直通（WT）+ 预 调度决策，分配结果 取或 DMA MMIO（Memory-Mapped I/O）路径通过将 SmartNIC 内存映射到主机虚拟地址空间，实现 CPU 指令级别 的直接访问。Wave 优化了页表属性：写合并（Write-Combining, WC）用于消息队列，允许 CPU 将多个写操作 缓冲并合并为单个 PCIe 事务，显著降低小消息的发送开销；写直通（Write-Through, WT）用于决策队列，确保 SmartNIC 写入的数据立即对主机可见，配合软件预取隐藏读取延迟。 DMA（Direct Memory Access）路径利用 SmartNIC 的 DMA 引擎实现大批量数据传输，绕过 CPU 直接 读写主机内存。DMA 的启动延迟较高（数微秒），但对于批量状态同步（如页表更新、统计信息收集），其吞吐效率远超 MMIO。 适配层的软件抽象包括：队列原语（queue_send()/queue_recv()，支持阻塞/非阻塞/超时模式）、事务封装 （txn_begin()/txn_commit()，保证多操作原子性）、以及事件通知（中断、轮询、信号量多种机制）。 3.3.1.3 兼容性保证：对 Linux 调度器、内存管理器的透明支持 Wave 的兼容性保证体现在三个层面： Kimi.ai 生成

对现有系统软件的兼容性：ghOSt Agent、内存管理器等组件可以不经修改或仅需重新编译即可运行在 SmartNIC 上。 Wave 运行时提供了与 Linux 兼容的 POSIX API 子集（线程、内存、文件、网络），以及特定的硬件抽象（定时器、性 能计数器）。 对主机内核的兼容性：Wave 的集成通过内核模块实现，遵循标准的 Linux 内核扩展机制。调度子系统注册新的 sched_class（SCHED_WAVE），内存管理通过 shrinker 和 alloc_hooks 介入，网络栈通过 netfilter 或 BPF 钩子 集成。这些扩展在不修改核心内核代码的前提下实现功能注入。 对应用程序的透明性：应用程序继续使用标准的系统调用和库接口，无需感知底层资源管理决策的实际执行位置。Wave 的 优化对应用程序完全透明，仅通过系统性能的提升体现价值。 3.3.2 主机-SmartNIC 通信 API 3.3.2.1 共享内存队列：基于 MMIO/DMA 的双向队列抽象 Wave 的队列实现针对 PCIe 特性深度优化： 优化技术 应用场景 效果 实现细节 写合并（WC） 主机 →SmartNIC 小消息 降低有效延迟至 ~200ns 缓冲多个写，批量发射 PCIe 事务 写直通 + 预取 SmartNIC→ 主机决策读取 隐藏 ~750ns MMIO 读延迟 主机主动预取，轮询而非中断 （WT+Prefetch） 等待 DMA 批量 大批量状态同步 饱和 PCIe 带宽，~25GB/s 描述符环，异步完成通知 有效 自适应路径选择 运行时动态切换 根据消息大小自动选择 阈值配置，性能计数器反馈 MMIO/DMA 写合并的微观机制：x86 CPU 的 WC 缓冲区（Write-Combining Buffer）可将最多 64 字节的写操作合并为单个 PCIe TLP（Transaction Layer Packet）。对于典型的调度事件通知（约 32 字节），WC 可将有效 PCIe 事务数从” 每事件一次” 降低到” 每两事件一次”，延迟从 400ns 等效。 750ns降至 预取的协同设计：SmartNIC在写入决策后，立即触发MSI-X中断；主机中断处理程序在读取决策时，使用 prefetcht0 指令将相邻的决策行拉入 L1 缓存。这种” 中断 + 预取” 的组合，使得主机读取延迟从典型的 100ns 800ns（缓存未命中）降低到 （缓存命中）。 3.3.2.2 事务型接口：请求-响应模式的状态同步机制 Wave 引入了事务（Transaction）抽象，将分布式的请求-响应 模式封装为类似本地调用的语义： 事务生命周期： 主机：构造请求消息 → 写入消息队列 → [可选] 等待完成或继续异步执行 SmartNIC：轮询/中断接收请求 → 执行策略计算 → 构造决策消息 → 写入决策队列 主机：接收完成通知 → 读取决策 → 验证并执行 → 发送确认（异步事务） 事务的关键属性包括：唯一标识符（用于重复检测和乱序处理）、超时时间戳（触发回退到本地默认策略）、幂等性标记（允 许安全重试）、以及优先级/紧急程度（影响队列调度和抢占）。 原子性保证：对于需要一致状态更新的操作（如” 迁移页面 P 到节点 N，并更新映射表”），事务封装了完整的操作序列，主 机内核原子性提交，避免部分执行导致的状态损坏。 3.3.2.3 微秒级延迟优化：批量处理与中断合并策略 Wave 实现了多层延迟优化技术，目标是将摊销后的通信开销降至 亚微秒级： Kimi.ai 生成

优化层 技术 效果 适用条件 L1：预暂存（Prestaging） SmartNIC 主动计算并缓存 关键路径降至 426ns 决策可预测，工作负载规律 预测决策 L2：批量处理（Batching） 累积多个请求/决策统一传输 摊销固定开销，提升吞吐 高负载，延迟容忍微秒级增加 L3：中断合并（Coalescing） 累积多个完成事件统一中断 减少中断风暴，提升吞吐 超高负载，P99 延迟可妥协 L4：纯轮询（Polling） 主机忙等待决策队列 消除中断延迟，CPU 占用换 延迟极度敏感，核心可独占 取确定性 预暂存（Prestaging）是 Wave 最具创新性的优化。其核心洞察是：许多资源管理决策具有可预测性——例如，轮询调 度器的下一个任务、基于历史模式的页面预取、基于服务拓扑的 RPC 路由。SmartNIC Agent 在空闲时主动计算这些” 推测性决策”，缓存于共享内存的” 预暂存区”；当主机实际请求到达时，若预计算命中，直接读取缓存结果，无需完整的策 略计算和通信往返。 实验测量显示，预暂存使关键决策路径从 ~800ns 降至 426ns（SmartNIC 写入决策到发送 MSI-X 中断），这一数字 接近 PCIe 物理延迟的理论极限 (华南师范大学计算机学院) 。 3.3.3 Wave Agent 架构 3.3.3.1 Agent 模型：SmartNIC 上的资源管理决策组件 Wave Agent 是运行在 SmartNIC Linux 用户态的资 源管理进程，每个 Agent 封装特定的系统软件功能： Agent 类型 核心职责 典型实现 资源需求 sched_agent 线程调度决策 ghOSt 全局 EDF 调度器 2-4 ARM 核心，512MB 内 存 mem_agent 内存管理策略 ML 驱动的页面分类和迁移 4-8 ARM 核心，1-2GB 内 存 rpc_agent RPC 处理栈 gRPC/Thrift 协议终止和路 2-4 ARM 核心，动态内存 由 vmm_agent 虚拟机调度 KVM vCPU 放置和气球管 2-4 ARM 核心，与 VM 数 理 相关 Agent 的设计遵循事件驱动架构：主循环轮询输入队列，接收事件消息，调用策略处理函数，生成决策写入输出队列。策略 代码直接复用现有的用户态实现，仅替换底层的系统调用为 Wave 适配层 API。 3.3.3.2 组合灵活性：单组件运行与多组件融合的部署模式 Wave 支持灵活的部署拓扑，适应不同场景的资源约束和性 能需求： 部署模式 配置 优势 适用场景 单组件独立 每个 Agent 独占 ARM 核心 资源隔离，延迟确定性 延迟敏感的生产环境 多组件融合 多个 Agent 共享核心，协作 资源利用率提升，跨功能优化 资源受限，功能交互密集 调度 分层卸载 关键路径本地处理，复杂决策 极致延迟 + 资源回收平衡 混合负载，动态变化 离岸 Kimi.ai 生成

融合部署的协同优化：sched_agent 与 rpc_agent 融合时，RPC 到达事件可直接触发调度决策——网络 I/O 的到达 模式（突发 vs. 平稳）即时影响线程优先级和 CPU 分配，实现” 网络感知调度”。这种跨层优化在分离部署中难以实现， 因为跨 Agent 通信延迟会抵消协同收益。 3.3.3.3 安全隔离：Agent 间的资源边界与故障隔离 Wave 的安全架构从硬件到应用多层纵深防御： 层级 机制 保护目标 硬件 ARM TrustZone/Secure Boot Agent 代码完整性，启动安全 内核 cgroups, namespaces, seccomp 资源配额，系统调用过滤 运行时 地址空间隔离，capability 模型 Agent 间内存隔离，权限最小化 协议 事务验证，决策审计，超时回退 逻辑错误检测，故障容错 故障隔离的关键设计：每个 Agent 配备硬件看门狗（watchdog）和心跳机制。若 Agent 崩溃或心跳超时（默认 50ms）， 主机内核自动检测到异常，回退到本地默认策略（如 CFS 调度、标准内存分配），记录审计日志，并可选重启 Agent。这 一机制确保单点故障不会级联影响系统可用性。 3.3.4 系统架构全景 3.3.4.1 架构图解析：Figure 1 的高层设计 Wave 的系统架构呈现清晰的分层结构 (华南师范大学计算机学院) ： ┌─────────────────────────────────────────┐ │ 应用层：用户应用程序、ML 框架、数据库 │ ← 主机 x86 ├─────────────────────────────────────────┤ │ 系统软件层：ghOSt、内存管理器、gRPC 等 │ ← 主机（适配层）/ SmartNIC（Agent） ├─────────────────────────────────────────┤ │ Wave 适配层：队列抽象、事务管理、通信优化 │ ← 主机内核模块 + SmartNIC 运行时 ├─────────────────────────────────────────┤ │ 硬件抽象层：PCIe 驱动、DMA 引擎、中断管理 │ ← 主机内核 + SmartNIC Linux ├─────────────────────────────────────────┤ │ 硬件层：x86 主机 CPU/内存 ←PCIe→ ARM SoC │ ← 物理硬件 │ SmartNIC + 加速引擎 + 网络端口 │ └─────────────────────────────────────────┘ 架构的核心设计决策是策略-机制分离的跨硬件延伸：SmartNIC Agent 负责” 做什么”（策略决策），主机内核保留” 怎么 做”（机制执行）。这一分离既利用了 SmartNIC 的计算能力，又保持了主机内核对系统资源的最终控制和安全把关。 3.3.4.2 数据流与控制流：从应用到硬件的完整路径 以线程调度为例，Wave 的完整数据流： 阶段 执行位置 操作 延迟 1. 事件触发 主机内核 线程 A 在核心 0 阻塞，触发 ~100ns（内核路径） 调度事件 2. 消息构造 主机内核 封装事件为 Wave 消息，写入 ~200ns（WC 优化） 消息队列 3. 传输 PCIe MMIO 写到达 SmartNIC ~150ns（物理延迟） 4. Agent 处理 SmartNIC sched_agent 执行 EDF 调 ~500ns-2￿s（取决于策略复杂 度算法 度） 5. 决策返回 SmartNIC 写入决策队列，发送 MSI-X ~426ns（预暂存命中时） Kimi.ai 生成

Table 34 – continued 阶段 执行位置 操作 延迟 6. 中断处理 主机核心 0 读取决策，验证事务 ~100ns（预取命中） 7. 决策执行 主机内核 上下文切换到线程 B ~200ns（硬件路径） 总计 — — 0.8￿s（预暂存 1.5-3￿s（典型）， 最优） 这一延迟水平对于 10-100￿s 时间片的调度器完全可接受，且带来的资源回收收益远超微小延迟增加的成本。 3.3.4.3 与主机内核交互：决策下发与强制执行机制 Wave 的安全模型区分决策生成与强制执行： 阶段 责任方 操作 失败处理 决策生成 SmartNIC Agent 基于策略和状态计算最优决策 超时或错误时主机回退 决策验证 主机内核 检查决策合法性（存在性、权 拒绝非法决策，记录审计 限、约束） 决策执行 主机内核 调用标准内核机制实施决策 原子性保证，可回滚 效果反馈 主机内核 → Agent 执行结果和性能统计异步返回 用于策略学习和优化 这一设计确保 SmartNIC 被攻破不会导致系统崩溃：即使恶意 Agent 生成危险决策，主机内核的验证层会拦截；即使 验证通过，执行的原子性保证可回滚；即使执行完成，审计日志支持事后追溯。 3.4 实验设置与评估 3.4.1 硬件平台 3.4.1.1 SmartNIC 型号：Intel Mount Evans / NVIDIA BlueField-3 Wave 的原型实现基于 Intel Mount Evans IPU（Infrastructure Processing Unit），这是 Intel 专为数据中心设计的第三代 SmartNIC/ DPU 产品 (华南师范大学计算机学院) 。Mount Evans 的核心规格： 组件 规格 与 Wave 优化的相关性 ARM 核心 16× Neoverse N1 @ 2.0GHz Agent 执行载体，性能与主机 x86 的 ~40% 内存 32GB HBM2e + DDR5 大容量支持复杂策略状态，高带宽减少瓶 颈 主机接口 PCIe Gen4 x16 理论 32GB/s，优化目标饱和有效带宽 网络 2×100GbE RPC Agent 的网络边界，RDMA 支 持 加速引擎 加密、压缩、正则表达式 可选卸载，与 Agent 协同 选择 Mount Evans 具有代表性：其 ARM 核心性能足以运行复杂的系统软件，HBM 容量和带宽支持大工作集，而 PCIe 接口的延迟特性与业界其他高端 SmartNIC（如 NVIDIA BlueField-3、AMD Pensando）处于同一量级，实 验结论具有广泛适用性。 3.4.1.2 ARM 核心配置：核心数、频率、缓存容量 Wave 实验精细配置了 SmartNIC ARM 资源： Kimi.ai 生成

Agent 类型 绑定核心 频率策略 内存分配 sched_agent 2-4 核 固定 2.0GHz，禁用 512MB HBM，低延迟优 DVFS 先 mem_agent 4-8 核 动态调频，负载感知 1-2GB HBM，大工作集 rpc_agent 2-4 核 与网络引擎协同 动态分配，突发缓冲 缓存层次对性能关键：每核心 64KB L1 I/D-cache，1MB L2 cache，共享 8MB L3 cache。Wave 优化数据结构布 局以提升局部性：调度队列按 CPU 核心分片，减少 L3 争用；内存管理元数据按 NUMA 节点组织，优化 L2 命中。 3.4.1.3 主机配置：x86 服务器规格、网络拓扑 主机平台配置： 组件 规格 控制变量 CPU 2× Intel Xeon Platinum 8380 40 核/80 线程，与 SmartNIC ARM 性能可比 内存 512GB DDR4-3200，8 通道 与 SmartNIC HBM 带宽可比，消除 内存瓶颈 存储 NVMe SSD，RAID 配置 消除 I/O 瓶颈 网络 25GbE/100GbE，与 SmartNIC 端 控制网络变量 口直连 操作系统 Ubuntu 22.04 LTS，定制内核 软件环境标准化 5.15+Wave 补丁 网络拓扑为直连模式：SmartNIC 的 100GbE 端口与对端测试服务器直接连接，消除交换机引入的延迟抖动。整个测试 环境运行在 Google 内部数据中心的隔离集群，具有真实的背景负载和运维实践。 3.4.2 卸载场景与基准 3.4.2.1 内核线程调度器：CFS 算法的 SmartNIC 实现 Wave 评估了三种调度策略的 SmartNIC 卸载： 策略 特性 基准测试 关键指标 FIFO 简单队列，公平性保证 sysbench 线程测试 吞吐量，调度延迟 Shinjuku 抢占式调度，微秒级时间片 hackbench，RocksDB P99 延迟，尾延迟稳定性 GCE VM 调度 Google Compute Engine 内部负载模拟 多租户隔离，QoS 保证 生产策略 Shinjuku 调度器的评估尤为关键：其微秒级时间片（默认 5￿s）对延迟极度敏感，传统观点认为不可能离岸执行。Wave 通过预暂存和批量优化，证明了即使此类极端场景，SmartNIC 卸载仍然可行。 3.4.2.2内存管理：大页分配、NUMA感知的卸载 内存管理场景聚焦于TMLAD（TieredMemoryLearning- based Auto-Demote），一个基于机器学习的页面分层系统： 组件 功能 卸载收益 页面访问监控 采样和统计每个页面的访问模式 主机核心节省，监控开销降低 ML 模型推理 预测页面未来访问概率 16 核心节省，复杂计算离岸 Kimi.ai 生成

Table 40 – continued 组件 功能 卸载收益 迁移决策执行 根据预测决定页面放置（DRAM/ 决策质量提升，主机响应更快 CXL/SSD） TMLAD 的 ML 模型（基于 TensorFlow Lite）需要实时分析数百万页面的访问历史，传统实现消耗大量主机 CPU。 Wave 将其推理部分卸载到 SmartNIC，主机仅保留轻量级的执行路径（实际的页面拷贝）。 3.4.2.3 RPC 栈：gRPC/Thrift 的 SmartNIC 加速 RPC 场景实现了 Snap（Google 内部 RPC 框架） 的 SmartNIC 卸载版本： 功能层 卸载内容 保留内容 传输层 TCP/QUIC 协议终止，加密解密 无，完整卸载 协议层 HTTP/2 解析，gRPC 帧处理 无，完整卸载 路由层 服务发现查询，负载均衡决策 无，完整卸载 应用层 序列化/反序列化（Protobuf/ 无，完整卸载 Thrift） 业务逻辑 无 主机应用程序执行 评估使用真实的微服务跟踪数据，重放生产环境的请求模式，测量端到端延迟和主机 CPU 占用。 3.4.2.4 虚拟机监控器：KVM 调度的卸载优化 虚拟机场景评估 Wave 对 KVM 的优化效果： 优化点 传统瓶颈 Wave 改进 vCPU 调度 宿主机调度器干扰客户机 SmartNIC 全局视图，减少不必要迁 移 内存气球 频繁调整触发页表更新 预测性调整，批量处理 实时迁移 迁移时机和目的地选择 ML 驱动决策，最小化性能影响 关键指标是 “turbo 性能”：当物理核心有空闲周期时，vCPU 能否快速获得额外性能提升。Wave 的优化使虚拟机整体 性能提升 11.2% (华南师范大学计算机学院) 。 3.4.3 核心实验结果 3.4.3.1 性能损耗：与主机实现对比，1.1%-7.4% 的性能下降 Wave 的核心性能结果： 卸载场景 优化配置 性能损耗 关键优化技术 FIFO 调度 完整优化 1.1% 预暂存决策，批量提交 Shinjuku 调度 完整优化 3.3%-4.0% MMIO 快速路径，中断合 并 TMLAD 内存管理 完整优化 5%-7% DMA 批量传输，异步状 态同步 Snap RPC 完整优化 ~7% 全栈优化，轮询混合模式 Kimi.ai 生成

优化效果的敏感性分析：若禁用 Wave 的关键优化，RocksDB 吞吐量从 895K req/s 暴跌至 258K req/s，降幅达 350% (华南师范大学计算机学院) 。这一对比凸显了通信优化的必要性——未经优化的裸 PCIe 通信完全不可行。 优化技术 对 Shinjuku 调度的贡献 实现复杂度 写合并（WC） ~30% 延迟降低 低（页表属性配置） 预暂存（Prestaging） ~60% 延迟降低 中（预测模型，缓存管理） 预取（Prefetch） ~35% 延迟降低 中（推测执行，验证回滚） 中断合并 ~50% 吞吐提升 低（定时器配置） 忙等待轮询 ~70% 延迟降低（峰值） 高（CPU 占用，功耗增加） 3.4.3.2 资源回收效果 3.4.3.2.1 内存管理：节省 16 个主机核心 TMLAD 卸载的资源回收效果最为显著： 指标 主机原生 Wave 卸载 收益 ML 推理 CPU 占用 16 核心 ×100% 4 ARM 核心 ×~80% 16 x86 核心完全释放 页面分类延迟 ~2ms（批处理） ~2.5ms（异步） 可接受，异步流水线隐藏 内存效率提升 基准 +79% 有效容量 更好的冷热分离 节省的 16 核心可直接用于承载客户工作负载，或降低服务器配置以节省成本。以典型云实例定价估算，每服务器每年可节 省数千美元，百万级部署下收益可观。 3.4.3.2.2 RPC 处理：节省 8 个主机核心 Snap RPC 卸载效果： 指标 主机原生 Wave 卸载 收益 RPC 处理 CPU 占用 8-12 核心 2-4 ARM 核心 8 x86 核心释放 P50 延迟 ~45￿s ~38￿s -15.6%，意外改善 P99 延迟 ~2300￿s ~1100￿s -52.2%，尾延迟压缩 P99 延迟的显著改善源于 SmartNIC 的确定性执行环境：消除了主机上的” 嘈杂邻居” 干扰，调度延迟更可预测。 3.4.3.2.3 虚拟机：11.2% 的整体性能提升 虚拟机场景的” 负损耗” 现象： 效应类型 机制 量化贡献 直接效应 vCPU 调度优化节省 4 核心 与调度场景相当 间接效应 主机负载降低，Turbo 频率维持时间 单线程峰值性能 +15% ↑ 复合效应 延迟敏感服务（Redis）P99 延迟 ↓ -23% 这一结果揭示了系统软件卸载的深层价值：不仅是资源数量的回收，更是资源质量的提升——主机从系统软件干扰中解放， 交付更可预测的性能。 Kimi.ai 生成

3.4.3.3 延迟分布：P50/P99 延迟对比分析 Wave 详细报告了延迟分布的改善： 场景 指标 主机原生 Wave 卸载 变化 RocksDB 调度 P50 ~50￿s ~52￿s +4% P99 ~200￿s ~210￿s +5% P99.9 ~800￿s ~350￿s -56% TMLAD 内存 P50 ~85￿s ~88￿s +3.5% P99 ~240￿s ~250￿s +4.2% 尾延迟方差 高 低 确定性提升 Snap RPC P50 ~45￿s ~38￿s -15.6% P99 ~2300￿s ~1100￿s -52.2% 关键观察：Wave 的延迟增加主要集中在 P50-P99 区间，而 P99.9 极端尾部显著改善。这是因为 SmartNIC 的专 用资源消除了主机上的长尾干扰事件（如中断风暴、缓存污染）。 3.4.3.4 可扩展性：多 SmartNIC、多主机场景 Wave 验证了更大规模部署的可行性： 配置 场景 结果 单主机 ×2 SmartNIC 调度 Agent 分片，各管理 16 核心 吞吐量线性扩展，延迟 +8% 8 主机 ×1 SmartNIC 机架级调度，SmartNIC 间以太网同步 协调开销 <5%，全局优化有效 模拟 CXL 连接 类 UPI 缓存一致性，3GHz 频率 slowdown 仅 1.3% vs. PCIe 1.1% CXL 等新型互连的潜力：若 SmartNIC 与主机通过缓存一致性互联（而非 PCIe），通信延迟可进一步降低，卸载适用范 围扩展到更细粒度任务。 3.5 与现有技术对比 3.5.1 与内核态卸载对比：eBPF/XDP 的适用范围与限制 维度 eBPF/XDP Wave 执行位置 主机内核态 SmartNIC 用户态 延迟 极低（<1￿s） 较低（1-5￿s 摊销后） 功能复杂度 受限（验证器限制循环、调用） 完整（任意 C/C++ 代码） 资源隔离 与主机共享，无物理隔离 SmartNIC 独立，完全隔离 资源回收 无，仍在主机 CPU 执行 显著，释放主机核心 开发体验 特殊工具链，调试困难 标准 Linux，GDB/perf 可用 适用场景 网络包处理、简单跟踪 复杂调度、ML 推理、完整 RPC eBPF/XDP 与 Wave 形成互补关系：eBPF 适合超低延迟、简单逻辑的网络场景；Wave 适合需要复杂决策、可接受微 秒级延迟的系统软件。生产环境中可能两者共存：eBPF 处理网络快速路径，Wave 处理调度/内存/ RPC 控制平面。 3.5.2 与 DPU 方案对比：NVIDIA DOCA、AMD Pensando SDK Kimi.ai 生成

维度 NVIDIA DOCA AMD Pensando SDK Wave 硬件绑定 BlueField 系列 DSC 系列 硬件无关抽象 编程模型 专用 API 和运行时 专用 SDK 标准 Linux 用户态 代码移植 需重写 需重写 复用现有，重新编译 功能范围 网络、存储、安全 网络、存储、安全 任意系统软件 开源程度 部分开源 闭源 计划完全开源 云服务商友好度 中（供应商锁定） 中（供应商锁定） 高（多供应商兼容） Wave 的差异化优势在于通用性和透明性：不绑定特定硬件厂商，不修改应用程序，与标准 Linux 生态兼容。这一设计反 映了超大规模云服务商对供应商锁定的警惕，以及灵活部署多厂商硬件的需求。 3.5.3 与软件定义网络对比：Open vSwitch 的硬件卸载演进 演进阶段 技术 控制平面 数据平面 Wave 的延伸 纯软件 OVS 主机 CPU 执行全部 主机 主机 — 内核加速 OVS datapath 缓存 主机 主机内核 — DPDK OVS 用户态轮询 主机 主机用户态 — 硬件卸载 OVS TC Flower/ 主机 SmartNIC ASIC 数据平面卸载 Match-Action Wave 通用系统软件卸载 SmartNIC ARM SmartNIC/主机 控制平面卸载 Wave 将 OVS 的” 数据平面卸载” 演进推进到” 控制平面卸载”：不仅网络包处理，连调度决策、内存策略、RPC 路由等 控制逻辑也迁移到 SmartNIC。这是更激进的架构变革，也是更大的技术挑战。 3.6 实现细节与代码架构 3.6.1 Wave 运行时：SmartNIC 侧的轻量级 OS 内核 Wave Runtime 基于 Yocto Linux 定制，关键优化： 组件 优化策略 效果 内核配置 移除无关驱动和子系统 镜像 <200MB，启动 <5 秒 实时补丁 PREEMPT_RT 调度延迟 <10￿s 内存管理 静态分区，避免运行时分配 确定性延迟，无碎片 设备驱动 优化 PCIe 驱动，用户态 MMIO 绕过内核，降低延迟 运行时核心代码约 20,000 行 C/C++，包括：Agent 管理器（生命周期、资源配额、故障恢复）、消息路由器（基于内 容的分发、负载均衡）、性能计数器（延迟直方图、队列深度、缓存命中率）、以及配置子系统（动态更新，无需重启）。 3.6.2 主机内核补丁：Linux 调度子系统的扩展点 Wave 对 Linux 5.15 的修改约 3,000 行，集中于： 文件 修改内容 代码行数 kernel/sched/core.c sched_wave_hook() 决策点，CFS 与 ~150 Wave 交互 kernel/sched/fair.c 负载均衡，Wave Agent 咨询 ~80 mm/page_alloc.c 大页分配的 Wave 路径 ~120 Kimi.ai 生成

Table 54 – continued 文件 修改内容 代码行数 mm/migrate.c NUMA 迁移的 Wave 咨询 ~60 net/core/sock.c RPC 套接字的 Wave 标记 ~40 virt/kvm/kvm_main.c vCPU 调度的 Wave 集成 ~100 kernel/wave/ 新增子目录：事务管理器，队列抽象，中 ~2,450 断处理 设计原则：最小侵入，可上游化。调度相关修改以 ghOSt 扩展形式提交，通用事务管理器作为独立子系统提案。 3.6.3 设备驱动：PCIe 通信与 DMA 引擎优化 关键驱动优化： 技术 实现 效果 用户态驱动（vfio-pci） 绕过内核协议栈 零拷贝，低延迟 零拷贝 DMA 应用缓冲区直接作为 DMA 源/目标 消除中间缓冲 自适应批处理 动态调整批量大小 延迟-吞吐量权衡 MSI-X CPU 亲和性 中断绑定到请求发起核心 避免跨 NUMA 处理 性能基准：单队列 MMIO 带宽 2.5GB/s，延迟 150ns；DMA 带宽 12GB/s，批量传输延迟 1.2￿s。 3.6.4 用户态库：现有系统软件的 Wave 适配层 libwave 简化移植，典型适配工作量： 系统软件 适配代码量 主要修改 ghOSt 调度器 ~500 行 替换通信原语为 Wave 事务 API TMLAD 内存管理器 ~800 行 ML 模型格式转换，批量推理流水线 gRPC ~2,000 行 多线程模型调整（主机线程池 →SmartNIC 事件驱动） 适配层设计原则：保持原有 API 语义，错误处理回退本地执行，日志监控接口统一封装。 3.7 应用前景与部署场景 3.7.1 云数据中心：大规模虚拟化环境的资源优化 Wave 的直接价值量化： 规模假设 收益计算 商业价值 10 万台服务器 每服务器节省 20 核心 等效 200 万核心新增容量 核心成本 $1,000/核心（3 年 TCO） $20 亿成本节省 能耗降低 20W/核心 ×20 核心 ×10 万台 40MW 功率，年省 $3,500 万电费 部署路径：从网络密集型服务（负载均衡、缓存层）切入，逐步扩展至计算密集型服务（AI 推理、数据分析），最终覆盖全 量服务。 3.7.2 微服务架构：服务网格的 SmartNIC 加速 服务网格（Istio、Linkerd）的 Sidecar 优化： Kimi.ai 生成

当前瓶颈 Wave 方案 效果 Sidecar 消耗 30%-50% 容器资源 将 Sidecar 功能卸载至 SmartNIC 资源消耗降至 5% 以下 mTLS、流量管理、遥测收集 rpc_agent 统一处理 延迟开销接近零 Sidecar 升级需重启应用 SmartNIC 独立升级 零停机，灰度发布 架构优势：Sidecar 生命周期与 Pod 解耦，全局流量视图支持更优路由，统一遥测数据采集点。 3.7.3 边缘计算：资源受限环境的计算卸载 边缘场景的特殊考量： 约束 Wave 适配 技术调整 SmartNIC 配置降级 Agent 轻量化，功能裁剪 仅保留调度 + 网络核心功能 网络连接不稳定 离线自治模式 本地决策缓存，恢复后同步 物理安全薄弱 强化代码签名，运行时 attestation TrustZone，远程证明 适用场景：工业网关（协议转换、本地 AI 预处理）、5G MEC（基站级计算卸载）、智能摄像头（视频分析预处理）。 3.7.4 存储系统：NVMe-oF 与 Ceph 的 SmartNIC 优化 存储协议卸载方向： 组件 卸载内容 预期收益 NVMe-oF 目标端 命名空间管理，连接调度 主机 IOPS 提升 30%+ Ceph OSD 心跳检测，数据放置，压缩解压 释放核心用于 erasure coding 元数据服务 目录遍历，权限检查，缓存管理 延迟降低，吞吐提升 生态整合：Ceph 社区已探索 BlueField DPU 集成，Wave 的开源设计可促进跨厂商适配。 3.8 未来研究方向与挑战 3.8.1 更细粒度卸载：纳秒级系统软件的卸载可行性 目标场景与突破路径： 当前边界 目标 技术路径 微秒级（Wave 已实现） 纳秒级 CXL 3.0 缓存一致性，100ns 延迟 锁同步原语 无锁算法硬件化 SmartNIC 集成原子操作引擎 内存分配器快速路径 亚微秒分配 主机-SmartNIC 联合 slab，预测预 分配 CXL 3.0 的潜力：缓存一致性共享内存消除 PCIe 协议开销，SmartNIC 与主机共享 L3 缓存，理论延迟降至 100ns 以下。 3.8.2 异构 SmartNIC 支持：FPGA-based SmartNIC 的适配 ARM vs. FPGA 的权衡： 维度 ARM-based（当前 Wave） FPGA-based 开发效率 高（标准 C/C++） 低（RTL/HLS） 灵活性 高（动态加载） 中（重配置延迟） 峰值性能 中（通用处理器） 高（专用流水线） Kimi.ai 生成

Table 62 – continued 维度 ARM-based（当前 Wave） FPGA-based 能效比 中 高（算法硬化） 适用场景 复杂控制逻辑，快速迭代 固定算法，极致性能 融合路径：ARM+FPGA 异构 SmartNIC，ARM 运行 Wave Agent 框架，FPGA 加速特定内核（ML 推理、哈希 计算）。 3.8.3 安全与可信：卸载代码的验证与运行时保护 多层安全保障： 层级 机制 状态 形式化验证 调度算法关键属性（无饥饿、公平性） 研究中，部分路径已验证 运行时监控 性能计数器异常检测 已实现，生产部署 可信执行 ARM TrustZone/Intel TDX 扩展 规划中，硬件依赖 供应链安全 固件签名，配置完整性 标准实践 3.8.4 动态负载均衡：主机与 SmartNIC 间的自适应任务迁移 自适应卸载的愿景： 触发条件 迁移动作 技术挑战 SmartNIC ARM 负载 >90% 部分任务回退主机 状态分割，一致性保证 主机 CPU 空闲 >30% 本地执行优先，减少通信 快速路径切换，无抖动 网络分区 离线自治，恢复后同步 冲突检测，状态合并 策略模型更新 热加载，A/B 测试 版本管理，回滚机制 实现路径：强化学习驱动的决策引擎，基于在线性能反馈优化卸载策略，与 AutoML for Systems 趋势融合。 4. 综合对比与趋势分析 4.1 技术路线对比：LAIKA vs. Wave 对比维度 LAIKA Wave 核心目标 APU 异构计算性能最大化 SmartNIC 资源效率优化 优化方向 向内——内核深度集成 向外——功能硬件卸载 硬件假设 APU 统一内存架构 SmartNIC 通用计算能力 软件位置 Linux 内核模块 SmartNIC 用户态 + 主机适配 关键创新 AShm 三域共享，APK 持久化 用户态系统对齐，微秒级通信 性能收益 延迟 ↓9.7×，功耗 ↓71% 节省 8-16 核心，损耗 1.1%-7.4% 部署场景 边缘 AI，低功耗设备 云数据中心，大规模虚拟化 生态策略 框架插件（PyTorch/TensorFlow） 系统软件复用（ghOSt 等） 两论文代表了操作系统性能优化的两种哲学：LAIKA选择深度挖掘单节点硬件潜力，通过内核态创新消除软件开销；Wave 选择分布式资源重组，将功能迁移至专用硬件以释放主机能力。两者并非互斥——未来系统可能同时采用 APU 加速和 SmartNIC 卸载，形成” 主机-APU-SmartNIC” 的三层异构架构。 Kimi.ai 生成

4.2 共同趋势与启示 4.2.1 操作系统内核的” 瘦身” 趋势：核心功能外迁 两论文均体现了将传统内核功能迁移的趋势： 演进阶段 技术 代表 传统宏内核 所有功能内核态 Linux, Windows 微内核/外核 驱动、文件系统用户态 Minix, Exokernel 虚拟化卸载 I/O 虚拟化至 hypervisor KVM, Xen 异构卸载（当前） 计算/控制平面至专用硬件 LAIKA（APU），Wave （SmartNIC） 未来：Serverless OS 仅保留最小隔离抽象 研究中 这一趋势的驱动力：安全性（代码量减少降低攻击面）、可维护性（用户态组件更新便捷）、性能隔离（专用资源避免争用）、 专业化（特定功能由优化硬件执行）。 4.2.2 异构计算的统一抽象：编程模型与运行时融合 LAIKA 的 AShm 和 Wave 的 Agent 模型均指向统一抽象的需 求： 当前碎片化 统一抽象愿景 技术路径 CUDA/ROCm/HIP（GPU） 跨加速器统一内存模型 C++ 标准（std::mdspan），Rust （wgpu） DOCA/Pensando SDK（DPU） 硬件无关的系统软件框架 Wave 的开源实现，标准化 API oneAPI/SYCL（跨平台） 单一源代码，多目标编译 MLIR 中间表示，自动代码生成 LAIKA 和 Wave 的实践为这一愿景提供了具体输入：AShm 的三域共享机制可扩展至多加速器场景；Wave 的 Agent 模型可抽象为” 离岸执行单元” 的通用接口。 4.2.3 能效优先的设计原则：性能与功耗的联合优化 两论文均将能效作为核心优化目标，反映了行业范式转变： 指标演进 传统 当前 未来 首要指标 峰值性能（TFLOPS） 能效比（Performance/ 碳效率（Performance/kg Watt） CO2） 设计约束 散热和供电上限 可持续运营目标 全生命周期环境影响 优化层次 硬件工艺 软硬件协同 系统-数据中心-电网协同 LAIKA 的 28.9% 功耗和 Wave 的核心节省，在数据中心规模下转化为显著的碳排放降低。据估算，若全球数据中心 10% 的 AI 推理负载采用类似优化，年碳减排可达数百万吨。 4.3 对工业界的影响 4.3.1 云服务提供商：AWS/Azure/GCP 的潜在采用场景 云服务商 现有基础 Wave/LAIKA 应用 AWS Nitro 系统（Annapurna Labs） 扩展 Nitro 功能至调度/内存管理 Azure Azure Boost（Fungible/Marvell） 集成到 Boost 架构，优化 VM 性能 Kimi.ai 生成

Table 69 – continued 云服务商 现有基础 Wave/LAIKA 应用 GCP 自研 TPU+Intel IPU 与 Borg 调度系统深度集成 阿里云 神龙架构（含 MOC 卡） 类似 Wave 的卸载路径 预计 2-3 年内，主要云服务商将推出类似 Wave 的资源管理卸载功能，作为基础设施产品的差异化特性。 4.3.2 硬件厂商：AMD、NVIDIA、Intel 的产品路线图影响 厂商 当前产品 可能演进 AMD Ryzen AI（APU），Pensando APU+SmartNIC 协同优化，LAIKA （DPU） 技术集成 NVIDIA BlueField（DPU），Grace-Hopper DOCA 向 Wave 模式演进，支持通用 （CPU-GPU） 卸载 Intel Mount Evans（IPU），Gaudi（AI IPU 与 CPU 更紧密集成，CXL 优化 加速器） 新兴 Tenstorrent，SambaNova 数据流架构，原生支持任务卸载 4.3.3 开源社区：Linux 内核与相关子系统的演进 子系统 当前状态 潜在演进 sched_ext（可扩展调度器） BPF 调度类 原生支持离岸调度 Agent dma-buf（跨设备内存共享） 图形/媒体为主 扩展至通用加速器，AShm 模式标准化 CXL 子系统 内存扩展 缓存一致性优化，SmartNIC 集成 rust-for-linux 驱动开发 系统安全关键组件，Wave Agent 运行 时 5. 结论与建议 5.1 研究价值总结 5.1.1 学术贡献：操作系统与硬件协同设计的新范式 LAIKA 和 Wave 共同推进了操作系统研究的重要范式转变： 传统范式 新范式 代表工作 操作系统作为硬件的”管理者” 操作系统作为异构资源的”协调者” LAIKA（CPU-GPU 协同），Wave （主机-SmartNIC 协同） 性能优化限于软件算法 软硬件协同消除根本瓶颈 AShm（硬件统一内存 + 软件零拷贝）， Wave 通信优化（PCIe 特性 + 软件批 量） 功能完整性优先于效率 功能-效率可配置权衡 APK 持久化（透明性 vs. 性能）， Wave 适配层（兼容性 vs. 开销） Kimi.ai 生成

5.1.2 实践意义：云计算与边缘计算的性能突破路径 两论文为产业界提供了立即可用的技术路径： 场景 技术选择 预期收益 边缘 AI 推理，功耗敏感 LAIKA 式 APU 优化 10× 级延迟降低，70%+ 功耗节省 云数据中心，规模优先 Wave 式 SmartNIC 卸载 20%+ 有效容量提升，显著 TCO 优化 混合部署，灵活需求 LAIKA+Wave 组合 分层优化，全局最优 5.2 后续调研建议 5.2.1 获取论文全文 渠道 内容 优先级 ACM Digital Library ASPLOS 2026 正式出版物 高，权威版本 作者主页/机构库 技术报告，扩展实验 高，补充细节 arXiv 预印本 早期版本，快速获取 中，可能有过时内容 5.2.2 跟踪开源实现 项目 关注渠道 预期内容 LAIKA 华南师范大学 SCHOLAT 团队 内核模块，liblaika，PyTorch 插件 GitHub Wave Jack Tigar Humphries, Kostis SmartNIC 运行时，主机内核补丁，评 Kaffes GitHub 估工具 5.2.3 会议现场资料 资料类型 来源 价值 演讲 Slides ASPLOS 2026 官网，作者分享 可视化架构，关键数据强调 Demo 视频 会议录制，YouTube/Bilibili 实际运行效果，交互体验 Poster 会议现场，作者 Twitter 扩展细节，非正式讨论 同行评议 其他研究者的批评与改进 技术深度，潜在问题识别 特别值得关注的是 Wave 论文提及的后续批评与改进工作（如编号 (ResearchGate) 的 FITO critique），这些讨论对 于全面理解技术局限性和演进方向具有重要价值。 Kimi.ai 生成