Как Perplexity оптимизирует встраивания на GPU

Perplexity опубликовала техническое описание своего стека для обработки векторных представлений (embeddings) на GPU — компонента, критичного для качества поиска в ИИ-системах. Исследовательская команда компании рассказала о трёх ключевых разработках: Ivy (токенизация), Tulip (батчинг запросов) и ROSE (рейтингование), которые лежат в основе модели pplx-embed и используются в поисковой системе Perplexity Search, ассистенте Computer и открытом API.

Ядро проблемы просто: качество поиска зависит от двух факторов — мощности самой модели встраивания и того, насколько дёшево её запускать на больших индексах документов. Perplexity обнаружила, что на современных GPU Hopper и Blackwell все движки уже достигли паритета по инферену модели как таковому. Поэтому выигрыш нужно искать в слое выше — в оптимизации самого инфраструктурного кода: управлении CUDA-графами, асинхронной обработке результатов и написании criticial path-ов на Rust.

Компания разделила задачу на три сценария: массовое встраивание при индексировании (нужна максимальная пропускная способность), встраивание на ходу при поиске (нужна минимальная задержка) и рейтингование уже найденных документов (компромисс между обоими). Ключевое решение — не строить отдельный engine для embeddings. Модели встраивания — это небольшие трансформеры, и их поведение на GPU похоже на prefill и decode LLM-стека, поэтому Perplexity переиспользует уже оптимизированные ядра отсюда.

Tulip берёт последовательности в порядке поступления, не перетасовывая их для лучшей упаковки. Это работает, потому что на малых последовательностях (которыми обычно и являются запросы) квадратичная сложность внимания почти не растёт — доминируют линейные слои. Как только батч насыщает GPU (около 512 токенов на малых моделях), добавление новых последовательностей не помогает. Вторая оптимизация — CUDA-графы, захватывающие всю модель целиком в один вызов, что критично для малых моделей, где издержки на запуск ядер могут быть значительнее, чем само вычисление. Так как конфигураций много, разработчики применили ленивый захват: первый вызов — разминка, второй и далее — повтор уже записанного графа. ROSE поддерживает несколько реализаций внимания (FlashInfer 2/3, FlashAttention 4) и выбирает оптимальную для каждой модели, избегая ненужного паддинга.

Для HoReCa это релевантно в контексте встроенных ИИ-сервисов и приложений: если заведение интегрирует поиск по своему каталогу блюд, отзывов или ингредиентов через ИИ, то такая инфраструктура снижает издержки на инферен и отклик. Однако практическое применение сложно предсказать без информации о том, планирует ли Perplexity открывать API для встраивания на базе этого стека и каковы будут цены. Статья не раскрывает, будет ли эта оптимизация доступна внешним разработчикам или остаётся внутренним инструментом Perplexity.