Contexte technique
J’ai examiné ces calculs pour Kimi K3 et tout de suite une question essentielle : parle-t-on d’un essai en laboratoire ou d’une véritable intégration IA pour la production ? Ce sont deux budgets radicalement différents, à ne pas confondre.
Si l’on prend du BF16 pour un modèle de classe 2,5–2,8T, l’estimation de 32 GPU B300 n’a rien d’extravagante. On arrive réellement à des téraoctets de HBM, un énorme cache KV, des tampons, sans oublier l’alimentation et le refroidissement qui constituent déjà un projet d’ingénierie à part entière.
Mais ensuite, cela devient plus intéressant. Avec Kimi K3, le débat ne porte pas seulement sur la taille totale du modèle, mais sur le format des poids et l’architecture de service réelle. Si l’inférence native s’exécute en MXFP4 ou MXFP8, le tableau change radicalement : on peut alors envisager 1–2 DGX B300 non pas comme une plaisanterie, mais comme un compromis viable pour un scénario à faible concurrence.
Cependant, je ne vendrais pas trop vite l’idée « un DGX et tout roule ». Sur le papier, 2,3 To de HBM sur un DGX B300 semblent suffisants, mais en pratique, la mémoire n’est pas consommée que par les poids. Il faut de la place pour le cache, les tampons de service, le routage des experts et une marge de sécurité, sinon le système vit à la limite.
C’est pourquoi des estimations du type 600–700k $ pour un seul DGX B300 en usage privé ne sont plausibles que comme scénario de recherche. En revanche, 2× DGX B300 à 1,25–1,45 M$ ressemblent davantage à la limite inférieure pour un déploiement on-premise correct avec batching, requêtes simultanées et sans bataille permanente pour chaque gigaoctet.
Je comprends parfaitement le débat BF16 contre quantification. Si vous voulez le « top sans compromis », le BF16 est logique. Mais alors le budget s’envole dans une zone où beaucoup réalisent soudainement : l’API n’était pas si chère.
Impact business et automatisation
Pour les entreprises, trois enseignements. Premièrement : un grand modèle ouvert ne signifie pas une automatisation IA bon marché. Le matériel, l’interconnexion et l’exploitation peuvent vite coûter plus cher que l’idée elle-même.
Deuxièmement : si vous avez un cas d’usage privé étroit, de la R&D ou un système de connaissances interne, 1–2 nœuds peuvent se justifier. Si vous avez besoin d’un SLA stable, d’un contexte long et de nombreux utilisateurs simultanés, économiser sur le cluster se paie ensuite en latence.
Troisièmement : beaucoup d’équipes surévaluent l’importance de « tout garder on-premise » et sous-estiment l’architecture IA hybride. Chez Nahornyi AI Lab, nous résolvons précisément ce genre d’arbitrage pour nos clients : là où l’API est avantageuse, là où un circuit privé est nécessaire et là où il vaut mieux construire une automatisation IA sur un modèle plus petit, sans facture à un million.
Si vous êtes actuellement face à un dilemme similaire entre on-premise, API et architecture personnalisée, raisonnons sur des chiffres, pas sur des impressions de forum. Chez Nahornyi AI Lab, je calcule rapidement où la mise en œuvre de l’intelligence artificielle est vraiment rentable et où il est préférable de ne pas s’offrir une coûteuse illusion de contrôle.