Когда self-hosting оправдан

Причины: требования к размещению данных, контроль версии и latency, специализированная модель или высокая предсказуемая загрузка. Для малого и переменного трафика managed API часто дешевле с учётом инженеров и резервной мощности.

Качество до инфраструктуры

Проведите eval на своих задачах и сравните с текущим baseline. Более дешёвая модель, которая требует больше повторов и ручных исправлений, может увеличить TCO.

Память и KV cache

Вес модели - только начало. Нужны память под runtime, activations и KV cache, который растёт с batch и длиной контекста. OOM под длинным production prompt не виден в коротком smoke test.

Runtime и continuous batching

Inference runtime объединяет разные запросы в динамические batches, управляет KV cache и streaming. Фиксируйте версию runtime и параметры: они меняют latency, throughput и иногда численное поведение.

Quantization как компромисс

Снижение precision уменьшает память и может ускорить inference, но эффект зависит от железа и backend. Проверяйте не только perplexity, а task-level eval, long-context и tool calling.

SLO и autoscaling

GPU replica загружается медленно, поэтому обычный CPU-autoscaling может опоздать. Используйте queue depth, waiting tokens и TTFT как сигналы, держите headroom и проверяйте cold start.

Безопасный API

Ставьте gateway с authentication, tenant quotas, input limits, timeouts и audit. Ограничьте доступ к model management endpoints, не запускайте контейнер privileged без явного threat review и патчите runtime.

Обновления и TCO

Blue/green загрузка требует временно двойной памяти. Храните immutable model artifact, tokenizer и config, прогоняйте eval и load test перед переключением. В TCO включайте GPU idle time, replicas, storage, egress и on-call.

С чего начать внедрение?
С узкого сценария, измеримого baseline и набора реальных запросов. Сначала зафиксируйте качество и ограничения, затем меняйте один параметр за эксперимент.
Какие метрики считать обязательными?
Качество результата, p95 latency, ошибки, стоимость и отдельные метрики ключевого этапа. Среднее значение без сегментов и percentiles скрывает провалы.
Можно ли выбрать параметры по документации?
Документация задаёт безопасный baseline, но финальные параметры выбирают по собственному корпусу, нагрузке и eval-набору.
Как обновлять систему без риска?
Версионировать конфигурацию, запускать shadow-сравнение, затем canary и иметь заранее проверенный rollback target.
Почему нужен набор отрицательных примеров?
Он показывает, умеет ли система отказываться и не поднимать нерелевантные результаты только потому, что они ближайшие среди доступных.
Что сохранять для расследования?
Версии компонентов, trace ID, параметры запроса, IDs доказательств, решения фильтров и агрегированные метрики с соблюдением правил доступа и retention.
← Все статьи блога