1
blless 2020-05-31 20:03:19 +08:00 via Android
并发是解决 IO 密集问题, 计算密集要么靠算法 要么就靠加硬件了
|
2
helloworld000 2020-05-31 20:27:52 +08:00 3
哥们我从你问的这些问题可以感觉你貌似学了不少 fancy 的名词,但是并没有都真正理解这些到底是干嘛的。。。
|
3
David1119 2020-05-31 20:29:33 +08:00
@helloworld000 哈哈哈,够 fancy~~~
|
4
andj4cn 2020-05-31 20:37:13 +08:00
你需要的仅仅是计算资源调度和分配,跟 MQ 没有任何卵关系
|
5
xiaoFine OP @blless 对,算法端已经不能提速了,gpu 资源有限,并发一高就崩了,所以想着加个消息队列
|
7
xiaoFine OP @helloworld000 是的,确实是个二把刀,还请指教
|
10
inwar 2020-05-31 22:12:40 +08:00 via Android
专业平台有多实例+gpu 虚拟化,自己玩可以做调度,分时间片
|
11
sioncheng 2020-05-31 22:12:40 +08:00
粗浅地认为,消耗 GPU 的程序应该是计算密集型的吧,而 rabbbitmq 是用来支撑 IO 密集型的程序。
|
12
liuxey 2020-05-31 22:19:24 +08:00
分开来看
1. 急迫需要 GPU 算力的服务,为什么要削峰,还不赶紧跑满计算出结果 2. 不急破 GPU 算力的服务,反正不急,GPU 跑着慢慢算呗,阻塞就阻塞 |
13
tfdetang 2020-05-31 22:33:15 +08:00 via Android
小规模的推理服务其实不是特别需要 gpu, 因为显存 io 的开销很大,不如多分几个 cpu 推理服务。
如果非要用 gpu,那必须用好 batch 运算。将队列中的任务压到一个 batch 里再传递到 gpu 。 当然简单的只是做一个阻塞队列也是可以的 |
14
hallDrawnel 2020-05-31 22:35:52 +08:00
这个要看具体的算法,比如深度学习模型可以做 batch 化调度,稍微增加一小点延迟提高计算速度。计算密集型的任务问题不在于 IO 等待,在于算不完,只能加硬件或者优化算法解决。
|
16
qieqie 2020-05-31 23:07:56 +08:00
其实楼主的想法并非没有道理,
cuda 的驱动对于每一个 stream 是维护了一个内部的 kernel 发射队列的, 如果超过了这个队列的上限会阻塞 cpu 线程。 所以需要做 batch 或者在 cpu 上用 queue 调度。 |
17
xcstream 2020-05-31 23:09:28 +08:00
就是排队,一个一个来
|
18
different 2020-05-31 23:15:06 +08:00 via Android
会不会是多个服务申请显存,显存不够就炸了?
|
20
helloworld000 2020-06-01 07:05:39 +08:00
好了不开玩笑了
前面提了很多解决办法,比如加机器,multiple-queue,batch ( gang scheduling )这些都算方法之一 但真正的得看你具体应用具体环境的。这玩意不会有银弹或者 1,2 个这些 fancy words 就能搞定的。 整个一套里面还有很多东西,弄下来真没你想的那么简单,大公司都是有专门的 infra team 来做这些。 给你一个正确的学习思路,你可以看看 k8s 相关文档,google borg,borg2 ( https://research.google/pubs/pub49065/) 还有 bytedance 的这个工作 https://github.com/bytedance/byteps |
21
xiaoFine OP @helloworld000 感谢(看来还有很多路要走
|
22
kennylam777 2020-06-01 14:36:45 +08:00
如果你的 GPU 只是一種保證獨佔的計算資源,在 k8s 已經輕鬆解決。
|
23
xiaoFine OP 回头自问自答下。
这个要看各家的 serving 框架,目前 triton 和 torchserver 都能做到 dynamic batching 之类的功能,但本质上每次推理还是显卡独占;如果是为了省 GPU ,另一个思路是 GPU 虚拟化,暂时没实践 |