Qwen3.8-27B: cuánta VRAM necesitas y cómo llegar a 262K

Para una RTX 5090, empieza por elegir la cuantización y el contexto que necesitas; el número de parámetros no basta para calcular la VRAM. Los pesos originales de Qwen3.8-27B en BF16 suman aproximadamente 51,75 GiB, según el índice oficial de tensores. No caben íntegramente en una sola tarjeta de 32 GB. Una versión GGUF de unos 15,33 GiB deja bastante más espacio, pero ese espacio también debe albergar la caché de la conversación y las reservas del motor de inferencia.

El modelo admite de forma nativa 262.144 tokens, contando entrada y salida. Ese límite describe el modelo, no la capacidad de cualquier GPU. La ficha oficial de Qwen3.8-27B lo presenta como un modelo denso con capacidades visuales; procesar imágenes introduce costes adicionales que no deben confundirse con los de una conversación de texto.

Las cifras siguientes, comprobadas el 6 de septiembre de 2026, son tamaños de archivos, cálculos derivados de la configuración y resultados publicados por sus respectivos autores. No son mediciones propias de rendimiento en GPU.

Calcula primero lo que queda después de cargar los pesos

La RTX 5090 de sobremesa tiene 32 GB de GDDR7 y no dispone de NVLink, según NVIDIA. Para dimensionar el proceso, consulta la memoria que expone realmente el controlador y la que está libre:

bash
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv

Haz la consulta antes de arrancar el servidor y durante la carga de trabajo. La GPU que mueve el escritorio puede tener menos memoria disponible. No conviertas automáticamente la etiqueta comercial «32 GB» en una cantidad libre exacta en GiB: usa la cifra del controlador y sus unidades.

En esta guía, 1 GB son 1.000.000.000 bytes y 1 GiB son 1.073.741.824 bytes. La diferencia explica parte de las discrepancias entre las páginas de descarga y las herramientas de memoria.

Los valores FP8 corresponden al checkpoint oficial Qwen3.8-27B-FP8. Los GGUF proceden de una revisión concreta del repositorio de Unsloth. Conserva el nombre exacto de la variante y su revisión cuando compares resultados: un UD-Q4_K_M de este repositorio no es intercambiable sin más con cualquier archivo llamado Q4_K_M.

El tamaño de descarga sirve para empezar el cálculo, pero no equivale al pico de VRAM. La representación cargada, las partes no cuantizadas y las reservas del motor pueden cambiar el consumo. Por eso FP8 tampoco significa que el archivo tenga exactamente la mitad de tamaño que BF16.

Para una estimación útil, separa estos términos:

text
VRAM máxima aproximada = pesos residentes en GPU
                       + caché KV de atención completa
                       + estados de atención lineal
                       + activaciones y reservas del motor
                       + costes opcionales de visión y MTP

La guía de SGLang para este modelo detalla, por ejemplo, reservas de estado GDN de 153,9 MB por ranura en FP32 o 78,4 MB en BF16. El número de ranuras y los estados intermedios dependen de la configuración. Que una parte del estado no crezca como la caché KV convencional no significa que ocupe cero.

El contexto puede consumir más que la diferencia entre dos cuantizaciones

Qwen3.8-27B combina 48 capas de atención lineal y 16 de atención completa. Estas últimas tienen cuatro cabezas KV y dimensión de cabeza 256, según su configuración oficial. Aplicar una fórmula convencional de caché a las 64 capas daría una estimación incorrecta.

Para una secuencia, la parte de atención completa en F16 o BF16 necesita:

text
2 × 16 × 4 × 256 × 2 bytes = 65.536 bytes por token = 64 KiB por token
│    │    │    │    └─ bytes de cada valor
│    │    │    └────── dimensión de cabeza
│    │    └─────────── cabezas KV
│    └──────────────── capas de atención completa
└───────────────────── claves y valores

A partir de esa cuenta se obtiene la siguiente memoria de datos KV. La tabla no incluye pesos ni las demás reservas.

FP8 y q8_0 no son el mismo formato. Los bloques de llama.cpp almacenan 34 bytes por cada 32 valores en q8_0 y 18 bytes en q4_0. De ahí que sus tamaños sean algo superiores a los de una cuenta ideal de ocho o cuatro bits por valor. Las cifras suponen que tanto K como V usan la precisión indicada.

Cuantizar los pesos y cuantizar la caché son dos decisiones distintas. Un modelo Q4 puede mantener la caché en F16; cambiar el archivo no reduce automáticamente la memoria de la conversación. Tampoco hay una garantía general de que bajar la precisión KV conserve la calidad de todas las tareas. Comprueba especialmente la recuperación de información y el seguimiento de instrucciones con documentos largos.

La concurrencia también importa: dos conversaciones que almacenan 131.072 tokens cada una requieren, en conjunto, una cantidad de datos KV comparable a una de 262.144, salvo reutilización efectiva de prefijos u otros mecanismos del motor. Ajusta el cálculo al número de secuencias activas, no solo al máximo de una petición.

Una RTX 5090: qué probar antes de pedir 262K

Con UD-Q4_K_M como referencia, la suma de archivo y caché a 262.144 tokens queda así:

El primer caso deja un margen insuficiente para una ejecución ordinaria en una 5090. Los otros dos son candidatos para probar, no demostraciones de que el contexto completo vaya a funcionar. El margen real depende de lo que cargue tu versión del programa y de la fase más exigente de la petición.

Para comenzar con GGUF, descarga la variante elegida, identifica el archivo local y usa una versión de llama-server compatible con el modelo. El siguiente ejemplo adapta las opciones documentadas de llama.cpp; no es una ejecución medida en este hardware. MODELO debe apuntar a tu archivo real:

bash
MODELO="/ruta/al/modelo.gguf"

llama-server \
  --model "$MODELO" \
  --n-gpu-layers 99 \
  --ctx-size 32768 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --host 127.0.0.1 \
  --port 8080

Comprueba antes llama-server --version y llama-server --help: la compatibilidad del modelo, de la caché cuantizada y de las opciones corresponde a la versión instalada. --n-gpu-layers 99 solicita cargar en la GPU todas las capas posibles de este modelo; verifica en el registro cuáles se han cargado realmente. Aquí se fija una sola secuencia para que el presupuesto de contexto sea inequívoco.

Cuando la carga y la generación funcionen, sube --ctx-size a 65536, después a 131072 y finalmente a 262144, repitiendo la prueba con entradas de longitud creciente. Subir solo la cifra del argumento no ejercita el contexto completo. Si necesitas liberar memoria, reduce primero el contexto a lo que exige tu tarea; después compara una cuantización distinta o una caché menos precisa manteniendo el resto de condiciones.

Si prefieres vLLM y NVFP4

NVFP4 no es una opción que convierta un GGUF al arrancar. Necesita un checkpoint y una implementación compatibles. La receta de vLLM para Qwen3.8-27B publica una configuración de una RTX 5090 con Inferact NVFP4 que combina:

• Paralelismo tensorial 1.
• max-model-len de 32768.
• Caché KV fp8.
• enforce-eager activado.
• Analizador de razonamiento qwen3.

En ese entorno, la receta informa de un error de memoria durante la captura de grafos si no se activa enforce-eager. Es una condición útil para reproducir aquel caso, no una obligación universal de todo motor NVFP4. La versión de las pruebas publicadas es 0.26.1rc1.dev608+g99a10304d; conserva también el checkpoint exacto del ejemplo. Un requisito mínimo de versión no identifica por sí solo la compilación con la que se obtuvo el resultado.

Esa configuración ofrece un punto de partida a 32.768 tokens. No permite concluir que bastará con sustituir el límite por 262144.

Dos GPU: comprueba el reparto, además de la suma

Añadir otra tarjeta puede resolver el presupuesto, pero el programa tiene que repartir los pesos, la caché y el trabajo. Dos GPU no forman automáticamente una única memoria utilizable, y su velocidad no se duplica por sumar sus capacidades. En dos RTX 5090, la comunicación entre tarjetas tampoco cuenta con NVLink.

Las cuentas agregadas permiten descartar algunas opciones antes de configurarlas:

• BF16 más caché F16 a 262.144 tokens: aproximadamente 67,75 GiB, antes de las reservas. Excede dos tarjetas de 32 GB.
• GGUF Q8_0 más caché F16 al mismo contexto: aproximadamente 43,052 GiB. La suma puede resultar razonable para dos 5090, pero necesita comprobar reparto y picos.
• Ese Q8_0 en dos tarjetas de 24 GB: 43,052 GiB no demuestra que funcione. El margen global es más estrecho y una tarjeta puede agotarse antes que la otra.

Con llama.cpp, una configuración inicial de dos GPU para texto podría mantener el contexto en 32.768 y distribuir las capas:

bash
MODELO="/ruta/al/modelo.gguf"

CUDA_VISIBLE_DEVICES=0,1 llama-server \
  --model "$MODELO" \
  --n-gpu-layers 99 \
  --split-mode layer \
  --tensor-split 1,1 \
  --ctx-size 32768 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --host 127.0.0.1 \
  --port 8080

Es un ejemplo de configuración, sujeto a la compatibilidad de tu versión. El modo layer de llama.cpp reparte capas y caché KV; en modo row, la GPU principal conserva los resultados intermedios y la caché. Esa diferencia puede explicar que una tarjeta se llene mientras la otra parece tener espacio.

--tensor-split 1,1 expresa proporciones iguales, no una promesa de consumo idéntico. Con tarjetas de distinta capacidad o una GPU ocupada por el escritorio, empieza con una proporción acorde a la memoria libre y corrígela observando cada dispositivo. No uses únicamente el total combinado de nvidia-smi.

En vLLM, la receta citada publica pruebas con paralelismo tensorial de dos vías en dos RTX 5090:

Son datos del entorno de los autores. La última columna describe la capacidad del conjunto de caché reservado: no es la longitud máxima del modelo, una medición de velocidad ni una prueba de generación a contexto completo. Tampoco demuestra que los tres checkpoints tengan la misma calidad.

Qué acredita el caso publicado de 262K en una sola 5090

El repositorio de MiaAI-Lab sobre Qwen3.8-27B NVFP4 en RTX 5090 documenta un caso de una sola tarjeta con límite de 262144. Las condiciones son bastante más específicas que «usar cuatro bits»:

El resultado sirve de referencia para reproducir esa combinación. No debe trasladarse a FP8, a q4_0 de llama.cpp ni a otra versión de vLLM como si fueran equivalentes. El propio repositorio advierte de posibles salidas corruptas con la configuración estándar y de fallos al combinar MTP y concurrencia.

MTP intenta anticipar varios tokens y añade estados y trabajo; no lo actives como si fuera una mejora gratuita cuando aún estás intentando que el modelo quepa. Para una primera instalación, resulta más fácil diagnosticar una configuración sencilla a menor contexto y añadir optimizaciones después. Si buscas reproducir específicamente el caso de MiaAI-Lab, conserva sus versiones, cambios y ajustes como un conjunto y revisa los scripts antes de ejecutarlos.

También conviene leer el alcance de las pruebas de otros motores. Las configuraciones de GPU de consumo de SGLang se validaron con 8.192 tokens de entrada, 1.024 de salida y concurrencia uno. Una mención al máximo nativo en la documentación no convierte todas esas pruebas en ensayos de 262K.

Cómo comprobar que el contexto largo funciona de verdad

«El servidor arranca», «hay capacidad KV» y «la petición termina con una respuesta útil» son comprobaciones diferentes. Para aceptar tu configuración, usa este recorrido:

1. Registra el entorno. Guarda GPU, memoria libre, versión del controlador, motor, revisión de pesos, precisión KV y argumentos de arranque. Anota el reparto de capas o el paralelismo tensorial.
2. Cuenta tokens con el tokenizador adecuado. A 262.144 tokens totales, reservar 8.192 para la respuesta deja como máximo 253.952 para toda la entrada, incluidos mensajes e instrucciones que añada la plantilla. Contar caracteres o palabras no basta.
3. Comprueba que no se recorta la entrada. Revisa tanto el cliente como el servidor. Una petición aceptada después de truncar el documento no demuestra capacidad para el documento original.
4. Observa cada GPU durante la lectura inicial y la generación. La fase de procesar la entrada, también llamada prefill, puede tener un pico distinto de la generación token a token. Conserva el error concreto si falla.
5. Introduce comprobaciones al principio, en medio y al final. Por ejemplo, coloca tres identificadores con valores distintos en un documento de prueba y pide recuperar los tres, además de resolver la tarea real. Que el texto final parezca coherente no prueba que haya usado todo el documento.
6. Compara la calidad antes de aceptar una caché más comprimida. Usa las mismas preguntas y materiales con una configuración de mayor precisión que puedas ejecutar. Si la cuantización evita el error de memoria pero degrada la extracción que necesitas, no has completado el objetivo.

Los nombres «262K» y «256K» pueden referirse aquí al mismo límite: 262.144 = 256 × 1.024 tokens. Para reproducir una prueba, conserva el número exacto y la reserva de salida.

Si falta memoria, cambia el ajuste que corresponde al fallo

Dejar parte de los pesos en RAM puede hacer viable una carga que no cabe íntegra en VRAM, pero cambia el rendimiento y exige memoria del sistema suficiente. No interpretes un arranque con descarga parcial a CPU como prueba de que todos los pesos caben en la GPU.

Si vas a usar imágenes, añade el proyector compatible: en el GGUF de Unsloth citado, mmproj-F16.gguf ocupa aproximadamente 0,864 GiB. Ese archivo no representa todo el pico de procesamiento visual. Repite la validación con las imágenes reales y no extrapoles el margen de una prueba solo de texto.

Para empezar con una 5090, una variante de pesos moderada, una secuencia y 32.768 tokens permiten comprobar el funcionamiento y medir el margen antes de ampliar contexto. Para dos GPU, resuelve primero el reparto. Si ni la precisión ni el contexto que exige tu tarea encajan en el equipo, la siguiente decisión es comparar Qwen3.8-27B con Qwen3.8-Flash y Next, en lugar de seguir reduciendo una configuración hasta que deje de servirte.