¿Entra Qwen3.8-27B en 16 GB de VRAM? Lo medí, y de paso descubrí que mi banco de pruebas mentía

Alibaba publicó Qwen3.8-27B el 5 de agosto bajo Apache 2.0, y los cuantizados en GGUF aparecieron el 13. Con ellos llegaron las guías de siempre, todas repitiendo la misma cifra: unos 15 GB de VRAM en 4 bits.

Mi GPU tiene 16 GB. Ninguna de esas guías respondía la única pregunta que me importaba, que es si entra o no entra en una tarjeta como la mía. Así que lo medí.

Spoiler doble: no entra, y funciona igual. Y el modelo terminó encontrando un error en mi propio banco de pruebas.

El hardware y la pregunta

Una RTX 4070 Ti SUPER de 16 GB, en un Ryzen 7 7800X3D. La tarjeta arrancó prácticamente vacía, sin procesos usando la GPU. Eso lo verifica el banco antes de empezar, y aborta si encuentra algo encima, porque una medición contaminada no es una medición.

Dos tropiezos antes de la primera métrica

El primero: mi ollama estaba en 0.20.3 y el modelo lo rechazó con un 412 y un mensaje pidiendo una versión más nueva. El manifiesto exige la 0.32.12. Actualizar y reiniciar el servicio lo resolvió.

El segundo: la descarga murió a los 4 GB con un TLS handshake timeout. Como ollama pull reanuda desde donde quedó, lo envolví en un bucle de reintentos y siguió sin perder lo bajado.

Cuando terminó, ollama list mostró el número que ya respondía media pregunta:

qwen3.8:27b    16.5 GB

Dieciséis coma cinco gigabytes. La tarjeta tiene dieciséis. La cifra de “unos 15 GB” que repite la cobertura corresponde a los parámetros en 4 bits y nada más; el archivo real trae además el encoder de visión, y aparte hay que hacerle sitio a la caché del contexto.

Lo que ollama show dice del modelo:

Cómo medí

Siete repeticiones por configuración, con una corrida de calentamiento descartada para no contar la carga de pesos como si fuera inferencia. temperature=0 y seed fija, para que lo que varíe sea el sistema y no el muestreo. VRAM muestreada cada 100 ms en un hilo aparte, reportando el pico menos la línea base. Y el reparto CPU/GPU que informa ollama, porque sin ese dato un tokens/s no se puede comparar con nada.

Los números

contexto 4 096contexto 16 384contexto 32 768

GPU75% de las capas

CPU25% de las capas

tokens/s

28.86

VRAM pico

14 438 MiB

primer token

199 ms

El mejor caso. Aun así una cuarta parte del modelo vive fuera de la tarjeta, y sigue dando más tokens por segundo de los que alcanzo a leer.

GPU71% de las capas

CPU29% de las capas

tokens/s

26.55

VRAM pico

14 576 MiB

primer token

209 ms

Cuadruplicar el contexto empuja un 4% más de capas a la CPU y cuesta 2.3 tokens por segundo. La caché de claves y valores también ocupa, y compite con los pesos.

GPU66% de las capas

CPU34% de las capas

tokens/s

23.70

VRAM pico

14 724 MiB

primer token

225 ms

Un tercio del modelo en CPU. Multiplicar el contexto por ocho cuesta un 18% de velocidad, y la tendencia no se estabiliza: sigue inclinándose.

Tres cosas que saltan a la vista.

La respuesta a la pregunta del título es no, pero con matiz. El modelo nunca carga entero: incluso en el contexto más pequeño, una cuarta parte se queda en CPU. Y aun así da 28.86 tokens por segundo, que para leer en pantalla es más rápido de lo que uno lee.

El castigo del contexto es progresivo y predecible. Cada salto empuja más capas fuera de la tarjeta, el reparto se inclina hacia la CPU y el rendimiento baja: de 25% a 29% a 34% de CPU, y de 28.9 a 26.6 a 23.7 tokens por segundo. Multiplicar el contexto por ocho cuesta un 18% de velocidad.

La VRAM nunca llega al tope. El pico se queda en 14 724 MiB de 16 376. ollama deja margen a propósito en vez de apurar la tarjeta hasta el borde y arriesgar un fallo de memoria.

Las 21 respuestas salieron idénticas entre sí, así que el determinismo con seed fija se sostiene.

Sobre la desviación conviene una advertencia. Entre las siete repeticiones de una misma corrida va de 0.03 a 0.06 tokens por segundo, un número que invita a confiarse. Pero corrí el banco entero dos veces, y el contexto de 16 384 dio 25.17 la primera vez y 26.55 la segunda: un 5% de diferencia, muy por encima de esa desviación interna. Repetir dentro de una sesión mide el ruido de esa sesión, no la reproducibilidad real. Los números de la tabla valen como orden de magnitud y como comparación relativa entre contextos, no como cifras exactas al segundo decimal.

El modelo me corrigió a mí

Aquí viene la parte que no esperaba.

Mi banco compara la respuesta contra un resultado verificable guardado de antemano. Las 21 corridas dieron distancia_km=240 horas=4 y el banco las marcó todas como incorrectas, porque mi archivo decía que la respuesta buena era distancia_km=204 horas=3.4.

Antes de escribir que el modelo falla en aritmética elemental, hice la cuenta a mano.

El problema: un tren sale de A hacia B a 60 km/h; dos horas después otro sale de B hacia A a 90 km/h; entre A y B hay 420 km.

Cuando arranca el segundo, el primero lleva 120 km recorridos y quedan 300 km entre ellos. Se acercan a 150 km/h, así que se cruzan 2 horas más tarde: 4 horas desde la salida del primero, a 60 × 4 = 240 km de A. Comprobación: 240 + 90 × 2 = 420 km exactos.

Con mi respuesta guardada, 204 km y 3.4 horas, los trenes estarían a 90 km de separación. Nunca se cruzan ahí.

El modelo tenía razón las 21 veces. El que estaba equivocado era mi banco de pruebas.

Y todavía peor: ese valor falso no vivía solo en el comparador, estaba escrito dentro del archivo del prompt, en una línea que decía “(Respuesta verificable: …)”. O sea que se le enviaba al modelo junto con el enunciado. Le estaba filtrando una respuesta equivocada y aun así contestó la correcta, contradiciendo el dato que el propio prompt le daba.

Arreglé las dos cosas. El enunciado y la respuesta ahora viven en archivos separados, y el banco aborta si detecta la respuesta esperada dentro del prompt, para que esta contaminación no pueda repetirse en silencio. Con el input corregido, el resultado es 7 de 7 correctas.

Publico el error porque es la parte más útil del artículo. Un banco de pruebas que da un veredicto equivocado con una desviación de 0.03 se ve exactamente igual de riguroso que uno correcto. La precisión de la medición no dice nada sobre si estás midiendo lo que crees.

Mi opinión

Para la pregunta práctica de si sirve en una tarjeta de 16 GB, la respuesta es que sí, con la advertencia de que no es una carga limpia en VRAM y de que el contexto se paga en velocidad. Si tu caso de uso vive en contextos cortos, casi treinta tokens por segundo con un modelo de 27B y capacidad de visión en una tarjeta de consumo es un buen trato.

Lo que me molesta es la cifra que circula. “Unos 15 GB en 4 bits” no es exactamente falsa, pero describe un modelo que no existe como archivo descargable: ignora el encoder de visión y la caché del contexto. La cifra útil es la del archivo real, que son 16,5 GB, y esa nadie la publica porque implica bajarlo.

Cuándo lo usaría

• Con contexto de 4096 y tareas cortas: ahí rinde y el derrame a CPU se nota poco.
• No lo pondría a procesar documentos largos en esta tarjeta. A 32 768 ya hay un tercio del modelo en CPU y la tendencia solo empeora.
• Si vas a comprar hardware para este modelo en concreto, 24 GB lo cargan entero y evitan todo el reparto.

---

Los datos crudos de las tres configuraciones, con las respuestas literales de cada repetición: qwen38-bench.json.

Fuentes

• Qwen3.8-27B. La ficha del modelo original, publicada el 5 de agosto de 2026, de donde salen la licencia Apache 2.0 y la arquitectura con encoder de visión.
• Qwen3.8-27B-GGUF, de Unsloth. Los cuantizados que medí, subidos el 13 de agosto. El tamaño de 16,5 GB es el del archivo Q4_K_M de ese repositorio, no una estimación.
• Longitud de contexto, en la documentación de Ollama. La variable OLLAMA_CONTEXT_LENGTH y por qué ampliarla cuesta memoria además de los pesos.