Деплой векторного поиска на CPU: опыт внедрения Triton Inference Server в Magnit
Команда Magnit Tech перешла от классических REST-сервисов к оптимизированному решению на базе NVIDIA Triton Inference Server. Использование нативных бэкендов ONNX, динамического батчинга и кэширования позволило достичь производительности в 1000+ RPS на CPU без необходимости использования графических ускорителей.
# Векторный поиск: как Magnit задеплоил модель без GPU
Команда поиска MAGNIT OMNI столкнулась с классической дилеммой ML-инженера: модель обучена, метрики улучшены, но деплой оказался bottleneck'ом. Стандартные фреймворки, такие как FastAPI, не обеспечивали достаточной скорости ответа и требовали ручного написания сложной инфраструктуры для кэширования и мониторинга. Решением стало развертывание через NVIDIA Triton Inference Server.
«Главный недостаток старых подходов — скорость на CPU. Даже инференс одного запроса занимал около 30 мс, что категорически не устраивало. Мы искали решение, которое работало бы быстро, стабильно и имело бы инфраструктурные функции из коробки».
Выбор инструмента и отказ от Python для инференса
Изначально рассмотренные фреймворки (BentoML, нативный FastAPI) имели существенные минусы: динамическое батчинг и кэш приходилось реализовывать вручную, а гильбина интерпретатора Python (GIL) ограничивала параллелизм. Triton же предлагает нативные бэкенды, что позволило полностью исключить Python-код из пути критического запроса.
Архитектура модели базировалась на компактной русскоязычной модели BERTA (полученной дистилляцией от FRIDA). Для асимметричного поиска функционал был разделен на два независимых сервиса: один для эмбеддинга запросов (где критична скорость ответа), второй — для эмбеддинга товаров (где важнее пропускная способность).
Важнейшим шагом стало конвертация модели в формат ONNX. Оставлен только легковесный токенизатор на Python, основная обработка тензоров перешла в нативный onnxruntime бэкенд. Код развертывания свелся к размещению весов (model.onnx) и конфигурации (config.pbtxt) в репозитории, остальное Triton настроил автоматически.
*Технический нюанс:* Модель была обучена с использованием loss-функции матрешки (matryoshka-loss). Первые 192 координаты из 768-мерного вектора сохраняют почти всю смысловую нагрузку. Это позволило сократить размер вектора в 4 раза, уменьшив нагрузку на хранилище и ускорив поиск кандидатов.
Настройка производительности: кэш и батчинг
Техническая часть внедрения фокусировалась на трех ключевых параметрах конфигурации.
1. Кэширование ответов Следовательно, что три четверти запросов являются повторными, была включена функция отклика (response cache). Конфигурация позволяет использовать как локальный, так и удаленный (Redis) кэш. Для надежности при перезапуске сервиса была реализована процедура прогрева (warmup): пода прогоняет топ-N частых запросов, чтобы избежать обрушения трафика на неготовый сервер.
2. Динамическое батчинг Сервер накапливает входящие запросы в батчи для параллельной обработки. В конфиге задается предпочтительный размер батча и максимальное время ожидания (в микросекундах). Это обеспечивает баланс между задержкой первого байта и общей пропускной способностью.
3. Параллелизм и экземпляры Triton позволяет создавать несколько независимых экземпляров модели. Для сервиса запросов были выделены два экземпляра. Настройка потоков intra_op_thread_count (ядра для матричных операций) и inter_op_thread_count (независимые операции) позволила эффективно использовать все доступные ядра CPU без троттлинга системы.
Результаты бенчмарков
Тестирование проводилось на двух подах с суммарно 12 ядрами CPU. Сравнение с нативной реализацией на FastAPI и стандартным Triton с Python-бэкендом показало значительный прирост скорости.
Для сервиса запросов достигнуты следующие показатели при разной загрузке: * Производительность (RPS): От 212 до 1571 запросов в секунду при нагрузке от 10 до 105 пользователей. * Задержка (Avg Latency): Стабильно держится на уровне 45–66 мс на стороне клиента, при этом задержка непосредственно в модели (исключая кэш) составляет 110–124 мс. * Успешность: 100% успешных ответов при высокой нагрузке.
Для сервиса документов (обработка текстовых описаний товаров) задержка естественным образом выше (579–1283 мс), но пропускная способность также превышает плановые показатели.
Итоговый вывод: Решение на базе CPU с помощью Triton Inference Server обеспечило более чем 1000 RPS и высокую скорость, полностью исключив необходимость во внедрении дорогостоящих GPU-кластеров на данном этапе.
*Авторский штрих:* Как отмечал автор оригинальной статьи, после внедрения такой системы, где метрики капают сами собой, и инфраструктурный код сведен к нескольким строкам в конфиге, ML-разработчик получает уникальную возможность — наконец-то отдохнуть. А премия... она уже ждет в следующем квартале.
Методика успешно применяется командой Magnit Tech, демонстрируя, что эффективный векторный поиск доступен и на классических вычислительных ресурсах.