Initial commit: obsidian to gitea

projects/moe-autoscaling/Sync.md

@@ -0,0 +1,105 @@
+# 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？
+
+