DeepSeek reduziu sua memória em 437 vezes em dois anos

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 Cut Their Memory 437x in Two Years · Canal: Prompt Engineering · 13:34 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos de IA

Resumo

O vídeo apresenta as mudanças de arquitetura do DeepSeek V4.1 Flash, que reduziram o uso de KV cache para 890 bytes por token, segundo a transcrição. As principais medidas são dividir o modelo em encoder e decoder, compartilhar memória entre camadas, quantizar a memória global para 4 bits e reconstruir o estado local em vez de salvá-lo em disco. O apresentador também explica recursos de velocidade e compara resultados de benchmarks, destacando que o modelo se sai bem em algumas tarefas de desenvolvimento, mas perde desempenho em tarefas científicas complexas. A conclusão é que a eficiência de memória e o tamanho dos parâmetros não bastam para avaliar a capacidade de um modelo: também importam o conhecimento factual, o harness e a configuração das avaliações.

Pontos-chave

A transcrição atribui ao DeepSeek V4.1 Flash um uso de 890 bytes de KV cache por token, 437 vezes menor que o valor de referência citado para o modelo original.
A arquitetura CED divide a rede em encoder e decoder; o decoder reutiliza um conjunto compartilhado de keys e values.
A CSA2 permite que algumas camadas compartilhem memória e seleção de tokens, em vez de manter cada uma seu próprio conjunto completo.
A memória global é quantizada para 4 bits, enquanto o estado das janelas locais não é salvo em disco e pode ser reconstruído ao receber novas mensagens.
O apresentador afirma que o custo de geração por token aumenta cerca de 25% quando o contexto cresce de 4 mil para 1 milhão de tokens.
Engram e DSpark são citados como componentes que contribuem para a velocidade de geração.
Os resultados apresentados são atribuídos ao fornecedor e usam 100% de reasoning effort; o desempenho varia entre benchmarks e tarefas.
O modelo tem resultados competitivos em algumas avaliações de programação, mas apresenta uma lacuna em tarefas científicas complexas.
A transcrição observa que a pontuação pode variar conforme o harness usado na avaliação.

Capítulos

Início	Capítulo	Resumo
00:00	A redução de memória do V4.1 Flash	O vídeo apresenta a queda do uso de memória por token e explica por que isso é relevante para contextos longos e agentes.
02:05	KV cache e arquitetura CED	A explicação passa pelo custo do KV cache e pela divisão entre encoder e decoder, que permite compartilhar keys e values.
04:12	Compartilhamento de memória e quantização	O vídeo descreve a CSA2, a quantização para 4 bits e a reconstrução do estado das janelas locais em vez de salvá-lo em disco.
07:50	Custos de contexto e velocidade de geração	O apresentador aborda o custo de geração em contextos longos e apresenta Engram e DSpark como recursos de velocidade.
10:28	Benchmarks, limitações e conclusão	A comparação de benchmarks destaca bons resultados em algumas tarefas de desenvolvimento, limitações científicas e a influência do harness.

Citações

Isso é 437 vezes menor. — 00:30

O problema real em produção não é mais a computação. São os bytes e a distância que eles precisam percorrer pelo hardware. — 02:05

A solução deles foi: não gravar esses estados. — 07:17

Verifique o harness antes de acreditar em qualquer gráfico. — 12:32

Conceitos e entidades

DeepSeek V4.1 Flash (modelo): Modelo apresentado no vídeo como uma arquitetura voltada à eficiência de memória e inferência.
KV cache (conceito): Memória que armazena keys e values associados aos tokens para evitar que o modelo releia todo o contexto a cada etapa.
Causal Encoder Decoder (CED) (conceito): Arquitetura descrita no vídeo que divide as camadas entre encoder e decoder e permite compartilhar um conjunto de keys e values.
Compressed Sparse Attention 2 (CSA2) (conceito): Mecanismo apresentado como forma de algumas camadas reutilizarem memória e seleção de tokens de outras camadas.
Engram (ferramenta): Tabela de consulta de grande porte citada como componente que recupera informações comuns sem usar o mesmo volume de computação da GPU.
DSpark (ferramenta): Mecanismo de speculative decoding descrito como um modelo auxiliar que propõe tokens para o modelo principal verificar em paralelo.
DeepSeek V4 Pro (modelo): Modelo maior usado no vídeo como comparação com o V4.1 Flash.
DeepSeek (empresa): Empresa associada aos modelos e às técnicas de arquitetura discutidos no vídeo.

Tradução completa (pt-BR)

00:00 Então, a DeepSeek acabou de lançar o V4.1 Flash, e tudo gira em torno da eficiência. Não é uma atualização incremental. É uma mudança arquitetural que vai ser muito importante. Para entender isso, precisamos colocar as coisas em perspectiva. Em 2023, o primeiro modelo deles consumia 389 MB só para manter na memória um único token do seu prompt. Na versão 3.2, reduziram esse valor para 48 MB. Depois, o V4 Flash

00:30 reduziu para 3,5 megabytes. Mas, no V4.1 Flash, são apenas 890 bytes. Isso é 437 vezes menor, o que é impressionante. Portanto, não é apenas uma atualização incremental. O modelo inteiro foi redesenhado para reduzir esse número específico. Para chegar a esse resultado, eles fizeram quatro mudanças radicais. Primeiro, cortaram o modelo pela metade. Segundo, deixaram as camadas compartilharem

01:01 a memória, em vez de cada uma calcular a sua própria. Terceiro, comprimiram os nós restantes para quatro bits. E, quarto, pararam de salvar completamente o cache local em disco. Não se preocupe se essas coisas ainda não fazem sentido. Vou explicá-las daqui a pouco. Se você executa agents autônomos de horizonte longo ou alimenta o modelo com bases de código enormes, esse número é justamente o que determina os custos da sua infraestrutura. Vamos analisar as quatro partes, porque há um ponto cego interessante

01:32 em que essa arquitetura falha completamente. E vou mostrar isso daqui a pouco. Mas, primeiro, vamos ver o que está consumindo sua memória. O modelo de linguagem lê seu prompt. Cada camada anota algo sobre cada token. Isso é chamado de chave e valor. Assim, ele não precisa reler seu contexto ao gerar a próxima palavra. Essa pilha de anotações é o cache KV, e só aumenta. Nas taxas antigas, um contexto de 1

02:05 milhão de tokens consome cerca de 48 GB de VRAM pura, sem nem contar os pesos do modelo. E isso é muito. Esse é o número que impede você de usar toda a context window de um modelo. Com esse novo modelo, a DeepSeek apresenta um argumento bem simples: a atenção já resolve a matemática básica de contextos longos. O problema que os desenvolvedores enfrentam na prática, em produção, já não é o poder computacional. São os bytes em si e a distância que eles precisam percorrer pelo seu

02:36 hardware. Certo. Cada chamada de API que você faz realiza dois trabalhos completamente diferentes. O primeiro é o prefill. O prefill é o modelo processando seu prompt inteiro em uma única passagem enorme. O decode é a geração da resposta, um token por vez. Pense na leitura como um trabalho em grande escala, enquanto a escrita é, essencialmente, um fluxo lento de tokens, um por um. É por isso que esses modelos de linguagem grandes são chamados de preditores do próximo token.

03:07 Além disso, esta é uma arquitetura enorme de mistura de especialistas, o que significa que ela ativa apenas uma pequena fração do seu cérebro para cada token. No total, são 552 bilhões de parâmetros, mas cada camada ativa apenas seis especialistas dinâmicos entre 384, além de um especialista compartilhado que opera em cada token. Mas aqui vem uma mudança arquitetural insana: ela ativa 8 bilhões de parâmetros para ler um token e 16 bilhões para

03:40 escrever um. Portanto, processar o contexto custa literalmente metade do poder computacional necessário para gerá-lo. Isso não é por acaso. É consequência direta da primeira grande mudança arquitetural. Certo. A primeira é o que eles chamam de codificador-decodificador causal, ou CED. Em um transformer típico de 40 camadas, cada camada calcula e armazena suas próprias chaves e valores. Então, 40 camadas significam 40 pilhas separadas de

04:12 anotações para o cache KV. A DeepSeek literalmente corta o modelo pela metade: as 20 camadas inferiores atuam como codificador, e as 20 superiores, como decodificador. O decodificador não gera suas próprias anotações. Ele projeta um único conjunto compartilhado de chaves e valores a partir da camada final do codificador. Assim, metade da rede inteira lê de um único banco de memória compartilhado, em vez de alocar mais 20 conjuntos próprios.

04:43 É exatamente daí que vem a diferença entre 8 bilhões e 16 bilhões de parâmetros. Durante a ingestão do prompt, você executa apenas a metade inferior da pilha. Portanto, a leitura é literalmente metade do trabalho. Isso reduz muito a necessidade de memória, mas ainda há 20 camadas do codificador gravando anotações na VRAM, o que nos leva à mudança número dois. É o que eles chamam de atenção esparsa comprimida 2, ou CSA2. Lembre-se: nenhuma camada lê seu

05:14 prompt inteiro. Um pequeno indexador com pontuação analisa o contexto e escolhe apenas algumas centenas de tokens que realmente importam. Isso significa que uma camada de atenção tem dois trabalhos: escrever novas anotações e escolher quais anotações antigas ler. A CSA mostra que a maioria das camadas não precisa fazer as duas coisas. Uma camada completa faz o trabalho inteiro: calcula suas próprias anotações e escolhe seus próprios tokens. Uma camada de reindexação não escreve nenhuma anotação. Ela empresta memória de uma camada completa anterior, mas executa novamente o seletor para examinar outras partes do prompt. E há também uma camada de reutilização, que simplesmente empresta as duas coisas. No decodificador, ela copia diretamente as anotações e a seleção, deixando apenas uma camada para escrever e selecionar de novo, e 15 camadas simplesmente copiando.

05:46 Mas há uma ressalva. Cada camada ainda mantém uma pequena janela deslizante de tokens recentes em resolução completa. Essa

06:16 janela local é mantida separadamente por camada, e esse compartilhamento não a afeta. Lembre-se disso, porque vamos voltar a esse ponto daqui a pouco. Isso nos leva às mudanças três e quatro, que tratam diretamente do armazenamento físico. Na mudança número três, eles quantizam as anotações da memória global para quatro bits. Como 4 bits oferecem uma faixa dinâmica muito pequena, a cada 16 valores é atribuído um fator de escala de alta precisão. Assim, os números pequenos não são arredondados

06:47 para zero. A ideia é que, se você combinar a precisão de 4 bits com o compartilhamento entre camadas e a divisão entre codificador e decodificador, o uso de memória cairá para apenas 890 bytes por token, uma redução de 75% em relação ao V4 Flash. Agora, em quarto lugar, aquelas janelas deslizantes locais que acabamos de mencionar: cada camada mantém uma. Então, salvar uma conversa inativa no SSD significa gravar 40 blocos separados em

07:17 disco. Qual foi exatamente a solução deles? Disseram para simplesmente não gravá-los. Quando o usuário enviar outra mensagem, basta reproduzir os últimos tokens da janela pela rede e reconstruir o estado local na hora. Nesse caso, o armazenamento persistente em disco cai para um oitavo. A DeepSeek deixa claro que esse estado reproduzido é uma aproximação, não uma correspondência exata. Eles afirmam que a perda de qualidade é insignificante, porque treinam o modelo para lidar com o ruído da reprodução. Mas

07:50 esse é o teste que eles mesmos relataram. Então, encare o resultado com cautela, como faria com qualquer outro modelo. Certo, vamos ver o que acontece quando juntamos tudo. Nesse caso, metade das camadas grava, e o restante compartilha ou copia; tudo é armazenado em 4 bits, e a janela local nunca é salva em disco. Certo. Aqui está a curva de desempenho do artigo da DeepSeek. Ela mostra o poder computacional necessário para gerar um token em função do tamanho da context window. As gerações de modelos anteriores aumentam em linha reta. O V4.1 Flash fica quase completamente plano. Agora, se você ampliar o contexto do prompt em 256 vezes, de 4.000 tokens até 1 milhão completo, o custo para gerar um token aumenta apenas cerca de 25%.

08:22 Então, se você já teve um agent autônomo usando ferramentas por três horas, sabe que não está pagando pela inteligência pura.

08:53 Você está pagando para carregar todo aquele histórico enorme em cada turno. Isso torna muito barato carregar contextos longos. Certo. Além da economia de memória, há dois módulos de velocidade por baixo dos panos. Eles explicam por que a geração de tokens é tão rápida. Ela pode gerar até 300 tokens por segundo, o que é impressionante. O primeiro é o Engram, uma enorme tabela de consulta com 196 bilhões de parâmetros, que funciona junto ao núcleo do

09:24 modelo. Em vez de gastar poder computacional da GPU para identificar frases comuns do Engram, o modelo simplesmente as recupera da memória estática. E, por funcionar como um dicionário esparso, esses parâmetros extras ficam na memória comum e barata do sistema, em vez de ocupar a preciosa HBM. Tenho um vídeo sobre o assunto, se tiver interesse. O segundo é o DSpark, o mecanismo de decodificação especulativa deles. Um pequeno modelo auxiliar e rápido propõe cinco

09:56 tokens à frente. O modelo enorme verifica os cinco de uma vez, em uma única passagem paralela. Assista a este vídeo se quiser saber mais. Além disso, na API, o esforço de raciocínio agora é controlado por um seletor numérico de 1 a 100, em vez das opções genéricas baixo, médio e alto. Portanto, a engenharia de sistemas é, sem dúvida, brilhante. Mas a pergunta de um milhão de dólares é: quão inteligente é o modelo em si? Antes de olhar os benchmarks e os placares, entenda como ele foi treinado.

10:28 A DeepSeek admite abertamente que não há nenhuma inovação algorítmica no pós-treinamento. É SFT, RL e destilação padrão. O segredo está inteiramente no pipeline de dados sintéticos e nos ambientes automatizados de agent. E lembre-se de que estes são números divulgados pelo fornecedor, com esforço de raciocínio em 100%. Vamos comparar primeiro a arquitetura base. O V4.1 Flash tem 552 bilhões de parâmetros, com 8 a 16

10:59 bilhões ativos, enquanto o V4 Pro tem 1,6 trilhão, com 49 bilhões de parâmetros ativos. No LU Pro, o Flash marca 74,1 contra 73,5 do Pro, um empate, usando um terço dos pesos e um quarto do compute ativo. Em benchmarks de agent para desenvolvedores, ele tem um desempenho muito acima do que seu tamanho sugere. Sua pontuação de 90,6 no Terminal Bench 2.1 supera os 89,1 do Opus 5.

11:29 Ele empata com o Opus, com 74,2. Faz 200 no Deep e alcança um ELO absurdo de 3.471 no Codeforces. Mas agora veja onde ele realmente desaba: no Terminal Bench 4.0, que não é um benchmark simples de scripts Bash, mas um ambiente de agent científico e extenuante, o Flash cai para 31,2, contra 51,8 do Opus. Ele também é derrotado exatamente da mesma forma

12:00 no Humanity’s Last Exam e no ProgramBench. Agora, a DeepSeek admite isso diretamente no texto: há uma diferença de desempenho perceptível em tarefas científicas de nível especializado realizadas por agents, em comparação com modelos realmente de ponta. Você vê o mesmo padrão exato em QA simples. Quando você comprime um modelo para um terço do tamanho, mantém as regras de raciocínio lógico, mas perde a capacidade enciclopédica de recuperar fatos. E fique atento à configuração de avaliação da DeepSeek.

12:32 Testar o mesmo checkpoint em diferentes harnesses faz a pontuação variar de 74,2 para 65,5. Portanto, a conclusão é: verifique a estrutura de suporte antes de acreditar em qualquer gráfico. Certo. Então, quais são exatamente algumas das conclusões daqui? Ele foi pré-treinado do zero com 45 trilhões de tokens, usando atenção esparsa nativa, escalável para uma context window de 1 milhão de tokens. Tanto os pesos do modelo quanto a implementação de inference são completamente

13:03 open source sob a licença MIT. Não há um template padrão de gráfico Ginga incluído. Você precisa usar o encoder de referência em Python ou compilar a receita REST. Além disso, as chamadas de API existentes do V4 Pro são roteadas automaticamente para a infraestrutura do V4.1 Flash. Mas acho que eles mudaram isso nos últimos dias. A grande conclusão aqui é que o setor de IA finalmente está deixando de tratar a escala bruta dos parâmetros como a única métrica

13:34 que importa. O número que define este modelo é 890 bytes por token de cache KV. Ao redesenhar a pilha de camadas, quantizar a memória e remover do disco o cache redundante, eles criaram uma arquitetura enxuta que supera modelos gigantes em codificação e workflows de desenvolvimento, mesmo que o conhecimento científico profundo ainda exija uma escala física enorme. Enfim, espero que este vídeo tenha sido útil. Obrigado por assistir e, como sempre, vejo vocês no próximo

Transcrição original

[00:00] So Deep Seek just dropped V4.1 Flash and it’s all about efficiency. It’s not an incremental update. It’s an architectural change which is going to be a huge deal. Now to understand this, we need to put things in perspective. Back in 23, their very first model burnt through 389 MGB just to hold a single token of your prompt in memory. By version 3.2, they got it down to 48 MB. Then V4 flash

[00:30] dropped it to 3.5 mgabytes. But in V4.1 flash, it takes just 890 bytes. That is 437 times smaller, which is kind of incredible. So this is not just an incremental update. The entire model was redesigned around shrinking that one specific number. Now to get there, they made four radical pads. First, cut the model in half. Second, let layers borrow

[01:01] memory instead of calculating their own. Third, crush the remaining nodes into four bits. And fourth, stopped saving local cache to disk altogether. Don’t worry if these things don’t make sense yet. I’m going to explain them in a bit. If you’re running long horizon autonomous agents or feeding in huge code bases, that number is actually what drives your infrastructure bill and cost. Let’s walk through all four pieces because there is one interesting blind

[01:32] spot where this architecture completely breaks down. And I’m going to show you that in a minute. But first, let’s look at what actually is eating your memory. Language model reads your prompt. Every layer writes down a small note about each token. It’s called a key and value. So it never has to reread your context when generating the next word. That stack of nodes is KV cache and it only ever grows. At older rates, a single 1

[02:05] million token context eats roughly 48 GB of pure VRAM before you even count the model weights. And that’s significant. This is the number that stops you from using the whole context window of a model. With this new model, Deep Seeks makes a very simple point. Attention already solves the raw math of long context. The real world developer hits in production is not compute anymore. It’s actually the raw bites and how far they have to travel across your

[02:36] hardware. Okay. So, every API call that you make does two completely different jobs. The first one is prefill. So prefill is model ingesting your entire prompt in a single massive pass. Decode is it generating the response back to you one token at a time. Think about reading as a wholesale work and writing is essentially slow trickle token by token. That’s why these large language models are called next token predictors.

[03:07] On top of that, this is a massive mixture of experts architecture, meaning it only wakes up a tiny fraction of its brain for every given token. Now, it has 552 billion parameters in total, but each layer only activates six dynamic experts out of 384, plus one shared expert that runs on every token. But here’s an insane architectural shift. It fires 8 billion parameters to read a token and 16 to

[03:40] write one. So ingesting context literally costs half of the compute of generating [clears throat] it. Now this is not by accident. It falls directly out of the first majoral architectural change. Okay. So the first one is what they are calling causal encoder decoder or CED. In a typical 40 layer transformer, every single layer computes and stores its own keys and values. So 40 layers means 40 separate piles of

[04:12] nodes for KV cache. DC literally cuts the model in half and the bottom 20 layers act as a encoder and the top 20 act as a decoder. The decoder doesn’t generate its own nodes. It projects one single shared set of keys and values out of the final encoder layer. So the entire half of the network reads from the single shared memory bank instead of allocating 20 more set of its own.

[04:43] That’s exactly where the 8 billion versus 16 billion parameter splits comes from. You only run the bottom half of the stack during prompt injection. So reading is literally half the work. It’s a huge cut in memory requirement, but you still have 20 encoder layers writing nodes into VRAM, which brings us to change number two. This is what they’re calling compressed sparse attention to or CSA2. Remember, no layer reads your

[05:14] entire prompt. A small indexing scorers scans ahead and pick only the few hundred tokens that actually matter. That means an attention layer has two jobs. Write new notes and pick which old note to read. CSA proves most layers don’t need to do either. A full layer does the whole job. It computes its own nodes and picks its own tokens. A reindex layer writes zero nodes. It borrows memory from a full layer before

[05:46] it, but reruns the picker to look at different parts of the prompt. And then there is a reuse layer which simply borrows both. It copies the notes and the selection directly in the decoder that leaves just one layer writing for repicking and 15 straight up copying. Now there is just one catch. Every layer still keeps a tiny sliding window of recent tokens in full resolution. that

[06:16] local window is kept separate per layer and none of this sharing touches it. Now keep that in mind because we’re going to come back to it in a bit. That leads into change three and four and these go straight after physical storage. Change number three is they quantize the global memory nodes down to four bits because 4bit has almost no dynamic range. Every 16 values share a high precision scale factor. So tiny numbers don’t round away

[06:47] to zero. The idea is that if you stack 4bit precision on top of the layer sharing and the encoder split, the memory footprint is going to drop to almost 890 bytes per token which is a 75% reduction from the V4 flash. Now fourth, those local sliding windows we just mentioned, every layer keeps one. So saving an idle conversation out of the SSD means writing 40 separate chunks to

[07:17] disk. What exactly was their fix? Well, they said don’t write them at all. When the user sends another message, simply replay the last window of tokens through the network and rebuild the local state on the fly. In this case, the persistent disk storage drops to an eight. Now, Deepseek is upfront that this replayed state is an approximation, not an exact match. They claim that the quality is loss is negligible because they train the model to handle replay noise. But

[07:50] that’s their self-reported test. So, take it with a grain of salt like you will do it with every other model. Okay, we’re going to look at what happens if you put all of the stack together. So in this case half the layers are writing the rest are sharing or copying and everything is stored in 4bit and local window never is saved to the disk. Okay. So here’s a payoff curve from the deepseek paper. Plotting the computing needed to generate one tokens against the size of the context window. Model

[08:22] generations scaled straight up. V 4.1 flash is almost completely flat. Now, if you stretch your prompt context 256 times from 4,000 tokens out to full million and the cost to spit out a token only takes up by about 25%. So, if you ever had an autonomous agent who running tools for 3 hours, you know, you’re not paying for raw intelligence.

[08:53] you are paying to drag that massive chart history behind it on every single turn. This makes dragging contacts dirt cheap. Okay. Beyond memory savings, there are two speed modules under the hood. That explains why the token generation moves so fast. It can generate up to 300 tokens per second, which is kind of incredible. So first is engram a massive 196 billion parameter lookup table running alongside the core

[09:24] model. Instead of burning uh GPU compute to figure out common engram phrases, it simply retrieves them from static memory. And because it acts as a sparse dictionary, those extra parameters sit in ordinary cheap system memory rather than hogging precious HBM. I have a video on the topic if you are interested. Second is DSpark which is their speculative decoding engine. It’s a tiny fast helper model drafts five

[09:56] tokens ahead. Massive model checks all five at once in a single parallel pass. Watch this video if you want to learn more. Plus on the API side, reasoning effort is now exposed integer slider from 1 to 100 rather than generic low, medium, and high toggles. So the system engineering is undeniably brilliant. But the million-doll question is how smart is the actual model? Before looking at the benchmarks and scoreboards, understand how this was trained.

[10:28] Deepseek openly admits there is zero algorithmic innovation in their post training. its standard SFT, RL and distillation. The secret source is entirely in their synthetic data pipeline and automated agent environments. And keep in mind these are vendor reported numbers running at 100% reasoning effort. Compare the base architecture first. V4.1 flash sits at 552 billion parameters with 8 to 16

[10:59] billion active while V4 Pro sits at 1.6 6 trillion with 49 billion active parameters. On LU Pro, Flash scores 74.1 against Pros 73.5, which is dead even while using a third of the weights and a quarter of active compute. On developer agent benchmarks, it punches way above its weight. 90.6 on terminal bench 2.1 beats Opus 5 at 89.1.

[11:29] It ties OPUS at 74.2. 200 on deep and hits an absurd 3,471 ELO on code force. But now look at where it actually collapses on terminal bench 4.0 which isn’t a simple bash script benchmark u but a gruding scienceheavy agent environment flash tanks to 31.2 against ous at 51.8. It also gets crushed the exact same way

[12:00] on humanity’s last exam and program bench. Now, Deepseek admits it directly in the text. There is noticeable performance gap on expert level scientific agent tasks compared to true frontier scale models. You see the exact same pattern on simple QA. When you compress a model down to a third of its size, you keep the logical reasoning rules, but you lose the encyclopedic factual recall. And watch out for the uh evaluation setup on Deep Sweet.

[12:32] Testing the exact same checkpoint across different harnesses cause the score to swing from 74.2 down to 65.5. So the takeaway is check the scaffolding before you believe any chart. Okay. So what exactly are some takeaways from here? It was pre-trained from scratch on 45 trillion tokens with a native spots attention scaling out to 1 million token window. Both the model weights and the inference implementation are completely

[13:03] open under any MIT license. There’s no there is no standard Ginga uh chart template included. You have to use the Python reference encoder or compile the rest recipe also is existing V4 Pro API calls automatically route to V 4.1 flash infrastructure. I think they changed it in the last couple of days though. The big takeaway here is that the AI industry is finally moving past treating raw parameter scale as the only metric

[13:34] that matters. The number defining this model is that 890 bytes per token of KV cache. By redesigning the lay stack, quantizing memory, and dropping redundant cache from disk, they built a lean architecture that outclasses giant models on encoding and developer workflows, even if the deep scientific knowledge still demands massive physical scale. Anyways, I hope you found this video useful. Thanks for watching and as always, I’ll see you in the next