💡 [REQUEST] - <title>qwen推理模型是否可以多机分布式部署？（单机单卡不足以支撑推理模型部署，需要多机多卡）

[feifaxiaoming]

起始日期 | Start Date

No response

实现PR | Implementation PR

我想布置qwen-14B-chat推理模型，但是我只有两台16G显存的机器，一张卡上运行不起来模型，我想问一下，是否可以两台机器分布式部署推理模型

相关Issues | Reference Issues

No response

摘要 | Summary

多台机器分布式部署推理模型

基本示例 | Basic Example

如何使用两台tesla-16G进行14B-chat的推理

缺陷 | Drawbacks

单机单卡不足以支撑

未解决问题 | Unresolved questions

No response

[xuanhua]

目前transformer默认都是使用自家的accelerate这个库来提供推理的，从目前来看这个库只支持单机多卡。多节点的推理其实应该也很简单，都是类似。
huggingface/accelerate#1890

[feifaxiaoming]

目前transformer默认都是使用自家的accelerate这个库来提供推理的，从目前来看这个库只支持单机多卡。多节点的推理其实应该也很简单，都是类似。 huggingface/accelerate#1890

您提供的连接中，也是咨询多节点得，但是我发现里面并没有给出解决答案，您那有能用的方案吗？

[xuanhua]

@feifaxiaoming 对，我给你的链接就说明目前huggingface这边还没有实现这块儿功能，建议你单步跟踪一下huggingface的模型的token的生成过程。尤其是将 device_map 参数设置为 ”auto“ 的时候。transformers库使用了huggingface家的另外一个叫做accelerate的库，这个库会把模型的各个sumodule分散放到不同的设备上（优先gpu，gpu显存不够了，再往cpu的memory上放）。然后在模型进行forward的过程时候，修改了原有模块的forward函数，使得原有的foward函数执行之后还会执行一个post的操作，就是把foward的输出结果放到下一submodule的forward操作之后，首先将上一轮的计算结果防止到该submodule所在设备上。同理，如果是跨节点，那么就需要将某一个节点上最后执行完的结果通过网络发送到下一个节点上。从更高效率的角度上说，似乎还需要一个mpi，或者nccl来做一个调度器，让整个pipeline更加有效率。

[xuanhua]

@feifaxiaoming 另外，训练和推理还是不太一样，推理的时候，如果是分成两台机器，生成一个token需要两次数据传输；
假设机器A上存储模型的0~15层，机器B上存储模型16~29层（假设模型一共30层transformer结构），那么在完成计算所有prompt中的token对应的hidden states （假设为H_0）的计算之后，计算真正所需要生成的第一个token需要经历下面的过程：
1） H_0在机器A上作为输入，经过0~15层的计算，产生第一个token所对应的 h_1_A （形状为 batch_size \times hidden_size）
2) h_1_A通过A和B之间的网络到达B机器
3）B机器使用h_1_A作为输入，经历16~29层的计算，产生h_1_B作为最后的输出，h_1_B在机器B上进行采样（假设使用采样的方法生成token）生成token t_1
4） t_1从B传回到A
5）A将现有的context长度加1，继续回到第 1)步
所以，每生成一个token，实际上两台机器之间就需要进行两次数据交换；假设最快耗时为1秒进行网络传输，那么一个token就需要多2秒针计算时间。对于一个prompt，整体计算下来的时间消耗基本上很难接受。例如生成120字，你可能光在网络传输上就需要等待120 x 2 = 4 分钟；所以你的两台机器之间网络传输速度要非常快，例如10ms，那么 120 x 20ms = 2.4s； 所以需要两台机器之间的网络延时非常的小，并且估计需要把batch size设置的很大，充分利用带宽。 总之训练的时候使用的并行预测token，多机也还行，但如果是推理，多机基本上对网络要求太高了。大部分的时间都是在网络传数据上。

[feifaxiaoming]

accelerate这个库只能单机多卡部署，不能实现多机并行，还有您说的这个层的，我试验了使用device_map拆分了80层，在单机上是可用的，但是多机的时候并不好用，您那边是否有可以直接使用的方案呢？就是可以多机分布式部署的模型方案呢》？

[feifaxiaoming]

@feifaxiaoming 另外，训练和推理还是不太一样，推理的时候，如果是分成两台机器，生成一个token需要两次数据传输； 假设机器A上存储模型的015层，机器B上存储模型1629层（假设模型一共30层transformer结构），那么在完成计算所有prompt中的token对应的hidden states （假设为H_0）的计算之后，计算真正所需要生成的第一个token需要经历下面的过程： 1） H_0在机器A上作为输入，经过015层的计算，产生第一个token所对应的 h_1_A （形状为 batch_size \times hidden_size） 2) h_1_A通过A和B之间的网络到达B机器 3）B机器使用h_1_A作为输入，经历1629层的计算，产生h_1_B作为最后的输出，h_1_B在机器B上进行采样（假设使用采样的方法生成token）生成token t_1 4） t_1从B传回到A 5）A将现有的context长度加1，继续回到第 1)步 所以，每生成一个token，实际上两台机器之间就需要进行两次数据交换；假设最快耗时为1秒进行网络传输，那么一个token就需要多2秒针计算时间。对于一个prompt，整体计算下来的时间消耗基本上很难接受。例如生成120字，你可能光在网络传输上就需要等待120 x 2 = 4 分钟；所以你的两台机器之间网络传输速度要非常快，例如10ms，那么 120 x 20ms = 2.4s； 所以需要两台机器之间的网络延时非常的小，并且估计需要把batch size设置的很大，充分利用带宽。 总之训练的时候使用的并行预测token，多机也还行，但如果是推理，多机基本上对网络要求太高了。大部分的时间都是在网络传数据上。

accelerate这个库只能单机多卡部署，不能实现多机并行，还有您说的这个层的，我试验了使用device_map拆分了80层，在单机上是可用的，但是多机的时候并不好用，您那边是否有可以直接使用的方案呢？就是可以多机分布式部署的模型方案呢》？

[xuanhua]

@feifaxiaoming 帮你找了一个多机推理的方案，https://github.com/LambdaLabsML/llama/tree/main

不过如我上面所说，普通的硬件做推理没有意义。下面是reddit上一个老外回复。简而言之就是普通硬件的多机推理方案慢到没有实际意义。

I'm assuming you want to run one model on muliple nodes and on consumer hardware.

That will not work at all or will have extremely bad performance. Training primarily needs raw computational power and not a lot of memory bandwidth. For inference it is the other way around.

You would need something like, RDMA (Remote Direct Memory Access), a feature only available on the newer Nvidia TESLA GPUs and InfiniBand networking. That will get you around 42GB/s bandwidth on hardware in the 200.000$ and upwards price range. To put that into perspective, the internal memory bandwidth of a 4090 is ~1,008 GB/s.

This is also the reason why multi node inference is not well supported software wise, DeeoSpeed, PyTorch and Trition can theoretically do that and if I remember some people tried multi-node inference with Trition and SLURM (Simple Linux Utility for Resource Management) if you want to dig deeper.

以上英文来源于一个叫做wreckingangel的网友在 Reddit 上的回复。

[github-actions]

This issue has been automatically marked as inactive due to lack of recent activity. Should you believe it remains unresolved and warrants attention, kindly leave a comment on this thread.
此问题由于长期未有新进展而被系统自动标记为不活跃。如果您认为它仍有待解决，请在此帖下方留言以补充信息。