orbitkv

OrbitKV est une couche de cache clé-valeur externe pour les moteurs d'inférence LLM. Elle étend le cache KV de vLLM et SGLang au-delà de la mémoire GPU : les préfixes réutilisables sont conservés en DRAM et sur SSD, puis restaurés lorsqu'une requête correspondante arrive. Les cas d'usage annoncés sont les charges de travail avec documents répétés, invites système partagées et longues conversations dont les préfixes ne tiennent plus dans le cache GPU du moteur. Modèle de déploiement Un Cache Manager indépendant s'exécute par hôte, et les moteurs de cet hôte se connectent à son cache partagé. Les moteurs conservent la propriété de la mémoire GPU et de l'ordonnancement ; OrbitKV gère les répliques externes et les transferts. Le chemin mono-nœud est décrit comme testé sur GPU avec vLLM 0.29.0 et SGLang 0.5.20. Le partage de cache multi-nœuds est étiqueté expérimental, et les interfaces peuvent changer avant la 1.0. Capacités clés - Mise en cache DRAM et SSD : les préfixes peuvent être réutilisés après éviction GPU ou redémarrage du moteur tant que le Cache Manager reste actif. - Politiques de réutilisation optionnelles : un composant Rust peut protéger les pages réutilisées dans une limite d'octets et admettre sélectivement les écritures SSD ; la documentation signale un compromis de réutilisation à froid. - Transferts GPU directs : les deux moteurs enregistrent les tampons GPU via CUDA IPC ; les adaptateurs synchronisent le flux CUDA producteur, et Rust gère les requêtes de cache, les lectures et la fin des transferts. - Récupération consciente du modèle : l'identité de cache inclut les artefacts du modèle, les paramètres de calcul et la disposition de stockage. Des règles de récupération compilées sélectionnent les pages d'attention, les fenêtres glissantes et les points de contrôle récurrents/conv, y compris les dispositions combinant les trois. - Utilisation bornée des ressources : les budgets en octets couvrent les lectures en attente, les pages prêtes et les transferts GPU actifs ; l'annulation conserve les E/S soumises jusqu'à leur achèvement. - Observabilité : métriques Prometheus et chronologies de requêtes optionnelles, avec commandes de reproduction pour les mesures publiées. - Cache partagé expérimental : des fragments de catalogue embarqués localisent les répliques pairs, Mooncake Transfer Engine déplace les octets, et etcd suit l'appartenance au cluster. Aperçu du démarrage rapide Une wheel est construite et installée par runtime Python et CUDA, avec des environnements séparés pour vLLM et SGLang. La wheel inclut le Cache Manager et les bibliothèques Mooncake ; le Manager nécessite aussi un PyTorch compatible. La première version Python est décrite comme en préparation, le statut de publication du paquet doit donc être vérifié dans la documentation de version. Un Cache Manager est démarré avec une commande telle que `orbitkv-cache-manager --addr 127.0.0.1:50055 --http-addr 127.0.0.1:9091 --pool-size 8gb`. vLLM est ensuite démarré avec la mise en cache de préfixes activée et une configuration de transfert KV nommant le module connecteur OrbitKV ; SGLang est démarré avec une variable d'environnement de point de terminaison OrbitKV, une taille de page, et les options de backend external linker et radix cache. La mise en cache SSD est activée en ajoutant `--ssd-cache-path` et `--ssd-cache-capacity` à la commande du Manager ; le cache SSD est recréé au redémarrage du Manager. Le backend SSD par défaut tente cuFile natif sur les montages pris en charge et revient à io_uring. Une option `--ssd-read-path uring|cufile` sélectionne la voie de restauration à la demande indépendamment de la représentation stockée. Les options d'encodage de stockage incluent la compression sans perte nvCOMP ANS, FP8 et TurboQuant 3/4 bits, sélectionnées avec `--storage-codec` ; la valeur par défaut est le stockage exact, et les modes avec perte nécessitent une qualification de la qualité du modèle. Une hausse de la métrique `orbitkv_load_bytes_total` est donnée comme confirmation d'une restauration externe. Architecture et statut L'adaptateur de moteur identifie l'état manquant et fournit les destinations GPU ; OrbitKV sélectionne les plages en cache compatibles, les lit depuis les niveaux configurés et conserve la propriété des pages jusqu'à la fin de la copie GPU. Le KV nouvellement calculé est publié pour une réutilisation ultérieure. La même API d'adaptateur sert les récupérations DRAM, SSD et distantes expérimentales, avec le placement physique à l'intérieur du Cache Manager. Le projet documente un plan de mise en œuvre associant les mécanismes épinglés LMCache, FlexKV et Mooncake à des travaux de déploiement et de validation. Des observations de coût Rust bornées, des prédictions d'ombre par copie brute et des voies de lecture SSD indépendantes sont décrites comme implémentées ; la sélection dynamique des coûts reste prévue, et les observations sont désactivées par défaut. La conversion d'octets entre moteurs, la HA du catalogue en production et le routage de requêtes conscient du KV sont listés comme travaux prévus. Documentation de performance Les performances sont déclarées dépendre de la réutilisation des préfixes, de la capacité du cache, du stockage et de l'ordonnancement du moteur. Les rapports couvrent des comparaisons mono-nœud (HBM natif, caches CPU du moteur, OrbitKV, LMCache, FlexKV), la récupération SSD, la récupération ordinaire avec lectures hôte Qwen3-8B et transferts GPU, la préparation des requêtes, et la qualification du cache partagé. La préparation des requêtes est désactivée par défaut : les contrôles documentés pour Qwen3-8B améliorent le débit dans les deux moteurs, mais la latence P95 de SGLang régresse, et les mesures sur un seul H20 ne sont pas présentées comme un avantage universel sur les autres caches. Le code de benchmark et les résumés se trouvent dans le répertoire `benches/`. Licence et contribution OrbitKV est sous licence Apache-2.0. La documentation couvre l'installation, la configuration de l'adaptateur, les options du Manager, les métriques, la qualification des pannes, les modèles de déploiement, un guide de contribution, les détails du paquet Python, les portes de test et les versions. Les contributions doivent inclure les vérifications et modifications de documentation pertinentes.