Como é que o batching contínuo afeta a equidade num servidor de IA doméstico?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

O batching contínuo melhora a utilização ao reabastecer os lotes ativos, mas a equidade depende da forma como os utilizadores obtêm admissão, serviço de tokens e memória ao longo do tempo.

Um servidor de IA doméstico pode combinar várias conversas sem esperar que todas as sequências terminem em conjunto. Os pedidos concluídos saem, entram novos pedidos e os utilizadores ativos partilham iterações de inferência repetidas. Isto aumenta o débito, mas os pedidos não são iguais: um utilizador pode enviar um comando curto, outro um documento longo e outro um agente que gera centenas de tokens. Um agendador equitativo tem de decidir que unidade de trabalho conta, como entram os novos pedidos e de que forma as prioridades interagem com comprimentos de saída imprevisíveis.

O batching contínuo altera a unidade de agendamento, passando de um lote fixo para iterações

O batching estático mantém um grupo unido até este terminar, desperdiçando capacidade quando os pedidos curtos terminam mais cedo. O batching contínuo pode reabastecer os espaços livres entre iterações de geração.

A Orca introduziu o agendamento ao nível das iterações, permitindo que os pedidos entrem e saiam à medida que o estado das respetivas sequências se altera.

Isto melhora a utilização, mas também significa que os utilizadores competem repetidamente por um lugar na iteração seguinte, em vez de receberem um espaço de pedido indivisível.

A ordem de admissão determina quem começa a acumular serviço

Um pedido fora do lote ativo não recebe qualquer progresso do modelo. O agendador pode admitir pedidos por ordem de chegada, comprimento estimado, prioridade, blocos KV disponíveis ou um contador de equidade.

O vLLM combina a admissão contínua com a gestão paginada da cache KV, para que a memória possa ser alocada à medida que as sequências crescem.

O primeiro a chegar é simples, mas uma fila de pedidos longos pode atrasar comandos domésticos curtos que chegam mais tarde, mesmo quando estes terminariam rapidamente.

Contar os pedidos de forma igual pode proporcionar um serviço desigual do acelerador

Uma resposta de cinco tokens e uma resposta de quinhentos tokens são ambas um pedido, mas ocupam números muito diferentes de iterações de descodificação. Os comprimentos dos prompts também geram diferentes quantidades de trabalho de pré-preenchimento.

O Virtual Token Counter define a equidade baseada em tokens, porque a simples contagem de pedidos não representa o serviço consumido por cargas de trabalho de LLM heterogéneas.

Uma política doméstica deve decidir se equidade significa trabalho equivalente em tokens, tempo de espera equivalente, igual oportunidade de conclusão ou prioridade para tarefas sensíveis à latência.

Nenhuma métrica única satisfaz todas as cargas de trabalho. Um comando de voz e um resumo executado em segundo plano não têm necessariamente de receber um tratamento idêntico.

-15% OFF

Um comprimento de saída desconhecido torna difícil prever o serviço futuro

O agendador conhece o tamanho do prompt no momento da admissão, mas normalmente não sabe exatamente quantos tokens de saída o modelo irá gerar. Um pedido pode permanecer ativo durante muito mais tempo do que o esperado.

A investigação sobre equidade destaca os comprimentos de pedidos imprevisíveis como um desafio específico da disponibilização de LLM.

Cobrar o serviço à medida que os tokens são efetivamente processados evita depender totalmente de uma estimativa de comprimento inadequada, mas ainda pode permitir que um pedido longo ocupe memória durante muitas iterações.

Pré-preenchimentos grandes podem perturbar utilizadores que já estão a receber tokens

Um novo prompt de documento pode entrar enquanto vários utilizadores estão a descodificar. O seu pré-preenchimento, intensivo em computação, pode prolongar a iteração que as conversas ativas têm de aguardar.

O Sarathi-Serve utiliza o agendamento sem interrupções para dividir pré-preenchimentos grandes e reduzir o seu efeito na latência de descodificação em curso.

Um agendador que conte apenas os tokens de descodificação pode continuar a ser injusto se um utilizador introduzir repetidamente pré-preenchimentos grandes que atrasam a saída transmitida de todos.

Por isso, a contabilização equitativa deve incluir tanto o processamento da entrada como os tokens gerados.

A pressão sobre a memória pode criar problemas de equidade antes de o processamento atingir a saturação

Cada conversa ativa precisa de cache KV, e os contextos mais longos consomem mais blocos. Um utilizador com um contexto grande pode reduzir o número de outros pedidos que cabem no lote ativo.

A análise multiutilizador da ZimaSpace relaciona a concorrência doméstica com a memória partilhada do modelo e as decisões do agendador.

Antecipar ou trocar um pedido pode restaurar capacidade, mas o utilizador interrompido poderá posteriormente suportar o custo de uma recomputação, do recarregamento da cache ou de um tempo de conclusão mais longo.

Por isso, a admissão de memória e o agendamento da computação devem seguir a mesma política de equidade, em vez de funcionarem como limites independentes.

As prioridades precisam de envelhecimento, quotas e métricas visíveis para os utilizadores

O controlo por voz, as ferramentas de acessibilidade e o chat interativo curto podem merecer uma prioridade superior à geração de embeddings ou aos resumos noturnos. Ainda assim, um agendamento baseado exclusivamente em prioridades pode deixar o trabalho de baixa prioridade sem recursos.

O Llumnix utiliza o agendamento dinâmico para adaptar a colocação dos pedidos e as decisões sobre recursos à medida que as condições de disponibilização se alteram.

Adicione envelhecimento, quotas por utilizador, limites máximos de contexto ou de saída e uma parcela reservada para tarefas em segundo plano, para que o trabalho prioritário responda rapidamente sem bloquear indefinidamente tudo o resto.

Meça o tempo na fila, o tempo até ao primeiro token, o atraso entre tokens, o tempo de conclusão, os tokens servidos e as antecipações por utilizador ou classe de carga de trabalho. O batching contínuo só é equitativo quando a distribuição observada corresponde à política doméstica, e não simplesmente quando o número total de tokens por segundo é elevado.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.