Введение
Все больше наших клиентов стремятся самостоятельно управлять своими операциями в сфере ИИ и данными. На практике это означает запуск моделей с открытыми весами на собственной инфраструктуре с использованием проприетарных данных, которые никогда не покидают периметр компании.
При запуске собственных моделей на собственных графических процессорах (GPU) максимальное использование ресурсов имеет первостепенное значение. Когда речь заходит о выводе (inference), загрузка уже сохраненного KV-кэша — это простой способ добиться такой эффективности. Чтобы узнать больше о KV-кэшировании, ознакомьтесь с этим блогом. Вкратце: для каждого нового входного запроса к LLM мы сохраняем вычисленные KV-векторы из этапа предварительного заполнения (prefill). Затем, когда аналогичный запрос обращается к тому же префиксу, мы загружаем соответствующий KV-кэш, освобождая GPU для вычисления новых, ранее не встречавшихся запросов вместо повторного вычисления уже известных данных.
В этом блоге рассматриваются несколько способов использования решений для хранения данных Everpure в связке с LMCache.
Что такое LMCache?
LMCache — это решение для KV-кэширования с открытым исходным кодом, которое работает как уровень управления KV-кэшем, разработанный для вывода LLM. Оно преобразует эфемерные данные KV-кэша в долговечные, повторно используемые знания, специфичные для ИИ, которые можно хранить постоянно и совместно использовать между несколькими движками обслуживания. Используя LMCache, системы достигают сокращения времени до первого токена (TTFT) и повышенной пропускной способности, что дает значительные преимущества для рабочих нагрузок с длинным контекстом, таких как многоходовые диалоги, агентные задачи и RAG.
Созданный с учетом нейтральности к поставщикам, LMCache легко интегрируется в широкую экосистему движков обслуживания с открытым исходным кодом, фреймворков вывода, бэкендов хранения, аппаратных платформ и поставщиков инфраструктуры.
LMCache может работать в двух режимах: внутрипроцессном (in-process) и многопроцессном (multi-process).
Рисунок 1: Режимы работы LMCache. Source.
Варианты хранения Everpure FlashBlade для LMCache
Everpure предоставляет несколько платформ хранения, которые могут использоваться LMCache в зависимости от вашей среды и требований.
FlashBlade//S™ — это гибкая масштабируемая платформа для корпоративных неструктурированных данных, поддерживающая такие рабочие нагрузки, как ИИ, аналитика, резервное копирование и быстрое восстановление с независимым масштабированием производительности и емкости.
FlashBlade//EXA™ расширяет семейство для самых требовательных сред облачных GPU и приложений ИИ, обеспечивая экстремальную пропускную способность и производительность в огромных масштабах.
Примеры интеграции LMCache и FlashBlade
Следующие примеры показывают, как интегрировать LMCache с Everpure™ FlashBlade®.
Важно отметить, что результаты и преимущества добавления LMCache зависят от самой среды. Среды с разными GPU, сетевым оборудованием и версиями программного обеспечения нельзя сравнивать напрямую.
В этой среде используются:
- ЦП: 1x Intel Xeon Gold 5515+, 32 ядра
- Ядро Linux: 6.8.0-124
- GPU: NVIDIA L40S, 46 068 МБ, SM 8.9
- Сетевые карты: 1x 100 GbE для S3, 1x 100 GbE для GDS
- NFSv3 с nconnect=16 и proto=rdma
- lmcache==0.5.3
- vllm==0.24.0
Внутрипроцессный режим с FlashBlade GPU Direct Storage (GDS)
Бэкенд GDS в LMCache использует NVIDIA cuFile (или AMD hipFile) для ввода-вывода с нулевым копированием между памятью GPU и смонтированной файловой системой, избегая использования буфера промежуточного хранения ЦП. Это путь с наименьшей задержкой на выделенных узлах вывода с Everpure FlashBlade.
Чтобы запустить LMCache внутрипроцессно с GDS, мы используем следующий файл определений lmcache.yaml:
Мы запускаем vLLM, указывая LMCACHE_CONFIG_FILE. Вот полная используемая команда:
Внутрипроцессный режим с FlashBlade S3
LMCache поставляется с коннектором S3, а FlashBlade поддерживает S3 нативно. Для мультиарендных или распределенных по нескольким площадкам парков серверов объектная семантика обычно является более простым операционным решением: идентификация и политики настраиваются для каждого бакета, а не для каждого монтирования, и нет необходимости управлять конфигурацией монтирования на стороне клиента во всем большом парке.
Чтобы запустить LMCache внутрипроцессно с S3, мы используем следующий файл определений lmcache.yaml:
Мы запускаем vLLM, указывая LMCACHE_CONFIG_FILE. Вот полная используемая команда:
vllm serve openai/gpt-oss-20b \ --port 8000 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-model-len 131072 \ --disable-hybrid-kv-cache-manager \ --kv-transfer-config '{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}' \ --no-enable-prefix-caching
Многопроцессный режим с L1 CPU и L2 FlashBlade NFS
В отличие от внутрипроцессного режима, при запуске LMCache в многопроцессном режиме процесс lmcache и процесс vLLM разделены. Это позволяет нескольким процессам vLLM использовать общую службу LMCache.
Следует отметить, что в этих двойных конфигурациях L1 основан на памяти, а L2 используется только тогда, когда LRU вытесняет кэш-попадание. По этой причине мы не будем демонстрировать эту конфигурацию в наших результатах, так как, по сути, результаты L2 сопоставимы с результатами внутрипроцессного GDS.
Сначала мы запускаем LMCache с помощью команды lmcache server и задаем соответствующие настройки L1 и L2 для нашей интеграции:
Затем мы запускаем нашу службу vLLM с определенной службой LMCache:
Результаты
Здесь мы видим разницу во времени до первого токена (TTFT) для каждой из различных настроек LMCache по сравнению с холодным, некэшированным предварительным заполнением (без LMCache). TTFT — это мера задержки перед тем, как LLM начинает отвечать, и она определяет, насколько быстрой или «вязкой» кажется модель. Более быстрый TTFT обеспечивает лучший пользовательский опыт.
Без кэширования модели требуется 33,5 секунды для ответа при длине контекста 128K. Чем длиннее контекст, тем больше время отклика. С LMCache на FlashBlade S3 или GDS TTFT при длине контекста 128K составляет 3,4 и 1,9 секунды соответственно.
Рисунок 2: Время до первого токена с LMCache и без него.
Ниже мы видим улучшение TTFT для различных бэкендов LMCache. FlashBlade используется с S3 и GDS (NFS через RDMA). FlashBlade поддерживает оба варианта на одной системе, поэтому вы можете выбрать протокол, который лучше всего соответствует вашим потребностям. Обратите внимание, что улучшение TTFT увеличивается по мере увеличения длины контекста.
Рисунок 3: Улучшение времени до первого токена с LMCache на FlashBlade S3 и GDS.
Сквозная пропускная способность токенов также существенно увеличивается при использовании LMCache с бэкендами FlashBlade. Эталонный показатель достигает пика на 32K, а затем снижается, поскольку предварительное заполнение растет быстрее, чем генерируемые токены. Однако пропускная способность токенов как для FlashBlade S3, так и для GDS продолжает расти вплоть до 128K контекста, на котором тестирование было остановлено из-за ограничений длины контекста используемой модели.
Рисунок 4: Сквозная пропускная способность токенов с LMCache и без него.
Улучшение сквозной пропускной способности токенов также продолжает расти по мере увеличения длины контекста. Прирост пропускной способности увеличился до 4,97 раза для FlashBlade с GDS и до 4,10 раза для FlashBlade с S3.
Рисунок 5: Улучшение пропускной способности с LMCache на FlashBlade S3 и GDS.
Заключение
Независимо от того, нужна ли вам «сырая» пропускная способность GDS с нулевым копированием на FlashBlade или операционная простота S3 для мультиарендных парков экземпляров, хранилище Everpure предоставляет LMCache долговечный и высокопроизводительный бэкенд, необходимый для превращения KV-кэша из побочного продукта в повторно используемый актив. Результатом является более низкий TTFT, более высокая пропускная способность и GPU, занятые вычислением новой работы вместо повторного вычисления того, что уже было обработано — и все это на инфраструктуре, которой вы владеете и управляете.
