SilverTorch: индекс становится частью рекомендательной модели

Отдельные сервисы мешают совместной оптимизации

Классический поиск кандидатов передаёт данные между пользовательской моделью, индексом, проверкой допустимости и пересортировкой. Каждый этап может быть быстрым сам по себе, но сериализация, сеть и разные версии добавляют расходы.

В SilverTorch эти этапы представлены тензорами и операциями одной PyTorch-модели. Индекс становится частью поставляемого вычислительного графа, а не независимым внешним сервисом.

Фильтры и поиск подстраивают под GPU

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

Здесь ускоряется весь путь кандидата. Суммировать отдельные коэффициенты ускорения операций и объявлять их итоговым выигрышем нельзя.

Обновления не требуют полной переустановки индекса

Полные снимки сочетаются с потоком изменений: новые объекты, признаки взаимодействий и допустимость можно обновлять в тензорах. Для роста каталога используются иерархия памяти GPU, несколько ускорителей и разбиение объектов между узлами.

Как читать результаты

Авторы воспроизводили производственный трафик для каталога в 80 млн объектов при бюджете задержки менее 100 мс. Указаны 23,7-кратный рост QPS относительно выбранной традиционной архитектуры и 20,9-кратная эффективность затрат против CPU-базы. С дополнительной пересортировкой последнее сравнение составляет 13,35 раза.

Это инфраструктурные измерения в заданных условиях. Они не означают такой же рост конверсий или универсальную экономию для любого каталога; численный бизнес-эффект в публикации не раскрыт.