Strata vs. Llama.cpp vs. vLLM

Autoria: Data Science in your pocket · 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: Strata vs Llama.cpp vs vLLM · Canal: Data Science in your pocket · 14:12 · Assistir no YouTube

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

Resumo

O vídeo compara três engines de inference de LLM com propostas diferentes: llama.cpp, voltado à execução local e ampla compatibilidade; vLLM, otimizado para servir muitas requisições em data centers; e Strata, especializado em executar um modelo MoE grande usando GPU, RAM e SSD em conjunto. Ele explica os desafios de inference, incluindo prefill, decode e KV cache, e apresenta as técnicas usadas por cada engine. Os números de desempenho do Strata são declarações de seu autor, medidas em uma única máquina, e ainda não tinham benchmarks independentes citados no vídeo. A comparação com llama.cpp também exige cautela, pois o suporte a essa arquitetura recente ainda estava em desenvolvimento.

Pontos-chave

A geração de texto ocorre token por token, o que torna o decode uma tarefa sequencial e limitada pela largura de banda da memória.
O prefill processa os tokens do prompt em paralelo, enquanto o decode gera a resposta um token por vez.
O KV cache cresce com o comprimento do contexto e pode ocupar mais memória do que os pesos do modelo.
llama.cpp prioriza execução local, quantização, ampla compatibilidade de hardware e suporte a muitos dispositivos.
vLLM usa paginação do KV cache e continuous batching para aumentar a eficiência e o throughput sob concorrência.
Strata distribui o trabalho entre GPU, RAM e SSD para executar um modelo MoE de grande porte em hardware de consumo.
O autor do Strata relata velocidades de 53 a 94 tokens por segundo para o modelo apresentado, mas os resultados são de uma única máquina.
A alegação de que Strata é cerca de quatro vezes mais rápido que llama.cpp compara o modelo com suporte inicial ainda pouco otimizado neste último.
O vídeo destaca que os três projetos atendem a cenários diferentes, e não são substitutos diretos em todas as situações.

Capítulos

Início	Capítulo	Resumo
00:00	A promessa do Strata e o desafio da inference	O vídeo apresenta a repercussão do Strata e explica por que prefill, decode e KV cache tornam a inference um problema de sistemas.
03:42	llama.cpp: execução local e compatibilidade	O vídeo descreve o GGUF, a quantização e o amplo suporte de hardware do llama.cpp, além de suas limitações sob carga concorrente.
06:17	vLLM: serving eficiente em escala	A explicação aborda PagedAttention e continuous batching, técnicas usadas pelo vLLM para aproveitar melhor a memória e atender mais requisições.
08:23	Strata: GPU, RAM e SSD trabalhando juntos	O vídeo apresenta a arquitetura MoE do modelo e as estratégias do Strata para distribuir pesos, cache e computação entre os recursos da máquina.
11:03	Resultados, ressalvas e comparação	O autor apresenta os resultados medidos em uma única máquina, ressalva a ausência de benchmarks independentes e começa a comparar velocidade e concorrência.

Citações

Gerar uma resposta de 500 tokens significa fazer 500 passagens sequenciais. — 02:07

Dobre o contexto, dobre o KV cache. — 03:10

Não trate a GPU como o computador. Trate o PC inteiro como o computador. — 08:57

Cada número que você está prestes a ver foi medido pelo autor do Strata em uma única máquina. — 11:03

Isso ainda é genuinamente impressionante: a especialização funciona. — 13:08

Conceitos e entidades

Strata (ferramenta): Engine de inference especializada que distribui o processamento de um modelo entre GPU, RAM e SSD.
llama.cpp (repo): Projeto de execução de modelos locais que prioriza quantização e compatibilidade com diferentes plataformas e tipos de hardware.
vLLM (ferramenta): Engine de serving de LLM que usa paginação do KV cache e continuous batching para atender muitas requisições.
Qwen3.8 Flash Next (modelo): Modelo MoE de pesos abertos apresentado no vídeo como alvo da otimização do Strata.
Mixture of Experts (conceito): Arquitetura que ativa apenas parte dos parâmetros especializados para cada token.
GGUF (conceito): Formato de arquivo descrito como um pacote que reúne pesos, tokenizer e metadados do modelo.
KV cache (conceito): Armazena vetores de key e value dos tokens anteriores para que o modelo possa usá-los durante a geração.
PagedAttention (conceito): Técnica do vLLM que divide o KV cache em páginas alocadas sob demanda, reduzindo o desperdício de memória.
continuous batching (conceito): Método que permite inserir novas requisições em um lote enquanto outras ainda estão sendo geradas.
speculative decoding (conceito): Técnica que propõe tokens antecipadamente e verifica vários deles em uma passagem do modelo.

Tradução completa (pt-BR)

00:00 Em 30 de setembro de 2026, uma publicação apareceu no subreddit local law ma com um título que parecia um erro de digitação. Quen 3.8 flash. Em seguida, geração a 50 tokens por segundo e processamento de prompt a 1.500 tokens por segundo, com 12 GB de VRAM e 64 GB de RAM em um laptop. Um modelo de 100 a 20-5 bilhões de parâmetros em um laptop, na velocidade de leitura.

00:32 A publicação recebeu cerca de 150 votos positivos e 140 comentários. E nem foi a primeira. Alguns dias antes, outra discussão alegava 65 tokens por segundo. Citação: “quatro vezes mais rápido que llama.cpp”. O mecanismo por trás das duas publicações se chama Strata. Ele apareceu no GitHub em 24 de setembro, criado por um único desenvolvedor anônimo. Três dias depois, era o repositório C++ em alta número um no GitHub. Três dias depois disso, era o número um

01:04 em todas as linguagens. Dez dias depois de existir, tinha mais de 8.000 estrelas, e as pessoas no 4chan o chamavam de assassino do llama.cpp. Metade meme, metade sério. Agora, se você roda modelos locais há algum tempo, seu alarme de ceticismo já deve estar disparando, porque essa comunidade já viu mecanismos milagrosos antes. Então, neste vídeo, vamos fazer isso direito. Vamos comparar Strata com os dois campeões atuais de inference de LLM: Llama.cpp, o mecanismo que roda literalmente qualquer coisa,

01:36 literalmente em qualquer lugar, e VLM, o mecanismo que atende milhares de usuários ao mesmo tempo em data centers. Três mecanismos, três filosofias totalmente diferentes. No fim, você vai saber exatamente qual deles faz sentido na sua máquina e se o entusiasmo no Reddit é real. Mas, primeiro, precisamos entender por que tudo isso é difícil. Eis o que a maioria das pessoas não percebe. Um LLM não pensa em parágrafos. Ele gera exatamente um token de cada vez. Cada novo token exige uma passagem completa para a frente pela rede inteira,

02:07 cada camada, cada peso ativo. Depois, esse token é acrescentado à entrada e fazemos tudo de novo. Isso se chama decodificação autorregressiva. E significa que gerar uma resposta de 500 tokens exige 500 passagens sequenciais. Não dá para paralelizar isso, porque o token número 500 literalmente não pode ser calculado até que o token 499 exista. Isso cria duas cargas de trabalho bem diferentes. Primeiro, há o prefill: processar seu prompt. Citação: “Todos esses tokens do prompt já existem, então

02:39 podem ser processados em paralelo. É uma multiplicação de matrizes grande e densa, que as GPUs adoram. Depois, há o decode: gerar a resposta um token de cada vez, quando a GPU passa a maior parte do tempo lendo pesos da memória, em vez de calcular. O decode é limitado pela largura de banda da memória. Por isso, o processamento do prompt é medido em milhares de tokens por segundo, enquanto a geração de tokens avança lentamente, na casa das dezenas. E há também o KV cache. Cada token que o modelo já viu nesta conversa deixa vetores de chave e valor em cada camada.

03:10 E o modelo precisa de todos eles, a cada etapa, para fazer atenção. O tamanho aproximado é dois, para chaves e valores, vezes o número de camadas, vezes o número de cabeças de atenção, vezes a dimensão da cabeça, vezes o comprimento da sequência, vezes os bytes por elemento. O fator decisivo aí é o comprimento da sequência. Dobre seu contexto e dobre o KV cache. Em contextos longos, o KV cache pode consumir mais memória do que os pesos do modelo. Então, o serving de inference não é um problema de modelo; é um problema de sistemas. Onde ficam os pesos? Onde fica

03:42 o KV cache? Como manter mil solicitações em andamento? Os três mecanismos deste vídeo são, na verdade, três respostas diferentes a essas perguntas. Campeão número um: llama.cpp. Em março de 2023, GRG Gurgengh portou o modelo Midas Llama para rodar em C puro em um MacBook, basicamente como um projeto paralelo. Dois anos e meio depois, esse projeto paralelo tem cerca de 130.000 estrelas no GitHub e é, sem exagero, a base de todo o movimento de IA local.

04:12 Sua primeira grande ideia é o GGUF, um único arquivo que reúne os pesos, o tokenizer e os metadados. Um arquivo, arraste para qualquer lugar e ele roda. A segunda grande ideia é tratar a quantização como um recurso de primeira classe. Os Kqu Quants: você já viu nomes como Q4KM e Q5KM. Eles comprimem os pesos para quatro, até mesmo três ou dois bits por peso, com kernels escritos à mão que desquantizam em tempo real. É isso que reduz um modelo a um quarto do tamanho, com uma perda de qualidade surpreendentemente pequena.

04:43 E é por isso que GPUs de consumo conseguem participar. Terceiro: ele prioriza a CPU. Kernels CS SIM para VX2 e VX512. Carregamento mapeado em memória, para que um modelo maior que sua RAM ainda rode, tecnicamente. Uma opção de offload para a GPU, que permite transferir quantas camadas couberem na VRAM. E a lista de backends é absurda: CUDA, Metal, Vulcan, Rockom, SYCL, CPU puro, Windows, Mac OS, Linux, Android,

05:14 iPhones, Raspberry Pi. Se tem um processador, provavelmente roda Llama CPP. E eis a parte que as pessoas esquecem. Quando você usa uma Lama, LM Studio ou Llama file, está usando Llama CPP. A Mozilla.i comparou os quatro em setembro de 2026 e descobriu que os resultados ficavam a poucos por cento uns dos outros, porque compartilham o mesmo núcleo. As opções de compilação e as configurações de speculative decoding alteraram os números em até 63%, mais do que a escolha do servidor. Seu ponto fraco: ele é

05:45 feito para um usuário. Sob carga concorrente, a taxa de transferência quase não aumenta e o tempo até o primeiro token dispara. Além disso, ele oferece suporte a novas arquiteturas de modelos no ritmo da comunidade, e isso importa. Lembre-se disso para mais tarde. Licenciado sob MIT e mantido pela comunidade GGML, com uma enorme base de colaboradores. O mecanismo do povo. Campeão número dois: VLLM. Este surgiu no Sky Computing Lab da UC Berkeley no início de 2023. Wu Kuan, Juan Lee, Ayan Stoka e colegas. E

06:17 o artigo ganhou o prêmio de melhor artigo na SOSP, uma das principais conferências de sistemas operacionais. Esse detalhe importa porque a ideia genial do VLLM foi literalmente emprestada dos sistemas operacionais. Lembra do KV cache da cena 2? Antes do VLM, os mecanismos de serving reservavam um grande bloco contíguo de VRAM para cada solicitação, dimensionado para o pior caso. A maior parte ficava sem uso. O artigo mediu que de 60% a 80% da memória do KV era desperdiçada por fragmentação. A resposta do VLM, a paginação, é exatamente

06:51 como seu sistema operacional gerencia a RAM. Divida o KV cache em páginas de tamanho fixo, distribua-as conforme necessário e mantenha uma tabela de páginas que mapeia os tokens lógicos de cada solicitação para blocos físicos espalhados em qualquer lugar da memória. Não é preciso que sejam contíguos. O desperdício caiu de 60% a 80% para menos de 4%, o que significa que muito mais solicitações cabem na mesma GPU. Depois, some o batching contínuo. Em vez de esperar que um lote inteiro termine, o escalonador permite que novas solicitações entrem no meio da geração, a cada

07:21 iteração. O artigo original alegou uma taxa de transferência de duas a quatro vezes maior que a pilha de serving da era de 2023, e o projeto continuou avançando desde então: prefixo em blocos, captura de prefixo, prefill e decode desagregados. Paralelismo multi-GPU, FP8. Hoje, tem cerca de 93.000 estrelas, licença Apache 2.0 e colaboradores da Nvidia, Red Hat e Anthropic. E os resultados de setembro de 2025: a Red Hat comparou VLM

07:52 com Llama.CP, usando o mesmo modelo e o mesmo hardware, e aumentou a carga. Na carga máxima, VLM apresentou uma taxa de solicitações mais de 35 vezes maior e mais de 44 vezes mais tokens de saída por segundo. O tempo P99 até o primeiro token permaneceu estável até 64 usuários simultâneos, enquanto o de llama.cpp cresceu exponencialmente. É para isso que serve um mecanismo de serving. A desvantagem: ele quer hardware de data center. Nvidia, AMD, Instinct, TPUs, Tranium, servidores Linux. É exagero

08:23 para seu desktop, e ele tem orgulho disso. E agora, o desafiante. Para entender Strata, primeiro é preciso entender o modelo em questão. Ele foi criado para o Quen 3.8 8 flash next, da Alibaba, com pesos abertos desde o fim de agosto de 2026. É um modelo de mixture of experts com 125 bilhões de parâmetros, mas apenas cerca de 6 bilhões de parâmetros ficam ativos por token, porque ele encaminha cada token para apenas 10 especialistas entre 24.576. São 512 especialistas por camada, 48 camadas, mais uma

08:57 tabela de embedding ungram separada, com 51 bilhões de parâmetros, que funciona por consulta direta, sem computação, e uma cabeça MTP de previsão de múltiplos tokens com 4 bilhões de parâmetros. O tamanho total fica em torno de 180 bilhões de parâmetros para armazenar em algum lugar. Um mecanismo de uso geral olha para isso e entra em pânico. A sacada do Strata é não tratar a GPU como o computador. Trate o PC inteiro como o computador. Três níveis. Nível um: USVM da GPU. Camadas de atenção,

09:28 os misturadores Delta, roteadores, especialistas compartilhados, o KV cache, além de um cache adaptativo dos poucos milhares de especialistas mais usados, cerca de 700 especialistas adicionais por gigabyte de VRM. Ele aprende com o uso em tempo real. Nível 2: RAM do sistema. Todos os 24.576 especialistas ficam fixos nela. E aqui está o movimento-chave. A CPU calcula os especialistas que não estão no cache em paralelo com a GPU, usando kernels AVX 512. Nenhuma das duas espera pela outra. O segundo domínio de computação, não

09:59 troca ingênua via PCI Express. Nível três: [música] seu SSD; aqueles 28,8 GB ficam armazenados ali. Algumas linhas são lidas por token através do cache de páginas do sistema operacional. Isso quase não usa recursos de computação. Depois, decodificação especulativa. O próprio cabeçalho MTP do modelo propõe até três tokens à frente, e uma única passagem de verificação confere todos eles pelas 48 camadas. O autor relata de 2,4 a 3,2 tokens aceitos por passagem, um aumento de velocidade de 1,6 a 1,8 vez, e sem perda de qualidade.

10:30 Mesmo modelo, mesma distribuição. Também há a proposta de tokens por consulta ao prompt, buscando até cinco tokens em contextos repetidos, o que vale de 6% a 11% em edições de código. Para prompts, há pré-preenchimento em blocos de até 8.192 tokens, com os especialistas da próxima camada sendo carregados por PCI Express enquanto a atenção da camada atual é executada. O autor afirma que a ingestão de prompts ultrapassa 2.000 tokens por segundo com contexto de 32 mil e de 64 mil tokens, e além disso. O streaming de KV move o cache KV para a RAM

11:03 mantendo apenas a janela ativa na VRAM, liberando espaço para cerca de 2.300 especialistas em cache a mais, o que, segundo o autor, na verdade aumenta a velocidade com contexto de 262 mil tokens: de cerca de 51 para 63 tokens por segundo. Contextos longos ficam mais rápidos. Pense nisso. Certo, os números. E quero deixar muito claro de onde vêm esses dados. Cada número que você está prestes a ver foi medido pelo autor do Strata em uma máquina. Essa máquina tinha uma RTX 570

11:34 com 12 GB de VRAM. Um Ryzen 5 e 64 GB de DDR5, no Windows. Até 4 de outubro de 2026, não havia benchmarks independentes de terceiros — com esse enorme asterisco na tela. As velocidades de decodificação são impressionantes. Na quantização mais agressiva, Q20, o autor afirma que são 93 tokens por segundo com contexto de 4.000 tokens, e ainda 60 tokens por segundo com o contexto máximo de 262 mil tokens. A quantização mais conservadora, IQ3, afirma alcançar 53

12:06 tokens por segundo com contexto de 4K. [música] A variante coder podada, que mantém apenas 256 dos 512 especialistas por camada, preserva 91,3% do desempenho da versão completa no SWE-bench Verified e cabe em 32 GB de RAM; afirma alcançar cerca de 55 tokens por segundo com contexto curto. Portanto, dependendo da quantização, são de 53 a 94 tokens por segundo de um modelo com 125 bilhões de parâmetros, em uma GPU que você pode comprar em uma loja comum. Processamento de prompts. O autor relata cerca de

12:37 1.300 tokens por segundo com contexto de 4K, mais de 2.100 com contexto de 32K, e uma versão mais recente do engine, a 0.1.36, supostamente ultrapassa 2.600 tokens por segundo com kernels fused int8 para tensor cores. E a comparação principal: o autor e os primeiros usuários do Reddit relatam que o mesmo modelo roda a cerca de 11 a 15 tokens por segundo no llama.cpp em hardware semelhante, contra 62 a 65

13:08 no Strata. Daí vem a alegação de que é quatro vezes mais rápido que o llama.cpp. É uma comparação justa? Em parte. O suporte do llama.cpp a essa arquitetura novíssima era reconhecidamente rudimentar no lançamento. PRs de otimização ainda estavam sendo incorporados no início de outubro. A versão honesta: o Strata era cerca de quatro vezes mais rápido que o suporte ainda imaturo de um engine geral a um modelo lançado havia 10 dias. Isso continua sendo realmente impressionante; a especialização funciona. Mas não é a mesma coisa que dizer que o llama.cpp é lento. Enquanto isso,

13:41 as estrelas no GitHub foram de 0 a cerca de 8.700 em aproximadamente 10 dias, com 770 forks e 218 issues em aberto. A comunidade está submetendo o projeto a testes intensos. Hora de comparar os resultados. 10 dimensões. Vamos rápido. Um: velocidade de decodificação para um único usuário. O Strata afirma alcançar de 53 a 94 tokens por segundo [música] em um modelo com 125 bilhões de parâmetros, numa RTX 570. O llama.cpp

14:12 supostamente chega a cerca de 15 na mesma configuração. O vLLM e o llama.cpp ficam praticamente no nível da paródia com batch size um. A velocidade em um único fluxo nunca foi o ponto forte do vLLM. Ponto para o Strata, com asterisco. Dois: concorrência. O Strata lida com exatamente uma solicitação por vez. O llama.cpp quase não escala. O vLLM, 35 a 244 vezes. A capacidade de processamento do llama.cpp sob carga, segundo o Reddit. Ponto para o vLLM, não

Transcrição original

[00:00] On September 30th, 2026, a post hit the local law ma subreddit with a title that sounded like a typo. Quen 3.8 flash. Next, 50 tokens per second generation and 1500 tokens per second prompt processing with 12 GB of VRAM and 64 GB of RAM on a laptop. 100 dash and dash 20-5- billion-p parameter model on a laptop at reading speed.

[00:32] That post pulled around 150 upvotes and 140 comments. And it wasn’t even the first one. A few days earlier, another thread claimed 65 tokens per second. Quote, four times faster than llama.cpp. The engine behind both posts is called Strata. It appeared on GitHub on September 24th, built by a single anonymous developer. 3 days later, it was the number one trending C++ repository on GitHub. 3 days after that, it was number one

[01:04] across all languages. 10 days after it existed, it had over 8,000 stars and people on 4chan were calling it the llama.cpp killer. Half meme, half serious. Now, if you’ve been running local models for a while, your skepticism alarm should be screaming right now because this community has seen miracle engines before. So, in this video, we’re going to do this properly. We’re going to put Strata up against the two reigning champions of LLM inference. Llama.cpp, the engine that runs literally anything,

[01:36] literally anywhere, and VLM, the engine that serves thousands of users at once in data centers. Three engines, three totally different philosophies. By the end, you’ll know exactly which one belongs on your machine and whether the Reddit hype is real. But first, we need to understand why any of this is hard. Here’s the thing most people miss. A large language model doesn’t think in paragraphs. It generates exactly one token at a time. Each new token requires a full forward pass through the entire

[02:07] network, every layer, every weight that’s active. And then that token gets appended to the input and we do it all over again. That’s called auto reggressive decoding. And it means generating a 500 token reply means 500 sequential passes. You can’t parallelize it away because token number 500 literally cannot be computed until token 499 exists. This creates two very different workloads. First, there’s prefill processing your prompt. Quote, “All those prompt tokens already exist, so

[02:39] they can be chewed through in parallel. It’s a big dense matrix multiply that GPUs love. Then there’s decode generating the answer one token at a time where the GPU spends most of its time just reading weights for memory rather than computing. Decode is memory bandwidth bound. That’s why prompt processing is measured in thousands of tokens per second. while decode crawls along in tens. And then there’s the KV cache. Every token the model has ever seen in this conversation leaves behind key and value vectors at every layer.

[03:10] And the model needs all of them, every step to attend. The rough size is two for keys and values times the number of layers times the number of attention heads times the head dimension time the sequence length time bytes per element. The killer term there is sequence length. Double your context, double your KV cache. At long context, the KV cache can eat more memory than the model weights. So, inference serving is not a model problem, it’s a systems problem. Where do the weights live? Where does

[03:42] the KV cache live? How do you keep a thousand requests in flight? The three engines in this video are really three different answers to those questions. Champion number one, llama.cpp. In March of 2023, GRG Gurgengh ported Midas Llama model to run in plain C on a MacBook as basically a side project. Two and a half years later, that side project has around 130,000 GitHub stars and is without exaggeration the foundation of the entire local AI

[04:12] movement. Its first big idea is GGUF, a single file that bundles the weights, the tokenizer, and the metadata. one file, drag it anywhere, it runs. Second big idea is quantization as a first class citizen. The Kqu Quants, you’ve seen names like Q4KM, Q5KM, squeeze weights down to four, even three or two bits per weight with handwritten kernels that dequantize on the fly. That’s what shrinks a model to a quarter of its size with surprisingly little

[04:43] quality loss. And it’s the reason consumer GPUs can play at all. Third, it’s CPU first. CS SIM kernels for a VX2 and a VX512. Memory mapped loading, so a model bigger than your RAM still technically runs. An optional GPU offload where you push as many layers as fit into VRAM. And the backend list is absurd. CUDA, Metal, Vulcan, Rockom, SYCL, Plain CPU, Windows, Mac OS, Linux, Android,

[05:14] iPhones, Raspberry Pi. If it has a processor, Llama CPP probably runs on it. And here’s the part people forget. When you use a Lama or LM Studio or Llama file, you’re using Llama CPP. Mozilla.i benchmarked all four in September 2026 and found them within a few% of each other because they share the same core. Build flags and speculative decoding settings moved the numbers by up to 63% more than the choice of server did. Its weakness, it’s

[05:45] built for one user. Under concurrent load, throughput barely grows and time to first token balloons. It also serves new model architectures on community time, which matters. Remember that for later. MIT licensed, maintained by the GGML or community with a huge contributor base. The people’s engine champion number two, VLLM. This one came out of UC Berkeley’s Sky Computing Lab in early 2023. Wu Kuan, Juan Lee, Ayan Stoka and colleagues. And

[06:17] the paper won best paper at SOSP, one of the top operating systems conferences. That detail matters because VLLM’s killer idea is literally borrowed from operating systems. Remember the KV cache from scene 2? Before VLM, serving engines reserved a big contiguous chunk of VRAM for every request, sized for the worst case. Most of it set unused. The paper measured 60 to 80% of KV memory wasted to fragmentation. VLM’s answer page detention is exactly

[06:51] how your OS manages RAM. Chop the KV cache into fixed-siz pages, hand them out on demand, and keep a page table mapping each request’s logical tokens to physical blocks scattered anywhere in memory. No contiguity needed. Waste dropped from 60 to 80% to under 4%. which means far more requests fit in the same GPU. Then stack continuous batching on top. Instead of waiting for a whole batch to finish, theuler lets new requests join mid generation at every

[07:21] iteration. The original paper claimed two to four times the throughput of the 2023 era serving stack and the project has kept sprinting since chunked prefix, prefix [music] catching, disagregated prefill, and decode. Multi-GPU parallelism FP8. Today it’s at roughly 93,000 stars, Apache 2.0 with contributors from Nvidia, Red Hat, [music] and Anthropic. And the receipts in September 2025, Red Hat ran VLM

[07:52] against Llama.CP, same model, same hardware, and ramped up the load. At peak load, VLM delivered over 35 times the request throughput and over 44 times the output tokens per second. Its P99 time to first token stayed flat out to 64 concurrent users while llama.cppps grew exponentially. That is what a serving engine is for. The catch, it wants data center hardware. Nvidia, AMD, Instinct, TPUs, Tranium, Linux servers. It’s overkill

[08:23] for your desktop and proud of it. And now the challenger. To understand Strata, you first need to understand the one model. It was built for Alibaba’s Quen 3.8 8 flash next open weights since late August 2026. It’s a 125 billion parameter mixture of experts model, but only about 6 billion parameters are active per token because it roots each token to just 10 experts out of 24,576. 512 experts per layer, 48 layers, plus a

[08:57] separate 51 billion parameter ungram embedding table, pure lookup, no compute, and a 4 billion parameter MTP multi-token prediction head. Total footprint around 180 billion parameters of stuff to store somewhere. A general purpose engine sees that and panics. Straight as insight is, don’t treat the GPU as the computer. Treat the whole PC as the computer. Three tiers. [music] Tier one, the GPU USVM. Attention

[09:28] layers, the Delta mixers, routters, shared experts, the KV cache, plus an adaptive cache of the hottest few thousand experts, about 700 experts per extra gigabyte of VRM. Learn from live usage. Tier 2 system RAM. All 24,576 experts pinned there. And here’s the key move. The CPU computes the cache mist experts in parallel with the GPU using AVX 512 kernels. Neither waits for the other. The second compute domain, not

[09:59] naive PCI Express swapping. Tier three, [music] your SSD, that 28.8 GB on table lives there. A few rows red per token through the OS page cache. It barely touches compute. Then speculative decoding. The model’s own MTP head drafts up to three tokens ahead and one verification pass over all 48 layers, checks them. The author reports 2.4 to 3.2 tokens accepted per pass, a 1.6 to 1.8 time speed up, and it’s lossless.

[10:30] Same model, same distribution. There’s also prompt lookup drafting, grabbing up to five tokens from repeated context, worth 6 to 11% on code edits. for prompts chunked prefill up to 8,192 token chunks with the next layer’s experts streaming over PCI Express while the current layer’s attention runs. The author claims over 2,000 tokens per second of prompt ingestion at 32k context and at 64k context and beyond. KV streaming moves the KV cache into RAM

[11:03] with only the hot window in VRAM, freeing space for roughly 2,300 more cached experts, which the author says actually raises speed at 262K context from about 51 to 63 tokens per second. Long context gets faster. Wrap your head around that. Okay, the numbers. And I want to be extremely clear about sourcing here. Every figure you’re about to see was measured by Strata’s author on one machine. That machine, an RTX 570

[11:34] with 12 GB of VRAM. A Ryzen 57,64 GB of DDR5 on Windows. There are no independent thirdparty benchmarks as of October 4th, 2026 with that giant asterisk on screen. They’re wild decode speed. At the most aggressive quant Q20, the author claims 93 tokens per second at 4,000 context, still 60 tokens per second at the full 262K context. The more conservative IQ3 quant claims 53

[12:06] tokens per second at 4K. [music] The pruned coder variant which keeps only 256 of 512 experts per layer retains 91.3% of full swbench verified performance and fits in 32 gigs of ram claims around 55 tokens per second at short context. So depending on quant 53 to 94 tokens per second from a 125 billion parameter model on a GPU you can buy in a normal store. prompt processing. The author reports roughly

[12:37] 1,300 tokens per second at 4K over 2,100 at 32K and a newer engine version 0.1.36 reportedly pushes that past 2,600 tokens per second with fused int 8 tensor core kernels. And the headline comparison, the author and early Reddit users report the same model running around 11 to 15 tokens per second through llama.cpp on similar hardware versus 62 to 65

[13:08] through strata. Hence the four times faster than llama.cpp claim. Is that a fair fight? Partially. LMA.CP’s support for this brand new architecture was admittedly rough at launch. Optimization PRs were still landing in early October. The honest version, Strata was about four times faster than a general engine’s immature support for a 10-day old model. That’s still genuinely impressive specialization works, but it’s not the same as llama.cpp is slow. Meanwhile,

[13:41] GitHub stars 0 to roughly 8,700 in about 10 days with 770 forks and 218 open issues. The community is stress testing it hard. Time for the tale of the tape. 10 dimensions. Rapid fire. One. Single user decode speed. Strata claims 53 to 94 tokens a second [music] on a 125 billion parameter model on an RTX 570. Llama.cpp

[14:12] reportedly manages about 15 on the same setup. VLM and Llama.CP are actually near parody at batch size one. Single stream speed was never VLM’s game. Round to straighta asterisked two [music] concurrency. Strata handles exactly one request at a time. Llama.cpp barely scales. Vlm 35 244 times. Llama.cpp’s throughput under load per red hat. Round of ELM, no