Налаштування балансування навантаження між GPU-інстансами

Як відсутність балансування GPU вбиває latency LLM-сервісу

Уявіть: ви запустили чотири GPU-інстанси з vLLM, але 80% запитів йде на перший сервер. Інші простоюють, а користувачі скаржаться на таймаути. Причина — не налаштоване балансування навантаження. Для LLM це критично: один довгий запит на 4000 токенів може заблокувати сервер на хвилину, поки інші — idle. У результаті p99 latency злітає до 30 секунд, а утилізація GPU падає до 25%. Типовий кластер з 4 GPU без балансування втрачає до 50% пропускної здатності.

Грамотне балансування дозволяє скоротити витрати на GPU-інфраструктуру до 40% за рахунок рівномірної утилізації. Середня економія GPU-годин після впровадження — 30% за тієї ж навантаження. P99 latency знижується в 1.7 рази порівняно з Round Robin. Наприклад, для кластера з 4 GPU економія становить до $5000 на місяць. Якщо ви зіткнулися з подібними проблемами, зв'яжіться з нами — ми підберемо оптимальну конфігурацію під ваш сценарій.

Порівняння алгоритмів балансування для LLM

Документація vLLM: метрики для балансування

Least Pending Tokens — оптимальний вибір для сервісів з різнорідним навантаженням. Він використовує Prometheus-метрики vLLM (vllm:num_requests_waiting), щоби вибирати найменш завантажений інстанс. Наш досвід показує, що Least Pending Tokens кращий за Round Robin в 1.7 рази за p99 latency.

Приклад: Nginx з health checks і кастомний балансувальник

Нижче — базова конфігурація Nginx для upstream з чотирьох vLLM-серверів, з active health checks і таймаутами для streaming.

upstream vllm_cluster {
    least_conn;

    server 10.0.1.10:8000 max_fails=3 fail_timeout=30s weight=1;
    server 10.0.1.11:8000 max_fails=3 fail_timeout=30s weight=1;
    server 10.0.1.12:8000 max_fails=3 fail_timeout=30s weight=1;
    server 10.0.1.13:8000 max_fails=3 fail_timeout=30s weight=1;

    keepalive 100;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}

server {
    listen 443 ssl http2;
    server_name llm-api.internal;

    location /v1/ {
        proxy_pass http://vllm_cluster;
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # Timeout для довгих streaming відповідей
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
        proxy_connect_timeout 5s;

        # Streaming: вимикаємо буферизацію
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding on;

        # Circuit breaker
        proxy_next_upstream error timeout http_500 http_502 http_503;
        proxy_next_upstream_tries 2;
        proxy_next_upstream_timeout 10s;
    }

    location /health {
        proxy_pass http://vllm_cluster/health;
    }
}

Якщо потрібен більш інтелектуальний вибір бекенда — пишемо кастомний балансувальник на FastAPI, що опитує метрики в реальному часі.

from fastapi import FastAPI, Request
import httpx
import asyncio

class LLMLeastPendingBalancer:
    def __init__(self, backends: list[str]):
        self.backends = {url: {"pending": 0, "healthy": True} for url in backends}
        self.client = httpx.AsyncClient(timeout=300)

    async def get_backend(self) -> str:
        """Вибираємо backend з найменшою кількістю pending токенів."""
        healthy = {url: info for url, info in self.backends.items() if info["healthy"]}
        if not healthy:
            raise RuntimeError("No healthy backends")

        metrics = await self._fetch_metrics(list(healthy.keys()))
        best = min(metrics.items(), key=lambda x: x[1].get("vllm_num_requests_waiting", 0))
        return best[0]

    async def _fetch_metrics(self, backends: list[str]) -> dict:
        tasks = [self._get_backend_queue(url) for url in backends]
        results = await asyncio.gather(*tasks, return_exceptions=True)
        return {url: result for url, result in zip(backends, results)
                if not isinstance(result, Exception)}

    async def _get_backend_queue(self, url: str) -> dict:
        response = await self.client.get(f"{url}/metrics")
        for line in response.text.split('\n'):
            if line.startswith('vllm:num_requests_waiting'):
                return {"vllm_num_requests_waiting": float(line.split()[-1])}
        return {"vllm_num_requests_waiting": 0}

    async def forward(self, request: Request) -> httpx.Response:
        backend = await self.get_backend()
        url = f"{backend}{request.url.path}"
        self.backends[backend]["pending"] += 1
        try:
            return await self.client.request(
                method=request.method,
                url=url,
                content=await request.body(),
                headers=dict(request.headers)
            )
        finally:
            self.backends[backend]["pending"] -= 1

app = FastAPI()
balancer = LLMLeastPendingBalancer(["http://gpu1:8000", "http://gpu2:8000", "http://gpu3:8000"])

@app.api_route("/v1/{path:path}", methods=["GET", "POST"])
async def proxy(path: str, request: Request):
    return await balancer.forward(request)

Чому sticky sessions критичні для LLM?

Якщо ваша LLM використовує KV-кеш prefix reuse (наприклад, загальний system prompt у чат-боті), без липких сесій кожен запит може потрапити на інший сервер — кеш марний. Рішення — consistent hashing за префіксом та sticky sessions.

def get_backend_by_prefix(prompt: str, backends: list[str]) -> str:
    prefix_hash = hashlib.md5(prompt[:256].encode()).hexdigest()
    idx = int(prefix_hash, 16) % len(backends)
    return backends[idx]

Застосування sticky sessions збільшує cache hit ratio на 30-50%, скорочуючи latency на 20%. Без них типовий сервіс із загальним system prompt втрачає до 60% ефективності кешу.

Типові помилки при балансуванні GPU

• Використання Round Robin для LLM — призводить до нерівномірного завантаження.
• Відсутність health checks — трафік йде на впавший сервер.
• Ігнорування streaming-таймаутів — клієнти отримують 502 помилки при довгих генераціях.
• Неправильна конфігурація proxy_buffering — збільшує latency.
• Відсутність failover GPU — при збої одного інстанса весь трафік втрачається.

Як налаштувати health checks для GPU-інстансів?

Що входить у налаштування балансування під ключ

1. Аналіз сценаріїв навантаження (кількість запитів, довжина токенів, вимоги до latency).
2. Вибір алгоритму та стеку (Nginx, кастомний балансувальник, Envoy).
3. Налаштування health checks, circuit breaker, таймаутів.
4. Реалізація sticky sessions (якщо потрібен KV-кеш).
5. Інтеграція з моніторингом (Prometheus + Grafana дашборди).
6. Документація з експлуатації та Playbook для інцидентів.

Процес роботи

• Аналітика — збір метрик поточної інфраструктури, профілювання запитів.
• Проектування — архітектура балансування, вибір алгоритмів, схема failover.
• Реалізація — розгортання конфігів або написання кастомного модуля.
• Тестування — навантажувальне тестування з вимірами p50/p99/p999 latency.
• Деплой — поетапний rollout з canary-релізом.

Строки та вартість

Базова настройка на Nginx — від 1 дня. Кастомний балансувальник з підтримкою Least Pending Tokens — від 3 до 5 днів. Вартість розраховується індивідуально, виходячи зі складності інфраструктури та вимог до відмовостійкості. Гарантуємо стабільність сервісу після впровадження — наші інженери з 5+ років досвіду в ML-інфраструктурі виконують роботу під ключ. Типовий ROI впровадження — 6 місяців.

Моніторинг розподілу навантаження

Після впровадження відстежуйте: розподіл RPS (має бути рівномірним ±20%), queue depth на кожному бекенді, error rate, latency p99. Налаштуйте алерт: «один бекенд приймає >80% трафіку» — сигнал про збій. При правильному налаштуванні p99 latency знижується до 5 секунд, а утилізація GPU підвищується до 95%. Cache hit ratio досягає 70% при використанні sticky sessions. Ми також навчаємо команду роботі з дашбордами.

Зв'яжіться з нами для попереднього аудиту — ми оцінимо поточну конфігурацію та запропонуємо оптимальне рішення. Замовте консультацію — допоможемо з вибором стратегії балансування для вашого GPU-кластера.

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

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

Як побудувати MLOps-інфраструктуру?

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 — тоді будь-який експеримент можна повторити з точністю до байта. Це скорочує час на відтворення результатів у 2–3 рази.

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

Коли потрібен оркестратор пайплайнів?

Скрипт навчання на 100 рядків у cron — нормально для простих задач. Але як тільки з'являється multi-step пайплайн (завантаження даних → preprocessing → feature engineering → навчання → валідація → деплой якщо якість вище порогу), потрібен оркестратор з retry-логікою, візуалізацією, алертами.

Kubeflow — Kubernetes-native оркестратор для ML. Кожен крок — Docker-контейнер. Підтримує паралельні кроки, умовні гілки, артефакти між кроками. Інтегрується з Katib (AutoML), KServe (serving), Feast (feature store). Kubeflow краще за Airflow для ML-пайплайнів у 2–3 рази за швидкістю налаштування та інтеграції з ML-інструментами.

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. Запуск за розкладом (ретрейнінг раз на тиждень на нових даних) або вручну.

from kfp import dsl

@dsl.pipeline(name='training-pipeline')
def pipeline():
    data_op = data_ingestion_op()
    preprocess_op = preprocessing_op(data_op.output)
    train_op = training_op(preprocess_op.output)
    eval_op = evaluation_op(train_op.output)
    with dsl.Condition(eval_op.output > 0.95):
        deploy_op = deployment_op(train_op.output)

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

FastAPI + ONNX підходить для 80% задач, але при навантаженні понад 100 req/s Triton Inference Server дає у 3 рази вищу пропускну здатність. Triton — 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%.

Моніторинг: 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 дні після зміни джерела даних — це врятувало кампанію з бюджетом понад $100K. За словами CTO клієнта, впровадження моніторингу скоротило час виявлення проблем з 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 тижнів. Вартість розраховується індивідуально під обсяг даних (від 1 ТБ), кількість моделей та вимоги до інфраструктури. Замовте аудит MLOps-інфраструктури — отримайте roadmap за 1–2 тижні. Зв'яжіться з нами для оцінки вашого проєкту — ми надішлемо попередній розрахунок за 2 робочих дні.

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