O que torna os modelos abertos rápidos em produção — Sujee Maniyam, Nebius

Ver no idioma original →

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: What Makes Open Models Fast in Production — Sujee Maniyam, Nebius · Canal: AI Engineer · 19:54 · Assistir no YouTube

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

Resumo

Sujee Maniyam e Dylan apresentam a Nebius Token Factory e explicam como a integração entre infraestrutura, otimização de modelos e serving pode facilitar a operação de modelos abertos em produção. A plataforma conecta inference, análise de dados, pós-treinamento e deploy em um ciclo contínuo de melhoria. A palestra detalha técnicas como roteamento com consciência de cache, spec decoding, KV cache, separação de prefill e decoding e quantização. O objetivo é melhorar velocidade e custo sem exigir que cada equipe gerencie toda a infraestrutura por conta própria.

Pontos-chave

• Modelos abertos podem ser competitivos com modelos proprietários e, em muitos casos, custar menos.
• A Nebius Token Factory combina inference gerenciada com controle e otimização da infraestrutura.
• A plataforma conecta inference, análise de logs, pós-treinamento e deploy em um ciclo de melhoria contínua.
• O desempenho depende da escolha do engine e do roteamento adequado para cargas de trabalho diferentes.
• Roteadores com consciência de cache ajudam a direcionar solicitações para GPUs que já armazenam os dados necessários.
• Spec decoding usa um modelo menor para propor tokens e um modelo maior para verificá-los.
• O KV cache evita recalcular tokens e pode ser transferido para memória convencional quando a memória da GPU é limitada.
• Separar prefill e decoding em conjuntos distintos de GPUs pode reduzir a competição por recursos.
• A quantização é ajustada para equilibrar eficiência e qualidade do modelo.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação da Nebius e da Token Factory	Dylan apresenta a empresa, sua infraestrutura de IA e a proposta de inference gerenciada da Token Factory.
04:14	Plataforma integrada para produção	A apresentação percorre as camadas de inference, análise de dados, pós-treinamento e deploy, conectadas em um ciclo de melhoria.
10:01	Modelos abertos e infraestrutura de serving	Sujee argumenta que modelos abertos podem competir com os proprietários e explica a escolha de hardware e engines para servi-los.
13:08	Roteamento com consciência de cache e spec decoding	A palestra aborda o roteamento de cargas de trabalho de LLM e o uso de modelos menores para acelerar a geração com spec decoding.
15:44	KV cache e separação de etapas	Sujee explica como o KV cache, o armazenamento fora da memória da GPU e a separação entre prefill e decoding podem acelerar inference.
18:20	Quantização e encerramento	A apresentação conclui com o equilíbrio entre eficiência e qualidade na quantização e um convite para experimentar os modelos na plataforma.

Citações

Você tem o controle e o desempenho do self-hosting com a simplicidade de um serviço de inference gerenciada. — 03:11

A inferência flui para o treinamento, e o treinamento flui diretamente para produção. — 05:47

Um modelo menor gera os tokens, e o modelo grande os verifica. — 14:41

Vimos acelerações de 5 a 10 vezes — não de 5 a 10 por cento. — 16:46

Conceitos e entidades

• Nebius (empresa): Empresa de infraestrutura de IA que opera data centers e oferece serviços de inference.
• Nebius Token Factory (ferramenta): Plataforma de inference gerenciada que conecta execução de modelos, análise de dados, pós-treinamento e deploy.
• Sujee Maniyam (pessoa): Developer advocate da Nebius que apresenta as otimizações de serving e inference da palestra.
• Dylan (pessoa): Apresentador da Nebius que introduz a empresa e a plataforma Token Factory.
• spec decoding (conceito): Técnica em que um modelo menor gera tokens que são verificados por um modelo maior.
• KV cache (conceito): Cache usado durante a geração para evitar recalcular informações já processadas.
• quantização (conceito): Redução da precisão numérica de um modelo para melhorar sua eficiência, equilibrada com a preservação da qualidade.
• NVIDIA (empresa): Empresa de chips e sistemas de computação mencionada como parceira de infraestrutura da Nebius.

Tradução completa (pt-BR)

00:01 [música] Obrigado por se juntarem a nós hoje. Eu sou Dylan. Estou aqui hoje com meu colega Suji. Eu lidero o marketing de produto da Nebius Token Factory, e estou aqui com Suji, que é defensor de desenvolvedores. Vamos falar um pouco sobre engenharia de LLMs open source para produção. Antes de começarmos, quero dizer algumas palavras sobre o que vamos

00:31 abordar hoje. Temos apenas 20 minutos, então vamos tentar ser breves. Vamos fazer uma rápida apresentação de quem somos e do que fazemos. Depois, vamos falar sobre o que é necessário para criar a infraestrutura de inference. Também vamos dizer algumas palavras sobre otimizações de preparação de modelos, que são extremamente importantes no nosso trabalho. Por fim, vamos falar sobre otimizações de serving de modelos. Mas, antes de começarmos, quero dizer algumas palavras sobre quem somos e o que fazemos. Trabalhamos na Nebius, mais especificamente na Nebius Token Factory. A Nebius é uma empresa de infraestrutura de IA em nuvem de ponta a ponta.

01:03 Isso significa que não apenas disponibilizamos APIs de modelos: também operamos a camada física de IA e a infraestrutura que ficam por baixo. Temos nossos próprios data centers e sistemas da Nvidia, capacidade bare metal, nuvem gerenciada e otimização de serving e inference por meio da Nebius Token Factory. A linha superior trata principalmente de escala e confiança. Somos uma empresa de capital aberto na NASDAQ, com sede em Amsterdã. Temos uma relação próxima com a Nvidia, que fez um investimento de US$ 2

01:33 bilhões na Nebius alguns meses atrás, e temos como meta atingir 5 gigawatts de sistemas da Nvidia até o fim de 2030. A linha inferior trata mais do controle da stack. Essa é uma vantagem bastante significativa que temos. Operamos nossos próprios data centers na União Europeia e nos EUA, com bare metal em vez de nuvem compartilhada. Fomos um dos primeiros a adotar o Nvidia Rubin, CP e armazenamento BlueField, e estivemos entre as primeiras nuvens europeias a operar Blackwell Ultra AGXP300 e GB300 em produção. Também temos

02:08 contratos sólidos com a Microsoft e a Meta, acordos que mostram que as maiores empresas de IA já estão construindo esse tipo de capacidade conosco. E o último ponto é bastante importante. É realmente a ponte essencial para esta palestra: a integração vertical, do silício ao serving, na qual nos apoiamos. Hoje, estamos falando da Nebius Token Factory. A ideia é realmente projetar IA para produtos. Somos uma empresa de inference gerenciada, o que significa que implantamos esses modelos e os otimizamos para nossos clientes.

02:41 Percebemos algumas coisas no mercado atual de serving de LLMs open source. Em geral, as equipes de IA ficam presas entre duas opções ruins. APIs fechadas são muito fáceis de começar a usar, mas muitas vezes você atinge um limite rapidamente e não consegue ajustar o modelo ao seu caso de uso específico. Você compartilha a infraestrutura com todo mundo. Então, ela funciona como uma caixa-preta, e os custos crescem em linha reta, sem que haja uma forma real de otimizar as coisas. A outra opção é hospedar tudo por conta própria. Obviamente, isso é bem interessante. Dá controle total sobre o modelo, mas é um

03:11 projeto de engenharia enorme. Você realmente precisa de uma equipe dedicada para manter tudo funcionando. E, em geral, ainda faltam meses para chegar à produção antes mesmo de começar a desenvolver seu produto. A Token Factory representa uma mudança: esse terceiro caminho que identificamos antes mesmo de você começar a trabalhar no seu produto. Você tem o controle e o desempenho da hospedagem própria, com a simplicidade de um serviço de inference gerenciada. Fazemos o trabalho pesado, o trabalho difícil de infraestrutura, e os clientes mantêm o foco no produto. Isso libera três aspectos principais dos modelos: desempenho, custo e comportamento.

03:43 Como vimos, a diferença entre os modelos proprietários e os modelos open source diminuiu bastante. É nessa área que atuamos e onde nos sentimos à vontade para trabalhar: não apenas contando com o fato de que essa distância está diminuindo, mas também descobrindo como fazer isso funcionar nos seus próprios casos de uso em produção. Esse é realmente o núcleo da Token Factory. Construímos uma plataforma de IA de ponta a ponta. A maioria das plataformas que vimos no mercado oferece inference, treinamento ou ferramentas de dados, mas nós

04:14 decidimos conectar tudo em um único ciclo. Temos várias ferramentas que ajudam a viabilizar isso no lado da inference. Permitimos que você execute modelos em produção. Temos mais de 60 modelos na plataforma: GLM, Kimi, DeepSeek, entre outros. Temos endpoints dedicados e diferentes variantes dos modelos, dependendo de você querer executá-los rapidamente. Também temos ferramentas como saídas estruturadas, chamadas de função e uma API de processamento em lote. A segunda camada é o Data Lab. Ele permite capturar e estruturar os logs de produção. Vemos muitos clientes executando esses modelos

04:45 em produção, importando as conclusões e querendo uma maneira de analisá-las em detalhes. É isso que permitimos com o Data Lab: importação de logs de inference, dados SQL, filtragem de conjuntos de dados, versionamento de conjuntos de dados, exportação e, depois, processamento em lote. A terceira camada é o pós-treinamento. Permitimos ajustar, destilar e otimizar esses modelos. É um próximo passo natural depois do Data Lab: quando você tem seus logs e dados de inference e pode gerar conjuntos de dados sintéticos, pode levar tudo isso ao pós-treinamento e usar esses dados para adaptar os modelos ao comportamento esperado, com LoRA ou

05:17 fine-tuning completo. Também permitimos destilar modelos. Fazemos decodificação especulativa personalizada para clientes que precisam de ferramentas avançadas de decodificação especulativa personalizada. Fazemos quantização e calibração sob demanda e específicas para cada modelo, de acordo com suas preferências, e fazemos nosso próprio GPO. A quarta camada é a implantação. Depois de executar esses modelos e treiná-los, você precisa de uma maneira de implantá-los. É isso que nos permite levar os

05:47 modelos à produção na nossa própria infraestrutura. Para a maioria das equipes, normalmente isso significa escolher diferentes ferramentas e conectá-las. Mas isso gera muito atrito e dificulta as iterações. Isso reduz a capacidade de iterar. O que permitimos é que os dados fluam da inference para o treinamento, e que o treinamento leve diretamente à produção. Assim, você mantém um ciclo virtuoso para o seu produto. E essa é, na minha opinião, a principal diferença entre executar um modelo e executar um sistema de IA realmente pronto para produção.

06:22 Esta é uma pequena apresentação do que cuidamos para que você não precise cuidar. Executar modelos em produção é bastante complicado. Dá muito trabalho. Acredito que o valor da nossa abordagem está em três camadas principais. A primeira é a otimização. Ajustamos continuamente a forma como os modelos são executados para que os clientes tenham velocidades muito melhores e custos mais baixos, sem precisar descobrir tudo isso por conta própria. Fazemos o trabalho pesado de implantação e otimização dos modelos e permitimos que você simplesmente comece a usá-los.

06:52 Isso envolve otimizar latência, throughput e custo no nível do próprio mecanismo, porque você pode executar o mesmo modelo open source em provedores diferentes e obter resultados completamente diferentes em termos de custo. Há muito trabalho técnico acontecendo nos bastidores para que isso funcione, e Suji vai falar sobre isso daqui a alguns minutos. A segunda camada é a infraestrutura. O fato de sermos donos do hardware e o mantermos em funcionamento, além de controlarmos essa stack vertical, nos dá uma vantagem que a maioria dos provedores não tem. É uma questão de controle. Nós realmente…

07:23 controlar o que o modelo faz. Nós cuidamos de tudo que fica por baixo e damos aos clientes controle total sobre o comportamento; nós cuidamos da infraestrutura. A terceira camada é a prontidão para empresas. Acho que isso é muito importante aqui, porque parece meio óbvio executar modelos open source, mas é preciso ter várias maneiras de protegê-los e garantir que funcionem em um ambiente seguro. Então, há várias coisas envolvidas: segurança, conformidade e confiabilidade. Tudo isso são requisitos que essas grandes empresas geralmente têm. E elas precisam disso antes de poderem colocar qualquer coisa em produção.

07:54 E muitos provedores de IA fazem você descobrir tudo isso por conta própria. Nossa missão aqui é cuidar de tudo isso para que você não precise fazer isso. Algo que acontece bastante com as equipes de IA é que elas começam com inference: colocam um modelo para funcionar e logo percebem que executá-lo não é tão fácil quanto parece. E isso é só o começo da jornada para executar modelos open source em escala. Então,

08:25 elas realmente precisam entender como o modelo está se saindo no mundo real, e é aí que entramos. Elas querem melhorá-lo com o tempo. Precisam reimplantá-lo com atualizações sem causar problemas. E esse ciclo completo, de executar a observar, capturar e reimplantar o modelo, é o que realmente diferencia as equipes que lançam ótimos produtos de IA das equipes que lançam demonstrações. Acho que isso é muito importante de ouvir, especialmente ao falar de open source. A Token Factory cobre todo esse ciclo: inference para executar os modelos — como Kimi, DeepSeek e todos os principais — por inference em tempo real ou em lote, com saídas estruturadas e chamadas de função, e em endpoints dedicados quando necessário. Depois, passamos para os dados, para coletar e analisar os sinais do mundo real, as conclusões; em seguida, para o pós-treinamento, para melhorar e personalizar o modelo; e, por fim, para a última etapa, provavelmente a mais importante: o deploy, para enviar atualizações com controle total sobre o modelo. E é realmente muito importante para a maioria dos nossos clientes saber onde e como ele está sendo executado,

08:56 em quais chips está sendo executado, qual é o nível de quantização e todas essas coisas. É nisso que atuamos e onde nos sentimos à vontade. Descobrimos que hoje a maioria das equipes precisa combinar diferentes ferramentas para conseguir isso, então construímos uma única plataforma que tenta cobrir tudo de ponta a ponta. Enxergamos isso como um ciclo de melhoria contínua. A cada ciclo, sua IA fica mais específica, muito mais rápida e muito mais barata. Agora vamos falar sobre como escalar modelos open source para produção. Vou convidar Sujee ao palco para continuar.

09:26 Muito bem. Obrigado, Dylan. Certo, pessoal. Vou passar rapidamente por alguns destes pontos, mas fico feliz em conversar depois. Venham falar conosco se tiverem alguma dúvida. Acreditamos que uma ótima inference começa com ótimos modelos, mas isso não basta. É preciso ter uma ótima infraestrutura por trás para obter o melhor desempenho, e acredito que é isso que a Nebius Token Factory oferece. Muitas vezes me perguntam: “Isso é ótimo, vocês hospedam modelos open source, mas quão bons são esses modelos, afinal?”

10:01 E gosto de mostrar este benchmark. Ele é da Artificial Analysis. Os modelos em preto são proprietários, e os azuis são open source. O interessante é que dá para ver como os modelos open source são realmente competitivos e, às vezes, até melhores do que muitos modelos proprietários. Portanto, a diferença entre modelos proprietários e open source é muito pequena. Não precisamos ficar sempre atrás dos modelos proprietários para obter inteligência. Podemos simplesmente

10:33 escolher também um modelo open source igualmente inteligente e que, na maioria dos casos, acaba sendo muito mais barato, o que é ótimo. O que isso significa para os clientes? Vocês têm opções, certo? Podem executar esses modelos open source em qualquer provedor — esperamos que na Token Factory —, então não há dependência de um fornecedor e vocês também acabam economizando bastante nos custos por token. Aqui estão alguns exemplos de modelos que hospedamos. A tabela de cima mostra os modelos grandes. Nós os chamamos de modelos professores: são muito capazes, muito inteligentes, mas também meio

11:05 grandes. Também é possível usar modelos professores grandes para treinar modelos alunos menores. Então, vocês podem ver tanto modelos grandes quanto pequenos hospedados aqui. Quero estruturar um pouco a palestra em torno das camadas de hardware, de serving e de otimização. O Dylan falou um pouco sobre hardware. Trabalhamos muito de perto com a Nvidia e recebemos os chipsets mais recentes. Além disso, não apenas os mais recentes: também otimizamos kernels e runtimes. Assim, os modelos são executados

11:37 muito bem. Por exemplo, adotamos o padrão de ponto flutuante da Nvidia. Ele nos proporciona um ótimo desempenho dos modelos nos chips mais recentes da Nvidia. E, se pensarmos em serving de modelos, chegamos à camada intermediária, onde há algumas otimizações sobre as quais vou falar, começando pelos engines, porque é preciso ter um engine para servir o modelo. Usamos muitos engines open source. Temos nosso próprio fork interno, que ajustamos e otimizamos continuamente, e

12:07 vamos implantar o modelo no melhor engine possível. Nem todos os modelos funcionam igualmente bem em todos os engines. Então, descobrimos quais engines funcionam bem e implantamos os modelos de acordo com isso. Assim, como cliente, você pode simplesmente usar uma API sem precisar se preocupar com o tipo de GPU ou com qual engine, porque cuidamos de todo esse trabalho nos bastidores. E, quando há centenas de milhares de GPUs executando modelos, o balanceamento de carga e o roteamento se tornam um problema. Muitas vezes, as pessoas dizem: “Ah, isso é fácil, certo? É só colocar um

12:37 balanceador de carga na frente e enviar o tráfego aleatoriamente para GPUs diferentes”. Não é assim que funciona com LLMs, porque as cargas de trabalho são um pouco diferentes. Para dar uma ideia, nos primeiros tempos dos LLMs, as entradas eram pequenas: eu podia simplesmente pedir para escrever uma frase de uma linha, e a saída também era pequena. Mas agora vemos entradas bem grandes, como bases de código grandes que enviamos usando coding agents para refatorar, resumir ou analisar. Como vocês podem ver, as saídas podem variar de grandes a pequenas ou de grandes a grandes. E roteá-las adequadamente não é nada trivial. O que usamos são roteadores que levam o cache em conta. O que quero dizer com isso é que, se olharem para o lado esquerdo, verão que o cache, representado por cores diferentes, está fragmentado por toda parte. Então, nossa taxa de cache não é muito boa, porque minhas solicitações chegam aleatoriamente a GPUs diferentes, que podem ou não ter o cache. Mas, se olharem para a imagem à direita, verão que agora o cache está muito

13:08 mais organizado. Vejam, as cores ficam agrupadas, e o roteador sabe onde os caches estão armazenados e encaminha as solicitações de acordo com isso. Assim, quando executamos a inference, temos um cache muito bom e uma velocidade excelente. Outra coisa, e estamos muito animados com isso, chama-se decodificação especulativa. O desafio é que os LLMs geram tokens um por um: um, dois, três, quatro. E os modelos grandes demoram muito para gerar esses tokens. Então, a ideia

13:39 de grande para pequeno, de grande para grande, e encaminhá-los de acordo com isso vai lhe dar… sabe, não é trivial. Então, o que usamos são roteadores que, na verdade, levam o cache em conta. O que quero dizer com isso é: se você olhar para o lado esquerdo aqui, verá que meu cache, representado por cores diferentes, está meio fragmentado por toda parte. Portanto, nossa taxa de cache não é tão boa, porque minhas solicitações chegam aleatoriamente a diferentes GPUs, que podem ou não ter o cache. Mas, se você olhar para o da direita, verá que agora o cache está muito

14:10 mais organizado. Veja, as cores estão meio agrupadas, e o roteador sabe onde os caches estão armazenados e encaminha as solicitações de acordo com isso. Então, quando fazemos a inference, conseguimos um cache muito bom e uma velocidade muito boa. Outra coisa — e isso é algo que nos deixa muito animados — é chamada de decodificação especulativa. O desafio é que os LLMs geram tokens um por um: um, dois, três, quatro, certo? E os modelos grandes demoram muito para gerar esses tokens. Então, a ideia é

14:41 Decodificação especulativa: que tal usarmos um modelo menor, que muitas vezes é mais rápido e barato para gerar os tokens, e depois deixarmos o modelo grande verificá-los no final? É meio como se você fosse um engenheiro sênior e delegasse o trabalho a um engenheiro júnior. Ele faz o trabalho pesado, e você verifica o resultado. E isso, surpreendentemente, funciona muito bem em grande escala. Os modelos menores conseguem gerar tokens muito rápido, e o modelo grande pode verificá-los. Se estiver bom, terminamos. Se o modelo grande não gostar da resposta,

15:13 ele vai gerar os tokens novamente para você. Esse é o pior cenário. Mas, na maior parte do tempo, você terá um desempenho muito bom misturando modelos pequenos e grandes. Na verdade, incorporamos esse recurso ao token factory. Ele proporciona uma otimização de velocidade muito boa. Uma das coisas que experimentamos foi treinar modelos de rascunho. Você pode treiná-los usando dados sintéticos. Mesmo que os treine com dados genéricos, vemos melhorias de até 30%. Mas fica ainda melhor se você puder treinar

15:44 o modelo menor usando seus próprios dados, certo? Fazemos muitos experimentos nessa área e estamos lançando um recurso. Você pode treinar esses modelos de rascunho praticamente com um clique. Vamos coletar seus dados de produção e treinar os modelos de rascunho para você, o que é bem legal. Outra otimização que acontece nos bastidores é o cache KV. Essa provavelmente é uma das otimizações com maior retorno sobre o investimento na inference, porque criar tokens é caro, especialmente quando você os gera um de cada vez. E o bom senso diz que, depois que você

16:15 gera um token, ele não muda. Então, não há necessidade de continuar gerando o mesmo token repetidamente. A ideia é armazenar os tokens em cache. Para dar um exemplo, digamos que este seja meu prompt: “o gato sentou em”, certo? Digamos que esses sejam meus prompts e que eu esteja criando a próxima palavra. Assim que criamos o próximo token, armazenamos em cache. Da próxima vez que precisarmos consultá-lo, não precisamos gerá-lo novamente; basta consultar o cache. É bem simples, e isso acelera bastante o processo. Para dar uma ideia, nós

16:46 observamos acelerações de 5 a 10 vezes, não apenas de 5 a 10 por cento: na verdade, até 10 vezes, certo? Porque o armazenamento em cache funciona muito bem. A questão é que o cache consome muita memória, especialmente com nossas entradas grandes e janelas de tokens grandes. Uma coisa que estamos implementando no token factory é que, quando usamos o cache, podemos descarregá-lo automaticamente da memória da GPU — que é muito valiosa — e salvá-lo na memória normal, para depois trazê-lo

17:16 de volta. Então, não descartamos o cache que levamos muito tempo para construir. Nós o descarregamos e o trazemos de volta, e tudo isso é feito automaticamente. Você não precisa se preocupar em gerenciar o cache. Isso é feito para você nos bastidores. Essa é uma das otimizações importantes que fizemos para acelerar a inference. Outra é chamada de decodificação. Pense assim: há duas etapas em um LLM. Uma delas é preencher o contexto, o que exige muito da CPU; a outra é a decodificação, que exige muita memória.

17:48 E, muitas vezes, se você fizer as duas coisas na mesma GPU, elas vão disputar recursos computacionais. O que fizemos foi separar essas duas fases. Um conjunto de GPUs faz o preenchimento inicial, que é muito eficiente em termos computacionais, e outro faz a decodificação, que é muito eficiente em termos de memória. Depois, eles transferem o cache KV entre si. Vimos que isso funciona muito bem. Outra coisa que fazemos — e que já está incorporada à nossa plataforma — é quantizar os modelos.

18:20 Ao quantizar, reduzimos a precisão. Mas não queremos ir longe demais, certo? Porque, nesse caso, a qualidade do modelo começa a cair. Então, fazemos muitos experimentos para descobrir qual é o ponto ideal da quantização. Assim, você consegue executar os modelos de forma eficiente sem degradar demais o desempenho. Tudo isso já está integrado, e há mais algumas coisas. Como o tempo está acabando, vou encerrar por aqui. Estas são algumas das coisas que abordamos: decodificação especulativa, cache KV e, quando você faz armazenamento em cache, o roteamento que leva o cache em conta, além de separar os casos de preenchimento inicial e decodificação.

18:52 Se você estiver usando uma API, talvez não perceba todo o trabalho que acontece nos bastidores, mas ele está acontecendo. É isso que torna uma plataforma de inference realmente ótima para servir especialmente os modelos grandes que estamos vendo, como os modelos de um trilhão de parâmetros. Por fim, quero mostrar rapidamente isto. Esta provavelmente é a lâmina mais importante da apresentação.

19:24 Tirem uma foto ou escaneiem o código rapidamente. Isso dará créditos para vocês na plataforma token factory, para que possam experimentar. Temos todos os modelos open source mais recentes: GLM52, kit K27s. Experimentem. Tenho usado muito esses modelos para programação ultimamente, e eles funcionam muito, muito bem. Se vocês usam Cursor ou OpenCode, podem integrar nossos modelos com muita facilidade ao trabalho de programação. Experimentem e nos contem o que acharam. Há um canal no Discord

19:54 na parte de baixo. Se tiverem alguma pergunta, podem publicá-la lá ou mandar uma mensagem para mim ou para Dylan. Ficaremos felizes em responder. Vou parar por aqui. Temos uns 10 segundos. >> [risos] >> Bem na hora, mas vamos ficar por aqui. Venham falar conosco se tiverem alguma pergunta. Ficaremos felizes em conversar mais e responder às perguntas de vocês. Muito obrigado a todos.

Transcrição original

[00:01] [music] Thank you for joining us today. Um I’m Dylan. I’m here today with my colleague Suji. So I lead the product marketing for Nibbius token factory and I’m here with Suji as a developer advocate and we’re going to talk a bit about engineering um open NLMs for production. So before we jump right in, um I want to give a few words about what we’re going

[00:31] to cover today. We only have 20 minutes, so we’ll try to keep this brief. Uh but we’re going to give you a quick intro on who we are, what we do. Uh then talk about what it takes to build the infra for inference. Um a few words on model shaping optimizations, which are extremely important in what we do. And then we’ll talk about model serving optimizations. But before we jump right in, I just want to give a few words uh about who we are and what we do. So we work for Nibbius. Uh so specifically Nibbius token factory but Nibbius is a like a full stack AI

[01:03] cloud infrastructure. Um so this means we actually not only exposing model APIs we run the actual physical uh AI layer and infrastructure underneath it. Um we have our own data centers and video systems uh bare metal capacity manage cloud and optimizing the serving and the inference through Nibius token factory. Um top top row here is really about scale and trust. So we’re a publicly traded company on the NASDAQ um headquartered in Amsterdam. Uh we’re very close with Nvidia who made a 2

[01:33] billion uh investment in Nebus a couple months ago and we’re targeting a 5 gawit of Nvidia systems by the end of 2030. Uh bottom row is really more about the control of the stack. This is a quite a a good edge we have. We operate own data centers across the EU and the US uh bare metal rather than shared cloud. We’re a very early adopter of Nvidia Rubin um CP like uh and bluefield storage and we were amongst the first European clouds to run both Blackwell Ultra AGXP300 and GB300 in production. Uh we also have um

[02:08] like strong contracts from Microsoft and Meta agreements that kind of show that the largest AR builders are already building this kind of capacity from us. Um and the last time is quite important. It’s the uh like really the important bridge to this talk is the vertical integration from silicon to serve that we um rely on. So today we’re talking about NEA token factory. So the idea here is to like really uh engineer AI for product. So we’re managed inference company uh meaning we deploy these models and optimize them for our customers.

[02:41] So we noticed a few things today in the market of serving open source LLNs. Um, usually most AI teams are stuck between choosing two bad options. Um, closed APIs are really easy to start with, but you often hit a ceiling really fast and you can’t really tune the model to your specific use case. Uh, you share the infra with everyone else. So, it kind of operates as a black box black box and the costs grow in a straight line with no way to really optimize things. The other option here is self-hosting. Obviously, it’s quite fun. Uh, gives you full control on the model, but it’s a

[03:11] massive engineering project. Um so you really need a dedicated team to actually keep it running. Um and you’re usually month away from production before you even start your actual product. So token factory is kind of the shift uh this third path we identified uh before you even start like on your um actual product. You get the control and the performance of self-hosting with the simplicity of a manage inference service. So we do the heavy lifting, the hard infrastructure work and then customers stay focused on their product. This really unlocks uh three main things performance, cost and behavior of the

[03:43] models. Um as we’ve seen the gap between proprietary and open source models has been closing a lot and so this is where we kind of operate and we feel comfortable um operating is really not only relying on the fact that this bridge and this gap is closing down but also figuring out how you actually make it work in your own production uh use cases. So this is really the core of token factory. uh we’ve built a full stack JI platform. Um most platform we’ve seen on the market either give you inference training uh data tooling but here we

[04:14] decided to connect everything under one loop. So we have a bunch of tools to that kind of unlock this on the inference side um we allow you to run models in production. So we have 60 plus models on the platform JLM Kimmy DC you name them. Um we have dedicated endpoints we have different flavors on the models depending if you want to run them fast. uh we have different tooling like structured outputs, function calling and batch API. Second layer here is the data lab. So this allows you to really capture and structure the production logs. So we see a lot of customers actually running these models

[04:45] in production importing the completions and wanted a way to kind of slice and dice through these completions and this is really what we allow with the data lab. So uh inference log imports SQL data like uh data set filtering, data set versioning, um exporting and then batching. These uh third layer is post training. So we allow you to kind of fine-tune distill optimize these models. So this is a natural follow-up with the data lab is once you have your logs and your inference and you can generate synthetic data sets you can bring them all to post training and use that to kind of either through Laura or full

[05:17] fine tuning make the models much more adapted to the behavior you’re expecting from. Uh we also allow model distillation. We do custom spec decoding for customers who need really advanced um custo custom spec decoding tooling. uh we do like on demand and like specific quantization and calibration of the model depending on your preferences and we do our our GPO and the fourth layer here is the deployment. So once you like run these models once you like train these models you need a way to deploy them. So these this is what allows us to push the

[05:47] models into production on our own um owned infra. So for most teams this is kind of usually a choice of different tools that you stitch together. But that’s creates kind of a lot of friction and need for iteration. It slows the need for like the the ability to iterate here. And so what we allow is really to make the data flow from u the inference to the training and the training flows directly into production. So that allows you to keep like a virtuous loop of your product. And that’s really what I think is the main difference between uh running a model and running an actual production uh AI system.

[06:22] Um so here is a little slide about what we handle so you don’t have to. Um so running models in production is actually quite complicated. It takes a lot of work and so I think uh the way we approach it the value here is in three main layers. The first one is the optimization. So we actively tune how models run so the customers get much better speed and lower co and lower costs without having to figure out um all of that themselves. Like we really do the heavy lifting around the model deployment and optimization and really allow you to kind of uh come in and just play with them.

[06:52] This is like all around optimizing latency, throughput and cost at the actual engine level because you could be running the same open source model on different providers and have completely different um results in terms of costs. So there’s a lot of technical stuff that goes on under the hood uh to make this work and Suji will cover that in a few minutes. Uh second layer is the infrastructure. So the fact that we actually own the hardware uh we keep it running. We own this like kind of vertical stack um gives us an edge that uh most providers don’t have. So it’s it’s it’s the control like we really

[07:23] control what the model does. Uh we handle like everything underneath and so we just give the the customers um the full control of the behavior and we take care of the infrastructure. Third layer is the enterprise readiness. I think this is really important here because like running open source seems kind of obvious but you need a bunch of ways to like secure like make it make sure it works in a secure environment. So there’s a bunch of things here. Um security, compliance, reliability, they all requirements that all these large companies usually have. Um and they kind of need those before they can ship

[07:54] anything into production. And so a lot of AI providers make you figure out all of these yourself. And uh our mission here is to really handle all of these so you don’t have to. Um something that comes up a lot with AI teams is that they start with inference. um they just get a model up and running and then they realize that pretty quickly quickly that running it is not just as easy as it seems and it’s only the beginning of your path through running open source models at scale. So

[08:25] they really need to understand how it’s actually performing in the real world and this is kind of where we come in. They want to improve it over time. Um they need to redeploy updates without breaking things. Um, and and that full cycle from running to observing to capturing and to redeploying the model is really what separates team from that ship like great AI products from team that ship demos. And I think that’s really important to hear especially when talking about open source. Um, and so token factory covers that full loop uh inference to run the models. So as I said, Kimmy, Deepseek, all the all the

[08:56] main ones uh through real-time inference or batch inference through structured outputs and function calling um and on dedicated end points when it’s necessary. Um and then moving on to the datab to collect and analyze the real world signal uh the completions, moving over to post training to improve and customize the model and finally moving to the last step and probably the most important one which is the deployment to push uh updates with full control over the model. And you actually really it’s it’s really important for most our customers to know where how it’s running

[09:26] and what chips it’s running on uh the level of quantization and all that stuff and that’s really where we kind of operate uh and are comfortable. Most teams today we figured have to stitch different tools together to get this and we actually built uh one platform that tries and covers it end to end. So we really see this as a continuous improvement loop. Every cycle makes your AR more specific uh way faster and much cheaper. And now we’ll dive into scaling open models to production. And I’ll invite Suji on stage to take it over.

[10:01] All right. Thank you, Dylan. All right, everyone. So, um I’ll zip through a few of these, but um I’m happy to um have a discussion afterwards. So, come and find us if you have any questions. So, we believe great inference starts with great models, but that’s not enough. you need great infrastructure behind the scene to get the best performance and I believe that’s what uh Nebio token fighter provides. Uh I get a lot of times I get asked like so this is great you guys host open models but how good are the

[10:33] open models really and I like to show you this benchmark here. Uh this is from artificial analysis. The black ones are proprietary models and the blue ones are open models. And the cool thing you can see here is how um the open models are actually very competitive sometimes even better than a lot of the proprietary models. So the gap between uh proprietary and open models is very narrow. Uh so we don’t really have to chase proprietary models all the time for the intelligence. You can just just

[11:05] as well choose an open model that’s just as smart and also ends up being much cheaper in most cases which is pretty cool. So what does it mean for customers? You get choice, right? You can run these open models in any provider, hopefully token factory, but so there’s no vendor lock in and also you end up saving a lot of money on tokconomics. And here’s a a few examples of models we host. Uh the top the top table is like the large models. We call them sort of the teacher models, right? They are very capable uh very smart but also kind of

[11:37] large. You can also use a large teacher models to train the smaller student models. So you sort of see the both large models and small models posted. So I want to sort of structure the talk a little bit um sort of the from the hardware layer, the serving layer and the optimizing layer. Uh so Dylan talked a little bit about hardware, we have we work very closely with Nvidia, we get the latest chipsets and uh not not just um the latest we also optimize uh kernels and runtimes. So the models run

[12:07] really uh really well. For example, something like the Nvidia floating point. standard we embraced it. It gives us a really good model performance on latest Nvidia chips. And if you think about model serving that kind of takes us to the middle layer and there are few optimization I’ll talk about uh starting with the engines because you need an engine to serve the model. Uh we utilize a lot of the open source engines. Uh we have our own internal folk uh that we continuously tweak and optimize and we

[12:37] will deploy the model on the best engine possible. uh you know not all the models run equally well on all the engines. So we figure out which engines run well and we’ll deploy the models accordingly. So as a customer you can just use an API not having to worry about you know which kind of GPU which engine because we take care of all that work behind the scene and uh when you have like hundreds of thousands of GPUs uh running models load balancing and routing becomes an issue. So a lot of the time people say oh that’s easy right we just you know put a

[13:08] put a load balancer in front um send traffic randomly to different GPUs uh that’s not how it works in LLMs because the workloads are slightly different for example just to kind of give you an idea uh in the early days of LLM the inputs were small I could just say write like a oneliner and the output is also small but now we are seeing your input could be pretty large like we are sending like large code bases uh as using coding agents to do like refactor or summarize or analyze right so the output as you can see can vary from like you know

[13:39] large to small large to large and routing them accordingly will give you um you know it’s not it’s not trivial so what we employ is we employ um routers that actually are cache aware what I mean by that is like if you look at the left side here you will see that my cache like different colors it’s kind of fragmented all over so our cache rate is isn’t all that great because my request landing randomly at different GPU use that may or may not have the cache. But if you look at the the one on the right, you can see that now the cache is much

[14:10] more coherent. See the colors are kind of together and the router knows where the caches are stored and it’ll route them accordingly. So when we actually do the inference, you get pretty good cache and very good speed. Um another thing and this is something we are really excited about. Um it’s called spec decoding. So the challenge is uh LLMs they generate tokens one by one one two three four right and then large models take a long time to generate these tokens. So the idea for

[14:41] spec decoding is how about we employ a smaller model which is a lot of the time faster and cheaper to generate the tokens but then have the large model verify at the end. So it’s kind of like if you’re like a senior engineer, you’re kind of farming out the work to a junior engineer. So they’re kind of doing the heavy lifting and then you are verifying the work. And this actually surprisingly scales really well. So the smaller models can generate tokens very quickly and the large model can verify and the and if it’s good, we are done. If the large model doesn’t like the the answer,

[15:13] it will actually regenerate the tokens for you. So that’s kind of the worst case scenario. But most of the time you will get pretty good performance out of this by mixing small models and large models. And this actually a feature we actually baked into token factory. Uh that gives you pretty pretty good optimization um speed. So one of the things we experimented we sort of trained graph models. Uh you can train them using synthetic data. Even if you train them using like you know generic data you get like you know we seeing like up to 30% improvement. But it it gets even better if you can train

[15:44] the smaller model using your own data. Right? So we do a lot of experiments here and u we are launching a feature feature. You can actually train these draft models almost like with one click and you know we will capture your production data and train the draft models for you which is pretty cool. Uh another optimization uh behind the scene is KV cache. Um this is probably one of the biggest ROI in doing inference because uh creating tokens expensive especially when you’re doing one at a time and the common sense is once you

[16:15] generate a token it it doesn’t change. So there’s no need to keep keep regenerating the same token over and over again. So the idea is we cache the tokens. So just to kind of give you an example here, let’s say this is my prompt the cat sat on, right? Let’s say the those are my prompts and I’m creating the next word and as soon as we create the next token, we cash it and the next time we need to look up, we don’t have to regenerate regenerative, we just look up the cache very easy and this actually speeds up quite a bit. So just to kind of give you some ideas, we

[16:46] have seen uh speed ups anywhere from 5 to 10x, not just 5 to 10 percentage, actually 10x, right? because caching really works well. Um the thing about caching is it takes a lot of memory right because you know especially with our large inputs large token windows and one thing we we we’ve been implementing in token factory is when we do caching we can actually uh because GPU memory is very precious. So we can offload caching out of GPU memory automatically save it in a regular memory and then bring it

[17:16] back. So we don’t like throw away the cache we spend a lot of time building. we actually offload it and bring it back and all of this is done automatically. So you don’t have to worry about managing cache. This is done for you behind the scenes. So and this is one of the um um one of the important optimization we have done to speed up inference. Uh another one is called decoding. Um so the way you think about this is like there are two stages to LLM. So one of them is like sort of fill in the context that is very CPU intensive and then other one is actually decoding that is very memory intensive.

[17:48] And a lot of the time if you do them in the same GPU they’re kind of computing for resources. So what we have done we sort of separate this two phases out. So one GPU set does prefill they are very you know uh compute efficient and the other one does uh boding that’s very memory efficient and then they sort of transfer the KV cache in between and we have seen this is actually working working out pretty well. And another thing we do and and this is already you know already baked into our platform we also quantize the models uh

[18:20] and when we do quantizing you know we are reducing the precision. So if but we don’t want to go too far right because then your model starts you know quality starts getting degrading. So what we do is we do a lot of experiments to figure out like what’s the kind of the sweet spot of a quantization. So you can run the models efficiently but not not degrade the performance too much. So, so all of these things are already built in and and there’s a there’s a few more and interest of time I’ll sort of wrap this up here and these are some of the things we kind of covered uh spec decoding KV cache and when you do

[18:52] caching doing um routing that is actually cache aware and also pre-fill uh you know uh separating prefill and decoding cases and if you’re using an API you may not realize all these works going behind the scene but they are right and this is what make up you know make a a inference platform really great to serve especially the large large models we are seeing like the one trillion models we are seeing and finally I want to quickly um give this out so we um probably this is the most important slide of the presentation so

[19:24] we can take the take a quick picture or scan the code uh this will give you some credit on token factory platform so we allow you for allow for you guys to try it out and we have all the uh latest open source models uh GLM52 kit K27s. Uh try them out. I’ve been using them them a lot a lot for coding lately and they work really really well. So if you’re using a cursor or open code um you can very easily incorporate our models to um for coding work. Try them out. Let us know. And there’s a discord channel um

[19:54] at the bottom. If you have any questions you can post them there or you can um you know um message me or Dylan. We will happy to um answer your questions. Uh so I’ll stop here. We have like 10 seconds. >> [laughter] >> right on time, but uh we’ll be around. Please come and talk to us if you have any questions. We’ll happy to um chat more and then take any take your questions. Thank you all.