При масштабировании инференса больших языковых моделей (LLM) разработчики часто сталкиваются с дилеммой: либо арендовать дорогие GPU-инстансы, чтобы разместить растущий KV cache, либо мириться с медленным временем до первого токена (TTFT), когда одинаковые промпты пересчитываются при каждом запросе. Для команд, развертывающих каталог открытых моделей вроде Qwen, Llama, DeepSeek, это напрямую влияет на стоимость инфраструктуры и пользовательский опыт.
Корень проблемы — в том, как работает инференс. Во время генерации vLLM хранит ключи и значения внимания для каждого обработанного токена в KV cache, чтобы не пересчитывать их на каждом шаге. Prefix caching расширяет эту идею, переиспользуя кэш между запросами с одинаковыми начальными токенами, например, с общим системным промптом. Однако на экономичных инстансах вроде ml.g6e.4xlarge (48 ГБ на GPU) после размещения весов модели и рантайма для кэша остается ограниченная память. С ростом моделей и конкурентности cache hit rate падает, а горизонтально масштабируемые реплики vLLM держат изолированные кэши: маршрутизация на другую реплику фактически означает холодный старт.
| Strategy | Best for |
|---|---|
| prefix-aware (default) | Multi-turn dialogue, shared system prompts |
| kv-aware | Long document processing, extended sessions |
| round-robin | Stateless batch inference, load testing |
AWS предложила решение на базе SageMaker HyperPod, расширяющее иерархию кэша за пределы GPU и CPU в общий распределенный NVMe-пул. Архитектура использует два встроенных компонента HyperPod — Managed Tiered KV Cache и Intelligent Routing — и добавляет Curvine, легковесную распределенную кэш-файловую систему, как общий уровень L2. Иерархия выглядит так: L0 — GPU HBM, где работает нативный paged-attention от vLLM; L1 — CPU-память, куда LMCache сбрасывает вытесненные блоки; L2 — общий пул NVMe, смонтированный через FUSE как ReadWriteMany PVC в каждый инференс-под. Это позволяет переиспользовать KV cache между репликами на скорости, близкой к локальным дискам.
В тестовом развертывании достигнут 100% cross-Pod cache hit rate и улучшение TTFT до 2,7 раза.
В тестовом развертывании архитектура показала до 100% cross-Pod cache hit rate, улучшение TTFT до 2,7 раза и задержку чтения L2 около 56 мс для промпта примерно из 1900 токенов. Благодаря этому рабочие нагрузки, которые раньше требовали инстансов P5, теперь могут выполняться на более дешевых G6e, снижая стоимость каждого эндпоинта. Точная экономия зависит от размера модели и профиля трафика.
Для понимания: на 48-ГБ GPU модель 7B в bf16 занимает около 14 ГБ на веса, оставляя более 30 ГБ под KV-блоки, поэтому давление на L0 минимально. Но модель 32B требует около 64 ГБ весов и не помещается на один GPU даже после шардирования, оставляя мало места для кэша. Именно поэтому расширение кэша за пределы GPU становится критичным при масштабировании.
Curvine устроен просто: Primary Node (Master) управляет метаданными и журналированием, сохраняя их на Amazon EBS для надежности, а Worker-компоненты на каждом GPU-узле хранят данные на локальном NVMe (обычно /opt/dlami/nvme/curvine-data). Если Worker выходит из строя, кэш не теряется, так как данные можно восстановить из журнала. Это делает систему отказоустойчивой и простой в эксплуатации.
Решение доступно для пользователей SageMaker HyperPod, и AWS опубликовала подробное руководство по внедрению: от включения Tiered Storage до развертывания Curvine и настройки Inference Operator. Для команд, работающих с RAG-пайплайнами и многоходовыми диалогами, это практический способ сократить задержки и затраты без переписывания кода.
