GPU-Offloading: Modelos entre RAM y VRAM

Qué cubre este artículo sobre GPU-Offloading

• Qué es GPU-Offloading y por qué lo necesitas cuando el VRAM no es suficiente
• Cómo se divide un modelo capa por capa entre GPU y CPU
• Diferencias concretas de velocidad entre GPU completa, offloading parcial y solo CPU
• Cómo configurar GPU-Offloading en Ollama y llama.cpp
• Qué alternativas existen y cuáles son las trampas típicas

Introducción: GPU-Offloading explicado

Quien ejecuta IA local tarde o temprano se encuentra con el mismo problema: el modelo es más grande que el VRAM de la tarjeta gráfica. En ese momento tienes varias opciones. Puedes elegir un modelo más pequeño, puedes cuantizar más agresivamente, o utilizas GPU-Offloading. Esto último significa que el modelo se ejecuta parcialmente en la GPU y parcialmente en el RAM de la CPU. No es la solución ideal, pero a menudo es el mejor compromiso entre velocidad y tamaño del modelo.

Este artículo trata los fundamentos de GPU-Offloading. Aprenderás cómo funciona, cuándo tiene sentido, cómo configurarlo y cuáles son los posibles problemas. Si ya conoces los conceptos de RAM vs. VRAM y CPU vs. GPU, eso es útil, pero no es imprescindible. Empezamos desde cero.

¿Por qué necesito GPU-Offloading?

Imagina que tienes una tarjeta gráfica con 6 GB de VRAM, por ejemplo una Nvidia RTX 2060 más antigua. Quieres ejecutar un modelo de 13B, es decir, un modelo con 13 mil millones de parámetros. Cuantizado a 4-bit, este modelo necesita aproximadamente 8 GB de memoria. Tu VRAM solo tiene 6 GB. El modelo no cabe completamente en la tarjeta gráfica.

Sin GPU-Offloading tienes dos opciones. O el programa se interrumpe con un mensaje indicando que no hay suficiente VRAM, o carga el modelo completamente en RAM y lo ejecuta en la CPU. Pero en la CPU el modelo es lento, porque la CPU tiene menos núcleos paralelos que la GPU y la RAM ofrece un ancho de banda de memoria inferior al del VRAM. En la práctica apenas llegarás a 5 o 10 tokens por segundo, si acaso.

Con GPU-Offloading ocurre algo diferente. El programa carga en VRAM todo lo que cabe, y deja el resto en RAM. En nuestro ejemplo, aproximadamente el 75 por ciento del modelo cabe en los 6 GB de VRAM, el 25 por ciento restante se queda en RAM. La GPU procesa su parte rápidamente, la CPU su parte más lentamente. El resultado es significativamente más rápido que solo CPU, porque la mayor parte de los cálculos ocurren en la GPU. En lugar de 5 tokens por segundo, quizás logres 15 a 20 tokens por segundo. No es velocidad de crucero, pero es funcional.

Aquí radica el valor de GPU-Offloading. Te permite utilizar modelos que en realidad son demasiado grandes para tu tarjeta gráfica sin que tengas que comprar hardware nuevo inmediatamente.

GPU-Offloading explicado brevemente

GPU-Offloading significa que un modelo de IA no se carga completamente en VRAM, sino solo una parte. El resto permanece en RAM y lo calcula la CPU. La GPU se encarga de las capas que caben en VRAM, la CPU se encarga del resto. Durante la inferencia, los datos fluyen continuamente entre ambas memorias.

Una analogía simple: imagina un trabajador que debe colocar cajas en una cinta transportadora. La cinta rápida es la GPU, la cinta lenta es la CPU. La cinta rápida solo cabe 6 cajas, pero hay 8 cajas en total. El trabajador coloca 6 cajas en la cinta rápida y las otras 2 en la lenta. La mayoría de las cajas llega rápido, solo 2 tardan más. En general, es mucho más rápido que si todas las 8 cajas tuvieran que ir en la cinta lenta.

GPU-Offloading funciona de manera similar. Cuanto más del modelo quepa en la cinta rápida, es decir, en VRAM, más rápida es la inferencia. Cuanto más deba quedarse en RAM, más frena eso la velocidad general.

¿Para quién está pensado GPU-Offloading?

GPU-Offloading va dirigido a cualquiera que quiera ejecutar un modelo que no cabe completamente en el VRAM de su tarjeta gráfica. Esto afecta especialmente a usuarios con tarjetas gráficas de 6 a 8 GB de VRAM que quieren ejecutar modelos de 13 mil millones de parámetros. Incluso quienes tienen una tarjeta más grande con 12 o 16 GB alcanzan el límite con modelos de 30B o 70B y necesitan GPU-Offloading.

Si acabas de comenzar con IA local y solo utilizas modelos de 7B, probablemente no necesites GPU-Offloading. Estos modelos caben en 8 GB de VRAM. Pero en cuanto experimentes con modelos más grandes, el tema se vuelve relevante. Vale la pena entender el concepto antes de encontrarte en la situación donde tu modelo de repente se vuelve lento y no sabes por qué.

Términos importantes relacionados con GPU-Offloading

Término	Significado
GPU-Offloading	Partes del modelo se descargan en la GPU, el resto permanece en RAM en la CPU
Partial Offloading	Solo una parte del modelo está en VRAM, el resto en RAM, el modelo se calcula dividido
Full Offloading	El modelo completo está en VRAM, la CPU no participa en la inferencia
Layer	Una capa de la red neuronal, los modelos constan de muchas capas una tras otra
VRAM	Memoria en la tarjeta gráfica, exclusiva para la GPU
RAM	Memoria del sistema, utilizada por la CPU
Ancho de banda de memoria	Cantidad de datos que pueden fluir por segundo entre la memoria y el procesador
Velocidad de inferencia	Velocidad a la que el modelo genera respuestas, generalmente en tokens por segundo
KV-Cache	Memoria temporal para valores de atención ya calculados, crece con la longitud del texto
Cuantización	Compresión del modelo mediante precisión numérica reducida, ahorra VRAM y RAM

¿Cómo funciona GPU-Offloading?

Para entender GPU-Offloading necesitas saber que un modelo de IA no es un único bloque, sino que consta de muchas capas, llamadas layers. Un modelo de 13B típicamente tiene alrededor de 40 layers. Cada layer contiene una parte de los pesos del modelo y se procesa secuencialmente cuando el modelo calcula una respuesta. La salida de un layer es la entrada del siguiente.

En GPU-Offloading, el modelo se divide en un punto específico. Los primeros layers que caben en VRAM se cargan en la GPU. Los layers restantes permanecen en RAM y la CPU los calcula. Por ejemplo, si cargas 30 de 40 layers en la GPU, 30 layers se ejecutan rápidamente en la GPU y 10 layers se ejecutan más lentamente en la CPU.

Durante la inferencia ocurre lo siguiente: la entrada, es decir, el texto que le das al modelo, primero pasa por los layers en la GPU. Después, el resultado intermedio se copia de VRAM a RAM para que la CPU pueda calcular los siguientes layers. El resultado de la CPU se copia nuevamente a VRAM si hay más layers en la GPU, o se utiliza directamente como salida.

Esta transferencia de datos entre VRAM y RAM cuesta tiempo. Cuantas más veces se deba copiar en ambas direcciones, mayor es la pérdida de velocidad. Por eso es mejor tener tantos layers como sea posible seguidos en la GPU, en lugar de mezclarlos. En la práctica, de todas formas los layers se cargan en orden, así que la división es automáticamente contigua.

El KV-Cache, es decir, la memoria temporal para los valores de atención, también debe tenerse en cuenta. Crece con la longitud del texto y requiere VRAM adicional. Cuando calculas cuántos layers caben en VRAM, debes reservar espacio para el KV-Cache. Si no lo haces, el modelo funcionará rápido al inicio pero se ralentizará a medida que crece la longitud del texto, porque el cache llena el VRAM.

Velocidad: Completa, Parcial, Nada

La velocidad de un modelo depende mucho de dónde se calcula. Aquí hay una comparación con números concretos para un modelo de 13B con cuantificación de 4-bit en hardware típico de consumidor.

Setup	Dónde se ejecuta el modelo	Tokens por segundo	Evaluación
Offloading completo	Completamente en VRAM (12 GB o más)	40 a 60	Muy rápido, ideal
Offloading parcial, 75% GPU	30 de 40 capas en VRAM (6 GB)	15 a 25	Usable, bueno para conversaciones
Offloading parcial, 50% GPU	20 de 40 capas en VRAM (4 GB)	8 a 15	Lento, requiere paciencia
Solo CPU	Completamente en RAM	3 a 8	Muy lento, solo para textos cortos

Estos números son referencias y varían según el hardware, el modelo y la cuantificación. Pero la tendencia es clara: cuanta más parte del modelo esté en VRAM, más rápido se ejecuta. El salto de solo CPU a 50% GPU es más notorio que el salto de 75% a offloading completo. Incluso un offloading parcial ya proporciona una mejora perceptible.

Un punto importante: la velocidad en offloading parcial no es lineal. Si carcas 75% del modelo en la GPU, no significa que alcances 75% de la velocidad del offloading completo. El cuello de botella es la transferencia de datos entre RAM y VRAM, así como el cálculo en CPU de las capas restantes. Por eso la velocidad cae desproporcionadamente conforme más capas permanecen en la CPU.

Configuración en Ollama y llama.cpp

Si usas Ollama, el offloading de GPU ocurre automáticamente. Ollama detecta al inicio cuánto VRAM está disponible y carga tantas capas como sea posible en la GPU. No necesitas configurar nada. Aun así, es útil saber cómo intervenir.

En Ollama puedes controlar el número de capas GPU con el parámetro num_gpu. Al iniciar un modelo, pasas el parámetro directamente:

ollama run llama3:13b --num-gpu 30

Este comando carga 30 capas en la GPU y el resto en RAM. Si lo omites, Ollama decide por sí solo. Con el parámetro puedes experimentar y descubrir qué funciona mejor en tu hardware.

En llama.cpp, el motor detrás de Ollama, existe el parámetro -ngl, que significa number of GPU layers. Una llamada típica se ve así:

./llama-cli -m modell.gguf -ngl 30 -p "Dein Prompt"

También aquí cargas 30 capas en la GPU con -ngl 30. Con -ngl 0 el modelo se ejecuta completamente en CPU, con -ngl 99 o un número mayor al de capas, cargas todo en la GPU, si hay espacio.

Si quieres saber cuántas capas tiene tu modelo, revisa la salida del modelo al inicio. Ollama y llama.cpp muestran al cargar cuántas capas se transfieren a la GPU y cuántas permanecen en RAM. Así puedes verificar si el offloading funciona como se esperaba.

Ejemplo: Modelo de 13B con 8GB VRAM

Veamos un ejemplo concreto. Tienes una tarjeta gráfica con 8 GB de VRAM y quieres ejecutar un modelo de 13B con cuantificación de 4-bit. El modelo necesita aproximadamente 8 GB de memoria solo para los pesos. Además está el KV-cache, que requiere entre 0,5 y 2 GB adicionales según la longitud del contexto.

Paso 1: Inicias el modelo con Ollama sin parámetros. Ollama detecta 8 GB de VRAM e intenta cargar el modelo completamente. Los pesos requieren 8 GB, el KV-cache necesita espacio adicional. El VRAM no es suficiente para ambos.

Paso 2: Ollama reduce automáticamente el número de capas GPU. En lugar de todas las 40 capas, carga tal vez 32 capas en VRAM. Eso corresponde a aproximadamente 6,4 GB para los pesos. El VRAM restante, alrededor de 1,6 GB, queda para el KV-cache y overhead.

Paso 3: Las 8 capas restantes permanecen en RAM y se calculan por la CPU. Son 20% del modelo en CPU, 80% en GPU.

Paso 4: La velocidad esperada es de aproximadamente 20 a 30 tokens por segundo, dependiendo de la CPU y la velocidad del RAM. Es notablemente más rápido que solo CPU, pero más lento que offloading completo con 12 GB de VRAM.

Paso 5: Si quieres mejorar la velocidad, puedes reducir el contexto para disminuir el KV-cache, o cuantificar más fuerte, por ejemplo a 3-bit, para meter más capas en el VRAM. Más información en Cuantificación.

Este ejemplo muestra que el GPU-offloading no es una decisión binaria, sino un espectro. Cada capa adicional que logres meter en el VRAM mejora la velocidad. Los requisitos de RAM y VRAM te ayudan a entender estas cifras para tu modelo específico.

Alternativas al GPU-Offloading

El GPU-offloading no es la única opción cuando el VRAM es muy pequeño. Estas son las alternativas principales.

Cuantificación más fuerte: Si cuantificas un modelo de 4-bit a 3-bit o 2-bit, el requisito de memoria se reduce significativamente. Un modelo de 13B que necesita 8 GB con 4-bit, podría ocupar 6 GB con 3-bit y entonces caber completamente en tu VRAM. La desventaja es una pérdida de calidad que es perceptible en 3-bit y clara en 2-bit. Más detalles en Cuantificación.

Modelo más pequeño: A veces la solución más sencilla es elegir un modelo más pequeño. Un modelo de 7B necesita aproximadamente 4 a 5 GB y cabe fácilmente en 8 GB de VRAM. La calidad de buenos modelos de 7B es a menudo sorprendentemente cercana a los modelos de 13B. Si tu caso de uso no requiere necesariamente el modelo más grande, te ahorras mucha frustración.

Más VRAM: La solución más obvia es una tarjeta gráfica con más VRAM. Una RTX 3060 con 12 GB es económica y puede cargar modelos de 13B completamente. Una RTX 4090 con 24 GB incluso maneja modelos de 30B. La guía de compra te ayuda en la selección.

Apple Silicon: Las Macs con Apple Silicon utilizan Unified Memory, donde CPU y GPU comparten una memoria común. Una Mac con 32 GB de Unified Memory puede poner casi toda la memoria a disposición de la GPU. El problema del VRAM demasiado pequeño no existe en la misma medida aquí. En cambio, el ancho de banda de memoria es menor que en tarjetas gráficas dedicadas de alto rendimiento.

Trampas típicas del GPU-Offloading

• Olvidar el KV-cache: El KV-cache necesita VRAM adicional y crece con la longitud del texto. Si solo calculas los pesos del modelo, crees que todo cabe, pero en conversaciones más largas el VRAM se agota y el modelo se ralentiza.
• Forzar demasiadas capas a la GPU: Si carcas manualmente más capas en la GPU de las que hay espacio, el programa se cuelga o hay errores. Deja que Ollama decida por sí solo en caso de duda, o reduce el número gradualmente.
• Esperar velocidad lineal: 50% de GPU-offloading no significa 50% de la velocidad. La transferencia de datos y el cálculo en CPU ralentizan desproporcionadamente. Ajusta tus expectativas en consecuencia.
• Subestimar la velocidad del RAM: El cálculo en CPU de las capas restantes depende mucho de la velocidad del RAM. Un RAM DDR4 lento hace que el offloading parcial sea notablemente más lento que un RAM DDR5 rápido.
• Ignorar el cuello de botella de PCIe: La transferencia de datos entre RAM y VRAM ocurre a través de la interfaz PCIe. Una versión antigua de PCIe o una tarjeta en el slot equivocado limita la tasa de transferencia y ralentiza el offloading.
• Pasar por alto la CPU como cuello de botella: Si la CPU es débil, las capas en la CPU se vuelven un cuello de botella. Una GPU potente no sirve de mucho si la CPU no calcula lo suficientemente rápido las capas restantes.
• Buscar offloading completo cuando lo parcial es suficiente: A veces el offloading parcial es más que suficiente, especialmente para modelos de 13B con 75% en la GPU. No necesitas comprar una tarjeta gráfica más grande solo para que el 100% quepa en VRAM.
• No considerar la cuantificación: Antes de resignarte a un offloading lento, prueba una cuantificación más fuerte. A menudo el modelo cabe entonces completamente en el VRAM y se ejecuta mucho más rápido.

Hardware, costos y seguridad en GPU-Offloading

Hardware: Para GPU-Offloading necesitas una tarjeta gráfica dedicada con al menos algo de VRAM, una CPU razonablemente moderna y suficiente RAM. Si quieres ejecutar un modelo de 13B con 8 GB de VRAM mediante offloading, tu equipo debe tener al menos 16 GB de RAM, preferiblemente 32 GB, para que el modelo tenga espacio en RAM y el sistema no esté bajo presión. La CPU debe ser al menos un procesador actual de 6 núcleos para que las capas de CPU no se conviertan en un cuello de botella.

Costos: GPU-Offloading en sí no cuesta nada, es una función del software. Los costos surgen del hardware. Una RTX 3060 de segunda mano con 12 GB de VRAM cuesta desde unos 200 euros y puedes cargar completamente modelos de 13B sin necesidad de offloading. Si te mantienes con una tarjeta más pequeña y utilizas offloading, ahorras dinero pero pagas con velocidad. Calcula por ti mismo si el ahorro vale la pena dado que la inferencia será más lenta.

Seguridad: GPU-Offloading no cambia nada en la seguridad de la IA local. El modelo se ejecuta completamente en tu equipo, ya sea en VRAM, en RAM o distribuido entre ambos. Ninguna consulta llega a un servidor, ningún dato abandona tu sistema. La transferencia de datos entre RAM y VRAM ocurre internamente y no afecta ninguna conexión de red. Quien usa IA local por razones de privacidad puede utilizar GPU-Offloading sin dudas.

Enlaces adicionales e información sobre GPU-Offloading

• KI-Hardware Grundlagen para más conocimientos básicos sobre hardware para IA local
• CPU vs. GPU si quieres entender por qué la GPU es más rápida
• RAM vs. VRAM para los fundamentos de ambos tipos de memoria
• Speicherbandbreite para el factor de velocidad más importante
• Quantisierung si prefieres reducir el tamaño de los modelos en lugar de usar offloading
• RAM und VRAM Anforderungen para números exactos sobre tamaños de modelos
• Ollama para la herramienta que maneja offloading automáticamente
• Kaufberatung si estás pensando en una nueva tarjeta gráfica

FAQ: GPU-Offloading - Preguntas típicas

¿Qué es GPU-Offloading explicado de forma sencilla?

GPU-Offloading significa que un modelo de IA se ejecuta parcialmente en la GPU en VRAM y parcialmente en la CPU en RAM. Esto sucede cuando el modelo no cabe completamente en el VRAM. La GPU asume la mayor parte, la CPU el resto.

¿Cuándo necesito GPU-Offloading?

Cuando tu modelo requiere más memoria de la que tu VRAM ofrece. Caso típico: tienes 8 GB de VRAM y quieres ejecutar un modelo de 13B que necesita 8 GB o más. Sin offloading, el modelo se ejecuta completamente en la CPU y es lento.

¿Cuánto más rápido es GPU-Offloading comparado con solo CPU?

Depende de cuánto del modelo quepa en la GPU. Con el 75 por ciento en la GPU, a menudo logras tres a cinco veces la velocidad de solo CPU. Con el 50 por ciento es considerablemente menos. La ganancia no es lineal.

¿Tiene sentido GPU-Offloading para cada modelo?

No. Para modelos pequeños que caben completamente en el VRAM, no necesitas offloading. Para modelos muy grandes donde solo el 10 por ciento cabe en la GPU, el offloading suele ser demasiado lento para ser práctico. El punto óptimo está entre el 50 y el 80 por ciento del modelo en la GPU.

¿Puedo configurar yo mismo cuántas capas van a la GPU?

Sí. En Ollama utilizas el parámetro num_gpu, en llama.cpp el parámetro -ngl. Con esto estableces el número de capas de GPU. Si omites el parámetro, el programa decide automáticamente.

¿Qué pasa si cargo más capas en la GPU de las que caben?

El programa se interrumpe o genera un error porque el VRAM no es suficiente. Reduce el número de capas hasta que el modelo se inicie. Ollama lo hace automáticamente si no estableces el parámetro manualmente.

¿Cuál es la diferencia entre Partial y Full Offloading?

Full Offloading significa que todo el modelo está en VRAM y la CPU no participa en la inferencia. Partial Offloading significa que solo una parte está en VRAM, el resto en RAM. Full Offloading es más rápido, pero requiere más VRAM.

¿Ayuda tener más RAM con GPU-Offloading?

Sí, pero solo indirectamente. Más RAM significa que las capas de CPU pueden calcularse más rápido porque hay suficiente memoria para el modelo y el sistema. Sin embargo, la velocidad depende más de la velocidad de la RAM y el rendimiento de la CPU que de la cantidad pura.

¿Necesito GPU-Offloading con Apple Silicon?

No, en el sentido clásico no. Apple Silicon utiliza Unified Memory, donde CPU y GPU comparten una memoria común. No hay separación entre VRAM y RAM. El modelo está en memoria compartida y la GPU accede directamente a ella. El concepto de offloading no existe aquí de la misma forma.

¿Se admite GPU-Offloading con múltiples tarjetas gráficas?

Sí. Ollama y llama.cpp pueden distribuir modelos entre varias GPUs. Cada GPU asume una parte de las capas. Esta es una forma de mantener modelos grandes completamente en VRAM sin necesidad de offloading a la CPU.

¿Pierde el modelo calidad con GPU-Offloading?

No. GPU-Offloading no cambia los cálculos, solo los distribuye entre dos procesadores. El resultado es idéntico, ya sea que el modelo se ejecute en la GPU, en la CPU o distribuido. La única diferencia es la velocidad.

Fuentes y lecturas adicionales

• Documentación de llama.cpp sobre GPU-Offloading y distribución de capas
• Ollama documentación sobre parámetros de GPU
• RAM vs. VRAM como base para entender los tipos de memoria
• Speicherbandbreite como factor decisivo para la velocidad
• Experiencias y benchmarks de la comunidad de IA local