Bitrix24 descreve o que constrói em torno de uma LLM própria de 1 trilhão de parâmetros

A Bitrix24 contou no Saint HighLoad++ o que começa depois da frase «subimos nossa própria LLM» de 1 trilhão de parâmetros. Só os pesos de um modelo desse porte ocupam cerca de 1 TB, mesmo em FP8, ou seja, quase um servidor inteiro com oito GPUs. No mesmo hardware rodam, ao mesmo tempo, chats, processamento de documentos longos e agentes. O anúncio no Habr apresenta apenas a formulação do problema; os detalhes ficaram no artigo completo. A seguir, uma análise das questões de engenharia que há por trás dele.

Onde termina o «simples»

A conta do projeto é dura. Um parâmetro em FP8 ocupa um byte, então um modelo de 1 trilhão de parâmetros consome cerca de 1 TB de memória antes mesmo da primeira requisição. Em BF16, seriam cerca de 2 TB; em 4 bits, cerca de 0,5 TB. Oito H200 somam 1128 GB de HBM, de modo que os pesos em FP8 quase cabem em um único nó, e sobra muito pouco para o KV-cache. Por isso, a plataforma quase inevitavelmente esbarra na necessidade de paralelizar entre vários nós e de economizar memória.

O modelo em si, porém, não tem nada de complicado: existem pesos abertos nessa escala, geralmente arquiteturas MoE, em que apenas parte dos parâmetros fica ativa por token. O trabalho principal começa em torno dele, e é a isso que a palestra se dedica.

Três cargas nas mesmas GPUs

O autor parte do princípio de que três tipos de tráfego dividem os mesmos recursos, cada um com requisitos próprios:

• Chats. Requisições curtas, com o usuário olhando para a tela. O que importa são o tempo até o primeiro token e a velocidade estável de geração.
• Documentos longos. Um estágio de prefill pesado, que pode ocupar a GPU por bastante tempo e atrasar as demais cargas.
• Agentes. Cadeias com dezenas de chamadas, muitas vezes com prefixo comum. O que importa é a vazão; a latência de cada chamada isolada pesa menos.

Daí vêm as três perguntas do anúncio: quem espera, o que colocar nos recursos entre os picos e como verificar a qualidade depois de uma otimização. A primeira se resolve com prioridades e filas. Um chat não pode ficar parado atrás da análise de uma página gigantesca, enquanto um agente em segundo plano suporta uma pausa sem problemas. A segunda se resolve preenchendo os períodos ociosos. À noite e nos vales entre os picos, é possível rodar tarefas em lote, que são interrompidas quando chega tráfego interativo.

Otimizações e o risco de degradação silenciosa

A terceira pergunta é a mais incômoda. Quantização, cache de prefixos, decodificação especulativa e mudanças no batching aceleram o sistema, mas podem piorar as respostas sem que ninguém perceba. O erro não derruba o serviço e não aparece nas métricas de latência. O modelo apenas confunde fatos com um pouco mais de frequência ou mantém pior o formato de chamada de ferramentas. Para agentes, isso é crítico: uma única estrutura JSON quebrada derruba a cadeia inteira.

A única forma de pegar esse tipo de problema é rodar um conjunto fixo de tarefas antes e depois de cada mudança e comparar os resultados. O conjunto deve incluir cenários reais do produto: contexto longo, chamada de funções, idioma russo. Benchmarks genéricos são quase inúteis nesse caso.

O que verificar antes de subir

Quem pensa em ter um modelo grande próprio deve percorrer uma lista curta:

• Calcular a memória: pesos, KV-cache com o comprimento de contexto real e folga para os picos.
• Dividir o tráfego por classes e combinar de antemão qual classe pode ser atrasada.
• Definir o que vai preencher a ociosidade e como essas tarefas são interrompidas.
• Montar um conjunto próprio de avaliação de qualidade antes da primeira otimização, e não depois.
• Medir a velocidade média e também as caudas de latência: p95 e p99 para chats, vazão para agentes.

A ideia central da palestra é que uma LLM própria de 1 trilhão de parâmetros é uma plataforma com escalonador, filas e sistema de controle de qualidade, e não um único modelo num servidor. A Bitrix24 divulga os números concretos de carga e a configuração do cluster na versão completa do material no Habr.