Open-weights Gemma, Google ADK и GPU на Cloud Run: когда агенту нужен не чат, а SecOps-контур

Редакция 17 октября 2026 г.

Три развилки решают, получится ли у соло-разработчика «продакшен-агент» или очередной демо-скрипт: локальный прототип на Ollama, serverless-инференс на GPU в облаке и жёсткие guardrails до вызова tools. В лонгриде разобран reference blueprint CloudGuard: enterprise-агента SecOps и FinOps на открытых весах Gemma, Google ADK и Google Cloud, с открытым кодом и воспроизводимым запуском в Cloud Shell. Для тех, кто собирает агентов в IDE и не хочет оставить модели путь к продакшену без IAM и RBAC, речь не про «подключить API», а про полный цикл от LlmAgent до QLoRA на Vertex.

ADK и Gemma: один агент, два бэкенда через `.env`

Стартовая точка: Python-стек вокруг Google ADK (google-adk>=1.0.0). Корневой LlmAgent с LiteLlm в cloudguard_agent/agent.py, tools в tools.py, память в memory.py, ограничения в guardrails.py. Режим инференса переключается переменной GEMMA_BACKEND_MODE: local_ollama (Ollama на localhost:11434, в примерах ollama_chat/gemma3:4b и gemma3:27b) или cloud_run_vllm, OpenAI-совместимый endpoint vLLM на Cloud Run с model id вроде google/gemma-3-27b-it.

Для соло-workflow это практичный паттерн: отладить tool calls и промпт на ноутбуке без оплаты GPU, затем поднять тот же ADK-агент на managed-инференсе. В репозитории github.com/RobinaMirbahar/cloudguard-gemma-agent лежат модули, deploy/ с Dockerfile.vllm, скрипты seed/eval и golden dataset tests/eval_dataset.json под ADK Eval.

Инструменты агента заточены под операционку, а не под «ответь красиво»: get_service_incident, list_active_alerts, check_gpu_quota_and_cost, mitigate_runaway_workload, с жёсткими docstring-правилами для Gemma (явные Args:, форматы вроде INC-YYYY-NNNN). Данные: Cloud Firestore или локальное зеркало схемы через USE_LOCAL_MOCK_DB; долгая память: Enterprise Memory Bank (в примере postmortem MEM-2026-014).

Масштабирование open-weights: L4, FUSE и scale-to-zero

Второй блок схемы: serverless GPU scaling. Gemma на Cloud Run через vLLM, веса с Cloud Storage FUSE (mount /mnt/models), без запекания модели в образ. В фрагменте gcloud run deploy: GPU 1× nvidia-l4, --min-instances=0, --max-instances=3, concurrency 8, 8 CPU, 32Gi RAM, --no-allow-unauthenticated, отдельный service account invoker. vLLM включает --enable-auto-tool-choice и parser pythonic: это про агентные tool calls в проде, не про одиночный completion.

Оценки VRAM на L4 (24 GB): порядка 8.4 GB для gemma-3-4b-it в bfloat16 и ~54 GB для unquantized gemma-3-27b-it; 4-bit AWQ для 27B, по расчётам в blueprint, влезает на тот же L4. Альтернатива: Vertex AI Model Garden с OpenModel("google/gemma3@gemma-3-4b-it"), машина g2-standard-12, один NVIDIA_L4. Семейство Gemma 3 перечислено явно: gemma-3-4b-it, gemma-3-12b-it, gemma-3-27b-it и соответствующие id на Hugging Face / Vertex.

FinOps в демо: не прайс GCP, а симулированная телеметрия агента (пример сэкономленных $36.12/hr после mitigation в сценарии CloudGuard). Для инженера важнее механизм: tool check_gpu_quota_and_cost смотрит квоты NVIDIA L4 / RTX PRO 6000 и процент monthly budget по регионам вроде us-central1 и europe-west4.

Governance, eval и QLoRA: гейты до продакшена

Третий блок: security и governance. Gate 1: IAM, только cloudguard-agent-sa с roles/run.invoker. Gate 2: callback before_model редактирует GCP API keys и bearer tokens, блокирует сигнатуры prompt injection (в духе Model Armor). Gate 3: before_tool RBAC, политика POL-PROD-MUTATION-001: mitigate_runaway_workload в production без роли sre-incident-commander получает DENIED. В system prompt зафиксирован запрет автоматического scaling/termination в production без эскалации.

Сценарии CloudGuard: DevOps/SRE читают инциденты из Firestore, сверяются с memory bank, remediation уходит в staging; regulated-кейсы опираются на open-weights Gemma в своём проекте и IAM. В security-тестах blueprint: redaction сработал, prod scale заблокирован, injection помечен как BLOCKED. Для vibe-coding с агентами это напоминание: skills и rules в IDE не заменят политики на границе tool call.

Четвёртый слой той же схемы: testing и optimization. ADK Eval (scripts/run_eval.py, dataset tests/eval_dataset.json) считает Tool Trajectory (tool_trajectory_avg_score) и Response Factuality (response_match_score); в таблице сравнения 5/5 cases PASS, средние 1.00 при порогах 1.00 и 0.85, плюс OpenTelemetry в Google Cloud Trace (gen_ai.*, adk.eval.*). Unit-тесты tool calls в CI/CD продолжают ту же идею: агент не «готов», пока траектория не детерминирована на golden set.

Специализация: QLoRA на Vertex AI (prepare_and_verify_lora.py, finetuning.py), база google/gemma-3-4b-it, параметры r=16, lora_alpha=32, accelerator NVIDIA_L4; адаптер cloudguard-sre-lora-v1 на GCS с hot-load в vLLM (--enable-lora). Сравнение конфигов (self-reported, не независимый бенчмарк):

Конфиг	Tool trajectory	P95 latency	VRAM
gemma-3-4b-it zero-shot	0.78	48.2ms	8.4 GB
gemma-3-27b-it zero-shot	1.00	144.1ms	54.0 GB
gemma-3-4b-it + cloudguard-sre-lora-v1	1.00	51.4ms	8.9 GB

4B + LoRA догоняет trajectory 27B при меньшей latency и VRAM на одном L4. Критерий «production-ready» здесь: связка private IAM, guardrails, eval gates в CI/CD и observability, а не один числовой SLA. Текст лицензии open-weights в исходном лонгриде не процитирован; условия смотрите по ссылке на обзор Gemma на ai.google.dev/gemma.

Что перенести в Cursor, Ollama и свой ADK-стек

Шесть этапов lifecycle (Build → Connect → Scale → Govern → Optimize → Specialize) замыкают обещание «production-ready open-weights AI agents». Если вы уже крутите агентов в Cursor или локальном Ollama, переносимый кусок: не бренд облака, а дисциплина. JSON Schema для tools, eval до релиза, RBAC на опасные функции, переключатель local/cloud в одном ADK-агенте. Официальные точки входа: ADK, ADK Eval, GPU на Cloud Run, Gemma на Vertex.

У публикации на Dev.to на момент снятия ленты мало публичных реакций; для объёма (~21 мин чтения по метке площадки) это скорее «ещё не разошлось», чем показатель качества. Для инженера смысл в открытом репозитории и воспроизводимости в Cloud Shell.

Источники

Основной материал (Dev.to, опубликован 16 октября 2026): Building Production-Ready Open-Weights AI Agents with Gemma, Google ADK, and Cloud Run GPUs — дата доступа: 2026-10-17.
Код и манифесты CloudGuard: github.com/RobinaMirbahar/cloudguard-gemma-agent — упомянут в том же посте; дата доступа: 2026-10-17.
Обзор open-weights Gemma (лицензия и условия — по первоисточнику Google): ai.google.dev/gemma — ссылка из поста; дата доступа: 2026-10-17.