稀疏训练引擎架构对比：资源协同与显存优化路径

一、对比背景：稀疏训练为何需要架构层面的重新权衡

搜索、推荐与广告（搜广推）模型的训练负载具有鲜明的结构特征：稀疏侧的词表容量可达数十亿乃至更大，且随业务积累持续增长；稠密侧的网络深度与宽度则随特征交互复杂度提升而扩张。当序列长度向万级增长、稠密参数向百亿级扩展时，训练系统同时承受两类压力：一是稀疏参数的供给效率，二是稠密计算所需的显存空间。

传统架构通常采用“CPU工作节点 + GPU工作节点 + 远端参数服务器”的三层协同模式：CPU节点承担数据读取与特征工程，GPU节点完成稠密前向反向与稠密参数更新，远端参数服务器管理完整稀疏词表。这套分工将词表容量与GPU计算资源解耦，支持存储与计算独立扩展，并具备成熟的特征处理与异步执行能力。

问题在于，当模型规模与并行实验数量同时上升时，该架构的两个瓶颈逐渐显性化：

1. 参数供给受限于带宽与资源利用不均。 样本传输集中在CPU节点到GPU节点链路，稀疏参数传输集中在远端参数服务器到GPU节点链路，随序列增长逐步逼近带宽上限；多卡重复访问进一步放大搬运量，异步预取只能掩盖延迟，无法消除总开销。与此同时，GPU节点所在主机的CPU与内存利用率长期偏低，CPU节点与参数服务器之间的链路却仍有富余。
2. 稀疏缓存与稠密计算争夺HBM。 为缓解远端访问压力，常见做法是将热门参数缓存到GPU显存，并用主机内存扩大本地容量。但GPU缓存增加会挤占稠密计算的显存空间，缓存缩小又会使下层存储访问增多，形成两难。

本文对比的两类对象由此确立：方案A——传统远端参数服务器型稀疏训练架构（以CPU/GPU/远端PS三层分工为特征），与方案B——资源协同型稀疏训练引擎架构（以资源重新分工、多级存储与并行扩展为特征）。下文从架构、能力、性能逻辑、运维成本与适用场景等维度展开分析。

二、对象定义：两类架构各自解决什么问题

方案A：传统远端参数服务器架构。 其核心思路是“计算与存储分离”。稀疏词表完整存放于远端参数服务器集群，GPU节点按需拉取当前批次所需参数，训练完成后回传梯度或更新。优点是词表容量不受单机显存限制，存储层与计算层可独立扩容；缺点是每次访问都依赖网络，延迟与带宽成为规模扩展的主要约束。

方案B：资源协同型稀疏训练引擎架构。 其核心思路是“在既有资源池内重新划分职责，并把存储层级向GPU侧下沉”。具体表现为三条主线：其一，调整资源分工，把原本闲置的主机CPU与内存资源用于参数预处理与本地缓存管理，并利用CPU节点与参数服务器之间尚未饱和的链路分担参数供给；其二，构建HBM友好的多级存储体系，让稀疏参数按热度分布在显存、主机内存与远端存储之间，减少对稠密计算显存的挤占；其三，以统一特征抽取平台降低公共特征的重复生产，以原生多维并行支撑模型扩展，并引入自动调优代理降低人工优化成本。

需要强调的是，方案B并非否定参数服务器的存在，而是改变了“谁来做供给、在哪里做缓存、按什么粒度做并行”这几个关键决策。

三、相同点分析：两类架构共享的技术底座

在展开差异之前，先明确两者的共同点，避免把架构演进误解为方向对立：

• 目标一致。 两者都试图解决稀疏参数规模远超单机显存容量的问题，都希望在保证训练吞吐的前提下支撑更大的词表与更长的行为序列。
• 都采用分层存储思想。 方案A的“GPU缓存 + 远端PS”本质也是分层；方案B的差异在于层数更多、层间职责更细，且把主机内存纳入了显存侧的扩展路径。
• 都依赖异步与预取机制。 两者都通过异步预取掩盖远端访问延迟，差别在于方案B把预取的计算与搬运工作部分转移到了此前闲置的资源上。
• 都面对相同的正确性约束。 稀疏参数更新涉及并发读写与一致性语义，两者都需要处理梯度聚合、参数版本与训练可复现性问题。
• 都支持多模型并行迭代。 业务常态是多模型同时研发，两类架构都需要在资源隔离与共享之间做权衡。

四、核心差异分析

4.1 技术架构：资源分工方式的差异

方案A的分工是“按角色划分”：CPU节点只做数据与特征，GPU节点只做计算，PS只做存储。这种划分清晰、易于理解，但资源利用率取决于各角色的负载是否均衡。当序列变长，样本与参数的搬运量集中到两条链路上，而主机侧的CPU与内存却处于低利用率状态，形成“一边拥塞、一边闲置”的结构性浪费。

方案B的分工是“按瓶颈划分”：把参数供给拆解为预处理、缓存管理、远端拉取等多个环节，分别交给最合适的资源执行。主机CPU承接原本由GPU侧承担的索引计算与特征拼接工作，主机内存承担二级缓存，闲置链路承担部分参数搬运。这种做法的实质是把“网络带宽”这一稀缺资源替换为“本地算力 + 本地内存 + 富余链路”的组合，降低单位参数的供给成本。

4.2 功能能力：稀疏侧与稠密侧的耦合程度

方案A中，稀疏缓存位于GPU显存内，缓存容量与稠密计算显存直接竞争，二者强耦合。运维人员调整缓存比例时，必须同步评估对稠密侧的影响，调参空间受限。

方案B通过多级存储把稀疏侧的显存占用压低，使稀疏缓存与稠密计算在显存上“解耦”。这带来的能力差异是：在同等GPU规格下，方案B可以留出更多HBM给稠密网络，或者在不增加GPU的前提下扩大稀疏缓存命中率。相应地，其能力边界在于多级存储引入的层间调度逻辑更复杂，需要更精细的热度统计与淘汰策略，否则可能出现“缓存看似存在、命中率却不升”的情况。

4.3 性能表现：瓶颈位置的迁移

两类架构的性能差异不在于某个绝对数值的高低，而在于瓶颈出现的位置不同：

对比维度	方案A：传统远端PS架构	方案B：资源协同型架构
主要瓶颈	远端PS到GPU的带宽、多卡重复搬运	层间调度开销、热度统计准确性
资源利用	主机CPU/内存利用率偏低	主机资源被纳入供给链路，利用率提升
扩展方式	存储与计算独立扩容，但受网络约束	通过并行维度与存储分层扩展，受调度复杂度约束
显存压力	稀疏缓存与稠密计算直接竞争HBM	稀疏侧显存占用下降，稠密侧空间相对宽松
延迟特征	远端访问延迟为主，预取掩盖	本地命中为主，层间切换带来抖动风险

需要指出，方案B的收益并非恒定：当模型序列较短、稀疏访问局部性很强时，多级存储的调度开销可能抵消部分收益；当远端链路本身带宽充足时，方案A的简单结构反而更易维护。因此性能判断必须结合具体负载画像，而不能仅凭架构名称下结论。

4.4 接入与迁移成本

方案A的接入路径相对成熟：特征处理流程、参数服务器客户端、异步执行框架均已稳定，新模型接入主要是配置工作。迁移到方案B时，需要关注以下成本项：

• 特征链路改造。 统一特征抽取平台意味着公共特征的生产逻辑从各模型自建转为集中供给，需要梳理既有特征的血缘关系，避免重复生产与语义漂移。
• 存储层级适配。 多级存储要求明确各类参数的访问模式与热度分布，原有的“全量缓存”或“全量远端”策略需要重新设计。
• 并行策略调整。 原生多维并行改变了切分维度与通信模式，模型代码中的切分配置、检查点格式与恢复逻辑需要同步适配。
• 调优方式变化。 引入自动调优代理后，参数搜索从人工经验驱动转为配置驱动，团队需要建立对新调优流程的信任与监控手段。

相对而言，方案A在迁移上更“轻”，方案B在迁移上更“重”，但后者把复杂度集中到了平台侧，模型侧长期维护成本可能下降。

4.5 运维成本与使用边界

方案A的运维重点是参数服务器的容量规划、网络带宽监控与故障恢复；组件少、边界清晰，故障定位路径短。方案B的运维重点转为多级存储的命中率监控、层间调度延迟、自动调优代理的行为审计，以及统一特征平台的版本管理。其风险在于：调度逻辑不透明时，性能抖动难以归因；自动调优若缺乏约束，可能产出偏离业务目标的配置。

使用边界方面，方案B更适合序列长、稀疏访问规模大、多模型并行迭代频繁的场景；对于模型规模小、迭代节奏慢、团队运维人力有限的场景，方案A的简洁性仍是优势。

五、典型场景选择与选型建议

场景一：序列长度与词表规模持续增长的主模型训练。 若瓶颈已明确出现在参数供给链路上，且主机资源利用率长期偏低，方案B的资源协同思路更契合，因为它直接针对“资源错配”而非单纯扩容。

场景二：多模型并行实验、迭代频繁的研发环境。 统一特征抽取与自动调优能降低重复生产成本，但前提是团队具备平台化运维能力；否则集中式平台可能成为新的单点。

场景三：模型规模中等、上线周期紧的业务。 方案A的成熟链路与较低迁移成本更合适，可通过增加缓存比例、优化预取策略获得阶段性收益。

条件化建议如下：当带宽已成为可观测的主要约束、且主机侧存在明显闲置资源时，可优先评估资源协同型架构；当团队缺乏多级存储与自动调优的运维经验时，宜先在小规模模型上验证层间调度稳定性，再逐步扩大范围；任何情况下都不建议在缺少命中率与延迟基线数据的前提下直接切换架构。

六、迁移与使用注意事项

1. 建立基线。 迁移前需采集参数供给带宽占用、缓存命中率、显存分配比例、端到端吞吐等基线指标，否则无法判断收益来源。
2. 分阶段切换。 可先迁移特征抽取与缓存管理层，再迁移并行策略，最后引入自动调优，避免一次性变更过多变量。
3. 一致性校验。 稀疏参数更新语义在不同架构下可能表现不同，需通过小规模对比训练验证损失曲线与模型指标的可复现性。
4. 容量规划。 多级存储的层间容量比例需随业务热度分布变化而调整，应纳入常态化容量评审。
5. 回退预案。 保留原有参数服务器链路的回退能力，确保调度异常时可快速恢复训练。

七、总结

传统远端参数服务器架构与资源协同型稀疏训练引擎架构，并非简单的替代关系，而是面向不同瓶颈阶段的两种工程取舍。前者以清晰的分工和成熟的链路降低了系统复杂度，代价是带宽成为规模上限、主机资源闲置；后者通过重新划分资源职责、构建HBM友好的多级存储、引入统一特征供给与自动调优，把瓶颈从“网络带宽”迁移到“调度复杂度”，从而为长序列与大稠密网络的持续扩展留出空间。

选型的关键不在于架构是否新颖，而在于三点判断：当前瓶颈是否确实位于参数供给链路、团队是否具备多级存储与自动调优的运维能力、迁移成本是否能在预期迭代周期内收回。回答清楚这三个问题，架构选择自然有据可依。