Dans son explication technique publiée le 22 octobre 2026, Cerebras répartit le modèle Kimi K3, qui compte environ 3 000 milliards de paramètres, sur 59 processeurs WSE-3T. Ce calcul repose sur des poids quantifiés sur 4 bits, un cache KV sur 8 bits et des requêtes moyennes supposées de 256 000 tokens. Il décrit un exemple d’architecture, pas une configuration universelle.
Pourquoi l’exemple de Kimi K3 mobilise 59 wafers
Chaque wafer WSE-3T dispose de 44 Go de SRAM, une mémoire vive intégrée à la puce. Cerebras estime qu’avec des poids sur 4 bits, les paramètres de Kimi K3 représentent environ 1,5 téraoctet, soit près de 16 Go par couche pour ses 93 couches : 69 à attention linéaire et 24 denses. Le cache KV, qui conserve des informations nécessaires au traitement des tokens déjà pris en compte, est supposé utiliser 8 bits par valeur.
Cerebras place deux couches à attention linéaire sur chaque wafer et une couche dense sur chaque wafer. Dans le second cas, une couche d’environ 16 Go laisse près de 28 Go de SRAM pour le cache KV. Comme les 69 couches linéaires ne se divisent pas exactement par deux, leur répartition demande 35 wafers ; les 24 couches denses en mobilisent 24.
| Type de couche | Nombre de couches | Couches par wafer | Wafers dans l’exemple | Mémoire prévue par wafer |
| Attention linéaire | 69 | 2 | 35 | Environ 32 Go pour les poids des deux couches |
| Dense | 24 | 1 | 24 | Environ 16 Go pour les poids, 28 Go restants pour le cache KV |
Comment les requêtes circulent dans la chaîne de traitement
Les poids restent associés aux wafers auxquels les couches ont été attribuées. Pendant le traitement, les activations, c’est-à-dire les données intermédiaires produites par le modèle, passent d’une étape à l’autre. Cerebras décrit leur transfert par RDMA sur Ethernet. RDMA, ou accès direct à la mémoire à distance, désigne ici le mode de transfert entre ces étapes ; l’entreprise indique environ 2 microsecondes par saut.
Ce chiffre concerne un saut entre étapes, pas le temps nécessaire à une requête complète. La chaîne peut aussi traiter plusieurs requêtes en parallèle : chacune peut se trouver à une étape différente. Les micro-lots, qui regroupent plusieurs requêtes pour le traitement, influent sur le compromis décrit par Cerebras : les plus petits favorisent la vitesse de réponse par requête, tandis que les plus grands favorisent le débit total.
Ce que recouvre l’estimation d’environ 190 requêtes
Cerebras estime qu’environ 190 requêtes simultanées pourraient tenir dans les 28 Go réservés au cache sur un wafer associé à une couche dense, en comptant quelque 147 Mo de cache pour une requête de 256 000 tokens. C’est un calcul arrondi fondé sur les hypothèses de l’exemple, pas une capacité de service observée.
La taille de la requête est déterminante pour ce résultat : le chiffre de 190 est lié à l’hypothèse de 256 000 tokens et au cache sur 8 bits. Il ne décrit donc pas une capacité fixe indépendante de la configuration.
L’accès par SDK ne répartit pas les couches sur les wafers
La répartition physique des couches et l’intégration d’un modèle dans une application relèvent de deux niveaux distincts. La documentation de l’AI SDK pour Cerebras décrit les deux voies d’accès : AI Gateway peut donner la préférence à Cerebras, mais basculer vers un autre fournisseur disponible du même modèle si Cerebras est indisponible ou si la requête échoue.
Pour un accès direct au fournisseur, l’AI SDK documente @ai-sdk/cerebras et la variable CEREBRAS_API_KEY. Cette voie est prévue pour utiliser les API propres à Cerebras ou des paramètres de connexion personnalisés ; elle ne constitue pas une méthode de placement des couches sur les wafers.
