Cortex: Планирование и объединение ресурсов с учётом рабочих процессов для агентского обслуживания

Основная информация

• ID статьи: 2510.14126
• Название: Cortex: Workflow-Aware Resource Pooling and Scheduling for Agentic Serving
• Авторы: Nikos Pagonas (Columbia University), Yeounoh Chung (Google), Kostis Kaffes (Columbia University), Arvind Krishnamurthy (Google & University of Washington)
• Классификация: cs.DC (Распределённые, параллельные и кластерные вычисления)
• Дата публикации: 15 октября 2025 г. (препринт arXiv)
• Ссылка на статью: https://arxiv.org/abs/2510.14126

Аннотация

В данной работе представлен Cortex — прототип платформы обслуживания с учётом рабочих процессов, разработанный для агентских рабочих нагрузок. Основной принцип Cortex заключается в изоляции этапов: предоставление выделенных пулов ресурсов для каждого отдельного этапа агентского рабочего процесса. Эта простая, но мощная стратегия снижает межэтапные помехи в вычислениях и памяти, обеспечивая лучшее использование KV-кэша, повышенную пропускную способность и более предсказуемую производительность. Путём адаптации распределения ресурсов и планирования для каждого отдельного этапа агентского рабочего процесса Cortex создаёт основу для более продвинутых парадигм обслуживания, ориентированных на агентов, включая пластичное управление ресурсами, спекулятивное выполнение ветвлений рабочих процессов и многоуровневое кэширование для «состояния агента».

Исследовательский контекст и мотивация

Определение проблемы

Агентские рабочие процессы объединяют логику вывода больших языковых моделей (LLM) с итеративным использованием инструментов: модель наблюдает промежуточные результаты, размышляет, вызывает другой инструмент и повторяет процесс до решения задачи или исчерпания бюджета. Этот замкнутый цикл становится всё более важным в приложениях производственного уровня, таких как агенты преобразования естественного языка в SQL (NL2SQL).

Ограничения существующих подходов

Современные платформы обслуживания LLM имеют следующие проблемы:

1. Невосприимчивость к рабочим процессам: популярные фреймворки обслуживания LLM (такие как vLLM) рассматривают каждый этап как независимый вызов LLM с использованием планирования по принципу «первым пришёл — первым обслужен» (FCFS)
2. Отсутствие понимания структуры: существующие платформы обслуживания агентов (такие как Autellix) используют сложные стратегии приоритизации, но не понимают внутреннюю структуру рабочего процесса
3. Упущенные возможности кэширования: пять итераций улучшения одного и того же паттерна создают пять идентичных построений подсказок и пять идентичных горячих кэшей для выполнения SQL
4. Слепое планирование: планирование вызовов LLM без понимания оставшейся части рабочего процесса, игнорирование нисходящих затрат

Исследовательская мотивация

Авторы наблюдают, что единый общий пул «универсального» двигателя LLM не подходит для агентских рабочих процессов, содержащих разнородные этапы. Каждый этап (генерация SQL, выполнение, исправление ошибок) имеет различные профили задержки, требования к памяти и возможности кэширования.

Основные вклады

1. Предложена архитектура Cortex: первая платформа обслуживания с учётом рабочих процессов, основанная на изоляции этапов, предоставляющая выделенные пулы двигателей для каждого этапа рабочего процесса
2. Реализована значительная оптимизация KV-кэша: изоляция этапов существенно снижает использование памяти KV-кэша и повышает утилизацию памяти GPU
3. Устранены межэтапные помехи: восстановлены стабильные локальные модели задержки этапов, повышена предсказуемость производительности
4. Разработана фреймворк обслуживания, ориентированный на агентов: создана основа для пластичных рабочих процессов, спекулятивного выполнения и управления состоянием агента

Подробное описание методологии

Определение задачи

На примере рабочего процесса NL2SQL входными данными является запрос на естественном языке (например, «Каков объём продаж в Европе за последний квартал?»), а выходными данными является успешно выполненный результат SQL-запроса. Рабочий процесс включает:

1. Извлечение целевой схемы
2. Авторегрессивное генерирование кандидатов запросов
3. Выполнение запроса
4. Проверка результирующего набора
5. При отказе запроса — исправление и повторная попытка

Проектирование основной архитектуры

Принцип изоляции этапов

Cortex предоставляет выделенный пул двигателей для каждого этапа рабочего процесса. Пул двигателей представляет собой набор однородных рабочих процессов (например, GPU для декодирования LLM или CPU-исполнители для SQL), управляемых локальным для этапа планировщиком с собственной очередью, кэшем и стратегией масштабирования.

Компоненты системы

1. Оркестратор (Orchestrator):
   • Осведомлён о рабочих процессах, отслеживает положение каждого запроса в графе
   • Предсказывает следующий набор допустимых операторов
   • Присоединяет ключи приоритета на основе люфта SLO, селективности этапа и ожидаемого времени обслуживания
2. Уровень распределения двигателей (Engine Allocation Layer):
   • Маршрутизирует подвызовы в конкретные экземпляры пула для максимизации локальности
   • Балансирует нагрузку между репликами
   • Переупорядочивает запросы на основе приоритета
   • Выполняет контроль допуска, когда этап становится узким местом
3. Механизм заимствования ресурсов: Когда нагрузка и давление памяти достаточно низки, оркестратор может возможностно позволить совместимым этапам заимствовать неиспользуемые двигатели для снижения фрагментации и повышения утилизации.

Технические инновации

Оптимизация KV-кэша

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

Предсказуемость производительности

Изоляция этапов устраняет межэтапные помехи, нарушающие предсказуемость. Когда разнородные вызовы совместно используют двигатель, пакеты связывают их время выполнения, задерживают выпуск токенов и делают задержку вызовов LLM зависимой от партнёров по пакету.

Независимое масштабирование

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

Экспериментальная установка

Экспериментальные сценарии

Статья использует рабочий процесс NL2SQL в качестве основного экспериментального сценария, включающий два этапа LLM:

• Генератор SQL
• Исправитель ошибок SQL
• Исполнитель SQL (этап, не связанный с LLM)

Метрики оценки

• Использование памяти KV-кэша
• Общее использование памяти
• Пропускная способность системы
• Задержка хвоста

Базовые сравнения

• Решение с общим пулом двигателей: все этапы совместно используют один набор двигателей LLM
• Решение Cortex с изоляцией этапов: каждый этап использует выделенный пул двигателей

Результаты экспериментов

Основные результаты

Эффект оптимизации KV-кэша

Результаты экспериментов показывают, что при выполнении этапов LLM рабочего процесса NL2SQL в Cortex общее использование KV значительно снижается. Когда каждый этап выполняется в собственном пуле Cortex, общий объём KV явно ниже: каждый двигатель сохраняет только контекст, специфичный для его этапа.

Повышение производительности

1. Эффективность памяти: благодаря изоляции этапов избегается дублирование KV-кэша, освобождается ценная память GPU
2. Увеличение пропускной способности: восстановленная память GPU напрямую преобразуется в более высокий эффективный размер пакета
3. Улучшение задержки: более плотные задержки хвоста и более предсказуемая производительность

Проверка системных преимуществ

Эксперименты проверили три основных преимущества Cortex:

1. Улучшенное использование KV-кэша: значительное снижение использования памяти
2. Устранение межэтапных помех: восстановление стабильных локальных моделей задержки этапов
3. Возможность независимого масштабирования: поддержка детального управления ресурсами

Связанные работы

Фреймворки обслуживания LLM

• vLLM: эффективное обслуживание больших языковых моделей с использованием PagedAttention для управления памятью
• SGLang: эффективное выполнение программ структурированных языковых моделей

Платформы обслуживания агентов

• Autellix: эффективный двигатель обслуживания LLM-агентов, использующий сложные стратегии приоритизации
• HEXGEN-TEXT2SQL: планирование запросов рабочего процесса NL2SQL на основе люфта оставшегося крайнего срока и ожидаемого времени выполнения

Технические различия

Существующие платформы не осведомлены о внутренней структуре рабочего процесса; Cortex заполняет этот пробел благодаря изоляции этапов.

Выводы и обсуждение

Основные выводы

Cortex посредством простой и эффективной стратегии изоляции этапов значительно улучшает производительность обслуживания агентских рабочих нагрузок. Этот подход не только повышает эффективность использования ресурсов, но и создаёт основу для более продвинутых парадигм обслуживания, ориентированных на агентов.

Направления будущих исследований

Пластичные рабочие процессы и ресурсы

1. Адаптивность вычислений: замена тяжёлых моделей облегчёнными вариантами, когда задержка приближается к границе SLO
2. Эластичность ресурсов: использование более мощных двигателей для ускорения отстающих в паттернах веерного расширения

Спекулятивное выполнение

• Спекулятивное выполнение наиболее вероятных ветвлений в рабочем процессе
• Предварительный прогрев соответствующих двигателей или предварительное выполнение следующего шага
• Параллельное генерирование и оценка нескольких кандидатов запросов

Управление состоянием агента

• Многоуровневое «состояние агента» с промежуточными данными как первоклассными объектами
• Общий уровень в пределах рабочего процесса как структура публикации/подписки
• Преобразование повторяющихся вызовов инструментов и LLM в попадания с нулевой стоимостью

Ограничения

1. Этап прототипирования: в настоящее время остаётся доказательством концепции, требует более полной реализации и оценки
2. Ограничения сценариев: в основном использует NL2SQL в качестве примера, требует проверки на большем количестве агентских рабочих процессов
3. Управление сложностью: как разработать интерфейсы, позволяющие рабочим процессам объявлять их пластичность, остаётся открытым вопросом

Глубокая оценка

Преимущества

1. Высокая инновационность: впервые предложена архитектура обслуживания агентов с учётом рабочих процессов
2. Точное определение проблемы: точно выявлены ключевые проблемы существующих платформ обслуживания LLM
3. Простое и эффективное решение: стратегия изоляции этапов проста, но даёт значительный эффект
4. Высокая перспективность: обеспечивает чёткий путь развития для будущего обслуживания, ориентированного на агентов

Недостатки

1. Ограниченная экспериментальная проверка: в основном основана на одном сценарии NL2SQL, не хватает крупномасштабных разнообразных экспериментов
2. Недостаточно количественных результатов: диаграммы показывают тенденции, но не хватает конкретных числовых значений повышения производительности
3. Недостаточная детализация реализации: описание конкретной реализации алгоритмов планирования и стратегий распределения ресурсов недостаточно подробно
4. Неполные сравнительные эксперименты: в основном сравнивается с простым решением общего пула, не хватает сравнения с другими продвинутыми методами

Влияние

1. Академическая ценность: предоставляет новое направление исследований для области обслуживания агентов
2. Практическая ценность: решает важные проблемы в реальных производственных средах
3. Вдохновляющее значение: предоставляет ценные идеи для последующих связанных исследований

Применимые сценарии

1. Многоэтапные агентские рабочие процессы: особенно подходит для агентских приложений с чёткой разбивкой по этапам
2. Среды с ограниченными ресурсами: значительный эффект в средах с ограниченными ресурсами, такими как память GPU
3. Сценарии с высокими требованиями к производительности: производственные среды со строгими требованиями к задержке и пропускной способности

Библиография

Статья ссылается на следующую ключевую литературу:

1. vLLM: механизм управления памятью PagedAttention
2. SGLang: выполнение программ структурированных языковых моделей
3. Autellix: двигатель обслуживания LLM-агентов
4. HEXGEN-TEXT2SQL: планирование агентских рабочих процессов
5. Соответствующая литература по NL2SQL и облачным сервисам

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