稀疏参数供给与显存扩展如何兼得？搜广推模型训练架构对比解析

一、对比背景：模型规模膨胀倒逼训练架构升级

在搜索、广告、推荐（搜广推）业务中，模型正在经历两个显著变化：其一，用户行为序列长度从百级向万级增长，以捕捉更完整的兴趣演化；其二，Dense 网络参数规模从十亿级向百亿级扩展，以提升特征交互的表达能力。这两个趋势直接冲击了传统训练系统的两大资源瓶颈——参数供给带宽和显存容量。

原有训练系统普遍采用“CPU Worker 负责数据与特征、GPU Worker 负责稠密计算、远端参数服务器（PS）管理稀疏词表”的分工架构。这种架构的优点是词表容量与 GPU 计算资源解耦，存储和计算可独立扩展。但当序列变长、词表变大后，两条传输链路——CPU Worker 到 GPU Worker 的样本流、远端 PS 到 GPU Worker 的参数流——都面临带宽压力。多卡重复访问同一批参数进一步放大了数据搬运量，而 GPU Worker 所在节点的 CPU、内存利用率往往长期低于 35%，造成资源闲置。

因此，本文对比的两类方案为：

• 方案A：传统远端 PS 架构（即上述 CPU Worker + GPU Worker + Remote PS 的分工模式）；
• 方案B：资源协同与 HBM-Friendly 多级存储架构（即从调整资源分工入手，充分利用主机资源与通信链路改善参数供给，并通过多级存储降低稀疏侧显存占用的新型引擎方案）。

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

方案A：远端 PS 架构将稀疏参数集中存储在远端服务器集群中，GPU Worker 按需拉取。其核心优势在于词表容量不受单机显存限制，支持超大稀疏特征。同时，CPU Worker 承担数据预处理，可以异步执行，掩盖部分 I/O 延迟。

方案B：资源协同与 HBM-Friendly 架构不再将远端 PS 作为唯一参数来源。它重新划分了资源角色：利用 CPU Worker 所在节点的内存和 CPU 算力作为参数供给的中间层，将热点参数缓存在 GPU 侧，冷门参数放置在主机内存或更底层的存储中。通过动态调整缓存策略和通信调度，让每一条链路都服务于参数供给，同时尽量减少对 HBM 的侵占。

三、相同点分析：共同目标与基础能力

两种架构在以下方面具有一致性：

1. 目标一致：都是为了支撑更大规模的稀疏参数和更长的行为序列，保证模型训练收敛效率。
2. 基础组件相似：都依赖 CPU 进行数据预处理，使用 GPU 完成稠密矩阵计算，都有独立的稀疏参数存储层。
3. 都支持异步执行：通过预取、缓存、流水线等手段隐藏数据加载延迟。
4. 都面临 HBM 容量约束：需要在“缓存多少热点参数”与“留给 Dense 计算多少显存”之间做权衡。

四、核心差异分析

1. 资源分工逻辑

方案A中的资源角色相对固定：CPU Worker 只做数据，GPU Worker 只做计算，远端 PS 只存参数。这种分工清晰，但容易造成资源利用率不均——GPU 节点上的 CPU 和内存大量空闲，而远端 PS 的带宽和存储压力持续攀升。

方案B重构了资源角色：CPU Worker 不再只是数据生产者，还承担了参数预取、排序、去重等中间处理；主机内存被纳入多级存储体系，成为 GPU 缓存的“第二层”；通信链路则被动态调度，避免单一链路过载。这使得原本闲置的 CPU 和内存资源被盘活，降低了远端 PS 的访问频率。

2. 参数供给路径

方案A的路径固定为“远端 PS → GPU Worker”，所有参数访问都要经过这条链路。序列越长，每轮迭代需要拉取的参数量越大，带宽成为硬瓶颈。

方案B构建了多级供给路径：热点参数常驻 GPU 缓存，次热门参数存放在主机内存，冷门参数才回源到远端存储。GPU 优先从最快的层级读取参数，仅在缓存未命中时才访问下层。同时，模型可以依据访问频率动态调整缓存内容，让有限的 HBM 空间服务最频繁使用的参数。

3. 显存管理策略

方案A对 HBM 的使用分为两部分：Dense 参数和梯度占据大部分显存，稀疏参数缓存只分配少量空间。当词表访问局部性较强时，小缓存会导致命中率低，频繁回源；若加大缓存，又挤压 Dense 计算所需空间，限制了模型宽度或 batch size。

方案B的 HBM-Friendly 策略在于“分级存储 + 智能驱逐”：通过统计参数访问频次，将高频参数固定在 GPU 侧，低频参数自动迁移到主机内存。这种方式让 HBM 空间不再是固定划分，而是随访问模式动态调整。另外，多级存储还可以有效利用 CPU 节点的内存带宽，将其作为参数聚合和分发的中间缓冲，避免 GPU 直接面对远端存储的高延迟访问。

4. 扩展性表现

方案A的扩展主要依赖增加远端 PS 节点数量或提升其带宽。但这种方式会带来更高的通信成本，且多模型并行时，每个模型都独占一份 PS 资源，总体资源利用率低。

方案B更强调资源协同：多模型训练时可以共享同一套主机内存缓冲池和多级存储体系，重复特征抽取的结果可以被复用，减少公共特征的生产成本。同时，方案B支持多维并行策略的组合，包括数据并行、模型并行、序列并行和专家并行等，可以根据模型结构灵活选择。

5. 调优与运维成本

方案A的调优重点在于 batch size、学习率、缓存容量、预取深度等超参数，经验性强且难以迁移。多模型并行时，每个模型都需要单独调参，人力成本高。

方案B引入自动调优机制，通过智能体监控训练状态，动态调整缓存分配、通信调度和并行策略参数。这降低了对资深工程师经验的依赖，也让系统能在模型规模变化时自动适应，减少人工干预。

五、对比表格

维度	方案A：传统远端PS架构	方案B：资源协同与HBM-Friendly架构
资源角色	CPU只做数据，GPU只做计算，PS只存参数	CPU参与参数预处理，主机内存参与多级存储
参数供给路径	远端PS→GPU，单链路	多级缓存（GPU→主机内存→远端）动态调度
显存占用	稀疏缓存与Dense静态争夺HBM	分级存储+动态驱逐，减少稀疏侧HBM占用
带宽压力	高，尤其多卡重复访问	中，热点本地命中，冷门才回源
扩展性	依赖增加PS节点，资源共享难	多维并行组合，多模型共享缓冲池
调优成本	高，依赖人工经验	低，支持自动调优
适用场景	词表规模中等、序列长度不长	万级序列、百亿Dense参数、多模型迭代

六、典型场景选择

• 场景一：词表中等、序列较短（百级）。此时方案A的带宽压力和显存竞争并不突出，传统架构的成熟生态和较低改造成本更具优势，不建议盲目引入新型引擎。
• 场景二：序列长度向万级增长、Dense参数向百亿级扩展。此时方案B能有效缓解带宽瓶颈，通过分级存储释放HBM空间，支撑更大规模模型。尤其在多模型并行迭代频繁的业务中，公共特征复用与自动调优带来的收益显著。
• 场景三：团队运维人力有限、训练系统需托管化运行。方案B的自动调优和动态资源调度能降低变更风险，适合追求稳定性和低成本运维的团队。

七、选型建议

没有绝对最优的架构，只有与业务规模、技术储备和运维能力最匹配的方案。条件化判断如下：

• 如果当前模型规模并未触及带宽和显存瓶颈，优先沿用方案A，保持技术栈稳定。
• 如果模型序列长度和参数规模持续增长，且多模型并行成为常态，应评估方案B的资源协同与多级存储能力。
• 如果团队具备较强的系统研发能力，可考虑基于方案B的思想做渐进式改造，例如先引入主机内存作为二级缓存，再逐步完善动态调度逻辑。
• 如果业务追求快速迭代、减少人工调参成本，方案B中的自动调优机制更具吸引力。

八、迁移与使用注意事项

从方案A向方案B迁移，需要关注以下风险：

1. 数据一致性：多级缓存引入了数据副本，需要设计缓存失效和回写机制，避免训练过程中出现参数过期。
2. 通信调度复杂度：动态链路调度需要在运行时监控各节点带宽和延迟，调度策略不当可能反噬性能。
3. 兼容性：原有特征处理流程和并行策略是否需要重构，公共特征抽取平台的接入成本需要提前评估。
4. 稳定性回退机制：新型引擎在极端负载或异常情况下，能否平滑降级为传统模式，需要预案。
5. 监控体系完善：多级存储意味着需要监控更多层级的命中率、访问延迟和数据迁移量，原有监控面板需要扩展。

九、总结

搜广推模型的规模化训练正从“容量扩展”转向“效率扩展”。传统远端 PS 架构通过解耦存储与计算获得灵活性，但在万级序列和百亿 Dense 参数面前，带宽与 HBM 的博弈成为核心矛盾。以资源协同和 HBM-Friendly 多级存储为核心的新型引擎方案，通过重构资源分工、优化参数供给路径和动态管理显存，为模型持续扩展提供了更可持续的路径。

技术选型时应回归业务本质：当模型规模和迭代频率未触及原架构瓶颈时，不必为迁移而迁移；当瓶颈明确出现时，新型引擎的收益则体现在更低的带宽压力、更高的显存利用率和更少的调优成本。最终决策应基于实际数据指标、团队工程能力和业务增长预期做出综合判断。