笔记|记录|文本

云端大模型接口设计

场景

1. 云端建立 websocket 客户端发送日志
2. 大模型端建立websocket 服务端接收客户端发送日志并进行推理

思路

云端每次发送日志之前通过 HTTP 请求大模型端获取是否可以建链（同步），大模型服务判断获取当前剩余并发数，返回云端是否可以建链，若可以则云端建立客户端发送日志（异步），若不能执行则排队。

1. 为什么每次建链都要请求？

   因为有的日志包含的故障数量很多，诊断此类任务需要更多的资源以达到更好的响应速度，此时并行度应该减少，以加速推理。

2. 是否每个任务来时都要请求？

   如果队列是空则请求，否则加入队列，直到有一个客户端执行结束时从队列头取出任务，再次请求。

3. 大模型端如何控制并行数？

   大模型端任务应该有三种状态：可以建链但未执行 allow_not_run，已经建链且已执行 running，执行结束 completed。

   当收到云端建链请求时，若可以建链，allow_not_run + 1，假设parallel_num = 5, 依次有5个任务都接收建链请求但未执行则 request = 5，第6个则排队。若云端异步建立5个客户端发送日志，则 runing = 5, allow_not_run = 0，若有一个任务推理完成，则 completed = 1，running = 4, 那么对应的客户端结束，则需要请求是否可以建链，若是则从队列中取任务建链发送（异步）。

问题

1. 若客户端发送建链请求，服务端响应可以建链，服务端 allow_not_run + 1，但是在那段时间由于网络等种种问题，或者直接云端服务直接断电，建链失败等，那么大模型端永远有 5个allow_not_run占据？

   allow_not_run 应该是一个类，包括请求时间，预期过期时间，取值 0/1，若到了预期的过期时间，还不是0，则取0