LinkedIn 公布多教师蒸馏训练基础设施，职位搜索排序模型提速 8 倍

LinkedIn 公布的并不是一项新的蒸馏算法，而是一套让蒸馏“跑得够快”的训练基础设施。按来源描述，训练一个小语言模型来改善点击和申请等相关性与互动目标，需要针对每个训练样本查询一个或多个大型教师模型；而为这些教师模型提供服务可能拖慢整个过程。对于每秒必须处理数十万次查询的排序系统，这会成为瓶颈。

这正是 LinkedIn 取舍的起点：蒸馏本身可行，但教师模型的服务开销会限制迭代速度。LinkedIn 的贡献被描述为创建了一个定制 SGLang 框架，使教师模型能够在训练期间接受实时查询。

LinkedIn 使用 SGLang 创建了一个多教师蒸馏框架，可以加载并服务不同规模的教师模型，同时管理张量并行与数据并行配置。训练期间，异步客户端向教师模型发送请求、处理其输出，并把结果加入蒸馏损失，团队称之为在线多教师蒸馏。

为压低延迟，系统在多个节点上部署本地教师模型副本。来源称这一做法把蒸馏过程提速 3 倍，同时保持较低延迟以支持快速迭代。需要说明的是，这一 3 倍数字来自 LinkedIn 团队自身的表述，缺少独立第三方验证。

在线模式灵活，但服务开销始终存在。为减少开销并避免重复计算，LinkedIn 引入离线多教师蒸馏：预先计算教师模型的输出，存储在 HDFS 或 NFS 上，训练时直接使用这些结果，而不再实时查询教师模型。

来源给出的切换逻辑是：在教师模型选择仍然频繁变化的早期阶段适合在线查询；当教师模型趋于稳定且查询量增加后，再切换至离线缓存。但文章并未说明两种模式在生产中的具体切换阈值或判定标准。

围绕这套在线与离线结合的方案，LinkedIn 还叠加了多项训练层优化。来源列出的包括：采用 LiGer 降低内存使用量，并把批次大小扩大至原来的 2 倍；通过多节点训练进一步实现最高 3.5 倍加速；使用 FSDP2 再获得 20% 的性能提升；采用 H200 多节点集群，在此基础上额外提升最高 30%。

来源称正是这些优化叠加在一起，带来了文章标题中提到的约 8 倍训练速度提升。这里需要标注不确定性：约 8 倍是多项优化叠加的结果，各单项贡献的精确拆分并未给出，且上述加速数据均来自 LinkedIn 自身研究或团队表述。

团队指出，他们曾评估 FP8 混合精度，但发现它对参数量低于 80 亿的模型没有帮助，因为类型转换开销超过了计算方面的节省。

来源进一步把这一点提炼为对团队的提示：对于参数量低于 80 亿的模型，上述优化都不需要使用 FP8。对于考虑默认采用较低精度的团队而言，这一细节值得注意。

在模型层面，这个 6 亿参数学生模型的知识来自一个 80 亿参数的相关性预言模型和一个 17 亿参数的互动教师模型。来源称 LinkedIn 的研究显示，该学生模型改善了职位搜索结果，将职位搜索的 NDCG@10 提升了 24.48%，从 0.7583 提高至 0.9432。

同一项研究还在推理侧采用结构化剪枝和上下文压缩，将每块 GPU 的排序吞吐量从每秒约 290 个条目提高到 2000 多个。这些数字同样来自 LinkedIn 自身研究，缺少独立第三方验证；6 亿参数学生模型与 80 亿、17 亿教师模型的对比基线细节也未在文中完整披露。

该系统已经投入生产，为 LinkedIn 美国用户的自然语言职位搜索提供支持。它基于开源大语言模型服务引擎 SGLang 构建，LinkedIn 此前已在排序工作负载中对其进行投入，而没有使用专有服务技术栈。

来源把这项工作定位为给团队的一份指南：帮助其在满足实时延迟要求的同时，实现接近交叉编码器质量的排序，而无须为每个请求调用前沿大语言模型进行推理，从而避免高昂成本。需要保留的边界是：该系统在美国以外地区的部署情况未提及；来源中作为背景对比的 Pinterest 文章与前沿模型蒸馏调查，其数据与 LinkedIn 方案的可比性也不明确。