Porque é que as respostas dos LLM locais ficam mais curtas sob carga simultânea?

As respostas de LLM locais tornam-se mais curtas sob carga quando a camada de disponibilização troca orçamento de geração por simultaneidade através de limites, prazos, preempção ou pedidos falhados.

O modelo não decide inerentemente ser conciso porque chegou outro utilizador. Com um prompt e um estado de amostragem fixos, a simultaneidade deveria alterar sobretudo o tempo de espera na fila e o tempo dos tokens. Respostas mais curtas indicam que o runtime, o gateway, o cliente ou o gestor de memória alterou uma condição efetiva de paragem, cancelou trabalho ou devolveu um fluxo parcial depois de a pressão ultrapassar um limiar.

A simultaneidade expande a memória KV e ativa limites de disponibilização

Cada sequência ativa mantém blocos de cache KV que aumentam com o contexto retido e os tokens gerados. Quando vários pedidos partilham um acelerador, o runtime pode reduzir a saída máxima, rejeitar a admissão, efetuar a preempção de uma sequência ou trocar blocos para manter o lote dentro dos limites de memória.

Um sistema de disponibilização baseado em alocação paginada de cache KV utiliza blocos KV paginados para reduzir a fragmentação e permitir uma maior simultaneidade. O seu mecanismo melhora a capacidade, mas também torna claro que cada sequência ativa consome uma alocação de memória crescente até ser concluída ou removida.

Um gateway pode impor um orçamento de tokens separado por pedido ou global. Se esse orçamento for derivado da capacidade disponível, da prioridade ou da profundidade da fila, prompts idênticos recebem uma saída máxima diferente, apesar de os pesos do modelo e os parâmetros de amostragem parecerem inalterados.

Os prazos e a preempção podem devolver uma resposta parcial com aspeto válido

Os sistemas interativos aplicam frequentemente prazos de relógio, tempos-limite de fluxo inativo ou cancelamento pelo cliente. A entrega mais lenta entre tokens sob carga atinge esses limites mais cedo na resposta semântica e algumas APIs devolvem os tokens já emitidos em vez de um erro evidente.

O método de prefill dividido em blocos separa o processamento do prompt em blocos mais pequenos para impedir que prefills longos bloqueiem a descodificação. Este trabalho demonstra como as alterações de escalonamento afetam o tempo até ao primeiro token e a latência entre tokens sob pressão de pedidos mistos. Esta distinção continua visível durante os testes domésticos posteriores.

A preempção pode preservar um pedido para retoma posterior, reiniciá-lo ou abortá-lo, dependendo do motor. Se o cliente se desligar durante a pausa, o servidor pode registar um cancelamento enquanto a interface apresenta um prefixo gramatical mas incompleto como uma resposta concluída.

A amostragem, por si só, não deve apresentar uma correlação fiável com a carga

A descodificação estocástica produz naturalmente comprimentos variáveis quando a temperatura e a semente aleatória diferem. Essa variação pode coincidir com a carga em amostras pequenas, mas a simultaneidade não possui um sinal semântico direto, a menos que o estado partilhado, uma política adaptativa ou um erro de software altere o caminho de descodificação.

A investigação sobre escalonamento consciente dos SLO modela o encaminhamento e o escalonamento, protegendo simultaneamente os objetivos de tempo entre tokens. A separação entre débito, TTFT e prazos de descodificação mostra por que motivo a política de capacidade deve ser medida independentemente da qualidade da saída do modelo. O resultado intermédio deve continuar a ser inspecionável antes de a automatização avançar.

A fronteira da falha consiste em culpar o escalonador antes de verificar os metadados de paragem. Os tokens de fim de sequência, os limites de comprimento explícitos, os cancelamentos pelo cliente, os prazos do servidor, os erros OOM e as desconexões do transporte são causas diferentes. Apenas alterações repetidas e controladas do comprimento, com motivos de paragem correspondentes, sustentam um mecanismo relacionado com a carga.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Compare o comprimento e o motivo de paragem em níveis fixos de simultaneidade

Reproduza prompts e sementes fixos com um, dois, quatro e oito pedidos simultâneos. Registe os tokens máximos solicitados, os tokens de saída efetivos, o motivo de conclusão, o tempo na fila, o TTFT, a latência entre tokens, o prazo do relógio, a desconexão do cliente, o número de preempções, os bytes KV, a VRAM livre e o erro do servidor.

Relacione o comportamento da memória com os limites de carga de trabalho simultânea e, em seguida, repita sem tempos-limite do gateway e com um limite de admissão fixo. Preserve os prompts, os modelos, a amostragem e o código do cliente, para que a única alteração pretendida seja a simultaneidade. Essa fronteira deve ser medida separadamente em condições de funcionamento realistas.

Trate a saída mais curta como um defeito de disponibilização quando a taxa de conclusão ou a cobertura semântica diminuir antes do orçamento anunciado. Se apenas a latência aumentar enquanto os motivos de conclusão permanecerem EOS, recolha mais testes com sementes fixas; se predominarem os tempos-limite ou os limites, exponha e dimensione essas políticas explicitamente.