# trace 部分

## 现存的问题

1. traceA 和 traceB 来自不同的 log，格式不同，处理时需要的脚本不同
2. traceA 和 traceB 之前测试时使用的时长分别为 1h/2h，时长不统一 & 不够长
3. trace 相关的处理脚本、绘制脚本不够高效
	- 需要 load 所有 trace 进 RAM，1h/4h 还能处理，24h 下显然不可行
	- 即使是 simulator，4h 数据也需要差不多 1h 运行，24h 下效率太低

## TBD

- 统一 preprocess 一遍 24h 的 traceA 和 traceB，得到一份统一好用的 trace
- 优化现有脚本，把 load all 改为 streaming，支持 24h 的 trace 处理
- 刷一遍现有 trace 分析的数据
	- 改为 24h 后，一天内应该会出现特征的波动，为了说明一段较长的连续时间内是稳定的（小时级别），可能需要同时展示 24h 和 2h 的数据（高峰/低谷：9-11 / 22-24）
	- 预期：特征与之前分析的结论一致。24h 下一天的波动可能能带来一些新发现
- suggestion from 大爷：一个表，现有 paper 的假设/观察 和我们在实际工业界 trace 观察的关系：结论相同？相悖？

## From vLLM v1 meetup

1. 移除 prefill 和 decode 的概念
![[projects/kvcachecache/Refine roadmap.figs/250414-000021.png]]
2. 不做 PD 分离，对 scheduler 自然提出了很高的要求（需要 scheduler 尽可能避免 compute-bound/memory-bound）。vLLM 团队也有计划做 workload-specific scheduler。不过他们这个是请求到来的 workload-aware，不是我们之前的 KVCache 的 workload-aware。我们 refine 工作时，可能也可以思考 workload-aware 对 scheduler 能提供什么帮助。【需要先熟悉 vLLM v1 最新的 scheduler】
![[projects/kvcachecache/Refine roadmap.figs/250414-000021-1.png]]
3. 针对不同场景 Reasoning/Coding/... 做优化，我们的 workload-aware 能否考虑到这类信息，对系统设计/优化提供有价值的信息？
![[projects/kvcachecache/Refine roadmap.figs/250812-140723.png]]

# Response

- [ ] workload 对 PD 分离 global scheduler 有什么启发？
- [ ] workload 对 MoE 的影响？不同 workload 下，硬件配比是否有变化？
- [ ] Deepseek 320 experts， 320 卡每张卡一个 expert，如果在 8 卡下跑，expert 如何分布？激活特性？