- Quel problème PegaFlow résout-il pour le déploiement vLLM ?
- Comment PegaFlow s'intègre-t-il avec vLLM ?
- Qu'apporte l'architecture Novita AI ?
- Quels résultats de performance sont publics ?
- Quand le cache KV externe est-il le plus utile ?
- Comment les développeurs peuvent-ils inspecter PegaFlow aujourd'hui ?
- Que doivent vérifier les équipes plateforme avant de l'adopter ?
- FAQ
- Conclusion
- Articles recommandés
Cache KV externe PegaFlow pour vLLM
Un démarrage 2,15x plus rapide est le chiffre clé de l’article conjoint vLLM et Novita AI PegaFlow, mais le point profond est architectural : l’inférence LLM en production a besoin d’une propriété du cache KV en dehors d’un seul processus moteur d’inférence. PegaFlow fait du cache KV un service autonome afin que les déploiements vLLM puissent préserver, partager et dimensionner le cache entre les redémarrages, les instances locales et les nœuds distants.
Cet article donne la perspective de Novita AI sur les raisons pour lesquelles nous avons construit PegaFlow, ce que montre l’intégration publique vLLM, quelles affirmations sont déjà étayées par le code source, et comment les développeurs peuvent inspecter l’implémentation open source aujourd’hui.
Explorez le dépôt GitHub PegaFlow ou lisez l’article conjoint vLLM x Novita AI pour la présentation technique complète.
Quel problème PegaFlow résout-il pour le déploiement vLLM ?
PegaFlow résout la fragilité du cache KV local au processus dans l’inférence LLM à haut débit. Lorsque le cache KV vit uniquement à l’intérieur d’un seul processus moteur vLLM, un état de cache utile peut disparaître lors des redémarrages, rester enfermé dans une seule instance, ou ne pas se déplacer efficacement entre les nœuds.
Cela devient coûteux lorsque les charges de travail réutilisent des invites longues, acheminent des requêtes similaires entre répliques, ou séparent le travail de préremplissage et de décodage. Le cache peut déjà contenir un travail que le système ne devrait pas recalculer, mais la topologie de déploiement ne peut pas toujours le réutiliser.
PegaFlow change cette frontière. Il s’exécute en tant que service de cache KV externe, implémenté avec un noyau Rust, et se connecte à vLLM via le mécanisme de connecteur KV externe plutôt qu’un fork à long terme.
Comment PegaFlow s’intègre-t-il avec vLLM ?
PegaFlow s’intègre avec vLLM via kv_transfer_config, PegaKVConnector, et kv_connector_module_path. Dans l’article publié, le connecteur permet à PegaFlow de prendre en charge les opérations clés du cache KV à l’exécution tandis que vLLM continue de gérer l’ordonnancement, l’exécution du modèle, le regroupement par lots et le chemin de service compatible OpenAI.
Le dépôt public liste actuellement vLLM comme prêt dans son tableau d’intégration de frameworks et montre cette configuration de connecteur dans le démarrage rapide :
vllm serve Qwen/Qwen3-0.6B \
--kv-transfer-config '{"kv_connector": "PegaKVConnector", "kv_role": "kv_both", "kv_connector_module_path": "pegaflow.connector"}'
L’avantage pratique est un modèle de propriété plus clair : vLLM reste le moteur de service, tandis que PegaFlow possède le stockage, le transfert, le partage du cache KV externe et l’observabilité du cache associée.
Qu’apporte l’architecture Novita AI ?
L’objectif de conception de Novita AI est de faire en sorte que le cache KV se comporte comme une infrastructure de service de production, et non comme une mémoire de processus temporaire. Cela signifie que PegaFlow est conçu autour d’une frontière de service autonome, d’un chemin de données Rust, de pools de cache partagés et d’un stockage multicouche.
| Choix architectural | Pourquoi cela importe pour les développeurs | Source publique |
|---|---|---|
| Service side-car indépendant | Le cache KV peut survivre aux redémarrages du moteur d’inférence et évoluer séparément du processus vLLM. | README PegaFlow |
| Noyau Rust sans GIL | Le chemin chaud du cache évite la surcharge Python et maintient les threads du moteur d’inférence concentrés sur le service. | README PegaFlow |
| Mémoire hôte épinglée, mémoire distante RDMA et cache SSD | Le cache peut couvrir une mémoire locale plus rapide, une mémoire de nœud distant et une capacité SSD plus grande. | Article vLLM |
| Métriques Prometheus et export OTLP | Les opérateurs peuvent observer le comportement du cache plutôt que de traiter la réutilisation KV comme un détail caché du moteur. | README PegaFlow |
Dernière vérification : 2026-05-20. Ces détails proviennent de l’article conjoint vLLM et du README public novitalabs/pegaflow.
Quels résultats de performance sont publics ?
Les affirmations de performance publiques doivent être lues comme des résultats d’évaluation de PegaFlow provenant de l’article conjoint vLLM et du benchmark du dépôt, et non comme des garanties génériques pour chaque charge de travail. Le taux de succès du cache, la réutilisation des invites, la forme du modèle, le matériel, la topologie réseau et le routage des requêtes affectent tous les déploiements réels.
| Scénario | Résultat rapporté | Source |
|---|---|---|
| Démarrage vLLM avec un pool de cache hôte de 500 GiB pré-acquis | Démarrage 2,15x plus rapide | Article conjoint vLLM |
| Huit instances Qwen3-8B partageant un cache hôte | Débit 56 % plus élevé | Article conjoint vLLM |
| DeepSeek-V3.2 MLA avec TP8 | Débit 72 % plus élevé | Article conjoint vLLM |
| Lectures distantes sur cluster RDMA interne | Débit moyen de lecture distante 194 Go/s | Article conjoint vLLM |
| Benchmark de référence H800, Llama-3.1-8B, cache chaud vs froid | TTFT moyen réduit de 572,5 ms à 61,5 ms ; P99 TTFT réduit de 1113,7 ms à 77,0 ms | README PegaFlow |
Dernière vérification : 2026-05-20. Le nombre RDMA est décrit dans l’article source comme un résultat de cluster interne, il doit donc rester présenté comme une donnée d’évaluation rapportée plutôt qu’une promesse de débit universel.
Quand le cache KV externe est-il le plus utile ?
Le cache KV externe est le plus utile lorsque la réutilisation des invites est suffisamment élevée pour que le recalcul devienne visible dans la latence, le débit ou l’utilisation du GPU. Il est moins utile pour les charges de travail où presque chaque requête est unique et où la réutilisation du cache est naturellement faible.
- Redémarrages fréquents : garder le cache en dehors du moteur peut réduire les pénalités de redémarrage lorsque l’état du cache reste utile.
- Service multi-instances : partager le cache hôte peut réduire le travail de préremplissage en double entre les instances vLLM locales.
- Déploiements multi-nœuds : le cache distant basé sur RDMA peut rendre des blocs KV utiles disponibles au-delà d’une seule machine.
- Désagrégation préremplissage/décodage : le cache externe peut donner au système de service un point de passage plus clair entre les étapes.
Pour Novita AI, cela fait partie d’un principe d’infrastructure plus large : les systèmes d’IA en production ont besoin que le moteur de service, la couche mémoire, la couche de routage et la couche d’observabilité évoluent indépendamment lorsque les schémas de trafic deviennent complexes.
Comment les développeurs peuvent-ils inspecter PegaFlow aujourd’hui ?
Les développeurs peuvent inspecter le dépôt GitHub public et installer les packages publiés référencés par le README. Le dépôt documente un package CUDA 12, un package CUDA 13, un exemple de connecteur vLLM, la configuration du serveur, la configuration P2P RDMA, le routage préremplissage/décodage, les métriques et les objectifs du projet.
uv pip install pegaflow-llm # CUDA 12
uv pip install pegaflow-llm-cu13 # CUDA 13
La commande serveur locale la plus simple dans le README est :
pegaflow-server
Pour une évaluation en production, commencez par votre propre profil de réutilisation d’invites, modèle cible, topologie GPU, capacité mémoire et hypothèses RDMA ou SSD. PegaFlow est une infrastructure pour la réutilisation du cache ; la charge de travail détermine la valeur à capter.
Que doivent vérifier les équipes plateforme avant de l’adopter ?
Les équipes plateforme doivent valider PegaFlow par rapport à leur propre topologie de service avant de traiter les chiffres de référence publics comme des intrants de planification. Le bon test n’est pas seulement cache froid contre cache chaud, mais si la réutilisation du cache apparaît dans le schéma de trafic qui entraîne réellement le coût ou la latence.
- Mesurez la réutilisation des invites et le taux de succès attendu du cache KV sous routage réel.
- Comparez le comportement au redémarrage avec et sans cache KV possédé en externe.
- Testez le partage multi-instances sur un seul nœud avant de passer au RDMA.
- Vérifiez l’observabilité : succès du cache, échecs, latence de transfert, pression mémoire et comportement SSD.
- Confirmez la compatibilité de version avec le chemin du connecteur vLLM utilisé dans votre déploiement.
C’est aussi pourquoi la frontière open source est importante. Les développeurs peuvent inspecter le connecteur, la configuration du serveur, les métriques et la configuration du benchmark plutôt que de se fier à un service de cache en boîte noire.
FAQ
Qu’est-ce que PegaFlow ?
PegaFlow est un moteur de stockage de cache KV open source pour l’inférence LLM de Novita AI. Il s’exécute en tant que service indépendant et se connecte à vLLM via le chemin du connecteur KV externe.
PegaFlow nécessite-t-il un fork de vLLM ?
Non. L’article publié sur vLLM décrit PegaFlow se connectant via kv_transfer_config et PegaKVConnector, avec des packages externes chargés via kv_connector_module_path.
Quels résultats de performance sont publics ?
L’article conjoint vLLM rapporte un démarrage 2,15x plus rapide, un débit 56 % plus élevé dans une configuration de cache hôte partagé, un débit 72 % plus élevé pour une configuration DeepSeek-V3.2 MLA, et 194 Go/s de débit moyen de lecture distante dans un cluster RDMA interne. Le README rapporte également des réductions de TTFT H800 pour un benchmark de référence à cache chaud.
Où les développeurs peuvent-ils essayer PegaFlow ?
Les développeurs peuvent consulter le dépôt public novitalabs/pegaflow, installer pegaflow-llm pour CUDA 12 ou pegaflow-llm-cu13 pour CUDA 13, et suivre le démarrage rapide du dépôt.
Conclusion
PegaFlow est le travail de Novita AI sur le cache KV externe pour l’inférence LLM en production avec vLLM : un service de cache autonome, un chemin de données Rust, des pools de cache partagés et une frontière de connecteur qui évite un fork de vLLM. Le point clé est simple : lorsque le cache KV devient une infrastructure plutôt qu’un état local au processus, les équipes de service obtiennent plus de contrôle sur les redémarrages, le partage, la mise à l’échelle et l’observabilité. Examinez le dépôt PegaFlow, comparez les résultats publics avec votre propre charge de travail, et utilisez l’infrastructure développeur plus large de Novita AI lorsque vous avez besoin d’API de modèle, d’exécution d’agent ou de workflows GPU autour de cette pile de service.
