Заголовок: ломаем догму 'длиннее reasoning - лучше'. Как DTR ускоряет локальные LLM в 2 раза без потери качества

Безумная идея Google: остановить модель, когда она только начинает 'думать' хорошо

Два года мы верили в священную догму: чем длиннее цепочка рассуждений (reasoning chain), тем точнее ответ модели. Каждый токен reasoning - это священный кирпичик в храме точности. Пока исследователи Google не провели простой эксперимент: они измерили, какой вклад каждый новый токен reasoning вносит в конечную точность.

Оказалось, что после определенного момента модель начинает 'бубнить себе под нос'. Она генерирует reasoning, но он не приближает к правильному ответу. Просто тратит ваши вычислительные ресурсы. На 28.02.2026 это кажется очевидным - но в 2024 году это было ересью.

DTR - это не магия, это математика эффективности reasoning

Deep Thinking Ratio (DTR) - метрика, которая измеряет 'полезность' каждого токена reasoning. Проще говоря, насколько новый токен reasoning увеличивает вероятность правильного ответа.

Формула выглядит страшно, но суть проста: DTR = (вероятность_правильного_ответа_после_n_токенов) / (вероятность_правильного_ответа_после_n-1_токенов). Если DTR близко к 1 - модель 'топчется на месте'. Если DTR заметно больше 1 - reasoning продуктивен.

Читаешь таблицу и думаешь: 'Не может быть. Почти вдвое меньше вычислений при той же точности?' Но это работает. Особенно на локальном железе, где каждый сэкономленный токен - это реальная экономия времени и электричества.

1 Шаг первый: ставим правильный эксперимент для измерения DTR вашей модели

Не верьте абстрактным исследованиям. Ваша конкретная модель (допустим, одна из современных LLM с tool calling) на ваших задачах будет иметь свой DTR профиль. Нужно его измерить.

Берем 100-200 примеров из вашей предметной области. Запускаем модель с reasoning, но сохраняем не только финальный ответ, а лог вероятностей на каждом шаге reasoning. Звучит сложно? На практике это выглядит так:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

# Загружаем актуальную модель 2025-2026 года
model_name = "mistralai/Mistral-2.5-24B-Instruct"  # пример на февраль 2026
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16,
    device_map="auto"
)

# Функция для измерения DTR
def measure_dtr_per_step(question, max_reasoning_tokens=100):
    prompt = f"""Реши задачу по шагам. \nВопрос: {question}\nРассуждение: """
    
    inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
    
    dtr_values = []
    prev_answer_prob = None
    
    # Генерируем reasoning по токенам
    for i in range(max_reasoning_tokens):
        with torch.no_grad():
            outputs = model.generate(
                **inputs,
                max_new_tokens=1,
                output_logits=True,
                return_dict_in_generate=True
            )
        
        # Здесь упрощенная логика - в реальности нужно вычислить
        # вероятность правильного ответа на каждом шаге
        current_token = tokenizer.decode(outputs.sequences[0, -1])
        
        # (Упрощенный пример - в реальном коде нужно вычислять
        # вероятности для разных вариантов ответа)
        if i > 10:  # После 10 токенов начинаем оценивать
            # Предположим, мы как-то определили вероятность правильного ответа
            current_answer_prob = estimate_answer_probability(outputs)
            
            if prev_answer_prob is not None:
                dtr = current_answer_prob / prev_answer_prob
                dtr_values.append(dtr)
                
                # Если DTR упал ниже порога - останавливаемся
                if dtr < 1.05:  # пороговое значение
                    break
            
            prev_answer_prob = current_answer_prob
        
        # Добавляем токен к промпту для следующей итерации
        inputs['input_ids'] = outputs.sequences
    
    return dtr_values

2 Определяем порог DTR для ваших задач

Здесь начинается искусство. Слишком высокий порог (скажем, 1.2) - остановитесь слишком рано, потеряете точность. Слишком низкий (1.01) - почти не сэкономите.

Рекомендация на 2026 год: начните с порога 1.05 для сложных аналитических задач и 1.03 для простых классификаций. Но это эмпирика. Нужно построить график зависимости точности от порога DTR.

Вот как это выглядит на практике для разных типов задач:

• Математические задачи (GSM8K): DTR падает резко после нахождения метода решения. Порог 1.07 работает хорошо.
• Кодогенерация: DTR держится высоким дольше, так как каждый новый токен уточняет синтаксис. Порог 1.03-1.04.
• Классификация текста: Модель быстро 'решает', потом 'объясняет'. Порог 1.10 для агрессивной экономии.

3 Think@n стратегия: когда именно проверять DTR?

Самая глупая ошибка - проверять DTR после каждого токена. Вы потратите больше вычислений на проверку, чем сэкономите на generation.

Think@n означает: генерируем n токенов reasoning без проверок, потом измеряем DTR, решаем продолжать или остановиться.

# Практическая реализация Think@n

def think_at_n_generation(question, n=10, dtr_threshold=1.05):
    """
    Think@n стратегия:
    1. Генерируем первые n токенов reasoning
    2. Оцениваем DTR
    3. Если DTR выше порога - генерируем еще n токенов
    4. Повторяем до срабатывания порога или max длины
    """
    full_reasoning = ""
    
    while len(full_reasoning.split()) < 200:  # max tokens
        # Генерируем очередной блок из n токенов
        new_block = generate_reasoning_block(
            question=question,
            previous_reasoning=full_reasoning,
            tokens=n
        )
        
        full_reasoning += new_block
        
        # Оцениваем DTR после блока
        dtr = calculate_dtr(question, full_reasoning)
        
        if dtr < dtr_threshold:
            # DTR упал ниже порога - останавливаем reasoning
            break
    
    # Теперь генерируем финальный ответ на основе reasoning
    final_answer = generate_final_answer(question, full_reasoning)
    return final_answer

Оптимальное n зависит от задачи. Начинайте с n=8 для мелких моделей (7B параметров) и n=15 для крупных (70B+). Почему? Мелкие модели 'колеблются' чаще, их нужно проверять чаще.

Три смертельные ошибки при внедрении DTR

Ошибка 1: использовать один порог DTR для всех типов промптов

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

Ошибка 2: не учитывать стоимость вычисления DTR

Если для вычисления DTR вам нужно запускать forward pass модели отдельно (чтобы получить вероятности кандидатов ответов), это может съесть всю экономию. Решение - вычислять DTR на лету во время generation, как это сделано в фреймворке SEDAC v5.

Ошибка 3: слепо доверять DTR для творческих задач

В творческом письме или генерации идей низкий DTR не означает 'плохо'. Модель может исследовать разные направления. Здесь DTR нужно использовать осторожно или с другими метриками.

Почему DTR особенно важен именно в 2026 году?

Три фактора:

1. Мультимодальность - современные модели типа GPT-5o или Gemini 2.5 Ultra генерируют reasoning для изображений, видео, аудио. Каждый токен reasoning здесь в 3-5 раз дороже, чем для текста.
2. Edge-устройства - запуск на телефонах и IoT, где каждый милливатт на счету. DTR экономит не только время, но и батарею.
3. Конкуренция - если ваше приложение на локальных LLM отвечает за 500 мс, а конкурента - за 250 мс с той же точностью, вы проигрываете.

Совмещаем DTR с другими методами ускорения

DTR - не серебряная пуля. Но в комбинации с другими методами дает мультипликативный эффект:

• С DTR + квантование - квантованные модели иногда 'колеблются' дольше в reasoning. DTR помогает раньше остановить эти колебания.
• С DTR + Multiplex Thinking - sampling нескольких токенов вместо одного повышает точность, но увеличивает вычисления. DTR компенсирует этот рост.
• С DTR + Tuneable Attention - динамическое окно внимания позволяет модели 'видеть' только релевантные части reasoning. DTR решает, когда расширять окно.

Что будет дальше? Прогноз на 2027 год

DTR - только начало. Уже сейчас исследователи работают над:

1. Динамический DTR - порог, который меняется в зависимости от сложности задачи (определяется на лету).
2. DTR для отдельных компонентов модели - не всей модели, а только определенных слоев или голов внимания.
3. Аппаратная поддержка DTR - специализированные AI-ускорители, которые вычисляют DTR 'на аппаратном уровне', почти бесплатно.

Самая интересная возможность: обучение моделей с учетом DTR с самого начала. Не 'научись генерировать reasoning', а 'научись генерировать полезный reasoning'. Такие модели будут иметь изначально более высокий DTR, что еще больше ускорит inference.

Что делать прямо сейчас?

Не ждите идеальной реализации. Начните с простого:

1. Возьмите 50 своих типичных запросов к LLM
2. Запустите с длинным reasoning (скажем, 150 токенов) и коротким (50 токенов)
3. Сравните accuracy и latency
4. Если разница в accuracy меньше 2%, а latency в 2 раза меньше - поздравляю, вы только что открыли, что ваш use case идеален для DTR

Следующий шаг - внедрить простой Think@n с фиксированным n и порогом. Даже такая наивная реализация даст 30-40% экономии. А когда освоитесь - переходите к динамическому DTR.

Помните: каждая секунда, которую вы сэкономите на reasoning, - это не просто техническая оптимизация. Это возможность обработать больше запросов на том же железе. Это более отзывчивый интерфейс для пользователей. И в конечном счете - конкурентное преимущество.

P.S. Если после прочтения этой статьи вы все еще генерируете фиксированные 100 токенов reasoning для каждой задачи - вы буквально сжигаете половину своих вычислительных ресурсов. Бесплатно.

Подписаться на канал