Calculadora de VRAM

La velocidad es una estimación limitada por el ancho de banda para la decodificación de flujo único, no un benchmark. El procesamiento de prompts está limitado por cómputo y se comporta de manera diferente.

Cómo leer el desglose de tres partes

Casi cualquier discusión en internet sobre "si cabrá" es en realidad una discusión sobre cuál de los tres números alguien olvidó. El tamaño de descarga en la tarjeta del modelo es uno de ellos. Los otros dos solo existen una vez que el modelo está cargado y respondiendo, que es exactamente cuando quedarse sin memoria duele.

Tomemos Llama 3.1 8B en Q4_K_M con un contexto de 8K, una solicitud a la vez, cache F16. Esa es la configuración local más común que existe, y aquí está cada byte de ella:

weights  = 8.03e9 params x 4.85 bits / 8      = 4.87e9 bytes = 4.53 GB
kv       = 2 x 32 layers x 8 kv-heads x 128 dim
           x 8192 tokens x 2 bytes             = 1.07e9 bytes = 1.00 GB
overhead = 0.65 + 0.08 x (4.53 + 1.00)                        = 1.09 GB
                                                                -------
total                                                            6.63 GB

Los pesos son la única parte que puede consultar. Son aritmética pura: recuento de parámetros multiplicado por bits por peso, dividido por ocho. Nada en su carga de trabajo los cambia. Si nunca tocara los otros dos números, concluiría que un modelo de 8B a 4 bits necesita 4.5 GB y cabe cómodamente en una tarjeta de 6 GB. No es así.

La KV cache es la parte que se mueve. Cada token en el contexto tiene un vector de clave y valor almacenado para cada capa, por lo que el modelo puede atender al pasado sin volver a calcularlo. Eso es lo que hace que la generación sea rápida, y es por eso que la cache no es opcional. Escala linealmente con el contexto, linealmente con las solicitudes simultáneas, y está determinada por el diseño de la atención en lugar del recuento de parámetros. Aquí cuesta exactamente 0.125 GB por 1024 tokens, lo cual es pequeño porque Llama 3.1 usa ocho cabezales de clave-valor para treinta y dos cabezales de consulta.

La sobrecarga de ejecución es la parte que nadie presupuesta y con la que todos se topan. Kernels compilados, contexto CUDA o Metal, buffers de activación y logit, el asignador que no puede empaquetar bloques perfectamente y el conjunto de trabajo del sampler. Esta calculadora lo modela como un fijo de 0.65 GB más el 8 por ciento de todo lo demás. Es una aproximación deliberada, pero la forma es correcta: la sobrecarga no desaparece en modelos pequeños y no permanece constante en los grandes.

Una nota sobre unidades, porque causa confusión real. Cada GB en esta página se calcula dividiendo por 1024 al cubo, por lo que técnicamente es un gibibyte. Esa es la misma unidad que reporta su controlador de GPU, por lo que una tarjeta vendida como 24 GB muestra alrededor de 24564 MiB. Los archivos de modelo en Hugging Face generalmente se enumeran en gigabytes decimales, por lo que una descarga de 5.0 GB aparece aquí como aproximadamente 4.65 GB. La brecha es de aproximadamente el 7 por ciento y juega a su favor, no en su contra.

Elegir un nivel de cuantización

La cuantización almacena cada peso en menos bits. Un modelo lanzado en BF16 gasta dos bytes por parámetro; una cuantización de 4 bits gasta un poco más de medio byte. Nada más sobre el modelo cambia, por lo que la cuantización es la mayor palanca que tiene sobre si algo cabe o no.

Aquí hay un modelo, Llama 3.3 70B, en cada nivel que ofrece esta calculadora. Los pesos son el archivo en disco; las otras dos columnas son la huella cargada completa, incluyendo cache y sobrecarga en un solo flujo con una cache F16.

Hay tres cosas en esa tabla que vale la pena observar. Primero, el conteo nominal de bits es una mentira a su favor y en su contra. Q4_K_M no es de 4 bits por peso, es de 4.85, porque los formatos K-quant mantienen los tensores de atención y embedding en una precisión mayor donde el daño es peor. Q2_K promedia 3.35 bits por la misma razón. Si calcula el tamaño de un modelo como parámetros por cuatro sobre ocho, subestimará el resultado en aproximadamente una quinta parte.

Segundo, los rendimientos disminuyen drásticamente a medida que se reduce. Pasar de BF16 a Q8_0 reduce el modelo a la mitad y no tiene un costo medible. Pasar de Q8_0 a Q4_K_M casi lo reduce a la mitad de nuevo con un costo de calidad que la mayoría de la gente no puede detectar en el uso ordinario. Pasar de Q4_K_M a Q3_K_M ahorra 7.8 GB y comienza a notarse en un peor seguimiento de instrucciones, código más débil y más errores aritméticos. Por debajo de eso, está intercambiando capacidad por volumen de una manera que notará.

Tercero, el daño de una cuantización agresiva no se distribuye uniformemente entre los tamaños de modelo. Un 70B en Q2_K sigue siendo un modelo utilizable, porque hay una enorme redundancia que destruir. Un 3B en Q2_K frecuentemente produce resultados corruptos. La regla general que sobrevive al contacto con la práctica: prefiera un modelo más grande con una cuantización menor hasta unos 4 bits, y prefiera un modelo más pequeño a 4 bits o mejor por debajo de eso. Un 70B en Q4_K_M supera a un 32B en Q8_0 en la mayoría de las tareas; un 70B en IQ2_XXS generalmente no lo hace.

Un caso especial que vale la pena conocer. Algunos modelos se publican de forma nativa en un formato de pocos bits en lugar de cuantizarse después. gpt-oss se distribuye en MXFP4 a 4.25 bits por peso y, debido a que el entrenamiento lo tuvo en cuenta, la calidad no es comparable a una compresión a 4 bits de una versión BF16. Es por eso que la calculadora solo ofrece MXFP4 para modelos que realmente se distribuyen así, y por qué gpt-oss 120B ocupa 63.4 GB en lugar de los 250 GB que necesitaría un modelo de 117B en precisión completa.

Por qué la longitud de contexto es una decisión de hardware

La gente trata la longitud de contexto como un flag de funcionalidad: la ficha del modelo dice 128K, así que lo configuran a 128K. No es un flag, es una asignación de memoria y, en algunas arquitecturas, es la línea más grande en el presupuesto. Aquí hay cuatro modelos en Q4_K_M, flujo único, caché F16, con la huella total cargada en cuatro longitudes de contexto.

Llama 3.1 8B cuadruplica su tamaño entre 2K y 128K, de 5.8 GB a 22.8 GB, que es la diferencia entre ejecutarse en casi cualquier cosa y no caber en una tarjeta de 24 GB. Command R 35B es el caso extremo: comienza siendo más pequeño que Qwen3 32B a 2K y termina siendo casi cuatro veces más grande a 128K, porque utiliza atención multi-head completa con 64 cabezales key-value y consume 1.25 GB de caché por cada 1024 tokens. Gemma 3 27B apenas se mueve, porque cinco de cada seis de sus capas solo atienden a una ventana de 1024 tokens y, por lo tanto, dejan de crecer casi de inmediato.

La consecuencia práctica es que la longitud de contexto que configure debe ser la que realmente utiliza, no la máxima que admite el modelo. Si sus prompts son de 3000 tokens y sus respuestas de 800, configurar 32K desperdicia memoria que podría haber invertido en una mejor cuantización. Llama 3.1 8B en Q4_K_M en una tarjeta de 24 GB puede manejar un contexto de 64K, pero no de 128K, porque 128K necesita 22.8 GB y la tarjeta solo deja unos 22.3 GB después de que la pantalla y el controlador toman su parte. Reducir la caché a Q8 le permite lograrlo. Nada más tiene que cambiar.

También importa qué runtime utilice. llama.cpp asigna la caché para el tamaño de contexto que usted pasa y nada más, por lo que un contexto pequeño realmente libera memoria. vLLM, en cambio, reclama una fracción de la tarjeta por adelantado y gestiona un pool paginado en su interior, por lo que nvidia-smi mostrará la tarjeta casi llena sin importar lo que configure. El número que le da esta calculadora es el conjunto de trabajo que necesita, que se asigna directamente al comportamiento de llama.cpp y al pool que vLLM debe poder asignar.

La caché se decide por arquitectura, no por tamaño

El dato más útil sobre la caché KV es que el conteo de parámetros apenas lo predice. Lo que lo predice es cuántos cabezales key-value mantiene un modelo, qué tan ancho es cada uno, cuántas capas tiene y si hace algo inteligente. Aquí está el costo de caché por 1024 tokens para modelos que abarcan tres órdenes de magnitud en conteo de parámetros.

Lea las filas superior e inferior juntas. Un modelo de 671B tiene una caché más pequeña que uno de 35B, y un modelo de 3.8B tiene una caché cuatro veces y media más grande que uno de 27B. Phi-3.5 mini en un contexto completo de 128K necesita 54.8 GB en total, de los cuales solo 2.2 GB son pesos. Ese es un modelo que la gente describe como pequeño que necesita más memoria que uno de 32B.

Cuatro mecanismos explican toda la tabla. La atención Grouped-query comparte un cabezal key-value entre varios cabezales de consulta, lo cual es el estándar de la industria ahora y típicamente reduce la caché de cuatro a ocho veces. La atención Sliding-window da a la mayoría de las capas una ventana fija para que su caché deje de crecer más allá de ella, que es por lo que Gemma 3 y gpt-oss se aplanan. La atención Multi-head latent, utilizada por DeepSeek, comprime claves y valores en un solo vector de 576 elementos por token por capa en lugar de almacenarlos completos. Y la atención multi-head simple, todavía utilizada por versiones anteriores como Command R y Phi-3.5, no hace nada de esto y paga por cada cabezal.

Si desea la versión larga de este argumento con las derivaciones, está redactada por separado en por qué el conteo de parámetros es un mal predictor de VRAM.

Cuándo vale la pena la cuantización de caché KV

La caché se puede cuantizar igual que los pesos. F16 gasta 2 bytes por elemento almacenado; la opción Q8 aquí promedia 1.06 bytes y Q4 promedia 0.56, el overhead proviene de las escalas por bloque. Todo runtime serio lo admite: llama.cpp lo expone como cache-type-k y cache-type-v, vLLM como un flag kv-cache-dtype.

La pregunta nunca es si ahorra memoria. Es si el ahorro es lo suficientemente grande como para importar, y eso depende totalmente de cuánta de su huella es caché en primer lugar. En un contexto de 32K con pesos Q4_K_M:

Command R gana 20.3 GB con un solo flag, que es la diferencia entre necesitar dos tarjetas de 48 GB y necesitar una. Llama 3.3 70B gana 5.1 GB con el mismo flag, porque la atención grouped-query ya hacía su caché pequeña. El patrón se mantiene en general: la cuantización KV es transformadora en modelos multi-head en contextos largos y marginal en modelos grouped-query en contextos cortos. Revise el segmento de caché KV en el desglose anterior antes de usarlo. Si esa barra es una línea delgada, el flag no le salvará.

El costo es real pero limitado. La caché Q8 es casi gratuita en términos de calidad y vale la pena habilitarla por defecto en cualquier carga de trabajo de contexto largo. La caché Q4 degrada exactamente para lo que sirve el contexto largo: la recuperación precisa de hechos específicos enterrados profundamente en la entrada. El resumen y el chat abierto lo toleran bien; la recuperación en un documento largo, las búsquedas de tipo aguja en un pajar y el razonamiento de código en múltiples archivos no. También hay una asimetría que vale la pena conocer, que es que las claves son más sensibles a la cuantización que los valores, por lo que si su runtime le permite configurarlos por separado, una caché de claves Q8 con una caché de valores Q4 suele ser mejor que Q4 en ambos.

Una regla que no le llevará a error: cuantice primero los pesos, después la caché. Los pesos Q4_K_M con una caché F16 superan a los pesos Q6_K con una caché Q4 con el mismo tamaño total, en casi todos los casos, porque la cuantización de pesos ha sido estudiada y ajustada mucho más exhaustivamente que la cuantización de caché.

Dos tarjetas de 24 GB no son una tarjeta de 48 GB

Dividir un modelo entre GPUs funciona, y para modelos grandes es la única ruta asequible. Pero la aritmética no es una suma, y la diferencia aparece en dos lugares: capacidad utilizable y velocidad de decodificación.

En cuanto a capacidad, una sola tarjeta pierde una parte debido al driver, la salida de pantalla y la fragmentación del asignador. Esta calculadora asume que aproximadamente el 93 por ciento es utilizable en una tarjeta de consumo y el 95 por ciento en una tarjeta de workstation o centro de datos sin pantalla conectada. Una división en varias tarjetas pierde más, alrededor del 90 por ciento, porque cada tarjeta lleva su propio contexto de ejecución y su propia copia de los buffers de activación, y porque la división de capas casi nunca se reparte de forma equitativa. Por tanto, dos RTX 4090 le dan unos 43.2 GB de espacio de trabajo, mientras que una sola RTX 6000 Ada con los mismos 48 GB nominales ofrece 45.6 GB.

Esa brecha de 2.4 GB decide casos reales. Llama 3.3 70B en Q4_K_M con un contexto de 8K necesita 46.4 GB, por lo que no cabe en ninguna. Cambiar el caché a Q8 lo lleva a 45.1 GB, lo que cabe en la tarjeta única de 48 GB pero sigue sin caber en el par. Para ejecutarlo en dos 4090, debe bajar también a pesos Q4_0, a 42.5 GB. Misma memoria nominal, dos compromisos adicionales.

En cuanto a velocidad, la expectativa habitual es que dos tarjetas sean el doble de rápidas. Para la decodificación de flujo único no lo son, y a menudo son más lentas de lo que sería una sola tarjeta si el modelo cupiera. La división predeterminada en llama.cpp y en la mayoría de configuraciones de un solo nodo es el paralelismo de tubería (pipeline parallelism): las capas 0 a 39 residen en la primera tarjeta, y de la 40 a la 79 en la segunda. Generar un token recorre las ochenta capas en orden, por lo que exactamente una GPU realiza trabajo útil en cualquier momento mientras la otra espera, además de una transferencia de estado oculto a través de PCIe en el límite. Ha comprado capacidad, no rendimiento. Esta calculadora modela eso como una caída en la eficiencia del ancho de banda de 0.75 en una sola tarjeta a 0.6 en una división, lo que sitúa a dos RTX 4090 en aproximadamente 13 tokens por segundo en un modelo de 70B y a una sola RTX 6000 Ada en aproximadamente 16, a pesar de que el par tiene un mayor ancho de banda bruto por tarjeta.

El paralelismo de tensores (tensor parallelism), que utilizan vLLM y TensorRT-LLM, es la alternativa: cada capa se divide entre todas las tarjetas y trabajan simultáneamente. Eso escala realmente la velocidad de decodificación, pero necesita un all-reduce entre tarjetas en cada capa, por lo que requiere NVLink o al menos carriles PCIe x16 completos para cada tarjeta. En una placa base de consumo que ejecuta la segunda tarjeta a x4, el paralelismo de tensores puede ser más lento que el paralelismo de tubería. También requiere que el número de cabezales de atención sea divisible por el número de tarjetas, razón por la cual las configuraciones de tres tarjetas son complicadas.

Resumen práctico: añada tarjetas para ajustar un modelo que de otro modo no podría ejecutar, no para hacer que un modelo que ya puede ejecutar vaya más rápido. Y si elige entre una tarjeta grande y dos pequeñas al mismo precio, la tarjeta única gana en simplicidad, consumo de energía, capacidad utilizable y latencia de flujo único. Varias tarjetas ganan cuando atiende solicitudes concurrentes, donde el procesamiento por lotes mantiene ocupada a cada tarjeta.

Qué sucede al descargar a la memoria RAM del sistema

Si un modelo no cabe, llama.cpp y Ollama mantendrán algunas capas en la RAM del sistema y las ejecutarán en la CPU. Funciona. También es el punto en el que la gente concluye que su hardware está roto, porque la velocidad no se degrada suavemente.

La razón es que la decodificación está limitada por el ancho de banda de la memoria, no por el cómputo. Para producir un token, el runtime lee cada peso activo y todo el caché una vez. Para Llama 3.3 70B en Q4_K_M con un contexto de 8K, eso supone unos 45.5 GB de lecturas por token. Divida eso por el ancho de banda de la memoria donde resida y tendrá su límite antes de que se haya realizado cualquier cómputo.

Una RTX 4090 lee a 1008 GB/s. La DDR5 de doble canal en un escritorio típico lee a aproximadamente 90 GB/s. Es una diferencia de once veces, y esa es toda la historia. Si el modelo de 70B cupiera completamente en la 4090, decodificaría a unos 17 tokens por segundo. No cabe: 22.3 GB de los 46.4 GB están residentes, por lo que el 52 por ciento de cada lectura de token proviene de la RAM del sistema a una novena parte de la velocidad. El resultado es de unos 2.6 tokens por segundo. Mantuvo el 48 por ciento del modelo en el dispositivo rápido y perdió el 84 por ciento de la velocidad.

El mismo patrón se aplica a todas las escalas. Llama 3.1 8B lee 5.9 GB por token; en una 4090 eso es aproximadamente 127 tokens por segundo, y totalmente en CPU con 90 GB/s de RAM es aproximadamente 11. Qwen3 32B en Q4_K_M necesita 22.8 GB, por lo que en una RTX 5080 de 16 GB, aproximadamente el 65 por ciento permanece residente y la estimación cae de aproximadamente 33 tokens por segundo a aproximadamente 8.

Dos detalles hacen que la experiencia real sea peor de lo que sugieren estos números. El procesamiento de prompts en capas de CPU está limitado por el cómputo más que por el ancho de banda, por lo que un prompt largo puede tardar minutos antes de que aparezca el primer token, incluso cuando la tasa de streaming posterior parece tolerable. Además, la descarga no es gratuita en el lado de la GPU, ya que el runtime sigue necesitando buffers de trabajo para las capas que sí aloja.

Cuándo la descarga sigue siendo la decisión correcta: trabajos por lotes que no requieren espera, modelos donde un par de tokens por segundo es realmente suficiente, y el caso donde solo unas pocas capas se desbordan. Descargar el diez por ciento le cuesta mucho menos que el cincuenta por ciento. Cuándo es la decisión incorrecta: cualquier cosa interactiva. Un modelo más pequeño con una buena cuantización casi siempre le servirá mejor que uno más grande arrastrándose por sus DIMMs, y si necesita la capacidad del modelo más grande, llamarlo a través de una API es más rápido y barato que hacer que su escritorio finja.

Apple Silicon y memoria unificada

Apple Silicon no tiene VRAM separada. La CPU y la GPU comparten un pool de LPDDR en el mismo paquete, lo que significa que un Mac con 128 GB de memoria puede cargar un modelo que ninguna GPU de consumo en el mercado puede contener. Esa es una ventaja genuina y es la razón por la que los Macs son comunes en los círculos de inferencia local. Viene con dos matices que la gente descubre tarde.

El primero es que no obtiene toda la memoria. macOS reserva memoria para todo lo demás que hace la máquina y limita lo que la GPU puede reservar; esta calculadora asume que aproximadamente el 75 por ciento está disponible para un modelo, por lo que 128 GB de memoria unificada se convierten en aproximadamente 96 GB de presupuesto y un Mac mini de 16 GB se convierte en aproximadamente 12 GB. El límite puede aumentarse con el ajuste iogpu wired limit, pero llevarlo cerca del total físico arriesga a que el sistema haga swapping, y hacer swapping de un modelo es peor que no cargarlo.

El segundo es el ancho de banda. La memoria unificada es amplia, pero no tanto como la GDDR. Un M4 Max lee a unos 546 GB/s frente a los 1008 GB/s de una RTX 4090 y los 1792 GB/s de una RTX 5090, y el M4 base en un Mac mini lee a unos 120 GB/s, que es un tercio de lo que gestiona una RTX 3060 de hace cinco años. En Llama 3.1 8B en Q4_K_M, eso resulta en aproximadamente 60 tokens por segundo en un M4 Max, aproximadamente 13 en un Mac mini con M4 base, y aproximadamente 45 en la RTX 3060. La capacidad y la velocidad son compras separadas, y Apple vende mucho de lo primero por dólar y relativamente poco de lo segundo.

El procesamiento de prompts es el punto más crítico. La decodificación está limitada por el ancho de banda, donde Apple simplemente está por detrás; el prefill está limitado por el cómputo, donde la brecha frente a una tarjeta NVIDIA moderna con núcleos tensoriales dedicados es mucho mayor. Un documento de 30000 tokens pegado en un chat en un Mac puede quedarse esperando un tiempo notable antes de que empiece el streaming, aunque el streaming en sí mismo luego se vea bien. Si su carga de trabajo consiste en prompts largos y respuestas cortas, ese es el número que debe probar antes de comprar.

Donde un Mac gana claramente es en el rango medio que las tarjetas discretas no pueden alcanzar a ningún precio razonable. Llama 3.3 70B en Q4_K_M cabe cómodamente en un M4 Max de 128 GB a unos 8 tokens por segundo, y un M2 Ultra de 192 GB lo ejecuta a unos 11, pudiendo además albergar modelos que necesitan bastante más de 100 GB. Llegar a eso con hardware NVIDIA significa varias tarjetas, una placa base con los carriles para alimentarlas y una fuente de alimentación a la altura. Use MLX en lugar de un backend genérico cuando pueda, ya que está escrito para este modelo de memoria y supera constantemente a las alternativas en la misma máquina.

Atender a más de una persona a la vez

Todo lo anterior asume una solicitud a la vez. En el momento en que pone el modelo detrás de un endpoint que otras personas usan, los pesos permanecen compartidos pero cada solicitud concurrente lleva su propio KV cache. Eso convierte al caché de un elemento secundario en el costo dominante. Llama 3.1 8B en Q4_K_M con un contexto de 8K, a concurrencia creciente:

Con dieciséis usuarios concurrentes, el caché es más grande que el modelo. Con treinta y dos, un modelo de 8B necesita más memoria que uno de 70B para un solo usuario. Este es el número que sorprende a los equipos que hicieron prototipos en un portátil y luego se preguntaron por qué el servidor se caía con ocho personas usándolo.

La ventaja es que la concurrencia es donde las GPUs dejan de desperdiciarse. La decodificación de flujo único deja la mayor parte del cómputo inactivo porque está esperando a la memoria; el procesamiento por lotes amortiza una lectura de pesos en muchas secuencias, por lo que el rendimiento total aumenta mucho más rápido que el uso de memoria. Este es también el caso donde un caché paginado se justifica, ya que vLLM asigna caché en bloques a medida que las secuencias crecen realmente, en lugar de reservar el peor caso para cada ranura. Si está dimensionando un servidor, hágalo para el caché según su concurrencia real y su longitud media de prompt real, no para el contexto máximo multiplicado por el máximo de usuarios.

Errores comunes al dimensionar una GPU

Preguntas que la gente realmente hace

¿Cuánta VRAM necesito para ejecutar un modelo de 7B u 8B?

Unos 6.6 GB en Q4_K_M con un contexto de 8K, lo cual cabe en una tarjeta de 8 GB con algo de margen. En BF16, el mismo modelo requiere 17.9 GB y pide una tarjeta de 24 GB. Si quieres el contexto completo de 128K, sube a 22.8 GB, por lo que aquí el contexto importa tanto como la precisión.

¿Por qué mi modelo de 8 GB se niega a cargarse en una tarjeta de 8 GB?

Tres razones se acumulan. El controlador y el escritorio ya han ocupado cerca del 7 por ciento de la tarjeta, la KV cache se asigna sobre los pesos y el runtime necesita aproximadamente 0.65 GB de espacio de contexto y kernel antes de realizar cualquier tarea. El tamaño del archivo es el único número que no incluye nada de eso.

¿Puede una tarjeta de 24 GB ejecutar un modelo de 70B?

No solo en VRAM. Llama 3.3 70B necesita 46.4 GB en Q4_K_M y 8K, e incluso en IQ2_XXS con un contexto de 2K sigue necesitando 22.5 GB frente a los aproximadamente 22.3 GB disponibles. Puedes descargar parte a la RAM del sistema y obtener un par de tokens por segundo, o ejecutar un 32B y obtener treinta.

¿Es Q4_K_M realmente suficiente?

Para casi todo, sí, y es el valor predeterminado por una buena razón. Almacena 4.85 bits por peso en lugar de 4 planos, manteniendo los tensores de atención y embedding en mayor precisión. La diferencia medible con Q8_0 es pequeña y el ahorro de memoria es cercano a la mitad. Baja de este nivel solo cuando la alternativa sea no ejecutar el modelo en absoluto.

¿Es mejor un modelo más grande a baja precisión que uno más pequeño a alta precisión?

Hasta unos 4 bits, sí. Un 70B en Q4_K_M supera a un 32B en Q8_0 en la mayoría de las tareas con un footprint similar. Por debajo de 3 bits, el orden se invierte para modelos pequeños y medianos, porque hay menos redundancia que sacrificar. Los modelos muy grandes toleran formatos de 2 bits mucho mejor que los pequeños.

¿Por qué la KV cache en un modelo de 3.8B es más grande que en uno de 27B?

Porque Phi-3.5 mini utiliza atención multi-head completa con 32 cabezales key-value, a 0.375 GB por cada 1024 tokens, mientras que Gemma 3 27B asigna a cinco de cada seis capas una ventana deslizante de 1024 tokens. A 128K, eso supone 48 GB frente a 10.4 GB. El tamaño de la caché sigue el diseño de la atención, no el número de parámetros.

¿Debería cuantizar la KV cache?

Habilita Q8 siempre que tu contexto sea largo; es prácticamente gratis. Opta por Q4 solo cuando la caché represente una gran parte de tu footprint y tu carga de trabajo no dependa intensamente de la recuperación de datos. En Command R 35B a 32K, Q8 ahorra 20.3 GB. En Llama 3.3 70B con el mismo contexto ahorra 5.1 GB, porque la grouped-query attention ya realizó el trabajo.

¿Dos tarjetas de 24 GB equivalen a una de 48 GB?

No. Obtienes aproximadamente 43.2 GB utilizables en lugar de 45.6, porque cada tarjeta lleva su propio contexto de runtime y la división de capas es desigual. La velocidad de un solo stream tampoco mejora, ya que el paralelismo de pipeline implica que una tarjeta calcula mientras la otra espera. Dos tarjetas aportan capacidad y, bajo concurrencia, throughput.

¿Qué tan rápido se ejecutará realmente?

Divide el ancho de banda de la memoria por los bytes leídos por token. Llama 3.1 8B en Q4_K_M lee 5.9 GB por token, por lo que una RTX 4090 a 1008 GB/s alcanza cerca de 127 tokens por segundo tras las pérdidas de eficiencia. Esa estimación es válida solo para la decodificación. El procesamiento de prompts está limitado por la computación y sigue una curva diferente.

¿Qué sucede realmente si descargo a la RAM del sistema?

La velocidad cae en picado en lugar de descender gradualmente. Llama 3.3 70B con el 48 por ciento de sus capas en una RTX 4090 y el resto en DDR5 decodifica a aproximadamente 2.6 tokens por segundo en lugar de los 17 que lograría si estuviera totalmente residente. Un pequeño desbordamiento es tolerable; la mitad del modelo no lo es.

¿Es un Mac una buena máquina para inferencia local?

Por capacidad por dólar, sí: un M4 Max de 128 GB ofrece aproximadamente 96 GB de presupuesto utilizable y ejecuta un 70B a unos 8 tokens por segundo. Por velocidad bruta, no: 546 GB/s de ancho de banda frente a 1792 en una RTX 5090, y el procesamiento de prompts es aún más lento. Cómpralo para modelos grandes y funcionamiento silencioso, no por latencia.

¿Ahorran memoria los modelos mixture-of-experts?

Ahorran tiempo, no espacio. Qwen3 30B-A3B sigue necesitando 20.1 GB porque cada experto debe estar residente, pero solo lee unos 3.3B de parámetros por token, por lo que decodifica varias veces más rápido que un modelo denso de 32B con el mismo footprint. Evalúa un modelo MoE por su total para ver si cabe y por sus parámetros activos para la velocidad.

¿Reduce la VRAM el flash attention?

Elimina la gran matriz de atención intermedia, lo cual es un ahorro real durante el prefill en prompts largos, y hace que el procesamiento de prompts sea más rápido. No reduce la KV cache, que es la parte que crece con tu contexto. Actívalo de todos modos; solo no esperes que los totales en esta página cambien.

¿Por qué nvidia-smi muestra la tarjeta llena cuando configuro un contexto pequeño?

Probablemente estés ejecutando vLLM, que reclama una fracción fija de la tarjeta al inicio y gestiona un pool de caché paginado en su interior. llama.cpp asigna solo lo que necesita el contexto que solicitaste. Las cifras aquí describen el working set, que es lo que vLLM debe ser capaz de asignar y lo que llama.cpp reporta directamente.

¿Cuánta VRAM necesito para hacer fine-tune en lugar de ejecutar un modelo?

Mucho más, y esta calculadora no lo modela. Un fine-tune completo mantiene pesos, gradientes y estado del optimizador a aproximadamente 16 bytes por parámetro, por lo que un modelo de 8B llega a cerca de 130 GB antes de las activaciones. QLoRA sobre una base de 4 bits está mucho más cerca del footprint de inferencia más la memoria de activación, por lo que es la única opción realista en una sola tarjeta de consumo.

¿Cambian los modelos de visión el cálculo?

El codificador de visión está incluido en el recuento de parámetros de los modelos multimodales listados aquí, por lo que la cifra de pesos es correcta. Lo que los totales no capturan es que las imágenes se expanden en un gran número de tokens antes de llegar al modelo de lenguaje, por lo que unas pocas imágenes de alta resolución pueden consumir más contexto, y por tanto más caché, que una página de texto.

¿Qué pasa si nada cabe?

Reduce primero el contexto, ya que suele ser la concesión más barata, luego cuantiza la caché a Q8 y después baja los pesos un nivel. Si aun así no es suficiente, un modelo más pequeño con una cuantización razonable supera a uno más grande que se arrastra desde la RAM del sistema. O llama a los mismos modelos de pesos abiertos a través de la API gratuita y deja que alguien más sea el dueño del hardware.