Что такое тест-тайм компьютинг (Test-Time Compute) и чем он отличается от обычного инференса?

Краткий тезис

Compute|Test-Time Compute (TTC) — это стратегия выделения дополнительных вычислительных ресурсов на этапе инференса (inference) для улучшения качества ответа модели. В отличие от обычного инференса, который заканчивается за один forward pass (прямой проход) и сразу генерирует ответ, TTC позволяет модели выполнять внутренние рассуждения в скрытом пространстве (latent space) без генерации промежуточных токенов. Это делает TTC особенно полезным для сложных задач, требующих многошаговых рассуждений или самокоррекции, где один проход нейросети может быть недостаточным.

1. Термин: Test-Time Compute (TTC)

Compute|Test-Time Compute (вычисления в режиме тестирования) — это класс методов, при которых модель во время инференса тратит больше вычислительных ресурсов (FLOPS, памяти, времени), чем минимально необходимо для простого прохода по сети. Основная цель — повысить точность, надёжность или глубину ответа, не изменяя замороженные веса модели.

Обычный инференс (стандартный прямолинейный прогон) — модель получает входные данные (например, токены), пропускает их через все слои ровно один раз и сразу выдаёт вероятности следующего токена (в случае генеративных моделей). Никаких дополнительных циклов или исправлений внутри скрытых состояний не происходит.

TTC же подразумевает, что внутри модели или вокруг неё запускаются дополнительные итерации обработки, которые могут включать:

• повторное использование скрытых состояний (hidden states);
• внутренние циклы уточнения эмбеддингов (embeddings);
• вызов внешних модулей (верификаторов, симуляторов) с возвратом результата обратно в модель.

2. Зачем нужен TTC?

Не все запросы одинаково сложны. На простой вопрос «Сколько будет 2+2?» модель может ответить за один проход. Но на задачу вроде «Чему равно (12×15 + 48) / 6 — 7?» один проход часто даёт неверный результат. TTC позволяет модели «подумать дольше» и исправить ошибки.

Ключевые мотивации

Важно подчеркнуть: TTC не меняет веса модели (это не fine-tuning и не адаптация), а лишь перераспределяет budget|вычислительный бюджет между фазами forward pass.

3. Как работает TTC на уровне архитектуры?

В традиционных трансформерах (transformers) каждый токен проходит через фиксированное число слоёв (например, 12 слоёв). TTC добавляет итеративные механизмы внутри этих слоёв или между ними.

Самый простой пример — рекуррентный блок внутри трансформера: после прохода всех слоёв скрытое состояние последнего слоя подаётся обратно на вход первого слоя (или на вход некоторого модуля исправления) и повторно обрабатывается. При этом не генерируются новые токены, модель остаётся в «скрытом пространстве».

Более формально:

h⁰ = Embed(X)
for t in 1..T:
    hᵗ = TransformerBlock(hᵗ⁻¹)   # обычный forward pass
    if TTC_enabled:
        hᵗ = Refine(hᵗ)            # дополнительный цикл уточнения
output = FinalProjection(hᵀ)

Refine может быть:

• немедленным повторением блока с другими attention mask (например, маскирование своего выхода);
• вызовом внешнего модуля (верификатор, другая модель);
• стохастической выборкой с последующим усреднением.

4. Отличие TTC от Chain-of-Thought (CoT) и других методов

Chain-of-Thought (CoT) заставляет модель генерировать цепочку промежуточных токенов (текстовых рассуждений) перед финальным ответом. Это увеличивает число токенов и, следовательно, количество forward pass'ов, но каждое слово — это внешне наблюдаемая генерация.

TTC в чистом виде не генерирует внешние токены до момента финального ответа. Внутренние рассуждения происходят без артикуляции в текст, что потенциально экономнее (векторы сжимают информацию сильнее, чем токены) и быстрее (меньше вызовов словаря).

5. Техники реализации TTC в современных моделях

5.1. Итеративная рефинировка эмбеддингов

В моделях вроде Recurrent Memory Transformer (RMT) или Gato используются повторные проходы: контекстное представление задачи прогоняется несколько раз через один и тот же блок, корректируясь.

5.2. Самокоррекция через слой верификации

Модель генерирует черновой ответ, затем верификатор (отдельная модель или часть основной) оценивает его правильность. Если оценка низкая — повторный проход со сдвигом внимания.

5.3. Latent Bottleneck с итеративным уточнением

Скрытый вектор обновляется за счёт цикла внутреннего внимания (self-attention loop) без выхода в словарь. Пример — Thinker архитектуры (DeepMind), где модель делает несколько шагов «размышления» в латентном пространстве, затем один раз декодирует ответ.

5.4. Поиск в пространстве цепочек (Tree-of-Thoughts с TTC)

Идея Tree-of-Thoughts (ToT) комбинируется с TTC: модель генерирует ветви рассуждений, каждая ветвь проверяется верификатором, и на основе бюджета вычислений выбирается лучшая ветвь.

6. Компромиссы: задержка vs качество

TTC всегда увеличивает латентность (latency) — время ответа. Задача системы — распределить вычислительный бюджет так, чтобы на сложные запросы тратить больше ресурсов, а на простые — меньше. Желательно иметь адаптивный механизм: модель сама решает, сколько итераций делать (например, по confidence score).

Правило «не больше трёх»: на практике более 3-5 итераций не дают существенного прироста и могут привести к overthinking (ухудшению из-за шума).

7. Примеры моделей и подходов, использующих TTC

• OpenAI o1 — модель, специально обученная делать много внутренних рассуждений (TTC) перед ответом. Согласно документации, o1 тратит в несколько раз больше compute на сложные задачи, чем GPT-4.
• DeepMind’s Gato — использует повторные проходы скрытого состояния для планирования действий.
• Self-Correction with Verifier (Wang et al., 2022) — генерация + верификация + повторная генерация.
• LM with Explicit Iterative Refinement — например, STaR (Self-Taught Reasoner) на этапе инференса делает TTC, повторно переваривая контекст.

8. Связь с агентными системами (Agentic RAG)

В агентных RAG (вопрос 150) TTC играет ключевую роль: агент может «подумать» в скрытом пространстве, стоит ли делать запрос к базе знаний или выполнить внешнюю операцию. После каждого шага (вызов API, поиск документа) агент может запустить цикл TTC для интеграции новой информации.

Пример: агент ищет факт, находит два противоречащих документа, запускает TTC, чтобы взвесить надёжность, и только потом формирует ответ. Без TTC агент просто конкатенировал бы документы и выдал бы противоречивый ответ.

9. Когда применять TTC (и когда не стоит)

Когда полезно:

• Запросы с многошаговой логикой (математика, логические головоломки, программирование).
• Задачи, где цена ошибки велика (юридические консультации, медицинские рекомендации).
• Агентные сценарии с динамическим контекстом.

Когда не нужно:

• Простые фактологические вопросы (даты, определения) — излишняя задержка.
• Генерация творческого текста — TTC может «засушить» ответ.
• Сценарии с жёсткими ограничениями по времени (real-time чаты).

10. Метрики оценки эффективности TTC

• Accuracy на сложных бенчмарках (MATH, GSM8K, HumanEval).
• Cost-per-correct-answer: сколько дополнительных FLOPS тратится на правильный ответ.
• Liftoff threshold: при скольких итерациях точность перестаёт расти.
• Robustness: проверка, не ухудшает ли TTC простые запросы (устойчивость к overthinking).

11. Ограничения и риски

• Overthinking: модель «зацикливается» и начинает выдавать шум.
• Интерпретируемость: внутренние рассуждения невидимы, их сложно отлаживать.
• Нестабильность: небольшие изменения в скрытом пространстве могут привести к разным ответам.
• Рост стоимости: TTC требует больше GPU/TPU времени, что увеличивает операционные расходы.

Пет-проект для закрепления

Задача: Реализовать минимальный TTC для модели TinyLlama-1.1B на задаче решения математических выражений из 3-4 шагов (например: «((15 + 4) × 2) − 7 = ?»).

Инструменты: HuggingFace Transformers, PyTorch, набор данных GSM8K (или его фрагмент).

Шаги:

1. Создать бейзлайн: взять TinyLlama с промптом «Реши шаг за шагом» (CoT). Замерить accuracy и время.
2. Модифицировать модель для TTC: добавить после последнего слоя трансформера повторяемый блок refinement. На вход refinement подаётся последнее скрытое состояние, на выходе — уточнённое. Число итераций — параметр (1..5). После итераций идёт проекция на словарь.
3. Обучить refinement блок (или дообучить всю модель) на подмножестве GSM8K, используя потери на финальный ответ. Важно: не генерировать промежуточные токены, только внутренние итерации.
4. Тестирование: сравнить accuracy при 1, 2, 3, 4 итерациях на отложенной выборке. Замерить latency.

Ожидаемый результат:

• Accuracy растёт с числом итераций, но после 3-4 выходит на плато.
• Время ответа линейно растёт.
• На простых примерах TTC не даёт улучшения, а иногда даже незначительно ухудшает (overfitting на сложные).

Связь с другими вопросами

Навигация

• Предыдущий: 150
• Следующий: 152
• Индекс: 00. Индекс разборов