# LMCache и Mooncake: сравнивайте компонент, а не только проект

Сравнение интеграции LMCache с транспортом и хранилищем Mooncake: пересечения ролей, совместные пути и критерии проверки конкретной нагрузки.

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/lmcache-vs-mooncake-kv-cache/
Language: ru

Запрос «LMCache или Mooncake» понятен как начало исследования, но не определяет сравниваемые компоненты. LMCache предоставляет интеграции кэширования для движков инференса. Проект Mooncake включает транспорт и хранение, используемые в системах сервинга. Некоторые пути пересекаются, другие сочетаются. Поэтому начинать стоит с реальной границы интеграции, а не с выбора названия проекта или количества его упоминаний в чужих схемах.

## Сначала уточните смысл Mooncake

Официальный [репозиторий Mooncake](https://github.com/kvcache-ai/Mooncake/) описывает несколько компонентов и интеграций. Transfer engine отличается от store, и ни одно название само по себе не обозначает полный endpoint обслуживания запросов с моделью.

Запишите недостающую возможность: хранение контекста за пределами GPU, передачу блоков между разнесёнными фазами либо общее состояние кластера. Затем укажите предложенные для неё коннектор и компонент. Две команды могут говорить об использовании Mooncake, имея в виду существенно разные пути работы и границы ответственности.

## Разместите LMCache на той же границе

[Обзор LMCache MP](https://docs.lmcache.ai/mp/) описывает отделённый от воркеров сервис кэша с настраиваемыми уровнями. Сравнивайте выбранную интеграцию с путём Mooncake того же назначения, а не с несвязанным микротестом транспорта.

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

## Учитывайте сочетание уровней

[Плагин Mooncake для NIXL](https://github.com/ai-dynamo/nixl/blob/main/src/plugins/mooncake/README.md) показывает появление компонента за другой абстракцией. Его существование подтверждает, что экосистема состоит не только из взаимоисключающих продуктов. Однако совместимость каждой произвольной комбинации из этого не следует.

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

## Сравните на общей нагрузке

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

Измеряйте полезные завершения, хвост первого токена, переданные байты и давление RAM и хранилища. Отдельно записывайте работу настройки и восстановления. Прекрасная тёплая передача мало полезна, когда реальные запросы редко возвращаются к контексту. Развитое удержание помогает только при повторении состояния в пределах полезного срока жизни.

## Сформулируйте условный вывод

Укажите документированную конфигурацию, соответствующую нагрузке и эксплуатации, неподдерживаемые сочетания и резервный путь отказа. Не объявляйте один проект универсально быстрее или готовее к эксплуатации по несопоставимым результатам разных моделей.

После сравнения читатель должен определить нужный ему компонент и построить воспроизводимую проверку. Выбор проекта кэширования не создаёт спрос, не гарантирует принятия провайдером и не устраняет задержку передачи между физически удалёнными компьютерами. Эти условия сети и рынка остаются самостоятельными вопросами проектирования сервиса.

## Материалы по теме

[Prefix caching: когда повторяющийся контекст помогает GPU-пулу](/ru/journal/prefix-caching/), [KV-кеш и экономика GPU: зачем считать память активных запросов](/ru/journal/kv-cache-economics/).