¿Entra Qwen3.8-27B en 16 GB de VRAM? Lo medí, y de paso descubrí que mi banco de pruebas mentía
Todos repiten que el nuevo modelo de Alibaba necesita unos 15 GB en 4 bits. Mi GPU tiene 16 y el archivo pesa 17. Medí tokens por segundo, VRAM real y reparto CPU/GPU en tres contextos, y el modelo terminó corrigiéndome a mí.
Alibaba publicó Qwen3.8-27B el 13 de agosto bajo Apache 2.0. En cuestión de horas aparecieron 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ó vacía: 15 954 MiB libres y cero 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ó, apareció el número que ya respondía media pregunta:
qwen3.8:27b 17 GB
Diecisiete 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:
| Arquitectura | qwen35 |
| Parámetros | 27.3B |
| Cuantización | Q4_K_M |
| Contexto | 262 144 |
| Capacidades | texto, visión, herramientas, razonamiento |
| Proyector | clip, 460.73M |
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 | tokens/s (p50) | Desviación | VRAM pico | Reparto | TTFT |
|---|---|---|---|---|---|
| 4 096 | 28.86 | 0.06 | 14 438 MiB | 25% CPU / 75% GPU | 199 ms |
| 16 384 | 26.55 | 0.03 | 14 576 MiB | 29% CPU / 71% GPU | 209 ms |
| 32 768 | 23.70 | 0.05 | 14 724 MiB | 34% CPU / 66% GPU | 225 ms |
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, cien veces mayor que la 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 330 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 17 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.
Comentarios
Todavía no hay comentarios. El primero es tuyo.