Nossa configuração experimental: um modelo de aproximadamente 83,6 GB rodando localmente em um RTX 3060 econômico

Isso é incrível!

Qwen3.8-Flash-Next IQ3_S (~83,6 GB) rodando localmente com um orçamento RTX 3060 de 12 GB com apenas 48 GB de RAM do sistema!

Decodificação de até 68 tokens/seg, processamento de prompt de aproximadamente 916 tokens/seg e um prompt de 30 mil tokens processado em apenas 34 segundos.

Desenvolvido por Strata por coldniko. Nenhuma inferência de nuvem. Apenas hardware de consumo acessível!

Benchmarks completos, especificações de hardware, otimizações e compensações abaixo.

Você pode ir direto para as principais conclusões na seção final.

O hardware por trás desses resultados

Sem GPU de datacenter, sem servidor multi-GPU caro e sem configuração de RAM massiva.

Todo o experimento foi realizado em um PC de consumo/estação de trabalho bastante comum.

CPU

• Intel Core Ultra 7 265 (Arrow Lake)
• 20 núcleos/20 threads
• Até 5,3 GHz
• Cache L3 de 30 MB
• Suporte AVX-VNNI/BF16; sem AVX-512

Placa-mãe

• ASUS Pro Q870I-C
• Chipset Intel Q870, LGA1851
• Fator de forma Mini-ITX

Memória

• 48 GB DDR5-5600 (2 × 24 GB Micron)
• Aproximadamente 46 GiB utilizáveis

GPU

• NVIDIA GeForce RTX 3060 12 GB
• GA106, capacidade de computação 8.6
• PCIe 4.0 ×16
• Limite de potência configurado de 170 W

Armazenamento

• Lexar NM1090 PRO 2 TB
• PCIe 5.0 ×4 NVMe

OS

• Ubuntu 24.04.5 LTS
• Kernel Linux 7.0.0-38
• Controlador NVIDIA 615.71.10

Rede

• Intel 1 GbE Ethernet

O detalhe crucial: o modelo é muito maior do que a VRAM e a RAM disponíveis combinadas.

É exatamente isso que torna este experimento interessante.

Modelo, mecanismo e arquitetura de memória

Modelo

Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S

Dois fragmentos GGUF:

• 54.82 GB
• 28.80 GB
• Total: 83,62 GB (77,87 GiB)

Componentes adicionais

• Pesos densos compactados: ~1,5 GiB
• Redator de decodificação especulativa MTP
• Adaptador de visão BF16: ~866 MB
• Codificador de visão baseado em CPU (12 threads)

Mecanismo de inferência

• Strata engine 0.1.52
• Infra-estrutura CUDA 13.0
• Arquitetura CUDA sm_86

Alocação de memória real

• GPU VRAM: 11,14 GiB usados
• Especialistas residentes em RAM do sistema: 24 GiB
• Dados de especialistas restantes transmitidos do NVMe
• Nenhuma atividade de troca durante a inferência normal

Definições de configuração importantes

--expert-cache auto
--prefill 4096
--spec 4
--spec-min-p 0.5
--mtp mtp/rt
--max-context 32768
--kv int8
--kv-grow
--kv-resident 32768
--vision
--vram-reserve-mib 960
--pool-workers 12
--conversation-cache-mib 1536
--prompt-cache-tail
--prompt-cache-spread
--resident-experts
--resident-budget-gib 24

Esta não é uma configuração convencional de “carregar todo o modelo na memória da GPU”.

Strata usa memória GPU, RAM do sistema, cache especializado e armazenamento NVMe juntos.

A otimização importante é minimizar transferências caras de especialistas e, ao mesmo tempo, manter a produtividade da GPU.

Resultados reais de benchmark

Mesmo modelo, mesmo hardware, duas configurações de roteamento.

Modo A: encaminhamento especializado rápido e baseado na residência (anterior = 1,5)

Tempo frio para o primeiro token:

• 1K: 3.7 s
• 4K: 4.9 s
• 8K: 9.7 s
• 16K: 17.3 s
• 30K: 33.9 s

Para efeito de comparação, o Modo B desativa o roteamento baseado em residência (prior = 0):

Execução de geração de 500 tokens:

• Rápido: 62 tok/s, 7,1 s no total
• Preciso: 21 tok/s, 20,8 s no total

As medições de velocidade foram comparadas com os tempos de streaming do lado do cliente.

Observação principal:

Desabilitar o roteamento baseado em cache pode reduzir a velocidade de decodificação em aproximadamente 2–2,4×.

Mas há um motivo importante para não deixar o roteamento agressivo habilitado para todas as cargas de trabalho. Mais sobre isso na próxima seção.

Velocidade versus qualidade do modelo: a compensação oculta

Nesta versão do mecanismo Strata, GPUs com VRAM ≤13 GB usam automaticamente roteamento baseado em residência:

STRATA_ROUTE_PRIOR=1.5

Isso favorece os especialistas já disponíveis na memória rápida, em vez de sempre selecionar os especialistas que o roteador original preferiria.

O benefício é dramático:

• Taxa de acerto do cache especialista: 97,2% no modo rápido
• Sem preconceito: 65,3%
• Leituras de armazenamento durante a carga de trabalho comparada: 5,5 GiB vs 46 GiB
• Velocidade de decodificação: aproximadamente 2× mais rápida

Mas esta NÃO é uma otimização gratuita.

Alterar a seleção de especialistas pode alterar o comportamento do modelo, aumentar a divergência do modelo original e afetar longos raciocínios ou fluxos de trabalho dos agentes.

De acordo com a avaliação do desenvolvedor em 10 tarefas do agente:

• Roteamento anterior a 1,5: 4,5/10
• Roteamento antes de 0: 5,6/10

Os próprios resultados da linha de base variaram entre as execuções, portanto este é um resultado direcional, não uma medição de qualidade definitiva.

Minhas seis verificações curtas de agente foram aprovadas em ambos os modos.

No entanto, uma execução de estresse de exclusividade separada expôs a repetição:

• Modo rápido: 205 linhas, 96 duplicatas
• Modo preciso: 209 linhas, 79 duplicatas

A conclusão é direta:

• Roteamento rápido para bate-papo, uso interativo e tarefas curtas.
• Roteamento original para fluxos de trabalho de agentes mais longos e sensíveis à qualidade.

E a velocidade de referência por si só nunca deve ser confundida com a qualidade do modelo.

O cache imediato muda tudo

Um dos resultados mais impressionantes não foi a velocidade de decodificação. Foi o tempo de resposta para solicitações repetidas usando o mesmo prompt.

Com um prompt totalmente armazenado em cache:

Isso representa cerca de 45 a 90 vezes menos tempo para o primeiro token nessas execuções.

O cache de prompt faz uma enorme diferença ao consultar repetidamente o mesmo documento longo ou manter uma conversa com um contexto estável.

O mecanismo também está configurado para cache de conversas:

• Orçamento de cache de 1.536 MiB
• Mínimo de 4.096 tokens para estacionamento
• Limite mínimo de memória livre: 1.536 MiB

Há um problema: esses resultados são para prompts idênticos com um cache totalmente reutilizável.

Isso não significa que novos prompts arbitrários de 30 mil tokens serão processados ​​em meio segundo.

Mas para a IA local interativa, um cache quente é uma virada de jogo.

O mistério do SSD: PCIe 5.0 não é o gargalo

A princípio, a unidade NVMe parecia suspeitamente lenta. Investigamos o link PCIe, a topologia de armazenamento e o comportamento real de E/S.

A unidade: Lexar NM1090 PRO 2 TB, PCIe 5.0 ×4.

Conexão PCIe verificada:

• Ligação atual: 32,0 GT/s ×4
• Link máximo: 32,0 GT/s ×4
• Porta raiz da CPU: 32,0 GT/s ×4

Portanto, a unidade está funcionando em velocidade total do link PCIe 5.0.

Benchmarks de leitura diretos sem cache:

• Fluxo único, blocos de 1–4 MiB: 2,9–3,4 GB/s
• Quatro fluxos paralelos: 10,94 GB/s
• Quatro fluxos, blocos de 64 KiB: 2,25 GB/s
• Quatro fluxos, blocos de 4 KiB: 0,26 GB/s (~63 mil IOPS)

Esse resultado paralelo de 10,94 GB/s é particularmente importante: ele excede a largura de banda prática do PCIe 4.0 ×4.

Por que a taxa de transferência de fluxo único é muito menor?

Porque a largura de banda PCIe não é a mesma coisa que a taxa de transferência no nível do aplicativo.

Profundidade da fila, tamanho de E/S, paralelismo de solicitação e latência são importantes.

O padrão de carregamento especializado do Strata está muito mais próximo do caso de menor simultaneidade do que de um benchmark sintético de rendimento máximo.

Taxa de transferência de armazenamento do mecanismo observada:

• Roteamento rápido: ~0,3 GB/s
• Roteamento original: ~2,4 GB/s

A diferença vem de quantos especialistas devem ser obtidos, não de um downgrade do PCIe.

Mais um detalhe útil: o próprio RTX 3060 é um dispositivo PCIe 4.0. Ver seu link cair para Gen1 enquanto ocioso é um comportamento normal de gerenciamento de energia.

Sempre verifique qual dispositivo você está medindo antes de diagnosticar um problema de PCIe.

Uma lição importante: não deixe o Linux armazenar em cache um modelo de 83,6 GB em uma máquina de 48 GB

Encontramos um problema sério durante a inicialização.

A primeira configuração permitiu o carregamento em buffer dos arquivos do modelo.

O modelo tem ~83,6 GB, enquanto o sistema possui apenas 48 GB de RAM física.

Sob essa carga de trabalho, o Linux sofreu forte pressão de recuperação de memória. A máquina quase não respondeu, incluindo a conectividade SSH, e exigiu uma reinicialização forçada.

A solução foi mudar a estratégia de carregamento e introduzir proteções de memória.

Configurações atuais:

• STRATA_UNBUFFERED_LOAD=1
• STRATA_RESIDENT_HEADROOM_GIB=10
• Orçamento de especialista residente de 24 GiB
• Disponibilidade de memória verificada antes do lançamento
• Margem de segurança adicional de 12 GiB na política de lançamento

Após essas alterações:

• Nenhuma atividade de troca durante a inferência normal
• Aproximadamente 34,6 GiB RAM em uso no ponto observado
• Aproximadamente 12,7 GiB disponíveis
• Geração estável sob carga

A lição:

É possível executar um modelo maior que sua memória física, mas a contabilidade da memória é absolutamente crítica.

A pressão do cache de página, os dados do modelo fixado, os especialistas residentes e o cache KV devem ser considerados em conjunto.

Não copie cegamente sinalizadores de desempenho máximo de máquinas com configurações de RAM muito maiores.

Consumo de energia, térmicas e custo de inferência

Esta é outra agradável surpresa.

Potência medida do componente:

Inativo com modelo carregado:

• CPU: ~5.8 W
• GPU: 15–18 W

Durante a geração:

• CPU: ~62.8 W
• GPU: 152–167 W
• Breves picos de GPU em torno de 174 W

Potência total estimada do sistema na parede (não medida com medidor de parede):

• Inativo: ~54 W
• Geração: ~280 W

Temperaturas observadas:

• GPU sob carga: 62–68°C
• GPU em modo inativo: ~40°C
• NVMe: 38–47°C

Nenhum estrangulamento térmico observado.

A um preço presumido de eletricidade de 0,25€/kWh:

• 24 horas inativas: ~€0,32
• 30 dias continuamente inativos: ~€9,72
• Uma hora de geração ativa: ~€0,07

Isso torna totalmente realista operar um endpoint de IA local capaz e que preserva a privacidade em casa.

É claro que esses são custos estimados de eletricidade, e não o custo total de propriedade. A depreciação, resfriamento e manutenção de hardware estão excluídas.

Onde a configuração do RTX 3060 deixa de fazer sentido

Esta configuração é excelente para solicitações interativas curtas, mas tem limites.

Mais importante ainda:

• Contexto máximo: 32.768 tokens
• Um prompt próximo a 32K deixa espaço insuficiente para geração
• O teto de referência prático foi de aproximadamente 30.165 tokens de entrada
• O pensamento/raciocínio pode consumir centenas de tokens gerados adicionais
• Sessões de agentes de longa duração tornam-se rapidamente restritas

Para efeito de comparação, executei o mesmo modelo em um sistema local mais poderoso com uma GPU de 24 GB.

Desempenho medido nesse sistema:

• Pré-preenchimento de prompt 4K: 1.339 tok/s
• Decodificação 4K: 94 tok/s
• Pré-preenchimento de prompt de 16K: 2.956 tok/s
• Decodificação de 16K: 125 tok/s
• Contexto máximo: 262.144 tokens
• 15 threads de trabalho

O sistema RTX 3060 oferece uma taxa de transferência de pré-preenchimento muito menor e cerca de metade da taxa de transferência de decodificação em casos comparáveis, com um oitavo do contexto disponível.

No entanto, o cartão de 12 GB é muito mais acessível e continua impressionantemente útil.

Minha abordagem atual:

• Hardware mais poderoso para agentes complexos e de longa duração
• GPUs acessíveis de 12 GB para bate-papo, fluxos de trabalho curtos, experimentos e inferência de backup

A questão não é fingir que uma GPU barata substitui uma máquina de última geração.

A questão é o quanto a IA local útil já pode ser executada em hardware barato.

O que ainda pode ser otimizado?

O sistema já está funcionando bem, mas existem alguns caminhos interessantes para novas experiências.

Inferência simultânea

A opção --slots 2 poderia melhorar o rendimento total com duas conversas simultâneas.

Uma taxa de transferência agregada estimada de +10–12% é possível para esta carga de trabalho, mas precisa de validação.

Isso não significa que uma única conversa se torne 12% mais rápida.

Lotes de pré-preenchimento maiores

Atual: --prefill 4096

Candidato: --prefill auto:16384

Janelas de pré-preenchimento maiores podem melhorar o processamento de prompts longos, mas a VRAM disponível já é limitada.

Com aproximadamente 11,14 GiB dos 12 GiB da GPU ocupados, o comportamento da memória deve ser medido com cuidado.

Mais RAM do sistema

Usar --ple-io ram pode trazer mais dados do modelo para a memória do sistema e reduzir as leituras de armazenamento.

A documentação do desenvolvedor sugere:

• +16–31% de desempenho de pré-preenchimento
• +3–11% de desempenho de decodificação

Mas esta configuração exigiria substancialmente mais RAM, aproximadamente 72+ GiB para o layout medido.

Não é prático na configuração atual de 48 GB.

Decodificação especulativa

A decodificação especulativa MTP já está habilitada.

Aceitação observada: ~33–41 tokens aceitos de 50–60 elaborados, ou aproximadamente 65–70%.

Contexto mais longo

O limite atual de 32K é um limite de configuração operacional e não é uma evidência de que o modelo em si suporta apenas 32K.

Aumentá-lo requer uma nova verificação da capacidade de memória, comportamento do cache KV, latência e estabilidade.

Para esta carga de trabalho, reduzir leituras especializadas caras e melhorar os padrões de acesso pode ser mais importante do que aumentar a largura de banda sequencial máxima da unidade.

Como sempre: compare a carga de trabalho real, não apenas os números de marketing de hardware.

Considerações finais

Aqui está o que este experimento demonstra.

Um modelo MoE quantizado de aproximadamente 83,6 GB pode ser executado localmente em:

• RTX 3060 12 GB
• 48 GB DDR5 RAM
• CPU Intel de consumo
• PCIe 5.0 NVMe SSD
• Ubuntu + Strata

Com resultados medidos até:

• Decodificação quente de 68 tok/s
• Processamento imediato de 916 tok/s
• Solicitação fria de 30 mil tokens em aproximadamente 34 segundos
• Prompt de 30K totalmente armazenado em cache: ~0,44 s para o primeiro token
• Nenhuma troca em condições normais de operação

Mas há advertências importantes.

• O contexto máximo configurado é 32K
• O roteamento especializado rápido muda o comportamento do modelo
• A velocidade mais alta não é necessariamente a mais alta qualidade
• O desempenho do armazenamento depende dos padrões de acesso
• O gerenciamento de memória requer ajuste cuidadoso
• Agentes de longa duração se beneficiam de hardware mais poderoso

Estou particularmente interessado na economia prática da IA local.

Não apenas o benchmark máximo num sistema de 10.000€, mas o desempenho útil alcançável em máquinas de consumo e configurações acessíveis a partir de cerca de 1.000€.

Privacidade, independência, custos operacionais controlados e utilidade no mundo real são mais importantes do que perseguir apenas números de referência impressionantes.

Este ainda é um experimento em evolução e continuarei compartilhando as medições, falhas, alterações de configuração e melhorias.

O futuro da IA ​​local já está se tornando surpreendentemente acessível.

Adições posteriores

Ah, esqueci de mencionar que a GPU está rodando com NVIDIA Unlock, que foi lançado há poucos dias, na semana passada.

Agora pedi ao meu agente de IA para executar os mesmos benchmarks sem o desbloqueio, para que possamos comparar os resultados em cerca de 15 a 20 minutos.

Nos próximos dias, embora não hoje, instalarei esta GPU em um sistema que custa menos de US$ 1.000 e verei como ela funciona lá.

Tópico original em X · Todas as notícias