3.8 KiB
3.8 KiB
# OKR
## Objectives
1. MoE pattern feature
2. EP design for inference performance
## Key results
- [ ] 现有工作的激活 pattern，与真实 trace 测试结论的对比 [O1]
- [ ] load imbalance 的 temporal locality，workload (reasoning/...)
- [ ] 层间 load imbalance 的 correlation
- [ ] Models 是否 sensitive：Qwen3-30B/235B, DeepSeek-671B [O1]
- [ ] EP 是否需要 dynamic，dynamic EP 扩缩容对性能的影响 [O2]
---
# 0617
- 在 8 * H800 上跑起来 Qwen3-235B，进行 expert activation 的 trace
- 代码开发：distributed 在当前版本的 vllm 会 fallback 到 v0，之前测试 30B 模型（num_expert=48）为单进程，默认开启 v1，完成了在 distributed 上的代码重写
- 测试得到一份 235B model 的 expert activation trace，尚未进行 data analysis
- 跑 DeepSeek-671B
- 完成了 Ray 版本 & DeepSeek 模型的 expert activation trace 部分的 vllm 代码
- 学习 Ray
- 使用 Ray 运行满血 DeepSeek，存在的问题
- 默认的 vllm 尚且不能正常跑起来（怀疑是最新的 main 分支存在 bug），checkout 回 0.9.1 版本，rebuilding wheel...
- 基本的 expert activation temporal pattern 分析
- 每 5min 作为一个 bin，与全局 1h 的 TopK expert IDs 的 Jaccard 相似度比较（取 K=8）
!
- 每 5min 作为一个 bin，前 5min 与后 5min 的 Jaccard 相似度比较
!
- [ ] 完成 671B 模型的测试
- [ ] 测试 ShareGPT
- [ ] expert 部分 同步 or 异步
- Request defer 对 GPU memory 的影响（GPU coroutine）
- [ ] 从 **异步**/load balance/colocation 出发，能给出哪些观察
- [ ] 动态重排 experts 的 cost？
---
# 0624
- 运行起 DeepSeek-671B，并且可以 trace expert activation pattern
- 当前存在的问题：16 * H800 中测试 DeepSeek 时只能使用受限的 prompt 长度（< 1024）
- 分析 Qwen-235B 的 expert pattern
- 与全局 1h 的 TopK expert IDs 的 Jaccard 相似度比较（取 K=8）
$$
\text{Jaccard(A, B)} = \frac{|A \cap B|}{|A \cup B|}
$$
!
- 前 5min 与后 5min 的 Jaccard 相似度比较
!
---
# 0701
Survey
- [ ] 总结百炼的架构，分析整体系统有什么可能可以做的
- [ ] expert scaling
前提：流量 spike，模型切换（数量？）需要启动，模型为 MoE 模型
- [ ] train 和 inference 的 A2A 的区别？和 deepep 的区别？
- [ ] 容错问题？本质 GPU 数量增多，更容易挂，EP 是不是最容易容错的？kvcache 的容错
- [ ] failure 的概率？
- [ ] replication 除了容错，能服务什么
GPU serverless?
---
# 0715
Bailian Arch
---
# 0722
- 老 trace ToB/ToC 混合
- Bailian Arch
- 不同并行模式的 scheduling
同一模型会有不同的 parallel setup，global schedule 可以做当前 request 的特点做 route，选择最合适的 parallel setup 的 instance，$P = f(req, queue, state)$
- 不同 parallel setup 对请求类型/长短的影响体现在哪里？
- 考虑 global 做 batch 时，一个 batch 对 parallel setup 的亲和性如何考虑？如何做 batch？如何做分发？
现状：一个 model serving 会有多个部署，每个部署内部一般还是相同的 parallelism，但是不同的部署可能会采用不同的 parallelism，目前线上的主要区别来自于：在线请求与 batch 请求，batch 请求由于类型不同/SLO 需求不同，可能会采用不同的 parallelism mode 分别满足不同的 SLO 需求（thpt/latency）
---
# 0729
Trace-Qwen3
Heterogenous Parallelism Cluster
Transfer to project: heterogenous parallelism
---
# TBD
为什么 MoE 能减少 attention head？
agent 场景下，master 的 KVCache 动态变化，如何容错，简单的 replica？
MoE 如何容错，expert re-route？
- 每 5min 作为一个 bin，前 5min 与后 5min 的 Jaccard 相似度比较
!
- [ ] 完成 671B 模型的测试
- [ ] 测试 ShareGPT
- [ ] expert 部分 同步 or 异步
- Request defer 对 GPU memory 的影响（GPU coroutine）
- [ ] 从 **异步**/load balance/colocation 出发，能给出哪些观察
- [ ] 动态重排 experts 的 cost？
---
# 0624
- 运行起 DeepSeek-671B，并且可以 trace expert activation pattern
- 当前存在的问题：16 * H800 中测试 DeepSeek 时只能使用受限的 prompt 长度（< 1024）
- 分析 Qwen-235B 的 expert pattern
- 与全局 1h 的 TopK expert IDs 的 Jaccard 相似度比较（取 K=8）
$$
\text{Jaccard(A, B)} = \frac{|A \cap B|}{|A \cup B|}
$$
!
- 前 5min 与后 5min 的 Jaccard 相似度比较
!
---
# 0701
Survey
- [ ] 总结百炼的架构，分析整体系统有什么可能可以做的
- [ ] expert scaling
前提：流量 spike，模型切换（数量？）需要启动，模型为 MoE 模型
- [ ] train 和 inference 的 A2A 的区别？和 deepep 的区别？
- [ ] 容错问题？本质 GPU 数量增多，更容易挂，EP 是不是最容易容错的？kvcache 的容错
- [ ] failure 的概率？
- [ ] replication 除了容错，能服务什么
GPU serverless?
---
# 0715
Bailian Arch
---
# 0722
- 老 trace ToB/ToC 混合
- Bailian Arch
- 不同并行模式的 scheduling
同一模型会有不同的 parallel setup，global schedule 可以做当前 request 的特点做 route，选择最合适的 parallel setup 的 instance，$P = f(req, queue, state)$
- 不同 parallel setup 对请求类型/长短的影响体现在哪里？
- 考虑 global 做 batch 时，一个 batch 对 parallel setup 的亲和性如何考虑？如何做 batch？如何做分发？
现状：一个 model serving 会有多个部署，每个部署内部一般还是相同的 parallelism，但是不同的部署可能会采用不同的 parallelism，目前线上的主要区别来自于：在线请求与 batch 请求，batch 请求由于类型不同/SLO 需求不同，可能会采用不同的 parallelism mode 分别满足不同的 SLO 需求（thpt/latency）
---
# 0729
Trace-Qwen3
Heterogenous Parallelism Cluster
Transfer to project: heterogenous parallelism
---
# TBD
为什么 MoE 能减少 attention head？
agent 场景下，master 的 KVCache 动态变化，如何容错，简单的 replica？
MoE 如何容错，expert re-route？