Bitrix24 détaille ce qu'elle construit autour de sa propre LLM de 1000 milliards de paramètres

Bitrix24 a expliqué au Saint HighLoad++ ce qui commence une fois qu'on a dit « nous avons déployé notre propre LLM » de 1000 milliards de paramètres. Les seuls poids d'un tel modèle occupent environ 1 To, même en FP8, soit presque un serveur entier à huit GPU. Sur ce même matériel tournent en parallèle les chats, le traitement de longs documents et les agents. L'annonce publiée sur Habr se limite à poser le problème ; les détails figurent dans l'article complet. Voici une analyse des questions d'ingénierie qui se cachent derrière.

Où s'arrête le « simple »

L'arithmétique du projet est implacable. Un paramètre en FP8 pèse un octet : un modèle de 1000 milliards de paramètres représente donc environ 1 To de mémoire avant même la première requête. En BF16, on arrive à environ 2 To ; en 4 bits, à environ 0,5 To. Huit H200 offrent 1128 Go de HBM : les poids en FP8 tiennent presque sur un seul nœud, mais il ne reste que très peu de place pour le KV-cache. La plateforme se heurte donc presque inévitablement à la parallélisation sur plusieurs nœuds et à la nécessité d'économiser la mémoire.

Le modèle lui-même n'a rien de compliqué : des poids ouverts de cette échelle existent, et il s'agit en général d'architectures MoE, où seule une partie des paramètres est active pour chaque token. Le gros du travail commence autour du modèle, et c'est précisément le sujet de l'exposé.

Trois charges sur les mêmes GPU

L'auteur part du principe que la puissance est partagée entre trois types de trafic, chacun avec ses propres exigences :

• Chats. Des requêtes courtes, avec un utilisateur qui regarde son écran. Le temps jusqu'au premier token et la stabilité de la vitesse de génération comptent.
• Longs documents. Une phase de prefill lourde, qui peut monopoliser un GPU longtemps et ralentir les autres charges.
• Agents. Des chaînes de dizaines d'appels, souvent avec un préfixe commun. Le débit est critique, tandis que la latence d'un appel isolé importe moins.

De là découlent les trois questions de l'annonce : qui attendra, comment occuper les ressources entre les pics, comment vérifier la qualité après une optimisation. La première se règle par des priorités et des files d'attente. Un chat ne doit pas rester derrière l'analyse d'un document de plusieurs milliers de pages, alors qu'un agent en arrière-plan supportera très bien une pause. La deuxième se règle en comblant les temps morts. La nuit et dans les creux entre les pics, on peut faire tourner des tâches par lots, interrompues dès que du trafic interactif arrive.

Optimisations et risque de dégradation silencieuse

La troisième question est la plus délicate. La quantification, la mise en cache des préfixes, le décodage spéculatif et les changements de batching accélèrent le système, mais peuvent dégrader les réponses sans que personne s'en aperçoive. L'erreur ne fait pas tomber le service et n'apparaît pas dans les métriques de latence. Le modèle se trompe simplement un peu plus souvent sur les faits, ou respecte moins bien le format des appels d'outils. Pour les agents, c'est critique : une seule structure JSON cassée fait échouer toute la chaîne.

La seule façon de détecter ce type de problème consiste à exécuter un jeu fixe de tâches avant et après chaque modification, puis à comparer les résultats. Ce jeu doit refléter les scénarios réels du produit : contexte long, appel de fonctions, langue russe. Les benchmarks généralistes sont ici presque inutiles.

Que vérifier avant le lancement

Pour ceux qui envisagent leur propre grand modèle, une courte liste de contrôle s'impose :

• Calculer la mémoire : poids, KV-cache pour la longueur de contexte réelle, et marge pour les pics.
• Répartir le trafic par classes et décider à l'avance quelle classe peut être retardée.
• Définir ce qui occupera les temps morts, et comment ces tâches seront interrompues.
• Constituer son propre jeu d'évaluation de la qualité avant la première optimisation, et non après.
• Mesurer non seulement la vitesse moyenne, mais aussi les queues de latence : p95 et p99 pour les chats, débit pour les agents.

L'idée centrale de l'exposé : une LLM maison de 1000 milliards de paramètres est une plateforme dotée d'un ordonnanceur, de files d'attente et d'un système de contrôle qualité, et non un simple modèle posé sur un serveur. Bitrix24 publie les chiffres précis de charge et la configuration du cluster dans la version complète de l'article sur Habr.