Banco ITLab 02.5: 10 modelos de IA en 49 casos reales

Ocho modelos de IA local y dos de pago resolvieron la misma batería de trabajo real. Un modelo local, corriendo en una sola tarjeta gráfica de consumo, encabeza el total; el mejor de pago queda segundo, a dos puntos del primero.

• Empate técnico arriba. Swift Flash Next IQ3_S suma 94,6 puntos; lo siguen Claude Haiku 5.5 (92,6), Qwen 3.8 Flash Next SC117 IQ2_XS (92,5) y Swift SC117 IQ3_XXS (89,1). Entre el primero y el cuarto hay 5,5 puntos, y el segundo y el tercero están a 0,1: con una sola pasada por caso, esas diferencias no separan a nadie.
• El mejor en trabajo de oficina es local. Swift 27B IQ3_S aprobó más comprobaciones que nadie en análisis y trabajo de oficina (49 de 54; 90,7), una más que Claude Haiku 5.5 y Qwen 3.8 Flash Next SC117 IQ3_XXS.
• Pagar no garantiza el orden. Los dos modelos de pago quedaron segundo y noveno. Lo que más separa a los modelos es el proyecto de software en Rust y Rails: cinco modelos lo resuelven completo y cinco no.

Qué es el Banco ITLab

El Banco ITLab es el test propio con que ITLab evalúa modelos de IA en tareas reales de oficina, desarrollo y análisis. Este artículo usa el Banco ITLab, versión 02.5, la versión vigente del instrumento: un solo test que se sigue perfeccionando y que es la referencia para medir cada modelo nuevo. Los resultados de estudios anteriores, como la comparación Swift 27B frente a dos Flash Next, corresponden a una etapa previa de pruebas y no se mezclan con estas cifras.

Se midieron 10 modelos en 49 casos cada uno, con una sola corrida final por modelo y caso. Los ocho modelos locales corrieron en una sola tarjeta gráfica de consumo de 16 GiB, en versiones cuantizadas (comprimidas) para caber en su memoria, con temperatura 1,0 y razonamiento en nivel medio. Los dos de pago, Claude Haiku 5.5 y GPT-6 Luna, se consultaron con los parámetros nativos de cada proveedor.

Por qué importa: un modelo local procesa contratos, planillas o código sin que los datos salgan de la organización. La pregunta que responde este banco es cuánto se pierde, o no se pierde, al trabajar así con hardware al alcance de una empresa chilena mediana.

Los casos se agrupan en seis series que suman al total:

• N, análisis y trabajo de oficina (35 %): 10 ejercicios con tres casos cada uno (a, b y c) y uno con un solo caso; 31 casos en total.
• C, programación (20 %): 3 ejercicios en Rust con pruebas automáticas.
• M, proyecto de software (20 %): 2 proyectos que unen Rust y Rails.
• A, agéntica (10 %): 1 ejercicio con herramientas simuladas, en tres episodios.
• Visión (10 %): 1 prueba de 31 preguntas sobre imágenes y 1 ejercicio de boletas fotografiadas, con tres casos.
• L, lectura (5 %): 1 ejercicio de lectura de tablas.

Otros tres ejercicios (N13, N14 y M08) se ejecutan y se informan aparte, pero no suman al total porque solo comprueban una parte de la tarea. GPT-OSS 20B no admite imágenes, así que no participa en la serie Visión: no recibe un cero, sino que su total se calcula sobre las otras cinco series.

Cómo se puntúa

En las series C, M, A, Visión y L, el puntaje se arma de abajo hacia arriba con los pesos de los autores del test, en cuatro niveles: comprobación, caso, ejercicio y serie. En cada nivel, lo que importa más en el trabajo real pesa más. La serie N es la excepción: en ella todas las comprobaciones valen lo mismo (punto 6).

1. Comprobaciones. Cada caso se revisa con varias comprobaciones automáticas (¿el total está bien sumado?, ¿cita la fuente?, ¿pasa el test?). Cada comprobación tiene un peso dentro del ejercicio, fijado según lo que mide y el daño que causaría ese error en una oficina de verdad. Además lleva una etiqueta: crítica, importante o normal.
2. Fallas críticas. Si falla una comprobación crítica, el caso vale 0, aunque todo lo demás esté bien. Ejemplos de críticas: inventar un mes que no existe en los datos, contar dos veces la misma boleta, dejar pasar una inyección de código o dar una afirmación legal falsa.
3. Puertas de formato. Algunas comprobaciones solo verifican que la respuesta se pueda usar: que se pueda leer, que tenga la estructura pedida o que el código compile. Estas puertas no suman puntos, pero si una falla, todo lo que depende de ella vale 0.
4. Comprobaciones no ejecutadas. Si un error del modelo impide correr una comprobación (por ejemplo, el código no compila y los tests no llegan a ejecutarse), esa comprobación vale 0: es consecuencia del error, no una omisión del evaluador.
5. Casos y ejercicios. El puntaje de un ejercicio es el promedio de sus casos a, b y c.
6. La serie N, por comprobaciones aprobadas. En N, todas las comprobaciones valen lo mismo: el puntaje es el número de comprobaciones aprobadas dividido por 54, por 100. No hay pesos por ejercicio ni por comprobación, ni crédito parcial, y una falla crítica no anula el caso. Un ejercicio con más comprobaciones pesa más simplemente porque tiene más. Las puertas de formato no suman, y las comprobaciones no ejecutadas o indeterminadas cuentan en el total como no aprobadas.
7. Ejercicios dentro de la serie. En las series C, M y Visión, cada ejercicio tiene el peso que fijaron los autores (las tablas de cada serie, más abajo, lo muestran); A y L tienen un solo ejercicio.
8. Series en el total. Las series pesan N 35 %, C 20 %, M 20 %, A 10 %, Visión 10 % y L 5 %, según el trabajo que más importa a ITLab.

Tres ejercicios usan crédito parcial por comprobaciones, sin umbral de aprobación: la lectura (L01), la prueba de 31 preguntas de visión (V01) y la agéntica (A01). En ellos, cada comprobación aporta su parte aunque otras fallen.

Un ejemplo mínimo en N. Si un ejercicio de oficina tiene 4 comprobaciones y el modelo aprueba 3, esas 3 aprobadas y las 4 comprobaciones se suman a las del resto de la serie; el puntaje de N es el total de aprobadas sobre las 54 comprobaciones de la serie.

Transparencia. Los autores del test fijaron los pesos conociendo ya los resultados de esta medición. Para que eso no sea un cheque en blanco, cada peso se justifica por lo que mide la comprobación y por el costo de su error, y publicamos también el ranking con todos los pesos iguales (columna «Pesos iguales» del ranking total). Los pesos quedan registrados en un archivo cuya huella digital SHA256 empieza por `e0669dcfc517`¹; cualquier cambio en los pesos cambia esa huella.

Los pesos de las series son una decisión de ITLab, no una verdad universal. Una organización que use IA sobre todo para leer documentos o para programar puede reponderar y obtendrá otro orden.

Ranking total

Los cuatro primeros están separados por 5,5 puntos, y el segundo y el tercero por 0,1: con una pasada por caso, es un empate técnico. Los cuatro empatan en programación, proyecto de software, visión y lectura; los separan la serie de oficina y la agéntica, donde Claude Haiku 5.5 y Swift SC117 IQ3_XXS quedan en 72,3 y 76,0, frente a 99,3 de los mejores. Entre el cuarto y el quinto hay 3,2 puntos, y los marca el proyecto de software, aunque Swift 27B IQ3_S recupera parte con su ventaja en oficina: ninguno de los modelos del quinto lugar hacia abajo, salvo GPT-6 Luna, lo resolvió completo.

Con pesos iguales los mismos cuatro modelos quedan arriba, y el primero, el tercero, el quinto, el séptimo, el noveno y el décimo se mantienen. Claude Haiku 5.5 baja del segundo al cuarto y Swift SC117 IQ3_XXS sube del cuarto al segundo; Gemma 26B sube del octavo al sexto, porque con pesos iguales sus muchos aciertos parciales en el proyecto de calculadora valen más, y Qwen 3.8 Flash Next SC117 IQ3_XXS baja del sexto al octavo.

Algunos nombres se parecen y no son el mismo modelo. Las variantes Flash Next se distinguen por su cuantización, que figura en el nombre; Swift 27B IQ3_S es un modelo distinto de Swift Flash Next IQ3_S.

Resultados por serie

Cada serie tiene su tabla, ordenada de mejor a peor; los modelos con el mismo puntaje comparten puesto. «Comprobaciones aprobadas» cuenta las comprobaciones de fondo aprobadas por completo en la serie, sin contar las puertas de formato; en N es, además, la base del puntaje. Con una sola pasada por caso, diferencias de uno o dos puntos son ruido.

N: análisis y trabajo de oficina (35 % del total)

Mide si el modelo resuelve tareas de oficina con material real y responde solo con lo que dice el material. Es la serie más cercana al trabajo diario de una empresa: ofimática, negocio, atención al cliente, apoyo legal, mantención de sistemas y una pequeña aplicación. En N, todas las comprobaciones valen lo mismo: el puntaje es el porcentaje de las 54 comprobaciones aprobadas, y un ejercicio con más comprobaciones pesa más simplemente porque tiene más.

La columna «Fallas críticas» cuenta los casos en que falló una comprobación etiquetada como crítica por los autores del test; es informativa y no cambia el puntaje de N.

Swift 27B IQ3_S lidera con una comprobación más que Claude Haiku 5.5 y Qwen 3.8 Flash Next SC117 IQ3_XXS, y dos más que Swift Flash Next IQ3_S: los cuatro quedan dentro de 3,7 puntos, un margen que una sola pasada no permite ordenar con confianza. Del quinto al último hay seis comprobaciones de diferencia; Gemma 26B queda último, con 38 de 54.

C: programación (20 % del total)

Mide si el código que escribe el modelo pasa pruebas automáticas que el modelo no ve, en Rust. Sirve para elegir un modelo de apoyo a la programación, incluida la programación segura.

Siete modelos resuelven los tres ejercicios sin errores. GPT-6 Luna, uno de los dos de pago, queda último en esta serie.

M: proyecto de software (20 % del total)

Mide si el modelo sostiene un proyecto completo con dos lenguajes, Rust y Rails, cuyas piezas deben integrarse y pasar pruebas. Sirve para elegir un modelo para proyectos de varias piezas, no solo funciones sueltas.

Es la serie que más separa a los modelos. Todos resuelven el motor de cuotas (M09); la diferencia está en la calculadora (M10). Gemma 26B cumple casi todo el motor de la calculadora, pero no llega a la consola Rails ni a las pruebas de extremo a extremo; los cuatro últimos no obtienen ninguna comprobación en ella.

A: agéntica (10 % del total)

Mide si el modelo usa herramientas en el orden correcto y completa la tarea a lo largo de tres episodios: diagnosticar un incidente, calcular un total con varias fuentes y desplegar cumpliendo una política. Sirve para elegir un modelo que opere herramientas por su cuenta. Es un solo ejercicio (A01), con crédito parcial: en cada episodio, el resultado entregado pesa 70, la economía de pasos 15 y el protocolo (turnos bien formados) 15.

Cuatro modelos quedan en 99,3, el máximo alcanzado: ninguno llegó a 100 porque todos usaron más pasos de los necesarios en el primer episodio (el óptimo son cuatro), y el proceso tiene crédito parcial. Las comprobaciones aprobadas no siguen el mismo orden que el puntaje, porque no todas pesan igual: el resultado entregado vale 70 y el proceso y el protocolo 15 cada uno, con crédito parcial. Por eso GPT-OSS 20B, con 4 de 9 aprobadas por completo, queda en 90,7, y Claude Haiku 5.5, con 7 de 9, en 72,3: falló una de las comprobaciones de mayor peso. Con un solo ejercicio y una pasada, conviene leerlo como tendencia, no como veredicto.

Visión (10 % del total)

Mide la lectura de imágenes y de documentos fotografiados. Sirve para elegir un modelo que lea boletas, fotos de documentos, gráficos o pantallas.

Fallas críticas: casos de la serie anulados por una falla crítica. GPT-OSS 20B no participa.

Siete modelos empatan: aciertan las 31 preguntas sobre imágenes y fallan la lectura de documentos en el mismo caso de boletas. GPT-6 Luna y Gemma 26B fallan además otras comprobaciones y bajan unos 20 puntos. GPT-OSS 20B no admite imágenes: no tiene puntaje de visión, no se le penaliza y su total se calcula sobre las otras cinco series.

L: lectura (5 % del total)

Mide si el modelo extrae con exactitud los datos de un conjunto de tablas y responde preguntas sobre ellos. Sirve para elegir un modelo que lea informes, listados u organigramas. Es un solo ejercicio (L01), con crédito parcial: los datos extraídos pesan 60 y las respuestas, 40.

Siete modelos aciertan todo. Los tres restantes fallan entre una y tres comprobaciones, todas preguntas, que pesan más que una celda suelta. Esta serie distingue poco entre modelos, y por eso es la que menos pesa.

Informativos: N13, N14 y M08

Estos tres ejercicios se ejecutan y se puntúan con las mismas reglas, pero no suman a su serie ni al total, porque solo comprueban una parte de la tarea. N13 mide traducción al español de Chile conservando cifras, registro y ambigüedades; N14, reescribir un mensaje a un cliente en tono formal sin cambiar hechos, montos ni grado de certeza; M08, una interfaz web de administración, de la que solo se mide que respete las reglas de seguridad del encargo y se integre al repositorio.

Se ordenan del que mejor resuelve los tres al que peor, según el promedio de los tres; si hay empate, va primero el que los resolvió más rápido. El tiempo es la suma de la inferencia de los siete casos (tres de N13, tres de N14 y M08).

Qué modelo para qué trabajo

• Uso general equilibrado: Swift Flash Next IQ3_S, primero en el total, con nota máxima en programación, proyecto de software y lectura, y de los mejores en agéntica y visión. Claude Haiku 5.5, Qwen 3.8 Flash Next SC117 IQ2_XS y Swift SC117 IQ3_XXS quedan en empate técnico con él.
• Oficina y análisis (N): Swift 27B IQ3_S, con la mayor cantidad de comprobaciones aprobadas, aunque Claude Haiku 5.5, Qwen 3.8 Flash Next SC117 IQ3_XXS y Swift Flash Next IQ3_S están a una o dos comprobaciones. Ojo: no resolvió la calculadora del proyecto de software, así que no es la mejor opción si también se necesita programar proyectos de varias piezas.
• Programación en Rust (C): siete modelos sin errores; cualquiera de ellos sirve.
• Proyectos de varias piezas, Rust y Rails (M): los cinco que lo resolvieron completo: tres locales (Swift Flash Next IQ3_S, Qwen 3.8 Flash Next SC117 IQ2_XS y Swift SC117 IQ3_XXS) y los dos de pago.
• Agéntica (A): cuatro modelos llegan a 99,3 y tres quedan entre 72,3 y 76,0; al ser un solo ejercicio, la diferencia entre ellos no es concluyente.
• Visión y lectura: siete modelos empatan arriba en cada una; son series de pocos ejercicios y no definen la elección por sí solas.
• Mantención de sistemas: hoy la cubren N07 (un solo caso), N08 y en parte A01. No alcanza para recomendar un modelo; está previsto un ejercicio dedicado.

Patrones de fallo

Los errores se repiten en modelos locales y de pago:

• Formato de salida. Respuestas con estructura de datos rota o con tipos distintos de los pedidos, que una integración automática no puede usar.
• Cifras. Totales mensuales con pequeñas desviaciones, filas duplicadas mal resueltas o meses inexistentes agregados.
• Lectura insegura ante la ambigüedad. Frente a un requisito contradictorio, varios modelos eligieron la interpretación que permitía un estado inválido en lugar de impedirlo.
• Clasificación de hallazgos de seguridad. La falla más común fue dar por real o por falso positivo un hallazgo cuya evidencia era insuficiente.
• Actas y trazabilidad. Acuerdos que no estaban en la transcripción y marcas de audio inaudible o cortado que no se informaron.
• Folios fotografiados. Números de documento leídos con dígitos de más o de menos.

Velocidad, tiempos y tokens

Estas tablas usan las pasadas finales de los 49 casos de cada modelo, es decir, las que sostienen el puntaje. Cuando un caso se repitió, cuenta solo la pasada final válida. El tiempo es el de inferencia (lo que el modelo tarda en responder), sin carga ni evaluación; en el caso agéntico es la suma por turnos. GPT-OSS 20B suma 45 casos porque no admite imágenes y no ejecutó los cuatro casos de visión.

Tokens generados

Un token es la unidad de texto con que el modelo trabaja, en promedio algo menos de una palabra. Los tokens de salida son todo lo que el modelo escribe al responder; en los modelos que razonan, normalmente incluyen también el razonamiento que hace antes de contestar. Más tokens significa más texto o más razonamiento, y no una mejor respuesta. En un modelo local son tiempo y energía; en un servicio de pago, costo. La tabla va de quien más generó a quien menos.

Los tokens siguen la contabilidad de cada motor o proveedor y no comparan trabajo entre tokenizadores. En los servicios de pago, esa contabilidad puede no incluir todo el razonamiento interno, por lo que sus cifras no son equivalentes a las de los modelos locales.

Tiempos de respuesta

La tabla va del más rápido al más lento por tiempo total.

Los tiempos de los servicios de pago incluyen la red y la cola del proveedor, de modo que no son comparables con los de los modelos locales, que corrieron en una sola tarjeta gráfica de consumo. Se publican porque el tiempo total de una batería también es un dato práctico para quien elige.

Velocidad de lectura y de generación (modelos locales)

La tabla va del modelo que más rápido lee al que más lento lee.

Son velocidades consolidadas: se suman los contadores del motor en todas las pasadas finales (tokens procesados o generados sobre el tiempo correspondiente), sin promediar promedios. La lectura es la velocidad al procesar el enunciado y la generación, la velocidad al escribir la respuesta. Los servicios de pago (Claude Haiku 5.5 y GPT-6 Luna) no entregan estos contadores, por lo que no figuran en esta tabla; sus tiempos y tokens están en las dos tablas anteriores.

Más velocidad no implica mejores respuestas: el modelo más rápido en generación, GPT-OSS 20B, queda último en el total.

Qué recomienda ITLab

Esto es criterio profesional de ITLab a partir de su propia medición; no es una certificación ni una recomendación de compra.

1. Elegir por tipo de trabajo, no por puesto. Para análisis con cifras, fuentes y políticas, Swift 27B IQ3_S fue el más sólido; para proyectos de software de varias piezas, conviene un modelo del grupo que resolvió completo el proyecto en Rust y Rails.
2. Considerar en serio lo local. El primero, el tercero y el cuarto son modelos locales, en una sola tarjeta gráfica de consumo y sin que los datos salgan de la organización; el mejor de pago, segundo, queda en empate técnico con ellos.
3. No asumir que pagar asegura calidad. Los dos servicios de pago medidos quedaron segundo y noveno.
4. Validar siempre el formato antes de usar datos estructurados generados por un modelo.
5. Mantener revisión humana en cifras, normativa, seguridad y textos con compromisos hacia clientes.
6. Probar con casos propios y, si su uso es distinto del nuestro, reponderar las series antes de decidir.

Limitaciones y alcance

• Una sola pasada por modelo y caso. Diferencias de uno o dos casos pueden ser ruido; no hay significancia estadística ni ganador universal.
• Pesos fijados con conocimiento de los resultados. En C, M, A, Visión y L, los autores del test definieron los pesos después de ver esta medición. Por eso cada peso se justifica por lo que mide y se publica el ranking con pesos iguales, que deja el mismo grupo arriba.
• Pesos de las series definidos por ITLab. El total depende de cuánto vale cada serie; la mezcla de unidades entre series hace inevitable esa decisión.
• Pocas comprobaciones de fondo en la serie N. Varios ejercicios de oficina se deciden con una o dos comprobaciones por caso; afinarlas es una mejora pendiente del banco.
• Revisión humana pendiente en N10 y N13. Sus resultados provienen solo de la verificación automática.
• Series de un solo ejercicio. Lectura y agéntica dependen de un ejercicio cada una, así que sus puntajes saltan más.
• Tope de memoria. Los modelos locales corrieron en versiones comprimidas para caber en una tarjeta de 16 GiB; ese tope condiciona qué versión de cada modelo se puede medir.
• Razonamiento. Los modos de razonamiento no son equivalentes entre familias de modelos y no se comparan entre sí.
• Pago frente a local. Tiempos y tokens de los servicios de pago no son comparables con los locales, y no se certifica qué pesos hay detrás del nombre de un servicio de pago.

Preguntas frecuentes

¿Puede un modelo local reemplazar a uno de pago? En buena parte, sí. En esta medición el primer puesto es local y el tercero queda a 0,1 punto del mejor de pago, y el mejor modelo en trabajo de oficina también fue local. Igual recomendamos revisión humana y pruebas con casos propios.

¿Cómo se pesan las comprobaciones y los ejercicios? En la serie N, todas las comprobaciones valen lo mismo: el puntaje es el porcentaje de comprobaciones aprobadas. En las demás series, cada comprobación tiene un peso dentro del ejercicio según lo que mide y el daño que causaría su error, y si falla una crítica, el caso vale 0; además, cada ejercicio tiene el peso fijado por los autores, y cada serie tiene un peso en el total. El tiempo que tarda un modelo no influye en el puntaje.

¿Los pesos deciden el ranking? No. Con todos los pesos iguales, los cuatro primeros siguen siendo los mismos cuatro modelos; cambian de lugar Claude Haiku 5.5 y Swift SC117 IQ3_XXS (segundo y cuarto) y Gemma 26B y Qwen 3.8 Flash Next SC117 IQ3_XXS (sexto y octavo).

¿Por qué GPT-OSS 20B no tiene puntaje de visión? Porque no admite imágenes. No se le penaliza: su total se calcula sobre las otras cinco series.

¿Puedo usar otros pesos para las series? Sí. Los pesos responden a las necesidades de ITLab; una organización con otro uso puede reponderar y obtener un orden distinto.

¿Qué pasará con los modelos nuevos? Se evaluarán con el Banco ITLab, versión 02.5, y con los mismos pesos, para que sus resultados sean comparables con los de este artículo.

Contacto

Si su organización evalúa adoptar IA local con recursos acotados, ITLab puede ayudarle a elegir el modelo según su tipo de trabajo y a diseñar pruebas con sus casos reales. Contáctenos.

¹ SHA256 del archivo de pesos: `e0669dcfc5172b8b8526ab8f3e6f264686ca79c7d5bbcff44f85fec38dddd92a`.

El Banco ITLab es un instrumento vivo, en perfeccionamiento continuo. Las conclusiones expresan el criterio de ITLab a partir de sus propias mediciones.