基于Golang所开发的大模型API高性能调度平台

• 可观测性、可运维性、可拓展性

• 优先级控制（高优队列排序）

• qps与tpm限制

• 账号池维护

• 任务队列维护

• 任务撤销，回调

• 更多大模型的API接入

• scheduler

• 创建任务，插入到相应的任务队列

• 维护任务状态，对外提供查询接口

• worker

• 根据 redis 中的队列优先级信息，拉取任务并执行

• 控制 tpm（维护账号-当前 tpm 信息）

• 从 account 中获取账号，拼接请求体

• account

• 维护逆向账号池

• 提供 api，更新账号池

• fe

• 提供一个前端页面查看任务状态

• 可以在前端创建任务，编辑任务（调整优先级），撤销任务

• 简单的查看管理账号池

• 一个用户可以创建若干个队列，一次提交对应一个队列

• 提交时，会生成对应的任务id，并更新优先级信息

• 每个队列可以由多个文件扫描而来，一个队列对应一个 redis 列表

• 调度器从队列取数据时，根据优先级信息动态判断要取哪个列表

• 队列机制

• 不维护一个总的队列，而是提交的每一个任务，单独有一个队列，任务id 作为 key

• 单独存一份不同任务id 的优先级

• 取数据的时候，根据优先级，动态选择当前从哪一个队列取

• 撤销任务，只要删除对应的队列并删除优先级数据即可

• 插队只要更新一下优先级信息即可

• 为何不用kafka，mq等消息队列？

• 因为消息队列实现撤销任务、灵活的多级别的优先级队列很麻烦，会导致复杂度变高，可维护性变差。不如用 redis

• 如何实现 tpm 或者 qps 控制？

• 每次请求完，账号作为 key，更新当前账号的 tpm、qps，这个信息由 worker 更新到 redis 中

• 请求前，找请求对应 model且 tpm不超过该账号限制的账号来请求

• 如果没有满足条件的账号，就 wait 一段时间

• 如何保障在tpm限制下，当前系统达到最大吞吐？

• 维护当前账号的可用，一个号的tpm或者rpm打满就换另一个号，直到无号可用，才等待

• 每一个 worker 可以开多个协程，这个数量可以增加动态调整机制

• 实时任务实现

• 控制中心默认空出最高优先级，所有实时任务全部推入到当前优先级

• 任务结果

• 共享存储硬盘

• oss、cos等存储云

• redis

原文始发于微信公众号（逆向OneByOne）：基于Golang所开发的大模型API高性能调度平台