# 名词解释

- **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 有什么不同的需求