Собственный inference API для SaaS: архитектура, квоты и экономика

Собственный inference API даёт контроль над моделью и вычислениями, но добавляет обязанности владельца сервиса. Нужно обеспечить доступность, изоляцию клиентов, учёт потребления и обновления без неожиданного изменения поведения. Запущенный модельный сервер является одним компонентом этой системы. Решение о переносе должно опираться на нагрузку и экономику продукта.

Определить контракт для клиента

Зафиксируйте поддерживаемые методы, ограничения входа, структуру ошибок и правила версионирования. Совместимый формат API упрощает интеграцию, но не гарантирует одинаковые ответы, токенизацию и поддержку всех параметров. vLLM реализует совместимые интерфейсы для ряда сценариев; поведение конкретных возможностей проверяют на используемой версии 1.

Клиент должен понимать, что происходит при превышении лимита, отмене запроса и временном отказе. Определите максимальную длительность операции и политику повторов. Если повтор может привести к платному внешнему действию, понадобится защита от дублирования на уровне приложения. Для обычной генерации повтор тоже расходует ресурс и должен учитываться в затратах.

Разделить управление и вычисления

Входной слой проверяет клиента, полномочия и квоты. Затем запрос попадает в управляемую очередь и модельный сервер. Учёт завершения и потребления сохраняется отдельно от текста ответа. Административные маршруты и метрики не следует открывать всем пользователям API.

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

Квоты должны учитывать реальную нагрузку

Ограничение	Что предотвращает
Число активных запросов клиента	Захват всей очереди одним пользователем
Максимальный вход и выход	Неограниченную память и длительную генерацию
Бюджет потребления	Неожиданные расходы клиента и владельца
Время ожидания	Бесконечное накопление запросов
Класс обслуживания	Конфликт пакетных и интерактивных задач

Лимит только по числу HTTP-запросов недостаточен: один длинный документ может стоить больше множества коротких вопросов. При этом тарифицировать всё исключительно по токенам тоже не всегда удобно для продукта. Внутренний учёт должен сохранять вычислительные показатели, даже если клиент платит за документ или завершённую задачу.

Проверить изоляцию данных

Если SaaS использует общий поиск документов, идентификатор клиента должен определяться из проверенной учётной записи, а не доверенного поля запроса. Qdrant описывает варианты многопользовательского хранения 3; выбор схемы не отменяет тесты разделения данных. Кеши, логи и резервные копии входят в ту же модель доступа.

Проведите отрицательный тест с двумя синтетическими клиентами и различимыми документами. Один не должен получать материалы другого при поиске, повторном запросе, восстановлении из копии или смене роли. Подобные проверки полезнее общей фразы о защищённом контуре в коммерческом описании.

Рассчитать стоимость на полезную операцию

Включите аренду или амортизацию, резерв, эксплуатацию, хранение, сеть и работу инженеров. Разделите расходы на число успешно завершённых операций, которые прошли критерий качества. Ошибки и повторные попытки остаются в числителе. При низкой загрузке собственная инфраструктура может быть дороже внешнего сервиса даже при дешёвой генерации на занятом узле.

Проверьте сценарии обычного дня, пика и отказа одного компонента. Автомасштабирование требует времени загрузки модели и наличия доступной мощности; его нельзя считать мгновенным. Для небольшого продукта разумно сравнить резервированную аренду и собственный узел на одном горизонте, не предполагая будущую загрузку как уже достигнутую.

Обновлять поведение управляемо

Храните версию модели и конфигурации в записи запроса. Новую версию проверяйте на контрольном наборе качества и нагрузки, затем направляйте ограниченную долю допустимого трафика. Предусмотрите возврат к предыдущей версии и совместимость сохранённых данных. Изменение ответа способно повлиять на продукт даже при неизменной схеме JSON.

Для принятия решения используйте план миграции с API, мониторинг инференса и проект inference-инфраструктуры. Покупка GPU становится частью обоснованного плана, когда контракт сервиса, нагрузка и стоимость эксплуатации описаны вместе.