Quantos utilizadores simultâneos pode servir um modelo de IA doméstico antes de a latência se tornar instável?
Um modelo de IA doméstico pode servir de forma fiável entre um e vários utilizadores interativos, mas o limite estável depende da procura de tokens, do batching e dos objetivos de latência.
Um modelo que produz 30 tokens por segundo pode parecer rápido num chat curto com uma pessoa, mas ficar bloqueado quando quatro pessoas enviam prompts longos em simultâneo. A simultaneidade consome memória de cache KV, partilha a capacidade de descodificação e cria picos de filas de espera. O limite correto é a carga oferecida máxima que continua a cumprir um objetivo p95 definido para o primeiro token e para a taxa de tokens durante a utilização normal da família.
A simultaneidade transforma o débito em tempo de espera
Uma estimativa aproximada da capacidade divide o débito sustentado de geração pelo número médio de tokens solicitados por segundo nas sessões ativas. Quando a procura se aproxima da capacidade do serviço, pequenos picos criam filas longas. Os utilizadores não são unidades idênticas; uma resposta de 50 tokens e uma resposta de 2 000 tokens ocupam o servidor de forma diferente.
Uma análise da latência e do débito explica que o batching melhora o débito agregado, muitas vezes à custa da latência de resposta individual. Essa tensão determina se as sessões adicionais parecem estáveis.
O prefill do prompt também pode bloquear o trabalho de descodificação, dependendo do agendador. Dois utilizadores que colem documentos grandes podem prejudicar mais todos os outros do que seis utilizadores a fazer perguntas curtas. Por isso, uma contagem de utilizadores sem distribuições de prompts e de resultados não é transferível.
A cache KV e o agendamento criam um segundo limite
Cada sequência ativa armazena as chaves e os valores de atenção do seu contexto. Históricos mais longos e batches maiores aumentam a utilização da cache KV até que os pedidos sejam rejeitados, trocados ou atrasados. O batching contínuo pode aceitar novo trabalho entre iterações de descodificação, melhorando a utilização, mas não cria memória adicional.
Uma explicação técnica do batching contínuo mostra como o agendamento ao nível das iterações preenche espaços de batch que, de outro modo, ficariam inativos. O benefício depende da carga de trabalho e pode aumentar ligeiramente a contenção por pedido.
A latência torna-se instável perto da saturação porque o comprimento da fila reage de forma acentuada à variância das chegadas. A latência média pode aumentar gradualmente, enquanto a latência p95 e a latência máxima disparam. A capacidade estável deve ficar abaixo desse ponto de inflexão, e não no ponto máximo de tokens por segundo do benchmark.
Onde a contagem de utilizadores deixa de prever a experiência
O mesmo servidor pode suportar mais utilizadores para preenchimento automático do que para RAG, utilização de ferramentas ou geração de texto longo. Arranques a frio, limitação térmica, recuperação e síntese de voz acrescentam etapas fora do serviço do modelo. Um valor de simultaneidade apenas do modelo não pode garantir a capacidade de resposta de toda a aplicação.
Um guia de serviço sobre memória de serviço descreve a memória, o contexto, o batching e o paralelismo como restrições interligadas. Alterar qualquer uma delas pode deslocar o ponto de inflexão da capacidade.
A previsão também falha se os pedidos da família chegarem em picos sincronizados, em vez de forma independente. Quatro utilizadores que raramente se sobrepõem podem ser fáceis de suportar, enquanto dois agentes automatizados podem saturar continuamente o modelo. Meça o trabalho oferecido, não as contas registadas.
Encontre o ponto de inflexão da simultaneidade com um teste de carga
Reproduza pedidos curtos, medianos e longos realistas com uma, duas, quatro e oito sessões simultâneas. Mantenha fixos o modelo, a quantização, o limite de contexto e a amostragem. Registe o tempo em fila, a latência do primeiro token, a latência entre tokens, a taxa de conclusão, a utilização da cache KV e os valores p50, p95 e máximos.
Utilize a arquitetura de sessões de modelo partilhadas como contexto de teste quando várias sessões domésticas partilham um modelo. Mantenha as etapas de RAG e de utilização de ferramentas desativadas ou cronometre-as separadamente.
Declare o limite estável como a simultaneidade máxima cuja latência p95 do primeiro token se mantém dentro do objetivo doméstico, sem tendência crescente da fila nem erros de memória. Mantenha uma margem de débito de 20–30% para os picos. Repita o teste sempre que alterar o comprimento do contexto, o modelo ou o agendador.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Como medir a qualidade da recuperação RAG local e interpretar a cobertura da recuperação, da precisão e das citações
Crie um conjunto de teste RAG local, calcule as principais métricas de recuperação, interprete os seus compromissos e audite se as afirmações das respostas...
Porque é que a computação das funcionalidades de casa inteligente se torna mais importante à medida que aumenta o número de sensores à mesma taxa de amostragem?
Monitorize o processamento por sensor e entre sensores à medida que o número de dispositivos aumenta, identifique os custos não lineares da fusão e...
Porque é que o custo da avaliação de RAG se torna mais importante à medida que a biblioteca de documentos cresce, com o mesmo volume de consultas?
Compreenda por que o crescimento do corpus aumenta o esforço de avaliação do RAG sem mais consultas dos utilizadores e como os testes estratificados...
