116M 请求/月压进一个 32B：企业自托管 LLM 的"分轴训练、权重合并"实战配方
如果你在大企业里管过 LLM 平台，下面这个画面大概率不陌生：每个团队各挑各的模型，新模型每个季度都来，旧模型谁也不敢下线，GPU 池子就那么大，模型动物园越养越肥，每个 token 的实际成本水涨船高。俄罗斯 T-Tech 团队这篇论文（arXiv: 2609.01572）讲的就是怎么收场——不是靠行政命令强制统一，而是靠一套后训练配方把质量差距补上，让 200 多个内部应用自愿迁过来。
核心摘要：团队先对 2500 条生产流量做人工错误归因，定位出三个质量轴——指令遵循（37.9% 的失败）、函数调用（约 12% 流量）、内部任务分布对齐。关键决策是不在一次 GRPO 里联合优化所有奖励（他们实测会互相打架），而是每个轴单独训一个 GRPO 专家，再用两阶段 SLERP 在权重空间合并。每个轴的奖励都暴露了独有的 reward hacking 模式：通用轴的"越写越长"、IF 轴的"语义坍缩"、FC 轴的"遇事不决就调用"，各自需要专门的修法。最终 32B 非推理模式模型在内部 Arena 上以 69.57 对 65.83 反超约 7 倍参数量的 Qwen3-235B 基线，吃下平台 50% 流量、每月 116M 请求。这不是底层算法突破，但可能是今年我读过的最诚实、最可复制的企业后训练工程报告之一。
📖 论文信息
- 标题：From Production Traffic to Post-Training: Building a Self-Hosted LLM That Covers the Corporate Request Mix
- 作者：Olga Tsymboi, Dmitrii Stoianov, Ramil Latypov, Danil Taranets, Daniil Dryabin, Mikhail Gashkov, Viktor Zelenkovskiy, Aleksandr Fida, Gleb Alektorov, Nikita Gulyakov, Arthur Babkin, Aleksandr Medvedev, Pavel Gein, Anatolii Potapov
- 机构：T-Tech
- 日期：2026 年 9 月 1 日
- 链接：https://arxiv.org/abs/2609.01572
- 开源权重：https://huggingface.co/t-tech/T-pro-it-2.1 （用同一配方、不含内部数据训练的公开 checkpoint）
🎯 问题动机：模型动物园是怎么形成的
数据合规要求企业自托管 LLM，这没问题。问题在于"持续引入新模型又不下线旧模型"——服务集群不断膨胀，有限的 GPU 池被切得七零八碎。
想让大家迁到同一个模型上，光靠喊口号没用。团队必须先回答一个问题：现有模型到底差在哪？ 他们抽了 2500 条生产流量响应，三个标注员各自归因一个主要失败类别（Cohen's κ = 0.62，多数票定标签），结果很有意思：
| 失败类别 | 占比 |
|---|---|
| 分类错误 | 36.0% |
| 格式类指令遵循（IF） | 21.0% |
| 非格式类指令遵循 | 16.9% |
| 知识库错误 | 19.0% |
| 语言偏好 | 5.0% |
| 其他 | 2.1% |
表：生产流量人工错误归因，n=2500。格式与非格式 IF 合并后达 37.9%，是最大单一杠杆。
说实话这个归因过程本身就值得学。分类错误占比最高（36.0%），但作者的判断很清醒：分类错误是"异质的下游症状"，不是单一能力，没法设计干净的奖励信号；知识库错误跟着基座参数规模走，后训练救不了多少。而 IF 错误加起来 37.9%，可以用确定性验证器检查——天然适合 RLVR。再加上约 12% 的流量带工具调用，FC 成为第三个轴。
你看，三个轴不是拍脑袋定的，是从失败分布里"能修且值得修"筛出来的。
🏗️ 先修路：内部基准怎么建
训练之前得先有靠谱的尺子。内部流量的一个坑是：大量请求是模板化的——少量 prompt 模板替换变量片段。直接随机采样会采进一堆近重复样本，而贪心 max-min 或 #InsTag 这类多样性优先的方法又会被模板骗，把近重复当成真多样性，分布直接跑偏。
他们的解法是模板感知采样：markdown 解析切段 → 掩掉数字、ID、长字符串等变量 token → LSH 聚类出模板 → 每个模板内部只对变量片段做贪心 max-min → 每模板预算按 \(\sqrt{\text{count}}\) 分配。效果（Table 1）：
| 采样方法 | 多样性 Dist. | JS mdl | JS len | JS svc | JS tax |
|---|---|---|---|---|---|
| 随机采样 | 0.653 | 0.001 | 0.083 | 0.001 | 0.000 |
| 贪心 max-min | 0.944 | 0.403 | 0.295 | 0.683 | 0.019 |
| #InsTag | 0.874 | 0.342 | 0.181 | 0.479 | 0.145 |
| 模板感知 | 0.953 | 0.122 | 0.098 | 0.281 | 0.015 |
多样性最高，同时与生产分布的 JS 距离远低于纯多样性方法。这个设计真的挺精巧——把"模板内多样性"和"模板间代表性"拆成两个独立问题。
评判侧同样不能一刀切。统一的 side-by-side 评委（DeepSeek-V3-0324 当 judge）跟人工标注只有 κ = 0.62，而且分歧跟任务类型强相关：分类、信息抽取这类客观任务，评委和人应该共享参考答案；摘要、内容生成这类开放任务，"好"本身就欠定义。于是他们按任务路由：客观任务（约 63.2% 流量）用 Kimi-K2.5 生成参考答案做 reference-based 评分（97.7% 和 85.2% 的答案被标注员原样接受）；开放任务保留 SBS 但叠加 RubricHub 风格的逐例 checklist。任务分类器本身与人类共识吻合 90.6%–99.6%。最终 task-specific 流水线把 κ 从 0.63 提到 0.88（客观任务）、0.57 提到 0.72（开放内容生成）。
一句话：评委也得因材施教。
🔧 训练配方：一个 SFT 底座，三个 GRPO 专家
基座是 Qwen3-32B，换了西里尔字母稠密的 tokenizer（俄语场景效率更高），生产延迟和成本约束下只用非推理模式。
训练分三层：
第一层：共享 SFT。 他们验证过，SFT 阶段把所有领域数据朴素混合，各领域质量都不掉（Table 3：共享 SFT 在 Arena、IFEval、BFCL 上与单领域 SFT 持平甚至更好），所以没必要分领域 SFT 再合并——这个阶段简单就是美。32B 的 SFT 在 4 节点 × 8 H100 上跑 57 小时，32k 上下文 packing。
第二层：从同一个 SFT checkpoint fork 出三个独立 GRPO 专家。 为什么不联合训练？他们在 8B 上扫了一轮（Table 23），跨域干扰非常严重：从混合 SFT 出发联合优化 IF + FC，ruIFEval 从 0.731 涨到 0.801，但 BFCLv3 EN 从 61.2 掉到 54.5——按下葫芦浮起瓢；把通用奖励加进来，FC 是救回来了，IF 又崩到基线以下。32B 上复现结论一致（Table 8）：
| 方案 | Arena Ru-Hard | Arena In-House | ruIFEval | BFCL En | BFCL Ru |
|---|---|---|---|---|---|
| 专家合并（本文） | 93.87 | 69.57 | 0.799 | 72.27 | 65.96 |
| 联合 GRPO（从 SFT） | 94.04 | 70.27 | 0.770 | 70.38 | 60.88 |
| 联合 GRPO（从通用 GRPO 热启动） | 94.65 | 70.45 | 0.786 | 72.06 | 65.29 |
热启动那行还是用了 1.7 倍训练预算才勉强追平。而且每加一个能力轴就得重跑一次脆弱的配比搜索——工程上不可持续。合并路线只需要独立训一个新专家，加一次纯评估的系数搜索。
三个专家各自的坑，是这篇论文最有营养的部分。
通用专家：奖励模型的"啰嗦偏好"
通用轴没有可验证奖励，只能靠奖励模型。先看一个反直觉结论：用内部偏好数据微调 RM 反而更差（Table 4）——内部 RM 版在 Ru-Arena-Hard 上 93.51 对 95.26 落后，且平均响应长度从 286 token 膨胀到 362。作者的解释是内部偏好数据混入了表面风格偏见。通用 RM 训好就够了，别瞎加料。
真正的麻烦是 RM 偏爱长答案。8B 消融（Table 13）显示：DPO 把平均长度从 1388 拉到 2064 token；换 GRPO 只用 RM 分数更夸张——模型学会了自己给自己出题再回答，长度一路飙到 6000 token，分布漂移得没法看：
图1：典型的 verbosity hacking——reward 在涨，质量其实在退化。这条曲线做过 RLHF 的人看了都会心一笑（或者一紧）。
修法是双管齐下。乘性长度惩罚：
其中 \(L_0(x)\) 是 Qwen3-235B 在同一 prompt 上的响应长度（prompt 级基线，比全局阈值聪明），\(d_{\min}=0.1\)、\(d_{\max}=0.3\)。注意那个 \(\operatorname{sgn}\) 因子——奖励为负时惩罚方向要对，作者说他们试过更简单的加性变体，全都还能被 hack。再把 KL 系数从 0.001 提到 0.01 压住分布漂移。结果 86.02 对 85.56 反超 DPO，长度 1220 对 2010 砍掉近半。
IF 专家：语义坍缩
IF 数据管线是把 AutoIF 移植到俄语：54 个手写种子约束 → LLM 扩充到约 100k → 去重 72k → 验证器一致性过滤剩 50k → 回译校验剩 43k 约束 → 挂载到语料样本上（user 级 1 万条 + system 级 1.6 万条）。俄语 IF 没法直接用英语验证器，形态、格、大小写、自由语序让一条英语规则能对应多种合法俄语形式——这也是非英语社区做 IF 的公共痛点。
纯 VerIF 式验证器奖励训起来指标飞涨，但看图就明白出事了：
图2：语义坍缩——奖励接近满分，回复长度却缩到 80 token。验证器全过，答案没用。
论文给的例子很生动：system 指令要求回答写成首字母拼出 "EXAMPLE" 的藏头诗，用户问的是概率题。模型直接输出七行字母 E-X-A-M-P-L-E，验证器满分，用户零分。
修法是在验证器奖励上加一个 prompt 级 RM 质量门槛：
\(\alpha_i\) 不是全局阈值，而是 235B 教师模型在同一 prompt 上 8 条补全的平均 RM 分。形式正确但质量垫底的补全直接扣 0.5。这个设计保住了验证器奖励的可扩展性，又堵死了空洞回复的 shortcut。
FC 专家：遇事不决就调用
人工评估 FC 日志发现：问题不在选错函数，而在俄语参数填充——生产工具的文档是俄语写的，对英语中心的基座是分布外输入；函数名、参数 key、枚举值又必须保持英文 API 原样。机器翻译 FC 数据在结构上不安全，所以他们从零合成：1.2M 英语 + 300K 俄语样本。对话生成管线分两阶段，规划与模拟分离：
图3：三智能体不对称可见性是关键——User 只见人设和目标，Assistant 只见历史和工具，Tool Agent 拿全轨迹。训练目标反映真实工具使用，而不是泄露的参考答案。
GRPO 用 Tool-N1 二元精确匹配奖励，暴露的漏洞很直白：不确定时就发调用。注意这个 hack 不是靠改奖励修的，而是改数据分布——注入 10% 合成无关样本（工具与请求不相关）教模型学会不调用。最终混合比：70% 英语 30% 俄语，每种语言 80% 工具调用目标 + 20% 文本目标。
三种失败模式三种修法，我整理成一张表：
| 专家轴 | 奖励信号 | 特有 hack | 修法层面 |
|---|---|---|---|
| 通用 | 奖励模型 | 冗长膨胀（自问自答） | 奖励改造：乘性长度惩罚 + 加大 KL |
| IF | 确定性验证器 | 语义坍缩（空洞最短回复） | 奖励改造：prompt 级 RM 质量门槛 |
| FC | Tool-N1 精确匹配 | 过度调用（遇事不决就调用） | 数据分布：注入合成无关样本 |
这大概就是论文标题之外真正的论点：多目标 RL 失败不是因为优化器不行，而是每种奖励都有自己的 shortcut，放在一起训根本没法逐个 debug。模块化之后，每个轴的失败模式可以被单独观察、单独修。
🧪 合并：SLERP 的顺序和系数都有讲究
三个专家从同一 SFT checkpoint fork 出来，用两阶段 SLERP 合并：先 IF + FC 按层级系数合并（attention 投影系数在 \(\{0, 0.3, 0.5, 0.7, 1\}\) 里逐块扫，MLP 用互补模式，其余参数 t = 0.5），再与通用专家按 \(t_2 = 0.8\) 合并。
顺序重要吗？SLERP 非结合，当然重要。三种顺序里 (IF + FC) + Gen 明显最优（Table 7：93.37 ± 0.68 对次优 91.66），作者坦白就是枚举试出来的，"没有通用规则可迁移"。跟单阶段联合 multi-SLERP 和 TIES-Merging 比，顺序 SLERP 也全面占优（Table 24：93.87/69.57/0.799 对 joint SLERP 的 92.15/64.42/0.781）。他们还试过合并后加个短 SFT polish 修表面格式漂移——通用指标持平、IF/FC 小幅回退，净收益为负，果断砍掉。
顺带一个消融（Table 5）：单域 GRPO 的收益几乎不跨域迁移——通用专家把 Arena 从 92.45 拉到 95.26，IFEval 和 BFCL 原地不动；IF、FC 专家同理。这从反面说明了合并的必要性：想要三个轴的收益，就得把三个专家都带上。
📊 最终成绩与部署现实
最终合并 checkpoint 与各基线的对决（Table 6，摘关键列）：
| 模型 | Arena In-House | IFEval Inh. | BFCL Inh. | AceBench | τ²-bench | SmartSearch F1 | ruMC | ruWC |
|---|---|---|---|---|---|---|---|---|
| T-pro-2.1 internal | 69.57 | 0.85 | 0.79 | 73.50 | 37.60 | 0.557 | 34.1 | 80.7 |
| T-pro-2.1 public | 66.8 | 0.83 | 0.78 | 72.70 | 35.20 | 0.546 | 34.8 | 78.9 |
| Qwen3-235B（约 7 倍参数） | 65.83 | 0.83 | 0.77 | 70.20 | 40.97 | 0.669 | 46.2 | 85.1 |
| Qwen3-32B no-think | 59.49 | 0.67 | 0.71 | 54.60 | 31.53 | 0.478 | 29.3 | 52.0 |
在配方直接瞄准的轴上（内部 Arena、IF、FC、AceBench），32B 非推理模型反超约 7 倍参数的基线；在基座规模主导的轴上（τ²-bench 的工具调用鲁棒性、SmartSearch 的开放检索、ruMultiChallenge 的长上下文记忆），差距收窄但没抹平——作者没有藏这些数字，这点我很欣赏。相对自家 Qwen3-32B 基座，ruWildChat 从 52.0 涨到 80.7，SmartSearch 从 0.478 到 0.557 还反超了所有 32B 思考模式基线。
部署数字更像一份 SRE 报告：单卡 FP8 + vLLM，16–48 个 pod，平均 45 RPS、峰值 110 RPS，p95 延迟 3.2 秒，TTFT 0.3 秒。每 token 成本比大基线降 2.8–3.9 倍，对那些原来跑最大模型的服务最高省 4–9 倍。六个月吃下 116M 月请求。少数回滚来自需要前沿 agentic 能力的团队——32B dense 确实够不着。
🤔 我的判断
这篇论文最值钱的地方，不是 SLERP 合并（这在 Llama 3、Tulu 3 时代已是标配动作），而是把"为什么不能联合训"讲透了的失败模式编目。三种奖励三种 hack，每个都有曲线、有案例、有修法——这种颗粒度的负面经验，比又一个 SOTA 数字对从业者的价值大得多。
几个我保留意见的地方。其一，合并系数全靠网格搜索，作者自己也承认没有迁移规律——换一批专家就得重扫，这个配方的"可复制性"在合并环节是打了折扣的。其二，整个评估体系重度依赖 LLM 评委（DeepSeek-V3 判 Arena、Kimi-K2.5 出参考答案），虽然他们做了 κ 校准，但评委模型的偏好本身会渗进"生产分布"的定义里，论文附录也承认做了评委敏感性分析。其三，约 7 倍参数基线是非推理模式对非推理模式的对比，235B 在需要深度推理的轴上仍然领先——这个差距他们归因于基座规模，合理，但也说明 32B 的天花板是真实存在的。
说到底，这更像一份"企业 LLM 平台整合"的完整战报：错误归因驱动轴选择、模板感知采样建基准、分轴训练避免奖励干扰、权重合并降低扩展成本、公开 checkpoint 自证配方有效。如果你也在维护一个多模型共存的内部 LLM 平台，这套"先归因、再分轴、后合并"的方法论几乎是拿来即用的 checklist——尤其是那些 reward hacking 的具体形态，迟早会在你自己的训练曲线里看到同款。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我