Clusters grandes para modelos pequenos — Daniel Svonava, Superlinked

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Large clusters for small models — Daniel Svonava, Superlinked · Canal: AI Engineer · 24:34 · Assistir no YouTube

Tópicos: Inferência e otimização de modelos, Infraestrutura e hardware de IA, Modelos locais e open source

Resumo

Daniel Svonava explica como modelos open source pequenos podem alcançar desempenho de ponta em tarefas específicas, com custos menores e latência reduzida. Para isso, é preciso selecionar e avaliar modelos por tarefa e adaptar a infraestrutura para atender a uma frota diversificada, em vez de depender de um único modelo grande. Ele apresenta uma arquitetura de cluster com fila centralizada, workers que formam seus próprios batches e suporte a diferentes runtimes. Também aborda resultados de desempenho, carregamento de modelos e loops de pesquisa automatizada para otimizar modelos e configurações.

Pontos-chave

Modelos pequenos que cabem em uma única GPU podem oferecer desempenho comparável ao de modelos de ponta em tarefas específicas.
A adoção exige dividir o trabalho em tarefas e escolher o modelo mais adequado para cada uma, usando evals e, quando necessário, adaptação.
Uma frota de modelos especializados amplia as exigências de infraestrutura e pode criar atrito entre equipes de IA e de infraestrutura.
Em cargas com muitas solicitações pequenas, o roteamento centralizado tradicional pode limitar a utilização das GPUs.
Uma fila compartilhada permite que os workers retirem tarefas e formem batches localmente, melhorando a utilização e o throughput.
A arquitetura apresentada combina um gateway, uma fila centralizada, workers e diferentes runtimes, com uma camada de abstração para lidar com sua diversidade.
Modelos de embedding são apresentados como um caso de adoção especialmente promissor, com potencial para reduzir custos e latência em comparação com endpoints gerenciados.
Modelos pequenos também podem ser usados para gerar dados sintéticos, anotações e conteúdo para fine-tuning e evals.
Loops de pesquisa automatizada ajudam a adicionar suporte a modelos e otimizar o desempenho; as configurações ajustadas podem ser distribuídas com o suporte a cada modelo.

Capítulos

Início	Capítulo	Resumo
00:12	Modelos pequenos e seu potencial	Svonava define modelos pequenos e argumenta que eles podem oferecer desempenho de ponta em tarefas específicas com custos e latência menores.
03:46	Modelos especializados e desafios de infraestrutura	A palestra descreve o uso de uma frota de modelos por tarefa e os desafios de servir modelos variados, inclusive fine-tunes e LoRAs.
06:52	Limitações do roteamento tradicional	O palestrante explica por que o roteamento top-down pode dificultar a formação de batches e a plena utilização das GPUs em cargas de solicitações pequenas.
09:58	Arquitetura de cluster com fila compartilhada	Svonava apresenta a arquitetura open source, na qual o gateway anota as solicitações e os workers retiram tarefas de uma fila centralizada.
13:34	Gateway, filas e formação de batches	O palestrante detalha o papel leve do gateway, o uso de NATS JetStream e a formação de batches pelos próprios workers.
16:11	Runtimes e abstração para modelos diversos	A palestra compara PyTorch, Candle e SGLang e defende uma camada de abstração para lidar com a variedade de modelos e runtimes.
18:48	Desempenho e casos de uso	Svonava apresenta o conceito de ponto de saturação e exemplos de throughput e latência para embeddings e modelos especializados.
21:26	Gestão de modelos e otimização automatizada	A parte final aborda escalabilidade, carregamento e remoção de modelos, loops de pesquisa automatizada e o uso de modelos pequenos.

Citações

Os modelos pequenos já não são burros. — 03:16

Esse roteamento top-down se torna o gargalo. — 07:55

Isso não é ciência de foguetes: você pode ter grandes economias de custo e melhorias de latência. — 20:53

Os modelos pequenos são muito mais baratos, mais rápidos e tão inteligentes quanto. — 24:34

Conceitos e entidades

Small models (conceito): Modelos que, na definição usada na palestra, cabem em uma GPU de gerações anteriores e podem ser especializados para tarefas específicas.
Superlinked (empresa): Empresa apresentada por Daniel Svonava, que desenvolve sistemas de busca e processamento de documentos com IA.
Daniel Svonava (pessoa): Palestrante que apresenta estratégias de serving para frotas de modelos pequenos.
NATS JetStream (ferramenta): Sistema de filas usado na arquitetura descrita para armazenar solicitações e permitir que os workers as retirem.
PyTorch (ferramenta): Runtime usado para executar e otimizar modelos, incluindo modelos encoder-only.
SGLang (ferramenta): Runtime de serving usado como referência de desempenho e integrado à arquitetura apresentada.
Candle (ferramenta): Runtime com binários menores que os de PyTorch, explorado para reduzir o tamanho das imagens e o tempo de inicialização.
Apache License 2.0 (conceito): Licença indicada pelo palestrante para o projeto open source de cluster apresentado.
RTX Pro 6000 (modelo): GPU usada como referência para alguns dos números de desempenho apresentados.
Hugging Face (empresa): Plataforma mencionada como hospedagem de centenas de milhares de modelos.

Tradução completa (pt-BR)

00:12 Certo, acho que vocês conseguem me ouvir. Eu certamente consigo me ouvir. Quem chegou mais perto ganha uma camiseta. Eu falei sério. Tem um monte de camisetas aqui atrás. E também, para as perguntas: talvez haja algumas no final. Se você fizer uma pergunta, também ganha uma camiseta. E, se conseguir adivinhar o que está no fundo deste slide, ganha uma camiseta também. Algum palpite?

00:42 O que isso representa? Esta imagem no fundo? Não. Alguém já viu um modelo transformer? >> Ah, sim, codificação posicional. Muito bem. Você ganha a camiseta, senhor. Certo. Hoje vamos falar basicamente sobre modelos open source pequenos, como eles estão bem bons agora e como criam desafios únicos quando você quer servir

01:13 vários deles na sua própria nuvem. Tudo o que vamos discutir é, de certa forma, open source. Faça você mesmo. Esse é o tipo de coisa que você pode simplesmente executar com um comando e controlar toda a stack. Então, não há peças proprietárias do quebra-cabeça aqui. Vamos começar. Bem, isso funciona. Certo. Então, modelos pequenos. O que queremos dizer com modelos pequenos? Dependendo de quem você perguntar, a maneira como eu

01:43 penso nisso é: são basicamente modelos que você consegue executar em hardware Nvidia de duas ou três gerações atrás. O modelo inteiro cabe em uma GPU. E, por isso, é fácil servi-los; essas GPUs estão disponíveis e também são acessíveis. A maioria das pessoas pensa: “Certo, modelos pequenos; deve haver algum tipo de concessão na qualidade dos resultados”. Espero conseguir fazer um bom trabalho nesta palestra e convencer vocês de que

02:15 na verdade, em tarefas específicas, é possível alcançar um desempenho de fronteira ou até superior e obter todos os outros benefícios óbvios, certo? Economias de custo de várias ordens de magnitude e, potencialmente, melhorias bastante grandes em latência ou throughput. Este é um dos gráficos que gostamos de mostrar. É o índice de inteligência da Artificial Analysis ao longo do tempo. E o que normalmente não mostram

02:45 é uma divisão dos modelos open source que vocês deveriam considerar: há o GLM 5.2 e outros modelos open source de fronteira, com, digamos, 750 bilhões de parâmetros. Mas há também os modelos open source pequenos, que ficam atrás dos grandes e dos modelos de fronteira. Dá para ver que os modelos de fronteira estão tendo retornos decrescentes atualmente, e os modelos pequenos estão alcançando-os, certo? Então, vemos essa convergência, essa saturação no topo e, ao mesmo tempo, o crescimento dos modelos

03:16 pequenos. Digamos que o Qwen3 27B tenha um desempenho próximo ao do GPT 5.1. Se você tem um workflow, um pipeline que consegue funcionar com o GPT 5.1, agora pode migrá-lo para um modelo pequeno e obter todos os benefícios que discutimos. Então, os modelos pequenos já não são bobos. Agora, também importa como você usa os modelos pequenos, certo? Você não pode simplesmente tratar

03:46 esse Qwen3 27B como um modelo totalmente generalista, ao qual você pode pedir para fazer qualquer coisa. Agora, você precisa adotar uma abordagem em que identifica um subconjunto de tarefas da carga de trabalho do modelo generalista e, para cada tarefa, descobre qual modelo open source é o mais adequado. Você executa alguns evals, talvez faça alguma adaptação — vamos falar disso — e é assim que alcança a qualidade certa para realmente colocar isso em produção. Aqui está um exemplo de um agent de revisão de contratos

04:18 que usa nove modelos diferentes. Esse é o tipo de configuração que você verá nas suas cargas de trabalho e nos seus agents quando começar a usar modelos pequenos na sua estrutura. Você vai notar que, em vez de martelar uma API com vários pedidos diferentes, ou usar um único modelo, é melhor usar uma frota de modelos. Aí, o problema passa a ser: como servir todas essas coisas diferentes sem deixar o pessoal de infraestrutura maluco, certo? E este é apenas um dos agents que você pode estar executando; talvez haja

04:49 uns dez desses na sua empresa. Então, como lidamos com isso? Essa é a expansão do escopo da infraestrutura, digamos. Para todas aquelas tarefas diferentes que mencionei, existe um modelo open source esperando para ser usado: de OCR a respostas a perguntas sobre documentos, rotulagem de imagens, geração de SQL e revisão de código. Há modelos open source fine-tuned e treinados para essas tarefas.

05:19 Se você usar um modelo open source treinado para fazer OCR em recibos em vietnamita, esse projeto terá visto mais recibos em vietnamita, certo? Alguém dedicou tempo para reunir o máximo de dados possível e, nessa tarefa, esse modelo vai superar praticamente qualquer outro. E há centenas de milhares de modelos no Hugging Face que são assim, certo? Está tudo ali, e é tudo grátis, basicamente, com licenças em sua maioria bastante permissivas. Então, os modelos existem; esse não é

05:50 o gargalo. E estamos falando de IA open source desde 2024, mas até agora isso ainda não está realmente acontecendo. Nas empresas em que acontece, basicamente significa que IA open source é igual a AWS Bedrock — exceto que, quando você olha o catálogo de modelos do Bedrock, os tipos de modelo disponíveis são bastante limitados. Esses modelos são antigos, muitas vezes estão dois ou três anos atrás do estado da arte. E, quando você faz

06:21 qualquer tipo de fine-tuning no Bedrock, na verdade não fica com os artefatos fine-tuned ou treinados. Então, você não pode usá-los como uma vantagem real no seu negócio. Eles continuam sendo servidos pela infraestrutura do Bedrock. Isso é o lado proprietário. Agora, se você servir modelos pequenos em infraestrutura open source — vLLM, SGLang e outras soluções — saiba que essas ferramentas não são ajustadas para nenhum modelo específico, nem para nenhuma combinação específica de modelo e hardware. Você vai ter que fazer o ajuste. Essa é a abordagem faça você mesmo. Todas

06:52 essas ferramentas vêm com guias sobre como fazer o ajuste, a varredura de parâmetros, a adaptação ao seu tráfego e assim por diante. Cada vez que você tenta adotar uma dessas ferramentas, isso se torna um projeto de pesquisa de escopo aberto. Portanto, não é algo que você simplesmente pega e transforma em um projeto de engenharia para, uma semana depois, ter uma infraestrutura de serving de alto desempenho. Não funciona assim. Esse é o problema típico das ferramentas open source, certo? É um pouco faça você mesmo demais.

07:24 Além de não serem pré-ajustadas para modelos pequenos, as cargas de trabalho de modelos pequenos e o tráfego que usa vários modelos mudam a lógica dos clusters de inference, certo? Normalmente, quando você tenta servir um único modelo grande, os problemas são: como compartilhar esse modelo entre várias GPUs? Como ter um roteador no topo que entenda o estado de todos esses workers, o estado do KV cache e assim por diante, e então tome uma decisão de roteamento de cima para baixo sobre

07:55 certo, esta solicitação vai para este worker ou para este grupo de workers, e assim por diante. É uma configuração muito hierárquica. Mas, se você tem solicitações pequenas e rápidas e muitas delas, esse tipo de roteamento de cima para baixo se torna o gargalo, certo? Porque o roteador tem uma versão um pouco desatualizada do estado dos workers, e é muito difícil saturar os workers se a decisão inicial precisa acertar perfeitamente o balanceamento das filas locais em cada um dos

08:26 esses workers, porque há muitas solicitações pequenas, certo? E, sabe, experimentamos com roteadores VLM e SGLang para modelos pequenos e esse tipo de tráfego, e é muito difícil fazer a utilização da GPU passar de 20% ou 30% sob carga constante. O problema é que esses lotes simplesmente não têm o tamanho adequado, basicamente por causa desse gargalo de roteamento. E o terceiro problema é que, com modelos pequenos, você se beneficia muito de LoRAs e

08:56 da adaptação de modelos em geral. E, então, o tráfego que você precisa atender contém, sabe, pessoas que chegam até você e dizem: “Ei, tenho 10 LoRAs. Como uso isso com nossa stack de serving? Ou fiz este fine-tune personalizado ontem à noite. Quero colocá-lo em produção.” E essa conversa entre o engenheiro de IA e a pessoa de infraestrutura para colocar essas LoRAs e esses modelos personalizados no ar é o que leva tempo e, basicamente, é o principal

09:26 fator que prejudica a velocidade da organização: ficar conversando, certo? Idealmente, você gostaria que os engenheiros de infraestrutura fizessem o trabalho deles e que os engenheiros de IA fizessem o trabalho deles, sem precisarem conversar para operar no dia a dia. Assim, eles não ficam bloqueando uns aos outros. E esse desejo de adaptação de modelos em torno de modelos pequenos acaba com isso e cria muita troca de mensagens, e isso é um problema, certo? Então, esses são alguns desafios relacionados a: temos um monte de modelos pequenos,

09:58 como montamos um cluster e como atendemos a essas solicitações com eficiência? Temos trabalhado nesse problema há algum tempo. Na verdade, sou Daniel, da Superlinked; acabei pulando a apresentação. Somos uma empresa financiada por capital de risco, de San Francisco, e, nos últimos dois anos, temos criado sistemas de busca e processamento de documentos com IA e agents. Nosso principal ponto problemático sempre foi a inference, especificamente os problemas que descrevi. E, por isso, iteramos e

10:28 iteramos e exploramos diferentes topologias de cluster para executar frotas grandes e abrangentes de modelos pequenos em diferentes ambientes, porque às vezes é preciso fazer o deploy junto com alguma plataforma em um ambiente onde não se sabe o que estará disponível. Os modelos pequenos facilitam isso, porque é muito mais fácil conseguir algumas L4s ou algum tipo de cota pequena de GPU em qualquer ambiente. Então, vou descrever um pouco a topologia do cluster à qual acabamos chegando e, a propósito,

10:59 tudo isso está sob a licença Apache 2.0, ou seja, é totalmente open source. Vocês podem simplesmente pegar e adaptar. Agora somos uma startup de inference. É open source desde o plano de controle até o componente que roda na GPU. Não poupamos esforços. A topologia é basicamente assim: há um gateway e, em vez de um roteador que decide previamente para onde vai cada coisa, há um gateway que analisa parte da solicitação e anexa alguns metadados à

11:31 solicitação, insere-a em uma fila compartilhada e em alguns canais secundários. Vou falar um pouco sobre isso. Depois, os workers retiram itens dessa fila centralizada, em vez de os dados serem enviados aos workers. Assim, eles conseguem se saturar melhor. E a configuração dos workers — acho que tenho um slide sobre isso — vai mostrar como absorvemos a complexidade das diferentes arquiteturas de modelos em um conjunto coerente de workers, sem

12:01 exigências conflitantes de Python e coisas do tipo. Essa é a topologia geral. E este é o ciclo de vida de uma solicitação. Vou destacar algumas coisas. Uma das coisas de que não gostamos no padrão de API da OpenAI é o JSON codificado em Base64, que não é bom para modelos pequenos nem para alto throughput. Por isso, usamos MessagePack em tudo, um formato binário. Assim,

12:32 também podemos enviar todos os dados multimodais pela API gateway propriamente dita. Assim, não há aquela separação entre “os dados binários ficam aqui” e “a solicitação fica ali”, nem a necessidade de o cluster acessar seu armazenamento em nuvem para começar a carregar dados binários, imagens ou vídeos. Codificamos tudo e enviamos pelo gateway. O gateway então separa alguns desses componentes mais pesados para não sobrecarregar a fila interna e os transfere para o armazenamento em nuvem em paralelo, enquanto a solicitação está na fila. Então,

13:03 ele divide algumas dessas solicitações — digamos, as que têm mais de um megabyte — e usa o armazenamento em nuvem no backend. Mas, como usuário, você envia todos os seus bits e bytes para a camada de API, o que resulta em uma interface limpa. Basicamente, toda a stack usa REST. O gateway usa REST, o worker usa REST e, depois, por um socket local, ele se conecta a diferentes runtimes. Usamos PyTorch, Candle e SGLang

13:34 como runtimes. E, quando fazemos a otimização, vou explicar como garantimos que, qualquer que seja o runtime usado e o código executado nele, tudo funcione da maneira mais eficiente possível. Para isso, temos um loop de pesquisa automatizada. Mas, enfim, é assim que funciona o ciclo de vida de uma solicitação. E um detalhe é que é muito importante garantir que o gateway, que é a primeira coisa atingida pela solicitação, não faça trabalho demais,

14:06 porque aí ele vira um gargalo, certo? Você nem quer analisar a solicitação inteira. Quer conseguir olhar os pacotes e entender o formato geral do que está chegando, fazer a anotação e, então, ter os workers — quantos forem, centenas de GPUs — observando o estado da fila e retirando itens dela. Para a fila, usamos NATS JetStream, que consegue processar, sabe, um milhão de solicitações por segundo. É muito difícil que isso vire um gargalo.

14:37 Então, idealmente, você não quer serializar os dados à medida que passam por todos esses componentes; essa é basicamente a ideia óbvia. Esta animação mostra a ideia por trás do enfileiramento centralizado, certo? Em vez de o roteador de cima para baixo tentar preencher as filas locais corretamente — o que é basicamente impossível —, a ideia é: será que podemos centralizar o enfileiramento de alguma forma, para que os workers escolham a tarefa

15:08 de formar os próprios lotes, com a própria previsão do custo do lote, e, assim, se tornem muito mais eficientes? Agora, um detalhe, como observação à parte: quando você começa a trabalhar nessas coisas, percebe que é realmente difícil prever quantos itens retirar da fila compartilhada para que o lote tenha realmente o tamanho ideal. Então, seria bom ter algum mecanismo que permitisse devolver itens à fila quando você percebesse: “Opa, retirei itens demais.” Só que isso exige um salto de rede.

15:40 Isso é um problema, e temos uma otimização especial para máquinas que têm várias GPUs localmente. Há um componente adicional de enfileiramento local à máquina que aproveita o fato de que os processos locais executados nas várias GPUs de uma máquina podem negociar um pouco com a fila, de um lado para o outro. Pela rede, isso acrescentaria milissegundos. Então, não fazemos isso pela rede; só quando colocamos os workers juntos em máquinas com várias GPUs

16:11 máquinas e, quero dizer, não estamos falando de diferenças de uns 5%, certo? Então, ao centralizar a fila, você dobra a vazão do cluster. Isso é significativo. Mencionei três runtimes diferentes. Basicamente, ou escrevemos, digamos, o código em PyTorch para modelos somente encoder, e o otimizamos com um loop de pesquisa automática que faz essa otimização. O mesmo vale para Candle. Começamos a testar Candle não faz muito tempo. Ainda não conseguimos fazer com que ele

16:43 tenha um desempenho nem de longe próximo ao do PyTorch. Então, é um projeto mais de pesquisa. O problema é a dependência: a imagem Docker do worker com PyTorch tem uns 12 GB, enquanto o binário do worker, estático e compilado com Candle, talvez tenha uns 10% desse tamanho, certo? E, se você se importa com a retomada após um estado ocioso e com o carregamento dessas imagens em várias máquinas diferentes, passar de 12 GB para 1 GB, ou algo assim, faz uma enorme diferença. Então, essa é a

17:14 motivação por trás do Candle. É que obter o mesmo desempenho do PyTorch é realmente muito difícil. E temos o SGLang como uma espécie de baseline de referência: devemos ter um desempenho pelo menos tão bom quanto o do SGLang com o ajuste ideal de todos aqueles parâmetros que mencionei e que você precisa ajustar. Aqui estão alguns números. Por exemplo, quando envolvemos o SGLang com o socket e com o nosso sidecar de RAS, conseguimos melhorar o desempenho do SGLang sem modificações,

17:47 simplesmente porque fazemos algo no lado do batching que o SGLang não faz nativamente. Provavelmente, você poderia fazê-lo fazer isso se desenvolvesse plugins personalizados para o SGLang e coisas do tipo. Provavelmente conseguiria igualar nosso desempenho, porque poderia simplesmente incorporar a mesma lógica ao servidor principal do SGLang. Mas aí você estaria desenvolvendo código personalizado que só funciona com o SGLang. E a grande lição aqui, no caso dos modelos pequenos, é que os runtimes são muito diversos, certo? Você

18:17 não quer necessariamente ficar preso a um runtime específico, porque temos, acho, cerca de 50 adapters diferentes que parametrizamos para os diferentes modelos. Então, de algum modo, é preciso lidar com essa complexidade subjacente, e provavelmente não é criando vários plugins para um runtime específico. É provável que a solução seja algum tipo de abstração, que, no nosso caso, é esse conceito de sidecar em Rust e o socket.

18:48 Agora vou falar de alguns números diferentes. Em termos da linguagem usada em benchmarks, o “joelho” é o conceito de que, quando você aumenta o tráfego em um servidor — isto é, solicita cada vez mais vazão —, ele fornece cada vez mais vazão. Nesse ponto, a curva sobe de forma mais ou menos linear. Então, chega um momento em que você pede cada vez mais, mas não recebe mais. A curva fica plana e a latência aumenta. Chamamos esse ponto de “joelho”, e é um conceito útil em benchmarks, porque é mais ou menos

19:19 o ponto de saturação, certo? É o desempenho máximo sem prejudicar a latência. Para dar uma ideia do que é possível com hardware relativamente pequeno e com diferentes tipos de modelos pequenos: isso foi medido na RTX Pro 6000. Trabalhamos com Nvidia L4, A100, RTX Pro 6000, H100, nessa faixa. Mais uma vez, essas GPUs estão muito mais disponíveis sob demanda em qualquer nuvem. Basicamente, há cotas na maioria dos continentes. E, com esse tipo de equipamento,

19:50 você consegue, no caso de modelos de embedding com até, digamos, centenas de milhões de parâmetros, codificar centenas de milhares de tokens por segundo em embeddings. Imagine que você esteja enviando texto para a API de embeddings de texto da OpenAI. Em vez disso, poderia ter uma GPU e enviar meio milhão de

20:21 tokens por segundo para ela, obtendo os vetores, certo? Está fazendo sentido? Você envia meio milhão de tokens por segundo para uma única GPU, que nem é tão grande, e recebe embeddings vetoriais para seu sistema de busca, em vez de enviar tudo isso para um endpoint de embeddings gerenciado e pagar ordens de grandeza a mais, certo? E você consegue latências de, sabe, algumas dezenas de

20:53 milissegundos nessas chamadas. Se usar APIs da Cohere, da OpenAI e outras, elas levam centenas de milissegundos, certo? E isso não é nenhuma ciência espacial. Você pode ter uma economia enorme, melhorias enormes na latência e uma operação relativamente fácil, com algumas GPUs e uma infraestrutura em volta delas, certo? Então, isso é uma oportunidade muito fácil de aproveitar se você está começando a usar modelos open source. Modelos pequenos e embeddings são uma escolha óbvia,

21:26 certo? Mas não acaba aí. Digamos que você queira trabalhar com reconhecimento de entidades nomeadas, busca multivetorial, ou até mesmo com a taxa de geração de texto ou de saídas estruturadas. Você também pode obter, sabe, milhares de tokens por segundo de saída de modelos generativos específicos para cada tarefa — digamos, cerca de 500 por segundo em uma GPU, lá embaixo.

21:58 Então, digamos que você esteja gerando dados sintéticos ou anotações para seu fine-tuning e seus evals. Não faça isso em um endpoint gerenciado. Essa é uma tarefa perfeita porque você tem controle sobre ela. Pode avaliar a qualidade. É uma tarefa perfeita para um modelo open source na sua própria infraestrutura. E, se a infraestrutura em volta dessas GPUs for razoável, você terá escalabilidade linear

22:29 com o número de GPUs. Outra ideia, se você trabalha com serving de modelos pequenos, é que normalmente você tem um pool de workers para cada modelo, certo? Você tem um conjunto de workers, um conjunto de nós com GPUs, ativa esses recursos e pré-carrega os modelos. Os modelos levam dezenas de minutos para carregar porque têm centenas de bilhões de parâmetros. Então, você fica satisfeito: “Beleza, finalmente carregaram. Agora tenho um pool de workers.” Essa

23:00 mentalidade não funciona muito bem com modelos pequenos. Sim. Sim. Rápido: quanto tempo falta? >> Acabou. >> Ah, acabaram os seis minutos. Certo. Então, colocar modelos juntos na mesma GPU é mais rápido. Esta é uma história sobre como você ainda quer fixar alguns modelos, mas também quer fazer carregamento sob demanda e remoção de modelos conforme a pressão sobre a memória. É preciso descobrir como combinar as duas coisas. Tem um pouco

23:31 sobre pesquisa automática. Temos loops de pesquisa automática para adicionar suporte a novos modelos e melhorar o desempenho deles. Criamos muitas ferramentas internas para fazer as medições e alimentar esses loops de pesquisa automática, basicamente para continuar melhorando os números. E talvez o mais importante: quando lançamos o suporte a um modelo, todo o ajuste já está feito. Então, não é preciso dizer: “Certo, vamos fazer uma varredura de parâmetros.” Basicamente, incluímos uma configuração de ponta a ponta para o cluster inteiro. Esta é uma configuração

24:02 para o loop de pesquisa automática. Há um meta-loop que cria o harness, que então executa o loop, e há um painel que ajuda você a entender como ele funciona. Temos interfaces personalizadas para isso. Um dos resultados disso foi um LoRA cujo treinamento custou 80 centavos e que melhorou em 18% a qualidade da recuperação em um conjunto de textos jurídicos alemães, como prova de conceito. E é isso. Modelos pequenos são bons. São relativamente fáceis de servir. Eles são

24:34 na verdade, muito mais baratos e rápidos, e são igualmente inteligentes. Esse QR code leva ao repo do GitHub do nosso cluster, que acabei de descrever. Deixe uma estrela e bom self-hosting. Obrigado. [aplausos]

Transcrição original

[00:12] All right, I think you guys can hear me. I can certainly hear myself. Um, whoever came closer gets a t-shirt. I I meant it. There’s like back full of t-shirts over here. Uh, and also for questions. Maybe there will be some questions at the end. If you ask a question, you get the t-shirt as well. And if you can guess what is on the background of this slide, you get a uh you get the t-shirt as well. Any guesses?

[00:42] What does that visualize? This picture in the background? No. Anybody has seen a transformer model? >> Uh yeah, positional encoding. Very good. You get the t-shirt, sir. All right. So, today we’ll discuss u basically small open source models and how they are pretty good now and how they create unique challenges when you want to serve

[01:13] a bunch of them in your own cloud. Uh everything we’ll discuss is kind of open source. Uh do it yourself. This is the kind of stuff you can just uh you know run a command and own the stack. So there is no proprietary uh you know pieces of the puzzle here. Uh let’s get this uh underway. Well, this works. Okay. So small models. What do we mean by small models? Um you know depending who you ask, the way I

[01:43] think about it is basically models that you can run on two three generations old Nvidia hardware. The whole model fits into one GPU. um and therefore they are easy to serve those GPUs are available and they are affordable as well. Um and then most people think okay small models um there will be some kind of tradeoff in terms of um you know quality of the results and hopefully I’ll be able to do a good job in this talk to convince you that

[02:15] actually for specific tasks you can be at frontier or beyond frontier performance and get all the other obvious benefits right uh orders of magnitudes of uh kind of cost savings and uh potentially quite big uh latency or throughput improvements of course. Um so this is kind of one of the charts we like to show. This is the artificial analysis intelligence index over time. And what they typically don’t show you

[02:45] is that there is like a breakdown of the open source models you should think about right there is the GLM 5.2 and so on those kind of frontier open source models with let’s say 750 billion parameters. Um but then there are the small open source models kind of trailing the big ones and trailing the frontier. You can see the frontier is kind of getting diminishing returns these days and the small models are catching up right. So uh you see this kind of convergence saturation on top and and kind of growth of the of the

[03:16] small models um and you know let’s say quen 3627b somewhere around the performance of GPT 5.1. So if you have a workflow, if you have a pipeline that uh you know can run with GPT 5.1, now you can move that to a small model and uh you know get all the all the benefits we discussed. So small models not dumb anymore. Um now it is also about how you use the small models, right? So you can’t just treat

[03:46] that 27 billion parameter quen 36 as your kind of totally generalized I can prompt it to do anything kind of model. Now you need to adopt the approach where um you basically figure out slice of tasks from the generalized model workload and then per task you figure out which model in the open source fits the task the best. You run some evals maybe some adaptation we’ll discuss um and then you know that’s how you kind of reach the the right quality uh to actually push this into production. So here is some example of a contract

[04:18] review agent that uses you know nine different models. This is the kind of shape that you will see in your workloads in your agents as you move to using small models for your um setup. you’ll start to see that okay instead of kind of hammering one API with bunch of different requests uh or one model you rather use a fleet of models and then your problem is okay how do I serve all of these different things in a way that my infra people don’t go crazy right and this is just one of the agents that you might be running and there might be you

[04:49] know 10 of these in your company so how do how do we sort of you know that’s the kind of expansion of infrastructure scope let’s say um Now all of those different tasks that I mentioned there is an open source model that’s uh sitting there waiting to be used um from you know OCR to question answering on top of documents to labeling images generating SQL you know reviewing code uh there are open source models fine-tuned and trained for those tasks

[05:19] uh you know if you use an open source model that’s trained to do OCR on receipts in Vietnamese that project has seen the most receipts in Vietnamese, right? There’s somebody who like took the time to gather as much data as possible and on that task that model will outperform pretty much anything else. Um, and there is, you know, hundreds of thousands of models on hagging phase that look like that, right? So, it’s just uh it’s all sitting there and it’s all free basically mostly quite permissive licenses. So the models exist you know that that’s not the

[05:50] bottleneck and you know we’ve been talking about like open source AI since 2024 and uh it’s so far still not really happening and to the extent it’s happening in companies it basically equals like open source AI equals AWS bedrock uh except when you look at the model catalog in bedrock it’s like very you know restrained in model types that are available these models are old uh often you two, three years behind the state-of-the-art. Um, and when you do

[06:21] any kind of fine-tuning in bedrock, you don’t actually own the fine-tuned or trained artifacts. So, you can’t, you know, use it as an actual advantage in your business. It kind of stays serving from the bedrock infra. Um, so that’s on the proprietary. Now if you do small models serving on open source infrastructure blm sglank different solutions just know that these things are not tuned for any specific model or any specific hardware model combination you’ll have to do the tuning right this is the do-it-yourself all of

[06:52] these tools ship with guides on how to actually do the tuning the parameter sweep tailoring to your traffic and so on. This is a kind of open-ended research project every time you try to adopt one of these tools. So this is not really something that sort of you you take it and it’s like an engineering project and a week later you have a high performance surveying infrastructure doesn’t work like that. Um and that’s kind of the typical problem with open source tools, right? This kind of like a little bit too much do it yourself. Um,

[07:24] and then on top of this not being kind of pre-tuned for small models, the small model workloads and traffic that uses a bunch of different models kind of flips the equation for inference uh kind of clusters, right? So normally when you try to serve one big model, um, your problems are how do I share that model across multiple GPUs? How do I have a router sitting on top that understands the state of all these workers? you know the KV cache state and so on and then makes a top- down routing decision of

[07:55] okay this request goes to this worker or this group of workers and and so on right it’s very top down setup but if you have small and fast requests and you have many of them the this this sort of top down routing becomes the bottleneck right because the router has a little bit obsolete version of the worker state and it’s just really hard to saturate the workers if you have that kind of upfront decision on that’s that has to get it perfectly right in terms of u you know balancing the local cues on each of

[08:26] these workers because there’s many small requests right um and you know like we have experimented with the VLM and SGline routers for small models and this sort of traffic and it’s very hard to get your GPU utilization beyond 20 30% under constant load and the problem is that those batches are just not correctly sized basically because you that routing bottleneck. Um, and then the third problem is that with small models, you benefit a lot from Loras and

[08:56] just model adaptation in general. And so the traffic that you have to serve, you know, contains, you know, people coming to you and saying, “Hey, I have 10 loras. How do I, you know, use this with our serving stack? Um, or I have this custom fine tune I made last night. You know, um, I I want to serve this in production.” And this conversation between the AI engineer and the infrastructure person in getting those you know lauras up there custom models up there that’s the thing that takes time and basically that’s like the main

[09:26] killer in organizational uh velocity is talking right like ideally you would want the infrastructure engineers to do their job and you would want to those AI engineers to do their job and they don’t have to talk to operate on the day-to-day mode. So, so you know they they are not blocking each other basically. Um and this kind of model adaptation desire around small models kind of breaks that and creates a lot of back and forth and uh that’s a problem right uh so these are some challenges related to okay we have a bunch of small

[09:58] models how do we have a cluster how do we serve this efficiently um so we have been playing with this problem for a while I’m Daniel actually from superl I kind of skip the intro um so we are you know VC backed company out of SF and we have been building AI powered search and document processing systems and and agents for the last couple of years and our main painoint has always been inference. um specifically these problems that I have described. And so we have iterated and

[10:28] iterated and explored different topologies for clusters for uh running you know large wide fleets of small models in different environments because sometimes you need to deploy together with some platform in some environment where who knows what is available there. um you know the small models make it easier because in whatever environment you can get some L4s or some kind of small GPU quota is much easier. So this is kind of I’ll describe a little bit about the topology of the cluster that we have kind of converged to and by the

[10:59] way this whole thing is Apache 2.0 So completely open source. Um you guys can just take it and wrap it and now we are an inference startup. Um this is open source from kind of the control plane all the way down to the thing that runs on the GPU. Um so we we didn’t pull any any punches. Uh and the topology is basically there is a gateway and instead of having a router that kind of predecides what goes where there is a gateway that parses some of the request and attaches some metadata to the

[11:31] request inserts that request into a shared queue and into some side channels. I’ll go a little bit into that and then the workers pull from that centralized queue instead of kind of pushing the data down to the workers. And this way they can saturate themselves better. And then the worker um setup I think I have a slide for that uh will describe how uh we basically absorb the complexity of different model architectures into kind of a coherent set of workers that you know don’t have

[12:01] like competing Python requirements and stuff like that. Um so that’s kind of the overall topology. Um and this is kind of life of a request. So maybe just uh I’ll call out a couple of things from here. Um we you know one of the things we don’t like about the OpenAI kind of API standard is the B 64 encoded kind of JSON not good for small models not good for high throughput. So we use message pack throughout like a binary format. Um

[12:32] this way we can also push all the multimodel data through the actual API gateway. So there is no like hey you know binary data over here and then request over here and then the cluster needs access to your cloud storage to start loading some b some binary data images or videos. We kind of encode it all and we push it through the gateway. Um and then the gateway kind of separates some of these heavier pieces to not clog the internal queue and differs it on cloud storage kind of inflight while the request is in Q. So

[13:03] it kind of splits up some of these requests that are let’s say over a megabyte and then uses cloud storage in the back end. Um but as a user you push all your bits and byes into the API layer and it’s kind of clean interface because of that. Um basically the whole stack is rest. So gateway rest the the worker is rest and then over a socket locally it kind of attaches to different runtimes and we have basically pytorch kendle and sglank

[13:34] on the as as a runtime um and and then when we do the optimization I’ll kind of go into that on how we make sure that whichever runtime we are using and whichever code is running in that runtime is the most efficient one. we have an auto research loop for that basically. Um but yeah, so so life of a request kind of looks like that. And like one tidbit is that you really want to make sure that the gateway that’s kind of the first thing that’s hit by the request doesn’t do too much work

[14:06] because then it becomes a bottleneck, right? So you don’t even want to parse the whole request. You want to be able to kind of look at the packets and uh figure out the general shape of what’s coming. do the annotation and then you have the workers however many workers you have hundreds of GPUs that that uh look at the queue state and then pull from there and and the queue we use u nats jetstream and that thing can do you know million requests per second like that’s very hard for that to become a bottleneck

[14:37] um so yeah like ideally you don’t want to serialize this serialize as you go through all of these different components that’s basically the kind of obvious thing. Um this is a little animation that shows the idea behind the centralized queuing, right? So instead of the top down router trying to uh you know fill in the local cues just right, which is basically impossible. um you know the the whole idea is hey can we somehow centralize the queueing and can the workers uh rather pick up the task

[15:08] of forming their own batches with their own prediction of the cost of the batch uh and and then you know become much more efficient. Now one tidbit and kind of side note once you kind of start working on these things uh you realize that it’s actually really hard to predict u how many things to pick up from that share queue for the batch to be really like really the optimal size and so you would want some mechanism that sort of allows you to put some things back into the queue if you figure out oh like I pulled a little bit too much and that’s a network hop right so

[15:40] that’s a problem and we have special optimization for that for machines that have multiple GPUs locally, right? So there is a there is additional kind of machine local queueing element that takes advantage of the fact that the local processes that run on the multiple GPUs on one machine can kind of negotiate with the queue a little bit back and forth which over the network you know there’s like milliseconds extra that that would add and so uh we we don’t do it over the network only when we collocate the um workers on multiGPU

[16:11] machines and you know the I mean we are not talking about like 5% differences here Right? So like you centralize the queue and now you get double the throughput of the cluster. So this is this is uh significant. Uh I mentioned three different runtimes. So basically it’s either you know we write let’s say for models that are encoder only we write the the PyTorch code and we kind of optimize it and we have a auto research loop that optimizes it. Same for Kendall. We started to play with Kendall not too long ago. We still can’t get it

[16:43] to perform anywhere near the PyTorch performance. So it’s a little bit more of a research project. It’s just the dependency like you know the worker Docker image with PyTorch is like 12 GB and the worker do basically binary statically linked binary with Kendall is maybe like 10% of that right and if you care about uh kind of waking up from the cold state and loading these images on bunch of different machines the you know going from 12 gigs to a gigabyte or something like this makes makes a huge difference. So that’s kind of the

[17:14] motivation behind Kendall. It’s just the the getting the same performances from PyTorch is is is really hard. And then SG lang we have there as a kind of uh go to baseline like we should perform as at least as well as as SGANG with the optimal tuning of all of those parameters that I mentioned that you have to do the tuning. Um here is some numbers. So for example when we wrap SG lang with the socket and with our kind of RAS side car um actually we can improve on the bare sglank performance

[17:47] just because we kind of uh do something on the batching side that natively sglang doesn’t do and probably you can make it to do that if you do like if you develop custom plugins into sglang and stuff like that like probably you can match our performance because you know you can just push the same logic into the SG Glang core server uh but now you are developing custom code that only works with SGLAN and the whole lesson here from small models is that the runtimes are super diverse right you

[18:17] don’t want to necessarily get staged with any one particular runtime because there is you know we have I think on the order of 50 different adapters now that that we parameterize for the different models and so you need to somehow deal with this kind of underlying complexity and it’s probably not by building a bunch of plugins for one specific runtime it’s probably some kind of abstraction uh which in our case is this rust site car concept and then the socket um

[18:48] now I’ll talk about couple different numbers but in terms of like language around benchmarking you know the knee is this concept of like when you ramp up traffic on a server uh when you sort of request more and more throughput from it and it gives you more and more throughput that’s when you go kind of linearly up and And then at some point you hit this point where you kind of ask for more and more is not coming. So you kind of flatten out and the latency goes up. So we call that the the knee and it’s it’s like a useful concept in in benchmarking. Uh because that’s kind of

[19:19] the point of saturation, right? That’s that’s kind of the maximal performance without hurting latency. Um so just to give you some ideas of what is possible on relatively small hardware, right? And different types of small models. So this is measured on the RTX Pro 6000. We we kind of work with Nvidia L4, you know, A100’s, RTX Pro 6000, H100, that sort of range. Um, again, those GPUs are much more readily

[19:50] available kind of on demand in any cloud. Basically, most continents have quota, you know. Um and on this kind of stuff uh you can basically get uh for embedding models even up to let’s say uh hundreds of millions of parameters you can get hundreds of thousands of tokens per second encoded into the embedding right so imagine you are sitting there now like hitting your text embedding tree on open AAI API instead you could be like having one GPU and push half a

[20:21] million tokens per second into that thing and get the vectors out right like is this like connecting right you have half a million tokens that you are pushing into single GPU that’s not even that big per second and you are getting out vector embeddings for your search system as opposed to like pushing all of that into a managed embeddings endpoint somewhere and paying like orders of magnitude more money right and you can get latencies like you know low tens of

[20:53] milliseconds for these calls like if you use uh you know cohhere openai APIs and so on these are hundreds of milliseconds right and and this is not rocket science you know you can have just like massive costsaving massive latency improvements and relatively e easy operation um with with like handful of GPUs and some some infra around them right so this is like really low hanging fruit if you start anywhere with open source models small models embeddings are like no-brainer,

[21:26] right? Uh but it doesn’t end there. So let’s say u you want to look at uh named entity recognition, you want to look at let’s say multi vector search u even generation rate uh of text or structured outputs and so on. um you you can be getting you know thousands of tokens per second output from uh you know task specific generative models as well per uh like let’s say half a thousand per second for for one GPU there at the

[21:58] bottom um and so let’s say you are generating synthetic data you are generating annotations for your finetuning for your evals you know don’t do that on a on a managed endpoint That’s a perfect task because you have it kind of under control. You can survey the quality. That’s a perfect task for uh open source model on your own infra. Um and then you like if the infra you have around those GPUs is like reasonable you’ll get linear scaling

[22:29] with with the number of those GPUs. Um now another sort of u idea if you are into small model serving uh is that you don’t you know normally um you have kind of worker pool per model right you have a set of workers set of nodes uh they have GPUs you kind of bring those up you preload the models the models load for tens of minutes because there are hundreds of billions of parameters uh and so you’re happy okay they finally loaded now I have a worker pool this

[23:00] mentality doesn’t really work with small models. Yeah. Yeah. Quickly. How how what’s the time left? >> Over. >> Oh, six minutes is over. Okay. All right. So, pack models on the same GPU is faster. Um, this is a story of how you still want to pin some models, but you want to also do u basically uh lazy loading and eviction uh as a kind of function of memory pressure. You want to figure out how to combine the two. Um there is a little

[23:31] bit about kind of auto research. We have auto research loops for uh adding support for new models and for their performance. Um we build a lot of internal tooling to do the measurement to feed into those out research loops to basically push the numbers forward. Um and maybe perhaps most importantly when we ship support for a model it has all the tuning done right. So there is no okay let’s do a parameter sweep. We bundle basically a config for end to end the whole cluster. Um this is a setup

[24:02] for the auto research loop. There is like a meta loop that builds the harness that then runs the loop and there is a dashboard on top that helps you understand how it works. Um, we have custom UIs for that. And one of the outputs of that was a Laura that took 80 cents to train and it improved 18 it improved quality of retrieval on German legalist STEX as a proof of concept by 18%. And that’s it. So small models are good. They are relatively easy to serve. uh they are

[24:34] actually much cheaper, faster, is as smart and that QR code goes to the GitHub repo of our cluster that I just described. Give us a star and happy self-hosting. Thank you. [applause]