Pode um servidor de IA doméstico partilhar um modelo entre várias sessões de utilizador?

Sim. Um único servidor de IA doméstico pode carregar um modelo uma vez e servir várias sessões de utilizadores. Os servidores de inferência modernos foram concebidos para partilhar os dispendiosos pesos do modelo, mantendo simultaneamente um estado de pedido separado para cada conversa. Isto é muito mais eficiente em termos de memória do que carregar uma segunda cópia do mesmo modelo para cada membro da família.

O principal limite de escalabilidade geralmente não são os pesos. É o crescimento da cache KV, o comprimento do contexto, a geração simultânea de tokens e as filas criadas pelos utilizadores ativos. Servir vários utilizadores é, por isso, tanto um problema de agendamento como de dimensão do modelo.

O que é realmente partilhado entre os utilizadores?

                 Um modelo carregado
                 pesos na RAM/VRAM
                         |
       +-----------------+-----------------+
       |                 |                 |
    Sessão A         Sessão B         Sessão C
   cache KV A        cache KV B        cache KV C
   histórico A         histórico B         histórico C

Os pesos do transformador são só de leitura durante a inferência normal, pelo que muitos pedidos podem utilizar a mesma cópia. Cada sequência continua a precisar do seu próprio estado de tokens e da sua própria cache de atenção.

Como é que os servidores de inferência lidam com pedidos simultâneos?

Diferentes runtimes disponibilizam diferentes controlos de agendamento, mas o princípio é semelhante: aceitar várias sequências, processar em lote sempre que possível e colocar os pedidos excedentes numa fila.

A FAQ do Ollama documenta os controlos de pedidos paralelos e indica que o contexto paralelo aumenta os requisitos de memória. O exemplo de processamento paralelo do llama.cpp demonstra vários clientes simulados a utilizar um único servidor de modelos.

Servidores com maior débito, como o vLLM, utilizam processamento em lote e agendamento sensível à cache KV para manter os aceleradores ocupados com várias sequências recebidas.

Porque é que o comprimento do contexto pode consumir mais memória do que outro utilizador sugere

Suponha que os pesos do modelo cabem confortavelmente na VRAM. Quatro utilizadores abrem, cada um, uma conversa muito longa. Os pesos não quadruplicam, mas a cache KV pode aumentar substancialmente para cada sequência ativa.

orçamento de VRAM
  |
  +-- pesos do modelo      fixos
  +-- cache KV do utilizador A    aumenta com o contexto
  +-- cache KV do utilizador B    aumenta com o contexto
  +-- cache KV do utilizador C    aumenta com o contexto
  +-- sobrecarga do runtime

É por isso que “o modelo cabe” não é suficiente para planear a capacidade. Os sistemas multiutilizador devem definir um comprimento máximo de contexto, um número máximo de sequências simultâneas e uma fila limitada.

O guia existente da ZimaSpace sobre agendamento de aceleradores para IA doméstica multiutilizador aprofunda o mesmo limite de recursos.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Cada utilizador deve ter um processo de modelo dedicado?

Normalmente, não. Processos separados duplicam os pesos e reduzem o número de modelos que cabem na memória. Ainda assim, podem fazer sentido quando:

• os utilizadores precisam de ajustes finos ou quantizações diferentes;
• um isolamento forte entre processos é mais importante do que a eficiência;
• uma carga de trabalho utiliza um ambiente de execução personalizado;
• pretende uma alocação rígida de GPU por utilizador;
• um modelo tem requisitos incompatíveis de contexto ou amostragem.

Para uma família ou uma pequena equipa que utilize o mesmo modelo, um único serviço de inferência por trás de uma aplicação autenticada é geralmente mais simples.

Mantenha a memória da conversação fora do servidor de modelos

O servidor de inferência não deve ser a base de dados de referência para saber “quem disse o quê”. Armazene o histórico das conversas e as preferências dos utilizadores na camada da aplicação, sob um ID explícito de utilizador/sessão.

Navegador / aplicação
    |
    | user_id autenticado
    v
Aplicação de chat
    |
    +-- base de dados do histórico (por utilizador)
    +-- permissões RAG
    |
    v
Servidor de modelos partilhado

Antes de cada geração, a aplicação reúne apenas o histórico e o contexto privado de recuperação que o utilizador atual tem autorização para consultar.

Isto é especialmente importante para um assistente de IA privado num NAS, onde o mesmo servidor pode conter documentos pessoais pertencentes a vários membros do agregado familiar.

A colocação em cache de prefixos partilhados não é memória de conversação partilhada

Alguns ambientes de execução podem reutilizar a cache KV ou outro trabalho para prefixos de pedidos comuns. Assim, uma instrução de sistema partilhada ou um prefixo de documento repetido pode ser calculado uma vez e reutilizado de forma eficiente.

Essa otimização não deve ser confundida com permitir que o contexto privado de um utilizador entre no pedido de outro utilizador. Os sistemas de cache precisam de um isolamento correto e de uma semântica de hashing adequada; as permissões da aplicação continuam a determinar que conteúdo pode ser fornecido a um pedido.

Utilize um agendamento justo para impedir que um utilizador ocupe o servidor

Um único pedido que solicite uma saída muito longa pode consumir a capacidade de descodificação enquanto os outros utilizadores esperam. Adicione controlos de admissão, como:

• limite de pedidos simultâneos por utilizador;
• número máximo de tokens de saída;
• janela de contexto máxima;
• máximo global de sequências ativas;
• tempo limite da fila;
• prioridade para pedidos interativos curtos;
• fila de lotes separada para tarefas em segundo plano.

O chat interativo e o resumo de documentos durante a noite não devem competir com uma política de agendamento idêntica.

O que acontece quando o servidor fica sem memória?

Um bom serviço rejeita ou coloca novos trabalhos na fila antes de o acelerador falhar. Os controlos de capacidade devem utilizar o contexto realmente configurado, e não apenas uma média otimista.

Não reduza silenciosamente a janela de contexto de todos os utilizadores até o servidor deixar de falhar. Torne a política de contexto visível, para que os utilizadores saibam o que o sistema pode conservar.

A privacidade e a autenticação são ainda mais importantes no modo multiutilizador

Quando um modelo serve um único administrador, um endpoint acessível apenas através do localhost pode ser suficiente. Assim que várias pessoas o utilizarem, a aplicação deve autenticar os utilizadores e autorizar as respetivas fontes de dados.

Proteja:

• históricos de chat;
• coleções RAG e ACLs de documentos;
• prompts guardados;
• credenciais de ferramentas;
• ficheiros gerados;
• registos e rastreios.

Um processo de modelo partilhado deve ver apenas o contexto do pedido atual e não deve tornar-se uma forma conveniente de contornar o modelo normal de permissões do NAS.

Quantos utilizadores pode suportar um servidor de IA doméstico?

Não existe um número fixo útil. Um servidor pode suportar muitos utilizadores registados se apenas um ou dois estiverem ativos, enquanto dois utilizadores concorrentes com contextos longos podem esgotar uma GPU pequena.

Avalie três cenários:

1. um utilizador interativo;
2. a carga doméstica simultânea esperada;
3. um utilizador intensivo e vários pedidos curtos.

Meça o tempo até ao primeiro token, os tokens por segundo por utilizador, o tempo na fila, a utilização da cache KV, a utilização de RAM/VRAM e a taxa de falhas dos pedidos.

Perguntas frequentes

Os utilizadores verão as conversas uns dos outros porque o modelo é partilhado?

Não, se a aplicação mantiver separados o histórico da conversa e o contexto de recuperação. Partilhar os pesos do modelo não partilha inerentemente o histórico do chat.

A inferência paralela torna cada utilizador mais rápido?

Pode aumentar o débito total, mas cada pedido individual pode receber menos capacidade de computação quando várias sequências estão ativas. O objetivo é normalmente obter um melhor serviço agregado e reduzir o tempo de espera na fila.

Um servidor pode alojar também vários modelos?

Sim, se a memória o permitir. Alguns runtimes carregam e descarregam modelos conforme necessário, enquanto outros são concebidos em torno de um ou vários processos persistentes de disponibilização. O agendamento de vários modelos acrescenta outra camada de capacidade para além do agendamento multiutilizador.

Veredicto final

\Um modelo carregado é exatamente o recurso que um pequeno serviço de IA doméstico deve normalmente partilhar.\ Mantenha os pesos do modelo comuns, isole o histórico das sessões e o estado KV, autentique todos os utilizadores, limite o contexto e a concorrência e agende o trabalho em segundo plano separadamente do chat interativo. A IA multiutilizador torna-se fiável quando planeia o estado por sessão e o comportamento da fila, em vez de multiplicar o processo do modelo.