106 lines
3.8 KiB
Markdown
106 lines
3.8 KiB
Markdown
# 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）
|
||
![[250624-105430.png]]
|
||
- 每 5min 作为一个 bin，前 5min 与后 5min 的 Jaccard 相似度比较
|
||
![[250624-105431.png]]
|
||
|
||
- [ ] 完成 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|}
|
||
$$
|
||
![[250624-152355.png]]
|
||
- 前 5min 与后 5min 的 Jaccard 相似度比较
|
||
![[250624-152444.png]]
|
||
|
||
|
||
---
|
||
# 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？
|
||
|
||
|