12 de noviembre de 2026 · Equipo de VRAMfarm
Llama 70B en una sola GPU: 4 bits o FP8, 48 GB u 80 GB y velocidades reales
El primer intento suele ser así: una tarjeta de 24 GB, ollama run llama3.3:70b y una respuesta que sale a rastras, a dos o tres tokens por segundo. No hay nada roto. El modelo en 4 bits ocupa 43 GB, así que Ollama ha metido sin avisar casi la mitad en la RAM del sistema. Una sola tarjeta ejecuta un modelo de 70B a velocidad de lectura solo cuando el modelo entero cabe: una tarjeta de 48 GB para una persona con un contexto normal (unos 12–18 tokens por segundo), o una de 80 GB para documentos largos, varios usuarios o calidad FP8 (25–50 tokens por segundo).
Todo lo que sigue usa Llama 3.3 70B, y las cifras valen para otros modelos densos de 70B basados en él, como DeepSeek R1 Distill Llama 70B. Un modelo de 72B como Qwen2.5 72B ocupa unos gigas más (unos 47 GB en Q4_K_M), lo que deja casi sin sitio para la caché en una tarjeta de 48 GB.
Primero, elige el formato
Cada motor tiene su propio formato de archivo, y el formato decide el tamaño y, con él, la tarjeta.
| Formato | Tamaño de un modelo de 70B | Funciona en | Tarjetas | Calidad frente al original |
|---|---|---|---|---|
| BF16 (original) | 141 GB | vLLM, Transformers | Una B200 sola, o 2 × 80 GB | La referencia |
| FP8 | ~71 GB | vLLM, SGLang | 80–96 GB: H100, RTX PRO 6000, H200 | Prácticamente igual |
| GGUF Q8_0 | ~75 GB | llama.cpp, Ollama | 80–96 GB | Prácticamente igual |
| GGUF Q5_K_M | ~50 GB | llama.cpp, Ollama | 80 GB (demasiado grande para 48 GB con cualquier caché) | Muy cerca |
| GGUF Q4_K_M | ~43 GB | llama.cpp, Ollama | 48 GB | Pequeña pérdida |
| AWQ o GPTQ, 4 bits | ~40 GB | vLLM, SGLang | 48 GB | Pequeña pérdida |
| GGUF Q2/IQ2 | 21–26 GB | llama.cpp | 24–32 GB | Claramente peor |
GGUF es el formato de llama.cpp, y Ollama también lo usa. Un solo archivo contiene los pesos, y el motor puede dejar algunas capas en la CPU si la GPU se queda sin memoria, lo cual es a la vez su punto fuerte y la trampa del primer párrafo. Q4_K_M es la opción habitual para un 70B.
AWQ y GPTQ son formatos de 4 bits para servidores con GPU. vLLM ejecuta los dos con kernels rápidos en cualquier tarjeta desde la generación Ampere, lo que cubre todo nuestro catálogo. Su calidad es parecida; elige una versión de una fuente mantenida y con muchas descargas.
FP8 reduce el original a la mitad casi sin pérdida. Las tarjetas lo calculan de forma nativa desde la generación Ada (serie RTX 40, L40S), y también en Hopper (H100, H200) y Blackwell (serie RTX 50, RTX PRO 6000, B200). Un modelo de 70B en FP8 necesita unos 71 GB, así que en la práctica FP8 significa una H100 de 80 GB, una RTX PRO 6000 de 96 GB o una H200. La A100 puede cargar pesos FP8 en vLLM, pero calcula en 16 bits, así que ahorra memoria sin ganar velocidad. Las tarjetas Blackwell también calculan NVFP4, un formato de 4 bits de unos 40 GB que, en las comparativas publicadas, suele quedar más cerca de la calidad de FP8 que los métodos de 4 bits más antiguos; su soporte en los motores es más reciente, así que comprueba que tu versión de vLLM lo incluye.
48 GB u 80 GB: decide el contexto
Los pesos son solo una parte de la cuenta. Llama 3.3 70B guarda unos 0,33 MB de caché KV por token en 16 bits, así que 8000 tokens de conversación ocupan 2,7 GB y el contexto completo de 128 000 tokens ocupa 43 GB, tanto como los pesos en 4 bits. La guía de VRAM explica la fórmula; esto es lo que significa en cada tarjeta.
| Configuración | Pesos | Lo que queda para la caché | Contexto, caché de 16 bits | Contexto, caché de 8 bits |
|---|---|---|---|---|
| Tarjeta de 48 GB, GGUF Q4_K_M | ~43 GB | 3–4 GB | 8000–12 000 tokens | 16 000–24 000 |
| Tarjeta de 48 GB, AWQ en vLLM | ~40 GB | 3–5 GB | 8000–12 000 | 16 000–24 000 |
| 2 tarjetas de 24 GB, AWQ o Q4 | ~40–43 GB | 3–5 GB | 8000–12 000 | 16 000–24 000 |
| Tarjeta de 80 GB, AWQ o Q4 | ~40–43 GB | 30–35 GB | unos 100 000 en total | los 128 000 completos para un usuario, o muchas conversaciones más cortas |
| Tarjeta de 80 GB, FP8 | ~71 GB | 4–8 GB | 12 000–25 000 | 25 000–50 000 |
| RTX PRO 6000 de 96 GB, FP8 | ~71 GB | ~20 GB | ~60 000 | unos 120 000 |
| H200 de 141 GB, FP8 | ~71 GB | ~60 GB | 128 000 y varios usuarios | muchísimo margen |
Son rangos porque las tarjetas varían en uno o dos gigas de memoria utilizable, cada motor reserva sus propios búferes y vLLM solo usa la parte de la tarjeta que fija --gpu-memory-utilization. Lo de «en total» importa al servir: la caché se reparte entre todos los que hablan con el modelo a la vez, así que 100 000 tokens en una tarjeta de 80 GB son un documento largo o una docena de conversaciones de 8000 tokens.
La regla práctica: una tarjeta de 48 GB como la L40S o la RTX A6000 basta para una persona que chatea o resume unas cuantas páginas. Coge una tarjeta de 80 GB cuando pegues documentos largos, sirvas a un equipo o quieras FP8. Dos tarjetas de 24 GB en una misma máquina también pueden con un 70B en 4 bits. Compara dos RTX 3090 a 0,60 € la hora con una RTX A6000 a 0,72 €; las máquinas con varias tarjetas aparecen por separado en el catálogo.
Ollama o llama.cpp: un usuario, el mínimo de pasos
Ollama es el camino más corto. En un servidor vacío de PyTorch, abre el terminal de Jupyter o conéctate por SSH:
curl -fsSL https://ollama.com/install.sh | sh
OLLAMA_CONTEXT_LENGTH=8192 OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve > /workspace/ollama.log 2>&1 &
ollama run llama3.3:70bLa etiqueta por defecto llama3.3:70b es el Q4_K_M de 43 GB. Fijar la longitud del contexto a propósito es importante: si el contexto que pides no cabe, Ollama no falla, sino que pasa capas a la CPU. Compruébalo con ollama ps en un segundo terminal. La columna PROCESSOR tiene que decir 100% GPU; algo como 20%/80% CPU/GPU significa que la velocidad acaba de caer entre cinco y diez veces, y la solución es un contexto más corto o una tarjeta más grande. Con la caché de 8 bits de arriba, 16 000 tokens de contexto también caben en una tarjeta de 48 GB.
llama.cpp te da más control: archivos de cuantización exactos, tipos de caché, cómo se reparten las capas entre dos tarjetas. Primero hay que compilarlo con CUDA; la comparativa de motores tiene los pasos. Después:
pip install -U huggingface_hub
hf download bartowski/Llama-3.3-70B-Instruct-GGUF Llama-3.3-70B-Instruct-Q4_K_M.gguf --local-dir /workspace/models
./build/bin/llama-server -m /workspace/models/Llama-3.3-70B-Instruct-Q4_K_M.gguf \
-ngl 99 -c 16384 --flash-attn on -ctk q8_0 -ctv q8_0 \
--host 127.0.0.1 --port 8081-ngl 99 pone todas las capas en la GPU. En nuestros servidores, el puerto 8080 lo ocupa Jupyter, así que usa otro y ábrelo a través de un túnel SSH: ssh -p <port> -L 8081:localhost:8081 root@<address>, con el puerto y la dirección que aparecen en Mis servidores, y luego entra en http://localhost:8081 para usar la página de chat que trae llama.cpp. La guía de la clave SSH explica la clave. Con dos tarjetas, llama.cpp reparte las capas entre ellas por sí solo.
vLLM: una API para varios usuarios
vLLM es la opción cuando te envían peticiones otros programas u otras personas, porque las agrupa y su rendimiento total crece con el número de peticiones en paralelo. Nuestro servidor vLLM ya trae vLLM instalado y el puerto 8000 publicado. Arranca solo un modelo pequeño, Qwen 7B, así que detenlo primero y luego arranca el 70B:
pkill -f "vllm serve"
# tarjeta de 48 GB: AWQ de 4 bits, contexto corto
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
--max-model-len 8192 --gpu-memory-utilization 0.95 --max-num-seqs 8 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &# H100 de 80 GB: FP8, calidad casi igual al original
vllm serve RedHatAI/Llama-3.3-70B-Instruct-FP8-dynamic \
--max-model-len 16384 --gpu-memory-utilization 0.95 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &# dos tarjetas de 24 GB en una máquina: cada capa repartida entre las dos
vllm serve casperhansen/llama-3.3-70b-instruct-awq \
--tensor-parallel-size 2 --max-model-len 8192 --gpu-memory-utilization 0.95 \
--host 0.0.0.0 --port 8000 --api-key change-me > /workspace/vllm.log 2>&1 &La carga lleva varios minutos después de la descarga; tail -f /workspace/vllm.log muestra el progreso. Al arrancar, vLLM comprueba que cabe al menos una petición de --max-model-len y, si no cabe, se niega a arrancar con un mensaje que indica el contexto más grande que cabría. Baja la cifra o añade --kv-cache-dtype fp8, que duplica el espacio en tarjetas Ada, Hopper y Blackwell. La versión FP8 en una H100 es el caso justo: sus pesos ocupan unos 72 GB, así que los 16 000 tokens de arriba necesitan el ajuste de 0,95, y los contextos más largos, la caché fp8 o una tarjeta más grande. No quites --api-key: la dirección de la API funciona desde cualquier sitio, y sin clave cualquiera que la encuentre puede usar tu GPU. Nuestro servidor vLLM fija una versión de vLLM que encaja con el driver de CUDA de las máquinas; si instalas una más reciente en un servidor vacío, comprueba antes la versión de CUDA que se muestra antes de lanzar.
Qué velocidad: tokens por segundo según la tarjeta
Para un usuario, cada token nuevo significa leer el modelo entero de la memoria una vez, así que la velocidad es más o menos el ancho de banda de memoria dividido entre el tamaño del modelo, menos la sobrecarga. Son tokens de salida para una sola conversación, calculados a partir del ancho de banda y de informes públicos de la comunidad, no de pruebas nuestras:
| Tarjeta | VRAM | Ancho de banda | 4 bits (Q4_K_M, AWQ) | FP8 |
|---|---|---|---|---|
| RTX A6000 | 48 GB | 768 GB/s | 12–16 tokens/s | no cabe |
| L40S | 48 GB | 864 GB/s | 13–18 | no cabe |
| 2 × RTX 3090 | 2 × 24 GB | 936 GB/s cada una | 14–18 (reparto por capas), 18–25 (vLLM, tensor parallel) | no cabe |
| RTX PRO 6000 | 96 GB | 1792 GB/s | 25–35 | 15–22 |
| A100 80 GB | 80 GB | 2039 GB/s | 25–35 | sin ganancia de velocidad, usa 4 bits |
| H100 | 80 GB | 3350 GB/s | 35–50 | 25–38 |
| H200 | 141 GB | 4800 GB/s | 45–65 | 35–55 |
Una persona lee a unos 5–8 tokens por segundo, así que hasta la fila más lenta resulta fluida en un chat. En la práctica importan otras dos cifras. Leer el prompt es mucho más rápido que escribir la respuesta, de cientos a unos pocos miles de tokens por segundo según la tarjeta, así que un documento de 10 páginas tarda entre unos segundos y medio minuto antes de la primera palabra. Y con muchas peticiones en paralelo, la salida total de vLLM llega a varios cientos o a más de mil tokens por segundo en una H100. El artículo sobre el coste por millón de tokens convierte esas velocidades en lote a euros.
Lo que cuesta una primera tarde y cuándo basta un modelo más pequeño
Lo primero es la descarga: unos 40–43 GB para una versión en 4 bits y unos 72 GB para FP8. Se factura como tráfico con la tarifa por GB de la máquina que se muestra antes de lanzar, más los minutos que tarde, desde menos de diez en una conexión rápida hasta media hora en una más lenta. Dos horas con Ollama en una L40S cuestan 2,12 € de tiempo de GPU; dos horas de FP8 en una H100, 7,80 €. Los precios van en vivo, y el precio por minuto queda fijado al lanzar.
Si vas a volver a menudo, puedes conservar el modelo en la carpeta guardada: 43 GB cuestan 43 × 0,03 € al mes. Restaurarla en el siguiente servidor también es tráfico, así que compáralo con volver a descargarlo sin más; el artículo sobre los archivos tras detener un servidor hace las dos cuentas.
Antes de decidirte por un 70B, prueba un modelo de 32B en una tarjeta de 24 GB. Qwen3 32B en 4 bits cabe en una RTX 4090 a 0,59 € la hora, responde más o menos el doble de rápido y, para mucho chat y redacción del día a día, la diferencia con un 70B es pequeña. Pasa los mismos cinco prompts reales por los dos en una misma sesión; el 70B se gana su tarjeta más grande cuando el 32B se equivoca con tus datos o con tus instrucciones. La página del modelo Llama muestra la memoria de cada tamaño.