Porque é que os trabalhos de criação de embeddings tornam o chat interativo de IA doméstica mais lento?
Os trabalhos de embeddings tornam mais lento o chat interativo de IA em casa, porque os lotes longos em segundo plano competem com o chat pelo tempo do acelerador, pela preparação do CPU, pela memória e pelo acesso ao armazenamento.
Uma base de conhecimento pessoal pode dividir milhares de documentos em fragmentos, tokenizá-los, executar um modelo de embeddings, normalizar vetores e gravar índices durante minutos ou horas. Os pedidos de chat chegam de forma imprevisível e precisam de um tempo reduzido até ao primeiro token, enquanto o pipeline de embeddings prefere lotes grandes que maximizem o débito. Se ambas as cargas de trabalho partilharem a mesma GPU, CPU, memória RAM ou dispositivo NVMe, o trabalho em segundo plano pode ocupar as filas antes de o pedido do utilizador chegar ao modelo. As secções abaixo analisam cada ponto de contenção e mostram como proteger a capacidade de resposta interativa.
Os pipelines de embeddings são cargas de trabalho em lotes longos
A ingestão de documentos envolve mais do que uma chamada ao modelo. Enumera ficheiros, extrai texto, divide o conteúdo em fragmentos, tokeniza lotes, calcula vetores e persiste metadados e estruturas de índice.
Os lotes grandes melhoram o débito dos lotes, mas podem prolongar o intervalo até que um pedido sensível à latência receba tempo do acelerador.
Por isso, uma importação inicial da biblioteca ou uma reindexação completa é muito diferente de gerar embeddings para uma única nota nova depois de a guardar.
O prefill do chat e o cálculo de embeddings competem pelo mesmo acelerador
O chat interativo começa com o prefill do pedido, que exige bastante capacidade de cálculo. Os modelos de embeddings também processam sequências completas de tokens através de camadas transformer, frequentemente em grandes lotes paralelos.
A investigação sobre interferência do prefill mostra por que motivo um cálculo intensivo semelhante ao processamento de pedidos pode tornar mais lenta a descodificação simultânea e o serviço do primeiro token.
Se o runtime não interromper nem der prioridade ao chat, uma pergunta curta pode ficar à espera atrás do lote de embeddings em curso, mesmo que o próprio modelo de chat já esteja carregado.
Lotes de embeddings mais pequenos reduzem o intervalo máximo de bloqueio, mas podem diminuir o débito total da ingestão.
Modelos separados aumentam a pressão sobre a memória
O modelo de chat, o modelo de embeddings, o reranker e o runtime vetorial podem manter residentes os pesos e as pools do alocador. O espaço ocupado em conjunto reduz a capacidade disponível para a cache KV do chat e para utilizadores simultâneos.
O artigo da ZimaSpace sobre contenção da memória do acelerador explica por que motivo uma baixa utilização de cálculo não significa que exista memória suficiente para um pedido interativo.
Quando a memória fica limitada, o sistema pode reduzir a concorrência do chat, retirar um modelo da memória, descarregar camadas ou iniciar um recarregamento a frio depois de terminar a fase de embeddings.
Em algumas arquiteturas, é possível utilizar um único codificador partilhado para a recuperação e o chat, mas os modelos separados e específicos para cada tarefa produzem frequentemente melhores resultados e implicam custos de memória distintos.
O processamento no CPU e no armazenamento pode atrasar a recuperação antes da inferência
A tokenização, a análise de PDFs, o OCR, a criação de hashes e as gravações na base de dados vetorial podem saturar os threads do CPU e gerar E/S aleatória no mesmo armazenamento utilizado pelos ficheiros dos modelos e pelo histórico do chat.
A indexação em segundo plano cria contenção da indexação, mesmo quando nenhum gráfico de CPU visível para o utilizador parece estar totalmente saturado.
A recuperação do chat pode então ficar à espera de bloqueios da base de dados, falhas de cache ou de uma fila NVMe ocupada antes de o pedido ser preparado.
As regras de prioridade e admissão protegem o chat
Agende a ingestão em lotes limitados, faça pausas entre lotes, limite a sua concorrência e só admita novo trabalho em segundo plano quando as filas interativas estiverem vazias ou abaixo de um determinado limiar.
O Llumnix utiliza prioridades dinâmicas para gerir pedidos com diferentes requisitos de latência e recursos.
Um servidor doméstico pode implementar uma política mais simples: o chat e a voz recebem admissão imediata, enquanto os embeddings são executados com prioridade inferior ou durante janelas de manutenção.
Meça a interferência em vez de adivinhar
Registe o tempo do chat até ao primeiro token, o intervalo entre tokens, a latência da recuperação, os fragmentos de embeddings por segundo, a memória da GPU, a saturação do CPU e a latência do armazenamento com o trabalho de embeddings desativado e ativado.
Se o chat só esperar nos limites dos lotes, reduza o tamanho dos lotes ou ative a preempção. Se surgirem recarregamentos de modelos, reduza o número de modelos residentes ou separe os workers. Se a recuperação ficar bloqueada, mova as gravações do índice ou os ficheiros dos modelos para outro caminho de E/S.
O objetivo útil não é a reindexação mais rápida possível. É obter a maior taxa de ingestão em segundo plano que mantenha a latência interativa da casa dentro do seu intervalo normal.
Depois de criar a biblioteca, substitua as análises completas recorrentes pela deteção incremental de alterações, para que a carga de trabalho em segundo plano permaneça proporcional ao conteúdo novo.
FAQ
Um modelo de embeddings separado torna sempre o chat mais lento?
Não. Pode permanecer inativo ou ser executado noutro dispositivo. A lentidão surge quando os caminhos de cálculo, memória, CPU, armazenamento ou agendamento se sobrepõem.
Reduzir o tamanho do lote de embeddings ajuda sempre?
Reduz a duração de cada intervalo de bloqueio, mas pode aumentar a sobrecarga e o tempo total de ingestão. A prioridade e a preempção podem preservar uma maior capacidade de processamento.
Os embeddings devem ser executados durante a noite?
As importações grandes frequentemente devem ser. As atualizações incrementais podem ser executadas durante o dia, desde que sejam limitadas e cedam prioridade aos pedidos interativos.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Que funcionalidades permitem criar um limite de confiança de IA doméstico em torno de ficheiros sensíveis?
Uma fronteira de confiança para IA doméstica combina encriptação em repouso, permissões de privilégio mínimo, sandboxing em tempo de execução e recuperação com âmbito...
O que faz com que os resultados de pesquisa privada favoreçam ficheiros editados com frequência?
Os ficheiros editados frequentemente obtêm vantagens no posicionamento quando cada atualização acrescenta sinais de atualidade, fragmentos, versões ou interação, sem normalização por fonte.
O que faz com que os modelos de presença de casas inteligentes confundam visitantes com residentes?
Os visitantes podem parecer residentes quando o sistema observa padrões de atividade doméstica, mas não dispõe de um sinal de identidade estável da pessoa...
