DeepSeek acaba de abrir o código de como atende 155 trilhões de tokens por dia

Ver no idioma original →

Autoria: Prompt Engineering · 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: DeepSeek Just Open-Sourced How It Serves 155T Tokens a Day · Canal: Prompt Engineering · 16:09 · Assistir no YouTube

Tópicos: Inferência e otimização de modelos, Infraestrutura e hardware de IA, Segurança de IA

Resumo

O vídeo explica a arquitetura de inferência da DeepSeek, apresentada no projeto Deep Infra, e como ela separa prefill e decode para atender muitas solicitações em escala. A transcrição detalha o uso prolongado do KV cache, o balanceamento de carga, a distribuição de experts e a decodificação especulativa. Também aborda o modo batch invariant, limitações da versão aberta e dos kernels para hardware específico, além de testes com DeepSeek Recipe e batching. A principal lição é evitar trabalho redundante e manter as GPUs ocupadas.

Pontos-chave

• Segundo a DeepSeek, um cluster com essa arquitetura atende 155 trilhões de tokens por dia.
• O sistema separa prefill, que processa o prompt, de decode, que gera a resposta token por token.
• O KV cache pode ser mantido por três dias para tráfego de agents e sete dias para chat; a DeepSeek afirma que 96% dos tokens de entrada são cache hits.
• Manter estável o prefixo do prompt é uma forma simples de aumentar o reaproveitamento do cache.
• O prefill é tratado como um problema de computação, enquanto o decode é sobretudo um problema de memória.
• A arquitetura distribui experts entre GPUs e usa cópias de experts populares para reduzir gargalos.
• A decodificação especulativa usa um modelo auxiliar para propor tokens, e uma confidence head estima quais têm mais chance de serem aceitos.
• O modo batch invariant busca manter resultados consistentes independentemente das outras solicitações no batch, com custo de velocidade.
• A versão aberta é voltada à inferência offline; componentes da infraestrutura interna, como o sistema de cache e os balanceadores de carga, não foram disponibilizados.
• Os kernels descritos são direcionados a GPUs Nvidia de data center Blackwell e podem não funcionar em outras arquiteturas.

Capítulos

Início	Capítulo	Resumo
00:00	O desafio de atender modelos em escala	O vídeo apresenta a alegação de escala da DeepSeek e introduz a separação entre prefill e decode.
03:08	Fluxo da solicitação, segurança e KV cache	A solicitação passa por DeepSeek Recipe e pela verificação do KV cache, que pode reter contexto por vários dias.
06:17	Prefill, decode e otimizações de throughput	O vídeo explica a divisão de hardware, a distribuição de experts e o uso de speculative decoding.
09:24	Resultados reproduzíveis e limites da versão aberta	São apresentados o modo batch invariant, números de produção e limitações de software e hardware.
12:31	Demonstrações e conclusões práticas	O apresentador testa a proteção contra marcadores de prompt injection e o efeito do batching, depois resume as lições para servir modelos.

Citações

Um único cluster executando essa stack atende 155 trilhões de tokens por dia. — 00:00

96% de todos os tokens de entrada são cache hits. — 05:14

Prefill é um problema de computação, e decode é um problema de memória. — 06:49

O que mais está no batch pode, de fato, mudar sua resposta. — 14:04

Servir um modelo nessa escala é, em grande parte, não fazer o trabalho duas vezes e nunca deixar uma GPU ociosa. — 14:37

Conceitos e entidades

• DeepSeek (empresa): Empresa que publicou a arquitetura de inferência discutida no vídeo.
• Deep Infra (ferramenta): Nome usado no vídeo para o sistema de inferência da DeepSeek e sua implementação aberta.
• DeepSeek Recipe (ferramenta): Componente aberto que converte formatos de solicitações em tokens do modelo e transforma a saída em resposta.
• prefill (conceito): Etapa que processa o prompt de entrada em paralelo e constrói a memória da conversa.
• decode (conceito): Etapa que gera a resposta do modelo um token por vez.
• KV cache (conceito): Memória que armazena informações do prompt já processado para evitar recalcular partes repetidas.
• SWA bonded replay (conceito): Técnica descrita no vídeo para reaproveitar uma janela curta de atenção e reduzir o trabalho de prefill.
• Mixture of Experts (conceito): Arquitetura em que cada token usa um grupo de sub-redes especializadas, em vez de todo o conjunto do modelo.
• speculative decoding (conceito): Técnica que propõe vários tokens com um componente menor e pede ao modelo principal que os verifique em conjunto.
• batch invariant mode (conceito): Modo que busca tornar a matemática e as saídas consistentes mesmo quando muda a composição do batch.
• vLLM (ferramenta): Engine de inferência mencionada como uma opção para executar o modelo.
• DGX Spark (modelo): Sistema de hardware citado nos testes e na discussão sobre compatibilidade dos kernels.
• Blackwell (modelo): Arquitetura de GPUs Nvidia de data center para a qual os kernels descritos foram escritos.

Tradução completa (pt-BR)

00:00 Como servir um modelo de IA para milhões de pessoas ao mesmo tempo sem ir à falência por causa das GPUs? Esse é um dos segredos mais bem guardados dos laboratórios de IA. Mas a DeepSeek acabou de disponibilizar como open source o Deep Infra, o mecanismo de inference por trás da API, junto com um relato muito detalhado das partes que não puderam liberar. Agora, aqui está a parte surpreendente: segundo a DeepSeek, um único cluster executando essa pilha atende a 155 trilhões de tokens por dia, o que é impressionante.

00:31 A DeepSeek realmente tem defendido uma IA verdadeiramente aberta. Li o relatório e algumas coisas me chamaram bastante a atenção. A primeira é como eles gerenciam o cache de prompt. A maioria das empresas mantém o cache de prompt ativo por apenas 5 minutos. Eles conseguem mantê-lo por vários dias, o que é impressionante. E, em segundo lugar, mesmo com temperature zero, o prompt de outra pessoa, se cair na mesma partição da GPU que o seu, pode alterar silenciosamente a resposta que você recebe. Isso não era algo que eu esperava. Então, neste

01:02 vídeo, quero explicar em detalhes o que exatamente é o Deep Infra e como você deve pensar em usá-lo. Vamos acompanhar uma única solicitação desde o momento em que sai do seu laptop até o momento em que os tokens começam a chegar. Vamos ver por que ler seu prompt e escrever a resposta acontecem em dois tipos de máquinas completamente diferentes. Depois, vou falar de algumas das minhas experiências tentando reproduzir isso no DGX Spark. Agora, quando você executa um modelo localmente na sua própria máquina, a vida é bem simples. Há um usuário, um

01:33 prompt e uma GPU fazendo todo o trabalho. O modelo lê seus prompts, escreve as respostas um token de cada vez e espera tranquilamente até você digitar de novo, o que é ótimo. Portanto, não há muita engenharia envolvida. Mas servir o mesmo modelo para milhões de pessoas ao mesmo tempo quebra completamente essa configuração. Há muitas variáveis diferentes. As pessoas vão enviar prompts diferentes simultaneamente. Eles terão tamanhos diferentes. Algumas podem fazer perguntas de umas 10 palavras. Pode haver um agente autônomo despejando uma base de código inteira na fila, apenas alguns milissegundos depois.

02:05 Agora, cada uma dessas solicitações esconde, nos bastidores, duas tarefas de hardware opostas. A primeira tarefa é o prefill, em que o modelo lê o prompt inteiro em uma única passagem massivamente paralela e constrói sua memória de trabalho da conversa. É aí que entra o KV cache. A segunda tarefa é o decode, em que o modelo escreve a resposta um token de cada vez, e cada token precisa esperar pelo token anterior. Em resumo, o prefill é uma montanha de cálculos feitos de uma só vez,

02:37 enquanto o decode é uma pequena fração de cálculos repetida milhares de vezes seguidas. Agora, você pode estar pensando: por que não simplesmente executar um mecanismo de inference normal em muitas GPUs? Você poderia, mas então cada GPU faria as duas tarefas, e uma atrapalharia a outra. Isso significa que as respostas de alguém ficam paradas sempre que aparece um prompt grande. Então, a pergunta que o Deep Infra responde é: o que é necessário para servir um modelo a milhões de pessoas, além de simplesmente executá-lo? Certo, então aqui está

03:08 o diagrama arquitetônico publicado pela DeepSeek. Vamos acompanhar uma solicitação por ele, de cima para baixo. Sua solicitação chega no topo como JSON. Ela é convertida em tokens. Depois, segue para o serviço de prefill de um lado e para o serviço de decode do outro. As setas azuis são a parte mais interessante, porque não transportam solicitações. Elas transportam a memória que o modelo tem da sua conversa entre máquinas e armazenamento. A primeira parada é um componente chamado

03:40 DeepSeek Recipe, que também foi disponibilizado como open source. Ele converte sua solicitação do formato da OpenAI ou da Anthropic nos tokens exatos esperados pelo modelo e converte a saída do modelo de volta em uma resposta. Isso parece entediante, mas há um problema de segurança escondido aqui. O modelo usa tokens especiais para marcar onde sua mensagem termina e onde a resposta dele começa. Portanto, se um usuário digitar um desses marcadores especiais em uma mensagem, um servidor ingênuo

04:12 pode transformá-lo em um token de controle real, e o modelo pensa que o turno dele começou. Essa é uma das formas que as pessoas usavam para fazer injeção de prompt. Você incluía os tokens de resposta do modelo e alguns tokens iniciais que o modelo poderia simplesmente continuar completando. Por isso, o Recipe da DeepSeek foi criado para garantir que tudo o que você digitar continue sendo texto simples. Vamos testar isso na minha própria máquina no fim do vídeo. Agora, antes de o modelo ler um único

04:43 token, o sistema verifica algo chamado KV cache, que é a memória salva do prompt que o modelo já leu. Então, quando você envia a próxima mensagem de uma conversa, tudo o que veio antes já foi lido uma vez, e não há motivo para ler de novo. Esse é o detalhe que mencionei no início: a DeepSeek mantém essa memória em disco por dias — 3 dias para tráfego de agent e 7 dias para chat. A escala disso é impressionante

05:14 porque eles armazenam tudo em um cluster de dados dedicado com cerca de 100 petabytes de SSD. Portanto, segundo a DeepSeek, 96% de todos os tokens de entrada são acertos de cache, o que significa que o modelo só precisa realmente ler quatro de cada 100 tokens de entrada, algo impressionante. É por isso que a API cobra muito menos pelos tokens de entrada em cache. Agora, se você está criando agents que reenviam o mesmo contexto longo em cada turno,

05:45 manter estável o prefixo do prompt é a otimização mais barata que você pode fazer. Certo, agora a parte nova do prompt segue para o prefill. Aqui, o balanceador de carga organiza as solicitações por tamanho em quatro grupos. Assim, prompts curtos não ficam presos atrás de uma solicitação com um quarto de milhão de tokens. Depois, cada GPU recebe um limite de tempo para cada etapa, e o escalonador prevê quanto do prompt ela consegue ler dentro desse limite. Agora, o truque mais interessante do prefill é algo que eles chamam de SWA

06:17 bonded replay. Esse modelo usa atenção de janela deslizante em partes de suas camadas, o que significa que essas camadas só prestam atenção aos 128 tokens mais recentes. Então, em vez de recalcular essa janela do zero em todas as camadas, eles repetem apenas a janela curta no fim do prompt, o que, segundo a DeepSeek, reduz quase pela metade o trabalho total de prefill. Agora, a maneira mais simples de pensar em todo esse projeto é que o prefill é um problema de computação e o decode

06:49 é um problema de memória. O prefill faz uma quantidade enorme de cálculos com muitos tokens de uma só vez, por isso é executado em máquinas comuns com oito GPUs cada. O decode faz poucos cálculos por token, mas precisa ler os pesos do modelo e a memória da conversa para cada token. Por isso, é executado em supernós com centenas ou mais GPUs. Agora, como os dois são executados em máquinas separadas, a DeepSeek pode ajustá-los separadamente, o que significa que eles podem

07:20 controlar tanto o tempo até o primeiro token quanto o tempo até a resposta final. Na produção, precisam de aproximadamente uma GPU de prefill para cada GPU de decode. Quando o prefill termina, sua solicitação passa para o decode, e é aí que entram os especialistas do modelo. O DeepSeek v4.1 flash é um modelo de mistura de especialistas, o que significa que cada token usa apenas um grupo de sub-redes especializadas, escolhido de um conjunto muito maior. No decode, a DeepSeek distribui esses

07:51 especialistas por 64 GPUs ou mais, de modo que cada GPU mantém apenas alguns especialistas e consegue atender a um lote muito grande de usuários ao mesmo tempo. O problema é que alguns especialistas são muito mais populares do que outros, e a GPU mais lenta determina a velocidade do grupo inteiro. Por isso, cada GPU também mantém um espaço extra com uma cópia do especialista popular, e o sistema movimenta essas cópias a cada poucos milhares de etapas, de acordo com o padrão do tráfego.

08:22 Mais uma vez, esse é um padrão de projeto muito engenhoso. Mesmo com tudo isso, o decode continua acontecendo um token de cada vez, então o último grande ganho de velocidade vem da decodificação especulativa. Uma pequena cabeça de rascunho adivinha os próximos cinco tokens, e o modelo grande verifica os cinco em uma única etapa, em vez de escrevê-los um por um. Já falei sobre a decodificação especulativa do DeepSpark em outro vídeo. O link estará na descrição. Agora, a DeepSeek acrescenta algo a isso,

08:53 que é um mecanismo de confiança que prevê a probabilidade de cada palpite ser aceito. Assim, o sistema só gasta poder computacional verificando os palpites que provavelmente serão mantidos. E, segundo a DeepSeek, esse escalonamento por confiança aumenta em cerca de 6% a vazão durante toda essa verificação de cinco tokens. Isso pode parecer pouco, mas, nessa escala, 6% significa muitas GPUs. Agora, há mais um recurso no DeepInfra que acho que todo desenvolvedor deveria conhecer. Se você enviar o mesmo prompt com

09:24 temperatura zero, esperaria receber uma resposta relativamente parecida — ou a mesma — todas as vezes. Mas, em um servidor movimentado, muitas vezes não é isso que acontece. A razão está no lote, porque as GPUs escolhem uma maneira diferente de somar os números dependendo de quantas solicitações estão processando juntas em um único lote. E essas pequenas diferenças de arredondamento podem mudar qual token vence. Por isso, o Deep Infra tem um modo invariável em relação ao lote, que força os cálculos a produzir

09:55 o mesmo resultado, independentemente do que mais estiver no lote. Ele vem desativado por padrão porque fazer os cálculos sempre da mesma maneira é mais lento. Então, se você precisa de resultados reproduzíveis para evals ou para depurar um agent, esta é a configuração que ativaria ao usar o Deep Infra. Certo, é assim que, segundo a DeepSeek, todo o sistema funciona em produção. Cada GPU de decodificação produz cerca de 14 mil tokens por segundo somando todos os usuários.

10:26 E, ao mesmo tempo, cada usuário ainda vê as respostas sendo transmitidas a algumas centenas de tokens por segundo. Em média, cada GPU gera cerca de US$ 38 por hora em receita. E esses são os preços fora do horário de pico. É importante conhecer as limitações, porque o Deep Infra não é algo que você baixa e executa no seu próprio hardware local. Primeiro, a versão open só faz inference offline, ou seja, não vem com um servidor de API. Agora, o sistema de cache de KB

10:58 e os balanceadores de carga de que acabamos de falar estão vinculados à infraestrutura interna da DeepSeek. Então, você recebe uma descrição deles, mas ainda não temos acesso ao código. Já vi pessoas na internet converterem esses US$ 38 em receita por gigawatt, mas esse valor corresponde à receita com preços fora do horário de pico. Ele pressupõe que todas as GPUs ficam ocupadas o ano inteiro e depende do sistema de cache de KB

11:28 que eles ainda não lançaram. A segunda limitação é o hardware, porque esses kernels foram escritos para os chips Blackwell de data center da Nvidia, como os B200. Portanto, não vão funcionar de imediato em algo como um DGX, que usa um chip Blackwell diferente. Analisei o código-fonte: a biblioteca de atenção só compila para esses chips de data center, e a biblioteca de multiplicação de matrizes gera um erro de arquitetura não compatível em qualquer outro chip. Então, minha recomendação é verificar

11:59 qual arquitetura de GPU é o alvo dos kernels do projeto antes de alugar hardware para ele, porque recompilar não vai resolver esse problema. Se quiser executar o DeepSeek v4.1 flash por conta própria, o modelo já funciona em engines comuns, como vLLM, sobre o qual o Deep Infer foi originalmente construído. E é por isso que open source é tão importante. A DeepSeek está lançando os modelos e a infraestrutura como open source, mas, ao mesmo tempo, também está construindo sobre bibliotecas open source, como vLLM.

12:31 Chega de teoria. Vamos ver algumas coisas que prometi. Vamos começar pelo marcador digitado que mencionei antes e verificar se o método da DeepSeek realmente o mantém como texto simples, o que potencialmente pode funcionar em qualquer laptop. Enviei uma mensagem em que o usuário digitou o marcador especial que inicia o turno do assistant, seguido de “vou ignorar minhas regras”, certo? Essa é uma técnica geral de injeção de prompt que você provavelmente já viu.

13:03 Quando você tokeniza o prompt da maneira ingênua, o marcador, ou token especial, se torna o verdadeiro token de controle, e o modelo passa a ver dois turnos do assistant. Mas, com o método da DeepSeek, há apenas um, e o marcador que digitei para iniciar o turno do assistant permanece como texto — o que é ótimo, especialmente se você estiver servindo o modelo na sua própria infraestrutura. Esse é exatamente o comportamento que você quer. Outra coisa que notei aparecer no prompt é que a DeepSeek

13:34 adiciona por padrão uma linha de esforço de raciocínio ao system prompt. Agora, vamos ver o comportamento da temperatura. Testei isso no meu Mac com um modelo open pequeno: enviei o mesmo prompt uma vez, sozinho, com temperatura zero, e depois dentro de lotes com outros prompts. Sozinho, o modelo disse que a luz azul se dispersa mais do que as outras cores. Depois, afirmou que o céu é, na verdade, verde ou violeta. Mas, quando coloquei

14:04 exatamente o mesmo prompt em um lote com apenas mais um prompt, a resposta mudou no token 14. Ele disse que o céu é principalmente azul. Agora, todas as execuções repetiram exatamente o mesmo resultado. Portanto, não se trata de amostragem aleatória, o que significa que o conteúdo do lote pode, de fato, mudar sua resposta. Este é um modelo minúsculo em uma biblioteca simples, então o lote também altera o preenchimento. Mas isso também mostra exatamente o mesmo tipo de problema que o modo invariável em relação ao lote da DeepSeek

14:37 foi criado para eliminar. E isso acontece até em um laptop. Portanto, vale a pena ter isso em mente se você estiver servindo o modelo para vários usuários e agrupando as solicitações deles em lotes. Este é um trabalho incrível da DeepSeek, especialmente no lado da inference. Há muito que podemos aprender com a maneira como essas empresas fazem inference ao servir modelos de ponta em grande escala. A ideia principal é que servir um modelo nessa escala consiste, em grande parte, em não repetir trabalho e nunca deixar uma GPU

15:08 ficar ociosa. Assim, o prefill e a decodificação são executados em máquinas diferentes. Quase todo token de entrada vem de um cache que permanece por dias. No caso da DeepSeek, o speculative decoding e os experts distribuídos mantêm as GPUs de decodificação ocupadas. Esse tipo de coisa é o que você precisa considerar ao tentar servir um modelo desse tamanho. Pelo menos nos meus experimentos, há duas coisas que você pode usar hoje com qualquer modelo: o método da DeepSeek, se estiver

15:38 construindo sobre os modelos da DeepSeek, e a ideia de manter estável o prefixo do prompt para obter o desconto do cache. Se você executa modelos em produção, conte nos comentários quais desses truques já está usando. E tenho curiosidade de saber até onde vão outras configurações. Estou preparando um vídeo sobre como servir esse modelo em dois DGX Sparks. Se quiser assistir, inscreva-se no canal. Se quiser saber mais sobre speculative decoding e Deep Spark em

16:09 particular, assista a este vídeo. Enfim, espero que este vídeo tenha sido útil. Obrigado por assistir e, como sempre, até a próxima.

Transcrição original

[00:00] How do you serve an AI model to millions of people at the same time without going bankrupt on GPUs? This is one of the best-kept secret when it comes to AI labs. But, Deep Seek just open-sourced Deep Infra, which is the inference engine behind the API, along with a very detailed write-up of the parts that they couldn’t release. Now, here’s the crazy thing. According to Deep Seek, a single cluster running this stack serves 155 trillion tokens every single day, which is kind of incredible.

[00:31] Deep Seek has really been pushing for actual open AI. Now, I read through the report, and there are a couple of things that really jumps out. First is how they manage prompt caching. Most companies keep the prompt cache live only for 5 minutes. They can push it for several days, which is crazy. And second, even at temperature zero, someone else’s prompt landing in the same GPU patch as yours can quietly change the answer you get back. This is not something I was expecting. So, in

[01:02] this video, I really want to break it down what exactly Deep Infra is and how you should think about using it. We’re going to follow a single request from the moment it leaves your laptop to the moment tokens stream back. See why reading your prompt and writing the answer happens on two completely different types of machines. And then, I’ll talk about some of my experiments trying to replicate this on DGX Spark. Now, when you run a model locally on your own machine, life is pretty simple. There’s one user, one

[01:33] prompt, and one GPU doing the entire job. The model reads your prompts, writes the answers one token at a time, and waits quietly until you type again, which is great. So, there is not much engineering involved. Now, serving the same model to millions of people at once breaks this setup completely. There are a lot of different variables. People are going to be sending different prompts simultaneously. They’re going to have different sizes. Some might have like 10-word questions. There might be autonomous agent dumps an entire code

[02:05] base in the queue just a few milliseconds later. Now, every single one of these requests hides two opposite hardware jobs under the hood. The first job is prefill, where the model reads your entire prompt in one massive parallel pass and builds its working memory of the conversation. This is where the KV cache comes into play. The second job is decode, where the model writes the reply one token at a time, and every single token has to wait for the token before it. In short, prefill is a mountain of math done at once,

[02:37] while decode is a tiny sliver of math repeated thousands of times in a row. Now, you might be thinking, why not just run a normal inference engine on a lot of GPUs? And you could, but then every GPU does both jobs, and the two jobs get in each other’s way. Which means somebody’s answers stalls every time a big prompt shows up. So, the question at Deep Infar Answer is what it takes to serve a model to millions of people beyond just running it. Okay, so here’s

[03:08] the architectural diagram that DeepSeek published. And we’re going to follow one request through it from top to bottom. So, your request comes in at the top as JSON. It gets turned into tokens. And then it goes into prefill service on one side and decode service on the other. Now, the blue arrows are the most interesting part because they’re not moving requests at all. They’re moving the model’s memory of your conversation between machines and storage. The first stop is a component called

[03:40] DeepSeek Recipe, which they also open sourced. Uh it converts your request from the OpenAI or Anthropic format into the exact tokens the model expects, and it converts the model’s output back into a response. Now, this sounds boring, but there is a security problem hiding here. Because the model uses special tokens to mark where your message ends and where its own answer starts. So, if a user types one of those special markers into a message, a naive server

[04:12] can turn it into a real control token and the model thinks that its turn has started. And this is one of the way people used to do prompt injection. You would include the model response tokens and a starting few tokens that the model could just continue completing. So, Deep Seek’s recipe is built so that whatever you type always stays plain text, which we are going to test on on my own machine at the end of the video. Now, before the model reads a single

[04:43] token, the system checks something called the KV cache, which is the model’s saved memory of the prompt it has already read. So, when you send the next message in a conversation, everything before it has already been read once and there is no reason to read it again. Now, this is the detail I mentioned at the start uh because Deep Seek keeps this memory on disk for days, which is 3 days for agent traffic and 7 days for chat. Now, the scale of this is pretty wild

[05:14] because they store it on a dedicated data cluster uh with about 100 petabyte of SSD. So, according to Deep Seek, 96% of all input tokens are cache hits, which means the model only has to read four out of every 100 input tokens for real, which is kind of incredible. And this is why the API charges you so much less for cached input. Now, if you’re building agents uh which resends the same long context on every single turn,

[05:45] keeping your prompt prefix stable the cheapest optimization you can make. Okay, so and now the part of the prompt that is new goes to prefill. Here, the load balancer sorts requests by length into four buckets. So, short prompts don’t get stuck behind a request with a a quarter of a million tokens. Then, each GPU gets a time budget for every step and the scheduler predicts how much prompt it can read within that budget. Now, the most interesting trick in prefill is something they call SWA

[06:17] bonded replay. So, this model uses sliding window attention uh in parts of its layers, which means those layers only attend to the most recent 128 tokens. So, instead of recomputing that window from scratch through every layer, they replay only the short window at the end of the prompt, which according to DeepSeek nearly halves the total prefill work. Now, here’s the easiest uh way to think about this whole design, which is that prefill is a compute problem and decode

[06:49] is a memory problem. Prefill does a huge amount of math on a lot of tokens at once, so it runs on regular machines with eight GPU each. Decode does a little math per token, but has to read the model’s weight and the conversation memory for every single token. So, it runs on super nodes with hundreds or more GPUs. Now, with the two run on separate machines, DeepSeek can tune them separately, which means they can

[07:20] both control the time to first token and the time to the final response. So, in production, they need roughly one prefill GPU for every decode GPU. So, once prefill is done, your request moves to decode and this is where the model’s experts come in. DeepSeek v4.1 flash is a mixture of experts model, which means every token only uses one uh group of specialized sub-networks out of a much larger set. Now, in decode, DeepSeek spread those

[07:51] experts across 64 or more GPUs, so each GPU only holds a handful of experts and can serve a very large batch of users at once. Now, the problem is that some experts are a lot more popular than others, and the slowest GPU sets the speed for the whole group. So, every GPU also keeps a spare slot of a copy of the popular expert, and the system moves those copies around every few thousand steps based on what traffic

[08:22] looks like. Again, this is a pretty genius design pattern. Now, even with all of that, decode is still one token at a time, so the last big speed up comes from speculative decoding. A small draft head guesses the next five tokens, and the big model checks all five in a single step instead of writing them one by one. I have covered the DeepSpark speculative decoding in another video. Link is going to be in the description. Now, DeepSeek adds something on top,

[08:53] which is a confidence head that predicts how likely each guess is to be accepted. So, the system only spends compute checking the guesses that are likely to survive. And according to DeepSeek, this confidence scheduling adds about 6% throughput over all this checking five tokens. Now, that sounds small, but at these scales, uh 6% is a lot of GPUs. Now, there’s one more feature in DeepInfra that I think every developer should know about. If you send the same prompt at

[09:24] temperature zero, you would expect a relatively similar or same answer every time. But on a busy server, that is often not the case. Now, the reason is the batch, because the GPUs picks a different way to add up numbers depending on how many requests it’s processing together in a single batch. And those tiny rounding differences can flip which token wins. So, Deep Infra has a batch invariant mode, which forces the math to come out

[09:55] the same no matter what else is in the batch. It is off by default because doing the math the same way every time is slower. So, if you need reproducible output for e-vals or for debugging an agent, this is the setting you would turn on when you’re using Deep Infra. Okay, so this is what the whole system looks like in production according to Deep Seek. Each decode GPU produces about 14,000 tokens per second across all its users.

[10:26] And at the same time, each user still sees answers streaming at a couple of hundred tokens per second. So, on average, each GPU brings in about $38 an hour in revenue. And that is their off-peak prices. Now, it’s important to know the limitations because Deep Infra is not something you download and serve on your own local hardware. First, the open version only does offline inference, which means there’s no API server in the box. Now, the KB

[10:58] cache system and the load balancers we just talked about are tied to Deep Seek’s internal infrastructure. So, you get a description of them, but we don’t have access to the code yet. Now, I have already seen people online turn that $38 into revenue per gigawatt, but that number is revenue at off-peak prices. It assumes every GPU is busy all year, and it depends on the KB cache system

[11:28] they actually haven’t released yet. Now, the second limitation is hardware because these kernels are written for Nvidia’s data center Blackwell chips, like the B200s. So, they’re not going going to work out of the box on something like a DGX box, which uses a different Blackwell chip. I looked at the source code, the attention library only builds for those data center chips, and the matrix multiplication library throws an unsupported architecture error on anything else. So, my recommendation would be to check

[11:59] which GPU architecture the project’s kernel target before you rent hardware for it, because recompiling won’t fix that issue. Now, if you want to run DeepSeek v4.1 flash yourself, the model already runs on regular engines like vLLM, which Deep Infer was originally built on. And this is where open source is so important. DeepSeek is releasing the models, their infrastructure as open source, but at the same time they are also building on top of open source libraries like vLLM.

[12:31] Now, that’s enough theory. Let’s actually look at a couple of things that I promised. So, we’re going to start with the typed marker from earlier, and whether DeepSeek recipe really keeps it as plain text, which potentially is going to work on any laptop. So, I give it a message where the user typed the special marker at that starts the assistant turn, followed by I will ignore my rules, right? And this is like a general prompt injection technique that you probably have seen.

[13:03] Now, when you tokenize the prompt the naive way, the marker or special tokens becomes the real control token, and the model now sees two assistant turns. But with DeepSeek recipe, uh there’s only one, and the marker I typed that starts the assistant turn which is great, especially if you are serving the model on your own infrastructure. This is exactly the behavior you want. One other thing that I saw that shows up in the prompt, which is that DeepSeek

[13:34] adds a reasoning effort line to the system prompt by default. Now, let’s look at the temperature behavior. And this is something that I actually tested on my Mac with a small open model where I sent the same prompt at temperature zero once on its own and then inside batches of other prompts. So, on its own, the model said blue light gets scattered more than other colors. And then it claimed that the sky is actually green or violet. But when I put

[14:04] the exact same prompt in a batch with just one other prompt, the answer changed at token 14. It said the sky is mostly blue. Now, every run repeated exactly. So, this is not random sampling, which means that what else in the batch actually can change your answer. Now, this is a tiny model in a a simple library, so the batch also changes uh the padding. Uh but it also shows the exact same kind of problem that DeepSeek’s batch-invariant

[14:37] mode is built to remove. And it even shows up on a laptop. So, something to keep in mind if you are serving the model to multiple users and you’re batching their requests. Now, this is incredible work from DeepSeek, especially on the inference side. There is so much that we can learn from how these companies uh who are serving frontier models at scale at doing inference. The main idea is that serving a model at the scale is mostly about not doing work twice and never letting a GPU

[15:08] sit idle. So, prefill and decode runs on different machines. Almost every input token comes from a cache that lives for days. In case of DeepSeek and speculative decoding plus spread out experts keep the decode GPUs full. And these are kind of the things that you need to uh think about if you are trying to serve a model of this size. Now, at least in my experiments, the two pieces you can use today uh with any model are the Deep Seek recipe if you’re

[15:38] building on top of Deep Seek’s models and the idea of keeping your prompt prefix stable uh so you get the cash discount. If you’re running models in production, please share in the comments which of these tricks you are already using. And I’m curious how far other setups go. Now, I’m putting together a video on serving this model across two DGX Sparks. So, if you want to see that, make sure to subscribe to the channel. Now, if you want to learn more about speculative decoding and Deep Spark in

[16:09] particular, watch this video. Anyways, I hope you found this video useful. Thanks for watching, and as always, see you in the next one.