Cline acelera modelo aberto a 11.840 tokens por segundo em uma única GPU

Um ponto de partida já forte

Em 15 de outubro, a equipe da Cline publicou um relatório sobre como conseguiu acelerar um modelo de linguagem aberto a 11.840 tokens por segundo combinados em uma única GPU. O modelo em questão é compacto, projetado especificamente para execução local — ele não pretende ser o mais inteligente, mas precisa funcionar de forma rápida e estável em várias tarefas ao mesmo tempo: análise de documentos, programação, cálculos financeiros. É justamente essa velocidade e eficiência que tornam modelos assim interessantes — eles podem ser ajustados para as necessidades específicas de uma empresa e rodar na própria infraestrutura, em vez de pagar por cada chamada a uma API de terceiros.

O experimento foi possível graças a uma parceria com a NVIDIA, que deu à Cline acesso a um servidor potente equipado com uma única GPU e 252 GB de memória de vídeo. O objetivo era simples: extrair o máximo de tokens por segundo dessa configuração sob alta carga paralela.

Já no início, com a versão do motor vLLM 0.32.0rc1.dev190+g3f1bcfd82 e configurações padrão, o modelo entregou 6.058 tokens por segundo em um teste com 512 tokens de entrada e 512 de saída, em 256 fluxos de requisições simultâneos. Isso foi uma surpresa para a Cline — a configuração padrão do modelo já se mostrou bem otimizada para cargas altas, e a equipe tratou esse número como um bom ponto de partida, e não como uma falha a ser corrigida de forma heroica.

Cinco passos que quase dobraram a velocidade

A partir daí, os engenheiros rodaram uma série de experimentos, alterando um parâmetro por vez:

• Previsão multi-token (MTP3). O modelo vem com uma "cabeça" capaz de prever vários tokens seguintes de uma vez. Ativar o modo MTP3 com execução em thread única (OMP1) — para evitar a sobrecarga de coordenação entre threads — trouxe o primeiro ganho de velocidade.
• Escalonador assíncrono. Com um grande número de requisições paralelas, a GPU fica ocupada com os cálculos enquanto a CPU lida com o escalonamento de tarefas. Mudar o escalonador para o modo assíncrono eliminou o tempo ocioso da GPU à espera da CPU.
• Substituição do bloco Mamba pelo FlashInfer. O modelo usa dois tipos de camadas: camadas de atenção convencionais com cache KV, e camadas Mamba, que armazenam o estado de forma diferente — por meio de memória recorrente e uma convolução curta sobre o histórico. Trocar o motor de computação das camadas Mamba pelo FlashInfer gerou, de forma inesperada, um salto expressivo de desempenho. A equipe admite honestamente que não entende por completo por que isso funcionou — o efeito pode estar ligado a essa configuração específica de GPU e talvez não se repita em outro hardware.
• Redução do MTP de 3 para 1. Seria de se esperar que, quanto mais tokens o modelo prevê com antecedência, mais rápida seria a geração. Na prática, aconteceu o contrário: cada previsão ainda precisa ser verificada, e se a verificação falhar, o tempo é desperdiçado. Com 256 fluxos paralelos, a GPU já estava ocupada com trabalho útil, então as previsões extras só atrapalhavam. Reduzir a profundidade de previsão para MTP1 trouxe mais um ganho de velocidade.
• Estado do Mamba em FP16. O último passo foi converter o estado interno das camadas Mamba de precisão de 32 bits para 16 bits, com arredondamento estocástico. Isso reduz a precisão dos cálculos e pode piorar um pouco a qualidade das respostas do modelo, mas, para o objetivo do experimento — velocidade máxima —, a equipe considerou a troca justificada.

Juntos, esses cinco ajustes elevaram a velocidade agregada de 6.058 para 11.840 tokens por segundo — quase o dobro, sem trocar o hardware.

O que isso significa para os engenheiros

A principal conclusão da equipe da Cline não é bem uma receita, mas um alerta: a engenharia de inferência depende fortemente do contexto. Os truques que funcionaram aqui — MTP1 em vez de MTP3, FlashInfer em vez do kernel padrão do Mamba — poderiam, em um formato diferente de tráfego (outra proporção de tokens de entrada/saída, outro número de requisições paralelas), reduzir a velocidade em vez de aumentá-la. Por isso, a Cline recomenda não copiar às cegas a configuração de outra pessoa, mas primeiro entender o formato do próprio tráfego e ajustar a inferência de acordo com ele.

A equipe também compartilhou três previsões para o futuro. Primeiro, executar localmente dezenas de fluxos de agentes em paralelo se tornará rotina — como exemplo, citam uma demonstração com 32 sessões simultâneas da Cline no modelo Nemotron 3.5 Super VL, em uma única estação NVIDIA DGX, gravada sem aceleração de vídeo.

Segundo, com a GPU em plena carga, hospedar os modelos na própria infraestrutura pode sair mais barato do que pagar por uma API — segundo os cálculos da Cline, no caso deles a economia foi de cerca de 66%. Terceiro, os autores acreditam que, com o tempo, encontrar a configuração ideal de inferência se tornará, em si, uma tarefa para agentes de IA: um agente com acesso às métricas do Grafana poderá rodar testes de carga em uma GPU reserva, encontrar a melhor configuração para um tráfego específico e migrar a produção para ela com segurança — ou seja, o autoescalonamento de inferência se tornará uma tarefa agêntica.