Все статьи
обновлено 10 мин

Миграция с облачного AI на self-hosted: пошаговый план

Как съехать с OpenAI / Claude / GigaChat на свой контур без даунтайма: оценка совместимости, выбор моделей, сохранение качества, параллельный запуск, отсечка.

миграцияself-hosted-aiopenai-альтернативаcloud-to-self-hostedagmind

Миграция с облачного AI на self-hosted — это проект на 6-12 недель, а не «переключить URL». Три триггера: счёт за API перевалил 200-500 тыс. ₽/мес, юристы подняли 152-ФЗ, или платёжки за OpenAI стали нестабильны. Этот текст — пошаговый план: что считать до старта, как переезжать без даунтайма и как не просесть в качестве.

Зачем переезжать с облачного AI на self-hosted?

Три типичных триггера:

  1. Деньги. Месячный счёт за API перевалил за 200-500 тыс. ₽. На этих числах свой сервер начинает окупаться за 4-9 месяцев.
  2. Compliance. Юристы / служба безопасности / регулятор поставили вопрос: «персональные данные в OpenAI — это вообще ФЗ-152?». Подробнее — в тексте про ФЗ-152.
  3. Геополитика и санкции. Платёжки за OpenAI через прокладки — нестабильно. Доступ к API — может пропасть в любой момент. Riski концентрации поставщика растут.

Часто все три сразу. Self-hosted решает все три, но не бесплатно: появляется стоимость инфраструктуры, требования к команде, риск качества.

Сравнительная картина — в on-premise vs cloud матрице.

Что считать ДО миграции

Самая частая ошибка — начать с «давайте развернём Llama 70B и посмотрим». Развернуть — самый простой шаг. Сложное — оценить, потянет ли open-source модель ваши задачи на ваших данных. Это решается до покупки железа.

Шаг 0: инвентаризация use-case’ов

Что у вас сейчас крутится на облачном AI?

| Use-case          | Модель      | Объём, токенов/мес | Качество, оценка | Критичность |
|-------------------|-------------|--------------------|--------------------|---|
| Поддержка-бот     | gpt-4o-mini | 50М                | 85%                | high |
| Резюмирование     | gpt-4o      | 10М                | 92%                | medium |
| Извлечение из PDF | claude-3.5  | 5М                 | 88%                | high |
| Анализ настроений | gpt-3.5     | 30М                | 75%                | low |

Это даёт три вещи: реальную нагрузку, требования к качеству, приоритет миграции. Не всё нужно мигрировать сразу. Низкокритичные кейсы можно оставить в облаке навсегда, если общий объём небольшой.

Шаг 1: бенчмарк качества на ВАШИХ данных

Публичные бенчмарки (MMLU, HumanEval, MTEB) — не предсказывают качество на ваших задачах. Нужен eval-сет на ваших реальных кейсах.

Минимум:

  • 50-200 примеров на use-case с эталонными ответами.
  • Разнообразие: типичные кейсы + edge cases.
  • Метрики: accuracy для классификации, BLEU/ROUGE для генерации, ручная оценка для творческих.

Прогон через 3-5 кандидатов:

  • Llama 3.3 70B — универсальный baseline.
  • Qwen 3 (~72B / 30B-MoE) — сильнее на multilingual, в т.ч. русском.
  • DeepSeek V3 / R1 — для reasoning-задач.
  • Saiga / Vikhr (русифицированные файнтюны) — для русско-специфичных кейсов. См. обзор.

Если open-source просел на 5-10 п.п. — ок, RAG / промпт-инжиниринг закроют разницу. Если просел на 20+ — миграция этого use-case либо не делается, либо делается через файнтюн.

Шаг 2: оценка инфраструктуры

Под выбранную модель считаем железо:

  • Llama 3.3 70B в Q4: ~40 ГБ VRAM, 1× A100 80GB или 2× RTX 4090 (с компромиссами).
  • Qwen 3 30B-MoE в Q4: ~20 ГБ VRAM, 1× RTX 4090 хватает.
  • Embedder bge-m3 в FP16: ~3 ГБ VRAM, можно на CPU.
  • Reranker bge-reranker-v2-m3: ~2 ГБ VRAM.

Подробный расчёт стоимости — в тексте про стоимость сервера и TCO для 30 человек.

Параллельно решаем:

  • Один сервер или два (для HA)?
  • Кластер на K8s или standalone?
  • Где взять железо — закупка или Beget/Selectel/VK Cloud bare metal?

Шаг 3: план миграции по use-case’ам

Не «переключаем всё в один день». По очереди:

  1. Наименее критичный use-case первым — анализ настроений, классификация, типизация.
  2. Параллельный запуск — облако и self-hosted работают одновременно, ответы сравниваются.
  3. Постепенное переключение трафика — 10% → 25% → 50% → 100%.
  4. Следующий use-case — после стабилизации предыдущего.
  5. Самые критичные — последними — когда вся инфра обкатана.

Типичная продолжительность: 6-12 недель на полную миграцию команды 30-50 человек.

Архитектура переезда: API-совместимость

Главный технический трюк — API-compatibility layer. Большинство приложений уже написаны под OpenAI-совместимый API. Если self-hosted-сервер выставляет тот же интерфейс — приложения переключаются сменой base_url и одной переменной.

Стек, который даёт OpenAI-совместимый endpoint:

  • vLLM — нативно OpenAI-совместим, production-grade.
  • TGI (Text Generation Inference от HuggingFace) — тоже совместим.
  • Ollama — для dev/малых нагрузок.
  • LiteLLM — proxy-слой, можно ставить перед любым из вышеперечисленных + унифицировать billing/rate-limit/fallback.

Типовая архитектура:

[Приложение]
    ↓ OpenAI API
[LiteLLM proxy]
    ↓
[vLLM (Llama 70B)]   [Embedder API]   [Vector store]

LiteLLM полезен для:

  • Smart routing: классификация → дешёвая модель, RAG → 70B.
  • Fallback: если self-hosted упал — переключиться на облако (на время инцидента).
  • Унифицированный billing / rate-limit / логирование.

Параллельный запуск: ключевая фаза

Самая важная техника снижения риска. Запросы дублируются: ответ выдаётся из облака (production), параллельно тот же запрос идёт в self-hosted, ответ записывается, но не показывается. На офлайн-разборе сравниваются качества.

# псевдокод
def chat(prompt):
    cloud_response = openai.chat(prompt)   # production-ответ
    asyncio.create_task(log_self_hosted(prompt))  # фоновый прогон
    return cloud_response

Результаты копятся 1-2 недели. Метрики:

  • Совпадает ли структура ответа.
  • Нет ли регрессии на специфических запросах.
  • Latency self-hosted в реальной нагрузке.
  • Стабильность (uptime, error rate).

После этого — переключение трафика.

Постепенное переключение: canary deploy

Переключаем не всех пользователей сразу:

  • Неделя 1: 10% запросов → self-hosted. Мониторинг качества и жалоб.
  • Неделя 2: 25%.
  • Неделя 3: 50%.
  • Неделя 4: 100%, облако в standby.
  • Неделя 5+: отключение облачных ключей.

На каждой стадии — кнопка rollback за минуты. Если жалобы пошли — откатываемся.

LiteLLM / Kong / любой L7-прокси умеют такое штатно.

Use-case-specific миграция

Чат-бот / ассистент

  • OpenAI gpt-4o-mini → Llama 3.3 70B Q4 / Qwen 3 30B Q4.
  • Промпты обычно переносятся as-is с минимальной правкой.
  • Если использовали function calling — vLLM / TGI поддерживают, но нюансы.
  • Streaming ответов — поддерживается.

RAG-система

  • Embedder: text-embedding-3-large → bge-m3 (русский multilingual).
  • Reranker: иногда не использовался в облаке, добавляется при миграции — улучшает качество.
  • LLM: gpt-4o → Llama 3.3 70B / DeepSeek V3.
  • Архитектура остаётся та же. См. архитектуру RAG.

Извлечение данных из PDF

  • Claude / gpt-4o с vision → Qwen 2.5 VL 32B / 72B.
  • Качество vision-моделей сильно отстаёт от облака на сложных layout’ах. Простые формы — ок, сложные таблицы / рукописный текст — может проседать.
  • Workaround: сначала OCR (Tesseract/PaddleOCR), потом текстовая LLM. Часто лучше vision-LLM.
  • Подробнее — vision LLM для парсинга PDF.

Speech-to-text

  • OpenAI Whisper API → self-hosted Whisper / GigaAM-RNNT.
  • Качество эквивалентно (это одни и те же модели в большинстве случаев).
  • Подробнее — сравнение STT.

Image generation

  • DALL-E / Midjourney → Stable Diffusion XL / FLUX.
  • Качество подтянулось, но стиль другой. Если у клиента сложился «фирменный стиль на DALL-E» — переезд требует rebrand или файнтюн через LoRA.

Технический долг, который вылезет

1. Промпты тюнились под gpt-4o. Open-source модели реагируют немного по-другому. Часть промптов придётся переписать. План: 10-20% промптов перетюнить.

2. Контекстное окно. Llama 3.3 — 128K, Qwen 3 — 128K. Большинство кейсов покрывают, но если у вас 200K+ контекст использовался регулярно — нужно архитектурно перепроектировать (чанкирование + RAG вместо «впихнуть всё в контекст»).

3. Function calling. Open-source поддерживает, но в production бывают edge cases. Регрессионные тесты обязательны.

4. Tools / MCP интеграция. Если использовали Claude с tools — миграция на open-source через MCP-протокол. См. MCP-подключение к 1C/Bitrix.

5. Latency. Облачный API даёт 50-200мс time-to-first-token. Self-hosted на одной GPU при низкой нагрузке — сравнимо. При высокой одновременной нагрузке — растёт. План: load-test + capacity planning.

6. Concurrency. vLLM держит десятки одновременных запросов на одной GPU за счёт continuous batching. Но не безграничен. Считать peak load заранее.

Что часто срывает миграцию

1. Недооценка стоимости. «Сервер за 800 тыс. → один раз и всё». Реальная TCO: железо + электричество + админ + лицензии + бэкап. Подробнее — TCO калькуляция.

2. Отсутствие eval-сета. Команда мигрирует, никто не меряет качество. Через два месяца — жалобы, что «AI стал хуже». Без бейзлайна спор не решить.

3. Один-единственный сервер. Упал — встал бизнес. HA-конфигурация с самого начала, или явное принятие риска даунтайма.

4. Команда не готова. Self-hosted требует знаний DevOps + ML. Если их нет — внедрение → провал → возврат в облако через полгода с убытками. Решения: внешний партнёр на саппорт + обучение команды, или продолжать в облаке.

5. Безопасность по остаточному принципу. Перенесли модель — забыли про security. Векторная БД без авторизации, логи без шифрования, секреты в env. См. безопасность RAG.

Гибридные сценарии: не всё или ничего

Не обязательно мигрировать 100%. Распространённые гибриды:

  • Чувствительные данные → self-hosted, неконфиденциальный креатив → облако. Юридические документы, ПДн — внутри. Маркетинговые тексты, общий research — в OpenAI/Claude.
  • Базовая нагрузка → self-hosted, пики → облако. Self-hosted рассчитан на 80% обычной нагрузки. При пике — LiteLLM перенаправляет в облако. Дешевле и проще, чем держать запас железа.
  • Production → self-hosted, R&D → облако. Эксперименты разработчиков и аналитиков идут на облачные API (быстрее итерация). Production — внутри.

Чек-лист миграции

До старта

  • Инвентаризация use-case’ов с объёмами и критичностью.
  • Eval-сет на ваших данных, минимум 50 примеров на use-case.
  • Бенчмарк 3-5 open-source моделей-кандидатов на eval-сете.
  • Расчёт TCO: железо / электричество / команда / поддержка.
  • Решение: full self-hosted, гибрид, или остаёмся в облаке.

Подготовка

  • Закупка / аренда железа.
  • Развёртывание стека: vLLM + embedder + vector store + LiteLLM + monitoring.
  • Безопасность: периметр, авторизация, шифрование.
  • Backup-план — см. DR для AI.
  • Промпты адаптированы под open-source модель.

Параллельный запуск

  • Все запросы дублируются, ответы логируются.
  • Метрики качества и latency собираются.
  • 1-2 недели наблюдений.
  • Регрессии разобраны и закрыты.

Постепенное переключение

  • Canary 10% → мониторинг → 25% → 50% → 100%.
  • Кнопка rollback готова на каждом шаге.
  • Жалобы пользователей мониторятся.

После

  • Облачные ключи отозваны.
  • Документация обновлена.
  • Команда обучена работе с self-hosted.
  • DR-учения проведены.

Итог

Миграция с облака на self-hosted — это 6-12 недель аккуратной работы, не вечернее переключение. Главные инструменты снижения риска: eval-сет на ваших данных, OpenAI-совместимый API, параллельный запуск, canary deploy. Главные ошибки: недооценка TCO, отсутствие бейзлайна, команда без DevOps-навыка.

В AGmind мы делаем миграции пакетом «аудит → деплой → интеграция → саппорт». Аудит включает eval-сет на ваших данных и честный ответ — стоит мигрировать всё, гибрид, или вам пока выгоднее облако. Это разговор на 30 минут.

Связанные тексты: on-premise vs cloud матрица, пилот за 4 недели, TCO для 30 человек, как развернуть ChatGPT в компании за 6 недель.