Как масштабируется тест-тайм компьютинг? Есть ли закон diminishing returns?

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

Test-time compute (вычислительные ресурсы, затрачиваемые на этапе инференса) масштабируется нелинейно: увеличение числа токенов, итераций или вызовов LLM повышает качество ответа, но с убывающей отдачей (diminishing returns). Эмпирические исследования (OpenAI o1, DeepSeek R1) показывают, что после определённого порога дальнейшее наращивание compute даёт всё меньший прирост точности. Оптимальная стратегия — адаптивное выделение ресурсов: простые задачи решаются быстро, сложные — с большим бюджетом. Некоторые архитектуры (Chain-of-Thought, Tree-of-Thought, агентные циклы) позволяют «разворачивать» модель на произвольную глубину, что делает test-time compute гибким рычагом управления качеством.

1. Термин: Test-time compute

Test-time compute (также inference-time compute, decoding compute) — это количество вычислительных операций (FLOPs, число токенов, число вызовов LLM), затрачиваемых на генерацию одного ответа после того, как модель обучена. В отличие от training compute (ресурсы на обучение), test-time compute можно динамически менять для каждого запроса.

Зачем это нужно

• Улучшение качества ответов на сложные задачи (логика, математика, многошаговый поиск).
• Возможность «думать дольше» над трудными вопросами.
• Баланс между latency и accuracy.

Примеры способов увеличить test-time compute

• Chain-of-Thought (CoT): генерация промежуточных рассуждений (больше токенов).
• Self-consistency: несколько прогонов CoT с голосованием.
• Tree-of-Thought (ToT): ветвление и поиск по дереву рассуждений.
• Агентные циклы: многократные вызовы LLM с инструментами (retrieval, код, калькулятор).
• Budget forcing: принудительное продолжение генерации (например, «подталкивание» модели к дальнейшим размышлениям).

2. Как масштабируется test-time compute

Масштабирование test-time compute можно рассматривать по трём осям:

Эмпирические наблюдения (на задачах MATH, GSM8K, сложных QA):

• При малом бюджете (например, до 1000 токенов) качество растёт быстро.
• При среднем бюджете (1000–10000 токенов) прирост замедляется.
• При большом бюджете (>10000 токенов) улучшения становятся маргинальными, а иногда качество даже падает из-за «переусложнения» (overthinking).

График (словесное описание):
Кривая напоминает логарифмическую: accuracy ~ a * log(compute) + b до насыщения.

3. Закон diminishing returns (убывающей отдачи)

Diminishing returns — экономический принцип, применимый к test-time compute: после некоторого порога каждая дополнительная единица compute даёт всё меньший прирост качества.

Формальное описание
Пусть C — количество затраченных токенов (или FLOPs), A(C) — метрика качества (accuracy, F1). Тогда:

dA/dC > 0  (качество растёт)
d²A/dC² < 0 (вторая производная отрицательна — рост замедляется)

Причины diminishing returns

1. Избыточные рассуждения: модель начинает повторяться, ходить по кругу.
2. Шум от длинного контекста: длинные цепочки рассуждений могут содержать ошибки, которые накапливаются.
3. Ограничения самой модели: даже при бесконечном времени модель не может превзойти свой «потолок» знаний.
4. Проклятие размерности поиска: в Tree-of-Thought количество ветвей растёт экспоненциально, а полезные пути редки.

Исследования

• В работе «Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters» (Snell et al., 2024) показано, что оптимальная стратегия — адаптивное выделение ресурсов.
• OpenAI o1 демонстрирует, что увеличение «времени размышления» улучшает результаты на сложных задачах, но прирост замедляется после ~30 секунд.

4. Адаптивное выделение ресурсов (adaptive compute allocation)

Вместо фиксированного бюджета на все запросы, эффективнее адаптивно определять, сколько compute тратить на каждый запрос.

Методы

• Early stopping: прекратить генерацию, если модель уже уверена в ответе (например, по вероятности токенов).
• Confidence threshold: если уверенность низкая — запустить дополнительный раунд рассуждений.
• Verifier-based: обучить отдельную модель (verifier) оценивать качество промежуточных шагов и решать, продолжать ли.
• Budget forcing: принудительно добавлять токены вроде «Wait, let me check again» для сложных задач.

Пример алгоритма

def adaptive_inference(query, model, max_budget=10000):
    budget = 0
    while budget < max_budget:
        response = model.generate(query, max_tokens=512)
        budget += len(response.tokens)
        if is_confident(response) or budget >= max_budget:
            return response
        query = query + " " + response + " Let's verify step by step."
    return response

Результат на лёгких запросах тратится мало compute (быстрый ответ), на сложных — много (точный ответ). Среднее качество выше, чем при фиксированном бюджете.

5. Архитектуры с произвольной глубиной

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

Примеры

• Chain-of-Thought (CoT): глубина = число шагов рассуждения.
• Tree-of-Thought (ToT): глубина + ширина (ветвление).
• Graph-of-Thought (GoT): произвольный граф рассуждений.
• Агентные циклы (ReAct, Reflexion): модель вызывает инструменты, получает результаты и продолжает.
• Recursive criticism: модель генерирует ответ, затем критикует его и улучшает.

Ключевая идея: модель не ограничена фиксированным числом слоёв (как при обучении), а может «думать» столько, сколько нужно, используя собственные выходы как вход для следующего шага.

Проблемы

• Рост latency.
• Накопление ошибок.
• Необходимость контроля бюджета (чтобы не уйти в бесконечный цикл).

6. Сравнение с scaling laws обучения

Вывод test-time compute — это дополнительный рычаг, который можно использовать после того, как модель обучена. Он не заменяет scaling обучения, но дополняет его.

7. Практические стратегии для инженеров

1. Измеряйте кривую quality vs compute на вашем датасете.
2. Используйте адаптивное выделение (early stopping, verifier).
3. Ограничьте максимальный бюджет (например, 4096 токенов на CoT).
4. Для агентных систем — ставьте тайм-аут на цикл (макс. 10 вызовов).
5. Комбинируйте с retrieval: если ответ найден в документах, не тратьте compute на рассуждения.
6. Мониторьте метрики: среднее число токенов, latency, accuracy.

Пример конфигурации

test_time:
  strategy: adaptive
  max_tokens: 8192
  early_stop_confidence: 0.95
  verifier_model: "gpt-4o-mini"
  budget_per_query: 0.01 USD

8. Исследования и open-source реализации

• OpenAI o1: использует «chain-of-thought reasoning» с внутренними токенами размышлений.
• DeepSeek R1: открытая модель с reinforcement learning на test-time compute.
• STILL-ALIVE (Snell et al.): показали, что адаптивное выделение превосходит фиксированное.
• LangChain / LangGraph: фреймворки для построения агентных циклов с контролем бюджета.

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

Задача Реализовать адаптивный test-time compute для задачи математического рассуждения (например, решение уравнений).

Инструменты Python, OpenAI API (или локальная модель через Ollama), библиотека tenacity для повторных попыток.

Шаги:

1. Создать датасет из 50 математических задач разной сложности (лёгкие: 2+2, сложные: интегралы).
2. Реализовать базовый CoT с фиксированным числом токенов (512).
3. Реализовать адаптивную версию:
   • Генерировать ответ.
   • Если модель выражает неуверенность (ключевые слова «maybe», «I think») — запустить второй раунд с принудительным «Let's double-check».
   • Ограничить максимум 3 раундами.
4. Сравнить accuracy и среднее число токенов на обеих стратегиях.
5. Построить график зависимости accuracy от затраченных токенов.

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

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

Навигация

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