Protocolo de decisión para inferencia local: de la restricción de VRAM a la validación de aislamiento de red

Definición del presupuesto de memoria: pesos, KV cache y sobrecarga

El primer paso del protocolo es determinar la huella de memoria real de un modelo, que no se limita a los parámetros cuantizados. La memoria total requerida es la suma de cuatro componentes independientes: los pesos del modelo, la caché clave-valor (KV cache), las activaciones transitorias y la sobrecarga del framework de inferencia.

Un error común es aplicar un margen fijo del 20% sobre los pesos, lo cual es inexacto porque estos términos escalan de forma diferente. Por ejemplo, en un modelo de 7B parámetros con cuantización Q4_K_M, los pesos ocupan aproximadamente 4,9 GB (0,61 bytes por parámetro, no 0,5 como sugiere la fórmula simplificada de 4 bits). A esto hay que sumar la KV cache, que crece linealmente con la longitud del contexto. Para un contexto de 8.000 tokens, la KV cache puede añadir entre 1 y 2 GB adicionales, dependiendo de la arquitectura de atención (GQA o MHA) y la precisión de la caché (FP16 o FP8).

La separación entre estos componentes ayuda a convertir una cifra de capacidad en un presupuesto útil. Los pesos representan el almacenamiento del modelo cargado, mientras que la KV cache conserva información de atención asociada a los tokens que permanecen en el contexto. Las activaciones, en cambio, son datos de trabajo temporales que aparecen durante el cálculo; su volumen depende de cómo el runtime ejecuta la inferencia. La sobrecarga incluye memoria que utiliza el framework y el entorno de cómputo, por lo que el tamaño del archivo del modelo no basta para decidir si una GPU puede alojarlo.

La KV cache cambia con la longitud del contexto y con la estructura de atención. Por eso, dos configuraciones que usan los mismos pesos pueden tener requisitos de memoria distintos al procesar conversaciones de diferente longitud. GQA y MHA organizan de manera distinta las cabezas que intervienen en la atención, y FP16 o FP8 determinan cuánta memoria ocupa cada valor almacenado en la caché. El intervalo de 1 a 2 GB para 8.000 tokens es una estimación condicionada por esas variables, no un requisito fijo para cualquier modelo 7B.

La tabla ofrece un cálculo orientativo para una combinación concreta: modelo 7B, archivo Q4_K_M y contexto de 8.000 tokens. Sus cifras aproximadas suman unos 7,4 GB antes de considerar variaciones propias del modelo y del runtime. El valor de alrededor de 1,5 GB para la KV cache depende, entre otros elementos, de n_kv_heads y head_dim; no debe trasladarse sin cambios a otra arquitectura. Del mismo modo, la sobrecarga indicada corresponde a una estimación mínima de la configuración descrita, no a una constante universal de todas las GPU.

Una GPU con 8 GB puede resultar suficiente para esta estimación, pero el total calculado no describe por sí solo todas las condiciones de ejecución. El presupuesto también debe dejar espacio para las activaciones transitorias y para la sobrecarga efectiva del framework que no quede reflejada en una cifra simplificada. El contexto solicitado puede aumentar el consumo de caché, y una cuantización distinta modifica el espacio de los pesos. Por ello conviene comparar cada componente con la configuración concreta, en vez de añadir automáticamente un porcentaje idéntico a cualquier modelo.

Selección de la cuantización: precisión efectiva vs. bits nominales

La elección de la cuantización debe basarse en los bits efectivos, no en el nombre del archivo. Los formatos GGUF mezclan precisiones: Q4_K_M equivale a unos 4,9 bits efectivos (0,61 bytes/parámetro), mientras que Q8_0 son 8,5 bits (1,06 bytes/parámetro). Suponer 4,0 bits para Q4 subdimensiona los pesos en aproximadamente un 20%, lo que puede llevar a una selección de hardware insuficiente.

La degradación de calidad varía según la tarea. Q4_K_M ofrece un equilibrio aceptable para la mayoría de los casos de uso general, con una pérdida de calidad estimada entre el 1% y el 3% frente a FP16. Q5_K_M es recomendable si se dispone de VRAM adicional y se requiere mayor precisión en razonamiento o código. Q8_0 se acerca a la calidad original pero duplica el consumo de memoria respecto a Q4, por lo que solo es viable en hardware de gama alta o para tareas de evaluación crítica.

Los bits nominales identifican una familia de cuantización, pero no expresan necesariamente el promedio de almacenamiento de cada parámetro en el archivo completo. En GGUF, distintos tensores pueden usar precisiones distintas y también se almacenan valores auxiliares, como escalas por bloque. Los tensores de embedding que permanecen sin cuantizar contribuyen asimismo al tamaño final. Por eso Q4_K_M no equivale a cuatro bits exactos por parámetro, y la cifra efectiva de unos 4,9 bits permite estimar mejor el espacio ocupado por los pesos.

Esta diferencia tiene un efecto directo en el cálculo de capacidad. Aplicar cuatro bits exactos produce una estimación inferior a la correspondiente a 0,61 bytes por parámetro para Q4_K_M; el error se acumula al multiplicarlo por todos los parámetros del modelo. La misma precaución se aplica a Q8_0, cuyo valor indicado es de unos 8,5 bits o 1,06 bytes por parámetro. El nombre del formato sirve para reconocer la cuantización, pero los bytes efectivos son la magnitud pertinente al estimar memoria.

La calidad no se reduce en la misma proporción para todas las tareas ni para todos los modelos. La pérdida estimada del 1% al 3% para Q4_K_M frente a FP16 debe leerse como una orientación general, no como una garantía de resultado. Una evaluación concreta puede mostrar diferencias distintas según el tipo de tarea y el criterio utilizado para medirla. Por la misma razón, la recomendación de Q5_K_M cuando se busca más precisión en razonamiento o código expresa una opción condicionada por la VRAM disponible, no una promesa de que la cuantización por sí sola asegure una respuesta correcta.

Q8_0 utiliza aproximadamente el doble de memoria que Q4 en la comparación descrita y se acerca a la calidad original, pero esas formulaciones no fijan un resultado idéntico para cada modelo o tarea. La elección práctica combina el espacio disponible con el nivel de calidad que se necesita evaluar. Si el presupuesto obliga a usar Q4_K_M, el tamaño de los pesos puede estimarse con sus bytes efectivos, mientras que la posible variación de calidad debe comprobarse en la tarea correspondiente. Más memoria permite considerar una cuantización distinta; no elimina la necesidad de validar el comportamiento del modelo.

Configuración del runtime de inferencia: Ollama, LM Studio o vLLM

La selección del motor de inferencia depende de la carga de trabajo. Para un solo usuario en un equipo de escritorio, Ollama y LM Studio (basados en llama.cpp) son comparables en rendimiento y ofrecen una API compatible con OpenAI en localhost. Ollama destaca por su facilidad de uso y gestión de modelos con un solo comando, mientras que LM Studio ofrece una interfaz gráfica más completa para la experimentación.

Para entornos de producción con múltiples usuarios simultáneos, vLLM es superior debido a su uso de atención paginada y procesamiento por lotes continuo. En pruebas de concurrencia, vLLM puede servir hasta 44 veces más tokens por segundo que llama.cpp bajo carga alta. Sin embargo, para un único usuario, la diferencia es mínima, por lo que la elección debe priorizar la facilidad de auditoría y la integración con el flujo de trabajo existente.

La carga de trabajo determina qué propiedad del runtime resulta más importante. En uso de escritorio con una persona, la facilidad de instalación, la gestión de modelos y la forma de experimentar pueden pesar más que el procesamiento simultáneo de muchas solicitudes. Ollama y LM Studio se describen aquí como opciones basadas en llama.cpp, con rendimiento comparable para ese uso y una API compatible con OpenAI accesible en localhost. Esa comparación no implica que todas sus versiones, modelos o configuraciones tengan un rendimiento idéntico.

Ollama prioriza una gestión sencilla desde la línea de comandos, mientras que LM Studio ofrece una interfaz gráfica más amplia para experimentar. La tabla también distingue la integración de gestión de vectores asociada a LM Studio y el menor control sobre parámetros avanzados atribuido a Ollama. Estas características ayudan a escoger según el flujo de trabajo, pero no sustituyen la comprobación de los requisitos concretos de hardware y software. La etiqueta «caso de uso ideal» resume una orientación, no limita las herramientas a un único propósito.

vLLM está orientado a cargas con varias solicitudes simultáneas y emplea atención paginada y procesamiento por lotes continuo. Esas técnicas permiten aprovechar el procesamiento conjunto bajo determinadas condiciones. La cifra de hasta 44 veces más tokens por segundo frente a llama.cpp corresponde a una prueba de concurrencia específica; no constituye una proporción que pueda esperarse en cualquier modelo, GPU o configuración. El resultado depende de las condiciones del benchmark y de cómo se configure la carga, por lo que no sirve por sí solo para anticipar el rendimiento de una instalación distinta.

La diferencia entre los runtimes se reduce para un único usuario en la comparación descrita, de modo que el mayor rendimiento bajo concurrencia no convierte automáticamente a vLLM en la opción más conveniente para todos. Su configuración y sus requisitos de GPU también forman parte de la decisión. Para una instalación personal puede ser preferible priorizar facilidad de auditoría e integración con el flujo existente; en producción con solicitudes simultáneas, el batching puede ser más relevante. En ambos casos, una comparación representativa debe mantener constantes el modelo, el hardware y las condiciones de carga.

Auditoría de aislamiento de red: verificando la privacidad

El aislamiento de red es una estrategia de seguridad que implica dividir la red en segmentos independientes para prevenir el acceso no autorizado o la fuga de datos. En el contexto de inferencia local, el objetivo es garantizar que el proceso de inferencia no establezca conexiones salientes no autorizadas, manteniendo los datos dentro de la jurisdicción controlada por el operador.

Para verificar empíricamente el aislamiento, se deben utilizar herramientas de monitorización de tráfico como Wireshark o tcpdump para capturar las conexiones del proceso de inferencia. Además, se pueden configurar reglas de firewall para bloquear todo el tráfico saliente excepto las conexiones necesarias (si las hay). En entornos corporativos, esto se alinea con las prácticas de aislamiento de red administrada, donde se controla el acceso saliente mediante puntos de conexión privados y etiquetas de servicio.

El aislamiento divide una red en segmentos para controlar qué comunicaciones pueden cruzar entre ellos. En una instalación de inferencia local, ese diseño busca limitar las conexiones salientes del proceso y mantener los datos bajo el control de quien opera el entorno. Ejecutar el modelo en una máquina local no demuestra por sí mismo que el proceso carezca de acceso a la red: la privacidad depende también de las rutas habilitadas, las conexiones remotas y las reglas aplicadas al equipo.

Wireshark y tcpdump permiten observar tráfico durante una prueba, mientras que las reglas de firewall pueden bloquear salidas no autorizadas. La captura muestra las comunicaciones que ocurrieron durante el intervalo y las condiciones examinadas; no demuestra que nunca pueda producirse otra conexión bajo una carga o configuración diferente. Por eso el procedimiento propone repetir la observación con cargas variadas y combinarla con controles de firewall, en lugar de tratar una única captura como certificación absoluta.

La revisión debe distinguir las conexiones esperadas de las que no están autorizadas para la instalación. Si el sistema requiere alguna conexión saliente, la regla puede permitirla de manera explícita; si no la requiere, el bloqueo general reduce las rutas disponibles. Los comandos y mecanismos de firewall mencionados corresponden a ejemplos de herramientas, no a una política completa aplicable sin adaptación a cualquier sistema operativo o red corporativa. La configuración concreta debe reflejar la infraestructura y los servicios que el operador haya autorizado.

Una interfaz local tampoco determina por sí sola la política de privacidad de todo el flujo. Las rutas que recurren a modelos cloud, búsqueda web, APIs remotas, servidores MCP externos o subidas pueden enviar datos fuera del equipo, aunque la interfaz principal se ejecute localmente. Por tanto, la auditoría debe atender a las conexiones del proceso y a los servicios efectivamente activados. El aislamiento de red ayuda a controlar esas rutas, pero su alcance depende de las reglas y los componentes incluidos en la prueba.

Validación de la integridad del artefacto y prueba de humo

Antes de integrar el modelo en el flujo de trabajo, es crucial verificar la integridad del artefacto descargado. Esto implica comparar la suma de control (checksum) del archivo GGUF o safetensors con la publicada por el proveedor o la comunidad. Una discrepancia indica posible corrupción o manipulación del archivo.

Una vez validada la integridad, se debe ejecutar una prueba de humo mínima: generar una respuesta simple para confirmar que el modelo carga correctamente en la memoria y produce salida coherente. Esta prueba debe realizarse en un entorno aislado de red para no comprometer la auditoría de privacidad. Si la prueba falla, se debe revisar la compatibilidad entre la cuantización, el runtime y el hardware antes de proceder.

La suma de control permite comprobar si los bytes del artefacto coinciden con una referencia publicada. Para que la comparación sea útil, el valor esperado debe corresponder al mismo archivo y a una fuente que el operador considere válida. Si ambos valores difieren, el archivo no coincide con esa referencia; la discrepancia puede deberse a corrupción o manipulación, pero el resultado por sí solo no identifica la causa. Un hash coincidente tampoco demuestra que el modelo sea seguro o que su comportamiento sea correcto: verifica la identidad de los datos comparados.

La prueba de humo responde a una pregunta más acotada: si el runtime puede cargar el artefacto en la configuración actual y generar una respuesta sencilla. Una salida coherente en esa prueba no valida de forma exhaustiva la calidad, la precisión ni la seguridad del modelo. Tampoco demuestra que todos los contextos o cargas funcionen. Si la carga falla, revisar la compatibilidad entre cuantización, runtime y hardware permite localizar posibles incompatibilidades antes de integrar el modelo en el flujo de trabajo.

Mantener la prueba dentro de un entorno aislado de red evita que la comprobación de carga dependa de conexiones salientes no previstas. La captura de tráfico y las reglas de firewall complementan el cálculo de memoria y la verificación del checksum: cada control responde a un aspecto distinto. El checksum compara el archivo con una referencia; la prueba de humo observa una ejecución básica; la auditoría de red examina comunicaciones dentro de las condiciones probadas. Ninguno de esos pasos reemplaza a los demás ni convierte una comprobación limitada en una certificación completa.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.