Вычисления и выделение ресурсов
Получение GPU-мощностей, пулы узлов, драйверы и стеки CUDA, совместимость которых с движком сервинга поддерживается постоянно.
Руководство по инференсу
Инфраструктура и эксплуатация
Всё, что окружает модель и позволяет ей обслуживать запросы: компоненты платформы, эксплуатационная дисциплина для безопасной выкатки изменений модели, масштабирование при всплесках нагрузки, работа в нескольких регионах и облаках и сборка нескольких моделей в один продукт.
Из чего состоит инфраструктура инференса
Слой сервинга
Движок инференса плюс шлюз перед ним: аутентификация, квоты, маршрутизация, переключение между бэкендами при отказе.
Оркестрация и масштабирование
Размещение моделей на оборудовании, политики автомасштабирования, динамическое распределение ресурсов между нагрузками.
Версионирование и реестр
Какая модель, какие веса, промпт и конфигурация работают и где именно; способность ответить на этот вопрос является обязательным условием безопасных изменений.
Безопасность
Контроль доступа к вызовам и к артефактам модели, защита промптов и ответов, аудит того, кто и что менял.
Управление затратами
Себестоимость обслуживания по каждой нагрузке и каждой функции; рычаги влияния: выбор модели, соответствие оборудования задаче, батчинг, маршрутизация и политика масштабирования.
InferenceOps: безопасная выкатка изменений модели
Эксплуатационная практика, которая относится к деплою моделей с той же строгостью, что и к деплою кода, но адаптирована к артефактам, у которых отказы проявляются в поведении, а не только в падениях:
- Релизный конвейер: стандартизированные процессы деплоя с предрелизной проверкой (наборы регрессионных тестов качества, контроль задержки и скорости выдачи токенов) до прихода трафика.
- Постепенная выкатка: канареечные или blue-green релизы, которые сравнивают кандидата с работающей версией на реальном трафике, с автоматическим откатом, привязанным к результату сравнения.
- Отказоустойчивость: повторы с бюджетами, таймауты, размыкатели цепи и сброс нагрузки, чтобы одна деградировавшая модель или один провайдер не вызвали каскадный отказ.
- Управление и контроль: реестр со статусом жизненного цикла, ответственными владельцами, журналами аудита и метаданными соответствия требованиям; прослеживаемость от запроса до конкретной версии модели.
- Гигиена затрат: выявление простаивающих GPU и разбор утилизации; неиспользуемые зарезервированные мощности являются самым незаметным способом сжечь бюджет.
Быстрое масштабирование и проблема холодного старта
Трафик инференса приходит всплесками, а GPU-минуты дороги в обе стороны: избыточное выделение ресурсов тратит деньги, недостаточное теряет запросы. Эластичное масштабирование для LLM сложнее классического автомасштабирования по двум причинам:
Холодные старты долгие
Новая реплика платит три счёта подряд: выделение GPU-инстанса, скачивание большого образа контейнера и загрузка десятков гигабайт весов из хранилища в память GPU. Меры противодействия работают на каждом этапе: тёплые пулы, кеширование и облегчение образов, веса на быстром локальном хранилище или их параллельная потоковая загрузка. Масштабирование до нуля экономит на простое, но перекладывает весь холодный старт на первый запрос; решайте отдельно для каждой нагрузки.
Очевидные сигналы вводят в заблуждение
Утилизация CPU мало что говорит о сервисе, который упирается в GPU, а показанная утилизация GPU может выглядеть высокой, пока чип делает мало полезной работы. Масштабируйтесь по сигналам со стороны спроса: глубина очереди, число одновременных запросов в работе и частота запросов, соотнесённые с размерами батчей, которых движок реально достигает.
Распределённый инференс, несколько регионов, несколько облаков
- Распределённый инференс охватывает два масштаба: шардирование одной модели по GPU и узлам (тензорный, конвейерный и экспертный параллелизм, о которых рассказывает оптимизация сервинга), и распределение флота реплик по зонам и кластерам с планированием, которое учитывает состояние, с проверками здоровья и восстановлением после сбоев.
- Зачем команды идут в несколько регионов или облаков: дефицит GPU и разница в цене между провайдерами и регионами, задержка для пользователя, отказоустойчивость, законы о резидентности данных (ограничения в духе GDPR привязывают часть данных к юрисдикциям) и уход от привязки к одному вендору.
- Что для этого нужно: репликация артефактов модели рядом с каждой точкой обслуживания, глобальная балансировка нагрузки с маршрутизацией по свободным мощностям и требованиям соответствия, автоматическое переключение при отказе и единая наблюдаемость с привязкой затрат к каждой локации.
- Цена вопроса: межрегиональный трафик платит реальной задержкой и платой за исходящие данные, а каждое дополнительное облако умножает эксплуатационную поверхность. По умолчанию концентрируйтесь; распределяйтесь по названной причине.
Конвейеры из нескольких моделей
Продуктовые функции редко состоят из одной модели. Ответ с дополнением из поиска соединяет в цепочку модель эмбеддингов, поисковик, часто переранжировщик, генератор и проверки безопасности; обработка документов соединяет OCR, разбор вёрстки, классификацию и суммаризацию; мультимодальные ассистенты добавляют энкодеры под каждую модальность. Сборка из специализированных моделей выигрывает у одной монолитной, когда у этапов разные требования к возможностям, разные оптимальные конфигурации железа и разное поведение при масштабировании.
- Топологии: последовательные этапы, параллельное ветвление со слиянием и условная маршрутизация между ними.
- Масштабируйте и размещайте каждый этап независимо: маленькому классификатору не нужен тот же класс GPU, что и генератору.
- Явно распределяйте бюджет задержки по всему графу и держите интерфейсы этапов стабильными; режимы отказа каждого этапа должны быть наблюдаемы, иначе диагностика превращается в угадывание.
- Это не конвейерный параллелизм (одна модель, разбитая на этапы) и не агентные циклы (динамический поток управления, который задаёт модель); граф конвейера фиксируется приложением.
Своими силами или купить, с честным подсчётом
Самостоятельно управляемая инфраструктура инференса несёт расходы, которые редко попадают в первую оценку: закупка GPU на дефицитном рынке, автомасштабирование и контроль конкурентности, построенные и настроенные вручную, оптимизации (кеширование префиксов, дизагрегация), которые платформы дают из коробки, а самодельный стек обязан реализовать сам, наблюдаемость с учётом GPU и бесконечная гонка версий движка, фреймворка и драйверов, которые должны двигаться синхронно. Добавьте прикладную обвязку (пред- и постобработка, коннекторы, поведение стриминга и кеширования для каждой модели) и дефицитных дорогих специалистов, которые всё это ведут. Взвесьте эти регулярные инженерные расходы против стоимости платформы и упущенной выгоды от того, что команда не строит; правильный ответ зависит от масштаба, и его стоит пересматривать по мере роста объёмов.