Об этом проекте

OrbitKV — это внешний слой кэша ключей-значений для движков вывода LLM. Он расширяет KV-кэш vLLM и SGLang за пределы памяти GPU: переиспользуемые префиксы хранятся в DRAM и SSD, а затем восстанавливаются при поступлении совпадающего запроса. Заявленные сценарии использования — рабочие нагрузки с повторяющимися документами, общими системными промптами и длинными диалогами, префиксы которых больше не помещаются в GPU-кэш движка. Модель развёртывания На каждом хосте работает независимый Cache Manager, и движки на этом хосте подключаются к его общему кэшу. Движки сохраняют владение памятью GPU и планированием; OrbitKV управляет внешними репликами и передачами. Одноузловой путь описан как протестированный на GPU с vLLM 0.29.0 и SGLang 0.5.20. Многоузловое разделение кэша помечено как экспериментальное, и интерфейсы могут измениться до 1.0. Ключевые возможности - Кэширование в DRAM и SSD: префиксы можно переиспользовать после вытеснения из GPU или перезапуска движка, пока Cache Manager остаётся активным. - Опциональные политики переиспользования: компонент на Rust может защищать переиспользуемые страницы в пределах лимита в байтах и выборочно допускать записи в SSD; в документации отмечается компромисс холодного переиспользования. - Прямые передачи GPU: оба движка регистрируют буферы GPU через CUDA IPC; адаптеры ограждают производящий поток CUDA, а Rust обрабатывает запросы к кэшу, чтения и завершение передачи. - Восстановление с учётом модели: идентичность кэша включает артефакты модели, настройки вычислений и раскладку хранения. Скомпилированные правила восстановления выбирают страницы внимания, скользящие окна и рекуррентные/conv-чекпоинты, включая раскладки, объединяющие все три. - Ограниченное использование ресурсов: бюджеты в байтах покрывают ожидающие чтения, готовые страницы и активные передачи GPU; отмена сохраняет отправленный ввод-вывод до завершения. - Наблюдаемость: метрики Prometheus и опциональные таймлайны запросов, с командами воспроизведения для опубликованных измерений. - Экспериментальный общий кэш: встроенные фрагменты каталога находят одноранговые реплики, Mooncake Transfer Engine перемещает байты, а etcd отслеживает членство в кластере. Краткое руководство по началу работы Колесо (wheel) собирается и устанавливается для каждой среды выполнения Python и CUDA, с отдельными окружениями для vLLM и SGLang. Колесо включает Cache Manager и библиотеки Mooncake; Manager также требует совместимый PyTorch. Первый релиз Python описан как подготавливаемый, поэтому статус публикации пакета следует проверять в документации по релизам. Cache Manager запускается командой вида `orbitkv-cache-manager --addr 127.0.0.1:50055 --http-addr 127.0.0.1:9091 --pool-size 8gb`. Затем vLLM запускается с включённым кэшированием префиксов и конфигурацией передачи KV, указывающей модуль коннектора OrbitKV; SGLang запускается с переменной окружения конечной точки OrbitKV, размером страницы и опциями внешнего линкера и бэкенда radix-кэша. Кэширование в SSD включается добавлением `--ssd-cache-path` и `--ssd-cache-capacity` к команде Manager; SSD-кэш пересоздаётся при перезапуске Manager. Бэкенд SSD по умолчанию пытается использовать нативный cuFile на поддерживаемых монтированиях и откатывается к io_uring. Переопределение `--ssd-read-path uring|cufile` выбирает маршрут восстановления по требованию независимо от хранимого представления. Опции кодирования хранилища включают lossless-сжатие nvCOMP ANS, FP8 и 3/4-битный TurboQuant, выбираемые с помощью `--storage-codec`; по умолчанию используется точное хранение, а режимы с потерями требуют квалификации качества модели. Рост метрики `orbitkv_load_bytes_total` приводится как подтверждение внешнего восстановления. Архитектура и статус Адаптер движка определяет отсутствующее состояние и предоставляет назначения GPU; OrbitKV выбирает совместимые кэшированные диапазоны, читает их из настроенных уровней и сохраняет владение страницами до завершения копирования на GPU. Нововычисленный KV публикуется для последующего переиспользования. Тот же API адаптера обслуживает DRAM, SSD и экспериментальные удалённые выборки, с физическим размещением внутри Cache Manager. Проект документирует план реализации, сопоставляющий механизмы закреплённых LMCache, FlexKV и Mooncake с работами по развёртыванию и валидации. Наблюдения ограниченной стоимости Rust, теневые предсказания необработанного копирования и независимые маршруты чтения SSD описаны как реализованные; динамический выбор стоимости остаётся запланированным, а наблюдения по умолчанию отключены. Преобразование байтов между движками, промышленная HA каталога и маршрутизация запросов с учётом KV перечислены как запланированная работа. Документация по производительности Утверждается, что производительность зависит от переиспользования префиксов, ёмкости кэша, хранилища и планирования движка. Отчёты охватывают одноузловые сравнения (нативный HBM, CPU-кэши движков, OrbitKV, LMCache, FlexKV), восстановление из SSD, обычное восстановление с хостовыми чтениями Qwen3-8B и передачами GPU, подготовку запросов и квалификацию общего кэша. Подготовка запросов по умолчанию отключена: задокументированные контроли Qwen3-8B повышают пропускную способность в обоих движках, но P95-задержка SGLang ухудшается, и измерения на одном H20 не представлены как универсальное преимущество перед другими кэшами. Код бенчмарков и сводки находятся в каталоге `benches/`. Лицензирование и вклад OrbitKV лицензирован под Apache-2.0. Документация охватывает установку, конфигурацию адаптера, опции Manager, метрики, квалификацию отказов, шаблоны развёртывания, руководство для контрибьюторов, детали пакета Python, тестовые шлюзы и релизы. Ожидается, что вклад будет включать соответствующие проверки и изменения документации.