Cline extrai 11 840 tokens/s de uma única estação NVIDIA DGX Station

A equipe da Cline levou a velocidade total de geração de um modelo aberto, em uma única GPU, a 11 840 tokens de saída por segundo. O recorde foi registrado em 15 de outubro em uma estação da NVIDIA, à qual os engenheiros tiveram acesso graças à parceria com a NVIDIA. O ponto de partida já era alto: o vLLM 0.32.0rc1 puro entregava 6 058 tokens/s no teste com 512 tokens de entrada e 512 de saída e 256 fluxos simultâneos. O resultado final é cerca de 1,95 vez maior.

O modelo foi concebido como um "cavalo de batalha" local e rápido para diversas tarefas: análise de documentos, programação e contabilidade financeira. Em uma única máquina, ele dispõe de um orçamento de 252 GB de memória de GPU. Na demonstração da Cline, 32 instâncias paralelas do Cline rodam nessa estação sobre o Nemotron 3.5 Super VL, em um vídeo sem aceleração.

Cinco passos de 6 058 a 11 840

A Cline não descreve uma única descoberta, mas uma série de experimentos, dos quais cinco funcionaram:

• Cabeça MTP integrada. A multi-token prediction já vinha com o modelo. Os engenheiros começaram com MTP3, isto é, três tokens de rascunho por passo, e fixaram OMP1: uma única thread de CPU funciona melhor, porque várias threads aumentam o overhead de coordenação.
• Agendamento assíncrono. Com alta concorrência, a GPU fica ocupada com os kernels de computação e a CPU, com o agendamento. O modo assíncrono permite que o agendador não precise esperar a GPU terminar o trabalho.
• Kernel de Mamba no FlashInfer. O modelo é híbrido: as camadas de attention usam KV-cache, enquanto as camadas Mamba guardam o estado recorrente e um breve histórico de convolução. Voltar ao kernel do FlashInfer deu um salto expressivo. Os autores não chegaram a entender totalmente por quê, e em outro hardware o efeito pode não se repetir.
• MTP1 no lugar de MTP3. Um passo contraintuitivo, que elevou o throughput mais uma vez.
• Estado de Mamba em FP16 em vez de FP32, com arredondamento estocástico. Isso reduz a precisão e, potencialmente, as métricas em benchmarks, mas para o objetivo de "máximo de tokens por segundo" o custo se mostrou aceitável.

Por que menos tokens de rascunho foi mais rápido

A decodificação especulativa parece um bônus gratuito: quanto mais tokens de rascunho são previstos, maior a chance de aceitar vários de uma vez. Mas cada rascunho precisa ser verificado. Se a verificação falha, o tempo do modelo foi desperdiçado. Com 256 fluxos paralelos, a GPU já está cheia de trabalho útil, e a verificação adicional não compensa. Por isso o MTP1 superou o MTP3.

O ganho do MTP pode parecer o oposto sob carga baixa e sob alta concorrência. A mesma receita poderia prejudicar em outro perfil de tráfego. A Cline diz abertamente: a engenharia de inferência depende muito do contexto, e o escalonamento depende do formato do tráfego.

Economia: 66% abaixo do preço da API

A principal conclusão prática é uma conta de guardanapo feita pela Cline. Comparando o pagamento de API com uma GPU totalmente ocupada, o resultado é um desconto de 66% na inferência. A condição é rígida: a GPU precisa ficar ocupada quase o tempo todo. Nesse caso, sai mais barato adotar a receita da Cline e pagar pelo hardware do que passar por um roteador de modelos e pagar por cada chamada.

Disso decorrem duas previsões da equipe. A primeira: o self-hosting de dezenas de agentes locais em paralelo vai se tornar prática comum, e os 32 Clines em uma única estação já mostram isso. A segunda: o autoescalonamento de inferência vai se tornar agêntico. Um agente com acesso às métricas do Grafana poderá rodar testes de carga em uma GPU dedicada, sem afetar o tráfego de produção. Ele escolherá a melhor configuração para o formato real das requisições e, depois, migrará o tráfego com cuidado para a nova configuração. Esse sistema "autocurativo" ajustará o consumo de GPU ao horário do dia e à carga.

O que verificar antes de repetir a receita

A receita não deve ser copiada às cegas. Primeiro, é preciso registrar o seu próprio perfil: tamanho dos prompts e das respostas, número de fluxos simultâneos e latência aceitável. Depois, vale testar os mesmos cinco ajustes um por um. Para alta concorrência, convém comparar MTP1 e MTP3; com poucos fluxos, o efeito pode ser o inverso. A troca de FP32 por FP16 no estado de Mamba exige necessariamente nova rodada dos conjuntos de avaliação, porque aqui a velocidade foi comprada ao preço da precisão. E, por fim, o cálculo de economia de 66% só vale com alta utilização da GPU: se a estação ficar ociosa, a API volta a ser mais vantajosa.