¿Qué provoca que un entorno de ejecución de IA local cargue copias duplicadas de un modelo?
Las copias duplicadas del modelo aparecen cuando procesos, réplicas, sesiones o contextos de dispositivo independientes no pueden compartir una asignación de pesos cargada.
Un servidor de IA doméstico puede mostrar aproximadamente el doble de RAM o VRAM de la esperada después de añadir una interfaz web, un trabajador en segundo plano, un servicio de voz, un indexador de documentos o un segundo endpoint de API. El archivo del modelo en el disco puede seguir siendo único, mientras varios objetos de ejecución mantienen pesos independientes, tensores convertidos, kernels preempaquetados, cachés y contextos de dispositivo. Algunas duplicaciones son accidentales; otras son réplicas deliberadas creadas para la concurrencia, el aislamiento o la ejecución en paralelo.
Un solo archivo de modelo puede producir varios objetos de ejecución independientes
Cargar desde la misma ruta no implica que dos aplicaciones hagan referencia a un único modelo en memoria. Cada instancia de ejecución puede analizar el checkpoint y asignar sus propios tensores.
La guía de inferencia de Google Cloud distingue entre configuraciones que cargan una copia del modelo por proceso o por máquina virtual.
Si la memoria aumenta en incrementos del tamaño del modelo a medida que aumenta el número de trabajadores, la causa principal es la replicación de instancias. Los incrementos menores apuntan más probablemente a cachés por trabajador, asignadores o contextos de ejecución.
Los servidores web y los trabajadores de tareas suelen iniciar procesos separados
Un servidor frontend, un consumidor de colas, un programador, un servicio de transcripción y un trabajador de RAG pueden importar cada uno el cargador del modelo, aunque pertenezcan a una misma pila de Compose.
El aislamiento de procesos proporciona a cada servicio su propio espacio de direcciones. Las páginas de la CPU a veces pueden compartirse mediante mecanismos del sistema operativo, pero los objetos habituales de los frameworks y las asignaciones de la GPU no se convierten automáticamente en un único servicio de modelo compartido.
La duplicación sigue los identificadores de proceso y los límites entre servicios. Si detener un contenedor libera aproximadamente una copia del modelo, el contenedor no se limitaba a reenviar solicitudes a un entorno de ejecución central.
Las réplicas de servicio son copias individuales por diseño
Los sistemas de escalado automático aumentan el rendimiento iniciando más réplicas. Una réplica es un trabajador independiente capaz de atender solicitudes cuando los demás están ocupados.
Ray Serve define las réplicas como copias individuales que se ejecutan en procesos de actores separados.
El crecimiento de la memoria que sigue a los picos de tráfico o a los eventos del escalador automático es una replicación intencionada, no una fuga. La causa es el modelo de concurrencia elegido, aunque las réplicas adicionales tarden en reducirse.
Varias sesiones de inferencia pueden duplicar inicializadores y pesos preempaquetados
Una aplicación puede crear varias sesiones dentro de un mismo proceso para distintos hilos, endpoints, perfiles o proveedores de ejecución.
ONNX Runtime documenta el uso compartido de asignadores, inicializadores y pesos preempaquetados entre sesiones, ya que, de lo contrario, las sesiones independientes añaden sobrecarga de memoria.
Si un proceso posee varios objetos de sesión y la memoria aumenta cuando se inicializa cada sesión, el estado duplicado existe dentro de la aplicación y no entre contenedores.
El uso de fork no garantiza que los pesos del acelerador se compartan
Un proceso principal puede cargar un modelo antes de crear trabajadores y aparentar compartir páginas de la CPU mediante la copia al escribir. La inicialización del acelerador y el estado mutable del entorno de ejecución complican esa suposición.
La guía de multiprocesamiento de PyTorch explica que los tensores pueden utilizar mecanismos de memoria compartida entre procesos, pero el uso compartido requiere un diseño compatible y explícito.
Un trabajador que mueve el modelo a la GPU, modifica los pesos, crea una caché o se inicializa después de spawn puede asignar una nueva copia, aunque las páginas del checkpoint original de la CPU se hayan compartido.
Los contextos CUDA separados añaden estado del dispositivo por proceso
Dos procesos que utilizan una misma GPU normalmente funcionan mediante contextos CUDA distintos, a menos que se use una arquitectura especial de uso compartido.
NVIDIA señala que varias aplicaciones CUDA suelen crear varios contextos con sobrecarga de memoria.
La sobrecarga del contexto no constituye por sí sola un segundo modelo completo, pero puede acompañar a pesos, kernels, espacios de trabajo y cachés duplicados. Por tanto, los aumentos de memoria inferiores al tamaño del checkpoint también pueden deberse a la duplicación de procesos.
Dos instancias de ejecución en una GPU reservan memoria de forma independiente
Un panel de control puede iniciar un servidor de modelos mientras un servicio de automatización inicia otro, ambos apuntando al mismo checkpoint y dispositivo.
vLLM documenta que la utilización de memoria de la GPU es un límite por instancia y ofrece el ejemplo de dos instancias que dividen la capacidad de una GPU.
Si cada endpoint tiene su propio listener, registros, programador y caché KV, los dos procesos son motores de inferencia independientes. Un directorio de modelos compartido evita descargas duplicadas, pero no asignaciones de ejecución duplicadas.
Las recargas pueden dejar un proceso antiguo activo junto al nuevo
Los recargadores en caliente, supervisores, actualizaciones graduales, cierres fallidos y reinicios por comprobaciones de estado pueden iniciar un reemplazo antes de que el trabajador antiguo libere su modelo.
Esta causa aparece como un par temporal o persistente de procesos casi idénticos con distintas horas de inicio. Las solicitudes pueden llegar únicamente al proceso más nuevo mientras el antiguo continúa ocupando RAM o VRAM.
El artículo de ZimaSpace sobre por qué separar el estado de ejecución de IA de los archivos del modelo establece el límite: una caché de checkpoints puede servir a muchas implementaciones, pero la topología del servicio sigue determinando cuántas copias cargadas existen.
Preguntas frecuentes
¿Tener un solo archivo del modelo en el disco significa que solo hay una copia en la RAM?
No. Varios procesos o sesiones pueden leer de forma independiente el mismo archivo y asignar sus propios tensores, cachés y estados de ejecución.
¿Es toda copia adicional una fuga de memoria?
No. Las réplicas, los trabajadores de paralelismo de tensores, los entornos de ejecución alternativos y los servicios aislados pueden asignar estado adicional de forma intencionada. Una fuga crece sin que exista un objeto de ejecución activo que la justifique.
¿Pueden los contenedores compartir automáticamente un modelo en una misma GPU?
No. Los contenedores pueden acceder al mismo dispositivo y a los mismos archivos, pero necesitan un proceso de servicio compartido o un diseño explícito entre procesos para reutilizar una única asignación del modelo cargado.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Qué funciones permiten establecer un límite de confianza de IA doméstica alrededor de archivos confidenciales?
Un límite de confianza para la IA doméstica combina cifrado en reposo, permisos de mínimo privilegio, aislamiento del entorno de ejecución y recuperación con...
¿Qué hace que los resultados de búsqueda privados favorezcan los archivos editados con frecuencia?
Los archivos editados con frecuencia obtienen ventajas de posicionamiento cuando cada actualización añade señales de frescura, fragmentos, versiones o interacción sin normalizarlas por fuente.
¿Qué hace que los modelos de presencia del hogar inteligente confundan a los invitados con los residentes?
Los invitados pueden parecer residentes cuando el sistema observa patrones de actividad del hogar, pero carece de una señal de identidad estable de la...
