Исследование: батчинг кандидатов решает энергозатраты LLM сильнее, чем их число

Исследователи изучили, как на точность и системные затраты влияет техника test-time scaling (масштабирование вычислений во время вывода), приём, при котором языковая модель генерирует несколько вариантов ответа и комбинирует их, чтобы повысить качество рассуждений. Обычно бюджет вычислений на это описывают одним числом, количеством сгенерированных кандидатов N. Но авторы показывают: N говорит только о том, сколько кандидатов сгенерировано, а не о том, как именно это было сделано технически, за один проход или за несколько.

Сначала команда проверила, как рост N влияет на точность: на 500 промптах из набора GSM8K (задачи школьной арифметики) для моделей Phi-3-mini и Qwen2.5-1.5B увеличение N с 1 до 8 подняло точность на 8,4 процентного пункта для Phi-3-mini и на 18,4 процентного пункта для Qwen2.5-1.5B.

Дальше исследователи зафиксировали N = 8 и сравнили четыре варианта того, как эти восемь кандидатов генерировать: один вызов сразу на восемь кандидатов (1x8), два вызова по четыре (2x4), четыре вызова по два (4x2) и восемь последовательных вызовов по одному кандидату (8x1). Для каждого варианта замерили задержку ответа, пропускную способность, часы работы GPU и суммарное энергопотребление видеокарты.

На GPU A100 восемь последовательных вызовов потратили в 4,64, 4,86 раза больше энергии GPU и показали в 5,77, 6,12 раза более высокую 95-ю процентиль задержки (P95), чем один пакетный вызов с теми же восемью кандидатами. Та же закономерность повторилась на трёх независимо запланированных узлах A100 для каждой модели и в дополнительных экспериментах с коротким выводом на наборе SciQ на видеокартах V100.

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

Ключевые факты

Рост числа кандидатов N с 1 до 8 повысил точность на 500 промптах GSM8K на 8,4 п.п. для Phi-3-mini и на 18,4 п.п. для Qwen2.5-1.5B.
При фиксированном N = 8 сравнили четыре схемы вызовов генерации: 1x8, 2x4, 4x2 и 8x1.
На GPU A100 восемь последовательных вызовов расходуют в 4,64, 4,86 раза больше энергии GPU и дают в 5,77, 6,12 раза более высокую P95-задержку, чем один батч из восьми кандидатов.
Закономерность подтвердилась на трёх независимых узлах A100 на модель и в отдельных экспериментах SciQ/V100.
Авторы делают вывод: оценки test-time scaling должны указывать не только число кандидатов и точность, но и схему вызовов генерации вместе с метриками GPU.

Почему это важно

Метод test-time scaling, генерация нескольких вариантов ответа с последующим выбором лучшего, стал стандартным способом поднять точность языковых моделей без дообучения. До сих пор его качество принято описывать одной цифрой, числом кандидатов N. Работа показывает, что это число ничего не говорит о реальных системных затратах: при одном и том же N разница в энергопотреблении и задержке между способами генерации достигает 4,6, 6,1 раза в зависимости от того, генерируются кандидаты одним батчем или последовательными вызовами.

Кому это важно

Инженерам, которые внедряют многовариантную генерацию (сэмплирование нескольких ответов) в продакшене, и командам инфраструктуры, считающим стоимость GPU-часов: неверный выбор схемы вызовов может впятеро увеличить счёт за электроэнергию и время ответа при том же качестве. Исследователям, которые сравнивают методы test-time scaling между собой и публикуют только точность и N, без учёта того, как кандидаты фактически генерировались.

Как это применить

Если кандидаты независимы друг от друга и видеопамять позволяет, стоит собирать их в один батч-вызов генерации, а не разбивать на несколько последовательных вызовов с меньшим размером батча, при равном числе кандидатов N это снижает энергозатраты и задержку в разы. При публикации или сравнении результатов test-time scaling указывать не только N и точность, но и схему вызовов генерации, а также замеры на уровне GPU (энергия, задержка, GPU-часы).

Можно ли доверять

Источник, препринт с полным текстом методики (страница на Hugging Face Papers), эксперименты воспроизведены на двух разных моделях (Phi-3-mini, Qwen2.5-1.5B), на трёх независимо запланированных узлах A100 для каждой модели и дополнительно на другом наборе данных и видеокарте (SciQ, V100), закономерность подтверждается на разных конфигурациях, что повышает доверие к выводу. В тексте не названы авторская аффилиация, издание или дата публикации, поэтому институциональную принадлежность и статус рецензирования работы проверить по имеющемуся тексту нельзя.

Риски и подводные камни

Эксперименты проведены на сравнительно небольших моделях (Phi-3-mini, Qwen2.5-1.5B) и на конкретном оборудовании (A100, V100), насколько вывод переносится на более крупные модели и другие GPU, в тексте не проверяется. Совет «использовать более крупный батч» работает только пока хватает видеопамяти: для больших моделей или длинных генераций батчинг всех кандидатов сразу может быть физически невозможен, и тогда компромисс между энергией и задержкой сложнее, чем показывает эта работа.