Lo que aprendí midiendo 25 modelos de IA en local con dos GPU

Parte 1 de 3. Aquí van los números: qué modelo corre rápido en una máquina de andar por casa y por qué. En la segunda parte están los siete errores que cometí midiendo, y en la tercera, la configuración final por si quieres replicarla.

Casi todo lo que se escribe sobre modelos de IA en local repite la misma frase: la VRAM es lo único que importa; si el modelo no cabe, te desplomas. Monté un servidor con dos tarjetas gráficas de 16 GB, medí 25 modelos en las mismas ocho tareas y resulta que con dos tarjetas esa frase se queda corta y, en algún caso, es directamente falsa.

Esto no va de descubrir nada nuevo: el principio que explica los resultados está publicado desde hace meses. Va de tener números propios de una máquina concreta, en español, con documentos españoles reales, y de contar también las tres cosas que yo daba por seguras y que los datos tumbaron.

---

Cinco conceptos en dos minutos

Si ya te manejas con esto, sáltate el apartado. Si no, con estos cinco términos se entiende todo lo demás.

Token. Los modelos no leen palabras, leen trozos de palabra. Un token viene a ser unas tres cuartas partes de una palabra en español. Cuando digo que un modelo va a 100 tok/s (tokens por segundo), quiere decir que escribe unas 75 palabras por segundo: bastante más rápido de lo que tú puedes leer.

VRAM. Es la memoria de la tarjeta gráfica, distinta de la RAM del ordenador. El modelo tiene que caber ahí dentro. Si no cabe, se desborda a la memoria normal y la velocidad se hunde entre cinco y veinte veces.

De ahí que todas las guías estén obsesionadas con los GB de la tarjeta. Mi máquina tiene dos tarjetas de 16 GB, o sea 32 GB en total, pero repartidos en dos sitios, que como veremos no es lo mismo que tenerlos juntos.

Parámetros. Son los números que el modelo aprendió durante el entrenamiento; es lo que ocupa sitio. Cuando lees «un modelo de 30B» significa 30.000 millones de parámetros. Más parámetros suele ser más listo, y desde luego es más grande.

Denso frente a MoE. Un modelo denso usa todos sus parámetros para cada token que escribe. Un modelo MoE (mixture of experts, mezcla de expertos) tiene los parámetros repartidos en grupos especializados y solo enciende unos pocos cada vez.

Piensa en una consultoría con treinta especialistas en plantilla. Todos ocupan su mesa y cobran su nómina —es decir, todos tienen que caber en la oficina—, pero para cada consulta concreta solo se levantan tres de la silla. La oficina la dimensionas por los treinta; la velocidad de respuesta te la dan los tres.

Por eso en los nombres de los MoE verás cosas como 30B-A3B: 30B es la plantilla entera y A3B son los que trabajan en cada token (la A es de activos). Un A1B levanta a mil millones de parámetros por token; un A3B, a tres mil millones. Ese número, como veremos, es el que manda.

Cuantización. Es comprimir el modelo, y funciona muy parecido a guardar una foto en JPEG en vez de en RAW. Cada parámetro es un número con decimales; al cuantizar lo redondeas para que ocupe menos bits.

Es la diferencia entre anotar 3,14159265 y anotar 3,14. Ocupa menos, se calcula más rápido, y casi siempre da igual… hasta que deja de darlo.

Verás etiquetas como q8, q6, q4 o q4_K_M: el número son los bits que se usan por parámetro. q8 es redondeo fino (el modelo pesa la mitad que el original y apenas se nota). q4 es redondeo bruto (pesa la cuarta parte, va más rápido y empieza a perder matices). Las letras de detrás son variantes del método de redondeo; para lo que nos ocupa, ignóralas.

La regla mental: más bits, más fiel y más lento y más grande; menos bits, más rápido y más pequeño pero con más riesgo de meter la pata en los detalles.

La máquina y el método para medir modelos de IA en local

Una workstation reacondicionada con dos RTX 5060 Ti de 16 GB, 64 GB de RAM y un Xeon de seis núcleos. Ubuntu Server y Ollama, que es el programa que descarga y ejecuta los modelos en tu propio ordenador. Nada exótico y nada caro: es la configuración típica de quien prefiere dos tarjetas de gama media a una sola grande.

El detalle que hace que los números sean comparables entre sí:

• Un banco de pruebas propio, en Python sin dependencias, con las mismas ocho tareas para todos los modelos.
• Las velocidades salen de la propia API de Ollama, que informa de cuántos tokens generó y en cuánto tiempo. No son cronometrajes a ojo ni estimaciones.
• La calidad se juzgó a ciegas: el script guarda las respuestas bajo un alias y solo al terminar de puntuarlas se revela qué modelo escribió cada una. Así no puntúas alto al que esperabas que ganara.
• Prompts en español, documentos españoles reales y un texto de 18.000 tokens (unas 50 páginas) para medir de forma realista la espera inicial: lo que tarda el modelo en leerse lo que le mandas antes de empezar a responder.

Ocho tareas: código, uso de herramientas, redacción en español, resumen de un documento largo, extracción de datos a JSON, lectura de una factura, lectura de un manuscrito y razonamiento.

El resultado que no esperaba que fuera tan limpio

Ordené los 21 modelos de las dos primeras rondas por velocidad de generación:

Ni un solo cruce. El MoE más lento del banco (75 tok/s) va más rápido que el denso más rápido (73 tok/s). No hay zona de solape, no hay excepciones, no hay «depende».

Y aquí está lo que le da la vuelta al consejo habitual. Cuando un modelo no cabe en una tarjeta, se parte en dos y cada mitad vive en una; las tarjetas tienen entonces que hablar entre ellas por el bus de la placa, que es mucho más lento que su memoria interna. Ese peaje era justo lo que yo temía al montar dos tarjetas en vez de una grande.

Pues bien: casi todos los MoE de la lista estaban partidos entre las dos tarjetas, y varios de los densos cabían enteros en una sola. Aun así ganan los partidos, y por goleada. El peaje del reparto no compensa ni de lejos la ventaja de la arquitectura.

Si estás decidiendo qué comprar, la traducción es directa: tu criterio no es cuánta VRAM sumas, es qué arquitectura vas a correr. Sumar VRAM con dos tarjetas te compensa de verdad si el modelo es MoE.

La regla que puedes aplicar leyendo el nombre del modelo

Recordando lo de la consultoría: la VRAM la fija la plantilla entera, la velocidad la fijan los que se levantan de la silla. Estos son mis números:

Triplicar lo activo (de 1B a 3B) reduce la velocidad a menos de la mitad. Subir a 4B baja otro 26 %. No es una proporción exacta —hay un coste fijo que se paga siempre—, pero el orden de magnitud lo fija el activo.

Lo práctico: con mirar el nombre puedes estimar a qué velocidad va a ir un modelo antes de descargar 20 GB.

Y un corolario que me sorprendió: un modelo de 24B con solo 2B activos, en q8 (redondeo fino), corre a 127 tok/s. Más rápido que ocho de los nueve modelos A3B que iban en q4 (redondeo bruto). Es decir: triplicar los parámetros y duplicar los bits sale más barato que subir de 2B a 3B activos.

Con el activo fijo, el tamaño total sale casi gratis

Esta es la parte contraintuitiva. Cogí los nueve modelos que tienen exactamente los mismos parámetros activos (A3B) y los ordené por tamaño total, a ver cuánto penalizaba ser más grande:

No hay tendencia. El más pequeño es el más lento y el de 33B es el más rápido. Las diferencias entre modelos del mismo tamaño son mayores que las diferencias entre tamaños: lo que varía es cómo está hecho cada modelo, no cuántos parámetros tiene.

Conclusión práctica, y va contra el instinto de todos: con MoE, elige el más grande que quepa en tu VRAM. Los parámetros que no se activan casi no se pagan.

Tres cosas que daba por ciertas y resultaron falsas

Esta es la parte que no suele publicarse, y probablemente la más útil.

1. «Cuantiza un denso grande para que quepa»

La idea era tentadora: coger un modelo denso grande, comprimirlo a lo bruto y meterlo con calzador. Probé uno de 27B a 3 bits. Pesa 15 GB en disco, pero al ejecutarse ocupa 18, así que se parte igual entre las dos tarjetas y encima va con la calidad recortada.

Fue el modelo más lento del banco: 25 tok/s y casi 14 segundos de espera con el documento largo. Es un solo modelo, así que no lo convierto en ley; pero de las veces que lo he probado, machacar a bits un denso grande para que entre no me ha compensado ninguna. Si necesitas ese tamaño, busca un MoE.

2. «Para leer documentos, usa un modelo especializado en OCR»

El OCR es el reconocimiento de texto en imágenes, y hay modelos hechos solo para eso. Probé tres. Los tres fueron los únicos del banco que devolvieron una respuesta vacía.

Los generalistas hicieron el trabajo sin quejarse. Para una factura impresa, un modelo generalista de 6,6 GB acertó los cuatro datos clave.

Un aviso sobre este hallazgo, que escribí antes de aprender por las malas lo que cuento en la segunda parte: «no devolvió nada» es un síntoma con varias causas, y no todas son del modelo. Uno de esos tres se gastó el presupuesto de tokens razonando y dejó el texto en un campo que mi script no leía. Y a un modelo de visión al que le falta su fichero de proyección arranca perfectamente y está ciego, sin avisar. Así que lo que puedo afirmar es más modesto: los tres especialistas no me dieron nada utilizable con el mismo montaje con el que los generalistas sí lo dieron. No que sean peores.

3. «La cuantización estropea el español»

Lo deduje en la primera ronda: un modelo en q4 escribía «costo» (americanismo) y el mismo modelo en q8 escribía «coste». Parecía cerrado y tenía sentido: menos bits, menos matiz.

En la tercera ronda monté el experimento controlado —mismo modelo, mismos activos, cambiando solo los bits— y salió lo contrario: escribe «costo» tanto en q4 como en q8. Con dos parejas controladas dando resultados opuestos, lo que predice el registro no son los bits, es el modelo.

El matiz que sí se sostiene: los bits compran fidelidad literal, no idiomatismo. Esa misma pareja falló y acertó, respectivamente, al extraer los datos del emisor de una factura. Más bits ayudan a copiar un dato exacto; no enseñan a escribir en español de España.

El español, casi nadie escribe bien

De los 15 modelos de la primera ronda, solo cuatro escriben «coste» en vez de «costo». En la segunda, dos de once. Y ninguno redacta un correo publicable sin repasarlo: aparecen calcos del inglés («espero que este mensaje le encuentre bien»), fórmulas de relleno y algún error de conjugación.

Es el único criterio que no puedes delegar en los benchmarks publicados, porque están en inglés y este sencillamente no existe. Si escribes en castellano, tienes que probarlo tú. Es la misma idea de la que hablaba en pensar antes de pedirle algo a una IA: el resultado depende de cómo plantees el encargo y de que alguien lo revise después.

Documentos, las facturas sí y los manuscritos no

Sobre una factura notarial real, 9 de 13 modelos acertaron los cuatro identificadores (el CIF del emisor, el NIF del cliente, el número de factura y la fecha). No hace falta un modelo grande para esto.

Pero el modo de fallo cuando fallan es el peligroso: no se equivocan en el texto corrido, se equivocan en un carácter de un identificador. Un CIF B12345678 transcrito como 812345678, con la B inicial leída como un 8. Se lee bien, parece correcto y es basura.

Si automatizas la extracción de facturas, valida el dígito de control del NIF/CIF antes de dar nada por bueno. Es una línea de código y te ahorra un disgusto.

Con manuscritos la cosa cambia de categoría. Pasé un acta de defunción manuscrita por cuatro modelos y obtuve cuatro documentos distintos. Ni un solo campo manuscrito coincide:

Los nombres y lugares de la tabla están alterados respecto al documento original, que es un acta real del Registro Civil con datos de personas identificables. Lo que se conserva intacto es lo que importa: qué modelo coincidió con cuál y en qué parte de cada palabra empezaron a separarse.

Porque lo revelador es el patrón: coinciden en los comienzos de palabra y divergen en los finales. Los tres leen «Villanueva del…» y a partir de ahí se separan en Sauce, Salce y un galimatías. Los tres leen «Pedro» y se bifurcan en el apellido, y dos de ellos aún coinciden en las dos primeras letras. Están reconociendo los primeros trazos de verdad y rellenando el resto por verosimilitud.

En los modelos que muestran su razonamiento se les lee adivinando, literalmente: «Let’s see: the image shows FOLIO… 118. So FOLIO 118.»

Y probé si más precisión lo arreglaba, subiendo el mismo modelo de q4 a q6. No: cambia qué se inventa, no que se lo invente. Peor aún, la versión de más bits no muestra su razonamiento, entrega un texto más limpio y añade fórmulas jurídicas plausibles pero falsas. Parece más fiable siendo igual de inventada.

El peligro no es que fallen. Es que «Villanueva del Sauce, 1924, ante el juez Anselmo» es perfectamente creíble. Sin el original delante se acepta sin pestañear. Para genealogía o investigación histórica es el peor resultado posible: peor que no responder.

Con qué me he quedado

De los 25 probados, ocho se quedan en disco con un papel asignado:

No hay un modelo. Hay una plantilla, y cada uno hace lo suyo. Es la misma lógica de qué tareas merece la pena automatizar: la herramienta se elige por el encargo, no al revés.

Este reparto es el de agosto de 2026, y ya no es el que tengo. Al montar un banco de pruebas que midiera comportamiento agéntico y no solo respuestas sueltas, el titular cambió y el catálogo se quedó en cinco modelos: lo cuento en la segunda parte, y la configuración final está en la tercera.

Lo que me llevo

Tres reglas que caben en un tuit y me habrían ahorrado semanas:

1. Manda cuántos parámetros activa el modelo, no cuántos tiene.
2. Con los activos fijos, el tamaño total sale casi gratis: elige el MoE más grande que quepa.
3. Los bits compran fidelidad literal, no idiomatismo.

Y una cuarta que no es sobre modelos: medir sale más barato de lo que parece. El banco de pruebas son 200 líneas de Python sin dependencias, y me ha librado de tres decisiones que habría tomado mal fiándome de la intuición.

Aunque esa frase tiene letra pequeña, y me costó bastante más caro descubrirla. Va en la segunda parte de este artículo: medir mal sale igual de barato, y un experimento defectuoso no te avisa con un error, te aprueba con un número redondo.

---

Anexo, los datos completos

Las tablas de la primera ronda, con arquitectura y métricas de los 15 modelos. La columna «Tarjetas» indica en cuántas se reparte el modelo: 1 es que cabe entero en una, 0+1 es que va partido entre las dos.

Y las puntuaciones normalizadas de 0 a 10 en seis dimensiones, con la media ponderada. El español y la visión se puntuaron a ciegas; el resto sale de las mediciones.

Y el ranking por uso, que es lo que de verdad usé para decidir. La media general engaña: un modelo puede ser el mejor del banco y no servirte para lo que tú haces.

---

Las cifras son de una máquina concreta con dos RTX 5060 Ti de 16 GB; las diferencias de uno o dos tok/s entre tablas son variación normal entre rondas de medición, no precisión perdida. Los modelos y sus versiones se mueven rápido: estos números son de agosto de 2026.