Kolibri vs. Granite 4.2 3B: una apuesta por la dispersión de 78B, y el modelo de 3B que se niega a jugar al mismo juego

Coloque Kolibri y Granite 4.2 3B uno al lado del otro y la primera observación honesta es que esta no es una contienda justa, y no en la dirección que uno supondría. Kolibri es el modelo de mezcla de expertos de Aleph Alpha, de 78,1 mil millones de parámetros, publicado el 3 de octubre de 2026, que activa 3,46 mil millones de parámetros por token. Granite 4.2 3B es el modelo de razonamiento denso de IBM, de aproximadamente tres mil millones de parámetros, cuyos pesos llegaron a Hugging Face el 7 de agosto de 2026, con la tarjeta del modelo y el blog técnico publicados después, el 25 de agosto. Uno es veintiséis veces el otro en cuanto a parámetros totales. La razón por la que entran en la misma decisión es que ambos son Apache 2.0, ambos son exclusivamente de texto, ambos están diseñados para autoalojarse y ambos apuntaban al mismo comprador: un equipo que quiere inteligencia documental en hardware que controla, con la procedencia necesaria para superar una revisión de adquisición. La pregunta interesante no es cuál es mejor. Es qué compra en realidad el presupuesto de parámetros veintiséis veces mayor, y cuánto cuesta cargar con él.

La discrepancia, expresada sin rodeos

Granite 4.2 3B es un modelo denso independiente postentrenado a partir de Granite-4.1-3B-Base, parte de la familia Granite 4.2 que IBM lanzó hasta agosto. Tiene 40 capas con atención de consultas agrupadas, un contexto nativo de 128K que IBM amplía a 512K en una quinta fase de preentrenamiento, y tres modos de pensamiento por consulta: pensamiento completo por defecto, una ruta de bajo esfuerzo y una ruta sin pensamiento. La ficha de IBM es inusualmente franca sobre lo que el 3B no es. A diferencia de sus hermanos de 8B y 30B, omitió deliberadamente el bloque especializado de aprendizaje por refuerzo agéntico entrenado en entornos de SWE-agent, de terminal y de búsqueda, por lo que IBM no incluye ninguna cifra de SWE-bench para él en absoluto y presenta el modelo como un especialista en razonamiento en lugar de un agente.

Kolibri va en la dirección opuesta en todos los ejes. Cincuenta capas, todas ellas de mezcla de expertos, 384 expertos por capa con uno compartido y seis enrutados, y una proporción de dispersión de aproximadamente 22,6 a 1. Su contexto es de 262.144 tokens de forma nativa, validado hasta 1.048.576, y la ficha recomienda mantenerse en o por debajo de 262.144 para cargas de trabajo sensibles a la latencia. Cuatro niveles de esfuerzo de razonamiento. Llamada a herramientas al estilo Hermes con un analizador de vLLM incluido en el mismo repositorio que los pesos. Y una huella de aproximadamente 78 GB en FP8, con la configuración mínima de la ficha siendo dos tarjetas A100 de 80 GB, dos H100 SXM5, una H200, una B200 o una B300.

• Parámetros — Kolibri: 78.103.074.560 en total, 3.457.573.120 activos por token. Granite 4.2 3B: aproximadamente 3B denso, todos los parámetros activos en cada token.

• Contexto — Kolibri: 16.384 entrenados, 65.536 entrenados de forma intermedia, 262.144 nativos, 1.048.576 validados. Granite 4.2 3B: 128K nativos, extendido a 512K.

• Modos de pensamiento — Kolibri: ninguno, bajo, medio, alto, configurados mediante la plantilla de chat. Granite 4.2 3B: completo, de bajo esfuerzo y sin pensamiento, por consulta.

• Llamada a herramientas — Kolibri: estilo Hermes, con un parser incluido. Granite 4.2 3B: sí, pero no la ruta entrenada con RL agéntico que recibieron sus hermanos mayores.

• Idiomas — Kolibri: alemán e inglés, por diseño y nada más. Granite 4.2 3B: inglés primero, con el entrenamiento multilingüe más amplio de IBM como respaldo.

• Huella — Kolibri: unos 78 GB en FP8, mínimo dos GPU. Granite 4.2 3B: aproximadamente 6–8 GB en bfloat16, menos de 2 GB cuantizado, de clase portátil.

• Licencia — ambas Apache 2.0, ambas sin una cláusula de uso aceptable ni un umbral de usuarios activos mensuales.

• Servicio — Kolibri: el plugin de vLLM aleph-alpha-inference o la imagen de contenedor publicada. Granite 4.2 3B: vLLM, SGLang, Transformers, GGUF y Ollama bajo granite4.2:3b.

Qué aportan los 75 mil millones de parámetros adicionales

Tres cosas, y vale la pena ser preciso sobre cuáles de ellas están establecidas y cuáles son afirmadas.

El primero es alemán. Esta es la diferencia real más marcada entre los dos modelos, y no es una fila de una tabla de benchmarks. Aleph Alpha construyó Kolibri en torno a un corpus bilingüe alemán-inglés, con el objetivo de que alrededor del 20 % fuera alemán en una ejecución de preentrenamiento de 20 billones de tokens, y terminó con un fondo de 2,4 billones de tokens en alemán, el 80 % del cual fue curado o generado por el propio laboratorio. La ficha explica por qué eso requirió trabajo: los conjuntos de datos alemanes abiertos y deduplicados solo proporcionaban 390.000 millones de tokens, un orden de magnitud menos, así que el laboratorio reajustó un filtro de Common Crawl específicamente para el alemán y reformuló documentos alemanes existentes convirtiéndolos en entradas de enciclopedia, diálogos y pasajes. El detalle del filtro es el que hay que recordar. Un pipeline estándar de datos lingüísticos descarta documentos con demasiadas palabras largas, y la prosa administrativa alemana suele superar el límite inglés de longitud media de las palabras, así que la configuración predeterminada elimina en silencio el registro en el que escribe la Administración pública. IBM no construyó Granite para ese corpus. Granite 4.2 3B manejará el alemán; no fue diseñado en torno al registro legal y administrativo alemán, y ninguna tabla de clasificación te dirá la diferencia.

El segundo es contexto largo que sobrevive a documentos reales. El techo de 512K de Granite es genuinamente grande, pero los dos modelos llegaron ahí de forma diferente y el diseño posicional de Kolibri es el argumento de contexto largo más convencional. Considera las cifras RULER de IBM —67,52 a 64K y 55,30 a 128K en el material publicado de la familia 4.2— como la divulgación honesta de cuánto se degrada la calidad de recuperación a 128K, y recuerda que Kolibri no tiene ninguna curva de degradación publicada equivalente en absoluto.

El tercero es el margen bruto de razonamiento, y aquí es donde la respuesta honesta es «no tanto como sugiere la proporción de parámetros». El pipeline de entrenamiento de Kolibri le consiguió una ejecución de preentrenamiento de 20 billones de tokens en 768 NVIDIA B200 durante 21 días, y la propia tabla comparativa de Aleph Alpha, con Kolibri en esfuerzo de razonamiento alto, lo sitúa en 75,5 en el promedio de inglés y 70,8 en el promedio de alemán de una comparación de catorce modelos — donde pierde frente a un modelo denso de 27.000 millones de parámetros de Alibaba en la mayoría de las filas. Las afirmaciones más destacadas de Granite 4.2 3B son suyas: AIME 2025 en 78,33, GPQA en 54,80, LiveCodeBench v6 en 69,71 y MMLU-Pro en 67,84, todas reportadas por IBM y no reproducidas. Distintos conjuntos de pruebas, distintos harnesses, distintos proveedores. No existe en ninguna parte una cifra con el mismo harness para este emparejamiento, y no vamos a inventar una.

Dónde gana realmente cada uno

Ejecuta Granite 4.2 3B si tu limitación es la máquina. Con 6–8 GB en bfloat16, o por debajo de 2 GB cuantizado, cabe en un portátil, en una única GPU de estación de trabajo o en una caja perimetral aislada de la red que nunca verá dos H100s. Se sirve a través de cinco entornos de ejecución diferentes, incluidos Ollama y GGUF, lo cual importa cuando el objetivo de despliegue es el portátil de otra persona en lugar de tu propio rack. Y su tarjeta de modelo es inusualmente fiable precisamente porque IBM dejó por escrito lo que dejó fuera. Un proveedor que se niega a declarar resultados de SWE-bench para un 3B te está diciendo dónde se detiene el modelo.

Ejecuta Kolibri si el corpus es lo importante y el hardware es el adecuado. Un equipo con contratos en alemán, documentación técnica o expedientes administrativos, un nodo de dos dispositivos y la condición de que los pesos nunca salgan es exactamente el destinatario de esta versión. La caché KV FP8 de 262.144 tokens, los cuatro niveles de esfuerzo y la ruta de llamada a herramientas de Hermes apuntan todos a flujos de trabajo con documentos en lugar de al chat. El tokenizador bilingüe forma parte del mismo argumento: Aleph Alpha informa 4,90 bytes promedio por token en texto web en alemán frente a 4,35 de GPT-5 y 3,28 de Kimi K3, todos medidos por el proveedor sobre el corpus del proveedor, y más caracteres por token es un efecto directo en el coste de inferencia, no una puntuación. Si se mantiene, se acumula en cada página que proceses.

La asimetría que nadie publicita son los datos. IBM publicó los pesos de Granite 4.2 3B y un informe técnico detallado de cómo se construyó el modelo, pero no los datos de entrenamiento. Aleph Alpha publicó el pipeline, la procedencia de los datos y la cifra de energía junto con los pesos de Kolibri: 20 billones de tokens de preentrenamiento, 9,5×10² MWh, incluida la sobrecarga del centro de datos y excluyendo el ajuste fino supervisado y el aprendizaje por refuerzo. Para un equipo que tiene que responder a la pregunta «¿de dónde procede el texto de este modelo?», esa diferencia no es cosmética.

La realidad del enrutamiento para ambos

Ninguno de los dos modelos figura hoy en un catálogo alojado. Kolibri no tiene ningún SKU de API de proveedor —el lanzamiento son pesos más un informe técnico—, y Granite 4.2 3B se distribuye como pesos para cinco pilas de ejecución, sin ningún endpoint alojado de IBM. Ambos son propuestas autoalojadas, y la pregunta práctica para la mayoría de los equipos no es cuál adoptar, sino si la carga de trabajo justifica tener cualquiera de los dos.

Ahí es donde una capa de enrutamiento se gana su sitio, incluso para modelos que no aloja. Rastreamos el catálogo de OrcaRouter con todas las grafías de ambos nombres de modelo y ni Kolibri ni Granite 4.2 3B aparecen, así que no vamos a fingir lo contrario. Lo que sí te da OrcaRouter es la forma barata de averiguar si la decisión de hardware está justificada antes de tomarla: apunta una ruta de prueba a un nivel pequeño de mixture-of-experts que ya esté enrutado —la variante Gemma 4 26B-A4B, a 0,06 $ por millón de tokens de entrada y 0,33 $ por millón de salida, con una ventana de 262.144 tokens— y comprueba si tu carga de trabajo de documentos en alemán necesita de verdad lo que ofrece Kolibri, con una única clave compatible con OpenAI, al precio de lista del proveedor y sin nada añadido. Si es así, compras las GPU con pruebas en lugar de con una corazonada. Si no, acabas de ahorrarte un pedido de hardware.

El veredicto, y qué lo cambiaría

Esto no es una confrontación con un ganador. Kolibri y Granite 4.2 3B responden a preguntas distintas en puntos de precio distintos, y la única clasificación honesta es por restricción: si la restricción es el hardware, Granite 4.2 3B es el único de los dos que califica. Si la restricción es el trabajo documental de registro regulatorio alemán en instalaciones propias, Granite 4.2 3B nunca estuvo en la contienda y Kolibri es el artefacto más interesante: una publicación legítima de pesos abiertos de 78B, Apache 2.0, con el pipeline de datos y el tokenizador publicados junto a los pesos.

Dos cosas resolverían la comparación. Una ejecución independiente de Kolibri en una tarea de QA sobre documentos en alemán pondría a prueba justamente la afirmación que el lanzamiento estaba destinado a hacer, ya que ninguna tabla de clasificación la mide actualmente. Y una reproducción independiente de las cifras de razonamiento de Granite 4.2 3B te diría si un equipo de clase portátil puede defenderse en el subconjunto de tu carga de trabajo que nunca necesitó 78 mil millones de parámetros en primer lugar. Hasta que ocurra una de esas dos cosas, compra guiándote por tus restricciones, no por la cantidad de parámetros.