Деплой LLM
FastAPI, Docker, K8s
Проблема: Вы создали ИИ-фичу. Как теперь безопасно задеплоить её в прод? Как обрабатывать обновления, откаты и масштабирование?
Решение: Запускай аккуратно как ракету
Деплой LLM — это работа по переносу ИИ-фичи с твоего ноутбука в сервис, к которому обращаются реальные пользователи — безопасно, воспроизводимо и с возможностью откатиться, если что-то сломалось. Сама модель — лишь часть истории. Продакшн-деплой это целая система: эндпоинт инференса (хостинговый API вроде Anthropic или OpenAI, либо твой собственный сервер с открытой моделью), код приложения, который собирает промпты и разбирает ответы, плюс rate limiting, ретраи, кеширование, мониторинг и план отката. Это как запуск ракеты — двигатель важен, но не менее важны предстартовый чеклист, поэтапное зажигание и телеметрия, за которой ты следишь всю дорогу наверх.
Как это работает
Большинство команд начинают с вызова управляемого API: ты отправляешь запрос, получаешь токены обратно, а провайдер сам разбирается с GPU и масштабированием. Это самый быстрый путь в прод, но ты платишь за каждый токен и зависишь от чужого аптайма. Если ты делаешь self-hosted открытой модели (Llama, Mistral, Qwen) через сервер вроде vLLM, TGI или Ollama, ты контролируешь стоимость и местонахождение данных (data residency), но теперь сам отвечаешь за выделение GPU, батчинг и масштабирование. Поскольку вызовы LLM тяжёлые по задержке (latency) и могут падать множеством способов — таймауты, rate limits, фильтры контента, обрезанный или некорректный JSON — для каждого режима отказа нужен свой обработчик. Две техники делают это управляемым: квантизация, которая ужимает self-hosted модель так, чтобы она помещалась на более дешёвое железо, и observability— логирование задержки, частоты ошибок и расхода токенов, чтобы ты реально видел, что происходит в проде, а не гадал.
Компромиссы и разбор примера
Ключевое напряжение — скорость выкатки против контроля рисков. Выкатить сразу на 100% пользователей быстро, но тогда любой баг превращается в инцидент; поэтапная раскатка медленнее, но ограничивает радиус поражения. Допустим, ты меняешь модель у бота поддержки на более новую. Безопасный деплой выглядит так: сначала запусти её как shadow (теневой деплой) — новая модель отвечает в фоне, ты логируешь её ответы, но никогда не показываешь пользователям, и сравниваешь качество офлайн. Потом сделай canary: направь 5% живого трафика на новую модель, понаблюдай за частотой ошибок и задержкой час, и расширяй до 25%, 50%, 100% только если дашборды остаются зелёными. Держи старую версию наготове, чтобы одно изменение конфига откатило тебя меньше чем за пять минут. Вывод: никогда не делай деплой дверью в одну сторону — каждый релиз должен быть наблюдаемым, пока он раскатывается, и обратимым, если он повёл себя плохо.
Представьте это как запуск ракеты:
- 1. Rate limiting настроен: Лимиты per-user и per-IP предотвращают злоупотребления и неконтролируемые расходы
- 2. API-ключи защищены: Не в клиентском коде, хранятся в переменных окружения, регулярно ротируются
- 3. Обработка всех режимов отказа LLM: Таймаут, rate limit, фильтр контента, некорректный ответ — для каждого есть свой обработчик
- 4. Мониторинг и алертинг запущены: Дашборды отслеживают задержку, частоту ошибок, расход токенов; алерты срабатывают на аномалиях
- 5. Fallback-поведение определено: Когда LLM недоступна: кешированные ответы, упрощённые ответы без LLM или дружелюбное сообщение «попробуйте позже»
- 6. Нагрузочное тестирование пройдено: Система протестирована при 2x ожидаемой пиковой нагрузке — без падений, приемлемая задержка
- 7. Стратегия отката определена: Canary: остановить перенаправление трафика. Blue-green: переключить обратно. Self-hosted: откатиться на предыдущий чекпоинт модели. Каждый деплой должен быть обратим менее чем за 5 минут.
- 8. A/B-оценка качества: Сравнение ответов старой и новой модели на реальном трафике. Отслеживание метрик качества (точность, relevance scores) наряду с задержкой и стоимостью до полного раскатки.
Чеклист продакшна: 1 баг на стейджинге дешевле 1000 багов в продакшне. Тестируйте каждый режим отказа перед запуском.
Варианты деплоя
- На базе API: Использовать OpenAI, Anthropic и т.д. — проще всего
- Self-hosted: Запуск открытых моделей на своей инфраструктуре
- Гибридный: API для сложных задач, self-hosted для простых
- Edge: Маленькие модели, работающие на устройствах пользователей
- Graceful Degradation: Когда LLM медленная или недоступна, показывать кешированные ответы, упрощённые ответы без LLM или дружелюбное сообщение «попробуйте позже»
- Canary-деплой: Направить 5-10% трафика на новую версию. Мониторить ошибки и задержки. Если стабильно — постепенно увеличивать до 100%.
- Blue-Green деплой: Два идентичных окружения: «blue» (текущее) и «green» (новое). Переключение трафика мгновенно через DNS/балансировщик. Мгновенный откат обратным переключением.
- Self-hosted LLM: Деплой open-source моделей (Llama, Mistral) через vLLM, TGI или Ollama. Ключевые задачи: выделение GPU, квантизация (GPTQ/AWQ), автомасштабирование.
Интересный факт: Многие компании сначала используют "теневой деплой" — запуск нового ИИ параллельно со старой системой без показа результатов пользователям. Это позволяет сравнить выводы и найти проблемы до реального деплоя.
Попробуйте сами!
Используй чеклист деплоя ниже, чтобы убедиться, что твоё ИИ-приложение готово к продакшну.
Частые вопросы
Чем отличается canary-деплой от blue-green?
Canary постепенно переводит трафик на новую версию (например, 5% → 25% → 100%), наблюдая за ошибками и задержкой на каждом шаге — баг затрагивает лишь часть пользователей. Blue-green держит два идентичных окружения и переключает весь трафик мгновенно одним изменением DNS или балансировщика; откат тоже мгновенный — обратным переключением. Canary безопаснее для постепенного контроля рисков, blue-green быстрее по переключению и откату.
Что выбрать для деплоя LLM: API или self-hosted?
Управляемый API (Anthropic, OpenAI) — самый быстрый путь в прод: провайдер сам отвечает за GPU и масштабирование, ты платишь за токены и зависишь от чужого аптайма. Self-hosted открытой модели (Llama, Mistral, Qwen) через vLLM, TGI или Ollama даёт контроль над стоимостью и местонахождением данных, но ты сам отвечаешь за выделение GPU, квантизацию, батчинг и автомасштабирование. Часто берут гибрид: API для сложных задач, self-hosted для простых и массовых.
Что такое теневой деплой (shadow deployment)?
Это когда новая модель работает параллельно со старой и отвечает на реальные запросы в фоне, но её ответы не показываются пользователям — только логируются. Так ты сравниваешь качество новой модели со старой на живом трафике и ловишь проблемы до того, как они дойдут до людей. Обычно это первый шаг перед canary-раскаткой.
Как безопасно откатить деплой LLM?
Каждый деплой должен быть обратим менее чем за пять минут. Для canary — просто остановить перенаправление трафика на новую версию. Для blue-green — переключить балансировщик обратно на старое окружение. Для self-hosted модели — откатиться на предыдущий чекпоинт. Главное правило: держи старую версию наготове и никогда не делай деплой «дверью в одну сторону».
Попробуй сам
Интерактивное демо этой техники
Безопасно деплоить LLM-приложение: прокси вместо прямого API-ключа в клиенте
// React component
const response = await fetch("https://api.openai.com/v1/chat/completions", {
headers: { "Authorization": "Bearer sk-abc123..." },
body: JSON.stringify({ model: "gpt-4", messages })
});
Архитектура: React → /api/chat (ваш сервер) → OpenAI API
// server.js (Express proxy)
const rateLimit = require("express-rate-limit");
const limiter = rateLimit({
windowMs: 60 * 1000, // 1 минута
max: 10, // 10 запросов/мин/пользователь
keyGenerator: (req) => req.user.id
});
app.post("/api/chat", limiter, async (req, res) => {
// 1. Валидация
const { message } = req.body;
if (!message || message.length > 4000) {
return res.status(400).json({ error: "Invalid input" });
}
// 2. Вызов LLM (ключ на сервере)
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: [{ role: "user", content: message }]
}); // API key из process.env.OPENAI_API_KEY
// 3. Логирование
logger.info({ user: req.user.id, tokens: response.usage });
res.json({ reply: response.choices[0].message.content });
});
Никогда: sk-... в клиентском коде, .env в git, CORS без ограничений.
Никогда не кладите API-ключ в клиентский код. Production-паттерн: клиент → прокси на вашем сервере (auth, rate limit, validation, logging) → LLM API. Это защищает и ключ, и бюджет.
Квиз по уроку
1.Какой ключевой аспект при деплое приложений на базе LLM в масштабе?
Создайте бесплатный аккаунт для решения челленджей
4 челленджей с AI-проверкой для этого урока
Этот урок — часть структурированного курса по LLM.
Мой путь обучения