5.5 KiB
名词解释
- 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
!
百炼的资源池的计算任务有 4 层：
- 实时推理任务
- Batch 推理任务
- 闲时训练任务
- 闲时数据处理任务
网关
接口协议层面提供了标准的 HTTP，HTTP SSE 和 Websocket 的接入 用户 API 的接入、鉴权、路由、限流、协议转换、计量、计费（部分）、内容安全和所有与之配套的业务逻辑 网关层同时作为平台的基础服务层，提供 Apikey、文件、用户空间、资源权限等基础服务能力
model serving
重构前：每个 model 部署一个 allinone，简单理解为一个 model 带着所有的 agent/plugin 作为一个最小单元进行部署。
!
重构后：每个 agent/plugin 单独部署（必然趋势），那么确实会存在 gateway -> agent1 -> gateway -> agent2 -> ... 这种不断通信的模式。尤其在 model 的 output 越来越长、模态种类越来越多（图片、视频）的场景下，通信开销确实不可忽视。
Q: 不同 agent 之间的数据如何传递？都需要经过网关再发给另一端吗？是否存在一个 global storage 存放不同 agent 的 output，实现共享（那么也需要考虑 global storage 内的隔离）
!
VL model
通过一系列一体化工作来减少图片/视频的传输，否则所有的图片/视频数据在经过每个节点时都需要传输，带来大量的开销。
!
!
!
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 亲和性
只拉指定位置的请求
!
且每个节点不知道其它节点的状态，容易陷入非全局最优的局面。
batch
财年batch api日调用占比商业化模型大盘20%，带动资源利用率提升10％
技术面临两大挑战
-
如何高速稳定的处理用户任务 长请求qps要大于2.5万+ 有状态，考虑ACID，不能丢、不能重复、状态一致、失败重试
-
不增加额外成本，不影响在线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 有什么不同的需求