O projeto Janas-LLM transmite os experts de modelos MoE do SSD para a memória sob demanda e afirma superar o llama.cpp em velocidade em todos os 13 modelos testados.
O gargalo: modelo maior que a memória do notebook
Rodar um modelo de linguagem↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → localmente sempre esbarrou na mesma conta: o arquivo de pesos precisa caber na memória (RAM ou VRAM) para o modelo responder em velocidade útil. Um modelo como o Qwen3-Next-80B-A3B pesa 48,4 GB na quantização usada nos testes. Num notebook com 32 GB de RAM, isso simplesmente não cabe, e a saída tradicional é deixar o sistema operacional trocar páginas com o disco, o que historicamente derruba a velocidade a quase nada.
O Janas, projeto publicado no GitHub por Maurizio "camauri" Cammalleri, ataca esse problema de um jeito específico: em vez de tentar encaixar o modelo inteiro na RAM, ele assume que vai faltar espaço e organiza o acesso ao disco em volta disso. O primeiro componente da família, o Janas-LLM, é descrito no próprio repositório rodando o tal modelo de 80 bilhões de parâmetros num laptop com 32 GB, respondendo a 37 tokens por segundo.
Pesos no disco, cache na memória: como funciona
A peça central é o fato de os modelos citados serem MoE (mixture-of-experts): a cada token gerado, só uma fração dos "especialistas" internos do modelo é realmente usada, não a rede inteira. O Janas-LLM explora isso de forma literal: os pesos ficam no SSD, os experts que o token atual precisa são lidos do disco (via O_DIRECT, em leitura direta sem passar pelo cache de página do sistema), e os que voltam a ser chamados com frequência ficam retidos numa área de memória dedicada.
Na prática, isso significa que o tamanho do modelo deixa de ser limitado pela RAM e passa a depender da velocidade do SSD. A máquina de referência do projeto tem um NVMe que lê a cerca de 5,7 GB/s, e é nela que todos os números abaixo foram medidos (Debian 13, kernel 6.12.107, Intel Core Ultra 9 185H com GPU integrada Arc, 32 GB de DDR5). Em outra máquina, com outro disco, os números mudam, e o projeto é explícito sobre isso.
Os números: Janas-LLM contra o llama.cpp
O repositório publica uma comparação direta com o llama.cpp (build de 18 de setembro de 2026, backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → Vulkan, mesma GPU integrada), medida entre 9 e 12 de outubro de 2026, em quatro dos treze modelos comparados:
| Modelo | Tamanho | Leitura (Janas) | Leitura (llama.cpp) | Escrita (Janas) | Escrita (llama.cpp) |
|---|---|---|---|---|---|
| Qwen3-Next-80B-A3B | 48,4 GB | 62 tok/s | 16 tok/s | 37 tok/s (24 sem drafts) | 2,8 tok/s |
| Qwen3-Coder-Next | 48,4 GB | 66 tok/s | 14 tok/s | 22 tok/s | 2,2 tok/s |
| Qwen3.6-35B-A3B | 22,3 GB | 104 tok/s | 79 tok/s | 19 tok/s | 12 tok/s |
| Qwen3-30B-A3B | 18,6 GB | 135 tok/s | 122 tok/s | 32 tok/s | 15 tok/s |
O caso do Qwen3-Next-80B-A3B é o mais revelador: com o arquivo maior que a memória da máquina, o llama.cpp em sua configuração normal simplesmente não roda (fica sem memória assim que a GPU entra, mesmo deixando os experts na CPU). Para gerar algum número de comparação, o projeto precisou rodar o llama.cpp numa build sem repacking de pesos (GGML_CPU_REPACK=OFF) e com as flags --no-host 1 -lm mmap, que deixam os experts no arquivo, lidos pelo cache de página do sistema. Mesmo assim, o llama.cpp escreveu a 2,8 tokens por segundo contra os 37 do Janas-LLM.
Além do chat: completar código no editor
Para quem pensa em usar isso no dia a dia de desenvolvimento, o projeto inclui o janas-server, que expõe o modelo numa API compatível com a da OpenAI e também implementa o endpoint /infill do llama.cpp, o mesmo que a extensão llama.vscode consome. A ideia é rodar um modelo de código como o Qwen3-Coder-30B-A3B localmente e ter autocompletar no VSCodium ou VS Code sem depender de um serviço de nuvem.
O documento técnico do projeto registra 1,5 a 2,2 segundos por sugestão na máquina de referência, com uma otimização específica: a janela de contexto enviada a cada tecla digitada é mantida fixa, de forma que uma tecla só força a releitura do que mudou. Quando a janela desliza uma linha inteira, a releitura sobe para 17 segundos, o que dá uma ideia de quanto a engenharia de cache pesa no resultado final.
Isto é experimental, e o autor avisa
O README do Janas abre com um aviso que vale repetir, porque muda a forma como ler os números acima:
Isto é um experimento, não um produto.
This is an experiment, not a product.Maurizio Cammalleri, autor do Janas
O projeto detalha o que isso significa na prática: a API pública e a linha de comando mudam sem aviso (já mudaram várias vezes por semana), o motor é deliberadamente agressivo com a máquina (enche a memória livre com o cache de experts e lê o disco na velocidade máxima), e numa máquina com menos folga do que ele calcula, o desktop pode ser empurrado para swap e travar. Um uso da GPU já causou, uma vez, um reset de driver que derrubou a sessão gráfica inteira.
Há válvulas de escape documentadas: Ctrl-C interrompe uma resposta, Ctrl-D sai do chat, a flag --cache <GiB> impõe um limite rígido de memória, e a variável JANAS_GPU=0 tira a GPU da jogada por completo. O projeto também registra que testar numa máquina ociosa é importante: com um navegador e um editor abertos, o mesmo modelo manteve cerca de três quartos da velocidade, mas esperou cinco vezes mais pelo disco.
O que ainda falta provar
Tudo que está documentado foi medido numa única máquina: o notebook com Core Ultra 9 185H, GPU Arc integrada e SSD NVMe de 5,7 GB/s. O próprio projeto afirma nunca ter testado em outras CPUs (especialmente sem a extensão AVX-VNNI, ou em processadores AMD), em GPUs dedicadas, em discos mais lentos, ou com mais ou menos memória disponível. Para quem roda em hardware diferente, o relatório gerado pelo janas-bench é, nas palavras do projeto, a contribuição mais útil que se pode enviar de volta.
Para quem quer testar, o binário para Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → x86-64 sai em três comandos:
curl -LO https://github.com/prabanta-dev/janas/releases/latest/download/janas-linux-x86_64.tar.gz
tar xf janas-linux-x86_64.tar.gz && cd janas
./janas-chatHá também build para Windows 10 (1903 ou posterior) e Windows 11, x86-64, testada no mesmo notebook sob o driver gráfico próprio da Intel, com desempenho equivalente ao Linux em escrita e até 1,8 vez mais rápido em leitura de prompt para modelos densos. O código é GNU GPL v3 ou posterior, escrito em C puro sem dependências além da biblioteca padrão, o que facilita embutir em outros projetos, mas também é um lembrete de que não há empresa nem suporte por trás: é um experimento de um desenvolvedor, publicado e mantido em público.
Fonte: Hacker News
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Microsoft detalha Maia 300, terceiro chip de IA próprio voltado a cortar custo na Azure
A gigante anunciou nesta segunda-feira (12) o Maia 300, chip projetado para rodar seus próprios modelos e os da OpenAI na Azure, prometendo mais eficiência por watt que GPUs líderes do mercado.
