Self-hosted AI Enterprise Stack — vLLM, SGLang, Docker. Внутренняя AI-платформа для команды

Модуль: 13. Профессиональная практика | Время: ~40 мин теории + 60 мин практики

Суть урока

Использовать Anthropic API — это покупать электричество из городской сети. Удобно, надёжно, платишь по счётчику. Не нужно думать о трансформаторах, проводах, диспетчерской.

Self-hosted AI — это построить собственную электростанцию рядом со зданием. Дорого на старте: турбина, охлаждение, оператор. Но если у тебя завод с 50+ станками работающими 24/7, своя электростанция окупается за 1-2 года и даёт независимость от поставщика.

Когда self-host окупается:

• LLM-расход $5000+/мес стабильно (break-even hardware)
• 50+ пользователей одновременно (рабочая нагрузка)
• Регулируемая отрасль (compliance требует data residency)
• Геополитика (sanctions risk, sovereignty)
• Кастомные модели (fine-tuned под domain)

В остальных случаях — API дешевле, проще, надёжнее.

Пороги и суммы в этом уроке — ориентиры для расчёта, а не прайс: цены на железо и тарифы меняются, проверяй перед закупкой. Актуальные цены API: Актуальное сейчас.

🎨 Образ: ресторан с фастфуд-меню vs ресторан с собственной фермой. Фастфуд берёт продукты у поставщика — быстро, дёшево на старте. Своя ферма — это большая инвестиция в землю и оборудование, но через несколько лет себестоимость порции заметно ниже и ты контролируешь качество от семени до тарелки.

🎯 Decision tree: нужен ли тебе self-host

Прежде чем тратить $50K на железо — пройди этот чек-лист. Один "нет" во всех узлах — оставайся на API.

LLM costs > $5000/мес стабильно последние 3 месяца?
→ Да → Self-host break-even через 12-18 мес
→ Нет → API дешевле, не трогай железо

Регулируемая отрасль (healthcare, finance, gov, defense)?
→ Да → Self-host required для compliance (HIPAA, PCI DSS, GDPR strict)
→ Нет → следующий вопрос

Team 50+ человек одновременно используют AI каждый день?
→ Да → Self-host для cost + privacy + latency
→ Нет → API streamlined, не усложняй

Specific model требуется (fine-tuned на domain data, кастомная)?
→ Да → Self-host (у облачных провайдеров fine-tuning ограничен списком моделей и условиями)
→ Нет → следующий вопрос

Geographic / political restrictions (Russia, China, sanctions impact)?
→ Да → Self-host = sovereignty insurance
→ Нет → API подходит

Все ответы "нет"?
→ Stay on API. Self-host = overengineering для тебя.

🎨 Образ: покупка трактора. Если у тебя огород 100 м² — лопата дешевле и быстрее. Трактор имеет смысл от 10 гектаров. Self-host — это трактор. Маленьким хозяйствам он только разоряет.

Ключевые концепции

• Inference engine — программа которая принимает запрос и генерирует ответ от LLM (vLLM, SGLang, TGI, Ollama). Аналог двигателя в машине
• vLLM — самый популярный open-source inference engine, Apache 2.0, отлично балансирует throughput и удобство
• SGLang — один из самых быстрых по throughput, вырос из проекта LMSYS (Berkeley), оптимизирован под structured outputs и parallel sampling
• API gateway — прокси-слой который превращает локальный inference в OpenAI-compatible endpoint (LiteLLM). Существующие клиенты работают без изменений
• Tensor parallelism — разделение модели между несколькими GPU. 70B модель требует ~140GB VRAM в FP16 — одной картой не обойтись
• Quantization — сжатие модели в 4-bit или 8-bit для уменьшения VRAM в 2-4 раза с минимальной потерей качества
• Throughput — сколько токенов в секунду генерирует система (важно для multi-user setups)
• Latency — задержка первого токена (TTFT — time to first token). Критично для интерактивного UX
• Concurrent users — сколько пользователей могут работать одновременно без деградации latency

Теория

Hardware tiers для company

Размер железа определяется тремя параметрами: размер модели (B параметров), количество одновременных пользователей, требования к latency.

Tier 1: Departmental (5-20 пользователей)

Целевой профиль — отдел разработки, маркетинга или поддержки в средней компании. Не критичная нагрузка, эксперимент или внутренний инструмент.

Пример: команда из 10 разработчиков на code review и docs generation. Сборка: две потребительские видеокарты верхнего класса по 24GB, серверный корпус, процессор класса Threadripper или Xeon, 128GB RAM, NVMe 4TB, блок питания 1500W. Суммарно порядка $10K (ориентир, сверь цены комплектующих на момент закупки).

🎨 Образ: компактный электрогенератор на даче. Дом обеспечивает, соседям не хватит.

Tier 2: Team (20-100 пользователей)

Целевой профиль — компания где AI стал production-критичным инструментом. SaaS-стартап со встроенным AI, агентство с 50 разработчиками, midsize fintech.

На этом уровне уже нужен серверный room с контролем температуры (HVAC), UPS на 5-10 кВт, выделенная сетевая инфраструктура. Нужен dedicated ops engineer хотя бы part-time.

Tier 3: Enterprise (100-1000+ пользователей)

Целевой профиль — крупная компания, банк, государственное учреждение. AI — core инфраструктура.

Это уже отдельный data center сегмент. Нужна команда из 3-5 человек: SRE, ML engineer, security, network. Sla 99.9%+ требует redundancy на всех уровнях.

Inference engines — сравнение (на октябрь 2026)

Inference engine — это сердце системы. От выбора зависит throughput, latency и операционная сложность. Реалистичный shortlist из 5 вариантов:

vLLM (github.com/vllm-project/vllm) — золотой стандарт. PagedAttention — фирменная техника эффективного использования VRAM. OpenAI-compatible API из коробки. Большинство туториалов и production кейсов — на vLLM.

SGLang (github.com/sgl-project/sglang) — в ряде бенчмарков обгоняет vLLM по throughput, но замерь на своей нагрузке. RadixAttention — переиспользование KV-cache между запросами. Особенно хорош когда у тебя много похожих system prompts (типичный agent-сценарий). Минус — экосистема моложе, меньше готовых руководств.

TGI (Text Generation Inference) (github.com/huggingface/text-generation-inference) — продукт HuggingFace. Хорошо интегрируется с HF Hub, простой деплой. Но на октябрь 2026 проект в режиме поддержки (maintenance mode): принимаются только мелкие исправления, а сами авторы рекомендуют vLLM и SGLang. Для нового проекта лучше начинать с них.

Ollama — для пилотов и небольших команд. Запускается одной командой, имеет красивый CLI. Не масштабируется выше ~10 одновременных пользователей. Детали: Локальные AI модели — Ollama, LM Studio и приватный AI.

🎨 Образ: выбор двигателя в машину. vLLM — Toyota (надёжно, доступно, всё работает). SGLang — Porsche (быстрее, но требует опыта). Ollama — мопед (запустится мгновенно, далеко не уедет).

Docker stack для team deployment

Production setup собирается из 3-4 контейнеров. Inference engine + gateway + UI + auth. Базовая конфигурация для Tier 1:

# docker-compose.yml — Tier 1 team setup (5-20 users)
# Ключ version в современном Docker Compose не нужен

services:
  # Inference engine
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    ports:
      - "8000:8000"
    volumes:
      - ./models:/root/.cache/huggingface
    command:
      # Модель bf16 весит ~65GB: на 2×24GB бери квантизованную версию (AWQ или GPTQ),
      # на A100/H100 80GB — как есть
      - --model
      - Qwen/Qwen3-32B
      - --tensor-parallel-size
      - "2"
      - --gpu-memory-utilization
      - "0.90"
      - --max-model-len
      - "32768"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]
    restart: unless-stopped

  # API gateway — OpenAI-compatible proxy с rate limiting + audit
  litellm:
    # Закрепи конкретную версию вместо main-latest (см. ниже про март 2026)
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    environment:
      - DATABASE_URL=postgres://litellm:secret@postgres:5432/litellm
      - MASTER_KEY=sk-master-внутренний-ключ-замени
    volumes:
      - ./litellm-config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml", "--port", "4000"]
    depends_on:
      - postgres
      - vllm
    restart: unless-stopped

  # PostgreSQL для LiteLLM (audit, keys, budgets)
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER=litellm
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=litellm
    volumes:
      - postgres-data:/var/lib/postgresql/data
    restart: unless-stopped

  # User-facing UI
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "3000:8080"
    environment:
      - OPENAI_API_BASE_URL=http://litellm:4000/v1
      - OPENAI_API_KEY=sk-master-внутренний-ключ-замени
      - WEBUI_AUTH=true
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - litellm
    restart: unless-stopped

volumes:
  open-webui:
  postgres-data:

Конфиг LiteLLM (litellm-config.yaml):

model_list:
  - model_name: qwen-32b
    litellm_params:
      model: openai/Qwen/Qwen3-32B
      api_base: http://vllm:8000/v1
      api_key: dummy  # vLLM не требует real auth

general_settings:
  master_key: sk-master-внутренний-ключ-замени
  database_url: postgres://litellm:secret@postgres:5432/litellm

litellm_settings:
  drop_params: true
  set_verbose: false
  json_logs: true
  cache: true

Запуск:

docker compose up -d
# vLLM скачает модель Qwen3 32B (~65GB в bf16) при первом старте
# Прогресс смотрим: docker compose logs -f vllm

После старта:

• http://localhost:8000/v1 — raw vLLM endpoint
• http://localhost:4000/v1 — LiteLLM gateway (используем этот)
• http://localhost:3000 — Open WebUI для пользователей

🎨 Образ: Lego-конструктор. Каждый контейнер — кубик с одной функцией. vLLM считает, LiteLLM контролирует доступ, Postgres помнит кто что делал, WebUI даёт интерфейс.

OpenAI-compatible API gateway — LiteLLM

LiteLLM (github.com/BerriAI/litellm) — критичный компонент стека. Без него self-host остаётся внутренней игрушкой, с ним — становится enterprise-grade платформой.

Что даёт LiteLLM:

• OpenAI-compatible API — все клиенты которые работают с OpenAI/Anthropic (Cursor, Continue.dev, Aider, custom scripts) работают с локальным vLLM без переписывания кода
• Per-user API keys — каждый разработчик получает свой ключ. Отозвать одного — не ломает остальных
• Rate limiting — лимиты per-user или per-team чтобы один скрипт не занял всё железо
• Cost tracking + budgets — кто сколько токенов потратил, alerts на превышение лимита
• Audit log — все запросы в PostgreSQL с user_id, model, tokens, latency
• Multi-model routing — можно роутить простые запросы на маленькую модель, сложные на большую
• Fallback to API — если локальный vLLM упал, можно проксировать на Anthropic API

Безопасность самого шлюза: 24 марта 2026 в PyPI на короткое время попали вредоносные версии пакета litellm (1.82.7 и 1.82.8), которые крали учётные данные. Разбор от авторов: Security Update: Suspected Supply Chain Incident. Вывод для любого шлюза с ключами: закрепляй версию (pin), ставь только из проверенных источников и подписанных образов, обновляйся осознанно, а не автоматически.

Создание пользовательского ключа через LiteLLM admin:

# Создаём team
curl -X POST http://localhost:4000/team/new \
  -H "Authorization: Bearer sk-master-внутренний-ключ-замени" \
  -H "Content-Type: application/json" \
  -d '{
    "team_alias": "backend-team",
    "max_budget": 100.0,
    "models": ["qwen-32b"]
  }'

# Создаём ключ для разработчика
curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-master-внутренний-ключ-замени" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "backend-team",
    "user_id": "dev_user_42",
    "max_budget": 10.0,
    "duration": "30d",
    "rpm_limit": 60,
    "tpm_limit": 100000
  }'
# Ответ: {"key": "sk-1a2b3c4d...", "expires": "..."}

Разработчик использует свой ключ в любом OpenAI-compatible инструменте:

# Aider (префикс openai/ говорит, что это OpenAI-совместимый endpoint)
export OPENAI_API_BASE=http://internal-llm:4000/v1
export OPENAI_API_KEY=sk-1a2b3c4d...
aider --model openai/qwen-32b

# Cursor — указать Custom API в настройках
# Continue.dev в VS Code — config.yaml (config.json устарел):
# models:
#   - name: Internal Qwen
#     provider: openai
#     model: qwen-32b
#     apiBase: http://internal-llm:4000/v1
#     apiKey: sk-1a2b3c4d...
# Точный формат смотри в документации Continue.

Authentication & access control

Раздавать пользователям master_key — это как давать всем сотрудникам ключ от серверной. Нужен SSO + per-user провизионирование.

Authentik (goauthentik.io) — open-source IdP, прямой конкурент Okta. Самохост, поддерживает SAML, OAuth2, OIDC. Интегрируется с Google Workspace, Microsoft 365, LDAP.

Keycloak — старший брат, enterprise-tested, но тяжелее в настройке. Если у компании уже Java-стек — естественный выбор.

Типичная схема:

Сотрудник входит в Open WebUI
  ↓
Open WebUI редиректит на Authentik
  ↓
Authentik проверяет через Google Workspace SSO
  ↓
Authentik возвращает JWT с user_id, groups
  ↓
Open WebUI создаёт session
  ↓
Open WebUI вызывает LiteLLM с user-specific API key
  ↓
LiteLLM проверяет ключ, лимиты, логирует, передаёт в vLLM
  ↓
vLLM генерирует ответ

Ключевые controls:

• Groups → models — junior разработчики только малая модель, senior получают доступ к большой (70B)
• Per-user budgets — небольшой дефолтный бюджет на пользователя, расширение по запросу через manager
• Rate limits — 60 req/min дефолт, чтобы случайный bash-скрипт в цикле не повалил систему
• Audit logging — все запросы пишутся в Postgres, retention 90 дней (или дольше для compliance)

Monitoring stack

Без мониторинга self-host превращается в чёрный ящик. Когда пользователи начнут жаловаться "медленно работает" — нужно сразу видеть метрики.

Минимальный стек:

• Prometheus — сбор метрик. vLLM экспортирует endpoint /metrics нативно
• Grafana — дашборды. Готовые шаблоны для vLLM есть на grafana.com/dashboards
• Loki — агрегация логов (опционально, для больших setups)
• OpenTelemetry — distributed tracing (опционально, для multi-service)

Метрики которые надо отслеживать с дня 1:

• GPU utilization (% — недогрузка = переплата, перегрузка = очередь)
• VRAM usage (% — приближение к 95% = OOM скоро)
• Tokens/sec (throughput аггрегированный)
• Time to first token (P50, P95, P99 — UX метрика)
• Queue depth (если растёт — нужно больше железа)
• Cost per user (LiteLLM экспортирует)
• Error rate (5xx, timeouts)

Расширение docker-compose для monitoring:

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin-замени
    volumes:
      - grafana-data:/var/lib/grafana
    restart: unless-stopped

prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: vllm
    static_configs:
      - targets: ['vllm:8000']
    metrics_path: /metrics

  - job_name: litellm
    static_configs:
      - targets: ['litellm:4000']
    metrics_path: /metrics

🎨 Образ: приборная панель в самолёте. Без неё пилот узнаёт о проблеме когда мотор уже задымился. С панелью — за 10 минут до этого.

Fine-tuning своей модели — дополнительная возможность

Если у компании есть domain-специфичные данные (юридические документы, медицинские протоколы, код на внутреннем DSL) — fine-tuning может дать существенный буст качества.

Базовые числа (ориентиры, проверяй под свою задачу):

• Hardware: 1x A100 80GB для small fine-tune (7B-13B), 4x для large (70B)
• Data: 1K-10K качественных examples для хорошего результата
• Tools: Axolotl (github.com/axolotl-ai-cloud/axolotl), LLaMA-Factory (github.com/hiyouga/LLaMA-Factory)
• Time: 2-24 часа в зависимости от размера модели и объёма данных
• Стоимость: $100-1000 при аренде GPU (RunPod, Lambda Labs)

Подробности fine-tuning — в уроке Fine-tuning — когда промптов мало. Здесь важно: после fine-tune модель деплоится в тот же vLLM/SGLang что и базовая. Меняется только параметр --model на путь к fine-tuned checkpoint.

Real-world setups — 3 case studies

Это обобщённые иллюстрации, а не отчёты конкретных компаний; суммы условные. Требования к данным (GDPR, медицинские и банковские регуляции) проверяй с юристом: урок не заменяет юридическую консультацию.

Case 1: Российский fintech (50 разработчиков)

Контекст: банк среднего размера, разработка core banking ПО, требования к data residency (Россия) исключают зарубежные облачные API.

Stack:

• 4x A100 80GB (1 сервер с tensor parallel 4)
• Открытая модель класса 70B (семейство Qwen) + LiteLLM + Open WebUI + Authentik
• Использование: code review автоматический, генерация документации, security analysis на pull requests

Экономика:

• Hardware: ~$200K (серверы + сетевое + UPS)
• OpEx: $400/мес электричество, 0.5 FTE ops engineer
• Альтернатива (Anthropic): ~$50K/год при текущей нагрузке
• Break-even: ~4.4 года даже без зарплаты ops engineer ($200K / ($50K − $4.8K электричества) в год)
• Sovereignty: 100% — все данные не покидают периметр

Case 2: European healthcare SaaS

Контекст: SaaS для клиник в Германии, GDPR + национальное medical data law. Любой запрос с patient data не может уйти в US/UK.

Stack:

• 2 сервера с 2x H100 80GB каждый (redundancy)
• SGLang + открытая модель класса 70B, fine-tuned на анонимизированных медицинских transcripts
• Authentik SSO с интеграцией в существующий Active Directory
• Использование: assistant для врачей (research, summarization), drafts для patient communication (всегда под supervision)

Экономика:

• Hardware: €300K
• OpEx: €600/мес инфра + 1 FTE ops
• Compliance: passed GDPR audit, medical data certification
• Risk reduction (потенциальный fine за data breach): millions of euros

Case 3: Latin American media company

Контекст: медиахолдинг в Mexico City, контент на испанском, португальском, английском, кечуа. Большие объёмы перевода и rewriting.

Stack:

• 2x RTX 4090 (один сервер)
• Qwen3 32B (в квантизации) + Open WebUI + LiteLLM
• Использование: translation pipeline на 5 языков, генерация черновиков статей, A/B варианты заголовков

Экономика:

• Hardware: $12K one-time
• OpEx: $80/мес электричество
• Альтернатива до self-host: $1500/мес (DeepL + OpenAI)
• Break-even: ~8.5 месяца ($12K / ($1500 − $80) в месяц)
• Дополнительный buy: возможность тонкой настройки под испанский регионализм Латамерики (не учитывается коммерческими переводчиками)

Operational concerns — что ломается в production

Self-host не "поставил и забыл". Реальный список того что требует внимания каждую неделю:

• Uptime — для 99.9% нужен redundant setup (2 сервера минимум, automatic failover)
• GPU failures — 1-2 карты в год выходят из строя при 24/7 нагрузке. Держи запасные
• Cooling — серверный room должен поддерживать 18-22°C. Перегрев = ускоренный износ GPU
• Power — UPS на 15+ минут для graceful shutdown, генератор для production
• Model updates — раз в квартал выходят новые версии Qwen/Llama/Mistral. Обновление модели = 1-2 часа downtime
• OS / Driver updates — NVIDIA drivers требуют осторожности (несовместимости с vLLM версиями)
• Backup — модели весят 50-200GB, нужен план хранения checkpoints
• Maintenance time — закладывай 1-2 часа в неделю ops time даже на stable setup

🎨 Образ: аквариум с рыбками. Купил рыбок — теперь надо кормить, чистить, температуру держать, лекарства если заболели. Не "поставил и любуешься".

Cost comparison — 1 год детально

Сравнение для команды 50 разработчиков, потребление ~$5K/мес если на API:

Hybrid часто оказывается оптимумом: большая часть запросов через локальный vLLM (cheap, sovereign), сложные запросы через Anthropic API (когда нужна сильная облачная модель). LiteLLM умеет роутить автоматически.

Аудитория — рейтинг применимости

Новичок (1 разработчик, личный проект)

Не нужен self-host. Возвращайся когда LLM bills > $300/мес стабильно. До этого — Anthropic/OpenAI API, экономия времени важнее экономии денег.

Если хочется поиграть с локальными моделями для learning — Ollama (см. урок Локальные AI модели — Ollama, LM Studio и приватный AI), запускается за 10 минут.

Средний (small team, 5-20 человек)

Tier 1 setup имеет смысл если:

• Стабильно $1500+/мес на LLM
• Или хотя бы одно requirement: privacy, sovereignty, latency

Конфиг: vLLM + LiteLLM + Open WebUI. Один сервер с 2x RTX 4090 или 1x A100. Setup за неделю, ops 2-4 часа в неделю.

Pilot перед production: запусти на 2 недели на cloud GPU (например, RunPod; цену за час смотри на сайте провайдера), измерь реальную нагрузку, потом закупай железо под точные параметры.

Профессионал (medium business, 20-100 человек)

Tier 2 рекомендуется когда:

• $5K+/мес стабильно
• Production-критичный AI use case
• Есть выделенный ops engineer

Конфиг: SGLang + LiteLLM + Authentik SSO + Prometheus/Grafana. 2-4 сервера для redundancy. Setup 2-4 недели, ops 1 FTE part-time.

Enterprise (100-1000+ пользователей)

Это уже другая весовая категория. Tier 3 — отдельная инфраструктура, dedicated team, SLA, disaster recovery, multi-region. За пределами этого урока. См. курсы NVIDIA / Anyscale / RunPod по enterprise AI infrastructure.

Anti-patterns — частые ошибки

• ❌ Self-hosting при <$2K/мес LLM spend — нет ROI. Hardware амортизируется 3+ года, ops time стоит денег
• ❌ Игнорирование electricity costs — каждый GPU 24/7 ест $50-200/мес электричества + cooling
• ❌ Без dedicated ops person — вечный downtime. Кто-то один должен отвечать за систему, даже part-time
• ❌ Skipping authentication — security breach неизбежен. Раздать master_key всем = invitation to disaster
• ❌ No monitoring — проблемы остаются скрытыми до production failure. Минимум Prometheus + 3 ключевые метрики
• ❌ Один сервер только — no redundancy = SPOF. Tier 1 ещё можно one box, Tier 2+ всегда redundant
• ❌ Использование latest unstable версий — vLLM/SGLang активно развиваются, breaking changes частые. Pin версию, тестируй upgrades
• ❌ Игнорирование model updates — модели стареют. Новое поколение приходит каждые несколько месяцев (Qwen 2.5 уже сменили Qwen3 и новее). Закладывай ресурс на migration
• ❌ Покупка enterprise-tier железа для pilot — арендуй GPU в cloud для первых 1-2 месяцев, потом закупай по реальным метрикам

Практика

Шаг 1: Pilot на cloud GPU перед закупкой железа

Прежде чем покупать $50K сервер — арендуй GPU в облаке на 1-2 недели и измерь реальную нагрузку.

# RunPod — самый удобный для pilot
# Регистрация на runpod.io, аренда A100 80GB (цену за час смотри на сайте)
# SSH в pod

# Установка Docker (если не установлен)
curl -fsSL https://get.docker.com | sh

# Запуск vLLM с моделью Qwen3 32B
docker run --gpus all -p 8000:8000 \
  -v ~/models:/root/.cache/huggingface \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-32B \
  --gpu-memory-utilization 0.90

# Тест запроса
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-32B",
    "messages": [{"role": "user", "content": "Объясни RAG в трёх предложениях"}]
  }'

Альтернативы RunPod: Lambda (lambda.ai), Anyscale (anyscale.com), Hyperstack, CoreWeave.

Шаг 2: Production setup на собственном железе

Когда pilot подтвердил параметры — собирай production. Базовый чек-лист:

# Сервер с Ubuntu Server (актуальная LTS-версия)
# Установка NVIDIA drivers (версию подбирай под CUDA и свою версию vLLM)
sudo apt update && sudo ubuntu-drivers install

# NVIDIA Container Toolkit для Docker GPU support (по документации NVIDIA)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update && sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Проверка GPU доступен в Docker (подставь актуальный тег образа nvidia/cuda)
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

# Клонируем стек (создаём свой репо или используем шаблон)
mkdir -p /opt/internal-ai && cd /opt/internal-ai
# Копируем docker-compose.yml из теории (Tier 1)

# Запускаем
docker compose up -d

# Смотрим логи
docker compose logs -f vllm

Шаг 3: Provisioning первых пользователей

# Создаём admin token через LiteLLM
MASTER_KEY=sk-master-внутренний-ключ-замени

# Создаём team разработки
curl -X POST http://localhost:4000/team/new \
  -H "Authorization: Bearer $MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_alias": "dev-team",
    "max_budget": 500.0,
    "budget_duration": "30d",
    "models": ["qwen-32b"]
  }'
# Сохрани team_id из ответа

# Создаём ключ для каждого разработчика (используем pseudonymized IDs)
for user in dev_user_001 dev_user_002 dev_user_003; do
  curl -X POST http://localhost:4000/key/generate \
    -H "Authorization: Bearer $MASTER_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"team_id\": \"<team_id_из_ответа>\",
      \"user_id\": \"$user\",
      \"max_budget\": 20.0,
      \"duration\": \"90d\",
      \"rpm_limit\": 60,
      \"tpm_limit\": 100000,
      \"metadata\": {\"role\": \"developer\"}
    }"
done

Раздай ключи через 1Password / secure channel. Каждый разработчик настраивает свой инструмент (Cursor, Continue.dev, Aider) на internal endpoint.

Шаг 4: Базовый мониторинг

# Запускаем Prometheus + Grafana
docker compose up -d prometheus grafana

# Открываем Grafana
# http://localhost:3001 (admin / admin-замени)
# Add data source → Prometheus → http://prometheus:9090

# Импортируем готовый dashboard для vLLM
# Пример dashboard есть в документации vLLM (раздел про Prometheus и Grafana)
# Dashboards → Import → загрузи JSON из примера

Ключевые алерты которые надо настроить в первый день:

# alerts.yml для Prometheus
groups:
  - name: vllm-critical
    rules:
      # Названия метрик менялись между версиями vLLM: сверь с /metrics своей версии
      - alert: GPU_OOM_Risk
        expr: vllm:gpu_cache_usage_perc > 0.95  # в новых версиях kv_cache_usage_perc
        for: 2m
        annotations:
          summary: "KV-кэш заполнен >95% (риск очереди и OOM)"

      - alert: High_Latency
        expr: histogram_quantile(0.95, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le)) > 5
        for: 5m
        annotations:
          summary: "P95 latency > 5 секунд"

      - alert: vLLM_Down
        expr: up{job="vllm"} == 0
        for: 1m
        annotations:
          summary: "vLLM endpoint недоступен"

Шаг 5: Fallback на API (hybrid setup)

Чтобы локальная инфраструктура не была SPOF — настрой автоматический fallback на Anthropic API.

litellm-config.yaml с fallback:

model_list:
  - model_name: smart-assistant
    litellm_params:
      model: openai/Qwen/Qwen3-32B
      api_base: http://vllm:8000/v1
      api_key: dummy

  - model_name: smart-assistant-fallback
    litellm_params:
      # актуальные идентификаторы моделей: документация Anthropic
      model: anthropic/claude-sonnet-5-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks:
    - {"smart-assistant": ["smart-assistant-fallback"]}
  context_window_fallbacks:
    - {"smart-assistant": ["smart-assistant-fallback"]}
  timeout: 30
  num_retries: 2

Теперь если vLLM упал или перегружен — запросы автоматически идут в Anthropic. Пользователь не заметит downtime.

Чеклист готовности к production (✅)

• Hardware размер соответствует ожидаемой нагрузке (pilot подтвердил)
• Inference engine (vLLM/SGLang) задеплоен и стабилен 7+ дней
• API gateway (LiteLLM) с per-user keys и rate limits
• SSO интеграция (Authentik/Keycloak) с corporate IdP
• Мониторинг (Prometheus + Grafana) с критичными alerts
• Audit log пишется в БД (retention 90+ дней)
• Fine-tune procedure задокументирована (если используется)
• Fallback на Anthropic/OpenAI API готов (LiteLLM routing)
• Backup моделей и configs (3-2-1 правило)
• Runbook на типичные сбои (GPU OOM, OOM kill, network)
• Power & cooling redundancy (UPS, cooling backup)
• Dedicated ops engineer назначен (хотя бы part-time)
• Disaster recovery план (RTO, RPO определены)

Инструменты и ресурсы

Inference engines:

• vLLM — most popular, balanced
• SGLang — best throughput, advanced features
• TGI (HuggingFace) — HF ecosystem (режим поддержки)
• Ollama — easy start для пилотов

API gateway & auth:

• LiteLLM — OpenAI-compatible proxy с rate limiting + audit
• Authentik — open-source IdP (SSO, SAML, OIDC)
• Keycloak — enterprise IdP (Java стек)

UI:

• Open WebUI — ChatGPT-подобный интерфейс для команды

Fine-tuning:

• Axolotl — flexible fine-tuning framework
• LLaMA-Factory — UI + CLI для fine-tuning

Cloud GPU для pilots:

• Anyscale — managed Ray + serving
• RunPod — самый удобный pay-per-hour
• Lambda — long-term contracts, hardware sales
• CoreWeave — enterprise-tier
• Hyperstack — конкурентные цены

Monitoring:

• Grafana — free tier для small teams
• Prometheus — стандарт для metrics

Ключевые выводы

Self-host окупается на масштабе: $5K+/мес LLM spend или 50+ одновременных пользователей. До этого порога API дешевле, проще, надёжнее. Не покупай трактор для огорода.

Tier 1 setup (1 сервер с двумя видеокартами по 24GB + vLLM + LiteLLM + Open WebUI) собирается за неделю и обходится порядка $10-15K на железо плюс электричество (ориентир). Этого достаточно для команды 10-20 человек.

LiteLLM — критичный middleware, превращает локальный inference в enterprise-grade платформу: per-user keys, rate limits, audit logs, cost tracking, automatic fallback to API. Без него self-host остаётся внутренней игрушкой.

Hybrid setup (основной поток локально + сложные запросы через Anthropic API) часто оптимальнее чистого self-host. LiteLLM routing делает это прозрачно для пользователя.

Ops time — главная скрытая стоимость self-host. Закладывай 1-2 часа в неделю даже на стабильный setup. Без выделенного ответственного — вечный downtime.

Что дальше

→ AI Regulation & Compliance — какие требования к данным и моделям нужно учитывать команде, которая строит внутреннюю AI-платформу