Initial commit: obsidian to gitea

projects/moe-autoscaling/Bailian Arch.md

@@ -0,0 +1,130 @@
+# 名词解释
+
+- **CPFS**: Cloud Parallel File Storage. CPFS provides a unified namespace and supports concurrent access of hundreds of machines. CPFS also provides an I/O throughput of tens of GB/s and millions of IOPS to ensure a sub-millisecond latency.
+- **ODPS (MaxCompute)**: MaxCompute (previously known as ODPS) is a general purpose, fully managed, multi-tenancy data processing platform for large-scale data warehousing. MaxCompute supports various data importing solutions and distributed computing models, enabling users to effectively query massive datasets, reduce production costs, and ensure data security.
+- **CEN**: Cloud Enterprise Network. CEN uses transit routers deployed in different regions to build a full-mesh network on top of the Alibaba Cloud global transmission network.
+- **BladeLLM**: BladeLLM is an inference engine tailored for large language model (LLM) optimization and high-performance model deployment. BladeLLM has an advanced technical architecture and provides a user-friendly interface and outstanding performance to address new opportunities and challenges in LLM fields. This makes BladeLLM a suitable choice for enterprises that want to deploy LLMs and use the LLMs to perform inference.
+
+# Arch
+
+![[250716-011140.png]]
+
+百炼的资源池的计算任务有 4 层：
+- 实时推理任务
+- Batch 推理任务
+- 闲时训练任务
+- 闲时数据处理任务
+
+
+## 网关
+
+接口协议层面提供了标准的 HTTP，HTTP SSE 和 Websocket 的接入
+用户 API 的接入、鉴权、路由、限流、协议转换、计量、计费（部分）、内容安全和所有与之配套的业务逻辑
+网关层同时作为平台的基础服务层，提供 Apikey、文件、用户空间、资源权限等基础服务能力
+
+
+## model serving
+
+重构前：每个 model 部署一个 allinone，简单理解为一个 model 带着所有的 agent/plugin 作为一个最小单元进行部署。
+![[250715-192813.png]]
+
+重构后：每个 agent/plugin 单独部署（必然趋势），那么确实会存在 gateway -> agent1 -> gateway -> agent2 -> ... 这种不断通信的模式。尤其在 model 的 output 越来越长、模态种类越来越多（图片、视频）的场景下，通信开销确实不可忽视。
+
+Q: 不同 agent 之间的数据如何传递？都需要经过网关再发给另一端吗？是否存在一个 global storage 存放不同 agent 的 output，实现共享（那么也需要考虑 global storage 内的隔离）
+
+![[250715-135101.png]]
+
+## VL model
+
+通过一系列一体化工作来减少图片/视频的传输，否则所有的图片/视频数据在经过每个节点时都需要传输，带来大量的开销。
+
+![[250715-202224.png]]
+
+![[250715-202246.png]]
+
+![[250715-202304.png]]
+
+
+
+## global batching
+
+方案：
+
+> 在Global Dynamic Batching的设计上，我们选择使用拉模式来进行调度，一句话概括为API Server先将请求发送至Redis全局队列，推理节点（Model Serving）从全局队列中拉取请求。
+
+Claim:
+
+> RR模式（推）负载不均衡：
+>     RR模式所有请求在调度层的视角下是相同的，LLM请求的差异性会导致负载不均衡
+>
+> 模型服务的容量难以评估：
+>     每个LLM请求的生成长度是未知数，无法准确评估下一时刻模型服务的容量
+>
+> 长尾延迟：
+>     在集群整体水位较低的情况下，也会出现非预期的长尾延迟请求（Prefill聚集）
+
+
+> 低时延迟：API Server和Turbo对Redis的操作耗时在毫秒级别
+
+但是每个推理节点主动从全局队列拉时，如何选择拉哪个请求？确实主动拉取的方案能够保证负载均衡和可靠性，但 KVCache 亲和性如何考虑？
+
+$n$ 个请求时，$k$ 个 instance（$k < n$），$O(nk) \to O(n^2)$，若每个节点都需要独立判断 KVCache 亲和性
+
+只拉指定位置的请求
+![[250716-012653.png]]
+
+且每个节点不知道其它节点的状态，容易陷入非全局最优的局面。
+
+## batch
+
+> 财年batch api日调用占比商业化模型大盘20%，带动资源利用率提升10％
+
+技术面临两大挑战
+
+1. 如何高速稳定的处理用户任务
+	长请求qps要大于2.5万+
+	有状态，考虑ACID，不能丢、不能重复、状态一致、失败重试
+
+2. 不增加额外成本，不影响在线api的SLO
+	不能为batch准备GPU资源，在线闲时的资源有多少，如何给batch使用
+
+- 用户任务并发，改为用户模型任务并发，解决用户多模型任务排队问题
+
+调度策略升级，requestId排队改为batchId排队
+- 解决查request表慢sql问题，提升整体qps，从1000qps提升至6000+qps
+- 多个batch同时调度，长短请求混合，减少模型服务突发扩缩容次数
+- 灵活调度策略，方便设置高优先级用户
+
+「解决查request表慢sql问题，提升整体qps，从1000qps提升至6000+qps」无法理解！是否说明查 sql 表成为了比 batch 推理更大的 bottleneck？
+
+
+Q: ToB 场景中 online 和 batch 的需求分别占多少？
+
+## serverless
+
+TBD
+
+
+## 无影 AgentBay
+
+TBD
+
+
+---
+## 杂
+
+>「目前百炼上架、更新、下架一个基础模型服务需要很多团队配合完成」，每个模型上线需要：商业化研发：设置模型计量、计费配置；测试：模型出账、配置验证
+
+这件事听起来非常麻烦，是否有统一的设置方案
+
+
+> PAI为百炼提供模块功能，例如，拓扑感知的POD分配策略。合作的团队不止有PAI，例如模型启动加速的工作也会有更底层的阿里云团队参与。
+
+
+
+
+# Thinking
+
+batch 任务和 online 任务处理时的区别，对 MoE 有什么不同的需求
+
+