Локальный запуск модели доказывает, что веса работают, но production API требует отдельного serving-слоя. До выбора облака или GPU-платформы определите модель, максимальный контекст, тип запросов, ожидаемую конкуренцию и целевые SLO по latency/availability.
Сначала решите: serverless или dedicated GPU
Serverless/общий inference удобен при низкой или нестабильной нагрузке: меньше операционной работы, оплата ближе к фактическим запросам, но меньше контроля над cold start и железом.
Dedicated GPU даёт предсказуемее latency и изоляцию, но вы платите за выделенную мощность и отвечаете за utilisation.
Для чувствительных данных отдельно проверьте регион, retention, network isolation и возможность private/VPC deployment.
Проверьте, помещается ли модель в выбранный GPU
VRAM зависит не только от размера весов. На память влияют precision/quantization, KV cache, context length, batch/concurrency и особенности serving runtime. Не выбирайте GPU только по числу параметров: сделайте реальный load test с тем контекстом и concurrency, которые будут в production.
Дайте приложению стабильный API-контракт
Зафиксируйте версию модели и endpoint, не подменяйте веса незаметно для клиентов.
OpenAI-compatible API может упростить интеграцию существующих SDK, но всё равно документируйте поддерживаемые параметры и отличия.
Разделите readiness/health endpoint и inference endpoint.
Добавьте timeout, request-size/token limits и идемпотентную обработку клиентских retry там, где это применимо.
Batching и autoscaling должны смотреть на очередь, а не только на GPU
Утилизация GPU полезна для наблюдения, но для LLM-serving она не всегда отражает пользовательскую задержку. Для scaling следите за queue depth, in-flight requests, time-to-first-token, tokens per second, KV-cache pressure и ошибками/таймаутами. Scale-to-zero экономит деньги на редкой нагрузке, но добавляет cold-start trade-off.
Минимальная observability для inference
p50/p95/p99 time-to-first-token и полная latency.
Input/output tokens, tokens/sec и размер batch.
Queue time, concurrency и rejected/rate-limited requests.
GPU memory/utilization, OOM, restarts и cold-start duration.
Стоимость на запрос/1M tokens или на пользовательский сценарий, а не только цена GPU-часа.
Не открывайте GPU endpoint напрямую в интернет без защиты
Используйте authentication/API keys и отдельные quotas/rate limits.
Ограничьте максимальный prompt/context и output tokens, чтобы один запрос не занял всю память.
Не логируйте чувствительные prompts/responses без явной retention-политики.
Сканируйте контейнеры и зависимости, обновляйте serving runtime и отделяйте management-plane от публичного inference endpoint.
Считайте стоимость под реальный профиль трафика
Сравнивайте не только цену H100/A100/L4 в час. В расчёт входят idle time, autoscaling floor, cold starts, storage/egress, резерв для пиков, инженерная поддержка и фактический throughput модели. Shared per-token endpoint часто дешевле на малом трафике; dedicated GPU может выиграть при стабильной высокой загрузке и требованиях к контролю.
Проверка перед production
Load test на ожидаемом и пиковом concurrency.
Проверка OOM и деградации на длинном контексте.
Тест scale-up/scale-down и поведения во время cold start.
Canary новой версии модели с возможностью rollback.
Алерты на latency, errors, queue и budget/cost anomalies.
Итог
Рабочая последовательность: выбрать модель и SLO → подобрать GPU/quantization → поднять reproducible serving container → дать стабильный API → нагрузочно протестировать → настроить batching/autoscaling → добавить security и observability → посчитать cost per request → запускать через canary. Так «модель на GPU» превращается в сервис, которым безопасно пользоваться из production-приложений.