Три оси масштабирования LLM: данные, параметры, вывод

С 2020 по 2025 год публичная литература по большим языковым моделям сместила акцент с простого вопроса «сколько параметров?» к трем связанным рычагам: сколько и каких данных дать модели, какой объём параметров ей выделить и сколько вычислений разрешить уже во время ответа. Линия от Scaling Laws for Neural Language Models к Training Compute-Optimal Large Language Models, затем к Learning to reason with LLMs и работам о test-time compute показывает: качество растёт не только от роста числа весов. Для практиков это важно потому, что эти рычаги по-разному влияют на стоимость обучения, память, латентность и характер ошибок.

Коротко

Ранние scaling laws описывали качество как функцию параметров, данных и тренировочных вычислений; если один ресурс становится узким местом, отдача от остальных падает.
Работа Chinchilla сместила фокус с «максимально большой модели» к более сбалансированному распределению бюджета между параметрами и токенами.
Ось данных сегодня означает не только объём, но и смесь доменов, дедупликацию, фильтрацию и контроль загрязнения бенчмарков.
Вычисления во время вывода стали отдельным рычагом: дополнительные сэмплы, голосование, ревизии и верификаторы могут повышать качество без нового цикла pretraining.
Но более длинное рассуждение не гарантирует лучший ответ: оно повышает цену запроса и в некоторых режимах может усиливать отвлекаемость или ложные паттерны.

Контекст

В Scaling Laws for Neural Language Models Kaplan et al. предложили важную рамку: качество языковой модели меняется предсказуемо при масштабировании числа параметров, размера датасета и бюджета вычислений на обучение. Для индустрии это было удобно: если у вас есть больше вычислений, можно ожидать систематического прироста, а не случайного поведения.

Но эта ранняя картина легко уводила к слишком простой эвристике: «лучше всего просто наращивать модель». В Training Compute-Optimal Large Language Models Hoffmann et al. показали, что при фиксированном тренировочном бюджете многие крупные модели были недообучены на слишком малом числе токенов. Официальный разбор Google DeepMind по той же работе прямо формулирует практический вывод: дело не только в размере модели, но и в том, как распределён бюджет между весами и данными.

После этого разговор о масштабировании стал более прикладным. Для команды, которая строит или дообучает модель, ось «вычисления на обучение» обычно выступает не как отдельная настройка продукта, а как общий бюджет, который нужно разложить между параметрами и данными. А начиная с reasoning-моделей 2024–2025 годов к этой картине добавилась ещё одна управляемая ось: сколько вычислений тратить уже на конкретный ответ.

Метод: как устроены три оси масштабирования

1. Данные: не только количество, но и состав

Данные — это самый буквальный источник знаний и статистических закономерностей. В ранней литературе ось данных часто выглядела как рост числа токенов. Однако более поздние работы уточняют, что для практики этого определения мало. Data Mixing Laws показывает, что пропорции разных доменов в pretraining-корпусе сами по себе предсказуемо влияют на итоговое качество. DataComp-LM добавляет ещё один слой: фильтрация, дедупликация, извлечение текста из web-страниц и смешивание источников могут заметно менять результат даже без смены архитектуры.

Поэтому «масштабировать данные» — не значит просто добавить ещё web-токенов. На практике это означает управлять распределением доменов, устранять повторы, убирать мусор, следить за contamination и понимать, какие данные действительно помогают целевым задачам.

2. Параметры: ёмкость и память в весах

Параметры — это ёмкость модели, её способность хранить и сжимать закономерности из обучения. В упрощённой аналогии данные — это то, что модель читает, а параметры — сколько она может удержать в «памяти весов». Работа Kaplan et al. полезна тем, что отделяет влияние параметров от влияния данных и показывает: сами по себе большие модели действительно помогают, если они не упираются в нехватку токенов или вычислений.

Но Chinchilla-логика добавляет важную оговорку: слишком большая модель при фиксированном бюджете может оказаться менее выгодной, чем меньшая, но обученная на большем числе токенов. Показательный пример из статьи Hoffmann et al. и официального блога DeepMind — Chinchilla на 70B параметров при том же тренировочном бюджете, что и Gopher на 280B. Главный смысл не в конкретном названии модели, а в том, что ось параметров нельзя оптимизировать изолированно от оси данных.

3. Вычисления вывода: сколько модель «думает» в момент ответа

Третья ось появилась в явном виде позже. В материалах OpenAI о серии o1 — research post и system card — reasoning-модель описывается как система, чья производительность растёт не только от дополнительного RL на обучении, но и от дополнительного времени на обдумывание на инференсе. Это и есть test-time compute или inference-time compute.

Тратить дополнительные вычисления во время ответа можно по-разному. Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters разбивает этот бюджет как минимум на два типа: параллельный поиск по нескольким кандидатам и последовательные ревизии, где модель перепроверяет и улучшает своё решение. s1: Simple test-time scaling показывает более простой открытый путь: управлять длиной и настойчивостью рассуждения даже без закрытой инфраструктуры фронтирной лаборатории.

Это делает ось вычислений вывода особенной. Параметры и данные в основном фиксируются до деплоя. А reasoning-budget можно менять на уровне запроса: дешёвый короткий ответ для простой задачи и более дорогой режим для сложной.

Результаты: что показали работы 2020–2025

Ось	Что подтверждают источники	Практический смысл
Данные	Kaplan et al. показывают, что рост датасета улучшает качество, пока модель не упирается в другие ограничения; Data Mixing Laws и DataComp-LM уточняют, что важны не только токены, но и их смесь, очистка и дедупликация.	Плохой или нерелевантный корпус нельзя надёжно компенсировать ни дополнительными параметрами, ни более длинным reasoning на инференсе.
Параметры	Kaplan et al. фиксируют устойчивую пользу от роста модели; Hoffmann et al. и DeepMind показывают, что при фиксированном бюджете можно переразмерить модель и всё равно проиграть более сбалансированной конфигурации.	Размер модели важен, но «максимально большая» не равна «максимально полезная».
Вычисления вывода	OpenAI, Snell et al. и s1 показывают, что дополнительные сэмплы, голосование, ревизии и поиск с верификаторами могут улучшать ответы на сложных задачах.	Это самый доступный рычаг для API-пользователей и команд, которые не могут запускать новый pretraining.

Если свести литературу к одной фразе, то ранняя эпоха LLM учила: «масштабируйте обучение». Период после Chinchilla добавил: «масштабируйте обучение сбалансированно». А reasoning-работы 2024–2025 годов добавили ещё одно уточнение: «часть качества можно докупать уже во время ответа, если задача того стоит».

Важно и то, что test-time compute не сводится к одному трюку. В OpenAI-материалах это видно через более тяжёлые режимы генерации и отбора ответа. У Snell et al. — через сочетание параллельного поиска и последовательных ревизий. У s1 — через простые механизмы управления бюджетом рассуждения. То есть новая ось — это не конкретная модель, а семейство стратегий распределения вычислений на уровне запроса.

Интерпретация

Наш комментарий

Для практиков из этой литературы следует не лозунг «всегда выбирайте reasoning-модель» и не лозунг «всегда берите больше параметров». Более полезная рамка такая: сначала определите, какая именно нехватка ограничивает вашу систему.

Если модель систематически не знает предметную область, первым кандидатом на улучшение остаются данные: доменная дообучка, пересборка смеси, очистка, дедупликация.
Если знаний в целом хватает, но модель не удерживает сложные зависимости, узким местом могут быть параметры или архитектурная ёмкость.
Если базовая модель уже сильная, а проблемы возникают в трудных многосвязных задачах, самым дешёвым следующим шагом часто оказывается не новый backbone, а более умная политика инференса.

На наш взгляд, именно поэтому фронтирные продукты всё чаще выглядят не как одна статическая модель, а как система маршрутизации бюджета. Короткий проход обслуживает простые запросы. Более длинное рассуждение, дополнительные сэмплы или верификация включаются только там, где ожидаемая польза перекрывает рост задержки и цены.

У этой рамки есть и организационное следствие. Команда pretraining думает в терминах параметров и токенов. Команда продукта — в терминах latency, SLA и стоимости одного ответа. Ось test-time compute стала мостом между исследованием и эксплуатацией: теперь часть масштабирования переносится из этапа обучения в runtime-политику.

Ограничения и критика

Во-первых, scaling laws — это эмпирические закономерности, а не физические законы. Они зависят от архитектуры, режима обучения, токенизации, смеси данных и набора evals. Результат, верный для одной семейства моделей, не обязан без изменений переноситься на другое.

Во-вторых, литература по данным и параметрам часто опирается на loss и на стандартные бенчмарки общего назначения. Это полезно для общей картины, но не всегда напрямую отвечает на продуктовый вопрос: что будет именно на вашем домене, языке, формате документов и профиле запросов.

В-третьих, evidence по test-time compute особенно убедителен на задачах, где полезны поиск, перепроверка и последовательное рассуждение: математика, код, некоторые научные и логические задания. Для кратких ответов, извлечения фактов, рутинной классификации или задач со строгими SLA дополнительное reasoning может быть просто дорогой надстройкой без достаточной отдачи.

В-четвёртых, более длинное рассуждение не всегда монотонно улучшает результат. Inverse Scaling in Test-Time Compute показывает режимы, где удлинение reasoning ухудшает точность: модель сильнее отвлекается на нерелевантные детали, подстраивается под ложную рамку задачи или уходит в спurious correlations. Это особенно важно для safety-оценок: нельзя тестировать reasoning-модель только в коротком режиме и считать картину полной.

Наконец, воспроизводимость reasoning-моделей остаётся ограниченной. Закрытые лаборатории не всегда раскрывают полную тренировочную схему, а скрытый chain-of-thought затрудняет независимую проверку того, что именно помогло: дополнительное RL, большее число сэмплов, reranking, верификаторы или комбинация всего сразу.

Итог

Масштабирование LLM больше не стоит понимать как линейную гонку за максимальным числом параметров. По состоянию публичной литературы 2020–2025 годов более точная картина такая: качество определяется балансом между данными, ёмкостью модели и вычислениями во время ответа.

Практический вывод прост: сначала ищите узкое место, а потом масштабируйте именно его. Если не хватает знаний — работайте с данными. Если не хватает ёмкости — смотрите на модель. Если не хватает глубины решения для сложных задач — управляйте бюджетом вывода, но проверяйте, что более длинное reasoning действительно помогает.

Источники

FAQ

Что важнее для качества: больше параметров или больше данных?

Ни один из рычагов не является универсально главным. Ранние scaling laws показывают пользу от роста обоих, а Chinchilla-работа уточняет: при фиксированном бюджете выигрывает не максимальный размер, а более сбалансированная раскладка между параметрами и токенами.

Можно ли компенсировать слабые данные длинным reasoning на инференсе?

Обычно нет. Дополнительные вычисления во время ответа помогают искать, перепроверять и выбирать ответ, но не создают отсутствующее знание и не исправляют систематически плохую смесь pretraining-данных.

Когда test-time compute особенно полезен?

Когда запросы неоднородны по сложности и заметная доля задач требует многошагового рассуждения. Тогда можно держать базовый дешёвый режим и включать более дорогой только для трудных случаев.

Почему более длинное рассуждение иногда ухудшает результат?

Потому что модель может тратить дополнительный бюджет не на полезную проверку, а на следование отвлекающим деталям, ложным формулировкам и спurious patterns. Это показано в работах об inverse scaling для test-time compute.

Три оси масштабирования LLM: данные, параметры и вычисления вывода