企业为何要把200多个应用的请求，集中到一个自托管模型上？

导语

企业部署大语言模型时，难点往往不只是选择一个更强的基础模型。随着不同应用陆续接入、新模型不断上线，旧模型又难以立即下线，有限的GPU资源会被分散到越来越多的服务实例中。本文介绍的一项实践，选择了另一条路线：把200多个内部应用的请求集中到一个自托管模型上，再用真实生产错误推动后训练，使模型覆盖企业请求组合，而不是只追逐通用榜单分数。

核心做法

• 从生产错误定义目标。 团队将主要缺口归纳为指令遵循、函数调用和内部任务分布三个方向，并建立与生产流量分层对应的离线评测集。
• 为不同能力分别训练专家。 研究没有把所有奖励放进一个联合目标，而是针对三个轴分别训练GRPO专家。这样做是为了避免不同任务之间的奖励干扰：一个方向的提升，可能会损害另一个方向的行为。
• 识别各自的“投机路径”。 指令遵循专家可能出现语义坍缩，函数调用专家可能过度调用工具，内部任务专家则可能通过冗长输出迎合评分。团队据此为每类失败设计不同修正，而不是用同一套奖励规则处理所有问题。
• 通过SLERP合并模型。 三个专家并非简单平均，而是采用两阶段SLERP进行参数插值与合并，最终形成一个面向混合请求的统一模型。
• 采用多种评测机制。 可验证的任务由确定性验证器评分，较难自动判定的任务则使用经过校准的LLM评审器，同时观察内部Arena、指令遵循和函数调用等指标。

结果与解读

在非推理模式下，合并后的模型在内部Arena取得69.6分，高于一个总参数量约大七倍的基线模型的65.8分；指令遵循得分为0.85对0.83，函数调用得分为0.79对0.77。材料还称，模型改善了通用对话基准，并已承载平台50%的流量，即每月约1.16亿次请求。

这些结果的关键不在于证明“小模型普遍胜过大模型”，而在于说明生产分布本身可以成为后训练的重要监督信号。对于企业而言，一个针对内部请求组合优化的模型，可能比多个面向不同应用的模型更容易部署、监控和扩容，也能减少GPU池被版本切碎的情况。更重要的是，模型能力建设被连接到服务成本：质量提升不再只体现在榜单上，而是直接对应更高的流量承载比例。

仍需关注的问题

这一方案也有明显边界。企业请求分布会持续变化，静态离线集可能很快落后于新工具、新提示词和新失败模式。因此，真正重要的不只是某个时间点的覆盖率，还包括评测集和后训练循环跟上流量漂移的速度。此外，LLM评审器可能把“像评审标准”误当成“真正有用”，尤其是在优化数据与评测数据高度相关时。若要判断结果能否长期成立，还需要持续报告人工评审一致性、困难样本表现以及模型覆盖率随时间的变化。

总体来看，这项工作提供了一个更贴近生产的模型整合范式：先从请求和错误中拆解目标，再分轴训练，最后合并为统一服务。它把后训练从一次性模型升级，转变为围绕企业流量持续维护的工程流程。

来源：Hugging Face Daily Papers