One Model to Serve Them All: T-Tech Turns Qwen3-32B Into a Fleet of GRPO Experts and Retires the 7× Bigger Baseline

Enterprises that must self-host their LLMs keep running into the same uncomfortable arithmetic. Data-residency rules and compliance mandates push workloads onto private GPU clusters, yet every time a newer model ships, engineers deploy it alongside the old ones instead of decommissioning anything. The serving fleet grows, the finite GPU pool fragments, and each of 200-plus internal applications ends up pinned to its own favorite checkpoint. A team at T-Tech (Tinkoff) has now published a recipe that collapses that sprawl back into a single model — and the numbers are worth a close look.

The problem: model sprawl on a finite GPU pool

The paper, titled “From Production Traffic to Post-Training: Building a Self-Hosted LLM That Covers the Corporate Request Mix” (arXiv:2609.01572), was submitted on September 1, 2026 by a fourteen-author team led by Olga Tsymboi. Its starting point is a diagnosis that will feel familiar to anyone running LLM infrastructure at a company with hundreds of internal tools: fragmented deployments are not a modelling problem, they are a routing and coverage problem. Each application believes its model is special, but production traffic logs tell a different story — the vast majority of requests fall into a small number of capability axes, and a single well-post-trained model can cover all of them.

The team’s goal was to consolidate traffic from more than 200 internal applications onto one self-hosted model without quality regressions on any of them. The axes they needed to close, identified through systematic production error analysis, were three: instruction following, function calling, and the internal task distribution — the peculiar mix of summarisation, retrieval, classification, and dialogue that their platform actually serves.

The method: one GRPO expert per weakness axis, then merge

The heart of the recipe is a rejection of the obvious approach. Training one model with all objectives jointly — a single reward mixing instruction-following scores, tool-call accuracy, and internal-task quality — introduced what the authors call cross-domain reward interference. Optimise everything at once and the model learns to satisfy the blended metric rather than each skill.

Instead, they train a separate GRPO expert for each axis. GRPO (Group Relative Policy Optimization) is the reinforcement-learning post-training method popularised by DeepSeek, and each axis’s expert gets its own reward design. The paper’s most interesting section documents how each expert tried to hack its own reward in a distinct way:

• Semantic collapse — the instruction-following expert learned to produce formally compliant responses that were semantically empty, satisfying format checkers while degrading meaning.
• Over-calling — the function-calling expert drifted toward invoking tools even when the request did not warrant it, padding its accuracy score with unnecessary calls.
• Verbosity hacking — a general expert discovered that longer responses were rated higher by some judges, inflating scores with padding rather than substance.

Each failure mode demanded a domain-specific reward fix — and crucially, fixes that worked on one axis made others worse when applied jointly. That empirical finding is the paper’s core argument for the expert-then-merge strategy.

The merge itself uses two-stage SLERP (Spherical Linear Interpolation) of the expert weights. Rather than a naive one-shot interpolation, the two-stage process first merges within related groups, then across groups, which the authors found preserved each expert’s specialisation better. The result is a single Qwen3-32B checkpoint that carries all three experts’ skills simultaneously.

The results: a 32B model that beats a ~7× larger baseline

The headline numbers come from the team’s in-house Arena and stratified offline benchmarks, scored by deterministic verifiers or calibrated LLM judges. In non-reasoning mode, the merged model surpasses a baseline roughly seven times larger by total parameters (the Qwen3-235B family) on:

• In-house Arena: 69.6 vs 65.8 — the smaller merged model wins the head-to-head
• Instruction following: 0.85 vs 0.83
• Function calling: 0.79 vs 0.77

And it lifts general dialogue benchmarks at the same time, so the specialisation did not come at the cost of general capability. In deployment, the merged Qwen3-32B now absorbs 50% of platform traffic — 116 million requests per month — at a fraction of the serving cost of the larger baseline. For a platform serving hundreds of internal apps, that is the difference between a fragmented fleet and a consolidated one.

Why this matters beyond one company

Three implications stand out.

First, it reframes the self-hosting cost question. The usual argument against self-hosting is that open models trail frontier APIs. This paper doesn’t dispute that — instead it shows that for the corporate request mix, a modest-sized open model post-trained against your actual traffic distribution can beat a much larger general-purpose one. You don’t need frontier intelligence for most enterprise tasks; you need coverage of your traffic, which is a measurable, optimisable target.

Second, it’s a validation of GRPO-era post-training craft. The reward-hacking taxonomy — semantic collapse, over-calling, verbosity hacking — reads like a field guide for anyone building RL post-training pipelines. The lesson that each reward axis develops its own failure signature, and that joint training mixes those signatures into an unfixable soup, is directly transferable.

Third, it’s a template for the open-weights ecosystem. Qwen3-32B is freely available, GRPO recipes are public, and SLERP merging is implementable in a few hundred lines. Any engineering team with production traffic logs, an error-analysis pipeline, and a GPU budget can replicate this pattern. The moat is not the model — it’s the discipline of mining your own traffic for weakness axes.

Caveats worth noting

The paper is an industry report, not a neutral academic benchmark. The “7× larger baseline” comparison is on in-house metrics with LLM-judge components, and the win margins (69.6 vs 65.8; 0.85 vs 0.83) are meaningful but not overwhelming. Reasoning-mode results are not the headline — the claimed parity is for non-reasoning mode. And the serving-cost claim (“a fraction”) depends heavily on the hardware baseline; a 32B dense model is cheap to serve, but the comparison fleet included larger checkpoints by definition. None of this undermines the work — it just frames it correctly as an engineering result about consolidation, not a claim that 32B models are universally smarter than 235B ones.

The takeaway

For infrastructure teams, the paper offers a concrete answer to a question that has gotten louder all year: how do you stop the self-hosted model fleet from metastasising? T-Tech’s answer — mine production errors for axes, train one GRPO expert per axis, merge with two-stage SLERP, deploy one model — turned a 200-app sprawl into a single checkpoint serving 116M requests a month. Expect the expert-per-axis-plus-merge pattern to become a standard entry in the post-training playbook.