# mas

**Repository Path**: liukai_1900/mas

## Basic Information

- **Project Name**: mas
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-06-18
- **Last Updated**: 2026-06-22

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 复现 MAS 优化实验

对论文中 **混合智能体调度器（Mixed Agentic Scheduler, MAS）** 评测的离散事件复现：

> *Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric
> Perspective* —— Raj, Kundu, Vohra, Wang, Krishna（arXiv 2511.00739v3），第 5.3 节、
> 算法 1、图 7 与图 8。

本项目复现的是论文的**调度机制与结论**，而非其硬件实测数据。论文的数字来自真实系统
（RTX-6000 Pro / H200、Grace / Xeon）运行无法获取的私有智能体负载。我们能够复现、也正是
论文真正贡献的部分，是这套**机制**：在共享并发预算下，通过类型感知的弹性准入策略，保护
少数派请求类型免受队头阻塞。本仓库从第一性原理重建该机制，并展示它能产生论文的定性图形
和同一量级的加速比。

## 论文指出的问题

智能体服务混合了两类瓶颈不同的请求：

- **CPU 密集型** —— 在主机上执行工具调用，瓶颈在 CPU 核心。
- **GPU 密集型**（"LLM 密集型"）—— 纯 LLM 推理，由高度并行化的 GPU 处理。

单一的 **FCFS** 准入队列配上共享的并发预算 `N_max`，会让占多数的那一类请求**垄断准入
名额**。于是少数派类型即使**自己的资源处于空闲**，也会在准入队列里遭受队头阻塞。

**MAS（算法 1）** 用按类弹性准入解决这个问题：

- 每类配额 `E_cap,CPU = 64`、`E_cap,GPU = 128`，
- 一个用于吸收突发的共享储备 `E_cap,shared = 32`，
- 每类各自的 FCFS 等待队列，在每次完成时按**轮转（round-robin）**方式排空。

`64 + 128 + 32 = 224 = N_max`，因此 MAS 与 FCFS 在**等并发（iso-concurrency）**下运行——
MAS 不增加任何容量，只是重新分配准入。任何收益都纯粹来自调度。

## 建模内容

| 论文概念 | 模型实现 |
|---|---|
| CPU 核心 / GPU 序列 | 两个有限容量的**处理器共享（PS）池**；超额订阅时按比例减慢所有在途请求，于是当负载逼近某资源吞吐拐点时，在系统内的占用数会爬升进入 `N_max` 预算（即饱和区）。 |
| 开环突发到达 | 两状态 ON/OFF **MMPP**；每 32 个请求翻转一次相位（与论文一致）。速率设置使长期平均到达率等于 λ（横轴），而 ON/OFF 比例控制突发程度。 |
| 请求混合比例 | `p_LLM = P(GPU 密集型)` ∈ {0.25, 0.50, 0.75}。 |
| 服务时间 | 对数正态分布，变异系数可配置。 |
| FCFS 基线 | 单一共享准入队列，预算 `N_max`。 |
| MAS | 逐字实现算法 1：类型桶 + 共享储备 + 轮转排空。 |

PS 池通过虚拟时间服务标签**精确**模拟，每个事件 `O(log n)`
（`mas_sim.py:PSPool`）——没有时间步进，也没有对共享动态的近似。

## 文件说明

| 文件 | 用途 |
|---|---|
| `mas_sim.py` | 纯标准库离散事件模拟器：PS 池、FCFS + MAS 调度器、MMPP 到达。 |
| `run_experiments.py` | 对每个系统 × `p_LLM` × 调度器扫描 λ，各跑 5 个随机种子；输出 `results.csv`。 |
| `plot_results.py` | 生成 `figure7_sys1.png` / `figure8_sys2.png` 并打印核心结论核对。 |
| `results.csv` | 生成的模拟输出。 |
| `figure7_sys1.png`、`figure8_sys2.png` | 生成的论文图形复现。 |

## 运行方式

```bash
python3 run_experiments.py     # 生成 results.csv
python3 plot_results.py        # 生成两张图 + 打印结论核对
```

模拟器为纯标准库；仅绘图用到 `matplotlib`。

## 标定（重要说明）

服务参数与 λ 区间**并非取自论文硬件实测**——它们的选取是为了让每种请求类型的饱和拐点
（`拐点 = 容量 / 平均服务时间 / 负载占比`，单位 req/s）落在论文的 λ 扫描区间内，
这正是让 FCFS 与 MAS 的差异显现出来的条件。

| 系统 | C_cpu | C_gpu | 说明 |
|---|---|---|---|
| Sys1（Xeon / RTX-6000） | 10.0/s | 12.7/s | 拐点较低 → λ 区间较低（图 7） |
| Sys2（Grace / H200） | 12.0/s | 15.8/s | 核心更多 + GPU 更快 → λ 区间更高（图 8） |

每个区间的上端都只到**轻度**饱和（约为绑定资源拐点的 1.1 倍）。这一点很关键：FCFS 是开环
的，一旦深入拐点之后，其少数派准入队列会无界增长，加速比会爆炸式地飙到毫无意义的
10–15 倍。把扫描控制在轻度饱和，可让 FCFS 的少数派延迟保持有界，使报告的加速比落在论文的
个位数量级。均衡的 `p=0.50` 区间则跨骑在拐点上，使均匀混合也能达到饱和并显现出总延迟收益。

## 复现结果与论文对比

`plot_results.py` 会打印如下对比（少数派类型取 λ 区间内的最大 FCFS/MAS 加速比；
总延迟取区间内的平均值）：

| 结论 | 论文 | 本复现 |
|---|---|---|
| `p=0.25` 少数派 **GPU 密集型**被保护（Sys2），P50 / P90 | 最高 2.37× / 2.49× | **6.24× / 4.88×** |
| `p=0.75` 少数派 **CPU 密集型**被保护（Sys2），P50 / P90 | 约 2.09× / 2.15× | **3.64× / 2.81×** |
| `p=0.50` 总延迟收益（Sys1），P50 / P90 | 1.62× / 1.30× | **1.27× / 1.05×** |
| 多数派类型基本不变 | 持平 | **1.02–1.24×** |

**三条定性结论全部精确复现：**

1. **少数派保护。** 在 `p=0.25` 时，MAS 的 GPU 密集型延迟曲线*持平*（约 4.3s），而 FCFS
   陡升到 20–40s 区间；在 `p=0.75` 时，CPU 密集型呈现镜像图景。少数派类型被屏蔽于多数派的
   准入垄断之外。
2. **多数派不变。** 占主导类型的 FCFS 与 MAS 曲线相互重叠——MAS 不会牺牲多数派去保护少数派
   （它也做不到：等并发约束）。
3. **均衡混合仍有收益。** 在 `p=0.50` 时，一旦混合达到饱和，MAS 的总延迟就位于 FCFS 之下。

复现出的**数值量级**落在论文的个位数范围内，但并不完全相同。这是预期之中、且并非缺陷：
精确的比值纯粹是「扫描深入饱和拐点多远」以及（无法获知的）真实服务时间分布的函数。这些都是
标定旋钮，在没有论文硬件与负载的情况下并无真值。把它们硬调到恰好命中 2.37× 只是把一个行为
模型过拟合到一个标题数字上，毫无增益。真正忠实的——也是论文真正讨论的——是这套**机制及其
方向**，而本复现干净地捕捉到了它。