A small specialist drew level with the strongest model in service

<p><strong>You don't have to fight the giants head-on — narrow to one task and sharpen it, and a far smaller model can draw level. It just isn't free</strong></p> <p>A model about a third the size (8B) <strong>drew level</strong> with the strongest class currently in service (27B). But only after narrowing to a single task — Live subtitles. 90 → 96, tied with its own teacher.</p> <p>That draw came with a price tag. The price of taking Live up +6 was <strong>Page and Manga each breaking by −4</strong>. Specialization isn't a free lunch; it's <strong>a choice about allocation</strong>.</p> <p>Which means the question to settle first isn't "should I specialize" but "which mode is the main battleground, and what do I do with the others." The ways out — remixing the data, per-mode routing, scaling capacity — each cost something different in shape.</p> <p>There's an unspoken pecking order in the world of machine translation. The more parameters, the smarter. So if you want the best quality, use the biggest model.</p> <p>The teacher model LYR runs in production is a general-purpose model with 27 billion parameters (27B) — one of the strongest currently in service. The specialist model LYR raises in-house has about a third of that: 8 billion parameters (8B).</p> <p>How far could I push that 8B on <strong>Live subtitles</strong> — the job of translating the one-line-at-a-time captions running along the bottom of a video, in real time? That's what this article is about. The short version: the 8B <strong>drew level</strong> with the 27B. But that draw came with <strong>a price tag</strong>.</p> <h2> The assumption — "a small model can't beat a big one" </h2> <p>Here's where it started. I measured the rate at which Live subtitle translations actually pass as usable (overall = the share where meaning and naturalness are good enough for real use), side by side across models.</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Model</th> <th>Live</th> <th>Page</th> <th>Manga</th> </tr> </thead> <tbody> <tr> <td>8B (sharpened for general use)</td> <td>90</td> <td>93</td> <td>92</td> </tr> <tr> <td>27B (in service, the teacher)</td> <td><strong>96</strong></td> <td>98</td> <td>99</td> </tr> <tr> <td>Scout (the predecessor)</td> <td>97</td> <td>86</td> <td>90</td> </tr> </tbody> </table></div> <p>On Live, the 8B was at 90. The 27B at 96. <strong>A 6-point gap.</strong></p> <p>Read plainly, that looks like a difference in capacity. The 8B's capacity is too small to handle Live's hard cases — idioms, picking the wrong subject. If that's true, there's only one move: make the model bigger. It's a tempting conclusion.</p> <p>But is that 6 points really "the capacity wall"? Or is it a question of <strong>how it was sharpened</strong>? Running to a bigger model without checking is sprinting in the most expensive direction available. So first I looked at what the failures actually were.</p> <h2> Measured — the gap wasn't capacity </h2> <p>Opening up the Live items the 8B was failing on, one by one, the culprits came in three kinds. Literal translation of idioms (rendering "isn't like you" word for word), picking the wrong subject, and word hallucination (adding words that were never in the source).</p> <p>Of those, idioms and subjects are <strong>not a question of capacity</strong>. They're the kind of mistake that goes away if you show the model enough correct model answers. So maybe what the 8B lacked wasn't capacity but <strong>high-quality model answers specialized for the Live job</strong>.</p> <p>So I sharpened it in two stages.</p> <p><strong>Stage one: make the model answers better.</strong> Have the 27B teacher translate the same sentence N different ways, then pick the single best among them with quality estimation (QE = automatically scoring a translation by looking at the translation alone). The translations picked out by this "best-of-N QE" become the 8B's model answers (→ <a href="https://lyr