Агентный ИИ в облаке: от function calling до MCP и GPU-инференса

Классический чат-бот отвечает на вопрос текстом. Агентный ИИ действует иначе: выбирает следующее действие сам, вызывает внешний инструмент, читает результат и решает, что делать дальше. Несколько итераций — без участия человека на каждом шаге.

Что такое агентный ИИ и почему облако — естественная среда для него

По данным CNCF и SlashData за Q1 2026, 71% backend-разработчиков в мире используют хотя бы одну cloud-native технологию, а 52% применяют три и более. Контейнеризация, оркестрация и API-first подход, ставшие нормой в этой среде, готовы к подключению LLM к внешним сервисам без инфраструктурной перестройки.

Ключевое отличие агентной архитектуры от обычного сервиса — цикл «наблюдение → рассуждение → действие». Каждый шаг требует нового обращения к модели и к инструменту, поэтому агентный сценарий порождает не одну пару запрос-ответ, а цепочку вызовов в реальном времени.

От function calling к единому протоколу: как LLM научились вызывать инструменты

В июне 2023 года OpenAI добавила в API function calling: модель возвращает не текст, а структурированный вызов конкретной функции с параметрами. Реализация была проприетарной — интеграция инструмента под одну модель не переносилась на другую без переписывания.

Основы паттерна были заложены раньше. Фреймворк ReAct формализовал подход, при котором LLM-агент чередует шаг рассуждения (reasoning) с шагом действия (acting): вызов внешнего инструмента и анализ полученного результата. Этот цикл лёг в основу большинства современных агентных архитектур.

Разрозненность интеграций — каждый инструмент требовал отдельного адаптера под каждую модель — создала спрос на единый протокол, который описывал бы вызов инструментов независимо от LLM-провайдера.

Model Context Protocol: единый язык между LLM и внешними инструментами

В ноябре 2024 года Anthropic представила Model Context Protocol (MCP) — открытый протокол для стандартизированного подключения LLM к внешним источникам данных и инструментам.

Архитектура MCP строится по схеме «хост — клиент — сервер». Приложение-хост со встроенной LLM подключается через клиента к MCP-серверам, а те предоставляют инструменты, ресурсы и промпты. Обмен идёт по JSON-RPC 2.0; формат запросов и ответов не зависит от транспортного слоя — stdio или HTTP/SSE.

MCP-сервер инкапсулирует доступ к конкретной системе: базе данных, файловому хранилищу, API стороннего сервиса. Модель обращается к серверу через унифицированный интерфейс и не работает напрямую с деталями реализации.

GPU-инстансы как вычислительная основа агентных пайплайнов

Инференс LLM, особенно многошаговый агентный сценарий с несколькими вызовами модели на одну задачу, требует GPU-ресурсов с предсказуемой задержкой.

На Kubernetes-платформах Device Plugin Framework даёт узлам кластера объявлять GPU как расширенный (extended) schedulable-ресурс, который запрашивается прямо в спецификации пода.

NVIDIA GPU Operator автоматизирует на кластере установку драйверов NVIDIA, device plugin для GPU и экспортёра метрик DCGM, снимая с команды ручную настройку GPU-нод.

Размещение MCP-серверов, оркестратора агента и GPU-инференса в одном облачном контуре сокращает сетевые задержки между шагами цепочки рассуждений. Каждый шаг агентного цикла обращается и к модели, и к инструменту, а задержка на сети накапливается пропорционально числу шагов.

Практическая архитектура: как собрать связку в облаке

Типовая схема строится из трёх слоёв:

1. LLM-инференс на GPU-инстансах.
2. Оркестратор агента с циклом рассуждение-действие.
3. MCP-серверы как обёртка над внешними системами.

Разделение слоёв на инференс, оркестрацию и инструменты даёт масштабировать GPU-ресурсы отдельно от логики агента: рост числа параллельных агентов не требует пропорционального роста числа MCP-серверов, и наоборот.

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