Коли Vertex AI стає вузьким місцем
Ми займаємося деплоєм LLM на Vertex AI вже 5+ років і знаємо, чому стандартний Model Garden не справляється з високонавантаженими системами. На практиці ви стикаєтеся з холодним стартом ендпоінту, неефективним автоскейлінгом і неконтрольованим зростанням білінгу за GPU. Для SaaS-продукту з p99 latency менше 500 мс потрібен кастомний образ з vLLM, TGI або Triton. Ми використовуємо vLLM з --enable-prefix-caching і --block-size=16 — це дає до 3x приросту throughput на повторюваних промптах.
За 50+ проєктів ми накопичили практику, як перетворити Vertex із чорної скриньки на передбачувану платформу. На одному проєкті для фінансового трейдингу ми знизили холодний старт з 12 секунд до 300 мс, утримуючи одну репліку активною. Економія на GPU за рахунок правильної квантизації склала 35%.
Чому стандартний Model Garden не підходить для високонавантажених систем?
Готові моделі з Model Garden розгортаються однією командою, але ви втрачаєте контроль над розміром батча, max-model-len, квантизацією та вибором скедулера. Для високих навантажень потрібен кастомний образ з TGI або Triton. vLLM з --enable-prefix-caching дає до 3x приросту throughput на повторюваних промптах.
Як ми розгортаємо LLM: покроковий процес
- Аудит моделі та інфраструктури. Оцінюємо вимоги до latency, throughput, підбираємо GPU/TPU та тип квантизації (INT4 vs FP16).
- Контейнеризація з vLLM/TGI. Збираємо Docker-образ з optimised параметрами — health check, predict route, env vars для Vertex AI Endpoints.
- Налаштування ендпоінту та автоскейлінгу. Задаємо
min_replica_count,max_replica_count, кастомні метрикиcustom.googleapis.com|model/requests_per_replica. - Моніторинг та алертинг. Дашборд Cloud Monitoring: latency p50/p95/p99, GPU utilization, кількість токенів, error rate.
- Документація та навчання. Runbook для розробників, terraform-конфігурація для повторюваного деплою.
Орієнтовні терміни: від 7 до 14 днів. Вартість розраховується індивідуально.
Мінімізація холодного старту
Холодний старт виникає, коли ендпоінт масштабується до нуля або при першому виклику після простою. Vertex AI не вміє попередньо завантажувати модель у пам'ять. Ми обходимо це двома способами: налаштовуємо min_replica_count=1 для критичних сервісів (невелика додаткова вартість) або використовуємо warm-up запити через Cloud Scheduler.
# Прогрів ендпоінту кожні 30 секунд from google.cloud import aiplatform import requests def warm_endpoint(endpoint_name: str): warm_payload = {"prompt": "ping", "max_tokens": 1} # виклик rawPredict response = requests.post( endpoint_name, json=warm_payload, headers={"Authorization": f"Bearer {token}"} ) В одному проєкті для фінансового трейдингу ми знизили холодний старт з 12 секунд до 300 мс — просто тримали одну репліку активною та додали keep-alive на стороні клієнта. Зв'яжіться з нами, щоб обговорити ваш сценарій.
Що обрати для інференсу: Cloud TPU чи GPU?
| Характеристика | TPU v5e (8-чип) | NVIDIA A100 (80GB, 1x) |
|---|---|---|
| Throughput (токенів/с) | ~4500 (Llama 3 8B, batch=64) | ~2100 |
| Вартість | Вище за годину | Нижче за годину |
| Доступність у Vertex | Тільки us-central2-b | Багато регіонів |
| Складність налаштування | Висока (JAX, MaxText) | Середня (PyTorch, CUDA) |
Tensor Processing Unit — спеціалізований чип Google. Внутрішні тести на Llama 3 8B з batch=64.
TPU v5e дає приблизно в 2 рази більше throughput на долар для великих батчів, але прив'язує до зони us-central2-b. Для production з мультирегіональною HA рекомендуємо GPU або гібрид: TPU для пакетної обробки, GPU для онлайн-інференсу.
Як налаштувати автоскейлінг та моніторинг?
Vertex AI автоматично публікує метрики в Cloud Monitoring, але їх недостатньо. Ми додаємо кастомні метрики: кількість згенерованих токенів, відсоток кешованих звернень (prefix_cache_hit_rate), час першого токена (TTFT). Це дозволяє швидко виявляти деградацію моделі після оновлення.
# Кастомна метрика в Cloud Monitoring from google.cloud import monitoring_v3 client = monitoring_v3.MetricServiceClient() series = monitoring_v3.TimeSeries( metric={"type": "custom.googleapis.com/model/tokens_per_second"}, resource={"type": "global"}, points=[{ "interval": {"end_time": {"seconds": now}}, "value": {"double_value": tokens_per_sec} }] ) client.create_time_series(name=project_name, time_series=[series]) Приклад конфігурації для Llama 3 70B
machine_type: g2-standard-24 accelerator_type: NVIDIA_A100_80G accelerator_count: 4 Порівняння vLLM та TGI для інференсу
| Параметр | vLLM | TGI |
|---|---|---|
| Throughput (batch=1) | ~1200 tok/s | ~1000 tok/s |
| Підтримка prefix caching | Так | Обмежена |
| Гнучкість кастомізації | Висока | Середня |
vLLM краще TGI в 1.2 раза по throughput для одиночних запитів і має більш просунуте кешування.
Що входить в роботу
- Аудит моделі та інфраструктури — аналіз вимог, підбір GPU/TPU, рекомендації щодо квантизації.
- Контейнеризація — збірка Docker-образу з vLLM/TGI, налаштування health check та predict route.
- Деплой на Vertex AI Endpoints — налаштування автоскейлінгу, кастомних метрик та моніторингу.
- Документація — runbook для розробників, terraform-конфігурація для повторюваного деплою.
- Навчання команди — передача знань з експлуатації та алертингу.
- Технічна підтримка — 2 тижні пост-деплойного супроводу, гарантія стабільної роботи під навантаженням.
Чому варто обрати нас
- 5+ років досвіду в MLOps та деплої LLM
- 50+ розгорнутих моделей, включаючи Llama 3, Mistral, Gemma, Qwen
- Сертифіковані спеціалісти Google Cloud (Professional ML Engineer)
- Повний супровід: від вибору моделі до експлуатації, гарантуємо стабільну роботу
Ви можете заощадити до 40% витрат на GPU при правильній конфігурації автоскейлінгу та квантизації. Отримайте консультацію щодо вашого проєкту — ми оцінимо оптимальну архітектуру деплою та розрахуємо бюджет.
Приклад деплою через Vertex AI Endpoints
from google.cloud import aiplatform aiplatform.init(project="my-project", location="us-central1") # Завантаження моделі з GCS model = aiplatform.Model.upload( display_name="llama3-8b-vllm", artifact_uri="gs://my-bucket/models/llama3-8b/", serving_container_image_uri="us-docker.pkg.dev/vertex-ai/prediction/pytorch-gpu.2-2:latest", serving_container_command=[ "python", "-m", "vllm.entrypoints.openai.api_server", "--model=/gcs/models/llama3-8b/", "--tensor-parallel-size=1", "--max-model-len=8192", "--host=0.0.0.0", "--port=8080" ], serving_container_ports=[{"containerPort": 8080}], serving_container_health_route="/health", serving_container_predict_route="/v1/completions", serving_container_environment_variables={ "TRANSFORMERS_CACHE": "/gcs/hf_cache/", } ) # Деплой endpoint endpoint = aiplatform.Endpoint.create(display_name="llama3-8b-endpoint") model.deploy( endpoint=endpoint, deployed_model_display_name="llama3-8b-v1", machine_type="g2-standard-12", # 1x L4 GPU accelerator_type="NVIDIA_L4", accelerator_count=1, min_replica_count=1, max_replica_count=10, # автоскейлінг traffic_percentage=100, ) Замовте консультацію — ми підберемо оптимальну конфігурацію під ваше навантаження.