🤖 machine learning

Depth-adaptive Inference of Looped Language Models via Continuous Depth Batching

Este artigo apresenta o Continuous Depth Batching (CDB), um novo framework de escalonamento que possibilita a inferência adaptativa de profundidade de ponta a ponta e eficiente para modelos de linguagem em loop, ao desacoplar as iterações de loop dos estágios de fronteira e sobrepor o escalonamento com a computação da GPU, alcançando assim até 1,9x mais throughput e uma latência significativamente menor em comparação aos métodos padrão.

Autores originais: Kristian Schwethelm, Daniel Rueckert, Georgios Kaissis

Publicado 2026-08-11

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Kristian Schwethelm, Daniel Rueckert, Georgios Kaissis

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está administrando uma biblioteca imensa e superveloz, onde um único bibliotecário consegue responder a milhares de perguntas ao mesmo tempo. No mundo da Inteligência Artificial, este bibliotecário é um "Modelo de Linguagem de Grande Escala" (LLM), e as perguntas são prompts de texto dos usuários. Normalmente, para economizar tempo e dinheiro, o bibliotecário processa todas as perguntas em uma fila estrita, dando a cada uma delas exatamente a mesma quantidade de atenção, não importa quão simples ou complexa seja a pergunta. Isso é eficiente, mas é um desperdício: responder "Quanto é 2+2?" exige tanto poder cerebral quanto resolver um problema complexo de física, embora a primeira seja uma moleza.

Recentemente, cientistas descobriram um truque inteligente chamado modelos "em loop". Em vez de uma linha reta, esses modelos possuem um "loop de pensamento". Eles podem revisar seu trabalho, passar a resposta por uma câmara de pensamento especial e, se a resposta parecer boa, eles param. Se ela parecer instável, eles passam pela câmara novamente. Isso significa que perguntas fáceis recebem um passe rápido, enquanto perguntas difíceis recebem loops extras de pensamento profundo. É como um estudante que olha para um problema matemático simples e escreve a resposta imediatamente, mas passa dez minutos rabiscando em um quadro branco para um cálculo complexo. Isso parece perfeito, mas cria um pesadelo para o bibliotecário tentando gerenciar a fila. Se todos na fila precisarem de um tempo diferente na câmara de pensamento, a fila inteira fica travada. O bibliotecário não pode processar o próximo grupo até que o grupo atual termine, e se algumas pessoas ainda estiverem pensando enquanto outras já terminaram, o sistema entra em colapso. Este artigo aborda exatamente esse congestionamento.

Os autores deste artigo introduzem um novo sistema chamado Continuous Depth Batching (CDB) para consertar o congestionamento causado por esses "loops de pensamento". Eles perceberam que a forma antiga de gerenciar a fila (chamada de batching padrão) era muito rígida. Tratava cada pergunta como se precisasse do mesmo número de loops, o que desperdiçava a vantagem de velocidade dos novos modelos. Para resolver isso, eles construíram um agendador dinâmico que atua como um controlador de tráfego superorganizado. Em vez de esperar que todo o grupo termine, este controlador permite que as perguntas finalizadas saiam da fila imediatamente e as substitui instantaneamente por novas perguntas esperando para começar.

Pense nisso como uma cozinha de restaurante movimentada. No sistema antigo, se um chef está fazendo uma salada simples (token fácil) e um suflê complexo (token difícil) ao mesmo tempo, toda a cozinha tem que esperar até que o suflê esteja pronto para servir a salada ou começar um novo pedido. O novo sistema CDB é diferente. Assim que a salada fica pronta, ela é montada e enviada, e o chef imediatamente pega um novo pedido para começar a picar os vegetais, mantendo a cozinha constantemente ocupada. O artigo mostra que, ao fazer isso, o sistema pode manter o "loop de pensamento" rodando em velocidade máxima sem nunca deixar as mãos do chef ociosas.

Os pesquisadores testaram isso em dois modelos de IA diferentes, chamados Ouro e Huginn. Eles descobriram que o CDB funciona incrivelmente bem. Para o modelo Ouro, o novo sistema alcançou até 99% do aumento de velocidade teórico possível. Em português claro, isso significa que o sistema é quase tão rápido quanto poderia ser se você pudesse remover magicamente cada segundo de tempo desperdiçado. Em testes do mundo real, isso se traduziu no processamento de 1,5 a 1,9 vezes mais requisições por segundo do que os métodos antigos. Quando o sistema estava sob carga pesada, como um site movimentado com milhares de usuários, o tempo de espera pelas respostas caiu de 45% a 90%.

No entanto, o artigo também aponta que essa magia não é automática. O sistema funciona melhor quando o "loop de pensamento" é a parte principal do trabalho. Se as etapas antes do loop (como ler a pergunta) e depois do loop (como escrever a resposta final) forem muito lentas ou pesadas, elas podem atrasar todo o processo. Os autores descobriram que, para modelos onde essas etapas extras são pesadas, o aumento de velocidade ainda é bom, mas não tão dramático. Eles também descobriram um "ponto ideal" para o processamento de quantas perguntas de uma vez. Se você tentar processar poucas perguntas, o sistema perde tempo recarregando o "cérebro" (pesos) do modelo para cada etapa. Se processar demais, o sistema fica sobrecarregado. O CDB ajuda a encontrar esse equilíbrio perfeito ao reabastecer constantemente a fila sempre que uma vaga se abre.

Um dos truques mais engenhosos que os autores usaram é algo chamado "gate de lookahead" (portão de antecipação). Normalmente, o sistema tem que esperar uma pergunta terminar seu loop de pensamento antes de saber se a resposta é boa o suficiente para sair. Isso causa uma pequena pausa onde o computador fica parado apenas esperando. O novo sistema prevê a resposta um passo antes, permitindo que o próximo lote de perguntas seja preparado enquanto o atual ainda está terminando. É como um maestro que sinaliza a próxima seção da orquestra pouco antes de a seção atual terminar, para que não haja silêncio entre as notas. Essa pequena mudança reduziu o "tempo de ociosidade" do computador para quase zero, tornando todo o processo incrivelmente suave.

Em suma, este artigo prova que podemos tornar esses modelos de IA inteligentes e autocorretivos realmente rápidos o suficiente para uso no mundo real. Ao tratar os "loops de pensamento" como um cronograma flexível em vez de uma linha rígida, e ao substituir constantemente tarefas finalizadas por novas, os autores construíram um sistema que não é apenas mais inteligente, mas significativamente mais rápido e eficiente. Eles não apenas sugeriram que isso poderia funcionar; eles o construíram, testaram em hardware real e mostraram que ele entrega ganhos de velocidade massivos, transformando uma ideia teórica em uma ferramenta prática para o futuro da IA.

Resumo Técnico: Batching de Profundidade Contínua para Modelos de Linguagem em Loop

Definição do Problema

Modelos de Linguagem (LMs) em loop oferecem uma arquitetura promissora para inferência de profundidade adaptável, onde um núcleo recorrente compartilhado é iterado um número variável de vezes por token. Isso permite que o modelo aloque mais computação para tokens "difíceis" e menos para os "fáceis", melhorando o compromisso entre computação e precisão. No entanto, essa adaptabilidade quebra fundamentalmente os mecanismos de batching padrão usados em frameworks de inferência modernos (ex: vLLM).

No batching contínuo padrão, uma passagem forward é uma operação uniforme onde todos os tokens em um batch passam pelo mesmo número de camadas. Em LMs em loop de profundidade adaptável, os tokens saem do núcleo recorrente em profundidades diferentes. Consequentemente, um único batch contém tokens que exigem operações distintas: alguns precisam de outro passo recorrente, enquanto outros que saíram devem executar o "coda" não-looped (LM head) para gerar o próximo token. Os schedulers de nível de token existentes não podem lidar com essa heterogeneidade porque não conseguem rotear diferentes tokens para diferentes estágios dentro de uma única passagem forward. Além disso, arquiteturas em loop introduzem "estágios de fronteira" (prelude e coda) que rodam uma vez por token, mas em frequências diferentes do loop, adicionando complexidade de agendamento. Nenhum sistema de inferência existente suporta o serviço de ponta a ponta desses modelos com profundidade dinâmica.

Metodologia: Batching de Profundidade Contínua (CDB)

Os autores introduzem o Continuous Depth Batching (CDB), um método de inferência que agenda na granularidade das iterações individuais do loop, em vez de fronteiras de tokens. O CDB aborda três desafios principais: heterogeneidade de estágio, saídas de caminho crítico e caches de Key-Value (KV) irregulares.

1. Scheduler de Decode Baseado em Filas

O CDB decompõe o processo de geração em quatro filas distintas:

Prefill: Requisições aguardando.
Prelude: Tokens aguardando o embedding inicial/pré-processamento.
Recurrent Core: Tokens prontos para seu próximo passo de loop.
Coda: Tokens que saíram do núcleo e aguardam a predição final.

O scheduler trata esses estágios como operações separadas, permitando ordens de execução flexíveis. O artigo implementa dois modos:

No-Refill: Uma ordem fixa (Prelude $\to$ Core $\to$ Coda). Quando os tokens saem, o batch encolhe e nenhum novo token entra até a próxima rodada de decode.
Refill: Os estágios rodam em qualquer ordem baseada em prioridade. Quando um token sai, sua vaga é imediatamente preenchida por um novo token da fila de prefill. Isso maximiza o tamanho do batch e o throughput, aproveitando o fato de que o núcleo recorrente reutiliza os mesmos pesos independentemente da contagem de iterações do loop.

2. Cache KV Consciente de Profundidade

Os caches KV padrão são indexados por profundidade, criando lacunas quando os tokens saem precocemente. O CDB propõe dois layouts:

Last-Exited Cache: Preenche slots vazios para passos pulados copiando o estado final do token que saiu. Isso preserva a semântica de atenção, mas desperdiça memória e computação na cópia.
Shared Cache: Cada camada física mantém apenas um slot KV, que é sobrescrito a cada passo do loop. Isso reduz a pegada de memória por um fator de $r_{max}$ , mas altera a semântica de atenção (os tokens atendem ao estado mais recente de tokens anteriores, independentemente de sua profundidade de saída). Os autores observam que kernels de atenção modernos (ex: PagedAttention, FlashAttention-3) são compatíveis com ambos.

3. Execução Assíncrona e Lookahead

Para minimizar o overhead de sincronização CPU-GPU, o CDB emprega execução assíncrona:

Sobreposição (Overlapping): A CPU prepara o próximo batch (baseado nas decisões de saída do passo $N-1$ ) enquanto a GPU execeuta o passo atual ( $N$ ).
Lookahead Gate: Para eliminar o tempo de ociosidade da GPU causado pela espera de decisões de saída, o scheduler utiliza um "lookahead gate". O sinal de saída no passo $r$ determina a participação no passo $r+2$ em vez de $r+1$ . Isso dá à CPU um passo de loop completo para preparar o próximo batch sem desperdiçar computação, reduzindo o tempo de ociosidade da GPU para quase zero (0,67% em experimentos).

Principais Contribuições

Implementação de Ponta a Ponta: A primeira implementação completa de CDB para LMs em loop de profundidade adaptável, incluindo um scheduler de serviço, integração de gate de saída e manipulação de cache KV.
Limites Teóricos: Derivação de um limite superior de velocidade baseado em FLOPs proveniente da profundidade adaptável e um modelo de roofline consciente de hardware para identificar os regimes de tamanho de batch onde o modo "refill" é mais benéfico (especificamente em regimes limitados por memória).
Avaliação Empírica: Avaliação abrangente em duas arquiteturas (Ouro 1.4B e Huginn 3.5B) demonstrando o impacto da estrutura do modelo, contagem de loops e custos de estágio de fronteira na eficiência da inferência.

Resultados Experimentais

Os autores avaliaram o CDB no Ouro 1.4B (totalmente em loop, estágios de fronteira baratos) e no Huginn 3.5B (divisão 2-4-2, estágios de fronteira caros) usando cargas de trabalho Alpaca e ShareGPT.

Throughput: O CDB atinge até 99% do limite teórico de aceleração baseado em FLOPs.
- Ouro 1.4B: O CDB (refill) alcança um throughput offline de 1,5–1,58× maior comparado ao batching contínuo (CB) padrão.
- Huginn 3.5B: Apesar dos maiores custos de estágio de fronteira, o CDB alcança até 1,9× mais throughput.
Latência: Sob cargas de serviço online dinâmicas, o CDB reduz a latência normalizada em 45–90% comparado ao CB padrão.
Eficácia do Refill: O modo "refill" é mais eficaz no regime limitado por memória (pequenos tamanhos de batch), onde saídas precoces deixariam a computação da GPU ociosa. No regime limitado por computação (batches grandes), a vantagem diminui conforme o tempo de relógio escala com o trabalho total, independentemente das saídas precoces.
Precisão: Os autores observam que o lookahead gate (decidir a saída um passo antes) não degrada significamente a precisão em comparação com os gates de saída padrão. No entanto, notam que o compartilhamento de cache KV (especificamente o layout de slot único compartilhado) pode causar colapso de precisão no Ouro, a menos que o modelo seja treinado para isso, enquanto o Huginn permanece robusto.

Significância e Alegações

O artigo afirma que LMs em loop servidos com CDB são não apenas eficientes em parâmetros, mas também eficientes em inferência. Ao decompor a passagem forward de profundidade variável em um problema de agendamento, o CDB permite que o hardware existente lide com a profundidade adaptável sem o enorme overhead que anteriormente tornava a implementação desses modelos impraticável para o serviço.

Os autores enfatizam que os ganhos de eficiência dependem fortemente do co-design da arquitetura do modelo e do sistema de inferência. Especificamente:

Estágios de Fronteira: Modelos com estágios de fronteira caros (como o Huginn) veem reduções na aceleração porque os tokens devem esperar por esses estágios antes de reentrar na fila para o refill.
Memória vs. Computação: A estratégia de "refill" é crítica para superar a natureza limitada por memória da inferência de pequeno batch, escondendo efetivamente os custos de recarregamento de pesos do núcleo recorrente.
Trade-offs: O trabalho destaca a tensão entre precisão e eficiência; embora o decoding de profundidade adaptável economize computação, a escolha dos limiares de saída e das políticas de cache KV impacta diretamente o desempenho do modelo.

O artigo conclui que o CDB fornece um caminho viável para servir modelos de profundidade adaptável, realizando os benefícios teóricos da inferência de profundidade variável em cenários práticos de alto throughput.