Kolibri: los parámetros activos son solo una parte del presupuesto de despliegue

El 3 de octubre, Aleph Alpha lanzó Kolibri, un modelo de mezcla de expertos con pesos abiertos centrado en alemán e inglés, bajo Apache 2.0. Su ficha indica 78B parámetros totales y 3.46B parámetros activos por token. Estas cifras describen distintas partes del mismo modelo; la menor no significa que la descarga o el modelo desplegado tengan solo 3.46B. [1] [2]

La discusión pública en Reddit incluye preguntas sobre equipos personales y la afirmación de un contexto de un millón de tokens. Plantean una pregunta útil para una compra: ¿qué recurso describe realmente una cifra destacada? Consideramos que una decisión de despliegue necesita presupuestos separados para el cómputo por token, los pesos residentes y el estado de las solicitudes. Ninguno sustituye a los otros dos.

La ficha del modelo FP8 describe una ocupación de aproximadamente 78 GB para los pesos. La versión BF16, publicada por separado, indica aproximadamente 156 GB. Son estimaciones del editor para los pesos, no una promesa de que un equipo con exactamente esa memoria pueda atender la carga prevista. La precisión cambia el presupuesto de almacenamiento, mientras que la dispersión se refiere al cómputo seleccionado para cada token. [2] [3]

La ficha dice expresamente que el modelo completo debe mantenerse en memoria, aunque solo una parte esté activa en cada momento. Un experto que no se usa para un token puede necesitarse para otro. Por tanto, una planificación útil de capacidad incluye pesos, cachés de solicitudes, búferes de ejecución y margen operativo; dividir los parámetros totales por la fracción activa no es una forma válida de dimensionar la memoria. [2]

La transferencia de pesos a otro nivel de memoria o una cuantización adicional pueden abrir más opciones de despliegue, pero una opción plausible no es una configuración probada. Las transferencias, los cambios de precisión y los distintos kernels pueden alterar la latencia o la calidad. Trate cualquier propuesta para un dispositivo de consumo como un experimento con sus propios criterios de aceptación, en vez de deducir la compatibilidad del número de parámetros activos.

La ficha de Kolibri distingue un contexto nativo de entrenamiento de 262,144 tokens de una validación ampliada hasta 1,048,576. Recomienda un máximo de 262,144 para tareas complejas o servicios sensibles a la latencia y al rendimiento. La sección de contexto largo del informe también describe una degradación dependiente de la tarea más allá de la longitud de entrenamiento. Considere juntos el límite ampliado, la recomendación y las pruebas sobre la carga de trabajo. [2] [4]

Supongamos que un equipo quiere que varias personas consulten documentos largos a la vez. Poder aceptar una solicitud muy larga no determina cuántas solicitudes de ese tipo puede atender bien el servidor. El estado de las solicitudes compite por memoria y el procesamiento de las entradas, por cómputo. Mida la espera hasta la primera respuesta, el tiempo de finalización y la demanda simultánea con los documentos reales, en vez de convertir el contexto máximo en una promesa de nivel de servicio.

Esto no resta utilidad al contexto largo. Mantener juntas las pruebas relacionadas puede reducir la fragmentación. La cuestión es si el material adicional retenido mejora la tarea lo suficiente para justificar su coste en recursos. Compare una entrada compacta y pertinente con el documento completo y compruebe la corrección de la respuesta y de los pasajes que la respaldan.

El informe de Aleph Alpha mide el rendimiento del servicio en un nodo con ocho B200 usando entradas sintéticas. Explora distribuciones paralelas admisibles, mide cerca del límite de concurrencia de la caché KV y presenta la distribución de decodificación más rápida medida. También estima el rendimiento del texto decodificado mediante los bytes por token, que dependen del tokenizador. Estas condiciones son esenciales para interpretar la comparación entre calidad y coste. [4]

El rendimiento de decodificación con alta concurrencia puede ser relevante para un servicio muy ocupado o un procesamiento con mucha generación. No indica directamente cuánto tardará un único usuario en consultar un documento. El procesamiento de la entrada, las colas, la longitud del razonamiento y la comprobación del resultado afectan a esa experiencia. El informe también señala que se supone que el servicio FP8 conserva las puntuaciones de las evaluaciones de referencia; no trate esa suposición como un resultado universal de equivalencia entre precisiones. [4]

El atajo contrario tampoco ayuda: una mayor ocupación de los pesos no demuestra una mala rentabilidad. Un modelo disperso puede aprovechar eficientemente la capacidad residente cuando suficiente trabajo adecuado lo mantiene ocupado. Compare tareas completadas aceptables por unidad de coste bajo la carga prevista e incluya los periodos de poca actividad, en vez de declarar un ganador basándose solo en una de las cifras de parámetros.

El repositorio de inferencia publicado proporciona un complemento de vLLM con arquitectura y analizadores de razonamiento y llamadas a herramientas específicos de Kolibri. Su README indica actualmente que cada versión admite una versión menor de vLLM; en el momento de esta revisión, la admitida era 0.29. Los pesos abiertos permiten acceder al modelo, pero no establecen su compatibilidad con todas las aplicaciones de inferencia ni con sus versiones instaladas. [5]

Registre juntos la revisión del modelo, la precisión, las versiones del complemento y del entorno de ejecución, el límite de contexto y la configuración de los analizadores. Pruebe la separación entre razonamiento y texto final, el análisis de argumentos de herramientas, el manejo de entradas largas y una solicitud interrumpida. Que un cliente acepte el formato de respuesta es solo una parte de una integración funcional. Esta especificación también facilita evaluar una actualización o reversión posterior.

Para un equipo que trabaja con documentos en alemán o inglés, empiece por solicitudes representativas y compruebe las respuestas de forma independiente con las pruebas aportadas. Para un equipo de desarrollo, incluya los esquemas reales de las herramientas y las salidas que la aplicación debe manejar. Para los responsables de infraestructura, compare los periodos previstos de actividad intensa y baja. El enfoque bilingüe justifica evaluar tareas en esos idiomas, pero no demuestra superioridad en todas las tareas de cualquiera de ellos.

Una prueba pequeña debería responder a tres preguntas: ¿la salida cumple el umbral de calidad?, ¿el equipo previsto puede sostener la carga necesaria?, ¿el equipo humano puede mantener la pila de inferencia? Use los mismos documentos, requisitos de salida y reglas de aceptación al comparar alternativas. Incluya los reintentos y los resultados rechazados en el coste.

Kolibri es una nueva opción útil porque sus materiales publicados permiten examinar estas compensaciones. Sus 3.46B parámetros activos describen cómputo disperso; los pesos de mayor tamaño y el estado de las solicitudes siguen siendo obligaciones reales del despliegue. El avance práctico es otro modelo que probar frente a un trabajo definido, no una prueba de que hayan desaparecido las restricciones de memoria, el trabajo operativo o las comprobaciones independientes de las salidas.