ИИ-агентам нужны CPU не меньше GPU — куда уходит нагрузка

|Автор: Редакция QUASA|5 мин чтения| 8
ИИ-агентам нужны CPU не меньше GPU — куда уходит нагрузка

ИИ-агенту нужны оба типа вычислений: GPU ускоряет обработку запроса крупной моделью и генерацию ответа, а CPU выполняет значительную часть работы вокруг модели — поиск, вызовы инструментов, сбор контекста, проверки и управление состоянием. Поэтому быстрый GPU сам по себе не гарантирует быстрого ответа агента. Слова «не меньше» здесь означают важность процессорной части, а не равенство затрат, числа устройств или времени их работы.

Масштаб спроса на эту часть инфраструктуры иллюстрирует сообщение Akamai: соглашение с Anthropic предусматривает обязательства на $11,6 млрд за семь лет и, по формулировке компании, поддержит рост процессорных нагрузок Anthropic. Контракт не раскрывает устройство отдельного агента и не позволяет вычислить универсальное соотношение CPU и GPU. Но он показывает, что мощности для задач вне ускорителя могут быть предметом крупного инфраструктурного соглашения.

Путь одного агентного запроса

Рекомендации Amazon EKS относят выполнение инструментов, сбор контекста, векторный поиск, защитные проверки, валидацию ответа и управление памятью агента к процессорной работе вокруг вызова модели. Для условного агента, отвечающего на вопрос по базе документов, распределение выглядит так:

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

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

Почему нагрузка остаётся на CPU

Вызов инструмента состоит не только из решения модели его вызвать. Приложению нужно отправить запрос к API или базе данных, дождаться результата, разобрать ответ и подготовить данные для следующего шага. Если инструменты вызываются последовательно, задержки складываются; более быстрый GPU не ускорит ожидание внешнего сервиса.

Поиск тоже занимает отдельное место в конвейере. Документы разбивают на фрагменты и индексируют, а при запросе находят подходящие записи, отбирают их и укладывают в доступный объём контекста. Создание векторных представлений может выполняться на CPU или GPU в зависимости от модели и нагрузки, но поиск и подготовку результатов всё равно приходится учитывать как самостоятельные службы с требованиями к процессору, памяти и сети.

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

Когда вычисления модели требуют GPU

GPU становится определяющим ресурсом, когда крупная модель должна отвечать быстро или одновременно обслуживать много запросов. На результат влияют память ускорителя, длина контекста, очередь перед моделью и скорость генерации. Добавление CPU не снимет очередь внутри модельной службы, если она ограничена ускорителем.

Небольшую квантованную модель для классификации, выбора инструмента или извлечения полей можно разместить на CPU. Для крупной модели с жёстким требованием к задержке обычно выбирают GPU; при пакетной обработке допустимое время ожидания может изменить решение. Квантование уменьшает объём весов в памяти, но его влияние на качество зависит от конкретной модели и задачи.

Матрица выбора облачных ресурсов

Выбирать вычисления полезно для каждого участка конвейера отдельно. Следующие условия задают направление выбора, но не обещают, что один тип оборудования всегда окажется дешевле:

  • Размер модели: небольшая квантованная модель делает CPU возможным вариантом; крупная модель с длинным контекстом и быстрой генерацией склоняет выбор к GPU. В обоих случаях нужно учитывать память, занятую моделью и текущими запросами.
  • Допустимая задержка: пакетная обработка позволяет рассматривать CPU даже для некоторых модельных задач. Для интерактивного ответа важны время ожидания в очереди и скорость генерации, а не только время поиска.
  • Частота запросов: редкие обращения к модели при множестве вызовов инструментов сильнее нагружают процессорные службы. Постоянный поток генерации повышает ценность загруженного ускорителя; среднее число запросов может скрывать пиковую очередь.
  • Тип задачи: маршрутизацию, поиск, подготовку данных и управление состоянием можно выделить в CPU-службы. Большую модель размещают отдельно на GPU; для небольшой модели сравнивают оба варианта с учётом качества ответа.

Такое разделение позволяет наращивать службы независимо. Если замедлился поиск, дополнительные ускорители не исправят его задержку; если запросы ждут доступа к модели, расширение поискового слоя тоже не поможет. Стоимость зависит от загрузки обеих частей, памяти, передачи данных и требований к времени ответа.

Где возникает очередь при масштабировании

Рекомендации Google Cloud связывают допустимое число одновременных запросов к службе с GPU с числом экземпляров модели, их параллельной обработкой, пакетированием и объёмом работы вне GPU. Слишком высокий предел может заставить запросы ждать внутри экземпляра; слишком низкий оставит ускоритель недогруженным и вызовет лишнее масштабирование.

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

Читайте также:

Поделиться:

Подпишитесь на рассылку

Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.

0