Un asistente local de documentos no necesita VRAM dedicada cuando la generación se ejecuta de forma remota o en un servidor de inferencia independiente. Para la inferencia en el mismo equipo, 8 GB es un punto de partida práctico para modelos pequeños cuantizados, mientras que los modelos más grandes, los contextos más extensos y la concurrencia pueden elevar el requisito muy por encima de 16–24 GB. Calcula el modelo exacto y el contexto de trabajo antes de comprar, porque la propia aplicación RAG no define el requisito de VRAM.
Decide si el asistente realmente necesita una GPU local
Un asistente de documentos tiene al menos dos capas: la aplicación que almacena archivos, divide el texto en fragmentos, busca o recupera pasajes y presenta respuestas; y el backend del modelo que realiza la generación. Estas capas no tienen que ejecutarse en el mismo hardware. Un servidor compacto puede alojar la biblioteca privada de documentos y la pila de recuperación, mientras envía las solicitudes del modelo a otro equipo local con GPU o a un proveedor remoto.
La documentación de alojamiento propio de AnythingLLM hace explícita esta separación al permitir que la aplicación se conecte a servicios de modelos y embeddings ubicados en otro lugar. Por ello, sus requisitos de alojamiento propio son mucho menores que el hardware necesario para ejecutar un LLM en el mismo equipo.
Si el requisito es «los documentos permanecen en mi servidor» en lugar de «cada token del modelo debe generarse en este servidor», cero VRAM dedicada puede ser una opción de compra válida. Aun así, debes verificar qué texto sale del equipo, dónde se generan los embeddings, cómo gestiona las solicitudes el modelo remoto y si el límite de privacidad coincide con el caso de uso.
La primera decisión de compra es arquitectónica: la inferencia remota o independiente implica dimensionar la CPU, la RAM y el almacenamiento para la recuperación; la inferencia en el mismo equipo convierte la VRAM en una limitación principal para seleccionar el modelo.
Calcula los pesos del modelo antes de añadir la sobrecarga de RAG
La planificación de la VRAM comienza con el modelo exacto y la precisión. Los pesos de precisión completa son mucho más grandes que las variantes de 8 u 4 bits, por lo que dos usuarios que dicen «ejecuto un modelo 7B» pueden tener requisitos de memoria muy diferentes. La cuantización puede hacer que un modelo pequeño útil funcione en hardware convencional, pero también puede cambiar el comportamiento de las respuestas y debe evaluarse con la tarea documental.
Hugging Face documenta que la cuantización reduce los costes de memoria y computación al representar los pesos y las activaciones con tipos de datos de menor precisión, y admite rutas habituales de 8 y 4 bits. Esto convierte la precisión en una variable de compra, no solo en un ajuste de software que se aplica después de elegir el hardware.
Como regla aproximada de planificación actual, los modelos de 7–8B cuantizados a 4 bits suelen caber en el rango de 6–8 GB; los modelos de 13–14B suelen acercarse a unos 10–12 GB; y los modelos de 27–32B suelen necesitar aproximadamente poco más de 20 GB antes de añadir margen para el contexto. La guía de Spheron para calcular la VRAM ofrece cifras similares para la planificación INT4 y añade explícitamente la sobrecarga de ejecución que va más allá de la estimación de los pesos.
No compres ajustándote exactamente al tamaño del archivo del modelo descargado. Deja espacio para el entorno de ejecución y el estado del contexto, y después verifica el modelo real en el motor de inferencia previsto. Un modelo que carga con una solicitud de prueba mínima aún puede fallar o descargar capas cuando el asistente recibe un contexto recuperado extenso.
La longitud del contexto puede cambiar el nivel de VRAM después de que el modelo quepa
Un asistente de documentos suele necesitar más contexto que un chatbot ocasional, porque los pasajes recuperados, las citas, las instrucciones del sistema, el historial de conversación y las preguntas del usuario se ensamblan en una sola solicitud. Los pesos del modelo pueden permanecer constantes, mientras que la caché de claves y valores y otros estados de la solicitud crecen con la longitud del contexto.
La documentación actual de Ollama sobre el contexto hace visible esta relación: su longitud de contexto predeterminada aumenta con la VRAM disponible, desde 4K por debajo de 24 GiB hasta 32K entre 24 y 48 GiB, y mucho más a partir de 48 GiB. Los valores predeterminados exactos son decisiones del entorno de ejecución, pero la lección para la compra es que trabajar con documentos y contextos extensos consume memoria adicional a la de los pesos del modelo.
No respondas maximizando el contexto indiscriminadamente. La recuperación debe seleccionar el conjunto más pequeño de pasajes que responda a la pregunta, y la división en fragmentos o la reclasificación deben eliminar el texto irrelevante antes de la generación. Un asistente de documentos que necesita introducir todos los documentos en una sola solicitud está usando VRAM para compensar un diseño de recuperación deficiente.
Pasa al siguiente nivel de VRAM cuando el modelo probado tenga una precisión suficiente, pero las solicitudes documentales reales provoquen descarga de capas, errores de falta de memoria o una latencia inaceptable con la longitud de contexto que realmente necesitas. Si la calidad de la recuperación es deficiente antes de que el contexto llegue al modelo, corrige primero el índice y la clasificación.
Presupuesta por separado los embeddings, la reclasificación, el OCR y la concurrencia
El LLM local no es el único componente que puede utilizar memoria de la GPU. Algunos asistentes de documentos también aceleran en la misma GPU los embeddings, los reclasificadores, el OCR, la transcripción de voz o los modelos de visión. Ejecutar estos modelos simultáneamente puede reducir la VRAM disponible para el generador, aunque cada componente quepa cuando se prueba por separado.
El artículo de ZimaSpace sobre la huella de memoria completa del modelo explica por qué los búferes de ejecución y el estado de las solicitudes deben considerarse junto al tamaño del punto de control. En un asistente de documentos, el contexto recuperado y los servicios paralelos añaden otra capa de presión sobre la memoria compartida.
La concurrencia también cambia la respuesta. Dos usuarios activos pueden necesitar estados de caché KV independientes aunque compartan un único modelo residente. Un servidor orientado al procesamiento por lotes puede mejorar el aprovechamiento del acelerador, pero no hace desaparecer la memoria necesaria por solicitud. Mide la consulta documental normal más extensa con el número previsto de usuarios simultáneos.
Si el generador es la única carga de trabajo de la GPU, puedes dimensionar más cerca de su conjunto de trabajo probado. Si el OCR, los embeddings, la reclasificación y la generación deben ejecutarse a la vez, compra más VRAM, serializa las etapas pesadas o separa los servicios entre recursos de CPU y GPU. La opción más económica es la que mantiene la latencia necesaria sin pagar por aceleración inactiva.
Usa niveles de VRAM para preseleccionar modelos y después prueba la calidad
Una preselección útil puede organizarse según lo que el asistente de documentos debe lograr, en lugar de basarse en el modelo más grande que quepa. Con unos 6–8 GB de VRAM, comienza con modelos pequeños de 7–8B cuantizados a 4 bits y una recuperación acotada. Con unos 12–16 GB, obtienes margen para modelos más grandes, mayor precisión o más contexto. Con unos 24 GB, muchos modelos cuantizados de 27–32B se vuelven prácticos con más margen de trabajo. Aproximadamente a partir de 40–48 GB comienza a ser realista utilizar modelos de escala 70B cuantizados a 4 bits sin una descarga de capas intensiva.
La guía de SitePoint sobre LLM locales de 2026 señala que un modelo 7B Q4_K_M puede funcionar cómodamente con unos 6 GB de VRAM. Otras guías actuales de dimensionamiento sitúan los modelos cuantizados de 14B y 32B en niveles superiores, lo que refuerza la regla de que el nivel depende del punto de control exacto y no de una etiqueta genérica como «PC de IA».
Crea un conjunto de evaluación a partir de tus propios documentos antes de comprar el siguiente nivel. Incluye preguntas que requieran extracción exacta, síntesis de varios pasajes, rechazo cuando falte la fuente, tablas o texto estructurado si es pertinente, y el contexto más extenso que esperes utilizar. Compara la calidad de las respuestas, el comportamiento de las citas, la latencia del primer token, la velocidad de generación y la VRAM máxima.
Compra más VRAM cuando el modelo pequeño falle porque la capacidad del modelo o del contexto sea realmente insuficiente. No actualices solo porque exista un punto de control más grande. La recuperación puede hacer que un modelo más pequeño y rápido sea más útil para una base de conocimiento privada acotada que un modelo más lento con una fundamentación deficiente.
Mantén separado el host de almacenamiento y recuperación de la decisión sobre la VRAM
Un asistente de documentos también necesita almacenamiento persistente para los archivos originales, el texto extraído, los índices, las bases de datos de la aplicación, los registros y las copias de seguridad. Estos recursos suelen consumir RAM del sistema y capacidad de disco, no VRAM. Combinar todos los recursos en una única cifra de «memoria de IA» conduce a malas decisiones de hardware.
La descripción de ZimaSpace de un asistente privado de IA en un NAS explica el papel de los archivos locales en una arquitectura centrada en la recuperación. Esta arquitectura permite que el sistema de almacenamiento permanezca estable aunque el hardware de inferencia cambie más adelante.
ZimaBoard 2 1664 es apropiada cuando la función del servidor compacto es almacenar documentos, indexarlos y ejecutar aplicaciones y orquestación, mientras el LLM se ejecuta de forma remota o en otro equipo con GPU. Sus gráficos Intel integrados no deben considerarse VRAM dedicada para LLM.
Elige el host de almacenamiento según el volumen de documentos, la memoria necesaria para las copias de seguridad y las aplicaciones, y las necesidades de red. Elige el acelerador según el modelo exacto, la cuantización, el contexto y la concurrencia. Mantener separadas estas decisiones permite actualizar la GPU sin reconstruir el almacén de documentos principal.
Verifica cualquier configuración con GPU en el mismo equipo antes de comprar
Si quieres combinar el almacenamiento, la recuperación y la generación local en una sola carcasa, la comprobación final de compra es la memoria exacta de la GPU disponible para el entorno de ejecución. Nombres de producto como «IA», «Creator» o «RTX» no indican si el modelo local elegido cabrá. Deben verificarse la VRAM, la compatibilidad de los controladores, el acceso desde contenedores, la alimentación, la refrigeración y las posibilidades de expansión física.
El ZimaCube 2 Creator Pack es la opción de Zima que conviene evaluar cuando se desea almacenamiento de varias bahías y una GPU NVIDIA dedicada en el mismo sistema. La página del producto actual identifica la familia de la GPU, pero no publica una cifra de VRAM en el texto principal de especificaciones; por tanto, no la asignes a un nivel de 8, 16, 24 o 48 GB hasta confirmar la memoria exacta de la GPU instalada.
Antes de finalizar la compra, ejecuta o solicita una prueba con un modelo representativo siempre que sea posible. Registra la VRAM máxima con la cuantización y el contexto normales, y repite la prueba con los embeddings, el reclasificador, el OCR u otros servicios de GPU del asistente activos. Confirma que el entorno de ejecución utiliza realmente la GPU prevista y no descarga silenciosamente capas en la memoria del sistema.
La regla final es comprar VRAM para el conjunto de trabajo validado, no para la categoría de marketing. Usa cero VRAM dedicada cuando la inferencia pueda ejecutarse en otro lugar; comienza con unos 6–8 GB para modelos locales pequeños cuantizados; pasa a 12–16 GB para modelos más grandes o mayor margen; y considera 24 GB o más solo cuando el flujo documental probado demuestre que el tamaño del modelo, el contexto o la concurrencia lo requieren.
Preguntas frecuentes
¿RAG reduce la cantidad de VRAM que necesito?
RAG puede permitir que un modelo más pequeño responda a partir de evidencia recuperada en lugar de depender del conocimiento interno de un modelo más grande, lo que puede reducir el nivel de modelo necesario. Los pasajes recuperados siguen consumiendo memoria de contexto, por lo que una recuperación deficiente que envíe demasiado texto puede aumentar la presión sobre la VRAM.
¿Los embeddings requieren la misma VRAM que el modelo de chat?
No. Los modelos de embeddings tienen su propia huella de CPU, RAM o GPU y pueden ejecutarse en la CPU o como servicio independiente. Si los embeddings y la generación comparten una GPU, mide el pico combinado en lugar de sumar sobre el papel los tamaños de los archivos de los modelos.
Guía de compra
Más para leer

Cómo traducir las especificaciones de CPU, RAM e IOPS al rendimiento de Plex
Una guía de compra para convertir las mediciones de carga de trabajo de Plex en requisitos mínimos de CPU, RAM, almacenamiento y red sin...

Cómo preseleccionar servidores domésticos para Plex mediante criterios ponderados
Una matriz de compra reproducible para Plex que separa los requisitos obligatorios de las preferencias y revela las incertidumbres antes de la compra.

¿Qué ciclo de soporte y actualizaciones debería ofrecer un servidor Plex?
Un marco de compra de aprobado o reprobado para evaluar la compatibilidad con servidores Plex, el historial de actualizaciones, la compatibilidad, la reparabilidad, los...

