Como é que o tamanho do lote afeta a latência do primeiro token e por token?
Lotes maiores melhoram frequentemente o débito total de tokens, mas podem aumentar o atraso até ao primeiro token e a latência por token devido ao enfileiramento, a iterações mais pesadas e à pressão sobre a memória.
Um modelo local com lote um pode subutilizar o acelerador, porque cada passo de descodificação transfere os pesos do modelo para realizar muito pouco trabalho. Combinar pedidos amortiza essa transferência e aumenta o débito. No entanto, os pedidos podem aguardar admissão, os prefills longos podem bloquear as descodificações e cada sequência ativa acrescenta cache KV e trabalho de processamento de tokens, pelo que o melhor lote depende de o objetivo ser o débito, a capacidade de resposta ou o goodput dentro de um objetivo de latência.
O batching amortiza o trabalho do modelo entre pedidos
Uma operação matricial em lote processa tokens de várias sequências em conjunto, melhorando a ocupação do hardware e distribuindo os custos fixos de lançamento ou transferência de pesos por mais trabalho útil. Os ganhos são maiores antes de a computação, a largura de banda da memória, a capacidade da cache ou a sobrecarga do escalonamento ficarem saturadas.
O escalonamento ao nível da iteração do Orca introduz um escalonamento ao nível da iteração, permitindo que as sequências concluídas saiam e que novo trabalho entre entre iterações de descodificação. Isto evita obrigar todos os pedidos a esperar pelo membro mais demorado de um lote estático.
O tamanho do lote pode significar o máximo configurado, as sequências admitidas ou os tokens processados numa iteração. Esses valores diferem com o batching contínuo, pelo que os relatórios de desempenho devem indicar qual foi a quantidade controlada e observada. Esta distinção continua visível durante os testes domésticos posteriores.
A latência até ao primeiro token inclui o enfileiramento e o prefill
O tempo até ao primeiro token começa quando chega um pedido e inclui a espera pelo escalonador, o prefill do prompt e o primeiro passo de descodificação. Uma política que aguarde para formar um lote pode aumentar o tempo de fila, enquanto a admissão de um prompt grande pode ocupar uma iteração e atrasar pedidos interativos já existentes.
Uma comparação atual de batching contínuo explica como o batching contínuo admite e remove pedidos dinamicamente e como um escalonamento agressivo estabelece um compromisso entre o débito e o TTFT. Esclarece por que motivo o tamanho do lote, por si só, não consegue prever a capacidade de resposta até ao primeiro token. O resultado intermédio deve continuar a ser inspecionável antes de a automação prosseguir.
O prefill segmentado pode intercalar prompts longos com trabalho de descodificação, mas o tamanho dos segmentos torna-se outra variável de compromisso. Segmentos pequenos protegem os tokens interativos, mas acrescentam sobrecarga de escalonamento; segmentos grandes melhoram a eficiência do prefill, ao mesmo tempo que criam intervalos de bloqueio mais longos. Esse limite deve ser medido separadamente em condições de funcionamento realistas.
A latência por token depende da iteração ativa
Durante a descodificação, cada passo produz geralmente um token por sequência ativa. Mais sequências aumentam o lote e podem prolongar a duração de cada iteração, mesmo quando o número agregado de tokens por segundo aumenta. Contextos de tamanhos diferentes, pressão sobre a cache, preempção e sincronização distribuída acrescentam variabilidade.
O DistServe separa o prefill da descodificação, porque estes têm características computacionais e objetivos de serviço diferentes. O design ilustra por que motivo a otimização do débito agregado pode entrar em conflito tanto com o TTFT como com o tempo por token de saída. A consequência prática surge quando várias fontes competem por um contexto limitado.
O limite de falha consiste em selecionar o maior lote a partir de um gráfico de débito obtido offline para um assistente doméstico interativo. Se o enfileiramento ou os intervalos entre tokens violarem o objetivo voltado para o utilizador, o débito nominal não constitui goodput utilizável, independentemente da utilização do acelerador.
Mapeie a fronteira de goodput dos lotes
Reproduza conversas curtas, prompts RAG longos e tarefas em segundo plano com taxas de chegada controladas. Varra o número máximo de sequências e os limites de tokens em lote, medindo os percentis de TTFT, a latência entre tokens, a latência de ponta a ponta, o débito de prompts e de saídas, a profundidade da fila, a utilização da cache, a preempção e os pedidos rejeitados.
Use o comportamento do batching contínuo para distinguir os limites configurados do lote efetivamente observado em cada iteração. Mantenha fixas as distribuições de prompts e saídas e indique a percentagem de pedidos que cumpre simultaneamente os objetivos relativos ao primeiro token e aos intervalos entre tokens.
Escolha a configuração que maximize o trabalho concluído dentro desses objetivos, em vez do número bruto de tokens por segundo. Isole ou atribua menor prioridade aos lotes em segundo plano quando estes reduzirem o goodput interativo e repita os testes após alterações ao modelo, à quantização, à combinação de contextos ou ao escalonador.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Um LLM local pode retomar a geração depois de o seu processo reiniciar?
Uma explicação da retoma da geração de LLM baseada primeiro no mecanismo, das suas concessões em termos de recursos partilhados, de três perguntas frequentes...
Pode um servidor doméstico executar embeddings e transcodificação de vídeo na mesma GPU integrada?
Uma explicação baseada primeiro no mecanismo dos embeddings partilhados da iGPU e da transcodificação, das suas cedências em termos de recursos partilhados, três perguntas...
Como é que o tempo de vida do token de acesso afeta a segurança e o atrito no agregado familiar?
Uma explicação baseada primeiro no mecanismo da duração dos tokens de acesso, os compromissos relativos aos recursos partilhados, três perguntas frequentes sobre a propagação...
