Documentation
Hiérarchie
Les noms ci-dessous sont ceux qu'on utilise d'ordinaire pour hiérarchiser le KV Cache d'inférence. GPUCache est G3.5. Ce n'est pas un autre nom pour G4.
Le chemin actuel utilise CPU/TCP avec copies hôte ; FileStore est un backend de référence CPU persistant. DPU/NVMe/GDS dans le tableau reste une cible. RDMA réel, GDS et BlueField-3 restent NOT_RUN_HARDWARE. Les tests froids utilisent un mock ; RustFS réel n’est pas qualifié.
| Couche | Support | Portée | Rôle pour le KV Cache | Produit |
|---|---|---|---|---|
| G1 | HBM du GPU | Un GPU | KV chaud utilisé pendant la génération | — |
| G2 | DRAM de l'hôte | Un nœud | Relais et tampon du KV déchargé du HBM | — |
| G3 | SSD NVMe local au nœud | Un nœud | KV tiède pour une réutilisation courte. Pas de partage entre nœuds. | — |
| G3.5 | Flash NVMe partagé, géré par un DPU et joint par Ethernet ou RDMA | Partagé dans un pod GPU ou un cluster | Couche chaude de KV Cache réutilisable, ramenée vers G2 ou G1 quand il le faut. Une perte est un miss ; on recalcule, puis on réécrit. | GPUCache (en développement) |
| G4 | Stockage réseau partagé (stockage objet) | Échelle du centre de données | Données froides durables : modèles, jeux de données, historique de session, produits d'inférence | RustFS |
La même pile, dessinée
- G1HBM
- G2DRAM
- G3NVMe
- G3.5GPUCache
- G4RustFS
G3.5 est le bloc Signal. Il se partage plus simplement que le SSD local de G3, et il est plus proche du chemin chaud d'inférence que le stockage partagé de G4.
La limite entre G3.5 et G4
GPUCache ne prend pas en charge la durabilité. Si un nœud G3.5 tombe ou si une donnée est perdue, le framework d'inférence voit un miss, refait le préremplissage comme il le ferait déjà, réécrit le résultat dans GPUCache, et l'usage suivant peut toucher.
Le contexte et les produits qui doivent rester longtemps vont à RustFS en G4. La couche chaude peut être recalculée. La couche de capacité est l'endroit où les données doivent rester.