Bitrix24 describe qué construye en torno a su propio LLM de 1 billón de parámetros

Bitrix24 contó en Saint HighLoad++ qué empieza después de decir «hemos desplegado nuestro propio LLM» de 1 billón de parámetros. Solo los pesos de un modelo así ocupan cerca de 1 TB incluso en FP8, es decir, casi un servidor entero de ocho GPU. En ese mismo hardware trabajan a la vez los chats, el procesamiento de documentos largos y los agentes. El anuncio en Habr se limita a plantear el problema; los detalles quedaron para el artículo completo. A continuación, un repaso de las cuestiones de ingeniería que hay detrás.

Dónde termina lo «sencillo»

La aritmética del proyecto es estricta. Un parámetro en FP8 pesa un byte, así que un modelo de 1 billón de parámetros equivale a unos 1 TB de memoria antes de la primera petición. En BF16 serían cerca de 2 TB, y en 4 bits, cerca de 0,5 TB. Ocho H200 suman 1128 GB de HBM, de modo que los pesos en FP8 casi caben en un solo nodo, pero para la KV-cache queda muy poco espacio. Por eso la plataforma casi inevitablemente tiene que recurrir a la paralelización entre varios nodos y al ahorro de memoria.

El modelo en sí no encierra una complejidad especial: existen pesos abiertos de esta escala y, por lo general, son arquitecturas MoE, en las que solo está activa una parte de los parámetros por token. El grueso del trabajo empieza a su alrededor, y a eso está dedicada la ponencia.

Tres cargas en las mismas GPU

El autor parte de que la capacidad la comparten tres tipos de tráfico distintos, cada uno con sus propios requisitos:

• Chats. Peticiones cortas con el usuario mirando la pantalla. Importan el tiempo hasta el primer token y una velocidad de generación estable.
• Documentos largos. Una fase de prefill pesada que puede ocupar la GPU durante mucho tiempo y frenar al resto de cargas.
• Agentes. Cadenas de decenas de llamadas, a menudo con un prefijo común. Lo crítico es el rendimiento (throughput); la latencia de cada llamada importa menos.

De ahí salen las tres preguntas del anuncio: quién espera, con qué ocupar los recursos entre picos y cómo comprobar la calidad tras una optimización. La primera se resuelve con prioridades y colas. Un chat no debe quedar detrás del análisis de una página de miles de tokens, mientras que un agente en segundo plano soporta una pausa sin problemas. La segunda se resuelve rellenando los tiempos muertos. De noche y en los valles entre picos se pueden ejecutar tareas por lotes que se desalojan cuando llega tráfico interactivo.

Optimizaciones y el riesgo de degradación silenciosa

La tercera pregunta es la más incómoda. La cuantización, el almacenamiento en caché de prefijos, la decodificación especulativa y los cambios en el batching aceleran el sistema, pero pueden empeorar las respuestas sin que nadie lo note. El error no tumba el servicio ni aparece en las métricas de latencia. Simplemente, el modelo confunde datos con algo más de frecuencia o mantiene peor el formato de las llamadas a herramientas. Para los agentes esto es crítico: una sola estructura JSON rota hace fallar toda la cadena.

La única forma de detectarlo es ejecutar un conjunto fijo de tareas antes y después de cada cambio y comparar los resultados. Ese conjunto debe incluir escenarios reales del producto: contexto largo, llamada a funciones, idioma ruso. Los benchmarks generales sirven aquí de muy poco.

Qué comprobar antes del lanzamiento

Quien se plantee tener un modelo grande propio debería repasar una lista corta:

• Calcular la memoria: pesos, KV-cache con la longitud de contexto real y margen para los picos.
• Dividir el tráfico por clases y acordar de antemano qué clase puede retrasarse.
• Definir con qué se llenarán los tiempos muertos y cómo se interrumpen esas tareas.
• Montar un conjunto propio de evaluación de calidad antes de la primera optimización, no después.
• Medir no solo la velocidad media, sino también las colas de latencia: p95 y p99 para los chats y el rendimiento para los agentes.

La idea principal de la ponencia es que un LLM propio de 1 billón de parámetros constituye una plataforma con planificador, colas y sistema de control de calidad, y no un único modelo en un servidor. Bitrix24 ofrece las cifras concretas de carga y la configuración del clúster en la versión completa del material en Habr.