Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Память, проверку и повторные вызовы LLM-агента удалось связать с измеримыми затратами, которые обычная оценка возможностей модели не учитывает. В препринте команды Georgia Institute of Technology и Etude AI, который не проходил рецензирование и числа для которого получили сами авторы, разрыв между двумя способами доступа к памяти достигает порядка Θ(n). Это позволяет оценивать архитектуру агента отдельно от качества выбранной LLM.
Цена возникает вокруг модели
LLM-агент редко сводится к одному запросу. Обвязка разбивает задачу на шаги, переносит данные между контекстом и постоянной памятью, вызывает инструменты, проверяет ответы и повторяет неудачные вычисления. Каждый такой механизм расходует вызовы модели и пропускную способность памяти, даже если сама LLM не меняется.
Авторы предложили абстракцию Language Model Agent Machine, или LAM. Она фиксирует смысловые возможности модели и отдельно учитывает ресурсы обвязки. Благодаря этому можно сравнивать не две LLM, а два способа построить агента поверх одной и той же модели.
Для переноса данных LAM связывает выполнение агента с классической задачей о размещении фишек на графе. В ней вычислительные шаги зависят друг от друга, а ограниченная быстрая память вынуждает переносить данные или вычислять их заново. Эта связь переносит известные нижние границы ввода-вывода на обмен между контекстом модели и постоянной памятью агента.
Практический смысл такого взгляда в том, что длинный контекст сам по себе не устраняет издержки. Если промежуточное состояние не помещается в доступную память или поступает в неудобном порядке, обвязка чаще передаёт одни и те же данные либо заново вызывает модель.
Доступ к памяти и пересчёт дают разные узкие места
Способ чтения памяти меняет сложность задачи. При обходе цепочки указателей произвольный доступ позволяет сразу обратиться к нужному адресу. Последовательный доступ без предварительного угадывания вынуждает читать данные по порядку; разрыв между этими интерфейсами достигает Θ(n). Поэтому хранилище с одинаковым объёмом может давать разную стоимость в зависимости от доступных операций.
Второй источник расходов — потерянные промежуточные результаты. Для вычислений на графах с особым порядком зависимостей число вызовов модели выражается как Θ(n²/(C+S)+n), где C обозначает вместимость контекста, а S — объём постоянной памяти. Чем меньше их общая ёмкость, тем чаще агент повторяет уже выполненную смысловую работу.
Надёжность тоже превращается в расход ресурсов. Работа связывает вероятность ошибки с повторной выборкой ответов на отдельных этапах, учитывает проверяющий механизм, который сам может ошибаться, и выводит оптимальный интервал между контрольными точками. Слишком частые проверки тратят вызовы, а слишком редкие заставляют откатывать длинные участки работы после сбоя.
Предсказания о переносе данных и надёжности проверяли на GPT-6 Astra в контролируемых и отложенных экспериментах. В задачи входили цепочки примеров MATH, программная проверка, выбор политики работы агента и сравнение размера вызовов с объёмом передаваемых данных и итоговой надёжностью. Поскольку этот материал сделан по абстракту, а не по полному тексту, точную схему экспериментов и способ расчёта показателей из доступного описания восстановить нельзя.
Архитектуру агента стоит считать до выбора модели
Работа не предлагает денежный калькулятор: абстракт не связывает вызовы и перенос данных с тарифами API, задержкой или расходом GPU. Зато она задаёт структуру расчёта. Команда может отдельно учитывать число обращений к модели, движение данных между контекстом и хранилищем, повторные вычисления и стоимость проверок.
Для агента с длинной последовательностью зависимых действий это меняет порядок проектирования. Сначала стоит описать, какие промежуточные результаты нужно сохранять, как быстро к ним обращаться и после каких этапов проверять состояние. Затем можно подбирать вместимость контекста и модель, а не рассчитывать, что более крупная LLM компенсирует неудачный доступ к памяти.
Особенно заметен вывод для систем, где модель вызывает инструменты и возвращается к ранним результатам. Последовательное хранилище может стать узким местом даже при достаточном объёме, а экономия на постоянной памяти способна увеличить число повторных вызовов. В таких сценариях цена архитектурного решения возникает не только в хранилище, но и в счёте за модель.
LAM пока полезнее как способ рассуждать о границах системы, чем как готовая методика бюджетирования. Она разделяет качество LLM и эффективность обвязки, поэтому помогает искать причину затрат там, где замена модели ничего не исправит: в движении состояния, интерфейсе памяти, частоте контрольных точек и повторении уже сделанной работы.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
