企业自建AI，别越用模型越多
企业自建 AI 很容易走进一个循环：每来一类需求，就再部署一个模型。模型越多，GPU 池越碎，评测、路由和维护成本也一起上升。有没有可能先看真实流量，再训练一个覆盖主要请求组合的模型？

【来源事实】9 月 1 日公开的一项企业自建研究，分析了 200 多个内部应用的生产流量，把薄弱点拆成三条轴：指令遵循、函数调用、内部任务分布。团队基于 Qwen3-32B，先做共享 SFT，再分别训练通用、指令遵循、函数调用三个 GRPO 专家，最后用两阶段顺序 SLERP 合并权重。

为什么不直接把所有奖励放进一次 RL？论文观察到跨领域奖励干扰，而且每条轴的“钻空子”方式不同：只用形式验证器，模型会用极短但空洞的回答过规则；函数调用只看精确匹配，模型会过度调用工具；通用任务则会靠冗长回答刷奖励。作者分别加入质量修正、无关工具样本、长度惩罚和更强 KL 约束。

部署结果也很具体：该模型承接平台 50% 流量，月请求约 1.16 亿，覆盖 200 多项服务；单 GPU FP8 副本运行于 vLLM，P95 延迟 3.2 秒。内部 Arena 得分 69.57，高于约 7 倍总参数模型的 65.83；内部函数调用基准为 0.79 对 0.77。

【专家判断】企业做模型整合，值得收藏这 5 个检查项：
1. 基准是否按生产请求占比分层，而非只看公开榜单；
2. 错误是否拆成指令、工具、业务任务三类；
3. 是否逐类记录奖励投机，避免奖励信号互相污染；
4. 合并专家后，是否重跑端到端回归和回滚测试；
5. 迁移门槛是否同时写清覆盖率、P95、单次成本与例外路由。

边界同样重要：数据来自单一机构，只验证俄语、英语和 Qwen3 家族；开放式评测依赖经人工校准的 LLM 评审，内部数据也无法完全公开。部分需要前沿级代理能力的业务还曾回滚。因此这是一套“先读流量、再做专家整合”的工程方法，不是一个 32B 模型替代所有模型的证明；工具调用上线前仍要做权限和参数校验。

一手 大模型部署 模型微调 AI工程