Test-Time Compute
test-time compute — дополнительные вычисления модели во время решения задачи
Test-Time Compute — способы потратить больше вычислений на конкретный ответ: сделать несколько попыток, провести поиск, проверить решение или увеличить внутренний бюджет рассуждения. Польза зависит от задачи и не растёт бесконечно вместе с числом токенов.
Коротко
Коротко. Обычно модель отвечает за один проход. Test-time compute добавляет вычисления именно во время решения: больше токенов, несколько кандидатов, поиск по дереву, внешний проверяющий или повтор после найденной ошибки. Это может повысить точность сложной задачи, но увеличивает задержку и стоимость.
Чем это отличается от обучения
При обучении меняются веса модели. Дополнительные вычисления расходуются заранее и влияют на все будущие запросы.
При test-time compute веса могут остаться прежними. Больше ресурсов получает только текущая задача. Поэтому один запрос можно обработать быстро, а другому дать несколько попыток и проверку.
Это отдельная ручка наряду с:
- размером и архитектурой модели;
- объёмом и качеством обучения;
- контекстом и инструментами во время запроса.
Основные способы
Длиннее обработать одну попытку
Reasoning-модель может использовать больший внутренний или выходной бюджет на промежуточное решение. Конкретный механизм зависит от API: видимый текст рассуждения не обязательно совпадает с внутренним вычислением.
Сгенерировать несколько кандидатов
Модель решает задачу несколько раз. Затем ответы объединяются голосованием, правилом или отдельным judge. Метод полезен, если ошибки попыток достаточно независимы.
Искать по вариантам
Вместо одной цепочки система развивает несколько веток, отбрасывает слабые и продолжает перспективные. Такой поиск помогает в коде, планировании и головоломках, но быстро расходует бюджет.
Проверить и исправить
Ответ проходит через тест, калькулятор, компилятор, симулятор или другую модель. Обнаруженная ошибка возвращается в следующую итерацию. Проверяемый внешний сигнал часто полезнее просьбы «подумай ещё».
Выделять бюджет по сложности
Маршрутизатор оценивает запрос и выбирает быстрый либо глубокий режим. Ошибка маршрутизации тоже имеет цену: сложная задача может уйти в короткий проход, а простая — потратить лишние ресурсы.
Наглядный пример
Модель должна исправить функцию и пройти тесты.
Одиночный режим генерирует один patch. Test-time pipeline может:
- построить несколько гипотез причины;
- внести минимальный patch для каждой;
- запустить тесты в изолированной среде;
- сравнить diff и побочные эффекты;
- выбрать прошедший вариант;
- остановиться по лимиту времени или шагов.
В этом примере качество повышает не длина текста сама по себе, а обратная связь от тестов.
Почему дополнительные попытки помогают
Вероятностная модель способна знать нужный приём и всё же выбрать неудачное продолжение. Несколько траекторий повышают шанс найти верную. Проверяющий затем отделяет хороший кандидат от убедительной ошибки.
Условие важно: judge должен быть надёжнее случайного выбора. Если все попытки повторяют одно заблуждение или проверяющий предпочитает уверенный стиль, вычисления только укрепят ошибку.
Где эффект обычно заметнее
- задачи с проверяемым ответом;
- математика и код;
- планирование с ограничениями;
- поиск доказательства или контрпримера;
- извлечение, которое можно сверить со схемой и источником;
- агентские действия с наблюдаемым результатом.
Для простого приветствия, свободного стиля или факта без доступа к источнику длинное рассуждение часто не окупается.
Бюджет не равен качеству
После некоторого уровня улучшение замедляется. Модель может начать ходить по кругу, менять верное решение или производить больше правдоподобного текста без новых доказательств.
Остановка строится по наблюдаемому сигналу:
- тесты прошли;
- найдено подтверждение в источнике;
- кандидаты сошлись;
- улучшение метрики прекратилось;
- исчерпаны шаги, время или деньги;
- дальнейшее действие требует человека.
Как измерять
Сравнивают несколько бюджетов на одном наборе задач. Для каждого записывают:
- долю корректных результатов;
- стоимость и задержку;
- число попыток и инструментальных вызовов;
- долю задач, где дополнительный бюджет изменил ответ;
- ошибки проверяющего;
- стоимость одного принятого результата.
График «качество против вычислений» полезнее одного рекорда на benchmark. Он показывает точку, после которой ресурсы почти не дают выигрыша.
Скрытое и видимое рассуждение
Длинный chain of thought в ответе не является надёжной телеметрией внутренних причин модели. Он может быть удобным объяснением, реконструкцией или просто ещё одним сгенерированным текстом.
Для аудита лучше сохранять проверяемые артефакты: запросы к инструментам, найденные документы, результаты тестов, кандидаты и критерий выбора. Они воспроизводимее свободного рассуждения.
Стоимость и задержка
Дополнительная попытка расходует токены, вычисления и иногда платные инструменты. Параллельный запуск сокращает время ожидания, но не общую работу. Последовательная проверка экономит ресурсы при ранней остановке, но увеличивает задержку.
Точные цены и лимиты принадлежат конкретной модели. Для продукта важна формула:
общая стоимость = все попытки + проверки + инструменты + повторы
Частые ошибки
- Считать длинный ответ более умным. Объём текста не измеряет корректность.
- Использовать модель как единственного judge. Она может разделять ошибки кандидатов.
- Не ставить предел циклу. Агент способен повторять похожие действия.
- Измерять только лучший результат. Нужны средняя стоимость и распределение ошибок.
- Показывать пользователю всё внутреннее рассуждение. Это может раскрыть данные и не объясняет систему точно.
- Давать одинаковый бюджет всем запросам. Простые задачи оплачивают сложные без пользы.
Частые вопросы
Reasoning-модель и test-time compute — одно и то же?
Reasoning-модель — тип модели или продукта. Test-time compute — более общий принцип, который включает несколько попыток, поиск и внешнюю проверку.
Можно ли улучшить маленькую модель?
Иногда да, особенно при доступе к точному проверяющему. Но дополнительный поиск не добавляет знаний, которых нет в модели и инструментах.
Как выбрать thinking budget?
По кривой качества, задержки и стоимости на собственном наборе. Универсального числа токенов нет.
Самопроверка всегда помогает?
Нет. Без нового сигнала модель может повторить прежнюю ошибку. Тест, источник или независимый кандидат обычно полезнее простого запроса «проверь себя».
Главное
Test-Time Compute превращает вычисления на запросе в управляемый ресурс. Его можно потратить на более длинную попытку, несколько решений, поиск или проверку. Выигрыш появляется там, где есть сложность и надёжный сигнал качества; без остановки и измерения дополнительное «размышление» легко становится просто более дорогим ответом.
