Как вы выбираете между увеличением тест-тайм компьютинга и использованием большей модели?

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

Выбор между test-time compute (дополнительные вычисления во время инференса, например, chain-of-thought или self-consistency) и большей моделью (больше параметров, выше качество, но фиксированный высокий cost на каждый запрос) — это trade-off между фиксированными и переменными затратами. Ключевой фактор — распределение сложности запросов: если запросы в основном простые, Compute|test-time compute позволяет тратить мало ресурсов на простые и много на сложные, что дешевле в среднем. Для heavy-tailed распределения (много простых, мало сложных) Compute|test-time compute эффективнее; для равномерно сложных запросов — model|большая модель может быть проще и надёжнее.

1. Термины: test-time compute и большая модель

Compute|Test-time compute — это любые дополнительные вычислительные затраты, которые происходят после того, как модель получила запрос, но до выдачи ответа. Примеры:

• Chain-of-Thought (CoT) — генерация промежуточных рассуждений.
• Self-consistency — несколько прогонов CoT с голосованием.
• Tree-of-Thoughts — перебор нескольких путей рассуждения.
• Рекурсивные вызовы (например, вызов инструментов, повторный retrieval).

Большая модель — модель с большим числом параметров (например, GPT-4, Claude 3 Opus, Llama 3 70B). Она имеет более высокое качество «из коробки», но каждый запрос требует фиксированного объёма вычислений (пропорционально числу параметров и длине контекста).

Фиксированный cost — стоимость одного запроса к большой модели практически не зависит от сложности запроса (в пределах одного контекстного окна). Переменный cost — стоимость запроса с test-time compute может варьироваться: простой запрос может быть обработан за один проход, сложный — за несколько.

2. Trade-off: фиксированный vs переменный cost

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

3. Распределение сложности запросов — ключевой фактор

Распределение сложности — это доля запросов разной сложности в вашем сценарии. Два типичных случая:

• Heavy-tailed (тяжёлый хвост): ~80% запросов простые (например, «Какая погода?»), ~20% сложные (например, «Проанализируй финансовый отчёт и сравни с прошлым кварталом»).
• Uniform (равномерное): все запросы примерно одинаковой сложности.

Математическая модель: Пусть:

• ( C_{[text](/wiki/text){big}} ) — cost одного запроса к большой модели (фиксированный).
• ( C_{[text](/wiki/text){small}} ) — cost одного прохода маленькой модели.
• Для простого запроса test-time compute требует ( k_{[text](/wiki/text){simple}} ) проходов (обычно 1).
• Для сложного запроса test-time compute требует ( k_{[text](/wiki/text){complex}} ) проходов (например, 5–10).
• ( p ) — доля сложных запросов.

Ожидаемый cost на запрос:

• Большая модель: ( \mathbb{E}C_{[text{big}}] = C_{[text](/wiki/text){big}} )
• Test-time compute: ( \mathbb{E}C_{[text{small}}] = (1-p) \cdot k_{[text](/wiki/text){simple}} \cdot C_{[text](/wiki/text){small}} + p \cdot k_{[text](/wiki/text){complex}} \cdot C_{[text](/wiki/text){small}} )

Test-time compute выгоднее, если: [ (1-p) \cdot k_{[text](/wiki/text){simple}} \cdot C_{[text](/wiki/text){small}} + p \cdot k_{[text](/wiki/text){complex}} \cdot C_{[text](/wiki/text){small}} < C_{[text](/wiki/text){big}} ]

При ( p \to 0 ) (почти все запросы простые) левая часть стремится к ( C_{[text](/wiki/text){small}} ), что обычно намного меньше ( C_{[text](/wiki/text){big}} ). При ( p \to 1 ) (все сложные) левая часть стремится к ( k_{[text](/wiki/text){complex}} \cdot C_{[text](/wiki/text){small}} ), что может быть сравнимо или больше ( C_{[text](/wiki/text){big}} ).

Вывод: для heavy-tailed распределения test-time compute почти всегда дешевле. Для равномерно сложных запросов большая модель может быть проще в эксплуатации и давать более стабильное качество.

4. Когда выбирать test-time compute

• Бюджет ограничен, и большая модель слишком дорога для массового использования.
• Большинство запросов простые (например, FAQ-бот, где 90% вопросов — «Как сбросить пароль?»).
• Допустима вариативная задержка — пользователь готов ждать 2–3 секунды на сложный вопрос, но хочет быстрого ответа на простой.
• Есть возможность тонко настраивать стратегию (например, динамически выбирать число шагов CoT).

Пример техники: Self-consistency с маленькой моделью (например, Llama 3 8B). На простой запрос — один прогон, на сложный — 5 прогонов с голосованием. Средний cost оказывается в 2–3 раза ниже, чем использование GPT-4 на всех запросах, при сопоставимом качестве на сложных.

5. Когда выбирать большую модель

• Требования к качеству максимальны — даже редкие ошибки на простых запросах недопустимы.
• Распределение сложности равномерное или смещено в сторону сложных запросов (например, юридический анализ, где каждый запрос требует глубокого понимания).
• Latency должна быть предсказуемой — test-time compute может давать выбросы задержки.
• Инфраструктура упрощается — один эндпоинт, один инстанс, не нужно управлять роутингом и динамическими стратегиями.

Пример: Финансовый ассистент, где каждый запрос — сложный анализ отчётов. Использование GPT-4 (большая модель) даёт стабильно высокое качество и предсказуемое время ответа.

6. Комбинированный подход: routing

На практике часто используют гибрид: маленькая модель с test-time compute для простых запросов, большая модель — для сложных. Для этого нужен классификатор сложности (rule-based или обученный классификатор).

Архитектура:

1. Запрос поступает в роутер.
2. Роутер оценивает сложность (например, по длине, наличию ключевых слов, эмбеддингу).
3. Если сложность низкая → маленькая модель + CoT (1 шаг).
4. Если сложность высокая → большая модель (или маленькая модель с большим числом шагов).

Пример кода (упрощённый):

import numpy as np

def classify_complexity(query: str) -> str:
    # Простой классификатор на основе длины и ключевых слов
    if len(query) < 50 and "анализ" not in query:
        return "simple"
    else:
        return "complex"

def answer_small_model(query: str, steps: int = 1) -> str:
    # Имитация маленькой модели с CoT
    return f"Small model answer after {steps} steps"

def answer_big_model(query: str) -> str:
    # Имитация большой модели
    return "Big model answer"

def hybrid_answer(query: str) -> str:
    complexity = classify_complexity(query)
    if complexity == "simple":
        return answer_small_model(query, steps=1)
    else:
        # Можно попробовать small model с большим числом шагов
        # или сразу big model
        return answer_big_model(query)

# Пример использования
queries = ["Какая погода?", "Проанализируй отчёт за 2024 год"]
for q in queries:
    print(f"Query: {q} -> {hybrid_answer(q)}")

Ожидаемый результат: средний cost снижается на 40–60% по сравнению с использованием только большой модели, при сохранении качества на сложных запросах.

7. Метрики для выбора

Принимая решение, оценивайте:

• Cost per query (средняя стоимость одного запроса).
• P95 latency (задержка для 95% запросов).
• Accuracy (или другая метрика качества) на валидационном наборе.
• Coverage — доля запросов, на которые модель дала приемлемый ответ.

Таблица сравнения для гипотетического сценария:

Гибрид даёт лучшее соотношение cost/качество.

8. Техники test-time compute в деталях

• Chain-of-Thought (CoT): модель генерирует цепочку рассуждений перед ответом. Увеличивает число токенов в 2–5 раз.
• Self-consistency: несколько независимых CoT, затем голосование по ответам. Увеличивает cost в ( N ) раз (обычно 3–10).
• Tree-of-Thoughts (ToT): модель генерирует несколько «ветвей» рассуждений, оценивает их и выбирает лучшую. Ещё более затратно, но может решать сложные задачи.
• Рефлексия (Reflexion): модель генерирует ответ, затем критикует его и улучшает. Требует 2–3 прохода.

Каждая техника увеличивает cost пропорционально числу шагов, но может значительно повысить качество на сложных запросах.

9. Примеры больших моделей и их cost

Для test-time compute обычно используют маленькие модели (8B–13B), так как cost на один проход низкий, и даже 10 проходов дешевле одного запроса к большой модели.

10. Практические рекомендации

1. Проанализируйте логи — оцените распределение сложности запросов в вашей системе. Если 80% запросов короткие и фактические — test-time compute будет выгоден.
2. Запустите A/B тест — сравните cost и качество для двух стратегий на репрезентативной выборке.
3. Начните с гибрида — используйте маленькую модель с CoT для простых запросов и большую модель для сложных. Постепенно улучшайте классификатор.
4. Мониторьте выбросы — test-time compute может давать очень долгие ответы на редкие сложные запросы. Установите таймаут и fallback на большую модель.
5. Учитывайте total cost of ownership — большая модель может требовать дорогих GPU, а test-time compute — более гибкой оркестрации (например, Kubernetes с автоскейлингом).

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

Задача: Реализовать систему, которая для заданного набора запросов выбирает между маленькой моделью с CoT и большой моделью на основе классификатора сложности, и оценить экономию.

Инструменты:

• Python, библиотеки: transformers, torch, scikit-learn (для классификатора).
• Маленькая модель: HuggingFaceTB/SmolLM2-360M-Instruct (или любая маленькая).
• Большая модель: meta-llama/Llama-3.2-3B-Instruct (или через API, например, OpenAI).
• Датасет: 1000 запросов, размеченных на простые/сложные (можно сгенерировать синтетически).

Шаги:

1. Сгенерировать датасет запросов разной сложности (например, 800 простых, 200 сложных).
2. Обучить простой классификатор (логистическая регрессия на эмбеддингах) или написать rule-based.
3. Реализовать функцию answer_small(query, steps) — генерирует ответ с CoT (число шагов = steps). Для простых запросов steps=1, для сложных steps=5.
4. Реализовать answer_big(query) — использует большую модель.
5. Реализовать гибрид: роутер → маленькая модель (1 шаг) для простых, большая модель для сложных.
6. Посчитать средний cost (по числу токенов или времени инференса) и accuracy (по сравнению с эталонными ответами).
7. Сравнить с вариантами «только большая модель» и «только маленькая модель с CoT (5 шагов)».

Ожидаемый результат: Гибридная стратегия покажет cost на 40–60% ниже, чем большая модель, при accuracy на 1–3% ниже. Вы получите практическое понимание trade-off.

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

Навигация

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