Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Энергозатраты на вывод LLM научились оценивать до развёртывания модели — по её архитектуре, длине входа и ожидаемого ответа. В работе University of Bologna ошибка оказалась примерно втрое ниже прежнего уровня, хотя препринт не рецензирован и числа получили сами авторы. Такой расчёт позволяет заранее сравнить длинный контекст, GQA и бюджет рассуждений, а не ждать замеров готовой системы.
Почему два токена стоят разной энергии
Тарифы API считают токены одинаковыми, но вычислительная цена у них различается. Во время подготовки запроса модель обрабатывает весь вход и заполняет кэш ключей и значений — память, в которой хранит данные внимания для уже прочитанного контекста.
Затем модель генерирует ответ последовательно. Каждый новый токен обращается ко всему накопленному кэшу, поэтому поздний токен длинного ответа требует больше работы, чем ранний. Если одновременно растут вход и выход, общие энергозатраты уже нельзя надёжно описать фиксированной ценой токена.
SIMPLE разделяет расход энергии на подготовку входа, чтение кэша при генерации и вычисление следующего токена. Закон использует четыре общих коэффициента вместе с параметрами архитектуры: числом слоёв, размерностью скрытого представления и устройством внимания.
Коэффициенты калибруют для сочетания оборудования и программной среды, но не подгоняют заново для каждой LLM. В этом отличие от SweetSpot: прежняя модель скрывала свойства конкретной архитектуры внутри своих коэффициентов и потому требовала отдельных замеров для новой модели.
Длинный контекст дорожает дважды
Средняя абсолютная процентная ошибка SIMPLE составила около 12%. Эта метрика показывает, на сколько процентов прогноз в среднем отклоняется от фактического энергопотребления.
Модель объясняет, почему размер LLM нельзя свести к общему числу параметров. Энергия подготовки входа растёт квадратично с размерностью скрытого представления и линейно с глубиной модели. Поэтому широкий Transformer сильнее реагирует на удлинение запроса, чем архитектура с той же общей величиной, но другими пропорциями.
Устройство внимания влияет прежде всего на чтение кэша. GQA объединяет головы запросов в группы, которые используют общие ключи и значения. Более агрессивная группировка снизила энергию токена до трёх раз относительно MHA, где каждая голова хранит собственные ключи и значения.
Бюджет рассуждений тоже имеет оптимум. Сначала более длинный ответ распределяет энергию подготовки запроса между большим числом токенов, но затем растущий кэш перевешивает эту экономию. Точность продолжает расти, однако энергия растёт быстрее, поэтому отношение точности задачи к затраченной энергии достигает максимума при промежуточном бюджете.
Особенно заметен эффект в агентных сценариях. Для типичного запроса coding agent расчёт дал рост энергии на запрос в 13 раз относительно короткого неагентного контекста. Кэширование префикса убрало повторную подготовку большей части входа, но не чтение полного кэша при генерации: запрос всё равно требовал в 4,8 раза больше энергии.
Когда SIMPLE меняет планы разработки
Для собственной инфраструктуры SIMPLE подходит как фильтр до нагрузочного тестирования. Команда может подставить параметры нескольких архитектур и ожидаемые длины запросов, чтобы понять, где расход создаёт сама модель, где — длинный контекст, а где — генерация ответа.
Это меняет выбор архитектуры для продуктов с большими документами, историей диалога и агентными циклами. GQA становится не только способом уменьшить память, но и отдельным параметром эксплуатационной стоимости. Кэширование префикса остаётся полезным, однако его нельзя считать решением всей проблемы: сохранённый контекст всё равно приходится читать для каждого следующего токена.
Для моделей с рассуждением закон даёт основание настраивать лимит ответа по двум метрикам одновременно — качеству задачи и энергии запроса. Максимальный бюджет не обязательно даёт лучший эксплуатационный результат, даже если точность при нём выше.
Проверка охватывает плотные декодерные LLM семейств OPT, LLaMA, Gemma, Falcon, Qwen2 и Granite с MHA или GQA, запущенные через TensorRT-LLM на одном NVIDIA H100. Формула не учитывает размер пакета и параллельные запросы; для моделей-смесей экспертов, других ускорителей и распределённого вывода коэффициенты потребуют новой проверки.
SIMPLE прогнозирует джоули, а не счёт провайдера API. Поэтому для покупки готового API закон помогает сравнить поведение архитектур и нагрузок, но сам по себе не переводит длинный контекст в денежный тариф.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
