Развёртывание LLM на Google Cloud Vertex AI

Когда 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: пошаговый процесс

1. Аудит модели и инфраструктуры. Оцениваем требования к latency, throughput, подбираем GPU/TPU и тип квантизации (INT4 vs FP16).
2. Контейнеризация с vLLM/TGI. Собираем Docker-образ с optimised параметрами — health check, predict route, env vars для Vertex AI Endpoints.
3. Настройка эндпоинта и автоскейлинга. Задаём min_replica_count, max_replica_count, кастомные метрики custom.googleapis.com|model/requests_per_replica.
4. Мониторинг и алертинг. Дашборд Cloud Monitoring: latency p50/p95/p99, GPU utilization, количество токенов, error rate.
5. Документация и обучение. 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?

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])

machine_type: g2-standard-24
accelerator_type: NVIDIA_A100_80G
accelerator_count: 4

Сравнение vLLM и TGI для инференса

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,
)

Закажите консультацию — мы подберём оптимальную конфигурацию под вашу нагрузку.

MLOps: инфраструктура для обучения, деплоя и мониторинга ML-моделей

Модель обучена, метрики — F1 0.94 на валидации. Через три месяца в продакшене качество падает на 12%. Никто не знает, когда именно — нет мониторинга. Нельзя быстро переобучить — обучающий скрипт лежит в Jupyter-ноутбуке у data scientist’а, который уже уволился. Данные для ретрейна собирают руками из трёх разрозненных систем. Примерно половина проектов приходят к нам с этой болью. Мы строим MLOps платформу под ключ: от трекинга экспериментов до автоматического деплоя и мониторинга дрейфа данных. Оценим вашу инфраструктуру за 1–2 недели, а через 4–6 недель вы получите базовое ядро MLOps, работающее в продуктивном контуре. Наша команда — 10+ лет опыта в ML-инфраструктуре, более 50 внедрений.

Experiment tracking и воспроизводимость

Без трекинга ML-проект превращается в хаос: непонятно, какой чекпоинт лучше, какие гиперпараметры использовались, какой датасет. Воспроизвести результат через месяц — квест.

MLflow — open source стандарт для трекинга. Логирует параметры, метрики, артефакты (модели, графики) и код. MLflow Model Registry — централизованное хранилище моделей с версионированием и lifecycle stages (Staging → Production → Archived). Деплой через MLflow Serving или интеграция с внешними системами.

Типичная инициализация в коде:

import mlflow

mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 3e-4, "batch_size": 64, "epochs": 10})
    mlflow.log_metric("val_f1", val_f1, step=epoch)
    mlflow.pytorch.log_model(model, "model")

Это минимум. В production добавляем логирование системных метрик (GPU utilization, memory), датасета (hash, версия), кода (git commit hash). Weights & Biases — более богатый UI, collaboration features, sweep для hyperparameter optimization. MLflow — для on-premise deployment без внешних зависимостей.

DVC (Data Version Control) — версионирование данных и моделей поверх git. Данные хранятся в S3/GCS/Azure Blob, в git — только метаданные (хэши). dvc repro воспроизводит весь пайплайн от сырых данных до метрик.

Как обеспечить воспроизводимость обучения? Фиксируйте random seeds (torch.manual_seed, numpy.random.seed, random.seed) и записывайте их в метаданные эксперимента. Без этого дебаггинг нерегулярных результатов — боль. Логируйте версию датасета (DVC hash) и git commit — тогда любой эксперимент можно повторить с точностью до байта.

Оркестрация пайплайнов: Kubeflow, Airflow, Prefect

Когда нужен оркестратор пайплайнов? Скрипт обучения на 100 строк в cron — нормально для простых задач. Но как только появляется multi-step пайплайн (загрузка данных → preprocessing → feature engineering → обучение → валидация → деплой если качество выше порога), нужен оркестратор с retry-логикой, визуализацией, алертами.

Kubeflow — Kubernetes-native оркестратор для ML (см. Wikipedia). Каждый шаг — Docker-контейнер. Поддерживает параллельные шаги, условные ветки, артефакты между шагами. Интегрируется с Katib (AutoML), KServe (serving), Feast (feature store).

Apache Airflow — более общий DAG-оркестратор. Широкая экосистема операторов (S3, Spark, DBT, Kubernetes). Проще развернуть, если уже есть Airflow в компании.

Prefect / Metaflow — меньше boilerplate. Prefect 2.x с декораторами @flow и @task — быстрый старт для небольших команд.

Типичная архитектура обучающего пайплайна на Kubeflow:

1. Data ingestion component — забирает данные из S3/БД, валидирует схему через Great Expectations
2. Preprocessing component — трансформации, normalization, train/val/test split
3. Training component — обучение на GPU, логирование в MLflow
4. Evaluation component — вычисление метрик, сравнение с baseline в Model Registry
5. Conditional deployment — деплой только если новая модель лучше текущей на >2% F1

Каждый component — отдельный Docker-образ. Пайплайн версионируется в git. Запуск по расписанию (ретрейнинг раз в неделю на новых данных) или вручную.

Model Registry и управление жизненным циклом

Model Registry — не просто хранилище чекпоинтов. Это централизованная система, которая знает:

• Какая модель сейчас в продакшене (и с какими метриками)
• История всех версий с параметрами обучения
• Метаданные: датасет, git commit, результаты валидации
• Lifecycle stage: None → Staging → Production → Archived

MLflow Model Registry — стандарт. Для enterprise — Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Azure ML Model Registry.

Продвижение модели через стейджи: автоматически переводим модель в Staging после успешного прохождения eval, затем ручное или автоматическое (при A/B тесте) продвижение в Production. Rollback — переключение на предыдущую Production-версию за секунды.

Serving: от FastAPI до Triton Inference Server

Простой случай. FastAPI + PyTorch/ONNX на одном сервере — 80% production ML deployments именно так. Достаточно для большинства задач с нагрузкой до 100 req/s.

from fastapi import FastAPI
import onnxruntime as ort

app = FastAPI()
session = ort.InferenceSession("model.onnx", providers=["CUDAExecutionProvider"])

@app.post("/predict")
async def predict(request: PredictRequest):
    inputs = preprocess(request.text)
    outputs = session.run(None, {"input_ids": inputs})
    return {"label": postprocess(outputs)}

Triton Inference Server — production-стандарт для высоких нагрузок (500+ req/s). Dynamic batching, concurrent model execution, model ensemble. Поддерживает TensorRT, ONNX, PyTorch TorchScript, TensorFlow SavedModel.

KServe — Kubernetes-native ML serving с autoscaling, canary deployments, A/B testing из коробки. Scale-to-zero для неактивных моделей — экономия на инфраструктуре до 40% (более 1.2 млн рублей в год для проекта с 10 моделями).

Мониторинг: data drift, model drift, инфраструктурные метрики

Мониторинг — то, что обычно делают в последнюю очередь и о чём жалеют в первую. Три уровня.

Инфраструктурный мониторинг. Latency (P50/P95/P99), throughput (req/s), error rate (4xx, 5xx), GPU/CPU utilization. Prometheus + Grafana — стандарт. Алерт при P99 latency > threshold или error rate > 1%.

Data drift мониторинг. Распределение входных данных меняется со временем. Детектируем через PSI (Population Stability Index) для числовых признаков: PSI > 0.2 — сильный дрейф. Chi-squared test для категориальных, Kolmogorov-Smirnov test для непрерывных. Evidently AI — open source библиотека с готовыми дрейф-тестами.

Model drift мониторинг. Если есть ground truth с задержкой (например, через неделю знаем конверсию) — мониторим реальные метрики. Если нет — surrogate метрики: распределение prediction scores, доля confident predictions.

Alerting. Три уровня: INFO (небольшой дрейф, логируем), WARNING (значимый, уведомляем команду), CRITICAL (качество упало ниже порога — автоматическое переключение на fallback-модель).

Почему важен мониторинг дрейфа данных? Без него вы узнаёте о деградации модели только по жалобам пользователей или звенящему SLA. Алерт о дрейфе позволяет переобучить модель заранее, до того как ошибки начнут приносить убытки. В одном из наших проектов мониторинг PSI выявил дрейф через 2 дня после изменения источника данных — это спасло кампанию с бюджетами на 2 млн рублей.

Feature Store

Feature Store решает проблему training-serving skew. Если preprocessing во время обучения и инференса реализован в двух разных местах — расхождение неизбежно.

Когда нужен Feature Store?

• Несколько моделей используют одни и те же признаки
• Признаки вычисляются из потоковых данных (real-time)
• Большая команда с разными людьми на feature engineering и model training

Feast — open source Feature Store. Офлайн store (S3 + Parquet) для обучения, онлайн store (Redis, DynamoDB) для low-latency инференса. Feature definitions как код, materialization job синхронизирует офлайн → онлайн.

Tecton (коммерческий), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варианты с меньшим ops overhead.

CI/CD для ML

ML CI/CD — обычный CI/CD плюс специфичные ML-шаги.

ML-специфичные checks в CI:

• Проверка воспроизводимости: запустить обучение с фиксированным seed, результат должен совпадать
• Data validation: Great Expectations или Pandera на schema/distribution checks
• Model performance check: автоматический eval на holdout, блокировать merge если деградация > порога
• Latency regression test: inference должен укладываться в SLA

GitOps для деплоя. Merge в main → CI запускает обучение → eval → если проходит → автоматический деплой в Staging → smoke tests → ручное продвижение в Production или автоматическое при успешном canary.

Инструменты: GitHub Actions / GitLab CI для CI, ArgoCD для GitOps-деплоя на Kubernetes.

Что входит в разработку MLOps-платформы

Мы предоставляем полный цикл работ, документацию и обучение команды.

Итоговый срок от аудита до полноценной MLOps-платформы: 3–5 месяцев. Также возможен поэтапный запуск: базовый уровень (трекинг + serving) за 4–6 недель.

Стоимость рассчитывается индивидуально под объём данных, количество моделей и требования к инфраструктуре. Закажите аудит MLOps-инфраструктуры — получите roadmap за 1–2 недели. Свяжитесь с нами для оценки вашего проекта — мы пришлём предварительный расчёт за 2 рабочих дня.

Обратите внимание: гарантия на архитектурные решения — 12 месяцев. Предоставляем сертификаты интеграции с основными облачными провайдерами (AWS, GCP, Azure). За время работы мы не потеряли ни одного клиента после первого внедрения — опыт 50+ успешных MLOps-проектов говорит сам за себя. Получите консультацию по построению MLOps платформы уже сегодня.