¿Puede un servidor de IA doméstico compartir un mismo modelo entre varias sesiones de usuario?

Sí. Un servidor de IA doméstico puede cargar un modelo una vez y atender varias sesiones de usuario. Los servidores de inferencia modernos están diseñados para compartir los costosos pesos del modelo y mantener separado el estado de cada solicitud para cada conversación. Esto es mucho más eficiente en términos de memoria que cargar una segunda copia del mismo modelo para cada miembro de la familia.

El principal límite de escalabilidad normalmente no son los pesos. Son la caché KV en crecimiento, la longitud del contexto, la generación simultánea de tokens y las colas creadas por los usuarios activos. Por lo tanto, ofrecer servicio a varios usuarios es tanto un problema de programación como de tamaño del modelo.

¿Qué se comparte realmente entre los usuarios?

                 Un modelo cargado
                 pesos en RAM/VRAM
                         |
       +-----------------+-----------------+
       |                 |                 |
    Sesión A         Sesión B         Sesión C
   caché KV A        caché KV B        caché KV C
   historial A         historial B         historial C

Los pesos del transformador son de solo lectura durante la inferencia habitual, por lo que muchas solicitudes pueden utilizar la misma copia. Cada secuencia sigue necesitando su propio estado de tokens y su propia caché de atención.

¿Cómo gestionan los servidores de inferencia las solicitudes simultáneas?

Los distintos entornos de ejecución ofrecen diferentes controles de programación, pero el principio es similar: admitir varias secuencias, procesar por lotes cuando sea posible y poner en cola las solicitudes adicionales.

Las preguntas frecuentes de Ollama documentan los controles de solicitudes paralelas y señalan que el contexto paralelo aumenta los requisitos de memoria. El ejemplo paralelo de Llama.cpp muestra varios clientes simulados utilizando un único servidor de modelos.

Los servidores de mayor rendimiento, como vLLM, utilizan procesamiento por lotes y una programación consciente de la caché KV para mantener ocupados los aceleradores con varias secuencias entrantes.

Por qué la longitud del contexto puede consumir más memoria de lo que sugiere otro usuario

Supongamos que los pesos del modelo caben cómodamente en la VRAM. Cuatro usuarios abren una conversación muy larga cada uno. Los pesos no se cuadruplican, pero la caché KV puede crecer considerablemente para cada secuencia activa.

presupuesto de VRAM
  |
  +-- pesos del modelo      fijos
  +-- caché KV del usuario A    crece con el contexto
  +-- caché KV del usuario B    crece con el contexto
  +-- caché KV del usuario C    crece con el contexto
  +-- sobrecarga de ejecución

Por eso, «el modelo cabe» no basta para planificar la capacidad. Los sistemas multiusuario deberían establecer una longitud máxima de contexto, un máximo de secuencias simultáneas y una cola limitada.

La guía existente de ZimaSpace sobre programación de aceleradores para IA doméstica multiusuario profundiza en el mismo límite de recursos.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

¿Debería cada usuario tener un proceso de modelo dedicado?

Normalmente, no. Los procesos separados duplican los pesos y reducen el número de modelos que caben en la memoria. Aun así, pueden tener sentido cuando:

• los usuarios necesitan ajustes finos o cuantizaciones diferentes;
• el aislamiento sólido de procesos es más importante que la eficiencia;
• una carga de trabajo utiliza un entorno de ejecución personalizado;
• quieres una asignación fija de GPU por usuario;
• un modelo tiene requisitos incompatibles de contexto o muestreo.

Para una familia o un equipo pequeño que usa el mismo modelo, normalmente es más sencillo utilizar un único servicio de inferencia detrás de una aplicación autenticada.

Mantén la memoria de conversación fuera del servidor de modelos

El servidor de inferencia no debería ser la base de datos de autoridad sobre «quién dijo qué». Almacena el historial del chat y las preferencias de los usuarios en la capa de la aplicación, bajo un ID explícito de usuario o sesión.

Navegador / aplicación
    |
    | user_id autenticado
    v
Aplicación de chat
    |
    +-- base de datos del historial (por usuario)
    +-- permisos de RAG
    |
    v
Servidor de modelos compartido

Antes de cada generación, la aplicación reúne únicamente el historial y el contexto privado recuperado que el usuario actual tiene permitido ver.

Esto es especialmente importante para un asistente de IA privado en un NAS, donde el mismo servidor puede contener documentos personales pertenecientes a varios miembros del hogar.

La caché de prefijos compartidos no es memoria de conversación compartida

Algunos entornos de ejecución pueden reutilizar la caché KV u otro trabajo para prefijos de prompt comunes. Por lo tanto, una instrucción de sistema compartida o un prefijo de documento repetido puede calcularse una vez y reutilizarse de forma eficiente.

Esta optimización no debe confundirse con permitir que el contexto privado de un usuario entre en el prompt de otro. Los sistemas de caché necesitan un aislamiento y una semántica de hash correctos; los permisos de la aplicación siguen determinando qué contenido puede proporcionarse a una solicitud.

Usa una programación justa para que un usuario no pueda ocupar el servidor

Una sola solicitud que pida una salida muy larga puede consumir la capacidad de decodificación mientras otros usuarios esperan. Añade controles de admisión como:

• límite de solicitudes simultáneas por usuario;
• número máximo de tokens de salida;
• ventana de contexto máxima;
• máximo global de secuencias activas;
• tiempo de espera de la cola;
• prioridad para solicitudes interactivas breves;
• cola de lotes separada para trabajos en segundo plano.

El chat interactivo y el resumen de documentos durante la noche no deberían competir con una política de programación idéntica.

¿Qué ocurre cuando el servidor se queda sin memoria?

Un buen servicio rechaza o pone en cola el trabajo nuevo antes de que el acelerador se bloquee. Los controles de capacidad deben utilizar el contexto real configurado, no solo un promedio optimista.

No reduzcas silenciosamente la ventana de contexto de todos los usuarios hasta que el servidor deje de bloquearse. Haz visible la política de contexto para que los usuarios sepan qué puede conservar el sistema.

La privacidad y la autenticación importan más en el modo multiusuario

Cuando un modelo sirve a un único administrador, puede bastar con un endpoint accesible solo desde localhost. En cuanto varias personas lo utilizan, la aplicación debe autenticar a los usuarios y autorizar sus fuentes de datos.

Protege:

• historiales de chat;
• colecciones RAG y ACL de documentos;
• prompts guardados;
• credenciales de herramientas;
• archivos generados;
• registros y trazas.

Un proceso de modelo compartido solo debería ver el contexto de la solicitud actual y no convertirse en una forma cómoda de eludir el modelo normal de permisos del NAS.

¿A cuántos usuarios puede dar servicio un servidor de IA doméstico?

No existe una cifra fija útil. Un servidor puede admitir muchos usuarios registrados si solo uno o dos están activos, mientras que dos usuarios simultáneos con contextos largos pueden agotar una GPU pequeña.

Compara estos tres escenarios:

1. un usuario interactivo;
2. la carga doméstica simultánea prevista;
3. un usuario intensivo y varias solicitudes breves.

Mide el tiempo hasta el primer token, los tokens por segundo por usuario, el tiempo en cola, la utilización de la caché KV, el uso de RAM/VRAM y la tasa de fallos de las solicitudes.

Preguntas frecuentes

¿Verán los usuarios las conversaciones de los demás porque el modelo es compartido?

No, si la aplicación mantiene separados el historial de conversación y el contexto de recuperación. Compartir los pesos del modelo no implica compartir el historial del chat.

¿La inferencia paralela hace que cada usuario sea más rápido?

Puede aumentar el rendimiento total, pero cada solicitud individual puede recibir menos capacidad de cómputo cuando hay varias secuencias activas. El objetivo suele ser mejorar el servicio agregado y reducir el tiempo en cola.

¿También puede un servidor alojar varios modelos?

Sí, si la memoria lo permite. Algunos entornos de ejecución cargan y descargan modelos según sea necesario, mientras que otros están diseñados en torno a uno o varios procesos persistentes de servicio. La programación de varios modelos añade otra capa de capacidad además de la programación multiusuario.

Veredicto final

Un modelo cargado es exactamente el recurso que normalmente debería compartir un pequeño servicio de IA doméstico. Mantén compartidos los pesos del modelo, aísla el historial de sesión y el estado KV, autentica a cada usuario, limita el contexto y la concurrencia, y programa el trabajo en segundo plano por separado del chat interactivo. La IA multiusuario se vuelve fiable cuando planificas el estado por sesión y el comportamiento de la cola, en lugar de multiplicar el proceso del modelo.