131 lines
5.5 KiB
Markdown
131 lines
5.5 KiB
Markdown
# 名词解释
|
||
|
||
- **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 有什么不同的需求
|
||
|
||
|