网络带宽不足：由于一台 GPU 机器可以顶替多台 CPU 机器，必然会导致整个集群网卡数量降低。这样在将数据和模型下载到 Trainer 阶段就很容易出现带宽瓶颈。尤其是当 Server 和 Trainer 都在一台设备时，一旦每个 Trainer 划分的训练数据过大，训练准备阶段就会变得极为耗时，整个训练过程直接输在了起跑线上。
图 4：传统参数服务器架构（GPU 机器）遇到 IO 瓶颈
也许有人会提出直接将 IO 任务交给 GPU 机器上的 CPU 不就可以解决了吗？答案是否定的。一台 GPU 机器上的 GPU 和 CPU 的硬件配比是固定的，且单台 GPU 的多卡相比多台 CPU 机器而言，每个 GPU 卡对应的 CPU 核数相对较少，这就导致 GPU 前向后向训练的越快，对 CPU 读数据和模型参数的要求就越高，这样 CPU 反而更容易成为瓶颈，而且不能解决网络带宽不足的问题。
新型算力接入成本较大。随着 AI 芯片发展日新月异，各种高算力低成本的芯片已进入工业实用化阶段。在参数服务器模式下，一旦更换新型算力硬件，需要完成计算集群的迁移，软件栈变更，训练速度及效果打平等一系列工作。
那么有没有可以
高效调整机器配比，快速支持新硬件的接入，使用 GPU 等高算力的同时还不用担心 IO 瓶颈的方法呢？
鱼与熊掌可以兼得？——异构参数服务器训练架构
上面的要求好像很多，其实核心问题就在于硬件的配置，传统的参数服务器对硬件的统一性要求太严格，而现实是单一「兵种」是无法应对大部分「战场」的。如果能同时使用不同的硬件同时参与到训练中，让它们各司其职，发挥各自优势，很多问题就可以迎刃而解了！
为了应对上述问题，飞桨框架 2.0 版本基于工业实践，创新性地
推出了大规模稀疏异构参数服务器功能，一举解除了传统参数服务器模式必须严格使用同一种硬件型号 Trainer 节点的枷锁，使训练任务对硬件型号不敏感，即可以同时使用不同的硬件进行混合异构训练，如 CPU、AI 专用芯片（如百度昆仑 XPU）以及不同型号的 GPU 如 V100、P40、K40 等。同时还可以解决大规模稀疏特征模型训练场景下，IO 占比过高导致的芯片资源利用率过低的问题。通过异构参数服务器训练架构，用户可以在硬件异构集群中部署分布式训练任务，例如云服务器集群，实现对不同算力的芯片
高效利用，为用户提供更高吞吐、更低资源消耗的训练能力。
图 5：异构参数服务器架构示意图
异构参数服务器架构的原理
如之前所述，在传统参数服务器模式下，前向及反向步骤在 Trainer 端完成，参数更新在 Server 端完成。而在异构参数服务器架构中，原先那样粗粒度的任务分工显然不再适用，只有让不同硬件参加到训练任务中，并在自己最擅长的领域工作，才能各显神通。因此飞桨的研发人员在传统的 CPU-Trainer 之外，又部署了一类 Heter-Trainer，并在 Heter-Trainer 上配置有 Service。这样 CPU-Trainer 便将 Heter-Trainer 视为特殊的 Server，从而对 Heter-Trainer 的异构算力不敏感，使 Heter-Trainer 可以混部各类不同型号芯片（例如 GPU 或 XPU 等）。
为了让 CPU-Trainer 和 Heter-Trainer 完成不同类型的任务，飞桨将整个计算任务做了进一步的拆分。CPU-Trainer 继续负责数据读取、参数的读取和更新、参数的网络传输等 IO 任务，甚至在小 BatchSize 训练时，使用 CPU 处理更快的网络层计算；而对于复杂网络的计算，则 CPU-Trainer 会交给 Heter-Trainer 处理。总之，所有 CPU 相对 GPU 或 XPU 更擅长处理的操作都放在 CPU 中，其它的放在 GPU 或 XPU 中。
图 6：传统参数服务器架构的异构改造
值得注意的是，异构参数服务器架构并不只是简单的将计算任务拆分。拆分后，异构硬件间的通信代价高的问题也需要解决。为了解决这个问题，飞桨的整个传输通信过程得到了优化。该过程将不会完全依赖于硬件自身的吞吐，而是引入类协程任务调度机制，该机制采用了异步等待和多 Queue 流水线等方式对任务进行灵活调度，避免传输队列阻塞，对任务进行灵活调度，并且还优化了 Heter-Trainer 的吞吐机制，高效的避免传输队列阻塞。
