Porque é que um servidor de IA doméstico pode parecer rápido para um utilizador, mas não para uma família?
Um servidor de IA doméstico pode parecer rápido para um utilizador, mas lento para uma família porque os pedidos concorrentes partilham computação, memória e tempo de agendamento.
A diferença aparece quando uma pessoa envia um prompt de chat curto durante um período ocioso, e depois vários membros da família começam conversas longas, resumos de documentos, análise de imagens, tarefas de voz ou fluxos de trabalho de agentes ao mesmo tempo. Um teste de utilizador único revela principalmente a latência do modelo aquecido; o uso familiar adiciona filas de espera, comprimentos mistos de prompts, caches de conversação separados, fases concorrentes de pré-preenchimento e decodificação, e comprimentos de saída imprevisíveis. As secções abaixo explicam como a camada de serviço converte essas diferenças em tokens iniciais mais lentos, geração irregular e maior pressão de memória.
O Agendador é a Camada de Controlo por trás dos Pedidos Familiares
Um modelo local não responde a cada utilizador independentemente a partir de uma cópia nova do hardware. Um processo de serviço recebe pedidos, decide quando cada prompt pode entrar no modelo, agrupa trabalho compatível e atribui tempo e memória limitados do acelerador a conversas ativas.
Os sistemas modernos usam agendamento de pedidos para equilibrar prompts heterogéneos, migrar trabalho e distinguir prioridades de latência. Num servidor doméstico com uma GPU ou memória do sistema partilhada, esse agendador não pode criar nova capacidade; apenas decide como a capacidade existente é dividida.
É por isso que duas interfaces ligadas ao mesmo modelo podem parecer diferentes mesmo na mesma rede. Um pedido que chega a uma fila vazia começa rapidamente, enquanto um pedido igualmente curto pode esperar atrás de um prompt longo, uma imagem grande ou a resposta prolongada de outro utilizador.
Por que um utilizador pode fazer o servidor parecer mais rápido do que realmente é
Um teste de utilizador único geralmente decorre em condições favoráveis: o modelo já está carregado, o acelerador está ocioso, nenhum outro contexto ocupa a memória cache, e o pedido começa sem fila de espera. O resultado visível é um tempo baixo até ao primeiro token e uma geração estável de tokens.
O serviço LLM tem um compromisso documentado entre rendimento e latência. O agrupamento pode melhorar o trabalho total concluído, mas o aumento da carga também pode aumentar o atraso experimentado por um pedido individual, especialmente quando o servidor mistura o processamento do prompt com a geração em curso.
O benchmark responde, portanto, “Quão responsivo é este modelo quando quase todos os recursos pertencem a um único pedido?” Não responde “Quantos pedidos familiares podem cumprir o mesmo objetivo de tempo de resposta?”
Um teste de capacidade útil deve adicionar utilizadores gradualmente e medir o atraso do primeiro token, o tempo entre tokens, o tempo na fila, o uso de memória e a taxa de conclusão, em vez de reportar um único número de tokens por segundo no melhor caso.
Pré-preenchimento e Decodificação Competem de Formas Diferentes
Cada pedido começa com o pré-preenchimento, que processa o prompt de entrada e constrói o estado necessário para a geração. A decodificação produz então tokens de saída um de cada vez. Um documento ou conversa longa pode tornar o pré-preenchimento pesado em termos de computação, enquanto várias respostas ativas retornam repetidamente à decodificação.
A pesquisa sobre pré-preenchimento e decodificação mostra que a colocação conjunta de ambas as fases pode criar interferência e acoplar a sua latência. Em casa, uma pessoa a colar um documento longo pode atrasar outra que já está a receber uma resposta, mesmo que os seus pedidos tenham formatos diferentes.
A família observa dois sintomas. Novos utilizadores podem esperar mais tempo pelo primeiro token, enquanto utilizadores ativos podem notar pausas irregulares entre tokens posteriores. O rendimento médio pode permanecer aceitável mesmo quando a experiência interativa se torna inconsistente.
Cada Conversa Consome a Sua Própria Capacidade de Cache KV
Após o pré-preenchimento, o servidor mantém tensores de chave e valor que representam tokens anteriores para não recalcular toda a conversa para cada novo token de saída. Conversas mais longas e mais utilizadores simultâneos expandem este conjunto de trabalho.
A pesquisa original do vLLM identifica a memória cache KV como um dos principais limites ao tamanho do lote e ao serviço concorrente. A paginação eficiente reduz o desperdício, mas cada contexto ativo ainda necessita de memória real em algum ponto do caminho de inferência.
Quando a memória GPU disponível, RAM partilhada ou memória do acelerador fica apertada, o servidor pode admitir menos pedidos, preemptar trabalho, encurtar limites de contexto, descarregar estado de cache ou expulsar outro modelo. Essas soluções podem transformar uma conversa única suave em picos de latência em toda a família.
A explicação relacionada da ZimaSpace sobre expulsão de modelo cobre um caso grave: cargas de trabalho ativas deslocam um modelo residente, pelo que o próximo pedido paga um custo de recarregamento e aquecimento antes de a geração normal recomeçar.
As cargas de trabalho familiares são desiguais, não apenas mais numerosas
Dois utilizadores não cortam necessariamente o desempenho exatamente pela metade. Um pode fazer uma pergunta factual curta enquanto outro fornece um PDF longo, pede uma resposta grande, executa reconhecimento de imagem ou lança um agente que faz chamadas repetidas ao modelo.
Os agendadores LLM devem lidar com custos desiguais de pedidos porque os comprimentos de prompt e saída variam de forma imprevisível. Sem limites ou agendamento justo, uma sessão pesada pode ocupar recursos de fila, cálculo e cache muito mais tempo do que várias conversas leves.
A tabela abaixo mostra por que o número de utilizadores sozinho é uma métrica de capacidade incompleta.
| Atividade Familiar | Recurso Principal Partilhado | Efeito Provável Visível |
|---|---|---|
| Vários chats curtos | Slots de decodificação e tempo do agendador | Menos tokens por segundo por utilizador |
| Um documento longo mais chats ativos | Latência de pré-preenchimento de cálculo e decodificação | Primeiro token lento e streaming irregular |
| Várias conversas longas | Memória cache KV | Enfileiramento, preempção ou limites de contexto mais curtos |
| Tarefas de texto, imagem e voz em conjunto | GPU, CPU, RAM e residência do modelo | Contenção entre cargas de trabalho e picos de latência |
| Modelos diferentes para utilizadores diferentes | Memória de peso e tempo de carregamento | Trocas de modelo ou atrasos na expulsão |
Um teste familiar deve, portanto, reproduzir a mistura real de chat, recuperação, visão, voz e automação. Cinco prompts curtos idênticos podem parecer saudáveis, enquanto um pedido de contexto longo mais duas conversas ativas expõem o limite real.
O que pode melhorar a capacidade de resposta da família?
Comece por manter um modelo adequado residente, reduzir o contexto máximo desnecessário, limitar saídas longas e atribuir regras justas de concorrência ou fila. Um modelo mais pequeno pode às vezes servir melhor uma família do que um modelo maior que quase não deixa memória para contextos ativos.
O limite de implantação do ZimaSpace para utilizadores de IA concorrentes é o mesmo princípio em maior escala: pesos do modelo, contextos ativos, tamanho do lote e estratégia de serviço devem todos caber no hardware em conjunto. O armazenamento pode conter um ponto de verificação, mas a inferência interativa rápida depende de onde os pesos e o estado ativo residem durante o uso.
Agrupamento contínuo, reutilização de prefixos, cache KV paginada, prioridades de pedidos e réplicas de trabalhadores separadas podem melhorar a utilização ou justiça. O benefício é condicional: um ambiente orientado para rendimento pode fazer o servidor completar mais tokens totais enquanto permite que um utilizador espere mais tempo.
O hardware ainda define o limite máximo. Se a carga familiar esgotar a memória do acelerador, largura de banda de computação, pré-processamento da CPU ou réplicas disponíveis do modelo, o agendamento pode distribuir a escassez de forma mais justa, mas não a elimina.
Perguntas Frequentes
Dois utilizadores tornam sempre um servidor de IA doméstico duas vezes mais lento?
Não. O resultado depende do comprimento do prompt, comprimento da saída, agrupamento, tamanho do modelo, uso da cache e se os pedidos se sobrepõem. Dois pedidos curtos podem agrupar-se eficientemente, enquanto um pedido longo pode interferir com várias sessões mais leves.
Cada membro da família precisa de uma instância separada do modelo?
Normalmente não. Um processo de serviço multiutilizador pode partilhar pesos do modelo e agendar pedidos separados. Instâncias separadas podem melhorar o isolamento, mas também duplicam ou partem a memória e podem reduzir a capacidade total em hardware pequeno.
Uma rede mais rápida resolve a latência da IA multiutilizador?
Só quando a transferência de entrada, armazenamento remoto ou conectividade do cliente são o gargalo. A maioria das lentidões locais na geração de texto sob carga familiar vem de filas, computação, memória do modelo e pressão na cache KV.
Um modelo mais pequeno é melhor para uso familiar?
Pode ser. Um modelo mais pequeno pode deixar mais memória para contextos simultâneos e gerar mais rapidamente, mas a compensação na qualidade deve ainda corresponder às tarefas da família.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Porque é que as previsões da casa inteligente se tornam menos precisas após mudanças sazonais na rotina?
As rotinas sazonais alteram a relação entre o tempo, os sensores, a ocupação e as ações pretendidas, tornando obsoleto um modelo treinado com hábitos...
Porque é que um NVR doméstico não regista eventos breves quando o seguimento de objetos está ativado?
O seguimento precisa de deteções suficientes para iniciar e confirmar uma trajetória, pelo que um objeto que apareça brevemente pode desaparecer antes de o...
Porque é que as etiquetas de fotografias geradas por IA mudam após uma atualização do modelo?
Uma atualização do modelo altera a representação e a classificação utilizadas para atribuir etiquetas, pelo que a mesma fotografia pode ultrapassar diferentes limites semânticos...
