Test-time compute: почему вычисление во время ответа стало новой осью масштабирования

Test-time compute — это идея тратить дополнительный вычислительный бюджет не на обучение модели, а на момент ответа: дать системе больше попыток, больше шагов рассуждения, внешний проверяющий сигнал или поиск по пространству решений. В 2024 году эта логика перестала быть набором разрозненных трюков и оформилась в отдельную ось масштабирования: это хорошо видно по работам Self-Discover, AlphaGeometry, статье Charlie Snell и соавторов, впервые выложенной на arXiv 6 августа 2024 года, и релизу OpenAI o1 от 12 сентября 2024 года. В этом разборе мы сознательно держим именно историческую рамку 2024 года, а не подменяем ее более поздними обзорами. Для практиков это важно потому, что вопрос смещается с «какую модель взять?» к «как распределить вычисления на один трудный запрос?»

Если упростить, test-time compute отвечает не на вопрос о размере модели, а на вопрос о том, что система делает после первого черновика ответа. Иногда это просто best-of-N, иногда — ревизии, консенсус, верификатор, формальный решатель или поиск по дереву действий. От этой разницы зависит, даст ли дополнительный бюджет рост качества или только рост счета за инференс.

Контекст: что такое test-time compute и почему это новая ось масштабирования

Классическая логика масштабирования больших моделей строилась вокруг трех переменных: параметры, данные и тренировочный compute. Test-time compute добавляет четвертую переменную: вычисление во время ответа. Идея проста: даже если веса модели зафиксированы, качество можно повышать, если разрешить системе не ограничиваться одним жадным проходом, а искать, пересматривать и проверять варианты.

Важно не путать это с банально более длинным ответом. Дополнительные токены сами по себе не гарантируют улучшения. Test-time compute — это управление бюджетом: сколько независимых гипотез породить, когда сделать ревизию, когда подключить проверяющую модель, когда остановиться и какой вариант считать лучшим.

До 2024 года у поля уже были отдельные кирпичики. Self-Refine показал, что одна и та же модель может улучшать собственный черновик через цикл «ответ → обратная связь → переписывание». Let’s Verify Step by Step задал другую линию: качество reasoning можно поднимать, если проверять не только финальный ответ, но и промежуточные шаги. Но именно в 2024 году эти идеи начали рассматривать не как промпт-инженерию, а как системный способ масштабирования.

Отсюда и формулировка «новая ось масштабирования». Она означает не то, что обучение стало неважным, а то, что теперь производительность модели зависит не только от того, что было обучено, но и от того, как устроен сам процесс ответа.

Метод: как работает test-time compute

1. Две базовые ручки: ширина и глубина

На практике почти все техники test-time compute укладываются в две ручки. Первая — ширина: сгенерировать несколько независимых решений и выбрать лучшее. Сюда относятся best-of-N, self-consistency, majority vote и повторные запуски с разными сэмплами. Вторая — глубина: взять один черновик и последовательно улучшать его через ревизии, критику, исправление ошибок и повторную декомпозицию задачи.

Ширина хорошо работает, когда правильное решение уже иногда появляется в распределении модели, но его нужно «добыть» несколькими попытками. Глубина полезна, когда первый черновик содержит исправимые ошибки и модель способна сама увидеть, где рассуждение свернуло не туда.

2. Связка proposer + verifier

Ключевый вклад Snell et al. — удобная абстракция. Авторы предлагают смотреть на систему как на пару генератор (proposer) и проверяющий (verifier). Генератор производит кандидатов или промежуточные шаги; проверяющий оценивает их, сравнивает между собой или направляет поиск. Верификатором может быть process reward model, отдельная judge-модель, majority vote, формальный решатель, компилятор, unit-тесты или символьный движок.

Из этой рамки следует практический вывод: одинаковый бюджет не стоит тратить одинаково на все запросы. Легкая задача может выигрывать от последовательных ревизий. Средняя — от смеси разнообразных сэмплов и проверки. Очень трудная — вообще не улучшаться, потому что базовая модель слишком редко выходит на полезную траекторию. Авторы называют это compute-optimal политикой: распределять бюджет адаптивно, а не по шаблону.

3. Search, tools и формальные проверки

Еще один важный момент: test-time compute — это не только «дольше думать текстом». В AlphaGeometry языковая модель не просто пишет цепочку рассуждения, а подсказывает символьному движку, какие конструкции добавить в доказательство, после чего формальный дедуктивный механизм проверяет и развивает эти шаги. То есть дополнительный бюджет может уходить на внешний поиск, а не только на токены.

Для прикладных систем это особенно важно. В кодинге проверяющим может быть тестовый раннер. В RAG-пайплайне — повторный поиск и reranking. В агентных задачах — среда, которая возвращает наблюдения после действий. Общий принцип один: модель получает право не отвечать с первой попытки.

4. Практическая схема для инженера

1. Оценить сложность запроса или неопределенность первого ответа.
2. Выбрать политику бюджета: больше параллельных сэмплов, больше ревизий или verifier/search.
3. Сгенерировать кандидаты или промежуточные шаги.
4. Сравнить их через judge, unit-тесты, majority vote или формальную проверку.
5. Если бюджет еще не исчерпан, сделать еще один цикл генерации и отбора.
6. Вернуть лучший ответ и зафиксировать цену в токенах, времени и вызовах инструментов.

Эта схема выглядит простой, но именно в ней скрыта вся инженерная сложность: как оценивать трудность, где ставить stop condition, чем проверять кандидатов и как не превратить один пользовательский запрос в дорогое внутреннее дерево поиска.

Результаты: что показали ключевые работы 2024 года

Ниже — не исчерпывающий список, а четыре работы, которые вместе хорошо показывают, что именно называли test-time compute в 2024 году.

Работа	Что добавляется на этапе ответа	Что показано	Практический смысл
Self-Discover	Модель сначала подбирает и композит явную структуру рассуждения, а уже потом декодирует ответ.	По данным статьи и страницы Google DeepMind, метод давал до 32% прироста относительно CoT, превосходил inference-heavy baselines более чем на 20% и требовал в 10–40 раз меньше inference compute.	Не всякий выигрыш требует больше токенов: иногда важнее лучше организовать саму процедуру reasoning.
AlphaGeometry	Нейросеть предлагает полезные конструкции, символьный движок проверяет и продолжает доказательство.	Статья в Nature и блог Google DeepMind сообщают о результате 25 из 30 задач IMO-AG-30 против 10 из 30 у предыдущего метода.	Test-time compute может жить в гибридной системе, где главный выигрыш дает поиск с формальной проверкой, а не просто длинный CoT.
Snell et al.	Адаптивное распределение бюджета между поиском, verifier и ревизиями в зависимости от сложности запроса.	По arXiv-версии и странице ICLR, compute-optimal стратегия улучшала эффективность scaling test-time compute более чем в 4 раза против best-of-N; в FLOPs-matched режиме на части задач меньшая модель обгоняла модель примерно в 14 раз крупнее.	Главный вывод не в одном трюке, а в том, что бюджет нужно распределять по-разному для разных запросов.
OpenAI o1	Обученное длинное reasoning плюс консенсус и reranking при увеличении бюджета на ответ.	В официальных материалах OpenAI для AIME 2024 указано: GPT-4o решал в среднем 12% задач, o1 — 74% с одним сэмплом, 83% при consensus@64 и 93% при reranking 1000 сэмплов.	Закрытые reasoning-модели сделали test-time compute не только исследовательским приемом, но и продуктовой настройкой качества.

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

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

Фактический слой здесь довольно ясен. В 2024 году несколько разных групп — Google DeepMind, OpenAI и академические авторы вокруг Snell et al. — пришли к схожему выводу: качество reasoning можно поднимать не только через более долгую и дорогую предобучку, но и через более умный инференс. Разница между работами — в том, где именно расположен дополнительный compute: в структуре рассуждения, в количестве сэмплов, в ревизиях, в verifier или во внешнем поиске.

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

На наш взгляд, главный сдвиг тут не в том, что модели «начали думать», а в том, что инференс стали проектировать как управляемый вычислительный процесс. Это меняет архитектурный выбор. Вместо схемы «берем одну максимально большую модель и всегда вызываем ее одинаково» появляется другая: базовая модель + роутинг по сложности + адаптивный бюджет + проверка.

Для продакшена это особенно важно по трем причинам. Во-первых, экономически может оказаться выгоднее держать более компактную базовую модель и платить reasoning-бюджетом только за сложные запросы. Во-вторых, появляется пространство для доменных verifier: тесты для кода, калькуляторы для математики, бизнес-правила для аналитики, retrieval-check для RAG. В-третьих, сам ответ становится менее «одиночным выстрелом» и больше похож на pipeline с промежуточными решениями.

Но есть и неприятная сторона. Как только вы добавляете sampling, judge-модель и reranking, вы проектируете уже не просто модельный вызов, а распределенную систему принятия решения. Ее надо измерять по трем осям сразу: точность, задержка и цена. Во многих командах именно это, а не отсутствие сильной модели, становится реальным узким местом.

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

Во-первых, большая часть сильных результатов приходится на задачи с верифицируемым сигналом. Математика, код, формальные доказательства и некоторые научные benchmark’и удобны тем, что там легче сравнить кандидатов. В открытом письме, маркетинговом тексте или продуктовой стратегии автоматически выбрать «лучший» вариант намного труднее.

Во-вторых, test-time compute не равен чистому увеличению числа токенов. На практике успех часто зависит от качества проверяющего сигнала. Слабый verifier может систематически предпочитать правдоподобные, но неверные траектории. Эта проблема особенно неприятна в доменах, где нет формальной проверки.

В-третьих, закрытые reasoning-модели плохо разделяют вклад обучения и вклад инференса. На примере OpenAI o1 видно, что рост качества связан и с посттренировкой, и с тем, что модели дают больше времени на reasoning. Для инженера это означает: нельзя механически перенести цифры закрытой системы на открытый стек и ожидать тот же эффект.

В-четвертых, дополнительный budget не всегда заменяет более сильную базовую модель. Snell et al. прямо показывают, что на самых трудных задачах выигрыш от test-time compute ограничен; при низкой исходной вероятности правильной траектории «искать дольше» почти нечего. Это важный антидот против слишком широкой трактовки «маленькая модель с reasoning всегда догонит большую».

В-пятых, стоимость и задержка могут расти быстрее, чем кажется. Consensus@64 или reranking 1000 сэмплов могут быть полезны в исследовании, но далеко не всегда совместимы с пользовательским latency budget. Поэтому у production-систем почти неизбежно появляется многоступенчатая политика: быстрый проход по умолчанию и дорогой reasoning-режим только там, где он действительно окупается.

Заключение

Test-time compute — это не один конкретный прием, а способ смотреть на инференс как на объект масштабирования. Работы 2024 года показали, что дополнительные вычисления во время ответа могут заметно повышать качество, если модель умеет хотя бы иногда выходить на верное решение, а система умеет отличать хорошие кандидаты от плохих.

Практический вывод для инженера простой: reasoning — это уже не только свойство весов модели, но и свойство вашей inference-системы. Поэтому выигрывает не тот, кто просто «включил думание», а тот, кто грамотно спроектировал бюджет, проверку и остановку.

Источники

• Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters — Charlie Snell, Jaehoon Lee, Kelvin Xu, Aviral Kumar.
• ICLR Oral: Scaling LLM Test-Time Compute Optimally Can be More Effective than Scaling Parameters for Reasoning.
• Self-Discover: Large Language Models Self-Compose Reasoning Structures — Pei Zhou и соавт.
• Large Language Models Self-Discover Reasoning Structures — Google DeepMind.
• Solving olympiad geometry without human demonstrations — Nature, 17 January 2024.
• AlphaGeometry: An Olympiad-level AI system for geometry — Google DeepMind.
• Learning to reason with LLMs | OpenAI.
• Introducing OpenAI o1-preview | OpenAI.
• Let’s Verify Step by Step — Hunter Lightman и соавт.
• Self-Refine: Iterative Refinement with Self-Feedback — Aman Madaan и соавт.

FAQ

Test-time compute — это просто chain-of-thought?

Нет. Chain-of-thought — только один из способов расходовать inference budget. Test-time compute шире: сюда входят параллельные сэмплы, majority vote, ревизии, verifier, tree search и внешние инструменты.

Может ли test-time compute заменить большую модель?

Иногда частично, но не всегда. На части режимов меньшая модель с хорошо организованным reasoning действительно может выглядеть неожиданно сильно, но на самых трудных задачах дополнительный инференс быстро упирается в предел базовой модели.

Где этот подход полезнее всего?

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

С чего начать внедрение в продукт?

Обычно — с дешевого адаптивного режима: базовый проход, затем ограниченный best-of-N или majority vote только для сложных запросов, а уже потом — judge-модель, тесты или доменный verifier. Без жесткого latency- и cost-budget reasoning-режим быстро становится слишком дорогим по умолчанию.

Читайте также

• OpenAI o1: как модель научили «думать» перед ответом
• DeepSeek-R1: что на самом деле значит «рассуждение из чистого RL»
• GPQA: как устроен benchmark с вопросами, которые не гуглятся
• Как читать AI-paper и не утонуть в абстрактном хайпе