Перейти к содержимому
Экосистема AI Vibe
← Назад к AI Vibe News

Редакция 14 августа 2026 г.

Разборы

Managed inference в Google Cloud: агентная платформа Gemini и Cloud Run

Managed inference в Google Cloud: агентная платформа Gemini и Cloud Run

Соло-разработчик, который тащит агента с MCP-серверами в прод, рано или поздно упирается не в промпт, а в границы слоёв: где живёт оркестрация и память, где — ваш код и MCP, а где — вызов модели. Enterprise-гайд GDG на Dev.to разбирает гибридную схему managed inference: Gemini Enterprise Agent Platform (ранее Vertex AI) плюс Cloud Run — с архитектурой, кодом на ADK, деплоем и security по шагам. Для тех, кто собирает production-паттерн вокруг агентов, а не «ещё один backend без ИИ», это чек-лист, который экономит недели на расхождениях между runtime и inference.

Три слоя вместо монолита: агент, inference и ваш код

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

Поток запросов выглядит так:

  1. Клиент или Web UI бьёт в Cloud Run Service — фронт приложения, эндпоинты, внешние tools.
  2. Cloud Run обращается к Agent Runtime платформы Gemini Enterprise Agent Platform — оркестрация, intent analysis, long-term memory.
  3. Agent Runtime уходит в Managed Inference / Model Garden — модели Gemini 3.x Pro или Flash.
Слой Зона ответственности
Cloud Run Бизнес-логика, IAP-защищённые эндпоинты, внешние API, MCP servers — «всё, что вы строите»
Agent Platform Состояние агента, reasoning в managed runtime — «всё, что Google запускает за вас»
Managed Inference Выполнение inference на выбранных моделях Gemini

Зачем так делить: spike на веб-фронте не должен трогать model layer; модели можно менять без redeploy приложения; граница безопасности — клиенты общаются только с Cloud Run, не напрямую с моделью. Для соло-команды без отдельного ML-ops это снимает вопрос «кто чинит, когда упал inference, а UI жив».

Агент в коде: ADK и docstring как контракт tool

Второй блок — не абстрактная схема, а code-first определение агента через Agent Development Kit (ADK). Стек: Google Cloud project с billing, gcloud, Python 3.10+, установка google-adk.

Ключевая идея ADK: tools — обычные Python-функции; фреймворк читает docstring, чтобы решить, когда и как вызвать tool. Docstring здесь — часть логики агента, не «комментарий для людей».

from google.adk.agents import Agent

def call_internal_business_system(query: str) -> str:
    """Invokes secure business workflows deployed on Cloud Run."""
    return "Data retrieved from secure internal backend."

root_agent = Agent(
    name="enterprise_inference_agent",
    model="gemini-3.5-flash",
    instruction="You are a data processing assistant using managed inference.",
    tools=[call_internal_business_system],
)

Поля агента: name — идентификатор в логах и traces; model — модель для reasoning (Flash быстрее и дешевле, Pro — для сложного reasoning); instruction — system prompt; tools — функции, которые модель вызывает при совпадении с docstring.

Важное предупреждение: Gemini 1.0 и 1.5 (включая gemini-1.5-pro) сняты с поддержки и отдают errors — target нужно ставить на актуальные gemini-3.5-flash, gemini-3.6-flash или Gemini 3.x Pro из Model Garden. Для разработчика, привыкшего к локальным rules и skills в IDE, параллель очевидна: контракт tool задаётся текстом в коде, а не отдельным YAML — но в проде за этим стоит managed runtime, а не ваш ноутбук.

Деплой: IAM, который все забывают, и одна команда

Архитектура без рабочего деплоя — диаграмма в Notion. Материал начинается с IAM: сервисы в GCP по умолчанию не доверяют друг другу, и инстансу Cloud Run нужно явное разрешение на endpoints Agent Platform.

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="serviceAccount:YOUR_RUN_SA@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/aiplatform.user"

Этот шаг назван тем, что чаще всего забывают: permission errors после deploy почти всегда сводятся к роли roles/aiplatform.user для service account Cloud Run.

Сборка и выкат — одной командой:

adk deploy cloud_run \
    --project="YOUR_PROJECT_ID" \
    --region="us-central1" \
    --service_name="agent-inference-backend" \
    path/to/your/agent

Команда собирает container image, пушит в Artifact Registry и создаёт или обновляет Cloud Run service. Альтернатива — agents-cli: agents-cli scaffold enhance --deployment-target cloud_run для scaffold конфига деплоя. Регион us-central1 в примере — placeholder гайда, не универсальное требование.

Минимальный стартовый путь: one-tool agent + adk deploy cloud_run + тестовый запрос; остальное наращивать инкрементально.

MCP, mTLS и выбор режима inference

Security здесь — не приложение к архитектуре, а часть production path. Для human-in-the-loop dashboards — Identity-Aware Proxy (IAP) на Cloud Run endpoints: Google identity проверяется до входа в код. Для agent-to-tool трафика, включая MCP servers на Cloud Run, — Agent Gateway: уникальная identity на агента и end-to-end mTLS при вызове tools.

Observability: встроенный OpenTelemetry, Cloud Trace по умолчанию для CLI-based deployments; визуализация DAG execution — reasoning steps, model calls, tool invocations — для отладки «странных ответов» агента.

По режимам inference после «plumbing» два primary сценария:

Режим Когда Пример
Online Нужен ответ сейчас, UI с низкой задержкой Синхронные вызовы с Cloud Run front end к deployed agent — чат, tool calls, step-by-step reasoning
Batch High-volume, latency не критична Async batch prediction через Agent Platform SDK; результаты в Cloud Storage; compute teardown после job

Batch обычно дешевле на запрос (качественно, без цифр); online — только для по-настоящему интерактивных сценариев. Для соло-разработчика с ограниченным бюджетом GCP это практичный фильтр: не гонять chat UI там, где хватит ночной пакетной классификации.

Итог: managed inference здесь — способ выложить AI-приложение без self-managed GPUs и model servers. Связка Agent Platform + Cloud Run отделяет оркестрацию и inference от вашего кода и MCP-серверов; ADK фиксирует агента в Python; IAM → deploy → IAP/mTLS/OTel закрывают путь в прод. Сравнительных бенчмарков с альтернативами и цен в материале нет — опирайтесь на собственные замеры нагрузки.

Источники