ainews
Трёхуровневый KV-кеш для LLM на AWS SageMaker HyperPod: как снизить расходы на инференс без потери скорости
AWS представил архитектуру трёхуровневого KV-кеша для больших языковых моделей на SageMaker HyperPod с распределённой файловой системой Curvine. Решение позволяет переиспользовать кеш между репликами vLLM через общий пул NVMe-дисков, ускоряя time-to-first-token до 2.7 раз и достигая 100% попаданий в кеш. Это позволяет запускать тяжёлые модели на дешёвых G6e-инстансах вместо дорогих P5.
Если вы разрабатываете продукт на больших языковых моделях, расходы на инференс — это одна из главных статей затрат. Это решение показывает, как можно снизить их в разы, не жертвуя скоростью, и открывает возможность запускать сложные модели на более дешёвом железе.
Что произошло
AWS выпустил техническое решение для оптимизации инференса больших языковых моделей на SageMaker HyperPod. Проблема известная: KV-кеш (где хранятся промежуточные вычисления модели) либо не влезает в память GPU и приходится переплачивать за мощные инстансы, либо каждый запрос заново пересчитывает одно и то же, убивая скорость.
Новая архитектура строит трёхуровневую иерархию кеша: - L0 — GPU память (самый быстрый, но маленький) - L1 — оперативка CPU (подхватывает вытесненное из GPU через LMCache) - L2 — общий пул NVMe-дисков через распределённую файловую систему Curvine
Ключевой момент: все реплики vLLM теперь видят единый кеш на L2, а не живут изолированно. Специальный роутер в составе HyperPod Inference Operator направляет запросы на реплику, у которой уже есть нужные KV-блоки в кеше (prefix-aware или kv-aware стратегии).
Curvine — простая распределённая ФС: Master-нода ведёт метаданные на EBS, Worker-компоненты на каждом GPU-узле хранят данные на локальных NVMe. Всё монтируется как ReadWriteMany PVC, и для LMCache выглядит как обычная директория.
Бенчмарки на тестовом развёртывании показали 100% попаданий в кеш между подами, ускорение TTFT в 2.7 раза и задержку чтения с L2 около 56 мс для промпта на ~1900 токенов. Модели, которые раньше требовали P5-инстансов, теперь работают на G6e — это прямая экономия на инфраструктуре.
Автор: Павел Заславский · Источник: aws.amazon.com
Разработчикам. Готовая инфраструктура для шаринга KV-кеша между репликами vLLM без переписывания кода. LMCache с fs:// коннектором, Curvine как FUSE-клиент, встроенный роутер с prefix-aware/kv-aware стратегиями. Всё управляется через CRD в HyperPod Inference Operator, можно быстро поднять и тестировать на разных моделях.
Бизнесу. Возможность запускать тяжёлые модели (DeepSeek, Llama 3, Qwen) на дешёвых G6e вместо P5, снижая расходы на инференс при сохранении скорости отклика. Особенно выгодно для RAG-пайплайнов, мультитёрн-диалогов и продуктов с общими системными промптами — там кеш переиспользуется максимально. Реальная экономия зависит от профиля трафика, но инфраструктурные затраты на endpoint падают заметно.
Инвесторам. AWS атакует проблему дорогого LLM-инференса с инфраструктурной стороны. Решение снижает барьер входа для продуктов на больших моделях и усиливает позиции SageMaker против специализированных платформ вроде Anyscale, Modal. Рынок управляемого инференса растёт, и такие оптимизации критичны для удержания клиентов на AWS. Потенциально влияет на маржинальность AI-сервисов компаний, использующих AWS.
- Запуск RAG-продуктов и агентов на тяжёлых моделях (32B+) на бюджетных G6e-инстансах вместо P5 — прямая экономия на облачных расходах при масштабировании
- Сервисы с общими длинными системными промптами (чат-боты для enterprise, персональные ассистенты) получают кратное ускорение TTFT и снижение затрат на инфру
- Консалтинг по миграции LLM-инференса на SageMaker HyperPod с настройкой Curvine и оптимизацией роутинга — спрос есть у компаний, уже сидящих на AWS
- Форк и доработка Curvine под специфичные кейсы (например, персистентный кеш для редко меняющихся промптов) как open-source инструмент или SaaS-обёртка
- Продукты на базе multi-turn диалогов (обучение, терапия, кастдев-интервью) становятся экономически выгоднее — можно делать ставку на глубину сессии, а не на краткость
- Curvine — это не battle-tested продакшен-решение, а скорее эксперимент AWS. Документация скудная, community маленькое, риск столкнуться с багами в проде высокий
- Экономия сильно зависит от паттернов трафика: если промпты уникальные и короткие, выигрыш минимален, а сложность инфры растёт
- Vendor lock-in усиливается: решение заточено под AWS-экосистему (SageMaker, HyperPod, EBS), перенос на другие платформы потребует переписывания
- NVMe-диски на G6e конечны по объёму, при высокой нагрузке кеш всё равно будет вытесняться, и реальная производительность может быть ниже бенчмарков на синтетике
Техническое решение добротное, но с нюансами. AWS атакует проблему дорогого инференса с инфраструктурной стороны, и для компаний, уже сидящих на SageMaker, это может быть выигрышным ходом. Трёхуровневый кеш с общим NVMe-пулом — это не магия, а грамотная инженерия: вместо того чтобы каждая реплика жила в изоляции, они теперь видят единый кеш. Экономия реальная, особенно для RAG-пайплайнов и мультитёрн-диалогов, где промпты повторяются.
Но есть подводные камни. Curvine — это не зрелый продукт, а скорее эксперимент. Документация слабая, community почти нет, и риск словить баг в проде высокий. Плюс экономика работает только при определённом профиле трафика: если промпты уникальные и короткие, выигрыш будет минимальным, а сложность инфры вырастет. И да, это усиливает vendor lock-in на AWS. Для стартапов на ранних стадиях, возможно, проще начать с managed-решений типа Anyscale или Modal, а к HyperPod переходить, когда появится чёткое понимание паттернов нагрузки.
Комментарии