O que é o processamento contínuo em lotes e quando é relevante para um servidor de IA doméstico?

O batching contínuo agenda sequências ativas em cada iteração de descodificação, permitindo que novos pedidos entrem e que os pedidos concluídos saiam sem esperar por um lote fixo.

Uma família pode enviar um pedido de voz, uma pergunta sobre um documento e um pedido de programação para um único modelo local em poucos segundos. Os prompts e os comprimentos das respostas são diferentes, pelo que um lote fixo desperdiça posições enquanto as respostas mais curtas aguardam pela mais longa. O batching contínuo mantém o trabalho útil em torno do modelo, mas só é relevante quando os pedidos se sobrepõem e o servidor dispõe de memória e margem de escalonamento suficientes.

O escalonamento ao nível da iteração é a ideia fundamental

A descodificação autorregressiva faz avançar cada sequência ativa aproximadamente um token por iteração do modelo. Um escalonador contínuo seleciona as sequências executáveis para a iteração seguinte, admite novos pedidos quando há capacidade disponível e remove as sequências imediatamente após a conclusão.

O artigo da Orca introduziu o escalonamento ao nível da iteração, com uma granularidade baseada nas iterações do modelo e não em pedidos completos. O batching seletivo agrupa depois operações compatíveis, mantendo separado o trabalho específico de cada pedido. Esta distinção continua visível durante os testes domésticos posteriores.

Isto não é o mesmo que transmitir tokens a um utilizador. A transmissão altera o momento em que o resultado é entregue; o batching contínuo altera a forma como vários pedidos partilham internamente a execução do modelo. O resultado intermédio deve continuar a ser inspecionável antes de a automatização prosseguir.

É diferente do batching estático e do batching por janela de chegada

O batching estático fixa um grupo e mantém-no unido, preenchendo frequentemente as sequências mais curtas até a mais longa terminar. O batching por janela de chegada, ou batching dinâmico, espera brevemente para reunir pedidos, mas pode continuar a executar o grupo resultante como uma única unidade. O batching contínuo reavalia a composição em cada iteração.

O artigo sobre vLLM combina o escalonamento ao nível da iteração com a gestão paginada da cache KV, para que as alterações aos conjuntos de sequências não exijam reservas contíguas rígidas. O escalonamento e a gestão da memória são funcionalidades complementares, não intercambiáveis. Essa fronteira deve ser medida separadamente em condições de funcionamento realistas.

Mais sequências ativas amortizam as leituras dos pesos e podem melhorar o débito, mas cada pedido compete pela memória KV e pela capacidade de computação. Um lote ativo maior não é automaticamente melhor para a latência ou a equidade. A consequência prática torna-se evidente quando várias fontes competem por um contexto limitado.

É a simultaneidade, não apenas o tamanho do modelo, que cria o benefício

Um único utilizador interativo pode observar poucos ganhos, porque não existe um segundo pedido disponível para preencher a capacidade não utilizada. Os benefícios surgem com utilizadores domésticos sobrepostos, ramificações de agentes, resumos em segundo plano ou várias aplicações que partilham um modelo residente.

O Sarathi-Serve analisa como a interferência do prefill pode perturbar a latência da descodificação e utiliza prefills repartidos em blocos para tornar mais previsível o escalonamento misto. O resultado mostra que a política de admissão é importante, além da designação de batching contínuo. Esta dependência deve permanecer explícita na interface final.

O limite de falha é atingido com pressão sobre a memória ou uma admissão agressiva que aumenta o tempo por token de saída e a latência de cauda. Quando a cache KV fica cheia, a preempção, a troca ou a recomputação podem eliminar os ganhos de débito e tornar instável o serviço interativo.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Determine se a procura simultânea o justifica

Reproduza um, dois, quatro e oito pedidos sobrepostos com comprimentos realistas de prompt e de saída. Registe o débito, o tempo até ao primeiro token, o tempo por token de saída, o tempo de conclusão p95, a utilização da KV, as preempções e a equidade por classe de pedido.

Compare o comportamento com as lacunas do batching contínuo. Repita com o batching contínuo desativado ou com uma referência de lote fixo, mantendo constantes o modelo, a quantização, os limites de contexto e o hardware. O resultado deve, por isso, ser verificado em relação à evidência original.

Utilize batching contínuo quando a sobreposição produzir ganhos materiais de débito ou capacidade sem violar a latência de cauda interativa. Se os pedidos raramente se sobrepuserem, dê prioridade à residência do modelo e à latência de arranque antes de acrescentar complexidade ao escalonador. Esta distinção continua visível durante os testes domésticos posteriores.