Vale a pena usar speculative decoding? Análise de desempenho do vLLM em NVIDIA Blackwell — Akamai

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: Is Speculative Decoding Worth It? Profiling vLLM on NVIDIA Blackwell — Akamai · Canal: AI Engineer · 14:43 · Assistir no YouTube

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

Resumo

Sheila, da Akamai, explica como speculative decoding usa um modelo menor para propor tokens, que são verificados pelo modelo principal, e quais custos e benefícios essa técnica traz. A demonstração compara tarefas estruturadas e criativas, mostrando que a taxa de aceitação dos tokens influencia a velocidade e o throughput. A técnica tende a ajudar em tarefas previsíveis e com pouca concorrência, mas consome VRAM adicional e não acelera a leitura de prompts longos. A decisão depende das características da carga de trabalho, do espaço disponível na GPU e da escolha do modelo draft.

Pontos-chave

A geração comum de texto ocorre token por token após o modelo processar o prompt e construir o KV cache.
No speculative decoding, um modelo menor propõe tokens e o modelo principal os aceita ou rejeita em uma etapa de verificação.
A técnica pode reduzir a latência e aumentar o throughput, mas exige memória adicional para o modelo draft e seus KV caches.
O modelo draft deve ser menor, rápido e suficientemente preciso; idealmente, deve compartilhar o tokenizer e a família do modelo principal.
Tarefas estruturadas, como geração de código, JSON e SQL, tendem a se beneficiar mais do que tarefas criativas.
Uma taxa de aceitação baixa reduz a vantagem do speculative decoding, especialmente em tarefas criativas com temperatura alta.
A técnica acelera a geração de tokens, mas não a etapa de leitura do prompt; por isso, tende a ajudar menos quando há muito contexto de entrada.
A disponibilidade de VRAM, o tamanho dos lotes e o nível de concorrência devem ser considerados antes de habilitar a técnica.

Capítulos

Início	Capítulo	Resumo
00:12	Como funciona speculative decoding	A palestrante descreve as etapas de processamento do prompt e geração, e explica como um modelo menor propõe tokens para o modelo principal verificar.
02:17	Custos e escolha do modelo draft	A técnica pode economizar tempo de inferência, mas exige memória adicional, e a escolha do modelo deve equilibrar velocidade, custo e precisão.
05:29	Demonstração em tarefas estruturadas e criativas	A comparação mostra que tarefas estruturadas podem alcançar maior taxa de aceitação, enquanto tarefas criativas tendem a apresentar aceitação menor.
10:29	Comprimento do contexto e critérios de avaliação	Speculative decoding acelera a geração, não a leitura de contextos longos, e sua utilidade depende também da VRAM e da concorrência.
12:02	Ferramentas, referências e recursos da Akamai	Sheila recomenda a documentação do vLLM, menciona outras abordagens e indica recursos da Akamai para explorar otimizações de inferência.

Citações

A saída continua a mesma porque o modelo principal ainda precisa verificar os tokens. — 01:46

Há cargas de trabalho que se beneficiam do speculative decoding e outras que não. — 05:29

A questão principal é pensar no que a sua aplicação está fazendo. — 11:31

Para começar, eu diria que você não tem como errar lendo a documentação. — 12:38

Conceitos e entidades

speculative decoding (conceito): Técnica que usa um modelo menor para propor tokens que o modelo principal verifica antes de incorporá-los à resposta.
KV cache (conceito): Memória de trabalho que armazena informações processadas do prompt para uso durante a geração.
draft model (conceito): Modelo menor que propõe tokens para serem verificados pelo modelo principal.
acceptance rate (conceito): Proporção de tokens propostos pelo modelo draft que são aceitos pelo modelo principal.
throughput (conceito): Quantidade de tokens gerados por unidade de tempo, usada como medida de vazão da inferência.
vLLM (ferramenta): Mecanismo de serving usado na demonstração para executar modelos e testar speculative decoding.
NVIDIA Blackwell (modelo): Plataforma de GPU mencionada como o hardware usado no ambiente de demonstração.
Akamai (empresa): Empresa à qual a palestrante está vinculada e que disponibiliza recursos sobre otimizações de inferência.
Sheila (pessoa): Palestrante da Akamai que apresenta a explicação e a demonstração.
RAG (conceito): Abordagem citada como exemplo de aplicação que pode exigir muito contexto de entrada.

Tradução completa (pt-BR)

00:12 Meu nome é Sheila. Sou DA na Akami e estamos aqui hoje para falar sobre decodificação especulativa e como descobrir se vale a pena ativá-la para suas cargas de trabalho. Certo, estou um pouco ansiosa. Certo. Normalmente, quando você faz uma pergunta a um LLM, há duas etapas que acontecem nos bastidores.

00:42 A primeira é quando o modelo lê seu prompt, processa todos os tokens de entrada e, então, cria o que é conhecido como cache KV, que é essencialmente a memória de trabalho do modelo para o restante da solicitação. Isso acontece apenas uma vez. Depois, vem a etapa de decodificação, quando o modelo começa a escrever a resposta de fato. Como cada token depende dos tokens anteriores, esse processo geralmente acontece um token por vez. Imagine que você esteja implantando uma aplicação que usa um modelo grande,

01:13 como um modelo llama de 70 bilhões. Normalmente, isso exigiria até centenas de passagens forward pelo modelo, e esse é um processo muito caro, certo? Além disso, pode causar muita latência nas aplicações dos usuários. Isso levanta a questão: e se você não precisasse usar o modelo maior para gerar os tokens? E se usasse um modelo menor para fazer parte desse trabalho de previsão e especular sobre alguns tokens? Isso

01:46 ainda é um processo autorregressivo, mas a ideia é que, por ser menor, o processo é mais rápido e, portanto, mais barato. A saída continua igual porque o modelo-alvo, o modelo principal que garante a precisão, ainda precisa verificar os tokens, e faz isso em uma única passagem forward. Essa é a ideia por trás da decodificação especulativa. Vou deixar isto aqui por um segundo. Como eu disse, há um modelo pequeno que gera tokens. Normalmente, você pode definir entre

02:17 três e cinco tokens por ciclo. O modelo-alvo cuida das previsões, podendo basicamente aprová-las ou rejeitá-las. E, para os tokens rejeitados, o modelo-alvo recalcula o token. Certo. Esse processo é ótimo. Pode economizar bastante na geração durante a inference, mas não é gratuito. Como agora você está hospedando dois modelos, precisa levar em conta a memória

02:49 necessária para hospedar esse segundo modelo. Não é muita, já que ele é menor, mas também é preciso alocar espaço extra para o cache KV dos dois modelos. Normalmente, você consideraria executar decodificação especulativa quando tem espaço livre na GPU. Por exemplo, se sua carga de trabalho tem alta concorrência, suas GPUs provavelmente já estão ocupadas processando todas as solicitações, então não faria sentido implementar decodificação especulativa. Mas, se você tiver espaço livre na GPU, vale a pena

03:20 considerar. Mas vamos falar sobre como avaliar se vale a pena. A primeira questão é escolher o modelo de rascunho. Normalmente, ao decidir se vale a pena ativar o recurso, você se pergunta: o modelo de rascunho consegue prever com a mesma precisão que o modelo-alvo? A outra questão é se ele é igualmente rápido. Então, normalmente, você escolheria um modelo que custasse uma fração do valor, como… Sim, essas são as duas

03:51 principais decisões que você precisa equilibrar, certo? Vou deixar isto aqui. Na minha situação, vou explicar por que escolhi esses dois modelos. Para a configuração da demonstração, eu tinha acesso a uma GPU. Estava usando uma GPU Blackwell e queria executar tanto a configuração de referência quanto a de decodificação especulativa ao mesmo tempo. Para fazer isso, precisei escolher um modelo pequeno o bastante para caber, porque tenho que dividir a utilização da GPU

04:23 entre os dois servidores. Por exemplo, foi assim que ficou: só a configuração de referência usa cerca de 16 gigabytes de pesos, e o modelo de rascunho usa 2,5. Isso deixa bastante espaço para o cache KV. Ao escolher o modelo, algumas coisas que normalmente se levam em conta são: primeiro, como eu disse, ele precisa ser menor, normalmente de 10 a 50 vezes menor que

04:54 o modelo-alvo. Ele precisa usar o mesmo tokenizer. De preferência, deve ser da mesma família de modelos; caso contrário, você teria que converter manualmente entre os diferentes tokenizers. O que mais? Sim, esses são os principais pontos. Acho que estou esquecendo um. Ah, sim, como eu disse, o custo e a precisão. Certo,

05:29 ops. Quando fiz isso, havia três questões. Há cargas de trabalho que se beneficiam da decodificação especulativa e outras que não. Como o objetivo é obter um modelo menor que consiga prever com quase a mesma precisão que o modelo-alvo, isso ajuda em alguns casos de uso, quando a carga de trabalho é mais estruturada, como

06:00 casos de uso de programação. Qual outro? Como escrever prompts em JSON ou SQL. Provavelmente, isso se beneficia mais do que um caso de uso altamente criativo, como escrever poesia, fazer brainstorming ou algo assim. Sim. Acho que tenho aqui uma aplicação rápida. Nem sei se vai funcionar, mas…

06:30 Aqui, para a primeira demonstração, tenho apenas duas abas. Como eu disse, o objetivo é observar como a taxa de aceitação varia dependendo do tipo de tarefa. A primeira aba é para saída estruturada. Quando clico aqui, as duas são executadas ao mesmo tempo. Uau. Ai, meu Deus,

07:03 só estou esperando. Problemas técnicos. Não sei por que minha demonstração não está funcionando. Vamos ver.

07:34 Ah, preciso me reconectar? Só um segundo. Acho que talvez eu precise reiniciar o… Parece que preciso reiniciar os servidores VLM.

08:05 e minha configuração. Me deem só alguns minutos. Está ligado? LSU, eu…

08:53 Ah. Devo…? Sim, acho que preciso… Ah, está aparecendo. Certo, lá vamos nós. Eu estava dizendo que esta é uma demonstração. Vou executá-la de novo. Como podem ver, como esperado, com a decodificação especulativa ativada, à direita, ela conseguiu gerar muito, muito mais rápido: 1,6

09:26 vezes mais rápido. O principal a observar aqui é a alta taxa de aceitação, que é o número de tokens aceitos dividido pelo total de tokens gerados pelo modelo de rascunho. Outra métrica: como podem ver, com a decodificação especulativa ativada, conseguimos gerar muito mais tokens por segundo, o que melhora a taxa de transferência. E, se eu executar para o outro

09:58 caso… Este é outro caso de uso. Como esperado, acontece a mesma coisa. Mas, neste caso, acho que a principal métrica a observar é a baixa taxa de aceitação. Como eu disse, isso acontece porque há mais variedade nos próximos tokens que seriam gerados,

10:29 porque, em primeiro lugar, a temperatura está alta. É um caso de uso criativo. Sim. O que mais? Acho que é basicamente isso para este caso. E a outra situação em que… Ops. Ah, sim, era isso. Eu deveria ter colocado isto aqui para explicar quando haveria benefício. O outro caso de uso é o comprimento do contexto. Como

11:01 mencionei antes, há duas partes na geração de tokens. A decodificação especulativa deve acelerar a parte da geração, não a parte em que o modelo lê o prompt. Portanto, normalmente, se você tem um caso de uso em que precisa fornecer bastante contexto ao modelo, como em aplicações de RAG ou na análise de muitos documentos, nessas situações o modelo passa muito mais tempo na etapa de criação do cache KV, especialmente se

11:31 Você usa isso para fazer algo rápido, em que os tokens gerados são muito menos numerosos que o contexto, ou seja, a entrada. Sim. Então, acho que o ponto principal aqui é pensar no que sua aplicação está fazendo. Ela é altamente estruturada? Você tem espaço suficiente na VRAM para sequer considerar isso? Está trabalhando com cenários mais criativos? Está executando muita concorrência ou não? Lotes menores se beneficiariam

12:02 disso. É. Vou deixar este slide aqui. Ele basicamente resume o que acabei de explicar. Se alguém tiver perguntas, vou responder a uma ou duas agora. >> Ah, não consigo ouvir você.

12:38 >> Ah, sim. A pergunta foi se há ferramentas específicas que eu recomendo para speculative decoding. Implementei isso com o vLLM, o mecanismo de serving. Eles têm uma documentação muito boa sobre como começar. Esta é uma das versões mais simples de speculative decoding. Há algumas outras, como Engram, Medusa e Eagle, em que a arquitetura subjacente é mais avançada. Mas, para começar, eu diria que não tem erro

13:08 em simplesmente ler sobre o assunto. Quando eu estava fazendo isso, não havia muito conteúdo disponível, mas encontrei alguns blogs. Quando você pesquisa por speculative decoding, um dos primeiros blogs que aparece, da General Compute, fala mais detalhadamente sobre isso. Também há dois artigos de pesquisa publicados pelo Google e por outra empresa, qual era mesmo? Sim, mas eles se aprofundam mais no assunto. Também estou tentando talvez

13:40 produzir mais conteúdo sobre isso, talvez vídeos. Foi meio difícil explicar tudo. Estou um pouco disperso, mas adoraria talvez publicar um blog ou fazer vídeos curtos. É, no YouTube ou em algum outro lugar. Mas vocês certamente conseguem encontrar os recursos. >> Certo. Eu deveria ter falado disso. Mas não tenho… Eu deveria ter incluído um QR code.

14:13 Ah, como eu disse, sou da Akamai. Se você tiver interesse em aprender a reproduzir isso, pode encontrar informações no nosso site e no nosso GitHub, o GitHub da Akamai Developers. É. Temos muitos recursos diferentes por lá. Estou me concentrando em otimizações de inference. Outras pessoas estão focadas em criar agents de IA e

14:43 em como aproveitar nosso serviço gerenciado de Kubernetes e usar o Akamai Functions. Então, se tiver tempo, confira nossas páginas no GitHub. Também temos um canal no Discord que estamos tentando desenvolver agora. Seria ótimo conversar com alguns de vocês por lá. Obrigado. >> [música] [música]

Transcrição original

[00:12] My name is Sheila. I’m a DA at Akami and we’re here today to discuss um the topic speculative decoding and how you can um figure out whether it’s worth enabling for your workloads. Okay, I’m a little anxious. Okay. So, typically when you ask LLM a question, there are usually two phases

[00:42] that happen under the hood. The first is the model would read your prompt, process all the input tokens and then build what is known as a KV cache um which is essentially the model’s working um memory um for the rest of the request. And this happens only once. Um and then you have the decoding phase which is uh when the model starts to actually write the answer. Um so because every token depends on the previous tokens um this process usually happens one at a time. Um and so imagine you’re deploying an application that uses a big

[01:13] model like llama 70 billion model. Um typically like this would require like even up to hundreds like forward passes on the model and this is a very expensive process right um and it can cause a lot of latency for your user applications which um brings the question of like what if you didn’t have to use your bigger model to handle the token generation. What if you use a smaller model to um do some of that guesswork to speculate on a couple tokens? Um which

[01:46] is still an auto reggressive process, but the whole point is because it’s smaller, there’s it’s a faster process, so it would be a cheaper process. Um the output is still the same because um the target model, the main model that has the accuracy still has to verify the tokens and it does this in one forward pass. Um so that’s the idea behind speculative decoding. Um I’ll just leave this here for a second. So as I said you have a small model um which generates token typically you can set it between

[02:17] three to five for each cycle. The target model would handle the predictions um like be able to scale like basically approve or reject it. Um and then for all the for the tokens that are rejected the target model would um recomputee the the token for that. Okay. So, um this process it’s great. It can save you a lot in terms of inference generation, but it’s not free. Um because you’re hosting now two models, you have to account for the memory

[02:49] required to host that second model. Not that much since it’s a smaller model, but you also have to allocate extra space for um the KV cache for both models. Um yeah so typically you would consider running speculative decoding when you have um extra space in GPU um for example if your workload is high concurrency your your GPUs are probably already busy trying to run all the requests so it wouldn’t make sense to implement speculative decoding but if you have extra GPU space it’s worth

[03:20] considering but uh we’ll talk about how to evaluate whether it’s worth um and the first question is um choosing the draft model. Um yeah, so typically when you’re deciding whether it’s worth enabling, um can the draft model predict as accurate as the target model? And then the other question is whether um it’s as fast. So you would typically choose a model that’s definitely like a fraction of the cost like um yeah, so these are the two

[03:51] main um decisions that you have to balance, right? Um, I’m just going to leave this here. Um, so for my situation, um, I will explain why I chose these two models. For my demo setup, when I was running this, I have access to one GPU. I was running on a Blackwell GPU and I wanted to run both the baseline and the speculative decoding setup in one. Um so to be able to do this I had to choose a model that was small enough to be able to fit because I have to split the GPU

[04:23] utilization between the both servers. Um so this is what that looked like for instance you can the baseline alone um takes about 16 gigabytes of weight and then the draft model is 2.5. So that leaves a huge amount and space for KB caching. Um, and then when you’re thinking about choosing the model, some of the things that you would usually consider is um, first of all, like I said, it has to be smaller, typically 10 to 50 times smaller than

[04:54] your target model. Um, it has to have the same tokenizer. Um, ideally from the same model family, otherwise you know, you would have to like manually translate between the different tokenizers. Um, what’s the other? Yeah, those are the main things. I think I’m forgetting one. Um, oh yeah, and like I said, the cost and accuracy. Uh, okay. So,

[05:29] oops. So when I was running this, there’s three questions. Um, speculative decoding, there’s some work loads that would benefit from it versus others that wouldn’t. Um, typically because the goal here is to get a smaller model that can predict almost as accurately as the target model would. It helps with some use cases when you have a workload that is more like highly structured like

[06:00] coding use cases. Um, what’s another one? Like writing JSON or SQL prompts. Um, it would probably like benefit more versus if you were using it for a highly creative use case like writing poetry or brainstorming or anything like that. Yeah. So, I think I have this is a quick application. I’m not even sure if it’s going to work, but um

[06:30] so here I do have for the first demo, I just have um two tabs here. Um like I said, this is just to focus on looking at how the acceptance rate performs depending on the type of task that you have. Um so the first tab here is a structured output. Um when I click this, it will run both at the same time. Whoa. Oh god,

[07:03] I’m just waiting. Technical difficulties. I’m not sure why my demo is not running. Um, let’s see.

[07:34] Oh, do I have to reconnect? Um, just give me one second. I think I might have to restart the Looks like I need to restart the VLM

[08:05] servers and my setup. Give me just a few minutes. Is this on? LSU I

[08:53] Oh. Um, should I Yeah, I think I need Oh, it’s showing up. Okay, there we go. Um, so yeah, I was saying this is a demo. So when I run this, I’ll redo it. So you can see um as expected with a speculative on the right side um it was able to generate much much faster um 1.6

[09:26] times faster. Um the key thing to note here is how high the acceptance rate is which is the rate of the tokens that were accepted by the the number of tokens that were accepted over the total generated by the draft model. Um another metric here um you can see with the speculative enabled um you we are able to generate a lot more tokens per second um which improves the throughput. And then if I run it for the other

[09:58] case. So here it’s another use case. Um as expected same thing. Um but in this case I guess the main metric to see here is the low acceptance rate. And like I said, this is because this is a more um there’s more variety in how the next tokens that would be generated

[10:29] because first of all, the temperature is set high. It’s a creative use case. Um yeah. Um what else? I think that’s pretty much for this um case. And then the other situation where oops oh yeah this is what I was I should have put this up here um just to explain when it would benefit and then the other use case would be context length. Um so as I

[11:01] mentioned earlier there’s two parts of generating tokens. Um with speculative decoding it’s supposed to accelerate the generating part not the part where the model reads the prompt. So typically if you have a use case where you need to provide the model with a lot of context like for rag applications or um analyzing lots of documents um with those situations um the model will spend a lot more time with the portion of like building the KV caching um especially if

[11:31] you’re using it to do like a quick where the the generated tokens are much less than the context like the input um Yeah. So ba I think the main point here is just how to think through like what is your application doing? Um is it highly structured? Do you have enough VRAM space to even consider it? Are you doing more creative scenarios? Are you running a lot of concurrency um or not? Like smaller batch sizes would benefit

[12:02] from this. Um yeah. Yeah, I’m gonna leave this slide here. This just basically summarizes uh what I just went through. And if anyone has questions, I’ll take one or two questions now. >> Oh, I can’t hear you.

[12:38] >> Oh, yeah. Um the question was are there particular tools that I recommend for speculative decoding? So I implemented this with VLM um the serving engine. Um they have really good documentation on how to get started with it. This is the simpler one of the simple versions of speculative decoding. There’s a couple others like the engram medusa eagle that’s more like the architecture beneath is like more advanced. Um, but for getting started, yeah, I would say you can’t go wrong

[13:08] with just reading up I when I was doing this, there’s there’s not much content out there on this, but I did find a few like blogs. Uh, when you re when you type in circulative decoding, um, one of the first blogs that will come up by general compute talks about more in detail. Um, there’s also like two research papers that were published um, by Google and what’s the other company? Yeah, it but that’s more like goes like more in depth. Yeah. Um, but I’m also trying to maybe like

[13:40] make more content around this, like maybe like videos. It was kind of hard to go through this. I I’m a little all over the place, but I would definitely love to maybe like publish a blog or make snippet videos. Um, yeah, on like YouTube or somewhere, but you can definitely find the resources. >> Okay. Right. I should have covered that. Um, but I don’t have the I should have put a QR.

[14:13] Oh, um, as I said, I I’m from Akamay. And if you’re interested in like learning how to replicate this, you can find it on our website, our GitHub, GitHub. Um, Akami developers. Yeah. Um, yeah. So we have a a lot of like different resources on here. Um I’m focusing on in inference optimizations. Uh we have other people that are focusing on building AI agents um and

[14:43] how to leverage our like manage Kubernetes service, how to use Akami functions. So if you have time, please go check out our GitHub pages and also we have a Discord channel that we’re trying to build up now. Um so it would be great to chat with some of you on the side. Thank you. >> [music] [music]