跳转至

作业 5 基础部分：从场景出发分析 NexOS 作为 AIOS 的设计动机

一、作业目标

本次作业希望大家基于前四次实验，从一个整体系统的角度思考：

如果 NexOS 要作为移动端 AIOS 或云端 AIOS，它需要解决什么系统问题？AI service、内存管理和文件系统应当如何协同支撑这个目标？

你需要选择一个主分析场景：移动端 AIOS 或云端 AIOS。报告应当围绕下面这条主线展开：

在这个场景中，NexOS 作为 AIOS 到底需要解决什么目标问题？

前四次实验已经提供了哪些系统机制雏形？

这些机制距离真正支撑该场景，还存在哪些不足和改进方向？

二、作业背景

本次作业提供两个参考场景。你需要选择其中一个作为主分析场景。

移动端 AI 应用调用场景

假设 NexOS 的设计目标是一个移动操作系统，例如 Android、iOS 或 HarmonyOS。

在这个场景中，系统主要服务于单个用户，大部分时间只有一个 AI 请求正在执行。系统资源相对有限，例如：

  • 内存：8 GB - 16 GB；
  • 存储：256 GB - 1 TB；
  • 计算资源：移动端 CPU / NPU / GPU。

一个典型的设备样例：

移动端设备样例

此时 NexOS 需要更加关注：

  • 响应延迟；
  • 内存占用；
  • 能耗；
  • 本地隐私；
  • 模型文件管理；
  • 前台应用体验。

在这种场景下，移动端往往倾向于使用大小在 3-7B 的模型。以一个 Qwen-7B 全量模型为例，本作业中为了简化计算，统一假设模型权重按每个参数 2 Bytes 存储，则：

\[ 7 \times 10^9 \times 2\ \text{Bytes} \approx 14\ \text{GB} \]

这说明，对于移动端设备来说：

  1. 14 GB 的模型文件可以放入 256 GB - 1 TB 的本地存储中；
  2. 但 8 GB - 16 GB 内存很难轻松容纳完整模型、操作系统、其他 App、输入输出缓冲区和运行时中间数据；
  3. 因此端侧 AIOS 的关键问题不是服务大量并发请求，而是如何在有限内存和能耗约束下，让一个本地 AI 应用稳定运行；
  4. 文件系统需要负责模型文件、缓存文件、对话历史和用户数据的管理；
  5. 内存管理需要考虑按需加载、用户缓冲区、进程隔离、内存不足时的失败处理等问题。

移动端场景的核心矛盾

移动端设备有足够的本地存储保存 3-7B 规模的模型文件，但内存、能耗和前台交互体验都受到严格限制。

因此，端侧 AIOS 的核心问题不是如何服务大量并发请求，而是如何在有限资源下，让一个本地 AI 请求稳定、及时、可控地完成，同时不破坏整个移动系统的可用性。

云侧 AI 应用调用场景

假设 NexOS 的设计目标是一个为了 LLM 服务优化的云端操作系统，例如 Linux 的各种发行版。

在这个场景中，系统主要服务于多用户请求，大部分时间会有多个 AI 请求同时执行。系统资源相对丰富，例如：

  • 内存：512 GB；
  • 存储：100+ TB；
  • 计算资源：8 张 H200 显卡。

设备样例：

云端设备样例

此时 NexOS 更加需要关注：

  • 吞吐量；
  • 公平性；
  • 请求调度；
  • 多租户隔离；
  • 缓存复用；
  • 故障恢复；
  • 模型版本管理。

在这种场景下，云侧往往倾向于提供更加智能的模型，例如大小 70B 以上的模型。以一个 Llama 3.3 70B 全量模型为例，采用相同方式估算：

\[ 70 \times 10^9 \times 2\ \text{Bytes} \approx 140\ \text{GB} \]

如果云侧节点使用 8 张 H200，NVIDIA H200 规格中每张 H200 有 141 GB HBM3e 显存，因此总显存约为：

\[ 8 \times 141\ \text{GB} = 1128\ \text{GB} \]

这说明，在云侧场景中，模型权重可以作为一个常驻共享资源：系统通常不会为每个用户请求重新加载一份完整模型，而是让多个请求共享同一个已经加载好的模型。

云侧更关键的问题是：

当模型权重已经常驻并共享后，每个请求运行过程中动态产生的 KV cache 会随着上下文长度和并发请求数增长，成为系统资源管理的核心压力。

做一个简单的计算：假设你现在要使用 AI 帮你优化一份大学生心理学期末报告，报告字数约 4000 字。为了便于估算，这里近似把一个字理解为一个 token。对于 Llama 3.3 70B，这里参考 Llama 3.3 70B 公开配置 中的 num_hidden_layers = 80、num_key_value_heads = 8、head_dim = 128 进行估算：

\[ \begin{aligned} \text{每 token 的 KV cache} &= \text{层数} \times 2 \times \text{KV head 数} \times \text{head 维度} \times \text{每元素字节数} \\ &= 80 \times 2 \times 8 \times 128 \times 2\ \text{Bytes} \\ &= 327680\ \text{Bytes} \\ &\approx 320\ \text{KiB} \end{aligned} \]

因此，一份 4000 字报告对应的 KV cache 规模约为：

\[ 4000 \times 320\ \text{KiB} \approx 1.2\ \text{GiB} \]

如果经过多轮对话修改，上下文总长度继续增加，单个请求的 KV cache 可能超过 10 GiB。若一个年级的学生都使用同一套云端服务，粗暴保存所有请求的 KV cache 和历史状态，就可能产生上千 GiB 的额外资源压力。

这说明，对于云端 AIOS 的设计来说：

  1. 以 Llama 3.3 70B 为例，按每个参数 2 Bytes 估算，模型权重约为 140 GB。对于拥有 512 GB 内存、100+ TB 存储空间和 8 张 H200 显卡的云侧节点来说，模型文件和模型权重通常可以作为常驻资源被系统加载和管理；
  2. 但云侧 AIOS 的主要压力并不只是模型权重本身。模型权重通常可以被多个用户请求共享，而每个请求运行过程中产生的 KV cache 会随着上下文长度和并发请求数量增长。例如，单个 32K 上下文请求大约需要 10 GiB KV cache，单个 128K 上下文请求大约需要 40 GiB KV cache；
  3. 因此云侧 AIOS 的关键问题不是“一个模型能否放入系统”，而是如何在模型常驻共享的基础上，同时服务大量用户请求，并高效、公平、安全地管理请求队列、KV cache、显存/内存资源和运行时状态；
  4. 文件系统需要负责模型文件、模型版本、用户数据、请求日志、错误日志和持久化结果的管理。与移动端不同，云侧文件系统的重点通常不是每次请求都重新读取模型，而是支持模型仓库、版本切换、日志记录、故障恢复和多用户数据隔离；
  5. 内存管理需要考虑模型权重共享、KV cache 分配与回收、长上下文请求限制、缓存复用、内存/显存碎片、多租户隔离和请求失败时的资源释放等问题。如果某个用户请求占用过多 KV cache，系统应当能够限制、排队、驱逐缓存或拒绝新的请求，避免影响其他用户。

云端场景的核心矛盾

云端节点通常可以让大模型权重常驻并被多个请求共享，但并发请求会持续产生 KV cache、请求状态、日志和用户数据。

因此，云侧 AIOS 的核心问题不是单个模型能否装入系统，而是如何在多用户并发下管理请求队列、内存/显存资源、缓存复用、公平性和隔离性。

三、作业要求

完成一篇 3 页左右的系统分析报告。报告必须选择一个主分析场景：移动端 AIOS 或云端 AIOS。

你的报告需要围绕一个明确的中心论点展开，而不是逐题回答。一个合格的中心论点可以写成类似下面的形式：

在移动端场景中，NexOS 最应该优先优化的是有限资源下的本地 AI 请求稳定执行。Lab2 的 AI service 提供了请求生命周期管理的雏形，Lab3 的 Lazy Allocation 和 COW 提供了缓解内存压力的机制基础，Lab4 的文件系统提供了模型文件和用户数据管理的基础；但当前 NexOS 仍缺少面向模型按需加载、内存压力控制、能耗约束和错误恢复的完整设计。

或者：

在云端场景中，NexOS 最应该优先优化的是多用户并发下的资源隔离与吞吐效率。Lab2 的 AI service 可以抽象为请求调度入口，Lab3 的内存机制可以用于分析模型权重共享和 KV cache 压力，Lab4 的文件系统可以支撑模型版本、日志和用户数据管理；但当前 NexOS 仍缺少 KV cache 调度、跨请求缓存复用、多租户隔离和故障恢复机制。

报告结构要求

报告需要把 Lab2、Lab3、Lab4 的机制放入同一个场景中，说明它们如何共同支撑你选择的系统目标。可以简要联系 Lab1 中的用户程序和系统调用接口，但报告重点应放在 AI service、内存管理和文件系统的协同分析上。

建议报告结构

可以按下面的结构组织报告。

  1. 场景与核心问题

    说明选择的是移动端 AIOS 还是云端 AIOS。结合模型权重、内存容量、存储容量、并发请求或 KV cache 等因素，解释这个场景中 NexOS 面临的主要系统压力。

  2. NexOS 的优先优化目标

    明确 NexOS 在该场景下最应该优先优化什么。例如：

    • 移动端：响应延迟、内存占用、系统稳定性、能耗、本地隐私；
    • 云端：吞吐量、公平性、资源隔离、缓存复用、故障恢复。

    不需要同时优化所有目标，但需要解释为什么你选择的目标最重要。

  3. 现有实验机制如何支撑该目标

    请把前四次实验中的机制作为论证材料，而不是逐个复述实验内容。你至少需要讨论下面三个方面：

    • AI service：请求提交、等待、完成、失败返回、worker 退出时的状态更新；
    • 内存管理：Lazy Allocation、COW、模型权重或 KV cache 带来的内存压力；
    • 文件系统：模型文件、缓存、日志、用户数据、模型版本和错误可见性。

    重点说明这些机制为什么是 AIOS 的基础。

  4. 当前 NexOS 的不足与待改进方向

    说明当前 NexOS 距离真正支撑该场景还缺少什么。可以从请求调度、资源限制、模型按需加载、KV cache 管理、缓存复用、权限隔离、错误恢复或性能优化等角度展开。

  5. 小结

    用一段话总结：你选择的场景中，NexOS 作为 AIOS 的核心目标是什么；当前实验成果已经提供了哪些基础；未来最关键的改进方向是什么。

可参考的思考方向

如果你不知道如何展开，可以参考下面的问题。但这些问题只是帮助你组织思路，不是要求你逐条作答。

  • 在你选择的场景中，NexOS 最应该优先优化哪个目标？为什么？
  • AI service 接收到请求后，应该立即执行、放入队列、拒绝，还是返回错误？判断依据是什么？
  • 如果请求执行时间过长、资源不足，或者 AI worker 退出，AI service 应该如何更新请求状态，并把结果或错误返回给用户程序？
  • 主要的内存压力来自哪里？是模型权重、输入输出缓冲区、运行时中间数据、KV cache，还是多个进程之间的资源竞争？
  • Lazy Allocation 可以如何帮助 NexOS 推迟内存分配、降低启动时内存压力，或者避免一次性分配过多无用内存？
  • COW 可以如何帮助多个进程共享已有内存，减少不必要的数据复制？在 AI service、worker 进程或用户程序 fork 的场景中，它可能带来什么好处和风险？
  • 文件系统需要管理哪些 AI 相关数据？例如模型文件、输入文件、输出结果、缓存、日志、用户历史记录或模型版本。
  • 如果模型文件缺失、损坏、版本不一致，或者用户没有权限访问某个文件，NexOS 应该如何让 AI service 或用户程序感知到这个错误？

四、提交要求

请提交一篇 3 页左右的 PDF 报告到BB系统上的Hw5基础部分。

报告至少需要包含：

  1. 一个明确的主分析场景：移动端 AIOS 或云端 AIOS；
  2. 一个清楚的中心论点：NexOS 在该场景中最应该优先解决什么系统问题；
  3. 对现有实验成果的综合分析：AI service、Lazy Allocation / COW、文件系统分别如何支撑该目标；
  4. 对待改进方向的分析：当前 NexOS 还缺少哪些机制，为什么这些机制对该场景重要。