- 主题:pajamax,高性能grpc服务端框架
阻塞等待gpu去算。此处阻塞是否有必要性,常规做法感觉应是非阻塞才好吧?
【 在 ensonmj 的大作中提到: 】
: 我现在就是单独起一个tokio,接受外部请求,预处理。然后通过channel提交给这个loop线程。loop 线程每次try recv外部请求,有就加进来,没有继续计算。计算过程就是就是组建一个大的batch,然后交给外部gpu去算。然后阻塞等待gpu返回结果。 gpu worker那边可以起一个同步的grpc server,因为gpu的请求永远是1,追求的不是高并发,而是低延迟。
: 概括地讲,就是一个llm 请求调度器 。
--
FROM 123.127.159.*
重点是我不想把这个loop线程交给tokio调度,也不想在这个线程中使用await。非阻塞也许可是考虑,但问题会更复杂一些,因为llm中下一次迭代是依赖上一次结果的。
【 在 AlphaO (AlphaO) 的大作中提到: 】
: 阻塞等待gpu去算。此处阻塞是否有必要性,常规做法感觉应是非阻塞才好吧?
:
: 【 在 ensonmj 的大作中提到: 】
: : 我现在就是单独起一个tokio,接受外部请求,预处理。然后通过channel提交给这个loop线程。loop 线程每次try recv外部请求,有就加进来,没有继续计算。计算过程就是就是组建一个大的batch,然后交给外部gpu去算。然后阻塞等待gpu返回结果。 gpu worker那边可以起一个同步的grpc server,因为gpu的请求永远是1,追求的不是高并发,而是低延迟。
--
FROM 39.144.103.*
那确实啊,就用同步就好了。运行时调度有不同策略,还有触发机制横插一杠子,我尝试过,时序要求严的场景不如同步。
【 在 ensonmj 的大作中提到: 】
: 重点是我不想把这个loop线程交给tokio调度,也不想在这个线程中使用await。非阻塞也许可是考虑,但问题会更复杂一些,因为llm中下一次迭代是依赖上一次结果的。
--
FROM 123.127.159.*