Kolibri-1 en la NVIDIA DGX Spark: una primera comparación con Qwen3.6

Por Iristrace B.V., con André Kingham, CEO

El 3 de octubre, Día de la Unidad Alemana, la empresa de Heidelberg Aleph Alpha publicó Kolibri-1, un modelo de lenguaje de pesos abiertos pensado para el alemán y el inglés. Nosotros nos adelantamos un día: su página en Hugging Face ya estaba publicada el 2 de octubre, antes que el propio modelo, y dimos con ella repasando los repositorios nuevos del día anterior. Kolibri significa «colibrí» en alemán, el pájaro más pequeño que existe. Sin embargo, su ficha pone el listón del hardware muy alto. Dice, textualmente: «Model memory footprint: ~78 GB (FP8 weights). Minimum: 2× A100 80 GB, 2× H100 SXM5, 1× H200, 1× B200 or 1× B300. Recommended: 2× H100 SXM5, 2× H200, 1× B200 or 1× B300». Es decir: unos 78 GB con los pesos en FP8; como mínimo, dos A100 de 80 GB, dos H100 SXM5 o una sola H200, B200 o B300, y lo recomendado, dos H100 SXM5, dos H200 o una B200 o B300. Son GPU de centro de datos, de las que van en servidores grandes.

Pero si nos atenemos a las cifras de la propia ficha, y no solo a su nombre, debería apañarse con menos: unos 78 GB caben en los 128 GB de una DGX Spark.

Queríamos saber dos cosas. ¿Funciona Kolibri-1 en una DGX Spark, sí o no? Y, frente a Qwen3.6, ¿qué tal cumple con lo que nuestros clientes le piden a un asistente: encontrar y usar la información correcta en sus propios documentos?

Así que, poco después del lanzamiento oficial, nos pusimos a responder esas dos preguntas por nuestra cuenta. En una de nuestras NVIDIA DGX Spark, estaciones de trabajo de sobremesa construidas en torno al chip Grace Blackwell de NVIDIA y montadas en nuestros racks; con el tipo de trabajo que hacen nuestros clientes, y en comparación directa con Qwen3.6-35B-A3B: los dos en FP8, en máquinas idénticas y por el mismo pipeline.

Para calibrar el potencial, tiramos de IA para todo: una biblioteca de prueba escrita por IA, correctores de IA y 1.428 respuestas. Lo que eso muestra es una promesa, y una promesa es lo que la práctica, con los documentos y las preguntas de nuestros clientes, tiene que confirmar. Dos días de trabajo intenso: una primera toma de contacto con el modelo.

En resumen

• ¿DGX Spark, sí o no? Sí, y desde el primer día. Kolibri-1 funciona en una sola DGX Spark, con el plugin que la propia Aleph Alpha publica para el servidor de inferencia, sin tocar el código y sin ajustes. El mínimo que da su ficha, textualmente, es «2× A100 80 GB, 2× H100 SXM5, 1× H200, 1× B200 or 1× B300». Con la máquina sin carga escribe unos 48 tokens por segundo, 31 palabras, más rápido de lo que nadie lee, y con ocho peticiones a la vez sigue dando 20 a cada una.
• Responder a partir de documentos: empate, en igualdad de condiciones. Con búsqueda y sin razonamiento, los dos sacan la misma nota: 0,55 frente a 0,55 por respuesta según el primer corrector y 0,50 frente a 0,47 según un segundo corrector independiente, en todas las configuraciones de muestreo. Kolibri-1 necesita más rondas y lee más para llegar ahí: lo típico son cuatro rondas del modelo y cinco llamadas a herramientas por respuesta, frente a dos y dos de Qwen3.6.
• Empate en la media, no en cada pregunta. En dos de las diecisiete preguntas los modelos se separan muy por encima de lo que explicaría el azar, y en sentidos opuestos. Kolibri-1 encontró la regla más estricta de 90 días de un cliente en 11 de 14 respuestas; Qwen3.6, en 1, porque Kolibri-1 siguió buscando. Qwen3.6 se dio cuenta en las 14 de que el contrato nombra una grasa que ya no está homologada; Kolibri-1 también lo vio y, aun así, concluyó «homologada» en 11. Misma media, puntos fuertes distintos.
• Con el razonamiento activado, Kolibri-1 quedó ligeramente por delante en las dos tandas, pero a un precio. 0,65 frente a 0,58 con búsqueda según el primer corrector, 0,60 frente a 0,51 según el segundo: una ventaja que todavía no se distingue del azar. Una respuesta de Kolibri-1 tardaba entonces una mediana de cinco minutos, frente al minuto y medio de Qwen3.6, con nuestra carga de prueba.
• La diferencia más clara no está en la precisión, sino en el comportamiento. Cuando una búsqueda no devuelve nada, el modo de razonamiento de Kolibri-1 la repite una y otra vez con formulaciones nuevas hasta que lo frena un límite de rondas; en un banco de pruebas sin respuesta de reserva, eso significó quedarse sin respuesta. Es algo que hay que vigilar, medir y prevenir con una estrategia de respuesta, no un motivo para descartar un modelo, y es justo el tipo de cosa que no se ve en la puntuación de un benchmark.
• Buscar sale más barato, no más preciso. Con una biblioteca que cabe en el prompt, meterlo todo dio respuestas igual de buenas o mejores en tres de cuatro configuraciones. Buscar gasta hasta tres veces menos tokens y sigue funcionando cuando la biblioteca ya no cabe en la ventana.
• Un hueco en la biblioteca no produce un «no lo sé». Cuando nuestra búsqueda no dio con el único documento que tenía la respuesta, las 34 respuestas a esa pregunta sonaban seguras y estaban incompletas; ni una dijo que la biblioteca no lo cubría. La cobertura forma parte de la respuesta, la dé el modelo que la dé.
• De dónde viene un modelo ya es una elección real. Con Kolibri-1, un modelo alemán solvente se suma a los estadounidenses, chinos y franceses. Para muchas empresas es una decisión de cadena de suministro tanto como de rendimiento.

Por qué hicimos esta prueba

En los documentos de nuestros clientes están sus contratos, procedimientos, registros de calidad y normas de RR. HH. Cuando nos preguntan por la IA, lo primero que quieren saber rara vez es lo lista que es. Es adónde van a parar sus documentos.

Los modelos de pesos abiertos cambian la respuesta. Cuando un fabricante publica el propio modelo, puedes ejecutarlo en hardware que controlas tú, y ningún documento tiene que salir hacia un servicio de IA externo. Con una licencia como Apache 2.0, además, puedes seguir usándolo decida lo que decida después su fabricante.

La mayoría de los modelos abiertos solventes que se usan hoy vienen de Estados Unidos y de China. Qwen3.6 es uno de ellos. Europa ha tenido menos, y menos aún pensados para el alemán. Un modelo solvente hecho en Heidelberg importa a las organizaciones que prefieren tener a su proveedor de IA, igual que sus datos, en Europa.

La forma del modelo también contaba. Kolibri-1 tiene 78.000 millones de parámetros, pero en cada token solo calcula con 3.460 millones: de los 384 expertos de cada capa elige seis por token, más uno compartido. Un modelo grande que lee poco por token es justo lo que premia una DGX Spark, con mucha memoria y un ancho de banda modesto. Y, según su ficha, se entrenó desde cero, sin depender de ningún otro modelo, con un corpus bilingüe filtrado de 20 billones de tokens, casi una cuarta parte en alemán; no es un ajuste fino sobre el modelo base de otro. Un modelo con esa forma, en ese formato y hecho en Europa: no queríamos probarlo dentro de unas semanas, sino el mismo día de su lanzamiento.

Pero una dirección europea no responde a las preguntas de nadie. La única manera de saber si un modelo vale para el trabajo de nuestros clientes es darle ese trabajo. Y eso hicimos.

Por qué estos dos

Los dos son modelos abiertos con licencia Apache 2.0, los dos pueden funcionar en hardware propio y los dos están construidos igual: un modelo grande del que solo una pequeña parte (unos 3.000 millones de parámetros) trabaja en cada palabra. Por eso los dos van rápidos en hardware modesto.

Los ejecutamos en FP8, que guarda cada número del modelo en ocho bits en lugar de dieciséis y así reduce a la mitad la memoria que necesita. Los dos fabricantes publican sus modelos en este formato, así que cada uno funcionó con la versión de su propio fabricante, no con la de un tercero.

Kolibri-1 está hecho para este trabajo. Su ficha cita, entre los usos previstos, «retrieval-augmented generation» (generación aumentada por recuperación), «long-document processing» (procesamiento de documentos largos) y «agentic tool calling» (llamadas a herramientas por parte de agentes), y dice que encaja en «question-answering systems over an organisation’s own material», sistemas de preguntas y respuestas sobre el material propio de una organización. Probamos los tres usos, aunque las llamadas a herramientas solo en la forma que adopta nuestra búsqueda y en ocho pequeños escenarios de fallo con herramientas simuladas. Los agentes que resuelven una tarea a lo largo de muchos pasos vendrán después.

Qwen3.6 no es un rival fácil. La familia Qwen de Alibaba se ha convertido en el caballo de batalla de la IA de pesos abiertos: es lo primero que coge mucha gente cuando ejecuta un modelo por su cuenta, y ha servido de base a muchísimos modelos derivados en todo el mundo. Sin ir más lejos, NVIDIA ha ajustado varios de sus modelos Qwen3-Nemotron a partir de Qwen3 y publica su propia versión comprimida del mismo Qwen3.6 que probamos. Incluso su Nemotron 3 Nano, construido sobre la arquitectura de la propia NVIDIA, dice en su ficha que se mejoró con modelos Qwen, entre otros («was improved using»). Además, esta versión de Qwen lee imágenes y cubre un abanico amplio de idiomas.

Nuestra propia experiencia con el modelo ha sido buena en general. Visto así, un recién llegado que simplemente lo iguale con los documentos de una empresa ya ha superado un listón alto, y eso es lo que queríamos mirar más de cerca.

	Kolibri-1	Qwen3.6 (35B-A3B)
Fabricante	Aleph Alpha Research GmbH, Heidelberg	Equipo Qwen, Tongyi Lab de Alibaba Group
Lanzamiento	Octubre de 2026	Abril de 2026
Tamaño, total / activo por palabra	78.000 millones / 3.500 millones	35.000 millones / 3.000 millones
Idiomas	Alemán e inglés, oficialmente	Un abanico amplio
Lee imágenes	No	Sí (no se compara aquí)
Entrada más larga	262.144 tokens	262.144 tokens
Hardware mínimo, según su ficha	«2× A100 80 GB, 2× H100 SXM5, 1× H200, 1× B200 or 1× B300»	No lo indica
Ficha en Hugging Face	Aleph-Alpha/Kolibri-1	Qwen/Qwen3.6-35B-A3B-FP8

Dónde se hizo la prueba: la base de conocimiento de Iristrace Docs

Iristrace Docs convierte documentos en datos utilizables: entra una factura o un albarán y salen campos estructurados, asignados a las cuentas y los códigos correctos de sistemas como SAP Business One. Se conecta a los sitios donde ya están los documentos, entre ellos SharePoint y los buzones de Exchange y Gmail. El paso que estamos construyendo ahora es una base de conocimiento a la que se le pueden hacer preguntas, por chat y también por voz, con respuesta hablada, y que responde a partir de los documentos de la propia empresa. La prueba se hizo sobre esa base de conocimiento tal y como está hoy. Esto no es una reseña del producto, sino el relato de lo que aprendimos al pasar dos modelos por ella.

Resaltado: lo que se usó en esta prueba

Iristrace Docs

App web

Chat con IA · subida de documentos · gestión de accesos

Iristrace Docs

App móvil

Chat · captura de tickets y procesos de calidad · preguntas por voz

↕

Iristrace DocsUna sola plataforma, en nuestra nube o en tu propia infraestructura

Espacios de trabajo: Ingeniería · RR. HH. · Calidad · Compras · Finanzas · …

Permisos por usuario y espacio de trabajo, en cada consulta

Inteligencia

• RAGRespuestas a partir del texto de los documentos, con citas
• Llamadas a herramientasBuscar, abrir documentos, consultar el almacén de datos
• Extracción con IADocumento → datos estructurados (JSON) y texto (Markdown); los escaneos y las fotos necesitan un modelo de visión

Almacenamiento

• Almacén de textoCada documento entero, en Markdown
• Almacén de registrosLos datos extraídos, en JSON
• Almacén de datosTablas que se construyen solas a partir de los registros
• Almacén vectorialEl índice de búsqueda, uno por espacio de trabajo

Integraciones

• SharePointDonde viven los documentos. Se traen a través de Microsoft Graph; el sincronizador que detecta por sí solo los cambios en una biblioteca o carpeta está en desarrollo. Quién puede leer qué lo marca el espacio de trabajo
• SAP Business OneEncuentra la cuenta contable correcta y los códigos de SAP del interlocutor comercial, el artículo y más

• Buzones de Exchange y Gmail
• Webhooks
• Transcripciones
• Iristrace Checks
• Y más, que construimos con nuestros clientes

↕

El prompt solo lleva el contexto que el usuario tiene permiso para ver

LLM privado

Texto y visión: un modelo que haga las dos cosas, como Qwen o Mistral, o dos modelos en paralelo

• LiteLLMEnrutador de modelos
• NVIDIA DGX Spark 1Kolibri-1 en esta prueba
• NVIDIA DGX Spark 2Qwen3.6 en esta prueba; antes, el modelo de visión que leyó los escaneos

Funciona en cinco pasos, y la prueba pasó por los cinco:

1. Conectar. Los documentos se traen de donde ya están. Para esta prueba, de una biblioteca de SharePoint, descargada una sola vez a través de Microsoft Graph. El sincronizador que detecta un fichero modificado y descarga solo ese fichero está en desarrollo.
2. Leer. Cada fichero se convierte en texto: Word, PDF, hojas de cálculo. Las páginas escaneadas las lee un modelo de visión que funciona en nuestro propio hardware. Cada documento se guarda entero, en Markdown, no solo a trozos. Sobre ese almacén de texto se construye la base de conocimiento.
3. Indexar. Los documentos se dividen en fragmentos siguiendo sus encabezados y se indexan para la búsqueda, cada espacio de trabajo en su propio índice.
4. Responder. El asistente busca, abre documentos enteros cuando un fragmento no basta y responde con citas. Cada cita lleva al fragmento y al fichero original.
5. Permisos. El espacio de trabajo marca el perímetro: una persona solo recibe respuestas de los espacios que tiene permiso para leer, y eso lo impone la propia base de datos, no solo la aplicación que hay encima. Como un espacio de trabajo se puede alimentar desde una sola carpeta de un sitio de SharePoint, su público se puede acotar al equipo responsable. No copiamos las listas de permisos de SharePoint, y es a propósito: un perímetro claro es más fácil de entender y de comprobar.

Al asistente también se le dice qué contiene cada espacio de trabajo, para que pueda avisar cuando una pregunta se sale de él en lugar de seguir buscando sin fin.

En esta prueba, todos los pasos funcionaron en nuestro propio hardware: la lectura de los escaneos, la indexación, la búsqueda y las respuestas. Los servicios externos fueron SharePoint, de Microsoft, donde estaba guardada la biblioteca como lo estaría la de un cliente, y dos modelos de IA de otros fabricantes: Claude, de Anthropic, escribió los documentos ficticios y las pruebas y corrigió cada respuesta, y GPT-6.1 Sol, de OpenAI, volvió a corregirlas todas, de forma independiente y a ciegas. Los dos trabajaron solo con material sintético, y por un motivo: solo con documentos cuyo contenido y cuyos fallos hemos fijado nosotros sabemos con certeza qué respuesta es la correcta.

La prueba: una empresa que no existe, con problemas que sí existen

No queríamos examinar a los modelos de cultura general. Queríamos saber si ayudan a un empleado que tiene una duda sobre las normas de su propia empresa. Así que necesitábamos una empresa.

Guiamos a Claude Opus 5.5, con el nivel de esfuerzo «extra alto», para que escribiera la biblioteca documental de un fabricante ficticio: una empresa de rodamientos para la automoción, parte de un grupo más grande, con plantas en seis países. Cuarenta y siete documentos: políticas, procedimientos, especificaciones técnicas, instrucciones de trabajo, matrices de autorización y un contrato de suministro, en inglés, español, polaco, alemán y chino. Unos 160.000 tokens de texto en total.

Después hicimos lo que el tiempo le hace a cualquier biblioteca documental real: sembramos 18 defectos, cada uno documentado en un solucionario. Algunos ejemplos:

• Dos revisiones de la política de viajes en la misma biblioteca, con distintos límites de hotel.
• Dos documentos que dan al mismo directivo dos límites de autorización diferentes.
• Un procedimiento que cita una lista de comprobación que no existe.
• Una instrucción de trabajo de una planta que se aparta, sin decir nada, de la especificación del grupo.
• Un requisito de un cliente más estricto que nuestro propio procedimiento.
• Un documento de RR. HH. regional que ha quedado superado por un cambio en la ley.

Se escribió además otro documento que dejamos fuera de la biblioteca a propósito, para ver si un modelo reconoce que la biblioteca no cubre un tema en lugar de inventarse algo.

Un detalle que nos pareció revelador: la IA que escribió la biblioteca había añadido, por iniciativa propia, más contradicciones que nadie le había pedido. Una segunda revisión encontró 18, y se volvieron a quitar. Así el foco se quedó en las trampas que habíamos planeado a propósito.

¿Por qué tomarse tantas molestias? Porque un asistente documental que responde «el límite de hotel es de 120 €» porque encontró primero la revisión antigua es peor que no tener asistente. La pregunta no es si un modelo escribe bien, sino si se da cuenta.

Del texto a una biblioteca documental de verdad

Escribir los documentos fue la mitad del trabajo. La otra mitad fue conseguir que se comportaran como ficheros reales.

Cada documento se generó en el formato que usaría una empresa real: Word la mayoría, PDF otros, hojas de cálculo para las matrices. Tres se convirtieron en escaneos, ligeramente torcidos, con motas y guardados como imágenes sin texto detrás, de modo que la única forma de entrar es leer la página. Todos los documentos llevan un bloque de control (número, revisión, responsable, aprobador, fecha de entrada en vigor, próxima revisión) en uno de dos estilos de la casa, porque el grupo y su filial dan formato a sus documentos de manera distinta.

Luego subimos la biblioteca a un sitio de SharePoint preparado para demos, con una carpeta por departamento, y desde ahí la cargamos en Iristrace Docs.

Antes de que ningún modelo viera una sola pregunta, un script comprobó que cada dato del solucionario se podía encontrar en el texto convertido, escaneos incluidos. Cuando un modelo se deja un dato, el dato estaba ahí para encontrarlo.

Una tarea, tres maneras de abordarla

Aquí no vas a encontrar una tabla de puntuaciones de benchmarks. Esas tablas existen, y los fabricantes las publican. Nosotros probamos lo que un empleado le pide más a menudo a un asistente documental: que responda a una pregunta a partir de los documentos de la empresa, y que acierte cuando los documentos no coinciden. La extracción y el análisis de datos estructurados también forman parte de Iristrace Docs, pero no de esta prueba; hablamos de ello al final.

Responder con tus documentos: leer también el segundo

Este es el trabajo en el que piensa casi todo el mundo cuando habla de IA sobre documentos de empresa. Antes de responder, el asistente busca en la biblioteca, lee lo que encuentra y lo cita. En la jerga se llama «generación aumentada por recuperación», o RAG por sus siglas en inglés.

Hicimos 17 preguntas que podría hacer un empleado, cada una con su solucionario. Algunos ejemplos:

• ¿Puedo aceptar un regalo de 75 € de un proveedor? El código de conducta del grupo y la política de compras local dan umbrales distintos. Una respuesta correcta menciona los dos.
• ¿Cuál es el límite actual de hotel en los viajes de trabajo? En la biblioteca sigue habiendo una revisión antigua con un límite más bajo.
• ¿Con cuánta antelación tenemos que avisar a un cliente concreto antes de cambiar un producto? Los requisitos del cliente son más estrictos que nuestro procedimiento general.
• ¿Qué pasa si un proveedor no devuelve su informe de minerales de conflicto? El documento que responde a esto es el que dejamos fuera. La respuesta correcta es «la biblioteca no lo cubre».

Para contar como correcta, una respuesta tenía que dar el dato clave y señalar el conflicto sembrado detrás. El dato correcto sin ver el conflicto cuenta como parcial.

Cada pregunta se hizo en inglés y en alemán, con tres configuraciones de muestreo (la configuración fija del modelo que usa nuestro chat, una temperatura baja y la que recomienda el fabricante), con el razonamiento desactivado y activado, y de una a tres veces por configuración: 1.428 respuestas en total. Todas las respuestas se barajaron, se les quitó el nombre del modelo y se corrigieron a ciegas contra el solucionario, dos veces: con agentes basados en Claude Opus 5.5 y, de forma independiente, con GPT-6.1 Sol, de OpenAI. Los dos correctores coincidieron en el 78% de las notas (kappa de Cohen de 0,68). El segundo fue más exigente con lo completa que debe ser una respuesta correcta; cuando dice algo distinto, lo indicamos.

Con búsqueda, que es como funciona el producto. Porcentaje sobre el total de respuestas; primero el primer corrector y, entre paréntesis, el segundo:

	Kolibri-1	Qwen3.6
Correctas / parciales / incorrectas, sin razonamiento	42% / 26% / 32% (32 / 36 / 32)	45% / 21% / 34% (28 / 38 / 34)
Puntuación media por respuesta, sin razonamiento	0,55 (0,50)	0,55 (0,47)
Segundos por respuesta, mediana, sin razonamiento, con carga de prueba	55	32
Correctas / parciales / incorrectas, con razonamiento (Kolibri-1 en high)	60% / 10% / 29% (49 / 22 / 29)	50% / 16% / 34% (35 / 32 / 32)
Puntuación media por respuesta, con razonamiento	0,65 (0,60)	0,58 (0,51)
Segundos por respuesta, mediana, con razonamiento, con carga de prueba	321	82

Puntuación por respuesta: correcta 1, parcial ½, incorrecta 0. Cada respuesta se corrigió dos veces. Sin razonamiento: 238 respuestas por modelo. Con razonamiento, con Kolibri-1 en high, su nivel más caro: 68 respuestas por modelo, dos tandas cada uno. Los segundos son medianas con nuestra carga de prueba, que durante la mayor parte del día fue más pesada en el servidor de Kolibri-1 que en el de Qwen3.6: compáralos dentro de un mismo modelo, no entre los dos. La velocidad de escritura y de lectura con los servidores sin carga, medida aparte, está en «En marcha». Las mismas cifras, pregunta a pregunta, están en el anexo E.

Sin razonamiento, los dos empatan, y el empate no depende de la configuración de muestreo: a temperatura 0, a 0,3 y con la recomendación de cada fabricante, la ventaja cambia de lado por unas centésimas. Pregunta a pregunta, Qwen3.6 va por delante en ocho y Kolibri-1 en cinco según el primer corrector, y seis a seis según el segundo; la diferencia media por pregunta es de 0,00 con el primer corrector y de 0,03 a favor de Kolibri-1 con el segundo, con un intervalo del 95% de unos ±0,12 en torno a cada una (anexo D). Kolibri-1 se esfuerza más para el mismo resultado: una respuesta típica le lleva cuatro rondas del modelo y cinco llamadas a herramientas, frente a dos y dos de Qwen3.6, y cada ronda vuelve a enviar las instrucciones, las herramientas y todo lo encontrado hasta ese momento, así que lee unos 86.000 tokens de prompt por respuesta en total, frente a 53.000. Eso, más que nada de lo que hagan los servidores, es lo que explica que tarde más.

Con el razonamiento activado, Kolibri-1 quedó ligeramente por delante, en sus dos tandas y con los dos correctores. Pregunta a pregunta, gana en seis, pierde en una o dos y empata en el resto; la diferencia media por pregunta es de 0,07 a 0,08 a su favor, y el intervalo del 95% termina justo en cero con el segundo corrector y lo supera por muy poco con el primero. Su segunda tanda redujo la ventaja. Así que lo que los datos respaldan es «ligeramente por delante», no «responde mejor», y con el número de comparaciones que hicimos (anexo D) es una tendencia que las próximas pruebas tendrán que confirmar. Además, tiene un coste: con nuestra carga de prueba, una mediana de más de cinco minutos por respuesta, y alrededor de una cuarta parte de sus respuestas por encima de los diez minutos. Qwen3.6 con razonamiento se queda por debajo del minuto y medio en la mediana.

Empate en la media, no en cada pregunta

El empate es una media, y esconde dos preguntas en las que los modelos se separan muy por encima de lo que explicaría el azar: las dos únicas de diecisiete cuya diferencia aguanta con los dos correctores una vez que se corrige por el número de preguntas comparadas (anexo D). Y apuntan en direcciones opuestas.

La regla más estricta de un cliente: Kolibri-1 hace bien en leer el segundo documento. ¿Con cuánta antelación tenemos que avisar a HallvikDemo Trucks antes de un cambio de producto? El procedimiento general de cambios dice 60 días; la matriz de requisitos de clientes dice 90 para este cliente. Kolibri-1 acertó en 11 de 14 respuestas; Qwen3.6, en 1 de 14 (12 frente a 2 según el segundo corrector), tanto en inglés como en alemán. Los dos modelos son capaces de leer la contradicción: si se les dan solo los documentos correctos, aciertan siempre. La diferencia está en cómo buscan. Qwen3.6, por lo general, buscaba una vez y respondía a partir del procedimiento; cuatro veces dijo que los documentos no mencionan a HallvikDemo, con la matriz entre sus propios resultados de búsqueda. Kolibri-1 hacía tres o cuatro rondas y encontraba la matriz. Aquí, las rondas de más que antes contábamos como un coste son justo lo que le dio la respuesta correcta, y en el tipo exacto de pregunta que quita el sueño a un equipo de calidad o de cumplimiento normativo. Con el razonamiento activado, Qwen3.6 buscó más y acertó en dos de cuatro.

Una grasa que ya no está homologada: Kolibri-1 saca la conclusión equivocada. ¿Qué tipo de grasa le compramos a ChemcoDemo, y es el homologado? El contrato de suministro nombra un tipo que la especificación ha retirado. Qwen3.6 acertó en las 14 respuestas. Kolibri-1 acertó del todo en 3. En las otras 11 se dio cuenta de que el contrato nombra la WH-2, ya retirada, y aun así concluyó, normalmente en la primera frase, que lo que se compra está homologado. Quien se quede en la primera línea se lleva una idea equivocada. Si se le dan solo los documentos correctos, Kolibri-1 también acierta siempre esta, y con el razonamiento activado acertó las cuatro respuestas también con búsqueda.

Una tercera pregunta los separa solo con el primer corrector: el primer pedido antes del informe de minerales de conflicto de un proveedor (pregunta 17). Esa diferencia mide nuestro solucionario, no los modelos. El solucionario premia un «no» rotundo que la biblioteca no permite sostener, y Kolibri-1 dijo casi siempre que los documentos no lo responden (ver las limitaciones más abajo).

Con catorce respuestas por modelo y pregunta, esto son comportamientos en dos preguntas, no una clasificación. Lo que muestran es que dos modelos con la misma media no son intercambiables: cuál te sirve mejor depende de las preguntas que haga tu gente, y eso solo se averigua con tus propios documentos.

¿Y por qué no dárselo todo?

Los dos modelos pueden asimilar 262.144 tokens de una vez, más que toda nuestra biblioteca. Es tentador saltarse la búsqueda, meter todos los documentos en el prompt y dejar que el modelo encuentre la respuesta por su cuenta. Así no hay nada que la búsqueda se pueda dejar por el camino. Lo probamos, con los dos.

Puntuación media por respuesta, primer corrector (segundo corrector)	Con búsqueda	Toda la biblioteca en el prompt
Kolibri-1, sin razonamiento	0,55 (0,50)	0,51 (0,44)
Qwen3.6, sin razonamiento	0,55 (0,47)	0,67 (0,54)
Kolibri-1, con razonamiento	0,65 (0,60)	0,73 (0,63)
Qwen3.6, con razonamiento	0,58 (0,51)	0,67 (0,56)

Esperábamos que ganara la búsqueda. No fue así. Con toda la biblioteca a la vista, Qwen3.6 respondió claramente mejor sin razonamiento, entre 0,11 y 0,16 por pregunta, y eso se sostiene con los dos correctores; es la única diferencia clara de lectura entre los dos. Los dos modelos respondieron mejor con razonamiento. La búsqueda solo ganó en el caso de Kolibri-1 sin razonamiento. Así que la lección honesta es esta: buscar sale más barato, no más preciso. Una pregunta con toda la biblioteca adjunta cuesta unos 150.000 tokens de prompt; con búsqueda, entre 53.000 y 86.000, sumando todas las rondas de una respuesta. Y el método de la biblioteca entera deja de funcionar el día en que la biblioteca ya no cabe en la ventana, y en una empresa real ese día llega pronto.

La primera lectura de toda la biblioteca llevó alrededor de un minuto en cualquiera de los dos servidores (de 62 a 68 segundos). Después, como el servidor conserva lo que ya ha leído, las respuestas empezaban en dos a cuatro segundos. Los prompts con la biblioteca entera fueron también donde se dieron las pocas respuestas desbocadas sin razonamiento: seis de 68 con la configuración fija empezaron a repetirse o chocaron con el límite de salida.

Los deberes son nuestros

Tres documentos dieron guerra, respondiera el modelo que respondiera. La búsqueda no encontró nunca un procedimiento de resolución de problemas (8D), en 35 intentos. Un procedimiento escaneado apareció 8 veces de 35. Una matriz de requisitos de clientes, para la pregunta que la necesita, 9 veces de 35. Eso no es culpa del modelo. Es nuestra, y es lo próximo que vamos a arreglar: el procedimiento 8D nombra una sola vez a la persona sobre la que trata una de las preguntas, y una búsqueda por significado colocaba siempre otros fragmentos por delante. Una búsqueda que además tenga en cuenta las palabras exactas seguramente lo encontraría.

Lo que hicieron los modelos cuando la búsqueda no dio con el documento es la lección más útil. De las 34 respuestas a esa pregunta, las 34 fueron parciales: cada modelo respondió con los documentos que sí había encontrado, con un cargo plausible e incompleto. Ni una dijo «no lo sé». Así se ve un hueco en una biblioteca desde el lado del usuario: no como una respuesta dudosa, sino como una respuesta segura.

El documento que dejamos fuera es el contraejemplo. Cuando se les preguntó por un tema que la biblioteca no cubre, los dos modelos lo dijeron la mayoría de las veces: Kolibri-1 en 26 de 36 respuestas, Qwen3.6 en 30 de 42. Cuando no encuentran nada en absoluto, los dos lo reconocen. Cuando encuentran algo casi correcto, ninguno de los dos lo hace.

La diferencia más clara está en el comportamiento

Además de las preguntas, ejecutamos ocho pequeños escenarios de agente con herramientas simuladas, cinco intentos cada uno, en inglés y en alemán, con el razonamiento desactivado y activado. Reproducen fallos que hemos visto en producción: una búsqueda que no encuentra nada, una herramienta que no para de agotar el tiempo de espera, una llamada a herramienta escrita como texto en lugar de ejecutarse, una lista larga que hay que devolver. El marcador está en el anexo E.

El modo de razonamiento de Kolibri-1 insiste cuando una herramienta no devuelve nada. En los dos escenarios en los que la búsqueda no encuentra nada o se queda sin tiempo una y otra vez, Kolibri-1, con el razonamiento en el nivel que evalúa su fabricante y el muestreo recomendado, repitió la búsqueda con formulaciones nuevas hasta el límite de rondas del banco de pruebas y, como ese banco no tiene respuesta de reserva, no dio respuesta en 6 de 10 intentos en inglés. Las llamadas varían; no es la misma llamada repetida. Hemos leído las llamadas, no el razonamiento, que el banco de pruebas no guardó en esos intentos. Con un nivel de razonamiento más bajo, los fallos se redujeron a la mitad, a 3 de 10. Sin razonamiento casi desaparecieron en inglés (1 de 20 intentos con muestreo, ninguno a temperatura 0), pero no en alemán (6 de 20). Qwen3.6 con razonamiento, con su muestreo recomendado, respondió en 10 de 10 intentos en inglés y en 9 de 10 en alemán. El bucle de nuestro producto se comporta de otra manera que el banco de pruebas: fuerza una respuesta final cuando se agota su presupuesto, y 77 de las 78 respuestas que llegaron a ese presupuesto respondieron igualmente. La única respuesta desbocada de la prueba principal, una pregunta de Kolibri-1 que tardó 47 minutos y nueve rondas y luego no dio respuesta, terminó antes de llegar a ese presupuesto.

Los escenarios de agente también se ejecutaron con razonamiento a temperatura 0, porque nuestro script de escenarios los ejecuta todos con los dos muestreos; las preguntas, no. Ningún fabricante recomienda esa combinación: los dos publican configuraciones de muestreo para el razonamiento, y se sabe que la decodificación voraz (greedy) en una cadena de razonamiento larga tiende a caer en bucles de alta probabilidad. Pasó justo lo que las configuraciones de muestreo existen para evitar. En los dos escenarios, Kolibri-1 no dio respuesta en ninguno (cinco intentos casi idénticos cada uno, así que son dos observaciones más que diez), y en cinco de los diez intentos razonó hasta el límite de 32.768 tokens, el más largo al cabo de 56 minutos. Qwen3.6 respondió en todos. Lo contamos solo porque un proxy o una aplicación pueden enviar esa combinación por error: es un aviso para el despliegue, no una nota, y nuestro producto no la envía nunca.

Un presupuesto de tokens mayor no lo contiene: las respuestas desbocadas pasaron de 32.768 tokens. Lo que lo contiene es un presupuesto por respuesta en tiempo o en tokens, un límite de búsquedas repetidas que no devuelven nada y una respuesta de reserva que conteste con lo que se haya encontrado. Nuestro bucle ya tiene un presupuesto de diez rondas y dieciséis llamadas a herramientas, tras el cual tiene que responder sin herramientas; 77 respuestas llegaron a él, y todas menos una dieron una respuesta. Lo siguiente que añadiremos es un presupuesto de tiempo.

Lo vemos como una excepción propia de los primeros días más que como un veredicto. Kolibri-1 tiene días de vida, y su plugin para el servidor es más nuevo aún. Los fallos iniciales del propio Qwen3.6, que no aparecieron en esta prueba (ver más abajo), son el precedente. Los modelos se asientan, los servidores se ponen al día y la aplicación aprende de qué tiene que protegerse. Lo que importa es vigilar, medir y anticiparse a ese comportamiento con estrategias de respuesta, que es justo lo que son los presupuestos de los que hablábamos.

Cambios de idioma, en las dos direcciones. Con preguntas en alemán y sin razonamiento, Kolibri-1 respondió en inglés en 15 de 119 respuestas con búsqueda; Qwen3.6, en 4. En los escenarios de agente con razonamiento, Kolibri-1 respondió en alemán a prompts en inglés en 5 de 11 casos en los que la herramienta no tenía nada o fallaba, con las instrucciones y la pregunta en inglés y los resultados de la herramienta en español, el idioma de nuestros datos simulados; el alemán no estaba en ninguna de sus entradas. Hay una salvedad que nuestro montaje le debe a Kolibri-1: nuestras instrucciones de respuesta están en inglés sea cual sea el idioma de la pregunta, y 34 de los 48 documentos están en inglés. Así que una pregunta en alemán llega con instrucciones en inglés. Es realista para una multinacional y es nuestro producto tal como está construido, pero no es Kolibri-1 en su idioma. Los correctores no puntuaron el idioma: la rúbrica no tiene ningún criterio de idioma, y ninguna nota de corrección lo menciona. Las respuestas con cambio de idioma sí sacaron menos nota que el resto, lo que sugiere que el cambio acompaña a las preguntas difíciles más que provocar una nota más baja.

Los fallos antiguos de Qwen3.6 no aparecieron. Con la versión de 4 bits que probamos antes que esta habíamos visto llamadas a herramientas escritas dentro de su razonamiento y razonamientos interminables. En el servidor FP8 equiparado, ninguno de sus textos de razonamiento contenía marcado de llamadas a herramientas y ninguno de sus 160 intentos de agente con razonamiento escribió una llamada como texto. No sabemos decir qué cambio lo arregló: los pesos, la versión del servidor, la precisión de la caché y la decodificación especulativa cambiaron a la vez.

Qwen3.6 tiene un pequeño fallo propio. Con preguntas en alemán y sin razonamiento, empezó 10 de 119 respuestas con búsqueda con una etiqueta <tool_call> suelta, y luego respondió correctamente. Los usuarios ven esa etiqueta a menos que la aplicación la quite. Ninguna de sus 119 respuestas en inglés la tenía. La ficha de Qwen3.6 advierte de que una penalización de presencia más alta, que pusimos en el 1,5 recomendado, «may occasionally result in language mixing and a slight decrease in model performance»: puede mezclar idiomas de vez en cuando y rebajar un poco el rendimiento del modelo. Sus pocas respuestas en el idioma equivocado y estas etiquetas hay que leerlas teniéndolo en cuenta.

En marcha: una DGX Spark por modelo

Cada modelo funcionó en su propia DGX Spark: una estación de trabajo de sobremesa con el chip GB10 Grace Blackwell de NVIDIA y 128 GB de memoria compartida entre procesador y gráfica, montada en nuestros racks. Kolibri-1 en FP8 ocupa unos 74 GiB de esa memoria, y aun así deja sitio para nueve conversaciones de longitud completa.

Instalarlo fue sencillo. Aleph Alpha distribuye con el modelo un plugin para el servidor de inferencia, y Kolibri-1 respondió sus primeras preguntas en una DGX Spark el mismo día de su lanzamiento, sin cambiar nuestro código. El modelo venía bien preparado, y daba la casualidad de que cabía en nuestras máquinas. Con Qwen3.6, en su momento, no fue así. La versión del servidor que lo soportaba era una versión candidata; la única versión del modelo que cabía era una compresión a 4 bits de un tercero, y esa versión necesitaba un fichero de tokenizador parcheado, que cortaba cualquier entrada en 4.096 tokens hasta que dimos con la causa. Eso nos costó días. En parte fue culpa del software de servidor de entonces, que desde entonces se ha puesto al día.

En una DGX Spark	Kolibri-1	Qwen3.6
Memoria que ocupa el modelo	73,6 GiB	34,2 GiB
Del arranque a la primera respuesta	11 minutos	unos 8 minutos
Caché para conversaciones	2,4 millones de tokens	7,0 millones de tokens
Conversaciones con la ventana completa de 262.144 tokens	9	unas 27
Rondas del modelo / llamadas a herramientas por respuesta con búsqueda, sin razonamiento, lo típico (mediana)	4 / 5	2 / 2
Tokens de prompt leídos por respuesta con búsqueda, sumando sus rondas (unos 14.000 y 9.000 por ronda)	unos 86.000	unos 53.000

Qwen3.6 aguanta unas tres veces más conversaciones largas en la misma máquina. Los dos modelos mantienen una caché que crece con la conversación solo en 10 de sus capas; la diferencia es sobre todo de espacio. Los pesos de Qwen3.6 ocupan la mitad de memoria, lo que deja el doble para la caché. El resto se debe a cómo organiza el servidor cada caché, algo que no hemos analizado. Para que la comparación fuera justa, limitamos los dos servidores a ocho peticiones simultáneas, lo máximo que admite la caché de Kolibri-1 con la ventana completa. Nueve conversaciones es el caso extremo, con cada una llenando a la vez toda la ventana de 262.144 tokens. La mayoría de las conversaciones son mucho más cortas: una ronda de búsqueda en esta prueba ronda los 14.000 tokens, y a ese tamaño la misma caché aguanta bastante más de cien. La prueba en sí solo lanzó cuatro preguntas a la vez por servidor, además de los escenarios de agente; la caché nunca fue el cuello de botella, y solo cuando el servidor de Kolibri-1 tuvo más de ocho peticiones en curso el límite las puso en cola, lo que forma parte de la salvedad sobre la carga que acompaña a todos los tiempos de este artículo.

Estas cifras son las de serie. No ajustamos nada; el propio servidor trae una configuración de kernels ajustada para la forma de las capas de Qwen3.6 en este chip y ninguna para la de Kolibri-1, así que cualquier diferencia de velocidad favorece a Qwen3.6 también por ese motivo. El servidor avisa además de que su formato de caché que ahorra memoria funciona sin calibrar en los dos modelos. Hay margen para ir más rápido, y quizá para ganar algo de precisión.

Velocidad con la máquina sin carga

Todos los tiempos de las tablas de resultados se tomaron con carga de prueba y solo sirven para comparar dentro de un mismo modelo. Por eso, la tarde del 5 de octubre medimos los dos servidores por separado: sin ningún otro trabajo, con documentos reales de la biblioteca de prueba como prompt y cada escenario hasta diez veces. Cómo lo hicimos y qué sesgos descarta la medición está en el anexo C; los datos en bruto se guardan junto con el conjunto de datos.

En una DGX Spark sin carga, sin razonamiento	Kolibri-1	Qwen3.6
Escritura, una petición, prompt corto	48 tokens/s	54 tokens/s
Escritura, una petición, tras un prompt de 14.000 tokens (una ronda de búsqueda)	45	52
Lo mismo en palabras: un informe real en alemán, 800 palabras pedidas	31 palabras/s	26 palabras/s
Escritura, una petición, con razonamiento	48	54
Escritura, dos / cuatro / ocho peticiones a la vez, cada una	39 / 30 / 20	44 / 33 / 23
Lo que escribe la máquina entera, ocho peticiones a la vez	152 tokens/s	175 tokens/s
Espera hasta la primera palabra, prompt corto	0,5 s	0,4 s
Espera hasta la primera palabra, una ronda de búsqueda (14.000 tokens)	2,6 s	3,0 s
Espera hasta la primera palabra, toda la biblioteca leída por primera vez (157.000 y 152.000 tokens)	63 s	59 s
La misma biblioteca otra vez, desde la caché	1,1 s	1,8 s
Escritura con toda la biblioteca en la conversación	34	38
Cuatro rondas de búsqueda a la vez: primera palabra / escritura por petición	6,7 s / 22	9,3 s / 27
Ocho rondas de búsqueda a la vez: primera palabra / escritura por petición	12 s / 13	16 s / 15

Medianas de entre tres y diez repeticiones. La velocidad de escritura varió entre repeticiones como mucho en un token por segundo; todos los rangos están en el anexo C.

Los dos escriben más rápido de lo que nadie lee. Una respuesta típica con búsqueda y sin razonamiento en esta prueba, de unos 360 tokens, se escribe en unos ocho segundos con Kolibri-1 y en siete con Qwen3.6; una respuesta típica con razonamiento, de 4.400 tokens en Kolibri-1 y 2.800 en Qwen3.6, tarda unos 90 y 50 segundos. El razonamiento no ralentiza la escritura; multiplica los tokens. Y los tokens no son palabras: por token, Qwen3.6 es un 13% más rápido; por palabra, Kolibri-1 lo es en torno a una quinta parte, porque su tokenizador encaja una palabra alemana en 1,45 tokens y el de Qwen3.6 necesita algo más de dos. Quien compara dos modelos por tokens por segundo también está comparando dos tokenizadores; lo que ve un lector son palabras.

Por qué un modelo de 78 GB escribe como uno pequeño. La escritura está limitada por el ancho de banda de la memoria: por cada token, la máquina saca de la memoria una vez todos los parámetros activos. Una DGX Spark mueve 273 GB por segundo. Kolibri-1 activa 3.460 de sus 78.000 millones de parámetros por token, unos 3,5 GB en FP8; Qwen3.6 activa 3.000 millones, unos 3,0 GB. Eso pone los techos en unos 79 y 91 tokens por segundo, y los dos modelos llegan al 60% del suyo: la misma eficiencia en el mismo servidor. La ventaja de Qwen3.6 por token, de un 13 a un 15% con cualquier carga, es la proporción entre los parámetros activos. Los 128 GB permiten cargar Kolibri-1; los 3.460 millones de parámetros activos son lo que lo hace lo bastante rápido. Con toda la biblioteca en la conversación, cada token lee además la caché de la conversación, unos 2,8 y 1,6 GB, y por eso ahí el ritmo baja a 34 y 38.

Con carga. Los dos servidores reparten la máquina de forma equitativa: con ocho peticiones a la vez, cada una sigue teniendo alrededor del 40% de la velocidad de una sola, y la máquina en conjunto escribe algo más del triple. El caso difícil no son las respuestas, sino los prompts. Cuatro rondas de búsqueda que llegan juntas reciben su primera palabra al cabo de siete y nueve segundos; ocho, al cabo de doce y dieciséis, cinco y seis de ellos en cola. Y leer una biblioteca entera paraliza todas las demás conversaciones del servidor: cuatro chats en marcha cayeron de unos 30 a menos de un token por segundo durante el minuto que duró la lectura, y luego se recuperaron. El servidor lee los prompts en pasos de 16.384 tokens, y durante cada paso todas las conversaciones en curso avanzan un token. El anexo A lo describe como «a costa de los demás usuarios»; medido, es una pausa de tres segundos por una ronda de búsqueda y un parón de un minuto por una biblioteca entera. Las palancas son pasos de lectura más pequeños, prioridad para las conversaciones en curso o un servidor aparte para las lecturas largas; todavía no las hemos probado.

Dos cosas que conviene preguntarle a cualquier benchmark están en el anexo C: si la caché de prompts estaba fría y si las peticiones en paralelo eran distintas. Aquí, cuatro peticiones idénticas escriben 38 tokens por segundo en lugar de 30.

Lo que dejamos fuera: las imágenes

Qwen3.6 también puede mirar imágenes; Kolibri-1 solo lee texto. En un producto documental eso importa: albaranes fotografiados, procedimientos escaneados, tickets.

Lo dejamos fuera de la comparación a propósito. Los tres documentos escaneados de nuestra biblioteca los leyó una sola vez, por adelantado, una versión anterior de 4 bits de Qwen3.6 que funcionaba en nuestro propio hardware, y se guardaron como texto. Después, los dos modelos respondieron a partir de exactamente el mismo texto. A Kolibri-1 no se le restó por no ver, ni a Qwen3.6 se le sumó por hacerlo.

Sea cual sea el resultado, leer escaneos y fotos requiere un modelo de visión. Algunos modelos hacen las dos cosas, como Qwen3.6 o algunos de los modelos de Mistral. Con un modelo solo de texto como Kolibri-1, el trabajo se reparte entre dos modelos, uno para las imágenes y otro para el texto, y eso no es ningún problema en hardware como este: en esta prueba, cada uno tenía su propia máquina. La pregunta aquí es más acotada: qué modelo lee, razona y responde mejor sobre texto.

Hay una consecuencia que conviene dejar clara. Si el modelo de visión hubiera leído mal un escaneo, los dos modelos habrían heredado el error. La comprobación de datos descrita más arriba confirmó que todos los datos clave sobrevivieron a la lectura.

Cómo nos aseguramos de que fuera justo

Comparar dos modelos solo tiene sentido cuando todo, salvo el modelo, es igual. Nuestra primera pasada, el 3 de octubre, no estaba a la altura: Qwen3.6 funcionaba con una versión comprimida a 4 bits de un tercero, en una versión anterior del servidor y con la mitad de ventana. Ahí Kolibri-1 iba por delante. Así que reconstruimos el servidor de Qwen3.6 para igualarlo con el de Kolibri-1 y repetimos todas las pruebas, con los dos modelos. Todas las conclusiones sobre los modelos de este artículo salen de esa repetición.

En la repetición, los dos modelos funcionaron:

• en el mismo tipo de máquina (DGX Spark), con el mismo servidor de inferencia (vLLM 0.29.0) y con la versión FP8 de cada fabricante;
• con la misma ventana, la misma configuración de caché, la misma cuota de memoria y el mismo límite de peticiones simultáneas;
• a través de nuestro pipeline real de respuesta, con los mismos prompts, el mismo índice de búsqueda, los mismos límites de longitud de respuesta y las mismas salvaguardas, cambiando únicamente el modelo.

Solo se diferenciaron donde el modelo lo exige: el formato en el que cada uno escribe las llamadas a herramientas, su interruptor de razonamiento y la configuración de muestreo que recomienda su fabricante. Ejecutamos cada modelo con esa configuración, con la fija que usa nuestro chat y con una temperatura baja, nuestra candidata a configuración por defecto. Con el razonamiento activado solo se usó el muestreo recomendado por los fabricantes: ninguno de los dos evalúa el razonamiento a temperatura 0, y nuestro producto no envía esa combinación.

Cada pregunta se hizo una vez con la configuración fija, con la que las respuestas se repiten, y tres veces con cada una de las otras dos; con razonamiento, dos veces cada una. Las respuestas se barajaron, se les quitó el nombre del modelo y se corrigieron a ciegas contra el solucionario, dos veces, por dos modelos de IA de dos fabricantes distintos.

La configuración exacta, y el motivo de cada ajuste, están en los anexos del final, junto con lo que cabe en una DGX Spark.

Lo que esta prueba no es

Esto es una primera toma de contacto con un modelo recién salido del horno, no un benchmark: un primer intento, hecho con toda la disciplina que hemos sido capaces de aplicarle, y que conviene tomar como un dato más. Léelo teniendo en cuenta estas limitaciones.

• Es pequeña. Diecisiete preguntas, una empresa ficticia, de una a tres tandas por configuración. Las diferencias de unas centésimas por respuesta son ruido. La diferencia con razonamiento se apoya en dos tandas, 68 respuestas por modelo.
• La IA escribió la prueba y la IA la corrigió. Claude Opus 5.5, con esfuerzo «extra alto» y bajo nuestra dirección, escribió la biblioteca, el solucionario y las pruebas. Después, dos correctores calificaron a ciegas cada respuesta como correcta, parcial o incorrecta según ese solucionario: agentes basados en Claude Opus 5.5 con esfuerzo «extra alto», el mismo modelo que escribió la prueba, y GPT-6.1 Sol, de OpenAI, con esfuerzo de razonamiento alto, en Codex. Coincidieron en el 78% de las notas, y nunca uno dio por correcta una respuesta que el otro diera por incorrecta. No resolvimos sus desacuerdos; cada conclusión se da con los dos, y cuando difieren en grado lo decimos: la ventaja de Qwen3.6 con toda la biblioteca en el prompt se sostiene con los dos; su ventaja menor cuando se le dan solo los documentos correctos queda dentro del ruido con los dos, y la ventaja de Kolibri-1 con razonamiento está en el límite de lo que pueden mostrar 17 preguntas. El segundo corrector trabajó más a ciegas que el primero (anexo D), y ninguna persona ha corregido todavía una sola respuesta; el siguiente paso son cincuenta notas humanas a ciegas. Ninguno de los dos modelos comparados es de los fabricantes de los correctores. El segundo corrector reduce el riesgo de que autor y corrector compartan puntos ciegos, pero no lo elimina.
• El pipeline conoció antes a Qwen. Nuestros prompts se escribieron primero con Qwen como el modelo que ya usábamos, y eso puede favorecerlo.
• Idiomas. Kolibri-1 admite oficialmente alemán e inglés. Nuestra biblioteca incluye también documentos en español, polaco y chino, como la de cualquier grupo real. Las preguntas se hicieron en inglés y en alemán, con instrucciones en inglés en los dos casos. El español viene después.
• No se compararon imágenes. Los dos modelos respondieron a partir del mismo texto (ver más arriba).
• Dos preguntas requieren leyes que la biblioteca no contiene. Nuestro solucionario esperaba que el modelo las conociera, la jornada de 42 horas de Chile y la cogestión alemana (Mitbestimmung), y los dos modelos fallaron casi siempre: una pregunta salió mal en las 79 respuestas, y la otra, en 72 de 78. Se puede defender que la mejor respuesta habría sido decir que la biblioteca no lo cubre. Es un fallo de nuestro solucionario más que de los modelos, y las dos preguntas se presentan aparte.
• Una pregunta pide un resumen, el de las normas de la política de uso de IA sobre datos confidenciales. El primer corrector aceptó casi todas las respuestas de los dos modelos; el segundo dio por parciales la mayoría por dejarse normas secundarias. Resumir, como tarea en sí, no se probó.
• Un solucionario estaba mal. El de la pregunta sobre un primer pedido antes del informe de minerales de conflicto de un proveedor esperaba una regla que está en el documento que dejamos fuera. Un modelo que dijo que los documentos no lo mencionan se dio por incorrecto, y un «no» rotundo se dio por correcto, lo que favoreció a Qwen3.6 en esa pregunta. Hay que corregir el solucionario y volver a calificar la pregunta; las cifras de arriba la incluyen. Sin ella y sin las dos preguntas de leyes externas, el empate con búsqueda se mantiene (Kolibri-1 por delante en 0,04 a 0,06 por pregunta, dentro del ruido) y la ventaja de Kolibri-1 con razonamiento es algo mayor.
• La precisión de la caché favorece a Kolibri-1, si es que favorece a alguno. Los dos servidores guardan la caché de la conversación en FP8, que es la configuración evaluada de Kolibri-1 y no la de Qwen3.6. Si el formato cuesta precisión, se la cuesta a Qwen3.6; los detalles, y la prueba de control que tenemos pendiente, están en el anexo D.
• Los escenarios de agente se construyeron a partir de los fallos de Qwen. Los ocho escenarios reproducen fallos que habíamos visto con la versión anterior de Qwen3.6 y con otro modelo. Apuntan a debilidades conocidas de Qwen3.6; un modelo que falle de otras maneras los pasa sin que se note.
• Todavía sin probar: una biblioteca a la que le falten documentos a propósito. Está en la lista de más abajo.

Con qué nos quedamos

Cuatro cosas, en el orden en que las preguntaría un comprador.

1. Cabe, y se instaló sin complicaciones. Kolibri-1 funciona en una sola DGX Spark desde el primer día, con el plugin de su fabricante y sin tocar nuestro código.
2. Responde tan bien como Qwen3.6 en el camino que usa nuestro producto. Con búsqueda y sin razonamiento, los dos empatan, con los dos correctores y en todas las configuraciones de muestreo. Qwen3.6 es uno de los modelos abiertos más usados, así que igualarlo no es poca cosa. Kolibri-1 llega ahí con más rondas y más tokens por respuesta, así que cuenta con que sea más lento, y en la misma máquina cabe solo un tercio de las conversaciones largas. Con el razonamiento activado quedó ligeramente por delante en las dos tandas, todavía sin salir del margen del azar, a cambio de una espera varias veces mayor. En trabajo de agentes, su modo de razonamiento puede seguir reintentando una búsqueda vacía hasta que lo pare un presupuesto; es algo que hay que prever con un presupuesto, no un veredicto.
3. Así que la elección pasa a ser una cuestión de cadena de suministro. Cuando la calidad está igualada, lo que decide es quién hace el modelo, dónde, con qué licencia, cómo se mantiene, cómo se maneja con tus idiomas y cuánta capacidad cuesta por máquina. Una empresa que quiera a su proveedor de IA en Europa, con el alemán contemplado desde el diseño, ahora puede elegir por esos motivos sin renunciar a calidad en este trabajo.
4. Las imágenes siguen necesitando un segundo modelo, y hardware para él. Kolibri-1 solo lee texto. Los escaneos, los albaranes fotografiados y los tickets necesitan un modelo de visión al lado, y en una DGX Spark eso significa una segunda máquina o un modelo más pequeño: un modelo de visión del tamaño de Qwen3.6 no cabe junto a Kolibri-1 en una sola Spark.

Tras este primer vistazo, el panorama es prometedor, y Kolibri-1 merece estar en la lista corta de cualquier empresa que pase sus documentos por un modelo privado. La práctica tiene que confirmarlo, y esa es la parte que más ganas tenemos de ver: lo siguiente es el español, luego más preguntas, más documentos y más modelos en el mismo marco y, por supuesto, el uso con clientes.

Más allá de los dos modelos, hay cuatro lecciones que valen uses el modelo que uses:

1. Buscar sale más barato, no más preciso. Con una biblioteca que cabe en el prompt, un modelo con todo a la vista respondió igual o mejor en tres de cuatro configuraciones. Lo que justifica la búsqueda es el coste y la escala: hasta tres veces menos tokens por pregunta, y sigue funcionando cuando la biblioteca ya no cabe.
2. La cobertura forma parte de la respuesta. Cuando la búsqueda no dio con el documento que tenía la respuesta, las 34 respuestas fueron parciales y sonaban seguras. Ninguna dijo «no lo sé». Un asistente tiene que saber, y decir, con qué documentos está trabajando, y la búsqueda hay que comprobarla con tu propia biblioteca antes de que nadie se fíe de ella.
3. Presupuestos, no límites más altos. Un modelo de razonamiento que no se detiene se contiene con un límite por respuesta y una respuesta de reserva, no dándole más margen. El comportamiento cuando algo falla importa tanto como la precisión cuando todo va bien.
4. Prueba con tus propios documentos, fallos incluidos. Cada biblioteca documental tiene sus propias contradicciones. Un modelo que sale bien parado en los benchmarks públicos puede seguir quedándose con el primer valor que encuentra.

Elegir un modelo es elegir un proveedor

El rendimiento es solo una parte de la decisión. Una empresa que ejecuta un modelo en su propio hardware también está eligiendo de quién depende para la siguiente versión, para las correcciones y para lo bien que el modelo manejará sus idiomas. Muchos de nuestros clientes ya piensan así sobre sus otros proveedores: de dónde viene un componente, con qué reglas se fabrica, si hay una segunda fuente de suministro. Un modelo de IA se está convirtiendo en un componente como otro cualquiera.

Ya hay modelos abiertos serios de fabricantes estadounidenses, chinos y franceses, y con Kolibri-1, uno alemán. Eso es lo que queremos dar a nuestros clientes: opciones. El origen y el mantenimiento tienen que estar en la lista, junto a la precisión, la velocidad y el coste: quién hace el modelo, dónde y quién lo va a mantener al día. Para muchas de las empresas con las que hablamos, no son cuestiones secundarias.

Los pesos abiertos suavizan la dependencia: una vez que tienes un modelo con una licencia como Apache 2.0, puedes seguir ejecutándolo pase lo que pase. El resto es arquitectura. En Iristrace Docs el modelo está detrás de un enrutador, y cambiar uno por otro, como hicimos para esta prueba, cambia el modelo y nada más.

Las preguntas que le haríamos a cualquier modelo:

• ¿Hace el trabajo con tus documentos y en tus idiomas?
• ¿Qué hardware necesita, y cuánto cuesta tenerlo funcionando?
• ¿Con qué licencia, y qué cubre exactamente?
• ¿Quién lo hace, dónde, y qué probabilidades hay de que lo siga mejorando?
• ¿Qué facilidad tendrías para cambiar a otro modelo más adelante?

Lo que viene

Esto ha sido un primer vistazo, y plantea tantas preguntas como responde. Los próximos pasos, por orden:

• Resumir, como tarea en sí. Una política resumida para un empleado nuevo, qué ha cambiado entre dos revisiones, una instrucción de trabajo en polaco o en chino resumida en alemán; comprobando los datos que se conservan, las cifras inventadas, el idioma y la extensión.
• Una biblioteca con huecos. Las mismas preguntas con los documentos clave retirados a propósito, para medir con qué frecuencia cada modelo dice «los documentos que tengo no lo dicen» en lugar de adivinar.
• Una regla para las contradicciones. Probaremos una instrucción que ponga la contradicción antes de la conclusión, con los dos modelos y con preguntas nuevas, para no ajustar el prompt a estas diecisiete.
• El español, a fondo. Muchos de nuestros clientes trabajan en español. Kolibri-1 admite oficialmente alemán e inglés, así que lo siguiente es someter su español a un buen examen: preguntas, documentos y respuestas.
• Alemán de principio a fin. En esta prueba, nuestras instrucciones de respuesta estaban en inglés aunque la pregunta fuera en alemán: realista para un grupo, pero no es Kolibri-1 en su idioma. Lo próximo es darle instrucciones en alemán para las preguntas en alemán.
• Extracción y datos estructurados. Convertir facturas, albaranes y escaneos en datos estructurados no se puede hacer sin un modelo de visión. Las preguntas sobre registros (cuántas facturas vinieron de un proveedor, cuál fue la mayor) se responden luego con llamadas a herramientas estructuradas sobre esos datos, y los agentes de IA podrán trabajar directamente con Iristrace a través de un servidor MCP. Todo esto necesita su propia investigación y su propia medición: escenarios de fallo, muchas repeticiones, razonamiento activado y desactivado. Eso lleva bastante más que un fin de semana.
• Más modelos, en igualdad de condiciones. Gemma 4 de Google, gpt-oss de OpenAI y Ministral de Mistral, por citar algunos, servidos en condiciones lo más idénticas posible, para que los resultados sigan siendo comparables.
• Agentes de larga duración. Aleph Alpha también posiciona Kolibri-1 para el trabajo con agentes. Los agentes que resuelven una tarea a lo largo de muchos pasos, durante minutos y no segundos, son lo siguiente que queremos ver con nuestros propios ojos, empezando por Kolibri-1 con un nivel de razonamiento más bajo y un límite estricto de búsquedas repetidas.
• Leer sin frenar a los demás. Pasos de lectura más pequeños o prioridad para las conversaciones en curso, para que leer una biblioteca entera no deje a todos los demás parados durante un minuto. Está medido, no supuesto; los remedios están por probar.

Y para convertir una primera toma de contacto en algo más parecido a una medición, la propia prueba tiene que crecer: más preguntas, algunas escritas por personas que nunca hayan visto los solucionarios; una biblioteca más grande, con más de las contradicciones que van acumulando las bibliotecas reales; más tandas, y que haya personas revisando una parte del trabajo de los correctores de IA, para que los jueces no sean solo máquinas.

Somos curiosos, tenemos la mente abierta y nos encanta trabajar con esta tecnología.

---

Así que Kolibri-1 funciona en una DGX Spark y da la talla. Un aplauso para Aleph Alpha, y gracias a Heidelberg, por una nueva opción sólida de IA privada en un hardware que una mediana empresa se puede permitir. Para ese tipo de empresas es una alternativa real más, aparte de los pesos pesados estadounidenses y chinos: un modelo solvente de origen europeo.

Si quieres saber más, o ver si una instalación de IA privada como esta podría servir para tu operativa, escríbenos. Además de nuestras dos líneas de producto, Iristrace Checks e Iristrace Docs, ofrecemos formación y asesoramiento. Estaremos encantados de hablar contigo y de llevarlo más lejos juntos.

Sobre este artículo. Es un relato de primera mano de Iristrace sobre una prueba de dos días hecha con IA, escrito internamente y sin revisión externa: no es un benchmark ni una clasificación general de los modelos. No tenemos ningún acuerdo de colaboración ni otra vinculación con Aleph Alpha ni con Alibaba, y no hemos recibido ninguna compensación por este artículo; nuestra única relación con NVIDIA es que le compramos las DGX Spark como un cliente más. Ninguna de las tres empresas vio este texto antes de su publicación. Los documentos de prueba pertenecen a empresas ficticias; todas las empresas y personas que aparecen en ellos son inventadas. Los modelos de IA escribieron la biblioteca de prueba, corrigieron las respuestas, hicieron la estadística y ayudaron a escribir este texto; Iristrace lo revisó y responde de él. Montamos y gestionamos instalaciones de IA privada, con el modelo que mejor le encaje a cada cliente.

Actualizado el 6 de octubre de 2026. Se añaden el apartado «Velocidad con la máquina sin carga», con la medición del 5 de octubre, su método en el anexo C y el párrafo sobre la forma del modelo en «Por qué hicimos esta prueba». Los resultados de la prueba no cambian.

Anexos, para los más técnicos

Anexo A — Cómo se configuraron los dos servidores, y por qué

Los dos modelos se sirvieron con vLLM 0.29.0, cada uno en su propia DGX Spark, detrás del mismo proxy LiteLLM y del mismo pipeline de respuesta. Cada ajuste que tenía que coincidir se eligió por un motivo, puesto por escrito antes de las pruebas.

Igual en los dos servidores	Valor	Por qué
Máquina	NVIDIA DGX Spark: GB10 Grace Blackwell, 128 GB de memoria unificada, 273 GB/s	Una por modelo, para que ninguno compita con el otro por la memoria
Servidor de inferencia	vLLM 0.29.0	La versión que soporta el plugin de Aleph Alpha. El plugin sigue una sola versión de vLLM cada vez, así que los dos servidores se actualizan a la par
Pesos	FP8: e4m3, bloques de 128×128, activaciones dinámicas	La versión de cada fabricante, en el mismo formato. Sin compresiones de terceros
Ventana de contexto	262.144 tokens	El máximo nativo de los dos modelos. Toda la biblioteca en un prompt necesita unos 160.000
Caché KV	FP8	La recomienda Aleph Alpha. A precisión completa, la caché de Kolibri-1 aguantaría la mitad
Cuota de memoria de la GPU	0,9	La memoria de la Spark se comparte con el sistema operativo; así le quedan unos 12 GiB
Peticiones simultáneas	8	Lo máximo que aguanta la caché de Kolibri-1 con la ventana completa (9,04), redondeado hacia abajo, para que ninguna petición se pause nunca por falta de memoria. Qwen3.6 podría aguantar más; se le dan 8 para que ningún servidor ejecute más en paralelo que el otro
Tokens de prompt por paso de planificación	16.384	Nuestros prompts son largos (de 20.000 a 160.000 tokens). Con pasos más grandes se leen más rápido, a costa de los demás usuarios: mientras se lee un prompt largo, sus conversaciones prácticamente se detienen (medido en «En marcha»)
Caché de prefijos	Activada	Un prompt que empieza igual no se lee dos veces. Mantenemos idéntico el principio de nuestros prompts: la fecha y la pregunta van al final
Decodificación especulativa	Desactivada	Sin pérdidas en principio, pero mete varios tokens por paso en el parser de llamadas a herramientas en streaming, donde ya hemos tenido problemas. Ahí, la velocidad no compensa añadir una pieza móvil más
Preguntas en curso	4 por servidor	Los tiempos de este artículo incluyen la espera detrás de otros trabajos, y el servidor de Kolibri-1 cargó con más; los tiempos se comparan dentro de un modelo, no entre los dos

Distinto a propósito	Kolibri-1	Qwen3.6
Parsers de llamadas a herramientas y de razonamiento	kolibri1	qwen3_coder, qwen3
Plugin de vLLM	aleph-alpha-inference, de Aleph Alpha	ninguno
Muestreo recomendado	temperatura 1,0, top-p 0,97, top-k 128	con razonamiento: 1,0, 0,95, 20; sin él: 0,7, 0,8, 20; penalización de presencia 1,5
Interruptor de razonamiento	reasoning_effort, en high, el nivel evaluado por el fabricante	enable_thinking
Ajuste de kernels	ninguno	DeepGEMM desactivado: vLLM avisa de que su formato de escalas FP8 degrada esta arquitectura en Blackwell

Hay tres ajustes que difieren de nuestro producto. El límite de razonamiento era de 32.768 tokens por ronda en la prueba; el producto usa 16.384. La prueba lanzaba cuatro preguntas a la vez por servidor. Y, con el razonamiento activado, la prueba enviaba la penalización de presencia de 1,5 de Qwen3.6, que la ruta de razonamiento del producto no envía; en ese único aspecto, el producto difiere de lo que probamos. Un pequeño script lee los dos servidores en marcha y falla si cualquiera de siete ajustes es distinto: la versión de vLLM, el formato de los pesos, la ventana de contexto, la precisión de la caché, la cuota de memoria, la caché de prefijos y la decodificación especulativa. Otros tres que no puede ver desde fuera —el número de peticiones servidas a la vez, los tokens de prompt leídos por paso y los kernels que eligió cada servidor— los comprobamos en el registro de arranque de cada servidor. Los dos registros muestran además la misma máquina.

Anexo B — Qué cabe en una DGX Spark

La ficha del modelo dice, textualmente: «Model memory footprint: ~78 GB (FP8 weights). Minimum: 2× A100 80 GB, 2× H100 SXM5, 1× H200, 1× B200 or 1× B300. Recommended: 2× H100 SXM5, 2× H200, 1× B200 or 1× B300». Una DGX Spark tiene 128 GB de memoria, compartida entre procesador y gráfica. Los ~78 GB de la ficha y los 73,6 GiB de la tabla de abajo son la misma cantidad en unidades distintas. Así es como cupo Kolibri-1, según su último registro de arranque:

Kolibri-1 en una DGX Spark	GiB
Memoria visible al arrancar	121,7
Cuota de vLLM (0,9)	unos 109,5
Pesos del modelo en memoria, FP8	73,6
Caché KV, FP8: 2.370.457 tokens, 9,04 conversaciones con la ventana completa	34,1
Memoria de trabajo para el propio cálculo	unos 2
Lo que queda para el sistema operativo y todo lo demás	unos 12

Uno al lado del otro	Kolibri-1	Qwen3.6
Parámetros, totales / activos por token	78.100 millones / 3.460 millones	35.000 millones / 3.000 millones
Pesos en memoria, FP8	73,6 GiB	34,2 GiB
Caché KV	2.370.457 tokens	7.014.337 tokens
Conversaciones con la ventana completa de 262.144 tokens	9,04	26,76
Del arranque a la primera respuesta	11 minutos	unos 8 minutos

¿Por qué Qwen3.6 aguanta el triple de conversación? No porque su caché crezca en menos capas: los dos modelos mantienen una caché que crece con cada token solo en 10 capas (Kolibri-1 en 10 de 50, mientras las otras 40 miran 513 tokens hacia atrás; Qwen3.6 en 10 de 40, mientras las otras 30 usan atención lineal). La diferencia es sobre todo de espacio. Los pesos de Qwen3.6 ocupan la mitad de memoria, lo que deja el doble para la caché. El resto se debe a cómo organiza el servidor cada caché, algo que no hemos analizado.

Los dos servidores leen sus pesos del disco sin lectura anticipada, a unos 120-145 MB/s. Los 74 GiB de Kolibri-1 se llevan unos nueve de sus once minutos; los 34 GiB de Qwen3.6, cinco. En la práctica, reiniciar el servidor del modelo es algo que se planifica, no un visto y no visto.

Queda una pregunta abierta. Antes de su último reinicio, con la misma cuota de memoria, el servidor de Kolibri-1 informaba de una caché de 3,38 millones de tokens; después, de 2,37 millones. Las cuentas acotan el problema: la caché final cuesta unos 15,4 KB por token (34,1 GiB para 2,37 millones de tokens), y a ese ritmo 3,38 millones de tokens necesitarían 48,6 GiB, más que los 36 GiB que quedan junto a los pesos. Así que el servidor anterior tuvo que organizar su caché con un coste por token más bajo. La capacidad no desapareció; lo que cambió con el reinicio fue la contabilidad, y qué ajuste la cambió es lo que todavía no hemos averiguado.

Anexo C — Toda la biblioteca en un solo prompt, y la velocidad con los servidores sin carga

Los dos modelos leen de forma nativa hasta 262.144 tokens. Nuestra biblioteca entera son unos 160.000, así que cabe en un solo prompt con margen de sobra. Las dos fichas describen ventanas más largas, de alrededor de un millón de tokens: la de Kolibri-1 dice que el fabricante validó la calidad hasta 1.048.576 tokens, y Qwen3.6 llega ahí con el escalado YaRN. Eso no lo probamos; los dos funcionaron con su ventana nativa, y tanteamos su límite.

El límite de la ventana, con los servidores sin carga. Se colocan tres valores cortos al principio, en medio y al final de un archivo de registros numerados, y se le piden los tres al modelo. Cada prompt empieza con una línea aleatoria nueva, para que el servidor no pueda reaprovechar una lectura anterior; los tiempos son en frío, sin razonamiento y a temperatura 0. Esta fue la única prueba que se hizo sin nada más en ninguno de los dos servidores, así que sus tiempos sí se pueden comparar entre ellos.

Tokens de prompt	Kolibri-1: segundos, encuentra los tres	Qwen3.6: segundos, encuentra los tres
unos 64.000	de 15 a 16, en 4 de 4 intentos	17, en 3 de 4 intentos
unos 129.000	45, sí	46, sí
unos 196.000	87, sí	89, sí
unos 247.000	130, sí	131, sí
unos 260.000	145, sí	146, sí
266.144, por encima de la ventana	rechazado, con un error limpio	rechazado, con un error limpio

Los dos recuperan los tres valores hasta el mismo borde de la ventana. El único fallo fue el primer intento de Qwen3.6 con 64.000 tokens, que devolvió tres números de registro en lugar de los valores colocados; las tres repeticiones con ese tamaño acertaron. Los dos leen un prompt largo a la misma velocidad, con unos dos segundos de diferencia como mucho en cada tamaño: de 3.700 a 4.200 tokens por segundo con 64.000 y unos 1.800 con 260.000, así que leer la ventana entera una vez lleva unos dos minutos y medio. Por encima de la ventana, los dos lo rechazan limpiamente con un error que explica por qué, y nuestra pasarela lo convierte en un mensaje para el usuario. La prueba es limitada, tres cadenas exactas en un relleno uniforme: dice que la ventana completa funciona y lo que cuesta leerla, no lo bien que razona un modelo sobre un conjunto largo y variado de documentos. Eso es lo que mide la condición de la biblioteca entera.

Lo que sí observamos, en unos 370 prompts con la biblioteca entera, de entre 145.000 y 159.000 tokens:

• La primera lectura cuesta un minuto. De 62 a 68 segundos hasta el primer token en cualquiera de los dos servidores, la primera vez que se lee una biblioteca.
• La segunda lectura es la barata. Cuando un prompt largo empieza exactamente igual que uno anterior, el servidor reaprovecha lo que ya ha leído y solo lee el resto. Después de la primera lectura, las respuestas empezaban en dos a cuatro segundos. Por eso nuestros prompts ponen primero los documentos y al final la fecha y la pregunta, y por eso importa que la plantilla de chat de un modelo no añada nada que cambie de una petición a otra.
• Con prompts largos es cuando aparece la repetición. Con la configuración fija y sin razonamiento, seis de 68 respuestas con la biblioteca entera empezaron a repetirse o chocaron con el límite de salida, más que en cualquier otra condición. Nuestro freno de repeticiones y el límite de salida las cortaron. Con el muestreo que recomiendan los propios fabricantes casi no hubo ninguna.

Velocidad de escritura y de lectura con los servidores sin carga: cómo la medimos. La tarde del 5 de octubre, de 20:44 a 21:14, un script midió cada servidor por separado desde la red de nuestra oficina, por la misma ruta que usa nuestra pasarela (Traefik con TLS), sin proxy, sin pasarela y sin prompt de sistema. Los dos servidores funcionaban con los ajustes del anexo A (vLLM 0.29.0, FP8, ocho peticiones simultáneas, pasos de lectura de 16.384 tokens, caché de prompts activada). Antes de empezar, sus propias métricas no mostraban ninguna petición en curso ni en espera, y la caché estaba vacía; durante la medición contaron exactamente las peticiones que enviamos, y ningún desalojo por falta de memoria. El script, los datos en bruto y una descripción completa del método se guardan junto con el conjunto de datos.

Qué es una petición. Un mensaje de usuario en tres partes. Primero, una línea que nombra el escenario, la ronda y la petición, para que nada de lo que viene después se pueda encontrar en la caché de prompts del servidor. Luego, documentos de la biblioteca de prueba, los mismos 48 ficheros que usó la prueba: un extracto de 120 palabras, documentos enteros hasta 8.000 palabras (unos 14.000 tokens, una ronda de búsqueda) o los 48 completos (157.000 tokens en Kolibri-1, 152.000 en Qwen3.6), cada vez empezando por un punto distinto. Y por último, la petición de un informe largo sobre normas, plazos y responsabilidades. Temperatura 0; un número fijo de tokens que escribir, que el modelo rellena más allá del final de su respuesta, porque lo que importa es el ritmo, no el contenido, salvo en el escenario de respuesta natural, que pide un informe de 800 palabras sin ese límite; razonamiento desactivado con los mismos interruptores que en la prueba, y activado en un escenario.

Qué se mide. Cada respuesta se recibe en streaming y cada fragmento lleva su marca de tiempo. La velocidad de escritura son los tokens posteriores al primero divididos por el tiempo entre el primero y el último; la lectura no entra. La espera hasta la primera palabra incluye la red, la cola y la lectura del prompt; un escenario con un solo token de salida mide los costes fijos (0,33 segundos, 0,25 de ellos en la red). Las peticiones en paralelo se envían todas en el mismo instante; la cifra por petición es la media, y el total de la máquina, todos los tokens escritos divididos por el tiempo hasta el último. Alrededor de cada medición leemos los contadores del servidor: cuántos tokens de prompt calculó y cuántos sacó de la caché, su propio tiempo hasta el primer token, los tiempos de lectura, escritura y cola, y los desalojos. La velocidad de escritura que da el servidor coincide con la del cliente hasta la décima en todos los escenarios; su tiempo hasta el primer token queda siempre un cuarto de segundo por debajo: es la red. Cada cifra es la mediana de sus repeticiones: diez para las peticiones sueltas, cinco para las paralelas, tres para la biblioteca y dos para los casos pesados, ejecutadas por turnos —la primera repetición de cada escenario, luego la segunda—, para que cualquier deriva a lo largo de la media hora afecte a todos por igual.

Sesgos, y qué hace la medición con cada uno.

1. Caché de prompts. El servidor guarda los resultados intermedios de prompts anteriores; un prompt que empieza igual se salta la parte conocida, lo que maquilla la espera hasta la primera palabra. La primera línea de cada petición lo impide, y los contadores lo demuestran: 32 tokens por petición desde la caché en Kolibri-1 (los primeros bloques de la plantilla de chat), 0 en Qwen3.6, cuyo bloque es de 2.096 tokens. Solo el escenario de la misma biblioteca otra vez quiere la caché: 157.088 de 157.097 tokens salieron de ella, y 150.912 de 152.052 en Qwen3.6; el último bloque, incompleto, no.
2. Peticiones idénticas en un mismo lote. Cuatro peticiones iguales a temperatura 0 escriben el mismo token, uno tras otro. Kolibri-1 escribe entonces 38 tokens por segundo por petición en lugar de 30, y Qwen3.6, 35 en lugar de 33. Los mismos cuatro prompts a temperatura 1 con semillas distintas —caché compartida, pero respuestas que divergen— dan 29,5 y 32,7, el nivel de prompts distintos. Así que la caché compartida no ahorra nada al escribir; lo que ahorra son las respuestas idénticas. En un modelo de mezcla de expertos cada token elige sus expertos, y cuatro tokens iguales eligen los mismos, así que el lote lee los pesos de un solo flujo en lugar de los de cuatro. Ninguna carga real envía cuatro peticiones iguales; todos los demás escenarios en paralelo usan prompts distintos. Un benchmark que no dice cuál de las dos cosas usó merece una pregunta.
3. Calentamiento y deriva. Antes de todo se lanzó una petición de calentamiento que se descartó. La cifra de una sola petición con prompt corto, tomada una vez en cada una de las diez rondas, se mantuvo entre 47,4 y 47,8 (Kolibri-1) y entre 53,6 y 54,0 (Qwen3.6) durante la media hora: ni deriva ni efectos térmicos. Dentro de una ráfaga de 100 segundos de ocho flujos de 2.048 tokens, el ritmo por flujo cayó un 5% (Kolibri-1) y un 13% (Qwen3.6), porque las conversaciones crecen y su caché se lee con cada token.
4. Dos tokenizadores. El mismo informe en alemán le cuesta a Kolibri-1 1,45 tokens por palabra, y a Qwen3.6, 2,02. Por eso los tokens por segundo también comparan tokenizadores; la tabla añade las palabras por segundo de respuestas reales, y el tamaño de los prompts en palabras.
5. Contenido de la salida. Con el número fijo de tokens, el modelo escribe más allá del final de su respuesta; la velocidad no depende del contenido, como confirma el escenario de respuesta natural sin ese límite (44,8 frente a 45,0 y 51,7 frente a 51,8).
6. Prompts largos y conversaciones en curso. Los prompts se leen en pasos de 16.384 tokens, y durante cada paso todas las conversaciones en curso avanzan un token. El escenario de cuatro chats y luego la biblioteca entera mide la consecuencia: los chats cayeron de 30 y 34 a 0,8 y 0,9 tokens por segundo hasta que se leyó la biblioteca, al cabo de 63 y 60 segundos, y luego siguieron a 27 y 32. La biblioteca en sí esperó lo mismo que con el servidor vacío: la lectura frenó a los chats, no al revés.
7. Relleno frente a documentos reales. Dos pasadas anteriores esa misma tarde usaron como prompt una frase repetida; donde los escenarios coinciden, quedaron a menos de un token por segundo de los mismos valores (48,2 frente a 47,6; 54,2 frente a 53,8).
8. Los límites del servidor. Los dos servidores admiten ocho peticiones; no enviamos más. Con ocho rondas de búsqueda a la vez, la primera palabra llegó al cabo de doce y dieciséis segundos, cinco y seis de ellos en cola detrás de los pasos de lectura.

Qué no mide. El pipeline (búsqueda, rondas de herramientas, pasarela, prompt de sistema), los usuarios reales y su forma de llegar, horas de carga sostenida, más de ocho peticiones, imágenes, otras cuantizaciones u otros servidores, ni ajustes: es el servidor tal y como viene, una tarde, en una pareja de máquinas.

Anexo D — Decisiones discutibles, y nuestras razones

Quien se gana la vida ejecutando modelos preguntará por la configuración antes que por las notas. Estas son las preguntas que nos haríamos nosotros, cada una con su respuesta y, cuando toca, con la prueba de control que aún tenemos pendiente.

¿Por qué estos dos modelos? Unos parámetros activos casi iguales, 3.460 y 3.000 millones por token, los ponen en la misma categoría de velocidad en el mismo hardware. Los dos caben en una DGX Spark en FP8, los dos son Apache 2.0 y los dos ofrecen razonamiento y llamadas a herramientas con una ventana de 262.144 tokens. Se diferencian justo donde un comprador quiere saber qué precio tiene la diferencia: Kolibri-1 tiene más del doble de parámetros totales, y la memoria que eso supone; Qwen3.6 cubre más idiomas y lee imágenes.

¿Por qué FP8, y la versión de cada fabricante? La precisión completa no cabe: los pesos de Kolibri-1 en bfloat16 necesitan unos 156 GB. El Qwen3.6 de 4 bits de un tercero que probamos antes conserva el 93% de la precisión completa en llamadas a herramientas de varios turnos, según la evaluación de su propio autor, y por eso nuestra primera pasada no fue justa. La versión FP8 de cada fabricante es la mayor precisión a la que pueden funcionar los dos aquí. Queda una asimetría: la última fase de entrenamiento de Kolibri-1 ya tuvo en cuenta la cuantización, mientras que el FP8 de Qwen3.6 se hizo después del entrenamiento. La ficha de Qwen dice que su FP8 es «nearly identical», casi idéntico, al original; eso no lo hemos medido nosotros.

¿Por qué una caché de conversación en FP8 en los dos? Porque Aleph Alpha sirve y evalúa Kolibri-1 así, y porque a precisión completa la caché de Kolibri-1 aguantaría la mitad. El fabricante de Qwen3.6 no documenta ese ajuste, y el servidor avisa de que las escalas están sin calibrar en los dos. Si el formato cuesta precisión, a Qwen3.6 le cuesta más que a Kolibri-1. La exposición es limitada, 10 de las 40 capas de Qwen3.6 frente a las 50 de Kolibri-1, y una caché a precisión completa habría sido viable solo para la prueba: Kolibri-1 habría podido seguir con los cuatro prompts de biblioteca entera en curso. La prueba de control que haríamos primero es Qwen3.6 con una caché a precisión completa, con búsqueda y sin razonamiento, unas cien respuestas.

¿Por qué el razonamiento en high? Es el nivel que evalúa y publica Aleph Alpha, y el razonamiento de Qwen3.6 no tiene niveles entre los que elegir. Comparar cada uno con la configuración evaluada por su fabricante es la opción defendible, y significa que los cinco minutos por respuesta corresponden al modo más caro de Kolibri-1. En los escenarios de agente, medium redujo a la mitad los casos sin respuesta; con las preguntas todavía no lo hemos probado. Es la segunda prueba de control que tenemos pendiente.

¿Por qué tres configuraciones de muestreo sin razonamiento y solo una con él? La temperatura 0 es lo que envía nuestro producto; las recomendaciones de los fabricantes son lo que ellos evalúan; 0,3 con top-p 0,9 es nuestra candidata a configuración por defecto, enviada a los dos. La ficha de Kolibri-1 da una única configuración, temperatura 1,0, sin una aparte para cuando el razonamiento está desactivado, así que su casilla de «recomendada» ejecuta un modo que su fabricante no ha puntuado; el 0,7 de Qwen3.6 está documentado, y su ficha añade que su penalización de presencia de 1,5, que usamos, «may occasionally result in language mixing and a slight decrease in model performance». Dos notas al pie, para ser honestos. La primera: una petición solo indica algunos parámetros; el resto queda en los valores por defecto de cada servidor, el top-k de su fabricante y, en el caso de Qwen3.6, la penalización de presencia fijada en su alias del proxy, así que a temperatura 0 y a 0,3 los dos eran iguales en lo que fijamos nosotros y diferían en lo que no, y la temperatura 0 de Qwen3.6 no era decodificación voraz pura. La segunda: todavía no hemos verificado de punta a punta que todos los parámetros atraviesen el proxy intactos; tenemos programada una comprobación de diez minutos. Ninguna de las dos notas afecta al empate con búsqueda, que se mantiene en las tres configuraciones, la de los fabricantes incluida. Con razonamiento solo se usó el muestreo de los fabricantes: ninguno recomienda la decodificación voraz para el razonamiento, los dos publican configuraciones de muestreo en su lugar, y nuestro producto nunca envía esa combinación. El script de escenarios la ejecutó de todos modos; el resultado aparece más arriba como aviso para el despliegue.

¿Por qué una tanda a temperatura 0 y tres con las demás? A temperatura 0 el modelo se repite casi palabra por palabra, así que tres tandas serían una sola muestra copiada tres veces. Con muestreo, cada tanda es una tirada nueva, así que ahí es donde tienen sentido las repeticiones.

¿Por qué un límite de razonamiento de 32.768 tokens si el producto admite 16.384? La ficha de Qwen3.6 aconseja 32.768 «for most queries», para la mayoría de las consultas, y con 16.384 Kolibri-1 se había quedado corto a mitad de razonamiento en dos preguntas en nuestra primera pasada. Cada respuesta registra sus tokens, así que los datos también dicen qué habría cortado el límite de 16.384: 13 de las primeras 114 respuestas con razonamiento de Kolibri-1.

¿Por qué cuatro preguntas a la vez, y por qué ningún veredicto sobre la velocidad? Para terminar en el tiempo que teníamos. Los dos servidores admiten ocho; los dos ejecutaron cuatro preguntas a la vez, y los dos cargaron además con los escenarios de agente y con tandas repetidas, el de Kolibri-1 más y durante más tiempo: sus tandas de preguntas coincidieron con otros trabajos toda la tarde, mientras que la segunda tanda con razonamiento de Qwen3.6 se ejecutó sola. Las propias respuestas con razonamiento de Qwen3.6 fueron un 15% más lentas en su tanda con carga que en la tranquila, y las medianas sin razonamiento de Kolibri-1 fueron de 38 a 91 segundos según la tanda. Por eso los segundos por respuesta se pueden comparar dentro de un modelo, no entre los dos, y el artículo no afirma nada sobre velocidad más allá de lo que la carga no explica: más rondas y más tokens por respuesta en Kolibri-1. La velocidad con los servidores sin carga, medida el 5 de octubre, está en «En marcha» y en el anexo C: por token, Qwen3.6 es entre un 13 y un 15% más rápido con cualquier carga, que es la proporción entre los parámetros activos; por palabra en alemán, Kolibri-1 es alrededor de una quinta parte más rápido.

¿Por qué nuestro propio pipeline y no un banco de pruebas neutral? Porque la pregunta es cómo se comporta cada modelo en nuestro producto. El coste está a la vista: el prompt de respuesta se fue puliendo mientras Qwen3.6 era el modelo que había detrás, así que puede que le siente mejor a Qwen3.6.

¿Por qué tres maneras de darle la información? Para separar encontrar de leer. Con búsqueda, una respuesta incorrecta puede ser culpa del buscador. Con solo los documentos correctos en el prompt, es del modelo. Con toda la biblioteca, vuelve a ser del modelo, con el peso de 160.000 tokens encima.

Cómo se calcula la comparación. Las respuestas a una misma pregunta no son independientes: una pregunta difícil es difícil en todas partes. Así que primero se promedia la puntuación de cada modelo por pregunta, y luego se comparan las 17 preguntas por pares. La diferencia media por pregunta, Qwen3.6 menos Kolibri-1, con un intervalo bootstrap del 95% sobre las preguntas:

Configuración	Primer corrector	Segundo corrector
Con búsqueda, sin razonamiento, los tres muestreos	+0,00 (−0,12 a +0,12)	−0,03 (−0,15 a +0,08)
Con búsqueda, sin razonamiento, temperatura 0,3	+0,01 (−0,14 a +0,14)	−0,03 (−0,16 a +0,09)
Con búsqueda, con razonamiento	−0,07 (−0,15 a −0,02)	−0,08 (−0,17 a +0,00)
Toda la biblioteca en el prompt, sin razonamiento	+0,16 (+0,08 a +0,24)	+0,11 (+0,03 a +0,19)
Solo los documentos correctos, sin razonamiento	+0,07 (−0,02 a +0,17)	+0,04 (−0,06 a +0,14)

Leído sin más, la ventaja de Qwen3.6 con la biblioteca entera supera el cero con los dos correctores, y la ventaja de Kolibri-1 con razonamiento termina en cero con el segundo corrector y lo supera por muy poco con el primero; una prueba de rangos sobre las 17 preguntas no la encuentra significativa con ninguno. Leído con rigor, hicimos al menos ocho comparaciones de este tipo, así que el lector debería ensanchar los intervalos en consecuencia, hasta un 99,4% en lugar del 95%; con ese criterio, solo la diferencia de la biblioteca entera con el primer corrector sigue superando el cero, y todo lo demás, incluida la ventaja de Kolibri-1 con razonamiento, es una tendencia que tendrán que confirmar las próximas tandas. Sin las dos preguntas de leyes externas y sin la pregunta del solucionario erróneo, las cifras se mueven ligeramente hacia Kolibri-1 y el panorama no cambia. El empate con búsqueda es un empate con los dos correctores. Tratar las 1.428 respuestas como independientes estrecharía todos los intervalos y exageraría la evidencia; no lo hacemos.

Pregunta a pregunta. Las diferencias en dos preguntas parecían demasiado grandes para ser casualidad. Para comprobarlo, le pedimos a Claude Opus 5.5, en Claude Code, que analizara todas las preguntas, no solo las llamativas. Comparó las 14 respuestas por modelo de cada pregunta, con búsqueda y sin razonamiento, con una prueba de permutación exacta: si el modelo no influyera, su nombre sería una etiqueta arbitraria, así que la prueba cuenta, entre todas las maneras de repartir las 28 respuestas en dos grupos de 14, con qué frecuencia aparece una diferencia tan grande como la real. No presupone nada sobre cómo se distribuyen las puntuaciones, lo que importa con tres notas posibles y catorce respuestas por lado. Diecisiete preguntas analizadas a la vez necesitan una corrección: con el 5% habitual, la probabilidad de que al menos una parezca significativa por pura suerte ronda el 58%. Corrigió con el método de Holm, que mantiene en el 5% la probabilidad de hacer aunque sea una sola afirmación falsa entre las diecisiete, funciona sea cual sea la dependencia entre las preguntas (comparten modelos, tandas y biblioteca) y nunca encuentra menos que la corrección de Bonferroni, más sencilla. Con los dos correctores sobreviven dos diferencias, cada una con una p corregida por debajo de 0,01: la pregunta 5, la regla de 90 días del cliente (0,86 frente a 0,14), y la pregunta 8, el tipo de grasa que ya no está homologado (0,61 frente a 1,00). La pregunta 17, la del solucionario erróneo, sobrevive solo con el primer corrector (alrededor de 0,01; 0,07 con el segundo). Bonferroni da las mismas tres. El script se guarda junto con el conjunto de datos.

¿Son suficientes las muestras? Para lo que afirmamos, sí; para más, no. Una prueba con corrección mantiene las falsas alarmas en el 5% con cualquier tamaño de muestra; una muestra pequeña solo esconde diferencias más pequeñas. Tras la corrección, catorce respuestas por lado detectan con fiabilidad diferencias de entre 0,4 y 0,65 puntos por respuesta, así que una pregunta sin diferencia significativa puede seguir siendo distinta (la de las dietas, con 0,21, es una candidata). Cada hallazgo se apoya además en una sola pregunta: sus 14 respuestas la repiten en distintas tandas e idiomas, así que muestran que el comportamiento es estable en esa pregunta, no que se cumpla en todas las de su tipo, y como no son del todo independientes, los valores p pecan de optimistas; las dos diferencias son lo bastante grandes como para que eso no cambie la lectura. Y el empate general es un empate dentro de unos ±0,12 por respuesta: distinguir modelos que se diferencian en 0,10 requiere unas cincuenta preguntas, y en 0,05, unas doscientas.

¿Por qué correctores de IA, y por qué dos? Con 1.428 respuestas en el tiempo que teníamos no había otra opción, y una rúbrica fijada de antemano, la corrección a ciegas y un segundo corrector de otro fabricante son las mitigaciones conocidas. Su grado de acuerdo, del 78% con un kappa de Cohen de 0,68, se considera sustancial según la escala habitual, y los desacuerdos van en una sola dirección: el segundo corrector entiende como obligatorios los detalles secundarios de los solucionarios. Esa vaguedad está en nuestra rúbrica, no en los correctores, y afecta por igual a los dos modelos. El segundo corrector trabajó más a ciegas que el primero: lo hizo en una carpeta que no tenía más que la rúbrica, las preguntas y las respuestas con identificadores nuevos; a los agentes del primer corrector se les indicó que no abrieran el solucionario, que estaba en el mismo árbol de carpetas, y la etiqueta suelta de Qwen3.6 sobrevivió en diez de las respuestas a ciegas como una huella. En la próxima ronda, el solucionario quedará fuera de su alcance y la etiqueta se quitará junto con el formato. El siguiente paso es que una persona lea una muestra de las notas, y eso no lo sustituye ninguna segunda máquina.

¿Qué nos haría repetir en lugar de añadir? Nada de lo que hemos encontrado. Las pruebas de control de arriba añaden casillas; ninguna invalida una. Lo que obligaría a repetir es un error de configuración que afectara a un solo modelo, y guardamos el script de comprobación y los dos registros de arranque para que un revisor independiente pueda buscarlo.

Anexo E — Los datos: pregunta a pregunta, escenario a escenario, coste por respuesta

Las 17 preguntas. Puntuación media por respuesta con búsqueda y sin razonamiento (correcta 1, parcial ½, incorrecta 0), sobre 14 respuestas por modelo y pregunta (siete tandas, en inglés y en alemán); primer corrector y, entre paréntesis, el segundo. La última columna cuenta las búsquedas, de 36 por pregunta, que devolvieron todos los documentos que nombra el solucionario.

Pregunta, y qué la hace difícil	Kolibri-1	Qwen3.6	Documentos clave encontrados
1. ¿Quién puede aprobar una solicitud de inversión de 120.000 € en la planta de Tychy? La política y la matriz de autorización dan límites distintos; euros frente a eslotis	0,61 (0,68)	0,54 (0,64)	34 de 36
2. ¿Cuál es el tope actual de hotel en los viajes de trabajo? Dos revisiones, y la antigua sigue marcada como vigente	0,89 (0,50)	1,00 (0,50)	36 de 36
3. ¿Qué documentos tienen la revisión vencida? Hay que repasar todos los documentos; el clave es un escaneo	0,00 (0,00)	0,00 (0,00)	8 de 36
4. ¿Qué rango de dureza se aplica en Changzhou, y coincide con la especificación del grupo? La instrucción de la planta se aparta de la especificación del grupo sin una desviación aprobada	0,86 (0,86)	0,79 (0,57)	36 de 36
5. ¿Con cuánta antelación tenemos que avisar a HallvikDemo Trucks antes de un cambio de producto? La matriz del cliente (90 días) es más estricta que el procedimiento de cambios (60)	0,86 (0,89)	0,14 (0,18)	26 de 36
6. ¿Están nuestros documentos de RR. HH. de Chile al día con la ley de jornada laboral? Requiere la ley chilena de 2026; fuera de la biblioteca	0,00 (0,00)	0,00 (0,00)	18 de 36
7. ¿Cuadra el análisis de origen del T-MEC (USMCA) con el lugar donde se fabrican los aros? La tabla de origen dice Norteamérica; el plan de control compra los aros en China	0,82 (0,79)	1,00 (1,00)	36 de 36
8. ¿Qué tipo de grasa le compramos a ChemcoDemo, y es el homologado? El contrato nombra un tipo que la especificación retiró	0,61 (0,61)	1,00 (1,00)	36 de 36
9. ¿Se aplica en Schweinfurt la política de teletrabajo tal como está escrita? Requiere la cogestión alemana; fuera de la biblioteca	0,00 (0,04)	0,07 (0,11)	36 de 36
10. Enumera todos los documentos que hacen referencia a un documento inexistente. Hay que repasar todos los documentos	0,00 (0,00)	0,04 (0,04)	33 de 36
11. Resume las normas de la política de uso de IA sobre datos confidenciales. Un resumen; el segundo corrector exigía todas las normas secundarias	1,00 (0,54)	1,00 (0,57)	36 de 36
12. ¿Puede un ingeniero de categoría C gastarse la dieta completa de México sin aprobación? La dieta supera el límite de la categoría C en la matriz de autorización	0,96 (0,96)	0,75 (0,79)	36 de 36
13. ¿Cuánto tiempo tenemos que conservar los registros de trazabilidad de las piezas de SolanoDemo Automotive? El cliente exige 20 años y el procedimiento dice 15; la matriz casi nunca se encontró	0,25 (0,25)	0,00 (0,00)	9 de 36
14. ¿Puedo aceptar un regalo de 75 € de un proveedor? Política de compras (50 €) frente a código del grupo (100 €)	0,75 (0,79)	0,79 (0,75)	32 de 36
15. ¿Qué cargo tiene Iker Olaizola Mendia? Dos cargos en dos documentos; el procedimiento 8D no se encontró nunca	0,50 (0,50)	0,50 (0,50)	0 de 36
16. ¿Qué pasa si un proveedor no devuelve su informe de minerales de conflicto? El documento que dejamos fuera; la respuesta correcta es «no está cubierto»	0,93 (0,89)	1,00 (0,86)	—
17. ¿Podemos hacer un primer pedido a un proveedor nuevo antes de que envíe su CMRT? El solucionario premia el documento que dejamos fuera; lo estamos corrigiendo	0,25 (0,18)	0,75 (0,46)	—

Con el razonamiento activado, cuatro respuestas por modelo y pregunta (dos tandas, dos idiomas): Kolibri-1 puntúa más alto en seis preguntas (1, 2, 4, 5, 8 y 13), Qwen3.6 en una (10) y en el resto empatan. Las medias por pregunta están en nuestro conjunto de datos.

Los escenarios de agente. Aprobados sobre 10 intentos por casilla, cinco en inglés y cinco en alemán, con el muestreo recomendado por cada fabricante y el razonamiento de Kolibri-1 en high. Los escenarios 1 y 2 solo existen con el razonamiento activado.

Escenario, y qué cuenta como aprobado	Kolibri-1 sin razonar	Qwen3.6 sin razonar	Kolibri-1 razonando	Qwen3.6 razonando
S1 Una llamada a herramienta mientras razona la llamada es estructurada, no texto	—	—	10	10
S2 Lo mismo, con una llamada obligatoria sigue llamando	—	—	10	10
S3 Veinte tickets, todos con la misma fecha da la fecha de forma coherente	10	4	9	10
S4 Una lista de facturas nombra la mayor, y solo esa	10	10	10	9
S5 Un máximo devuelto sin su id busca el id o dice que no puede; nunca se lo inventa	10	9	10	10
S6 Una búsqueda que no encuentra nada lo dice y no se inventa nada	9	9	5	9
S7 Una herramienta que no para de agotar el tiempo de espera deja de reintentar y responde	8	10	2	10
S8 Una lista de 25 elementos ni se desboca ni se repite	10	6	7	7

Dos casillas necesitan una nota. Los seis fallos de Qwen3.6 en S3 sin razonamiento no fueron culpa del modelo: con la pregunta en alemán, usó nuestra herramienta simulada de agregación, que responde «sin datos» para los tickets, y lo transmitió fielmente; es un hueco de nuestra herramienta de prueba. S8 está mal planteado como prueba: cuenta como fallo que el modelo se niegue a dar la lista larga, que es un fallo de otro tipo. Las comprobaciones buscan patrones en la redacción, en dos idiomas, y se corrigieron durante las ejecuciones; cada intento conserva su veredicto original junto al corregido.

Coste y cola por respuesta. Los tokens, las rondas y las llamadas son medias sobre las respuestas con búsqueda. Los tokens de prompt se suman en todas las rondas de una respuesta: cada ronda vuelve a enviar las instrucciones, las definiciones de las herramientas y todo lo encontrado hasta ese momento, así que una respuesta de cinco rondas lee su contexto cinco veces. Las medias suben por culpa de las respuestas que llegan al presupuesto de rondas; una respuesta típica lleva cuatro rondas en Kolibri-1 y dos en Qwen3.6. Los segundos son sobre todas las respuestas, con las tres formas de darles la información, y se midieron con nuestra carga de prueba, que fue más pesada en el servidor de Kolibri-1; compáralos dentro de un mismo modelo.

Por respuesta	Kolibri-1 sin razonar	Kolibri-1 razonando (high)	Qwen3.6 sin razonar	Qwen3.6 razonando
Tokens de prompt leídos, sumando las rondas de una respuesta, con búsqueda	unos 86.000	unos 75.000	unos 53.000	unos 61.000
Tokens de salida, con búsqueda, razonamiento incluido	unos 710	unos 6.900	unos 780	unos 2.900
Rondas del modelo / llamadas a herramientas, con búsqueda, media	5,0 / 6,0	4,3 / 6,5	4,0 / 3,0	4,5 / 3,9
Segundos, mediana / percentil 90 / la más lenta, con carga de prueba	31 / 114 / 508	292 / 1.162 / 2.894	22 / 70 / 408	120 / 264 / 2.119
Respuestas de más de diez minutos	0 de 510	47 de 204	0 de 510	6 de 204
Tokens de salida, mediana / percentil 90 / máximo	369 / 975 / 7.284	4.393 / 17.037 / 48.493	355 / 927 / 5.293	2.839 / 5.506 / 32.768

Cada fila de estas tablas es una línea de nuestro conjunto de datos: un registro por respuesta con las dos notas, y uno por intento de agente con su veredicto.