Le service de modèles plus petits de Cloudflare réduit la mémoire, mais la sécurité devient le test décisif
Le service de modèles plus petits de Cloudflare permet désormais de faire tenir deux fois plus de contexte Kimi dans la mémoire GPU, au prix d’un traitement légèrement plus lent aux niveaux de concurrence habituels. L’entreprise compresse également les poids de GLM et vérifie les pages de cache partagées avant que les opérations de décodage prises en charge ne les lisent. Ensemble, ces changements transforment la mémoire GPU, d’un plafond fixe, en une ressource que Cloudflare peut gérer activement.
C’est important, car les modèles Kimi de Moonshot AI et les modèles GLM de Z.ai ne sont pas de simples ajouts à un catalogue d’inférence. Ils combinent un grand nombre de paramètres, de longues fenêtres de contexte et des architectures mixture-of-experts. Un modèle mixture-of-experts active des parties sélectionnées de son réseau pour chaque token, réduisant les calculs sans rendre ses poids stockés plus légers.
Le conflit ne se résume pas à Cloudflare face à un autre fournisseur d’inférence. Il oppose une utilisation dense à une isolation sûre sur du matériel partagé. Regrouper davantage de requêtes sur un même GPU améliore l’économie et le débit total, mais accroît aussi les conséquences d’une gestion défaillante du cache.
Cloudflare affirme que sa nouvelle configuration préserve la précision des modèles tout en augmentant la capacité. Toutefois, la plupart des mesures à l’appui proviennent de la propre suite d’évaluation et de l’infrastructure de Cloudflare. Le prochain test consistera à vérifier si ces gains restent stables selon les charges de travail, les générations de matériel et des volumes de production bien plus élevés.
Ce que Cloudflare a modifié pour Kimi et GLM
Cloudflare a combiné trois techniques mémoire parce qu’aucune optimisation unique ne résout le service de modèles à l’échelle des modèles de pointe.
L’entreprise a détaillé ces changements dans un article technique du 3 août. Elle applique une quantification FP8 au cache KV de Kimi, une compression INT4 aux poids de GLM et des balises d’intégrité aux pages de cache partagées. Chaque technique répond à une contrainte différente du même système d’inférence.
Un cache KV stocke les clés et les valeurs d’attention créées pour les tokens que le modèle a déjà traités. Il permet à un modèle de poursuivre une conversation sans recalculer l’intégralité du prompt avant chaque token généré. Les prompts longs et les requêtes simultanées font rapidement croître ce cache.
Cloudflare stocke les données de cache de Kimi K2.6 en FP8 e4m3 plutôt qu’en BF16. FP8 utilise huit bits pour chaque valeur à virgule flottante, contre seize pour BF16. Cette conversion réduit de moitié l’empreinte mémoire du cache.
Selon Cloudflare, le contexte disponible en mémoire passe d’environ 686 000 tokens à environ 1,37 million de tokens. Il s’agit d’une capacité agrégée sur le déploiement testé, et non d’une nouvelle limite de fenêtre de contexte pour un utilisateur. Cette distinction est importante, car l’optimisation augmente principalement la concurrence.
Cloudflare a apporté une modification distincte pour GLM 5.2. L’entreprise a compressé les poids du modèle de FP8 vers INT4, une représentation entière sur quatre bits. Le checkpoint serait passé de 705 Go à 421 Go, soit environ 40 pour cent.
Un déploiement tensor-parallèle à huit voies répartit le modèle sur huit GPU. Dans cette configuration, Cloudflare affirme que l’utilisation de mémoire est passée d’environ 88 Go à 52 Go par GPU. L’espace restant peut accueillir environ 1,18 million de tokens de cache KV.
Le troisième changement protège le cache partagé créé par ce regroupement plus dense. Chaque page de cache physique reçoit une balise qui change chaque fois que la page est réallouée. Le serveur enregistre les pages et les balises attendues par chaque requête.
Avant que les opérations de décodage prises en charge ne lisent ces pages, Cloudflare vérifie les mappages. Une incohérence interrompt la requête concernée. Le système devrait ainsi échouer en mode fermé au lieu de lire des données associées à une autre requête.
Ces techniques s’inscrivent au-dessus de l’architecture plus large de Cloudflare pour les grands modèles. L’entreprise avait auparavant décrit l’inférence Infire comme un moteur basé sur Rust conçu pour son réseau GPU distribué. Elle sépare également le préremplissage et le décodage dans différents pools de ressources.
Le préremplissage traite un prompt entrant et crée son état de cache initial. Le décodage génère la réponse token par token. Ces phases sollicitent les GPU différemment, ce qui permet à Cloudflare d’optimiser chaque pool séparément.
Cette séparation est essentielle à la nouvelle conception. Cloudflare conserve les caches BF16 et les poids FP8 là où le calcul domine. L’entreprise utilise des représentations plus petites lorsque la capacité mémoire ou la bande passante devient la ressource limitante.
Le résultat n’est pas une configuration de modèle universellement compressée. Il s’agit d’un système de service conscient des phases, qui change de formats selon la charge de travail. Cela crée davantage de complexité opérationnelle, mais évite d’imposer un compromis unique à l’ensemble de la requête.
Pourquoi les caches plus petits de Cloudflare l’emportent sur la vitesse brute
La quantification du cache KV de Kimi gagne en admettant davantage de travail, et non en accélérant chaque requête individuellement.
Cloudflare a testé le décodage de Kimi K2.6 sur un déploiement H200 désagrégé. Avec une requête simultanée, le cache BF16 a délivré 137 tokens par seconde. La version FP8 en a délivré 125, rendant le cache compressé plus lent à cette charge.
La tendance s’est poursuivie à mesure que la concurrence augmentait. À huit requêtes, BF16 a atteint 731 tokens par seconde, contre 689 pour FP8. À seize requêtes, les mesures étaient de 1 106 et 1 028 tokens par seconde.
BF16 a atteint 1 558 tokens par seconde à 32 requêtes simultanées. Cependant, il a alors épuisé la mémoire disponible. Cloudflare indique que le cache FP8 a continué jusqu’à 64 requêtes et a délivré 2 192 tokens par seconde.
Ce chiffre final est environ 41 pour cent supérieur au débit mesuré le plus élevé de BF16. Cloudflare rapporte également un coût par token inférieur d’environ 30 pour cent. Le gain vient de davantage de travail effectué sur le même déploiement, et non de l’accélération de chaque requête à faible charge.
Cette distinction évite un titre facile mais trompeur. La quantification introduit un travail de conversion lorsque le noyau d’attention lit les valeurs mises en cache. À concurrence équivalente, les résultats BF16 de Cloudflare sont restés plus rapides de plusieurs points de pourcentage.
La quantification du cache KV de Kimi ne devient utile qu’une fois que les limites de mémoire empêchent le format plus volumineux d’accepter davantage de requêtes. Elle échange une efficacité modeste par requête contre une capacité totale bien plus élevée. C’est un compromis judicieux lorsque la demande reste suffisamment élevée pour exploiter l’espace ajouté.
Elle est moins utile lorsque le trafic est faible. Un déploiement ne traitant que quelques requêtes simultanées absorberait le surcoût de conversion sans utiliser la capacité supplémentaire. L’approche de Cloudflare dépend donc de l’orientation d’un volume suffisant de travail compatible vers chaque pool de décodage.
C’est là que l’infrastructure mondiale devient stratégiquement pertinente. Les grands fournisseurs peuvent agréger le trafic de nombreux clients et maintenir des accélérateurs coûteux occupés. Les opérateurs plus petits font souvent face à une demande irrégulière, ce qui les empêche de capter les mêmes gains d’utilisation.
Cloudflare utilise déjà l’affinité de session et le cache de préfixes dans Workers AI. Le cache de préfixes réutilise l’état calculé de débuts de prompts identiques. Son déploiement de grands modèles a exposé l’utilisation de tokens mis en cache et introduit un en-tête d’affinité de session pour un meilleur routage du cache.
La nouvelle optimisation cible une couche différente. Le cache de préfixes évite le travail de préremplissage répété, tandis que FP8 augmente la capacité de décodage. La combinaison des deux peut réduire les calculs dupliqués et admettre davantage de séquences actives.
Cloudflare a comparé la précision sur plusieurs évaluations. Sur GSM8K, BF16 a obtenu 94.24 contre 94.09 pour FP8. Les résultats MMLU étaient respectivement de 89.11 et 89.04.
Le cache FP8 a obtenu 67.49 sur ARC-Challenge, contre 66.72 pour BF16. Sur MMLU-Pro, FP8 a enregistré 79.29 tandis que BF16 atteignait 80.29. La validité des appels d’outils a été mesurée à 92.6 pour cent pour FP8 et 92.2 pour cent pour BF16.
Cloudflare décrit ces résultats comme indiscernables. Cette conclusion est plausible dans le cadre de la suite rapportée, mais les scores ne prouvent pas une équivalence universelle. De faibles variations numériques peuvent affecter des prompts rares, de longues traces d’agents ou des tâches en dehors des évaluations sélectionnées.
Plusieurs tests produisent également des sorties non déterministes. Un faible écart de score peut refléter l’échantillonnage, le bruit d’évaluation ou la quantification. Les lecteurs auraient besoin d’essais répétés et d’intervalles de confiance pour distinguer ces causes.
Le benchmark interne mcxams de l’entreprise a produit des résultats identiques, les deux configurations réussissant 61 tests sur 63. Les évaluations internes peuvent bien refléter les besoins de production, mais les observateurs externes ne peuvent pas inspecter indépendamment leur couverture.
La quantification du cache KV de Kimi doit donc être jugée comme un résultat opérationnel accompagné de preuves de qualité encourageantes. Ce n’est pas une conclusion générale selon laquelle chaque modèle peut utiliser en toute sécurité des valeurs de cache FP8. Les distributions d’attention et la sensibilité numérique diffèrent selon les architectures.
La véritable réussite de Cloudflare est d’avoir identifié le point où le changement de format est rentable. Le préremplissage reste limité par le calcul, l’entreprise conserve donc son cache en BF16. Le décodage devient limité par la mémoire, ce qui rend la représentation FP8 plus compacte utile à des niveaux de concurrence plus élevés.
Ce choix étaye la thèse centrale. Une meilleure inférence ne signifie pas toujours accélérer une requête. À grande échelle, elle consiste souvent à accomplir davantage de travail utile avant que le matériel n’atteigne son plafond de mémoire.
La véritable compétition se joue sur la mémoire par token utile
L’hébergement de modèles de pointe dépend de plus en plus de l’efficacité mémoire plutôt que des seuls nombres de paramètres affichés.
Kimi K2.6 appartient à une famille de modèles qui combine de grands volumes de poids stockés avec des fonctionnalités de long contexte et d’agents. La documentation actuelle du modèle de Cloudflare indique une fenêtre de contexte de 262 144 tokens, des entrées visuelles, l’appel d’outils et des sorties structurées.
Ces capacités créent des besoins mémoire qui se chevauchent. Les poids du modèle doivent rester accessibles pendant la génération. Chaque conversation active construit également un cache KV croissant, tandis que le regroupement impose au serveur de suivre simultanément de nombreuses séquences.
Un modèle peut tenir dans la mémoire GPU tout en restant coûteux à servir. Si ses poids laissent peu de place aux pages de cache, chaque déploiement prend en charge moins d’utilisateurs actifs. Les lots inactifs ou insuffisamment remplis gaspillent alors une capacité d’accélérateur coûteuse.
C’est cette compétition que les représentations plus compactes de Cloudflare cherchent à modifier. La métrique pertinente devient le nombre de tokens utiles produits par unité de mémoire, dans des limites acceptables de latence et de qualité. La vitesse brute pour une requête ne révèle qu’une partie du système.
Cette évolution met aussi sous pression les fournisseurs qui dépendent principalement de piles d’inférence standard. Si deux services utilisent un matériel et des poids de modèle similaires, celui qui gère mieux le cache peut accepter davantage de travail simultané. Il peut également répartir les coûts fixes d’infrastructure sur davantage de tokens générés.
Toutefois, les améliorations logicielles n’effacent pas les différences matérielles. Les GPU H200 offrent une importante mémoire à large bande passante, tandis que les systèmes Blackwell plus récents ajoutent d’autres capacités de basse précision. Les résultats d’une configuration d’accélérateur ne se transfèrent pas automatiquement à une autre.
La forme du trafic compte tout autant. Les agents de programmation peuvent soumettre de grands prompts, réutiliser des préfixes, appeler des outils et poursuivre sur de nombreux tours. Les sessions de chat grand public peuvent utiliser des prompts plus courts et présenter des schémas de suivi moins prévisibles.
Une charge de travail agentique peut conserver une séquence en mémoire plus longtemps. Cela augmente la valeur de la capacité de cache, mais rend aussi la planification plus difficile. Une requête exceptionnellement longue peut occuper de la mémoire pendant que de nombreuses requêtes plus petites attendent.
La conception désagrégée de Cloudflare pour le préremplissage et le décodage répond à ce déséquilibre. L’ingestion des prompts, intensive en calcul, s’exécute dans un pool. La génération, sensible à la mémoire, s’exécute dans un autre, ce qui permet à chaque pool de passer à l’échelle et d’utiliser différents formats numériques.
Cette conception introduit également des coûts de coordination. L’état du cache doit être déplacé ou rester accessible à travers la frontière entre les phases. Les décisions de routage doivent tenir compte de la mémoire disponible, des préfixes existants, de la profondeur des files d’attente et de la longueur attendue de chaque réponse.
Le projet SGLang fournit le framework de serving utilisé dans les expérimentations et le trafic de production de Cloudflare. Cloudflare indique collaborer avec le projet afin d’y intégrer en amont des correctifs et des fonctionnalités. Certaines améliorations deviennent ainsi disponibles au-delà d’un seul fournisseur.
Une infrastructure ouverte peut réduire l’écart logiciel entre les grandes plateformes et les opérateurs indépendants. L’expérience de déploiement reste toutefois importante. Un kernel ou une fonctionnalité d’ordonnancement publiés ne procurent pas automatiquement le volume de trafic, la télémétrie ou la planification de capacité de Cloudflare.
Cette différence rend la pression concurrentielle indirecte. Cloudflare ne présente pas Kimi ou GLM comme des modèles exclusifs. L’entreprise soutient que son infrastructure peut exploiter efficacement des modèles de pointe à poids ouverts, afin de les proposer dans un accès partagé et serverless.
Les développeurs de modèles bénéficient également de cet arrangement. Moonshot AI et Z.ai peuvent atteindre des utilisateurs qui ne souhaitent pas provisionner des clusters multi-GPU. Un support d’hébergement plus large peut accroître l’adoption et générer davantage de retours sur des charges de travail réelles.
En contrepartie, le fournisseur assume une responsabilité plus exigeante. Il doit préserver le comportement du modèle tout en transformant les formats numériques. Il doit aussi empêcher que l’état du cache d’un tenant affecte la sortie d’un autre tenant.
Les opérateurs les plus solides optimiseront donc simultanément trois variables : la capacité mémoire, la qualité des sorties et l’isolation. N’en améliorer que deux crée un service instable. Une densité accrue sans isolation soulève des préoccupations de sécurité, tandis que la compression sans tests de qualité risque d’introduire des régressions silencieuses.
Pour les acheteurs, le leadership dans les benchmarks reste pertinent, mais incomplet. Un modèle impressionnant n’est utile que si la couche de serving fournit une latence prévisible et des appels d’outils corrects. De longues files d’attente peuvent effacer la valeur pratique d’un modèle plus puissant.
Les développeurs doivent également distinguer la qualité du modèle de celle du fournisseur. Un même checkpoint Kimi ou GLM peut se comporter différemment selon l’hôte en raison de la quantification, des paramètres d’échantillonnage par défaut, des politiques de cache et du logiciel de serving.
Une évaluation en production doit mesurer des tâches complètes, et non des réponses isolées. Parmi les indicateurs utiles figurent la validité des appels d’outils, les taux de timeout, la cohérence sur les longues sessions et la latence sous une concurrence réaliste. Ces métriques révèlent si l’optimisation de la mémoire améliore réellement l’application.
La compression des poids de GLM modifie le compromis entre les phases
La compression des poids de GLM accélère le décodage, car des poids plus petits réduisent le trafic mémoire, mais elle ralentit la phase de préremplissage, plus intensive en calcul.
Cloudflare a converti les poids de GLM 5.2 de FP8 vers INT4. Lors du décodage, le système lit à répétition les poids du modèle depuis la mémoire GPU à haute bande passante. Déplacer moins d’octets peut produire chaque token plus rapidement lorsque la bande passante mémoire est le facteur limitant.
Le résultat à faible concurrence était le plus net. Avec une requête, FP8 générait 60 tokens par seconde, tandis qu’INT4 atteignait 92. Cela représente un gain rapporté de 55 %.
Avec huit requêtes concurrentes, le débit est passé de 425 à 513 tokens par seconde. Le gain était de 21 %. Avec seize requêtes, INT4 a produit 825 tokens par seconde, contre 683 pour FP8.
L’amélioration restait visible à charge plus élevée. INT4 a atteint 1 267 tokens par seconde avec 32 requêtes, contre 994 pour FP8. Avec 64 requêtes, les résultats respectifs étaient de 1 933 et 1 672.
La compression des poids de GLM n’apporte pas le même bénéfice pendant le préremplissage. Les poids INT4 doivent être étendus avant la multiplication matricielle. Cloudflare a mesuré environ 8 660 tokens de préremplissage par seconde pour INT4, contre 10 160 pour FP8.
Utiliser INT4 partout sacrifierait donc le débit de traitement des prompts. Cloudflare conserve plutôt FP8 pour le préremplissage et attribue INT4 au décodage. Cette séparation préserve le format le plus performant mesuré pour chaque phase.
Cette constatation fait écho aux travaux antérieurs de Cloudflare sur la compression de poids sans perte. Ce projet a exploré plusieurs chemins d’exécution, car les tailles de batch et les formes de matrices modifient l’équilibre entre décompression et calcul.
L’approche GLM actuelle emploie une quantification avec perte, plutôt que cette méthode antérieure sans perte. La conversion des poids FP8 vers INT4 représente davantage de valeurs dans un nombre réduit d’états possibles. Les tests de précision deviennent essentiels, car les poids originaux ne peuvent pas être reconstruits exactement.
Cloudflare a signalé des écarts inférieurs à 0,8 point sur les benchmarks évalués. MMLU a atteint en moyenne 86,60 pour FP8 et 86,54 pour INT4. Les scores exacts de MMLU-Pro étaient de 80,80 et 80,47.
Sur la précision ARC-Challenge, FP8 a enregistré 64,93 % et INT4 64,85 %. Les deux formats ont réussi 62 cas sur 63 dans le benchmark interne mcxams de Cloudflare.
GSM8K a montré un écart un peu plus large. FP8 a atteint 94,39 % de correspondance exacte, tandis qu’INT4 a atteint 93,56 %. Une notation flexible a produit 94,24 et 93,48 %.
Cloudflare affirme que la qualité du modèle compressé est indiscernable. Les chiffres publics étayent un faible écart moyen, mais ils laissent plusieurs questions ouvertes. L’entreprise n’a pas publié de résultats pour tous les comportements agentiques ou multilingues.
GLM est couramment utilisé pour le codage, l’utilisation d’outils et les tâches multilingues. Les benchmarks académiques généraux ne capturent pas tous les modes de défaillance dans ces contextes. Un argument de fonction mal formé peut avoir plus d’importance qu’une faible variation de précision moyenne.
Les rares défaillances numériques sont particulièrement difficiles à détecter. Un benchmark peut montrer une qualité agrégée stable, alors qu’un modèle compressé modifie son comportement sur des prompts inhabituels. De longues traces de raisonnement peuvent amplifier une différence précoce.
Cela ne rend pas INT4 inadapté. Cela signifie que les décisions de déploiement nécessitent des tests spécifiques à la charge de travail et une surveillance continue. Les fournisseurs devraient comparer la configuration exacte du modèle reçue par les utilisateurs, et non seulement un checkpoint de référence.
La même prudence s’applique aux affirmations de vitesse. Les tokens par seconde dépendent de la longueur des entrées, de la longueur des sorties, du batching, du matériel, des kernels et de l’ordonnancement. Les mesures de Cloudflare décrivent son système testé, et non un niveau de performance GLM universel.
La séparation des phases offre néanmoins une leçon architecturale utile. La quantification ne devrait pas être considérée comme une décision d’exportation statique unique. Un fournisseur peut maintenir plusieurs représentations et orienter le calcul vers le format adapté à chaque étape.
Cette flexibilité a un coût. Plusieurs formats de poids consomment du stockage et compliquent le déploiement. Les ingénieurs doivent vérifier la compatibilité, sélectionner les bons kernels et empêcher la dérive de configuration entre les pools de GPU.
La discipline opérationnelle détermine si cette complexité est rentable. Si une requête atteint le mauvais pool ou qu’une révision du modèle modifie le comportement numérique, les gains théoriques de débit importent peu. L’automatisation et l’observabilité deviennent elles-mêmes partie intégrante de l’optimisation.
Les résultats rapportés par Cloudflare montrent pourquoi les fournisseurs acceptent cette complexité. Un checkpoint 40 % plus petit libère une mémoire considérable pour les séquences actives. Un décodage plus rapide améliore alors la latence au moment où les utilisateurs voient les tokens arriver.
Le compromis est concret plutôt qu’abstrait. La compression des poids de GLM achète de la capacité et de la vitesse de décodage au prix d’un risque numérique accru et d’un surcoût de préremplissage. Cloudflare gère cet arbitrage en limitant le format à la phase où il l’emporte.
La sécurité du cache KV partagé devient un enjeu de production
Une densité GPU plus élevée augmente la valeur de chaque page de cache, tout en rendant un suivi défaillant de la propriété plus dangereux.
L’attention paginée divise le stockage du cache KV en blocs réutilisables, plutôt que d’exiger une allocation continue par requête. Le batching continu ajoute et retire ensuite des séquences tandis qu’un GPU reste occupé. Ensemble, ces méthodes réduisent le gaspillage de mémoire.
Elles créent aussi un problème exigeant de tenue des registres. Les pages de cache physiques sont constamment attribuées, lues, libérées et réattribuées. Le système de serving doit préserver le mappage correct entre chaque séquence logique et ses pages physiques.
Un mappage obsolète pourrait conduire une requête à lire une page incorrecte. Cela pourrait corrompre la réponse, faire échouer l’opération ou exposer un état associé à une autre séquence. La conséquence exacte dépend de la défaillance et des contrôles environnants.
Cloudflare indique que des erreurs très rares deviennent opérationnellement pertinentes à son volume de requêtes. Son article utilise une erreur sur un milliard comme seuil illustratif. Cette déclaration décrit le besoin de protection, et non un taux d’incidents divulgué.
Le mécanisme d’intégrité de l’entreprise associe un tag évolutif à chaque page physique. Une requête enregistre les tags qu’elle attend. Les opérations de décodage prises en charge valident ces valeurs avant de lire le cache partagé.
Une divergence de tag interrompt la requête concernée. Cette conception privilégie une défaillance explicite plutôt qu’un résultat fondé sur un état erroné. Elle s’apparente aux compteurs de génération utilisés dans d’autres systèmes de gestion de mémoire.
Cloudflare a évalué la vérification sur un modèle de production de taille intermédiaire utilisant deux workers de préremplissage et deux workers de décodage. Les tests employaient des entrées de 8 192 tokens et des sorties de 1 000 tokens. La concurrence rapportée allait de un à huit.
Le débit a diminué de 0,38 à 0,79 % dans ces tests. L’augmentation de latence p95 allait de 0,42 à 0,80 %. Cloudflare affirme que même la borne supérieure de l’intervalle de confiance est restée proche de 1 %.
L’entreprise exécute la validation comme une vérification de batch distincte. Elle a évité de fusionner l’opération dans le kernel d’attention, car les groupes de threads GPU pourraient créer une condition de concurrence. Un tracker no-op reste disponible pour les déploiements où la vérification est désactivée.
Ces résultats font apparaître les contrôles d’intégrité comme peu coûteux. Toutefois, l’évaluation ne couvrait pas toutes les tailles de modèles, formes de séquences ou niveaux de concurrence. Elle se concentrait aussi sur les opérations de décodage prises en charge, une précision qui mérite attention.
Les lecteurs ne devraient pas interpréter le mécanisme comme une preuve complète de l’isolation des tenants. L’intégrité du cache est une couche défensive au sein d’un système de serving plus vaste. Le routage, l’allocation mémoire, l’exactitude des kernels et l’isolation des processus restent pertinents.
La vérification peut détecter une discordance de génération de page comprise par son tracker. Elle ne peut pas identifier automatiquement chaque erreur numérique ou défaut logiciel. Un tag valide ne prouve pas que le contenu de la page est sémantiquement correct.
Il existe également une tension entre le déploiement optionnel et une protection universelle. Cloudflare indique que la vérification d’intégrité est activée par déploiement. Son objectif déclaré est de rendre cette fonctionnalité suffisamment peu coûteuse pour qu’elle reste activée partout.
D’ici là, les clients ne peuvent pas supposer que chaque chemin de modèle bénéficie de la même protection. Une documentation claire sur la couverture aiderait les développeurs à évaluer le risque restant. Des tests de sécurité indépendants apporteraient des preuves plus solides que les seules mesures de performance.
Le raisonnement de sécurité reflète néanmoins une évolution importante de l’ingénierie de l’inférence. Les fonctionnalités de performance exigent désormais un raisonnement explicite sur l’état inter-requêtes. L’optimisation de la mémoire ne peut plus être évaluée uniquement à l’aide de graphiques de débit.
La compression intensifie ce besoin. Les caches Kimi en FP8 permettent à davantage de requêtes de rester actives. Les poids GLM en INT4 créent davantage d’espace pour les pages de cache. Ces deux changements augmentent la quantité d’état partagé gérée par un déploiement.
Le principal adversaire de cette histoire est donc la densité non sécurisée. L’objectif n’est pas d’atteindre le remplissage maximal à tout prix. Il s’agit d’augmenter l’utilisation tout en préservant les frontières entre requêtes et un comportement de modèle acceptable.
L’approche de Cloudflare place la vérification de sécurité près de la ressource partagée. Elle peut ainsi détecter des erreurs d’allocation avant que les données mises en cache n’entrent dans une opération d’attention. Une terminaison précoce limite également la propagation d’un état corrompu.
Les requêtes interrompues affectent tout de même la fiabilité. Si les vérifications commencent à échouer fréquemment, les utilisateurs verront des erreurs ou des nouvelles tentatives, même lorsque l’isolation fonctionne comme prévu. Les opérateurs doivent suivre les taux de discordance, enquêter sur leurs causes et empêcher les tempêtes de retries.
Cloudflare n’a pas communiqué de taux d’écart en production dans l’article. Cette métrique manquante compte davantage que le seul surcoût synthétique. Une vérification peu coûteuse est utile, mais sa valeur opérationnelle devient plus claire lorsqu’elle signale des détections réelles.
L’entreprise a également intérêt à présenter cette nouvelle densité comme sûre. Ses éléments de preuve doivent être considérés comme une communication technique de l’opérateur du système. Ils sont informatifs, mais ne valent pas un audit indépendant.
Pour les développeurs, l’enseignement plus large est concret. L’inférence partagée masque la complexité de l’infrastructure, mais ne l’élimine pas. Les évaluations des fournisseurs devraient intégrer les contrôles d’isolation, la gestion des défaillances et la transparence sur les incidents, en plus de la latence et de la qualité des modèles.
Ce qu’il faut surveiller à mesure que les optimisations se généralisent
Trois signaux montreront si le service de modèles plus petits de Cloudflare devient un avantage durable ou reste une configuration spécialisée.
Le premier signal est un déploiement plus large des caches FP8. Cloudflare indique étendre les caches KV FP8 à une plus grande partie de sa flotte. Une couverture sur davantage de modèles et de matériels montrerait que la quantification du cache KV de Kimi se généralise au-delà d’une seule configuration mesurée.
Les éléments utiles comprendraient des données sur la concurrence, la latence de queue et la qualité pour différentes longueurs de séquence. Des résultats stables sur ces dimensions renforceraient l’argument de Cloudflare en faveur de l’efficacité mémoire. De fréquentes exceptions propres à certains modèles l’affaibliraient.
Le deuxième signal est la validation de NVFP4 sur les GPU Blackwell. NVFP4 est le format à virgule flottante sur quatre bits de Nvidia pour les matériels plus récents. Cloudflare indique tester cette représentation comme une autre voie vers des poids plus compacts.
Un déploiement réussi pourrait étendre la compression des poids de GLM au-delà de INT4 et modifier à nouveau l’équilibre entre prefill et decode. Il testerait aussi la capacité de Cloudflare à transposer sa stratégie tenant compte des phases entre plusieurs générations d’accélérateurs.
Le résultat important n’est pas un unique chiffre de débit maximal. Surveillez la latence de bout en bout, les évaluations de qualité et la capacité mémoire sous regroupement de production. Ces mesures montreront si une précision plus faible procure des gains utiles au niveau des applications.
Le troisième signal est une couverture universelle de l’intégrité des caches. Cloudflare veut activer des vérifications partout à un coût négligeable. Atteindre cet objectif relierait une densité plus élevée à un contrôle de sécurité cohérent par défaut.
Les informations de couverture devraient identifier les modèles, opérations et matériels pris en charge. Les métriques de détection apporteraient encore plus de valeur, notamment si Cloudflare explique la fréquence des écarts et leurs causes.
Ces signaux sont importants parce que les éléments de preuve actuels de l’entreprise sont solides mais limités. Ils montrent des gains significatifs sur certains modèles et déploiements. Ils n’établissent pas que chaque charge de travail bénéficie des mêmes formats.
Les développeurs devraient tester les systèmes Kimi et GLM hébergés avec des invites, chaînes d’outils et niveaux de concurrence réalistes. Suivez le délai avant le premier token, la vitesse de génération, les taux de dépassement de délai et le taux de réussite des tâches complètes. Comparez le comportement après les mises à jour des modèles côté fournisseur.
Les équipes devraient également conserver leur propre historique d’évaluation. Une base de connaissances d’ingénierie consultable peut relier les résultats de benchmarks, les incidents, les changements de configuration et les annonces des fournisseurs. Ce contexte aide à distinguer une régression du modèle d’un changement d’infrastructure.
Cloudflare a déplacé le débat sur les modèles de pointe au-delà de la simple disponibilité. La question la plus difficile est de savoir si un fournisseur peut maintenir des modèles volumineux rapides, économiques, précis et isolés en situation de concurrence réelle. Surveillez les trois signaux de déploiement, puis évaluez le système sur des charges de travail complètes plutôt que sur un seul benchmark ou graphique de débit.
