Pare de adivinhar sua configuração do vLLM: benchmarking de LLMs na Runpod — Chris Vela, Runpod

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: Stop Guessing Your vLLM Config: Benchmarking LLMs on Runpod - Chris Vela, Runpod · Canal: AI Engineer · 16:00 · Assistir no YouTube

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

Resumo

Chris Vela apresenta o BenchPod, um template da RunPod para configurar e fazer benchmarking de modelos servidos com vLLM. A proposta é substituir configurações escolhidas no escuro por medições de desempenho em diferentes níveis de concorrência, considerando métricas como tempo até o primeiro token e latência entre tokens. A demonstração mostra como comparar configurações, acompanhar métricas e usar os resultados para planejar a passagem de experimentos para produção. Vela também destaca que o modelo de fronteira nem sempre é a melhor opção: a escolha deve levar em conta a tarefa, os custos, o hardware e as ferramentas necessárias.

Pontos-chave

Defina a tarefa e o perfil de uso antes de escolher o modelo, o tamanho da context window e a configuração de GPU.
Receitas padrão do vLLM são um ponto de partida, mas não garantem que a configuração seja adequada para produção.
O BenchPod centraliza configurações, experimentos e métricas de benchmarking em um dashboard.
Benchmarks com diferentes níveis de concorrência ajudam a comparar configurações e entender o comportamento sob carga.
No exemplo apresentado, aumentar o número máximo de batch tokens reduziu a latência entre tokens, embora tenha alterado pouco o tempo até o primeiro token.
A ferramenta registra métricas e permite acompanhar instâncias, além de facilitar a execução de testes antes de integrar o modelo a um agent.
Resultados medidos podem orientar a passagem de uma instância em pod para uma implantação com múltiplos nós ou serverless.
Um modelo menor pode ser mais adequado e econômico do que um modelo de fronteira, dependendo da tarefa e dos requisitos.

Capítulos

Início	Capítulo	Resumo
00:01	O desafio de configurar modelos para produção	Chris Vela apresenta o problema de escolher configurações de serving sem dados e destaca a importância de começar pelos requisitos da tarefa e dos usuários.
03:47	Apresentação do BenchPod	Vela descreve o template baseado em vLLM, que reúne configuração, serving e recursos de resiliência para simplificar experimentos e fluxos de produção.
06:02	Dashboard e demonstração	A demonstração apresenta métricas de GPU, CUDA, inicialização e tráfego, além de mostrar como acompanhar uma instância do modelo.
09:43	Comparação de configurações e resultados	O palestrante compara execuções com diferentes níveis de concorrência e mostra como o aumento de batch tokens afetou a latência entre tokens.
13:22	Da experimentação à escolha do modelo	Vela recomenda testar configurações e métricas relevantes antes de escalar, além de considerar modelos menores, custos e ferramentas.

Citações

Como você obtém dados de verdade e mostra que isso está funcionando corretamente? — 01:03

Eu não colocaria isso em produção logo no dia seguinte. — 03:17

É sempre melhor basear tudo em fatos. — 11:17

Não comece simplesmente pela receita do vLLM. — 13:22

Conceitos e entidades

Chris Vela (pessoa): Engenheiro de implantação da RunPod que apresenta o BenchPod e demonstra benchmarking de modelos.
RunPod (empresa): Plataforma de nuvem mencionada como meio de alugar GPUs e executar cargas de trabalho de desenvolvimento e produção.
vLLM (ferramenta): Mecanismo de serving de modelos usado como base para o template demonstrado.
BenchPod (ferramenta): Template apresentado para centralizar configurações, execução de benchmarks e acompanhamento de métricas de modelos servidos com vLLM.
Kimi K3 (modelo): Modelo citado na palestra como exemplo de modelo testado em instâncias da RunPod; a transcrição também associa a ele tarefas longas e de programação.
CUDA (ferramenta): Plataforma de computação da NVIDIA cuja versão pode afetar a compatibilidade e o funcionamento de um modelo.
B300 (modelo): Acelerador mencionado como opção de hardware para testar modelos na RunPod.
FastAPI (ferramenta): Framework citado como base da aplicação de API usada pelo template.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é Chris Bella. Trabalho na RunPod. Sou engenheiro de implantação em campo. Hoje vou falar sobre benchmarking de VLMs. É mais ou menos sobre a dificuldade que as pessoas enfrentam, especialmente quando sai um modelo novo. Vou compartilhar alguns aprendizados que tivemos internamente na RunPod e com clientes. Hoje vou mostrar para vocês

00:32 basicamente um dashboard construído sobre o vLLM. Na verdade, ele usa nossos pods. Para dar um pouco mais de contexto sobre o que a RunPod faz: estamos na nova nuvem. Facilitamos muito o aluguel de GPUs, desde P&D até workflows mais voltados à produção de serviços. Muitas vezes, o que vejo com os clientes, especialmente com vLLM, é que alguém quer o modelo mais recente. A pessoa não sabe como colocá-lo para funcionar, ou quer começar a usá-lo em produção e não sabe quais parâmetros ajustar. Ela

01:03 simplesmente usa a configuração padrão, e imagino que muitos de vocês já tenham visto receitas de vLLM. É um bom começo, claro, mas, especialmente nesse mundo, estamos sempre avançando rápido. Então, como chegar a um código com qualidade de produção sem simplesmente ir no feeling? A questão é: como ter dados de verdade? Como mostrar ao seu gerente, ao engenheiro sênior da equipe, que isso realmente é melhor e está funcionando corretamente? Então,

01:35 o que estou tentando dizer é que vejo muita gente simplesmente fazendo suposições. Muitas vezes, vejo pessoas usando a versão errada do vLLM. Talvez não estejam usando a versão nightly. O tamanho da context window está errado. Isso realmente depende. Acho que sempre é preciso dar um passo atrás e perguntar: o que você está tentando alcançar com seu modelo de LM? Ele vai ser um coding agent? Ou você só vai fazer resumos, tarefas bem básicas? Essa costuma ser a primeira pergunta que eu faria antes de você, sabe, usar o Kimi K3, ter

02:09 sabe, um milhão de tokens de contexto longo. Isso nem sempre é necessário. E, ao mesmo tempo, quantas pessoas vão usar isso? Muitas vezes, todo mundo tenta conseguir a menor quantidade de GPU pelo preço mais baixo. Mas, se você vai ter mais usuários simultâneos, precisa começar a pensar: como vou utilizar o cache KV? Há vários pequenos parâmetros de otimização que você precisa descobrir antes de colocar em produção. E, muitas vezes, estamos tentando avançar rápido. Então,

02:43 sim, como eu disse, na RunPod, facilitamos muito as coisas. É como uma VM. É conteinerizado com Docker. Você pode trazer sua própria imagem. Mas, no fim das contas, quem aqui já usou vLLM? >> Certo. Então, vocês sabem que, quando procuram, especialmente o Kimi K3, se usarem uma versão como a 0.27, não vai funcionar. Estamos avançando tão rápido que o código não acompanha. Vocês precisam da versão certa. E muitas vezes isso acaba virando um processo de CI/CD

03:17 que faz as pessoas, especialmente quem não entende o que está acontecendo, começarem a ter dificuldades. Elas começam a ver erros e perguntam: “Por que isso não está funcionando?”. As camadas internas ainda não foram escritas, ou o código ainda está em desenvolvimento. E, ao mesmo tempo, isso acaba sendo um problema: sai o Kimi K3 e, sabe, no dia seguinte eu ainda não o colocaria em produção. Provavelmente vocês vão ver muitas alucinações. Eu diria que, nesse estágio, ele simplesmente ainda não está pronto.

03:47 Então, o que proponho — criei uma coisa chamada BenchPod. Vai ser um template. Ainda não foi lançado. Basicamente, é construído sobre o vLLM. É um sistema completo de métricas. Dá para fazer benchmarking com facilidade. Muitos de vocês que conhecem o vLLM já conseguem fazer benchmarking, mas isso centraliza tudo, para que vocês possam ver tudo e mudar a configuração rapidamente. Uma coisa muito importante que percebi, especialmente entre as pessoas que usam nossos pods, é que

04:22 você configura tudo, mas depois precisa reiniciar a imagem. Precisa esperar os cold starts. É todo esse processo de carregamento, e você não avança tão rápido. Fica esperando uns 30 minutos para o Kimi AI 3 baixar os weights e carregá-los na GPU. É tempo meio desperdiçado. Quer dizer, se você tem um agent, sabe, não se importa muito, mas isso é um ponto de dificuldade, especialmente quando estamos tentando avançar rápido. E, ao mesmo tempo, o legal da RunPod é que você consegue encontrar essas máquinas. Então, se você tem a dúvida “Quero executar o Kimi AI 3 em uma B300”, temos B300s, e você pode começar a

04:55 não apenas ler sobre isso. Você pode começar a testar de verdade e ver se essas métricas são confiáveis. Então, sim, como eu disse, o BenchPod é mais ou menos uma imagem Docker do vLLM OpenAI API. Vamos ter todas as versões disponíveis. Temos um pequeno payload que basicamente cria toda essa aplicação FastAPI. Você pode usá-la com seus agents. O legal é que você pode servir modelos e especificar quais modelos

05:29 quer disponibilizar. Também temos um watchdog completo, que faz a recuperação automática. Então, se você estiver começando a usar isso em produção, não precisa se preocupar. Vou mostrar: no último domingo, o Kimi AI caiu na nossa instância e se recuperou automaticamente. Temos quatro nós executando-o agora, então nenhum dos nossos usuários internos percebeu qualquer problema. Estava pronto para produção; não foi preciso pensar muito nisso. E, no fim das contas, isso torna o processo muito mais simples

06:02 para ter workflows de produção. Imagino que muita gente… vou mostrar o Kimi e K3, porque temos usado bastante. Imagino que muita gente aqui conheça bem o Kimi e K3. Então, um milhão de tokens de contexto. Uma coisa interessante: na B300, não dá para chegar a um milhão. É preciso usar metade disso. Mas uma coisa que percebi, especialmente com a nossa equipe, é que usamos bastante esse modelo para coding agents. Isso é mesmo

06:33 suficiente para realizar tarefas longas. Ele também utiliza muito bem o cache KV. Em termos de velocidade, como o tempo até o primeiro token, é muito, muito, muito rápido. E, na demonstração, também vou mostrar meu coding agent executando esse modelo Kimi na RunPod. Este é o nosso dashboard. Ele tem muitas métricas. Pode parecer muita coisa, mas, basicamente, estamos sempre pensando na GPU. Temos muitas métricas da GPU, sabe, e em qual versão do CUDA você

07:05 o que é muito, muito importante. Sabe, se você está executando o Kim e ele não funciona no CUDA 12.8, mas funciona no 13.0. E, na verdade, o que temos é o melhor que conseguimos fazer: podemos analisar benchmarks, olhar todos os nossos dados e brincar um pouco com isso. Então, antes mesmo de colocar isso no seu agent de programação ou simplesmente chamar a resposta da OpenAI, você pode começar a testar rapidinho se está funcionando. E isso torna o processo de CI/CD muito mais completo, sabe? Quanto tempo estão levando minhas inicializações a frio? Como estão minhas métricas

07:37 com tráfego real? Então, vou mostrar a demonstração para vocês. Vou mostrar rapidinho o próprio Runpod. Isso ainda não está configurado, como eu disse; provavelmente estará disponível no fim do mês. Mas, no fim das contas, tudo o que temos é uma imagem Docker. Podemos colocá-la ali. Se carregar corretamente. Mas, sim, no momento não há B300s, mas tenho uma instância em execução agora.

08:09 Essa é a parte divertida de trabalhar neste setor. Sabe, o fornecimento pode ser imprevisível. Mas, sim, no sentido de que tornamos tudo muito fácil. Você pode adicionar um volume de armazenamento. Você faz o deploy; temos uma segunda etapa para que você possa fazer o deploy quando estiver disponível. Então, se estivesse vendo uma tela assim, o deploy seria feito assim que a inicialização começasse. Esse é literalmente o processo. Você clica nesse botão e o Benchpod inicia.

08:40 E posso mostrar aqui. Estou usando a opção errada, mas vou mostrar para vocês. Então, esta é a nossa instância real do Kimi em execução neste momento. Uma coisa legal é que, quando você inicia, há uma varredura completa, para que você tenha dados reais e saiba o que está acontecendo. Outra coisa legal é que também temos métricas ao vivo, enquanto as coisas estão sendo executadas. Tudo isso também é armazenado em backup nos dados de armazenamento. Então, tudo fica

09:11 com backup, aconteça o que acontecer. Todas as chamadas são feitas pela FastAPI, então seu agent pode acessar facilmente todos esses dados. Você pode até mesmo disponibilizar tudo; nem precisa usar a interface. Acho que, à medida que avançamos com os agents, ainda quero ter alguma noção do que está acontecendo, e isso me dá uma boa visão panorâmica do que está acontecendo com minha instância do Kimi K3. Mas, sim, como podem ver aqui, eu ia mostrar que, neste fim de semana, tivemos uma falha em uma GPU. Conseguimos corrigir o problema,

09:43 mas conseguir uma inicialização a frio em 9 minutos no K3 é muito bom. E o legal aqui é que temos o serviço, então você pode iniciar experimentos e aplicá-los. Ele reinicia rapidinho. É literalmente só o arquivo de configuração YAML do VLM. Para esta pequena demonstração, o que testei foi alterar o número máximo de tokens de lote enviados. E eu queria mostrar a vocês

10:14 que tipo de ganho de velocidade isso poderia trazer. Vou abrir aqui. Já executei esses testes porque não vamos passar 20 minutos só olhando benchmarks. Esses benchmarks estão sendo executados com concorrência. Eles começam com um usuário concorrente e depois passam para 8, 64 e 192. E o legal é que podemos comparar várias execuções entre si.

10:46 Dá para ver que até mesmo aumentar o número de tokens de lote não altera muito o tempo até o primeiro token. Mas uma coisa interessante que notei ao aumentar esse número é que a latência entre tokens diminui bastante. Isso significa que a própria solicitação, especialmente se estiver executando um trabalho longo, termina muito mais rápido do que o

11:17 trabalho com a configuração básica que você encontra na receita do VLM. O legal é que você pode adicionar isso a um agent e começar a experimentar à vontade. Assim, consegue obter respostas muito mais rápido, ter os dados e passar disso, se estiver em um pod, para um cluster multinó. Você também pode passar para serverless. Então, se precisar aumentar e diminuir a escala, esta é a maneira perfeita de

11:48 obter dados de verdade. E, para dar um contexto sobre nosso serverless, muita gente faz a mesma coisa: usa a configuração básica que tiver e depois enfrenta dificuldades enquanto espera os workers iniciarem. Isso fornece dados reais. Agora você está pronto para ir para produção. Isso torna tudo muito, muito simples e faz com que tudo se baseie em fatos, como eu sempre digo. Posso mostrar aqui para vocês. Isto é o Kenny escrevendo. Eu perguntei: “O que é um

12:19 Benchpod?” Digitei errado, desculpem. Mas esta é uma instância de comando em execução. Sim, é bem rápido. Eu diria que há provavelmente uns 50 usuários na nossa instância interna agora; a maioria de nós está saindo da nuvem e usando isso. Também temos outras instâncias com GLM, DeepSeek e Qwen 3.8. Mas, sim, acho que, no futuro, vamos nos concentrar mais em roteadores inteligentes. Como podemos hospedar tudo isso sem depender de outra pessoa?

12:52 Então, vou voltar rapidinho à nossa apresentação. Alguns dados importantes, como acabamos de comentar. Se alguém quiser tirar uma captura de tela. Mas, como eu disse, você também pode especificar o experimento por conta própria. Por exemplo, se você disser: “Vou ter 500 pessoas usando isso o tempo todo. Quero ver como vai funcionar.”

13:22 Mas, no fim das contas, a questão é: como passamos da P&D para a produção? Acho que é aqui que o Benchpod vai facilitar bastante o uso para as pessoas. Então, no fim das contas, o que quero que vocês saibam é: escolham um pod e uma máquina com GPU. Vocês têm o modelo; comparem as configurações. Não comecem simplesmente com a receita do VLN. A receita do VLN é comprovada, mas não está pronta para produção. Depois,

13:53 testem. Testem com seu agent. Então, com base no que vocês precisam — ITL, TTF, TPOT ou outra métrica — otimizem para isso. Depois, coloquem em produção a configuração vencedora. Usem o serviço, escalem e agora terão um modelo LLM funcional, que pode ser usado internamente, pode ser usado para… Sim, isso torna tudo muito, muito simples. Mas uma coisa que eu diria, especialmente sobre

14:24 o Kimmy, é que nem sempre é necessário para uma equipe. Uma coisa importante que acho que a maioria das pessoas não considera é que vocês podem usar um modelo menor. No momento, é um nó B200. Na nossa plataforma, isso vai custar 40 mil por mês, essencialmente. O valor pode subir ou cair um pouco, mas é uma máquina muito potente, e acho que

14:55 quando você está pensando em como vai servir as coisas, se quiser fazer isso internamente ou para vocês mesmos, é pensar no que faz mais sentido. E só porque é o modelo de fronteira, talvez não faça sentido. Como eu disse, eu rodo um DeepSeek em 4 H200s e ele faz um ótimo trabalho. O Kimi é mais para tarefas longas, quando estou tentando resolver algo muito, muito detalhado. Mas, como eu disse, outra coisa é garantir que a escolha das suas ferramentas

15:26 esteja alinhada. Isso é muito importante. Não vou falar muito sobre contexto, wikis e tudo isso, mas a capacidade de ter tudo isso e a governança de IA são o próximo passo que vamos dar com RunPod. É algo em que vocês devem sempre pensar, especialmente se forem hospedar seus modelos de LLM por conta própria. Mas é isso, alguém tem alguma pergunta? E também estaremos nos estandes, lá embaixo. Mas, sim, me adicionem no LinkedIn se quiserem conversar mais. Estou sempre

16:00 explorando cada modelo novo, toda semana. Então, sempre encontro algumas pegadinhas que venho aprendendo ao longo do tempo em que faço todo esse trabalho. E, sim, também escaneiem o QR code do cartão para receber créditos e testar o RunPod. E, como eu disse, o template ficará disponível no fim do mês. Aí vocês poderão brincar com ele.

Transcrição original

[00:01] [music] >> My name is Chris Bella. I work at RunPod. I’m a forward deploy engineer. Today I’m going to be talking about benchmarking VLMs. Kind of like the struggle that people have when like especially like a new model comes out. Just some like learnings that we’ve had like internally at RunPod and with like customers. So today I’m going to be showing you

[00:32] essentially like a dashboard that is built on top of like VLM. It’s using our like pods actually. So to give you like a little more context of like what RunPod does is we’re in the new cloud. We make it really really easy for you to rent GPUs and starting from like R&D to like more service production workflows. A lot of times what I see with customers especially with VLM is like someone wants you know the latest model. They don’t know how to like spin it up or they they want to start going to production and they don’t know the the knobs to like touch. They’re they’re

[01:03] just using whatever like the base config and I’m guessing a lot of you probably seen like VLM recipes before. You know it’s a good start especially but like especially in this world we’re always moving fast. So how do you get to more production level style of code and at the same time not just like vibing it. It’s more like how do you actually have data? How do you show you know your manager like your staff engineer that hey this is actually better. This is actually working correctly. So

[01:35] really what I’m trying to say is like I’ve seen a lot everyone’s just guessing. Like you know you’re a lot of times I see people are using the wrong VLM version. They might they’re probably not using like the nightly version. They have the wrong size for their context window. It really depends like I I think it always is a step back. It’s like what are you trying to achieve with your your LM model? Are you is it going to be a coding agent? Is it more kind of like you’re just um you know, doing summaries, like very very basic tasks. That’s usually the first question I’d be asking before you you know, getting Kim K 3, having you

[02:09] know, a million long context. Like that’s not always necessary. Uh and at the same time it’s like how many users are going to be using this? Um a lot of times people are like going everyone’s trying to always get like the the smallest amount of GPU for the cheapest price. But if you’re going to be going to a more concurrent users, you need to start thinking about like how am I going to be utilizing the KB cache? Uh so all this is there’s all these little like optimization knobs that you need to like figure out before you go to production. And a lot of times we’re trying to move fast. So um

[02:43] Yeah, like like I said, like RunPod like we like have very much like, you know, we make it very very easy. It’s like a VM. Uh it’s dockerized. Uh you can bring your own image. But at the end of the day like um like who here has used like v l m >> before? >> Okay, so you know, like when you’re looking for like like especially like Kim K 3, like if you you use like a version of like, you know, 0.27, it’s not going to be working. Like like we’re moving so fast the code is not getting as fast. Like you need to have the right version. And a lot of times that turns into kind of like a CD

[03:17] CI CD process that um especially if people who don’t understand what’s happening uh just start struggling. They they start seeing errors and they’re like, “Why is this not working?” You know, it the the layers within it are not they haven’t been written or they’re it’s very in development code. Uh and at the same time that’s actually kind of a problem is like Kim K 3 comes out, you know, the next day I would not put that on production just yet. Uh you’re going to be seeing a lot of probably hallucinations. Uh it’s just not ready in that state, I would say.

[03:47] Um so what I propose um so uh I created this thing called it’s called BenchPod. It’s going to be a template. It hasn’t come out yet. Um so it’s essentially built on top of like uh v l m. Um it’s a whole metric system. Uh you can benchmark very easy. And a lot of you who are familiar with like v l m you can benchmark already, but this kind of um centralizes everything, so you can be able to see everything, be able to change the config very quickly. Uh that’s like a very important thing that I I notice is that uh especially with people who use like our uh our pods is

[04:22] you set up a config, but then you have to restart the image. You have to wait for cold starts to happen. It’s all this loading, and you’re not moving as fast. You’re waiting like 30 minutes like for Kim A I 3 to like download the weights, load into GPU. Uh it’s kind of wasted time. I mean, if you have an agent, you know, you really don’t care, but um that is a pain point especially when we’re trying to move fast. And at the same time it’s like the cool thing about Runpod is you can find these machines. So, if you have that question, it’s like I want to run Kim A I 3 on a B300, we have B300s, and you can start going from

[04:55] like not just like reading about it. You can actually start testing it and seeing if, you know, there’s truth to all these metrics. So, yeah, so like bench like like I said, like bench pod is more like um it’s it’s built like a of a a docker image of um um v l m open a b i. We’re going to be having every version already. Um we just have a little like like payload that like pretty much creates this whole fast a p i application. Uh you can use it for your agents. Uh the cool thing is you can serve uh you can pretty much specify which uh models you

[05:29] want to have. We have a whole watchdog, too, so it like self-heals, too. So, uh if you were actually starting to go to more production levels, uh you can actually uh you don’t have to worry about it. And then like I will show you uh like this past Sunday uh Kim A I went down on our instance, and it uh self-healed. And, you know, we have we have right now like four nodes running it, so none of like our internal users saw any problem. It was a production ready um didn’t have to like think about it too much. And at the end of day, yeah, like it’s it it makes it much more sim- uh simple

[06:02] process to uh have production work workflows. So, I’m guessing a lot of people I’m I’m going to show you Kim and K3 because we’ve been using that a lot. Um I’m guessing a lot of people here are very familiar with Kim and K3. Um so, you know, 1 1 million contacts. Uh one thing that’s interesting on 1B 300, uh can’t get to the 1 million. You got to use half of it. But one one thing I’ve noticed especially with our team, like we’re using it a lot for coding uh agents. Um that is very much um

[06:33] enough to do long task. Um It’s utilizing KB cache uh very well, too. So, um in terms of speed of like time to first second, um it is very very very quick. And like in the demo, I’ll show you too with like my coding agent running this Kim and uh model on RunPod. So, this is like our dashboard. Um It has a lot of metrics. You know, it can it look looks like a lot, but uh essentially, you know, we’re always thinking about like the GPU, like, you know, have a lot of like GPU uh metrics, you know, and what CUDA version you’re

[07:05] on, which is very very important. You know, if you’re running Kim and it doesn’t work on a 12 8 CUDA, it works on 13.0. Uh and really it’s what we have is like the best we can we we can look at benchmarking, look at all our data, we can like playground with it. So, like before you even put it into your like coding agent or uh just hitting the OpenAI uh response, you can start testing real quick if this is working. And just a lot of like more CICD process of like, you know, how long are my cold starts happening? Um how are how are my metrics looking um

[07:37] through actual traffic? So, I’m going to show you guys the demo. So, So, really like I’m going to show you real quick like RunPod itself. So, um this will So, we don’t have this set up yet. Like I said, um it’ll be up probably at the end of the month. Uh but really all we have is just like a Docker image. We can be able to uh put that in right there. If it loads correctly. But uh Uh, yeah, so right now there’s no B300s, but uh, I have one running right now.

[08:09] That’s the fun thing about working in this industry. Uh, you know, uh, supply can be uh, dependent. Uh, but >> [laughter] >> But yeah, it’s in in the sense of that like, you know, we make it really easy. You can put storage volume. Uh, you deploy it, you know, we have a part two so you can deploy when you’re available. So, you know, if you were seeing the screen like this, it will deploy whenever it get it get started. Uh, so that’s like literally the process. You click that button, benchpod like starts up.

[08:40] Um, and I can show you like right here. I have it on the wrong one, but I’ll show you guys here. So, like this is like this is our actual like Kimi running currently. Um, so a cool thing is like you know, you you start like it has a whole air scan so you have actual data to know like what is happening. Um, cool thing is we have live metrics, too. As like things are running. Uh, all of this is also like backed up in like storage data. So, like it’s all

[09:11] um, um, backed up no matter what. Um, it’s all face fast API calls so your agent could easily just call all this data. You can actually just serve everything. Like you don’t even have to use the UI. I I think I’m a big proponent of like as we go to agents it’s like I still want to have like some awareness of what’s happening and having this gives me a good like like eagle’s eye view of like what is happening with my uh, Kimi K3 K3 instance. Uh, but yeah, like you can see here like I was going to show you like uh, this past weekend we had a failure with a GPU. Uh, we were able to fix it,

[09:43] but uh, being able to just do a cold start time like 9 minutes on it like K3s pretty pretty good. Um, and the cool thing here is that we have the serve so you can start out experiments and essentially like apply them. It’ll restart real quick. Um, you can it’s literally just like the config YAML file from like VLM. And um, so like for this like little demo what I tested was we were just changing the max number of batch tokens uh, that were sent through. And I kind of wanted to show you guys of

[10:14] like, you know, what what kind of like speed ups would happen with this. Um I’ll go right here. So, I run these before because we’re not going to spend like 20 minutes just looking at benchmarks. So, these benchmarks are running like concurrency. So, they’re they’re running um you know, starting with like just one concurrent user and then eight, 64, 192. And the cool thing is like we can be at we can actually compare multiple runs against each other.

[10:46] You can kind of see like even just increasing the match the the number of batch tokens doesn’t really change that much the like time to first second. But, interesting thing that I did notice of increasing that is like the inner token latency actually decreases quite a bit when you increase that batch tokens. Which means it’s like the request itself, if it’s especially running like a long like job essentially, it’s actually much faster finishing the

[11:17] job than the base like config that like you find on VLM recipe. The cool thing is is like you can add this to an agent and just start going crazy with it. And you can start getting those answers much much quicker, have the data, and move from this if you have it like on a pod, you can start moving to, you know, a multi-node cluster. You can move to serverless, too. So, if you’re going to be like scaling up and down that that this is a perfect way of like

[11:48] actually getting data. And just to give you like a context on our serverless, like serverless a lot of people will do the same thing. They they just put whatever the base config is and then are struggling as like they’re waiting for workers to start up. This actually gets you the real data. You’re now ready to go to production. Makes it really really simple. And just gives It’s like I always say, it’s basing everything in facts. And I can like show you guys right here. Like this is actually like Kenny writing. So I was just like, what is a

[12:19] bench pod? I misspelled it. Sorry. But that this is little command instance running through it. Um yeah, and Um you know, it is pretty pretty quick. Like like I would say like there’s like a probably like 50 users right now on our internal one and we most of us are getting off cloud and just using the and we have other instances with like GLM, uh deep seek, uh quant 3.8. Um but yeah, like I think in the future we’re looking to more at like smart routers. Like how how do we

[12:52] host all this without being reliant on someone else? Um Yeah, so let me go back to our uh thing real quick. So some like important data like we were just talking about it. If anyone wants to screenshot that. But uh Like I said, like you can you can specify the experiment yourself too. So if you were like, I’m going to have like 500 people using this all the time. Like I want to like see how well this is going to be. Um

[13:22] But at the end of the day, like I said, it is how do we go from R&D to production? And I think this is where like bench pod will make it a lot more easier for people to use. Um So like at the end of the day, like what I want you guys to like know is like um you know, pick a pod, get like a GPU machine. You have your model, compare configs. Don’t just start with like the VLN recipe. The VLN recipe is proven, but it’s not production ready. Um and then

[13:53] test. Have your agent tested. And then whatever, you know, based on what you need, if it’s ITL, if you need TTF, TPOT, like metric, like optimize on that. And then ship that winner. Go to service, scale out, and now you can like um Now you have a working LLM model that can be used internally, can be used for our Um Yeah, it’s it just makes it very very simple. But yeah, one thing I would say especially with

[14:24] like Kimmy that I’ve noticed is um it’s not always necessary for a team. Like like a big thing that I think like most people don’t think about is that um you can use a smaller model. You know, it it’s a B 200 right now like a node. That’s like on our on our platform like that’s going to cost you 40K a month essentially. And it might go up, it might go down a little, but you know, it’s a very powerful machine and I think

[14:55] when you’re thinking about like how you’re going to be um serving stuff if you want to be doing this internally or for yourselves is like what makes sense the best. And just because it’s the the frontier model, maybe it doesn’t make sense. Um like I said like like I run a deep six on a 4 H 200s and does a really good job. Kimmy’s more for like long tasks that I’m trying to solve something like very very detailed. Um but like I said, the other thing is like making sure your like tooling

[15:26] choice is like on there. That’s a big thing. Context like I I’m not going to be going through too much about like context like wikis and all that, but the ability to have all that and like AI governance is the next step that we are going to be going with RunPod, but just something to be always be thinking about especially if you’re going to be self-hosting your um your LLM models. But yeah, is there any questions? Like And we’ll also be at the booths. So like downstairs. But yeah, add me on LinkedIn if you want to talk more. I’m always

[16:00] exploring every new model like every week. So always have some like gotchas that I’ve been learning through the through the time I’ve been doing all this work. And yeah, also scan the card QR code so you can get you get some credits and you can test out RunPod. And and said, the template will be out like at the end of the month. So you can go play around with it.