Как да deploy-на AI модел?

Най-практичният начин да deploy-неш AI модел е да го превърнеш в предсказуема, наблюдаема услуга: ясен вход/изход, стабилна среда за изпълнение, контрол на версиите, автоматизиран rollout и мониторинг на качество. Production deployment не е „качване на модел“, а пускане на услуга със SLA, мониторинг и план за rollback. Ако тръгнеш от тези принципи, изборът на платформа (Kubernetes, managed endpoint, собствен сървър) става детайл, а не риск.

Въведение

Deployment е мостът между „работи на лаптопа ми“ и „можем да разчитаме на него при реални потребители“. В реалния свят имаш ограничения за латентност, бюджет, сигурност, регулации, както и промяна на данните във времето (data drift). Тук ще минем през процес, който работи както за класически ML модели, така и за LLM-базирани системи.

Ще получиш:

  • практични стъпки за packaging, serving и rollout
  • избор между real-time, batch и async inference
  • опции за production: managed endpoints, Kubernetes (KServe) и високопроизводително serving (Triton, Ray Serve)
  • чеклист за мониторинг, сигурност и поддръжка

Ако не можеш да възпроизведеш средата и артефакта 1:1, не можеш да вярваш на предсказанията в production.

Стъпка 1: Определи целта и ограниченията (SLA, SLO, бюджет)

Преди да пишеш код, фиксирай „как изглежда успехът“. Минималният набор:

  • Латентност: например p95 < 200 ms за real-time, или „до 5 минути“ за async.
  • Пропускателност: заявки/секунда или токени/секунда при LLM.
  • Наличие: 99.5%/99.9% и какво значи „downtime“.
  • Разход: максимум на месец или на 1 000 заявки.
  • Качество: метрика (accuracy/F1), бизнес KPI (конверсия), или human evaluation.

Съвет: дефинирай отделно „технически“ и „бизнес“ SLO. Модел може да е бърз, но да дава „тихо“ грешни резултати.

Стъпка 2: Избери режим на inference (real-time, batch, async)

Това решение определя архитектурата и цената.

  1. Real-time endpoint
  • най-ниска латентност
  • плащаш за постоянно работещи инстанции
  • добър за препоръки, анти-фрод, чат интерфейси
  1. Batch inference
  • оптимален за големи обеми (например nightly scoring)
  • плащаш за изпълнение на job, не за 24/7 сървър
  • добър за сегментации, маркетинг списъци, отчетност
  1. Asynchronous inference
  • приемаш заявка, обработваш по-късно, връщаш резултат през webhook/пул
  • добър компромис за по-тежки модели и „спайкове“

Най-честата грешка е да избереш real-time, когато бизнесът реално търпи async. Това изгаря бюджета.

Стъпка 3: Подготви артефакта за deployment (модел + зависимости)

Целта е един артефакт, който се държи еднакво навсякъде.

Минимумът:

  • версия на модела (файл/папка): напр. model.onnx, model.pt, sklearn.joblib
  • точна среда: requirements.txt/poetry.lock/conda-lock, версия на Python
  • конфигурация: прагове, фичъри, препроцесинг параметри
  • README за inference контракт: как изглежда входът и изходът

Добри практики:

  • Запиши „signature“: имена/типове/shape на входовете.
  • Ако имаш feature store, фиксирай версия на фичърите.
  • За LLM: фиксирай system prompt, шаблони, инструменти (tools) и guardrails като версия.

Стъпка 4: Създай стабилен inference интерфейс (HTTP/gRPC)

Най-често ще expose-неш HTTP API (FastAPI) или gRPC.

Минимален HTTP контракт:

  • POST /predict
  • JSON вход
  • JSON изход
  • ясни error codes

Важно:

  • Валидирай входа (schema validation). Не приемай „каквото дойде“.
  • Пази idempotency (ако заявката се повтори).
  • Добави GET /healthz и GET /readyz.

Пример (идея, не догма):

# FastAPI: проста структура
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Input(BaseModel):
    text: str

@app.get('/healthz')
def healthz():
    return {'ok': True}

@app.post('/predict')
def predict(inp: Input):
    # 1) preprocess
    # 2) model inference
    # 3) postprocess
    return {'label': '...', 'score': 0.0}

Стъпка 5: Контейнеризирай и тествай локално (Docker + load test)

Контейнерът прави „еднаква“ среда за dev/staging/prod.

Преди да deploy-неш:

  • пусни контейнера локално
  • направи smoke test (1-2 заявки)
  • направи load test (k6/Locust) и измери p95 латентност
  • провери memory leak и GPU/CPU натоварване

За LLM serving следи:

  • time-to-first-token (TTFT)
  • tokens/sec
  • GPU memory и KV cache

Стъпка 6: Избери production платформа (3 практични пътя)

Вариант A: Managed endpoints (по-малко DevOps)

Това е най-бързият път до production за екипи без силна Kubernetes култура.

  • AWS SageMaker: плащаш за „instance-hours“ за хостинг плюс допълнителни компоненти (напр. мониторинг) и трафик. В официалните pricing примери има real-time хостинг с инстанции като ml.c5.xlarge на час и отделна цена за data in/out (таксуване на GB).
  • Google Vertex AI: цената за deployment и online prediction се таксува на „node hour“ (в pricing таблиците има ставки на час, според типа workload/модел).
  • Azure Machine Learning: описано е, че плащаш основно за Azure ресурси (VM-и, registry, storage и др.), като има и примерни калкулации на VM цена на час за training и inferencing.

Кога да го избереш:

  • искаш бърз старт и enterprise интеграции
  • екипът не иска да поддържа Kubernetes

Минуси:

  • по-малък контрол над serving стека
  • lock-in и разходи при 24/7 endpoints

Вариант B: Kubernetes + KServe (стандартизиран serving слой)

KServe е платформа за inference върху Kubernetes, насочена към „генеративен“ и „предиктивен“ AI, с функции като autoscaling, различни режими на инсталация (вкл. Knative за serverless) и удобства за production. Полезно е, когато искаш единен стандарт за много модели и екипи.

Практичен минимален път:

  1. Kubernetes cluster (managed или on-prem)
  2. Ingress + TLS
  3. Инсталирай KServe
  4. Деплойни InferenceService към model artifact (в S3/GCS/NFS)
  5. Настрой autoscaling и canary rollout (ако ползваш Knative режим)

Кога да го избереш:

  • имаш много модели/версии
  • искаш канарейки и стандартизиран API към моделите

Вариант C: Високопроизводително serving (Triton / Ray Serve / vLLM)

Ако ти трябва максимална производителност и контрол над inference:

  • NVIDIA Triton Inference Server (в последните материали на NVIDIA се среща и като „Dynamo Triton“): силен избор за GPU serving, dynamic batching, метрики, HTTP/gRPC и работа с model repository.
  • Ray Serve: framework за serving и autoscaling на Python/ML workloads. Има production гайдове (вкл. Kubernetes) и LLM serving възможности с OpenAI-compatible API и наблюдаемост.
  • vLLM: inference engine за LLM, често използван през OpenAI-compatible server; има описани интеграции с Ray Serve LLM.

Кога да го избереш:

  • LLM serving с високи изисквания към TTFT и throughput
  • нужда от multi-node scaling
  • контрол над batching, маршрутизация и кеширане

Стъпка 7: Мониторинг, сигурност и операции (без това няма production)

Тук се печели или губи доверието.

  1. Логове и трасета
  • request id, latency, входни размери, error codes
  • за LLM: входни/изходни токени, TTFT, токени/сек
  1. Метрики
  • p50/p95/p99 latency
  • error rate
  • CPU/GPU utilization
  • queue length
  1. Мониторинг на качество (ML monitoring)
  • data drift (разпределения на фичъри)
  • concept drift (качество пада)
  • „бизнес drift“ (KPI се променя)
  1. Rollout стратегии
  • blue/green
  • canary (5% трафик към нова версия)
  • автоматичен rollback при влошени SLO
  1. Сигурност
  • TLS навсякъде
  • auth (API keys/OAuth/JWT)
  • least privilege към storage/secret-и
  • сканиране на контейнер образи
  • защита от prompt injection при LLM (валидирай инструменти, allowlist домейни, изолирай tool execution)

Без наблюдение на качество и разход, моделът неизбежно „се чупи“ тихо в production.

Как да сметнеш разходите (бързо и честно)

Най-често грешиш в две места: плащаш за „idle“ и подценяваш трафика на данни.

Направи проста сметка:

  • Цена на compute: инстанция/под на час (CPU/GPU) по броя часове.
  • Среден throughput: заявки/секунда (или токени/сек).
  • Цена на заявка: (часова цена / заявки за час) + storage + трафик.

Практически трикове:

  • Ако трафикът ти е неравномерен, търси autoscaling (в идеалния случай и scale-to-zero).
  • За LLM endpoint: кеширай резултати за повтарящи се заявки, ползвай batching и оптимизирай контекстите.
  • Първо оптимизирай модела (квантизация/по-малък вариант), после скалирай хардуера.

Deployment за LLM приложения (RAG, инструменти, guardrails)

При LLM рядко „deploy-ваш само модел“. Обикновено имаш цял pipeline:

  • prompt шаблони + системни правила
  • retrieval (RAG) към база знания (vector DB)
  • инструменти (tools): търсене, калкулатор, CRM, файлове
  • филтри: PII редакт, политики за съдържание

За production стабилност:

  • Версионирай prompt-овете и правилата като код.
  • Изолирай изпълнението на инструменти (sandbox/allowlist) и логвай всичко.
  • Дръж лимити: максимален контекст, максимален изход, rate limits.

LLM deployment е най-рисков, когато смесиш „интелигентност“ и „достъп до системи“ без ясни политики и изолация.

Съвети за по-добри резултати

  • Версионирай всичко: модел, данни, фичъри, промптове, конфигурация.
  • Измервай „цената на заявка“ (или на 1 000 заявки) още в staging.
  • Оптимизирай преди да скалираш: batching, кеш, по-лек модел/квантизация.
  • Създай staging среда, която е максимално близка до production.
  • Запиши runbook: как се дебъгва, как се прави rollback, кой е on-call.

Чести грешки, които да избягваш

  • Няма contract за вход/изход и всеки клиент праща различен JSON.
  • Препроцесингът в training и serving се различават (training-serving skew).
  • Няма лимити: един огромен payload „убива“ инстанцията.
  • Няма мониторинг на качество, само на latency.
  • Няма стратегия за версия на модела и миграция на клиенти.

Мини-чеклист преди production

  • Има ли healthz/readyz?
  • Имаш ли throttling/limiting?
  • Има ли логове + метрики + аларми?
  • Имаш ли canary/rollback?
  • Имаш ли DPA/политики за данни (ако моделът обработва лични данни)?

Източници и полезни линкове (проверени 2025–2026)

Бележка: При първи deploy планирай време за онбординг, тестове и observability.