Nova versão integra o Leap Micro, apresenta KDE Plasma 6.6, moderniza ferramentas de desenvolvimento e fortalece a integração com o SUSE Linux Enterprise Server.

3 de novembro de 2026

O Projeto openSUSE anunciou oficialmente o lançamento do openSUSE Leap 16.1, trazendo uma das mudanças mais importantes da história recente da distribuição: a integração do openSUSE Leap Micro diretamente ao Leap, por meio de um novo modo de instalação chamado Immutable Mode.

A novidade representa um avanço significativo na estratégia do projeto, permitindo que uma única distribuição Linux atenda diferentes necessidades, desde estações de trabalho e servidores tradicionais até ambientes de virtualização, contêineres, computação de borda (Edge Computing) e infraestruturas empresariais.

Mais do que uma atualização de pacotes, o openSUSE Leap 16.1 consolida uma arquitetura que combina estabilidade, segurança, flexibilidade e modernização.

Uma distribuição, duas abordagens: tradicional e imutável

A principal novidade do openSUSE Leap 16.1 é a possibilidade de escolher entre dois modelos de instalação utilizando a mesma imagem e o instalador Agama.

Modo tradicional: mantém a abordagem clássica do Linux, com sistema de arquivos raiz em leitura e escrita, permitindo a instalação e administração convencional de pacotes e serviços.

Modo imutável (Immutable Mode): utiliza um sistema de arquivos raiz somente para leitura, com atualizações transacionais e mecanismos de recuperação baseados em snapshots.

Esse segundo modelo incorpora a experiência anteriormente oferecida pelo openSUSE Leap Micro, distribuição especialmente desenvolvida para servidores, execução de contêineres e dispositivos de borda.

Com essa integração, o Leap Micro deixa de existir como uma distribuição independente. Não haverá versões Leap Micro 6.3 ou 7.0. Seu sucessor passa a ser o próprio openSUSE Leap 16.1 em modo imutável.

A mudança simplifica o ecossistema openSUSE, permitindo que diferentes perfis de usuários compartilhem o mesmo ciclo de manutenção e atualizações.

Immutable Mode: mais segurança e previsibilidade

Uma das vantagens dos sistemas imutáveis está na maneira como as atualizações são aplicadas.

Em vez de modificar diretamente o sistema em execução, o openSUSE utiliza o mecanismo transactional-update, que prepara as alterações em um novo snapshot.

Isso proporciona benefícios importantes:

• Atualizações mais previsíveis: alterações são aplicadas de maneira transacional.
• Recuperação simplificada: problemas após atualizações podem ser revertidos utilizando snapshots anteriores.
• Maior consistência: reduz alterações inesperadas no sistema operacional.
• Segurança operacional: diminui a superfície de modificações persistentes no sistema base.
• Adequação a ambientes críticos: especialmente útil para servidores, appliances, dispositivos de borda e infraestrutura de contêineres.

Aplicações e dependências adicionais podem ser executadas de forma isolada utilizando tecnologias como Podman, Distrobox e Flatpak, conforme o cenário de utilização.

Essa abordagem se mostra particularmente interessante para infraestruturas modernas, nas quais a estabilidade do sistema operacional é tão importante quanto a capacidade de atualizar aplicações rapidamente.

Agama 24: uma nova experiência de instalação

O instalador Agama, introduzido no openSUSE Leap 16.0, chega à versão 24 com melhorias de maturidade e integração.

Agora, durante a instalação, o usuário pode selecionar o modelo tradicional ou imutável diretamente na interface.

Essa evolução elimina a necessidade de imagens de instalação completamente diferentes para os dois modelos de utilização.

O Agama também representa uma modernização importante da arquitetura de instalação do openSUSE, com recursos que favorecem automação, implantação e gerenciamento em diferentes ambientes.

Integração ainda maior com o SUSE Linux Enterprise Server 16.1

Outro marco importante é o alinhamento do lançamento do openSUSE Leap 16.1 com o SUSE Linux Enterprise Server (SLES) 16.1.

Pela primeira vez nessa série, os dois sistemas são lançados no mesmo dia, permitindo maior sincronização das atualizações de manutenção.

O openSUSE Leap continua utilizando uma base compartilhada com o SUSE Linux Enterprise, preservando compatibilidade de código-fonte e binários nos componentes compartilhados.

Para desenvolvedores e empresas, essa integração oferece vantagens importantes.

É possível desenvolver, testar e validar aplicações utilizando o openSUSE Leap e posteriormente implantá-las em ambientes empresariais baseados no SLES, com maior previsibilidade de compatibilidade.

A estratégia reforça o papel do openSUSE como plataforma comunitária de desenvolvimento, pesquisa, inovação e implantação de soluções empresariais.

KDE Plasma 6.6 e atualizações para o desktop

Os usuários de desktop também recebem novidades importantes.

O destaque fica para o KDE Plasma 6.6, que substitui a versão 6.4 presente no lançamento anterior.

A atualização é acompanhada pelo Qt 6.11 e KDE Frameworks 6.25, oferecendo uma base mais moderna para aplicações e ambientes gráficos.

Outras atualizações incluem:

Componente	Versão
KDE Plasma	6.6
KDE Frameworks	6.25
Qt	6.11
GNOME	48
LXQt	2.4
Xfce	4.20
LibreOffice	26.2
GIMP	3.2

O GNOME permanece na série 48, recebendo atualizações de correção e estabilidade.

A estratégia permite equilibrar modernização e confiabilidade, características tradicionalmente associadas ao openSUSE Leap.

Kernel Linux 6.12 e ferramentas atualizadas

O openSUSE Leap 16.1 mantém uma base de sistema operacional conservadora, priorizando estabilidade e suporte prolongado, sem deixar de atualizar ferramentas importantes.

Entre os principais componentes estão:

Tecnologia	Versão
Kernel Linux	6.12
systemd	257
glibc	2.40
Python padrão	3.13
Python adicional	3.14
LLVM	21
PHP	8.5.12
MariaDB	12.3
PostgreSQL	18
QEMU	11.0
libvirt	12.4
Podman	5.8

A presença de versões atualizadas do QEMU, libvirt e Podman fortalece a utilização do Leap como plataforma de virtualização e execução de contêineres.

Para desenvolvedores, Python 3.14 e LLVM 21 ampliam as possibilidades de utilização de ferramentas modernas, sem abandonar a base estável da distribuição.

Segurança: SELinux e requisitos de hardware

O openSUSE Leap 16.1 mantém o SELinux como módulo de segurança padrão, seguindo a estratégia estabelecida na série Leap 16.

O SELinux oferece mecanismos de controle de acesso obrigatório (MAC), permitindo políticas que restringem as operações realizadas por processos e serviços.

Essa arquitetura é especialmente relevante para servidores, ambientes multiusuário e infraestruturas com requisitos rigorosos de segurança.

Em relação ao hardware, a distribuição mantém o requisito mínimo de processadores compatíveis com x86-64-v2 na arquitetura x86_64.

O suporte à execução de aplicações de 32 bits continua desabilitado por padrão, mas pode ser habilitado quando necessário, inclusive para determinados jogos e aplicações legadas.

Para computadores antigos incompatíveis com x86-64-v2, o projeto recomenda avaliar alternativas como openSUSE Tumbleweed ou Slowroll, conforme a compatibilidade do equipamento.

Novidade para administradores: openSUSE Version Diff

O projeto também disponibilizou uma nova ferramenta chamada openSUSE Version Diff, baseada no projeto osdiff.

Seu objetivo é facilitar a comparação das versões dos pacotes entre diferentes lançamentos da distribuição.

A ferramenta permite comparar o openSUSE Leap 16.1 com o Leap 16.0, Tumbleweed e versões disponibilizadas pelos projetos originais.

Os resultados podem ser filtrados e exportados em formatos JSON e CSV.

Essa funcionalidade é especialmente interessante para administradores, desenvolvedores e mantenedores que precisam acompanhar mudanças de dependências, versões de bibliotecas e compatibilidade de software.

Ciclo de vida até a próxima década

O openSUSE Leap 16 mantém sua estratégia de lançamentos menores anuais.

O planejamento prevê a continuidade da série até o openSUSE Leap 16.6, em 2031, oferecendo um horizonte de longo prazo para usuários e organizações.

A documentação oficial estabelece uma janela de aproximadamente 24 meses de manutenção comunitária para cada versão menor da série Leap 16.

Esse planejamento permite que empresas e usuários organizem atualizações e migrações de maneira mais previsível.

Usuários do openSUSE Leap 16.0 podem realizar a atualização para o 16.1 seguindo a documentação oficial.

Já os usuários do Leap Micro 6.2 podem utilizar a ferramenta openSUSE Migration Tool para migrar ao novo modo imutável, embora esse caminho ainda seja considerado experimental e exija cuidados adicionais, incluindo backups completos.

Conclusão: uma evolução importante para o ecossistema openSUSE

O lançamento do openSUSE Leap 16.1 representa mais do que a chegada de novas versões de pacotes.

A decisão de integrar o Leap Micro ao Leap, oferecendo instalações tradicionais e imutáveis em uma única distribuição, demonstra uma evolução importante na arquitetura e na estratégia de manutenção do projeto.

Ao combinar uma base estável, integração com o SUSE Linux Enterprise, ferramentas modernas e suporte a diferentes modelos de implantação, o openSUSE fortalece sua posição como uma plataforma Linux versátil para desktops, servidores, virtualização e computação de borda.

Como participante da comunidade openSUSE e entusiasta de tecnologias abertas, considero essa evolução especialmente relevante para o futuro da infraestrutura Linux, principalmente em um cenário no qual inteligência artificial, segurança, automação e processamento distribuído estão cada vez mais presentes.

O openSUSE Leap 16.1 mostra que estabilidade e inovação não precisam seguir caminhos separados.

Downloads e referências

• Download oficial: https://get.opensuse.org/leap/
• Notas de lançamento: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/16.1/html/release-notes-leap-161/
• Atualização de sistema: https://en.opensuse.org/SDB:System_upgrade
• Instalador Agama: https://agama-project.github.io/
• Ferramenta Version Diff: https://github.com/openSUSE/osdiff
• Migração do Leap Micro: https://github.com/openSUSE/opensuse-migration-tool
• Projeto openSUSE: https://www.opensuse.org/

Viva o software livre! Viva a comunidade openSUSE!

A técnica Swift Bonsai 2 Katana + MTP, de Ayshinko, integra o Swift Bonsai 2 e MTP em um GGUF de aproximadamente 6,40 GB. A proposta combina compressão, eficiência de raciocínio e geração especulativa. Para entender sua proposta, vale acompanhar a origem de cada componente e distinguir três objetivos: comprimir os pesos, tornar o raciocínio mais econômico e acelerar a geração. [1]

A origem: uma variante do Qwen3.8-27B

O Ternary Bonsai 2, da PrismML, deriva do Qwen3.8-27B. A UkisAI desenvolveu o Swift Bonsai 2 sobre essa base ternária. Essa linhagem permite descrevê-lo como um derivado do Qwen3.8-27B. [2][3]

Componente	Contribuição	Responsável
Qwen3.8-27B	Modelo de origem	Equipe Qwen
Ternary Bonsai 2 27B	Compressão ternária	PrismML
Swift Bonsai 2	Ajustes para eficiência do raciocínio	UkisAI
KATANA + MTP	Integração do Swift com uma cabeça MTP	Ayshinko, utilizando pesos MTP de ProCreations

O Qwen3.8-27B é um modelo denso, multimodal, com 64 camadas. Sua arquitetura combina blocos de atenção linear Gated DeltaNet e Gated Attention. A documentação oficial informa contexto nativo de 262.144 tokens. Essas características descrevem o modelo de origem; a execução de cada derivado depende dos arquivos e do suporte oferecido pelo motor de inferência. [8]

Como a compressão ternária reduz o tamanho?

A representação ternária emprega pesos com três valores: −1, 0 e +1, acompanhados de fatores de escala. A PrismML informa escalas FP16 por grupo e aproximadamente 1,76 bit efetivo por peso no Bonsai 2, com tamanho próximo de 5,9 GB. [2]
Isso ajuda a explicar como um modelo da classe de 27 bilhões de parâmetros pode ocupar poucos gigabytes. Como referência aritmética, 27 bilhões de parâmetros armazenados em 16 bits corresponderiam a aproximadamente 54 GB, antes de considerar outros componentes e
particularidades do arquivo.

Segundo a avaliação publicada pela PrismML, o Bonsai 2 preservou 98,2% da pontuação agregada do modelo de precisão completa em sua bateria de benchmarks. Esse percentual resume os testes apresentados pela empresa; cada tarefa continua sujeita às perdas e variações observadas individualmente. [2]

A precisão efetiva deve ser considerada junto das escalas e demais informações necessárias à representação. Por isso, rótulos comerciais como “1-bit” precisam ser interpretados com a especificação técnica do formato.

O que o Swift modifica no raciocínio?

A UkisAI relata que identificou tokens marcadores associados a raciocínios excessivamente prolongados e realizou ajuste fino penalizando seu uso durante o raciocínio. A correção Swift foi incorporada aos pesos dos arquivos distribuídos. [3] O objetivo é diminuir etapas redundantes antes da resposta. A avaliação publicada, entretanto, mostra que o efeito varia conforme o teste:

Avaliação divulgada pela UkisAI	Resultado sobre o uso de tokens
GPQA-Diamond, avaliação histórica	Redução de 19,0% na média e 39,8% na mediana dos tokens de raciocínio
C-Eval, avaliação histórica	Redução de 18,4% na média
AIME 2025, arquivo PQ2_0 atual	Aumento de 4,3% na média dos tokens da resposta completa

Esses resultados utilizam protocolos e versões diferentes. GPQA e C-Eval correspondem à correção histórica em tempo de execução; AIME foi atualizado com os arquivos PQ2_0. A própria UkisAI esclarece que a variação na quantidade de tokens não mede diretamente latência ou custo. Portanto, “39,8% menos tokens” precisa acompanhar a identificação da métrica e do teste. [4]

A equipe também classifica o Swift como uma publicação experimental e relata comportamento irregular em seguimento de instruções, ferramentas e tarefas abertas de programação e agentes. Os benchmarks ajudam a investigar o modelo, mas a aplicação pretendida ainda exige avaliação própria. [3]

O que significa MTP?

MTP significa Multi-Token Prediction, ou predição de múltiplos tokens. A pesquisa de Gloeckle e colaboradores descreve o treinamento de modelos para prever vários tokens futuros, utilizando cabeças de saída sobre um corpo compartilhado. Esse trabalho oferece uma referência para compreender a técnica; seus resultados experimentais pertencem aos modelos estudados no artigo. [5]

Na decodificação especulativa, um mecanismo de rascunho propõe continuações e o modelo principal verifica as propostas. Quando vários tokens são aceitos, a geração pode avançar com menos etapas sequenciais custosas. O trabalho de Leviathan e colaboradores formaliza um algoritmo capaz de preservar a distribuição de saída do modelo principal. A equivalência depende de uma implementação correta doprocedimento de verificação e amostragem. [6]

O projeto ProCreations documenta uma cabeça MTP para o Bonsai 2, disponibilizada em BF16 e em Q8_0 inteiro, com verificação dos tokens especulativos pelo modelo principal. A taxa de aceitação é a proporção entre tokens propostos e aceitos, uma medida útil para analisar o funcionamento da aceleração. [9]

Minha leitura técnica é que Swift e MTP atuam em pontos complementares: o Swift procura reduzir trabalho redundante no raciocínio; o MTP procura executar a geração de forma mais eficiente. O ganho combinado precisa ser medido com a mesma tarefa, configuração e versão do motor.

Como interpretar o arquivo KATANA ?

NOME-DO-ARQUIVO-PTQ1_0-MTP-Q8_0.gguf

PTQ1_0 descreve o corpo ternário; Q8_0, MTP de uma camada adicional. O arquivo combina essas precisões. [1]. A documentação oficial do Bonsai-demo distingue os formatos: versões recentes do llama.cpp principal suportam o formato Q2_0 com a integração necessária, enquanto PTQ1_0 e PQ2_0 continuam exigindo o fork da PrismML. A compatibilidade depende do formato dos tensores e da versão do motor. [7]

O tamanho do download também precisa ser separado da memória utilizada durante a inferência. A documentação do Swift informa que o consumo inclui pesos e caches de contexto e estado. Dimensionar um servidor exige considerar esses componentes além do arquivo do modelo. [3] Para imagens, o KATANA exige mmproj separado; a execução visual não foi validada de ponta a ponta nessa publicação. [1]

O que as evidências permitem afirmar?

Os benchmarks e as estimativas de memória da página do KATANA são do Bonsai 2 MTP anterior; medições específicas desse pacote ainda são necessárias. [1]

Isso estabelece uma distinção útil para qualquer avaliação: preservação de qualidade do Bonsai, economia de tokens do Swift e aceleração com MTP são resultados de experimentos diferentes. Um teste do pacote completo deve registrar hardware, revisão dos arquivos, motor, contexto, amostragem, quantidade de tokens e MTP ligado ou desligado.

Para IA local, considero essa combinação uma direção interessante de pesquisa: aproveitar modelos maiores em máquinas com menos memória e reduzir o tempo necessário para concluir tarefas. Seu valor prático será demonstrado por respostas corretas, estabilidade e desempenho medidos na aplicação em que será utilizado.

Fontes e evidências

• Swift Bonsai 2 27B — KATANA MTP GGUF, por Ayshinko : Seções Feature Highlights, Benchmarks, Model Architecture e Known Limitations. Evidência da natureza do projeto: “independent community integration”.
• PrismML: Introducing Bonsai 2 27B : Origem Qwen3.8, representação ternária, tamanho e avaliação agregada. Evidência: “1.76 effective bits per weight”.
• UkisAI: Swift Bonsai 2 GGUF : Mmétodo de ajuste, arquivos, memória e limitações. Evidência: “This is an experimental research release.”
• UkisAI: Swift Bonsai 2 : Avaliação e metodologia — médias, medianas e distinção entre avaliações históricas e arquivos atuais. Evidência: “Token changes are not direct measurements of latency or cost.”
• Gloeckle et al.: Better & Faster Large Language Models via Multi-token Prediction : Referência científica sobre treinamento com predição de múltiplos tokens.
• Leviathan et al.: Fast Inference from Transformers via Speculative Decoding : Referência científica sobre geração especulativa e preservação da distribuição.
• PrismML-Eng/Bonsai-demo Upstream support : Suporte dos formatos Q2_0, PQ2_0 e PTQ1_0.
• Qwen/Qwen3.8-27B : Model Overview , arquitetura, número de camadas, multimodalidade e contexto do modelo de origem.
• ProCreations: Ternary Bonsai 2 27B MTP : Pesos da cabeça MTP, representação Q8_0 e definição de taxa de aceitação.

Arquitetura vantagens e limitações diante de llama cpp e vLLM

Pesquisa em 22 de outubro de 2026

O vllm.cpp procura reunir a distribuição de um motor nativo com mecanismos de atendimento concorrente inspirados no vLLM. Seu benefício mais claro é executar inferência sem um ambiente Python ou PyTorch dentro do motor. O projeto oferece recursos relevantes de escalonamento e cache, este texto é baseado no github oficial.

O que é o projeto e quem o mantém

Apresentado pela equipe do LocalAI e associado a Ettore Di Giacinto, o vllm.cpp é um motor de inferência desenvolvido em C++20. Ele carrega pesos já treinados e executa os cálculos necessários para produzir respostas. Pode funcionar como biblioteca incorporada a outra aplicação, ferramenta de terminal ou servidor HTTP. O repositório atual está em localai-org/vllm.cpp; endereços antigos sob mudler/vllm.cpp redirecionam para ele. [1]

O projeto é independente e não recebe endosso do vLLM oficial. A licença do código é Apache 2.0; os modelos mantêm suas próprias licenças. Seu objetivo inclui reproduzir comportamentos do vLLM, mas isso não equivale a compatibilidade completa com todas as suas versões, modelos, extensões ou configurações. [1, 4]

Como a arquitetura atende várias requisições

Em uma conversa com um modelo há duas etapas importantes. No prefill, o motor processa o texto de entrada. No decode, produz a continuação, normalmente um token por etapa. O escalonador decide quais requisições entram em cada rodada e como compartilhar a capacidade disponível. Separar essas etapas ajuda a entender por que um programa pode responder rapidamente a uma pessoa e ainda se comportar mal com muitas pessoas simultâneas.

O vllm.cpp implementa continuous batching, prefill em partes, preempção e reutilização de prefixos. Com continuous batching, novas requisições podem entrar à medida que outras terminam, sem esperar o lote inteiro acabar. Por exemplo, uma resposta curta pode liberar espaço para uma nova conversa enquanto outra resposta longa continua. O benefício depende da carga e dos kernels que realmente executam o modelo. [4]

O KV cache paginado armazena os estados de atenção em blocos administrados pelo motor. A técnica reduz desperdícios de alocação e permite compartilhar blocos quando há prefixos compatíveis. Ela atua sobre a memória usada pelo contexto; não comprime automaticamente os pesos do modelo. O trabalho original sobre PagedAttention explica essa relação entre fragmentação, compartilhamento e capacidade de agrupar requisições. [5]

O projeto também expõe políticas inspiradas no SGLang. A opção chamada RadixAttention é um alias para o cache automático de prefixos por hash do próprio motor; a documentação esclarece que não existe um caminho separado com uma árvore radix. A política LPM prioriza requisições com o maior prefixo já disponível no cache e depende desse cache estar habilitado. Essa escolha pode evitar trabalho repetido em aplicações com um prompt de sistema compartilhado. [6]

Biblioteca formatos e compatibilidade

A interface C pública, em include/vllm.h, permite vinculação estática ou dinâmica e integração por FFI. Na consulta realizada, a ABI estava na versão 30, consultável por vllm_abi_version(). Isso facilita incorporar o motor a programas escritos em C, C++, Go ou Rust. A ABI tem regras explícitas de evolução; internamente, os comandos e o servidor continuam mudando rapidamente. [2]

O servidor oferece /v1/chat/completions, /v1/completions, streaming, /metrics e tokenização. Endpoints para embeddings e áudio dependem da arquitetura e dos callbacks carregados. A API compatível com OpenAI facilita reutilizar clientes, mas seus recursos precisam ser confirmados. Até /health indica apenas que o processo está vivo, sem comprovar uma primeira geração concluída. [7]

Os formatos centrais são Safetensors e GGUF, com caminhos para NVFP4, FP8 e famílias GGUF. A compatibilidade depende da arquitetura, do layout dos tensores, da quantização e do backend. Aceitar um formato em uma família não garante que qualquer checkpoint com esse rótulo execute em outra. A documentação, por exemplo, ainda recusa GGUF TQ1_0 e TQ2_0, apesar da existência de kernels ternários. [8]

A decodificação especulativa inclui MTP, DFlash e caminhos com n-gramas, com diferentes níveis de validação. O documento também distingue métodos aceitos no JSON de métodos que realmente executam: draft_model tem configuração reconhecida, mas a carga é recusada por faltar o caminho de execução. Ganhos dependem do modelo, da taxa de aceitação e da carga; a existência de uma opção não demonstra aceleração em qualquer cenário. [9]

Hardware e distribuição

O motor textual usa seu próprio runtime de tensores. A compilação utiliza CMake e um compilador C++20; o servidor usa cpp-httplib. Há backends CPU, CUDA, Metal e Vulkan, com cobertura que varia por operação e modelo. No caminho CUDA, alguns kernels Triton já são distribuídos como código previamente compilado: Python e Triton são necessários para regenerá-los, não para executar esses binários. Os drivers e as dependências do backend continuam necessários. [10]

Ambiente	Situação documentada e consequência
CPU x86 e Arm	Há caminhos nativos e seleção de instruções. Velocidade deve ser medida no processador e no modelo escolhidos.
NVIDIA CUDA	A referência principal de medição é o GB10. Compilar para outra arquitetura CUDA não comprova o mesmo desempenho.
Apple Metal e Vulkan	Há implementações, mas a cobertura e a validação variam entre operações e modelos.
AMD ROCm	Há execuções nativas em caminhos específicos; permanecem lacunas de correção e de validação entre dispositivos.
Intel XPU e NPU	Não há base documental para prometer aceleração Intel NPU pronta. A matriz ainda indica lacunas nos backends XPU.

Fontes da matriz: guias de compilação e ROCm e matriz de funcionalidades. Suporte por Vulkan a uma GPU não implica suporte à NPU do mesmo fabricante. [4, 10, 11]

A release publicada mais recente encontrada foi a v0.0.2, de 11 de agosto de 2026. Seus arquivos para Linux e macOS possuem classificações distintas, incluindo stable e preview. Recursos descritos na branch principal em outubro podem não estar nesse pacote de agosto. Os arquivos também têm exigências de ABI do sistema e arquitetura do dispositivo; um executável pequeno não é automaticamente portátil para qualquer distribuição Linux ou GPU. [12, 13]

O que os números publicados demonstram

Os resultados abaixo foram publicados pelos mantenedores e constituem evidência documental, sem execução de novos benchmarks nesta análise. A principal ressalva está no próprio protocolo: várias comparações foram feitas contra uma referência anterior do vLLM e aguardam repetição após a mudança da referência em setembro. As séries identificadas como vLLM 0.25.0 são marcadas como superadas. Portanto, resultados históricos não comprovam paridade com a versão atual. [3]

O anúncio de aproximadamente 140 vezes menos para instalar compara um binário de 66 MiB com uma instalação de 9,1 GiB, medidos no ambiente usado pelo projeto. A ordem de grandeza é relevante para distribuição, mas não representa uma redução de 140 vezes na RAM, na VRAM ou na memória necessária aos pesos. Contêineres, modelos e drivers também não cabem automaticamente nesses 66 MiB. [1, 13]

Métrica publicada	vllm.cpp	vLLM	Como interpretar
Pico de PSS	24,88 GiB	28,18 GiB	Aproximadamente 11,7% menos no ensaio.
Pico de RSS	24,88 GiB	28,56 GiB	Outra medida de memória residente; não somar à PSS.
Queda de MemAvailable	68,35 GiB	80,66 GiB	Variação da memória disponível do sistema naquele ensaio.

A tabela de memória refere-se ao Qwen3.6-27B NVFP4 no GB10, durante a janela de atendimento. O GB10 usa memória unificada: números de memória do processo e do dispositivo não devem ser somados como se fossem RAM e VRAM fisicamente independentes. Os valores demonstram uma economia naquele teste, sem estabelecer uma porcentagem universal. [3, 14]

O relatório detalhado de atendimento também preserva um contraexemplo: para outro checkpoint/caminho do Qwen3.6-27B, registra pico de RSS de 21,10 GiB no vllm.cpp e 13,09 GiB no vLLM. São medições históricas de configurações distintas da tabela anterior. Elas mostram por que a retirada do Python, isoladamente, não garante menor uso de memória em todos os modelos. [15]

Na série histórica do Qwen3.6-27B NVFP4 da Unsloth, o projeto publicou 86,05 contra 82,32 tokens totais por segundo com uma requisição, e tratou as demais concorrências como empates. Esses tokens totais incluem entrada e saída; não são 86 tokens gerados por segundo. O relatório específico também contém resultados abaixo do vLLM para outros checkpoints e cargas. Como as referências mudaram, a leitura correta é que houve cenários competitivos, sem evidência de vitória geral ou atual. [3, 15]

A comparação com llama.cpp exige ainda mais cautela. O relatório de CPU informa que um denominador usado era um fork local com alterações de desempenho e pede nova medição contra o upstream fixado. Há também séries antigas em que vllm.cpp perde. A página diz expressamente que não mediu atendimento concorrente contra o servidor llama.cpp naquele ensaio. Assim, não há fundamento para transformar a antiga alegação de ganho no prefill em superioridade geral. [16]

Um levantamento exploratório em AMD Strix Halo torna a limitação mais concreta: com Qwen3.8-27B Q4_K_M, publicou 12,219 tok/s de decode para llama.cpp, 11,056 tok/s derivados para vLLM e 5,397 tok/s derivados para vllm.cpp. O próprio estudo não certifica a comparação: a verificação de tokens não passou, houve sessões distintas e parte das taxas foi inferida de tempos com dois comprimentos de saída. Ele documenta uma observação localizada desfavorável ao vllm.cpp, não um ranking reproduzido para todo hardware. [17]

Vantagens e desvantagens diante do vLLM

A principal vantagem é operacional. Distribuir e incorporar uma biblioteca nativa pode simplificar imagens de sistema, instaladores e aplicações que já são escritas em C ou C++. Também reduz a necessidade de manter um ambiente Python/PyTorch dentro do motor. Essa simplificação tem valor mesmo quando a taxa de geração empata. O ganho deve ser avaliado pelo pacote completo utilizado, inclusive bibliotecas e serviços externos. [2, 10, 13]

O carregamento direto de Safetensors e GGUF é outro atrativo para quem trabalha com os dois ecossistemas. É preciso, porém, corrigir uma comparação frequente: o vLLM também aceita GGUF. Sua documentação atual encaminha esse suporte ao vllm-gguf-plugin e o classifica como experimental e pouco otimizado. A diferença está na integração e na cobertura dos caminhos de execução, não na exclusividade do formato. [8, 18]

A desvantagem mais forte aparece na escala. O vllm.cpp descreve sua situação como single-GPU; o paralelismo de tensores possui trabalho e testes parciais, sem validação completa em duas GPUs na matriz consultada. Paralelismo de pipeline, de especialistas e execução multinó continuam incompletos. O vLLM documenta estratégias de tensor e pipeline parallelism para uma ou várias máquinas, o que o torna a escolha mais sustentada pela documentação para esses requisitos. [4, 19]

O vLLM também possui um ecossistema de implantação e uma arquitetura com servidor de API, núcleo do motor e workers. Essa organização traz componentes a operar, mas serve a necessidades de concorrência e distribuição. Descrever o vLLM apenas como Python lento seria incorreto: os cálculos pesados usam kernels especializados. A troca de linguagem da coordenação não determina, sozinha, a velocidade da GPU. O vLLM atual também documenta CPU, NVIDIA, AMD, Intel XPU e Apple Silicon, com diferentes mecanismos de suporte. [20, 21]

Vantagens e desvantagens diante do llama cpp

O atrativo do vllm.cpp é reunir Safetensors e uma arquitetura de atendimento inspirada no vLLM dentro de uma biblioteca nativa. Um serviço com muitas requisições e prefixos repetidos pode se beneficiar dessas escolhas, se o modelo e o backend necessários estiverem bem implementados. Isso é uma hipótese técnica para testar, e não uma vantagem de throughput já demonstrada contra llama.cpp em todas as situações. [2, 6, 16]

O llama.cpp já oferece execução nativa, quantizações, ampla variedade de backends e inferência híbrida CPU/GPU. Seu servidor documenta múltiplos usuários, continuous batching, cache, ferramentas, saídas estruturadas e decodificação especulativa. Portanto, a comparação não deve partir da ideia de que ele atende apenas uma pessoa ou carece de batching. O interesse está em comparar a eficiência e o comportamento dessas implementações na carga real. [22, 23]

Para máquinas pessoais, GGUF e combinações de CPU/GPU, a cobertura publicada do llama.cpp costuma oferecer um ponto de partida mais abrangente. O vllm.cpp precisa demonstrar um benefício concreto que compense a migração e as lacunas do caminho escolhido. Além disso, chamar a biblioteca nativa de diferencial exclusivo seria incorreto: ambos têm essa característica. As licenças do código são distintas, Apache 2.0 no vllm.cpp e MIT no llama.cpp. [1, 22, 24]

Limitações que influenciam a adoção

Algumas limitações ficam mais claras nos documentos específicos do que na apresentação do repositório. Elas devem orientar a escolha dos recursos:

Jump-forward. A opção existe e é validada, mas não tem chamador na execução de produção. Habilitá-la não acelera requisições no estado documentado. [6]

KV externo. O cliente C++ de LMCache possui caminho documentado de execução. O OffloadingConnector local para CPU/disco ainda não possui a parte que transfere os dados para as páginas do motor e, por isso, sua utilização é recusada. O servidor externo LMCache pode continuar exigindo seu próprio ambiente Python. [25]

Multimodalidade. No HTTP, o guia distingue Qwen3-VL e dots3-note, com testes de integração em CPU usando pesos sintéticos. Imagens exigem RGB bruto no caminho descrito; PNG, JPEG e entrada de vídeo são recusados. Registrar uma arquitetura multimodal não demonstra que todas as formas de entrada, interfaces ou aceleradores foram validados. [26]

Integrações incompletas. A matriz registra LoRA ainda sem uso completo pelo servidor. Recursos podem ter código, configuração ou testes locais sem uma execução completa acessível ao usuário. A evolução da branch principal também exige fixar uma versão ou commit e validar novamente após mudanças. [1, 4]

Como escolher e testar

Necessidade	Ponto de partida sugerido
GGUF local e combinação de CPU e GPU	llama.cpp, pela cobertura publicada; confirmar o modelo e o backend.
Múltiplas GPUs ou máquinas	vLLM, pelos caminhos documentados de paralelismo e implantação.
Biblioteca C++ com atendimento no estilo vLLM	vllm.cpp como candidato a avaliação, fixando o commit e os recursos necessários.
Maior desempenho ou menor memória	Medir os três na mesma máquina e na mesma carga; o nome do projeto não decide.

Essas sugestões são uma interpretação técnica da cobertura e dos limites descritos nas fontes, não resultados de um novo ensaio. Um teste útil mantém o mesmo checkpoint e quantização, template de conversa, modo de raciocínio, número de tokens de entrada e saída, dtype do KV cache e regras de parada. Deve testar separadamente cache frio, cache aquecido e concorrências representativas.

As métricas que permitem decidir são tempo até o primeiro token, tempo entre tokens, tokens de saída por segundo, latência completa, percentis p95/p99, falhas e consumo de memória do conjunto de processos. PSS, RSS, memória do dispositivo e memória disponível do sistema medem coisas diferentes. A utilização de CPU também precisa ser medida: a ausência de Python não comprova, por si só, menos trabalho de CPU, menor energia ou melhor throughput.

O vllm.cpp merece avaliação quando a distribuição nativa e a incorporação ao produto são prioridades. Uma adoção pode se justificar por manutenção e integração, mesmo com desempenho semelhante. Para substituir um serviço existente, o critério deve ser um resultado reproduzido no modelo, hardware e nível de concorrência da aplicação, com os recursos necessários funcionando de ponta a ponta.

Fontes primárias

Consulta em 22 de outubro de 2026. Os documentos do vllm.cpp abaixo apontam para o retrato consultado do repositório, commit 845b3c59d43d1da2583efa738b9ec9f715ba2312. As datas e referências dos benchmarks são as dos respectivos ensaios, que podem ser anteriores a esse commit. As páginas dos outros projetos refletem a documentação pública consultada na data da pesquisa.

[1] vllm.cpp — apresentação autoria licença e aviso de desenvolvimento
[2] vllm.cpp — interface C e versão da ABI
[3] vllm.cpp — protocolo referências superadas e medições pendentes
[4] vllm.cpp — funcionalidades cobertura e limitações
[5] Kwon e colaboradores — PagedAttention e gestão do KV cache
[6] vllm.cpp — políticas inspiradas no SGLang e jump-forward
[7] vllm.cpp — servidor rotas e comportamento das APIs
[8] vllm.cpp — uso formatos quantizados e tamanho do contexto
[9] vllm.cpp — métodos e limites da decodificação especulativa
[10] vllm.cpp — compilação dependências e backends
[11] vllm.cpp — guia e limites do backend ROCm
[12] vllm.cpp — releases e arquivos publicados
[13] vllm.cpp — distribuição binária e dependências externas
[14] vllm.cpp — medições de memória
[15] vllm.cpp — comparações de atendimento com vLLM
[16] vllm.cpp — comparação de CPU com llama.cpp e denominadores superados
[17] vllm.cpp — levantamento exploratório em AMD Strix Halo
[18] vLLM — documentação atual de GGUF e plugin
[19] vLLM — paralelismo e escala
[20] vLLM — arquitetura e processos
[21] vLLM — instalação e plataformas de hardware
[22] llama.cpp — apresentação e backends
[23] llama.cpp — recursos e opções do servidor
[24] llama.cpp — licença MIT
[25] vllm.cpp — conectores de KV e limitações
[26] vllm.cpp — entradas multimodais no servidor HTTP

Com modelos de até 1 trilhão de parâmetros, contexto de 1 milhão de tokens, multimodalidade nativa e treinamento por reforço em larga escala, a Xiaomi mostra que sua ambição em inteligência artificial vai muito além de celulares, carros e dispositivos inteligentes.

Quando pensamos na Xiaomi, a primeira associação normalmente é com smartphones, dispositivos IoT ou, mais recentemente, veículos elétricos. Mas a empresa chinesa vem construindo silenciosamente uma operação bastante mais ambiciosa na área de inteligência artificial.

Em setembro de 2026, essa estratégia ganhou um novo capítulo com o lançamento da família Xiaomi MiMo V2.6, composta principalmente pelos modelos MiMo-V2.6-Pro e MiMo-V2.6-Flash, além da variante de inferência acelerada MiMo-V2.6-Pro-UltraSpeed.

A novidade não chama atenção apenas pelo tamanho dos modelos. A Xiaomi combinou arquitetura Mixture of Experts, contexto extremamente longo, entrada multimodal e treinamento por Reinforcement Learning em larga escala. E, talvez mais importante para a comunidade, publicou pesos, relatório técnico e parte importante da infraestrutura utilizada nos experimentos.

Um modelo de mais de 1 trilhão de parâmetros

O principal modelo da família é o MiMo-V2.6-Pro. Ele utiliza uma arquitetura Sparse Mixture of Experts : MoE, com aproximadamente 1,02 trilhão de parâmetros totais, mas apenas cerca de 42 bilhões de parâmetros ativados durante o processamento de cada token.

Essa diferença é importante.

Em um Transformer tradicional, praticamente todos os parâmetros participam de cada inferência. Em um modelo MoE, diferentes especialistas são selecionados dependendo do conteúdo processado. Isso permite aumentar consideravelmente a capacidade total do modelo sem aumentar proporcionalmente o custo computacional de cada token.

O MiMo-V2.6-Pro suporta ainda uma janela de contexto de 1 milhão de tokens e recebe nativamente texto, imagens, vídeo e áudio. Seu encoder visual possui 681 milhões de parâmetros, enquanto a arquitetura de áudio combina um AudioTokenizer de 308 milhões de parâmetros com outro encoder de 127 milhões.

Há também o MiMo-V2.6-Flash, pensado para reduzir o custo de inferência. Ele possui aproximadamente 309 bilhões de parâmetros totais e 15 bilhões ativos, mantendo a mesma janela de contexto de 1 milhão de tokens e as mesmas quatro modalidades de entrada. Ou seja: Flash não significa exatamente um modelo pequeno. Ele continua sendo gigantesco, apenas utiliza uma arquitetura mais econômica.

Um milhão de tokens muda bastante o jogo

A janela de contexto de 1 milhão de tokens talvez seja uma das características mais interessantes para aplicações reais. Em vez de trabalhar somente com algumas páginas de informação, um agente pode manter grandes quantidades de código, documentação, histórico de execução, resultados de ferramentas e outros dados dentro da mesma sessão.

Para engenharia de software, por exemplo, isso permite que um agente analise repositórios muito maiores sem depender exclusivamente de mecanismos externos de RAG para recuperar pequenos trechos a cada interação.

Em aplicações empresariais, o mesmo conceito pode ser usado para trabalhar com documentação extensa, especificações técnicas, contratos, histórico de sistemas, logs ou grandes conjuntos de informações. Isso aproxima cada vez mais o LLM de uma espécie de motor de raciocínio para agentes, e não simplesmente de um chatbot.

A parte mais interessante talvez tenha sido o treinamento

O lançamento também chamou atenção pela forma como a Xiaomi realizou parte do treinamento de Reinforcement Learning. Segundo a empresa, aproximadamente seis dias do processo de RL foram apresentados publicamente, mostrando a evolução do treinamento. Pro e Flash completaram 30 etapas de RL cada, acumulando aproximadamente 750 mil trajetórias.

A Xiaomi informa custos aproximados de US$ 850 mil para o Flash e US$ 2,62 milhões para o Pro nessa etapa, com melhorias significativas nos resultados das tarefas utilizadas durante o treinamento. Esse experimento faz parte de uma estratégia que a empresa chama de busca por Recursive Self-Improvement, ou melhoria recursiva.

A ideia fundamental é interessante: em vez de depender exclusivamente de enormes quantidades de novos dados produzidos por humanos, o modelo executa tarefas, recebe feedback, compara diferentes estratégias e utiliza os resultados para aperfeiçoar o próprio comportamento.

Não significa que o modelo simplesmente “aprenda sozinho” indefinidamente. Existe toda uma infraestrutura envolvendo ambientes controlados, funções de recompensa, verificadores e mecanismos para evitar problemas como reward hacking.

Mas mostra claramente uma mudança na indústria: depois da corrida para aumentar os dados de pré-treinamento, estamos entrando na corrida para aumentar a quantidade e a qualidade da experiência computacional gerada durante o pós-treinamento.

Código, agentes, interfaces gráficas e até robótica

A Xiaomi está posicionando o MiMo V2.6 principalmente como um modelo voltado a tarefas agentivas. Isso inclui desenvolvimento de software, utilização de ferramentas, navegação por interfaces gráficas, automação de aplicações e resolução de tarefas longas envolvendo múltiplas etapas.

A empresa demonstrou, por exemplo, o modelo trabalhando com criação de ambientes 3D no Blender, geração de aplicações, construção de interfaces, criação de vídeos e até controle de um braço robótico Franka Panda utilizando feedback visual. Há também experimentos voltados para pesquisa científica. Em um deles, o MiMo-V2.6-Pro foi utilizado como auxiliar na pesquisa de materiais; em outro, participou da formalização matemática no Lean 4, resultando em milhares de linhas de código verificadas pelo próprio kernel do Lean.

Esses exemplos não significam que um LLM esteja substituindo pesquisadores ou engenheiros. O ponto mais interessante é outro: os modelos estão deixando de ser apenas sistemas que geram respostas para se tornar sistemas capazes de observar um ambiente, executar ações, verificar resultados e tentar novamente. Essa talvez seja a transformação mais importante ocorrendo atualmente no campo da IA generativa.

E os benchmarks?

O MiMo-V2.6-Pro alcançou 46 pontos no Artificial Analysis Intelligence Index, ficando, naquele momento, como o modelo de pesos abertos com maior resultado nessa avaliação. A medição independente também colocou o modelo à frente de outros modelos open-weight presentes no ranking. Esse resultado é relevante, mas precisa ser interpretado corretamente.

Não existe um único benchmark capaz de determinar qual é “o melhor modelo de inteligência artificial”. Desempenho varia bastante dependendo da tarefa, do framework agentivo, das ferramentas disponíveis, da quantidade de contexto, do método de avaliação e até da configuração de inferência.

A própria Xiaomi mostra benchmarks em que o MiMo lidera e outros em que modelos concorrentes permanecem superiores. Portanto, é mais preciso dizer que o MiMo-V2.6-Pro entrou no grupo dos modelos abertos de maior desempenho disponíveis atualmente, em vez de simplesmente declarar que ele é melhor em qualquer situação.

O preço também é parte da estratégia

Outra área onde a Xiaomi decidiu competir agressivamente é preço de API. Para usuários internacionais, a documentação oficial apresenta o MiMo-V2.6-Pro por US$ 0,435 por milhão de tokens de entrada sem cache e US$ 0,87 por milhão de tokens de saída.

No MiMo-V2.6-Flash, os valores caem para aproximadamente US$ 0,14 na entrada e US$ 0,28 na saída. A modalidade Batch API custa metade do preço da inferência em tempo real. A Xiaomi afirma que, considerando modelos com níveis semelhantes de desempenho, o custo do Pro pode chegar a ser dezenas de vezes menor que determinadas alternativas proprietárias. Essa comparação é uma afirmação da própria fabricante e depende naturalmente do modelo, benchmark e workload considerados.

Existe ainda o MiMo-V2.6-Pro-UltraSpeed, serviço que pretende entregar as capacidades do Pro com velocidade de geração até 20 vezes maior, destinado a aplicações nas quais latência é crítica.

Open source ou apenas open-weight?

Aqui existe outro detalhe interessante. Muitos modelos atualmente chamados de “open source” disponibilizam somente seus pesos. O restante do processo que levou até aqueles pesos continua fechado. No caso do MiMo V2.6, a Xiaomi foi consideravelmente além.

Os model cards estão publicados sob licença MIT, e a empresa disponibilizou os pesos do Pro e Flash, relatório técnico, um modelo destilado de 9 bilhões de parâmetros e recursos ligados ao treinamento por Reinforcement Learning.

Segundo a Xiaomi, foram disponibilizados mais de 7 mil ambientes de tarefas para RL, além de componentes para coleta de trajetórias, avaliação de recompensas, otimização das políticas e construção de agent harnesses.

Isso transforma o projeto em algo particularmente interessante para universidades, pesquisadores e empresas que estudam agentes inteligentes e treinamento por reforço.

Dá para executar localmente?

Tecnicamente, sim. O próprio repositório no Hugging Face já mostra utilização com Transformers, vLLM e SGLang, além de indicar a existência de quantizações para ecossistemas como llama.cpp, Ollama e LM Studio.

Mas precisamos colocar “local” em perspectiva. Estamos falando de um modelo Pro com 1,02 trilhão de parâmetros. Mesmo utilizando quantização agressiva, armazenar todos esses pesos exige uma quantidade enorme de memória. O fato de apenas 42 bilhões de parâmetros serem ativados em determinado token reduz principalmente o custo de computação; não significa automaticamente que seja necessário armazenar somente esses 42 bilhões.

Portanto, o Pro é muito mais adequado para servidores com grandes quantidades de GPU ou infraestrutura distribuída. O Flash, com 309 bilhões de parâmetros, é substancialmente menor, mas também continua muito além da categoria de modelos que normalmente colocamos em uma única GPU doméstica.

Para experimentação local, o MiMo-V2.6-Distill-Qwen-9B provavelmente será muito mais interessante, principalmente para pesquisadores interessados em estudar os métodos de Reinforcement Learning publicados junto com o projeto.

O que o MiMo V2.6 realmente representa

Talvez a parte mais importante desse lançamento não seja descobrir se o MiMo ganhou ou perdeu determinado benchmark. O que chama atenção é observar quem está construindo esses modelos. Até poucos anos atrás, a fronteira dos grandes modelos estava praticamente concentrada em empresas especializadas em inteligência artificial e alguns gigantes de nuvem.

Agora uma empresa conhecida mundialmente por fabricar celulares, televisores, eletrodomésticos, dispositivos IoT e veículos elétricos está apresentando um modelo de mais de um trilhão de parâmetros, multimodal, orientado a agentes e disponibilizando boa parte da tecnologia para a comunidade.

Isso também revela uma tendência maior. A próxima disputa talvez não seja simplesmente por quem possui o chatbot que responde melhor.

A verdadeira competição está migrando para modelos capazes de raciocinar por longos períodos, operar ferramentas, controlar computadores, programar, enxergar, ouvir, interagir com ambientes físicos e executar tarefas inteiras com pouca intervenção humana.

Nesse cenário, o MiMo V2.6 coloca a Xiaomi definitivamente entre as empresas que precisam ser acompanhadas de perto na evolução da inteligência artificial.

E talvez seja justamente essa a principal mensagem do lançamento: na atual corrida da IA, novos protagonistas continuam surgindo — e a próxima grande inovação pode não vir de onde estamos acostumados a procurar.

---

Executar modelos avançados de inteligência artificial localmente ainda exige, na maioria dos casos, computadores com grande quantidade de memória RAM ou placas gráficas caras. O Bonsai 2 27B, desenvolvido pela PrismML, propõe mudar essa realidade por meio de uma combinação de quantização ternária, transformações matemáticas e kernels de inferência especializados.

Baseado no Qwen3.8-27B, o modelo possui 27 bilhões de parâmetros e, em precisão FP16, ocuparia aproximadamente 54 GB. Entretanto, a versão ternária do Bonsai 2 reduz esse tamanho para cerca de 5,9 GB, mantendo, segundo a PrismML, 98,2% do desempenho agregado do modelo original.

Essa redução superior a nove vezes abre uma possibilidade importante: executar um modelo da classe de 27 bilhões de parâmetros em computadores pessoais, notebooks e dispositivos que jamais conseguiriam carregar sua versão em precisão completa.

O que é um modelo ternário?

Os modelos tradicionais armazenam seus pesos utilizando números com diferentes níveis de precisão, como FP32, FP16, BF16 ou INT8. Quanto maior a precisão, maior é o consumo de memória e a quantidade de dados movimentados durante a inferência.

No Bonsai 2, a maior parte dos pesos pode assumir somente três valores:

• -1
• 0
• +1

Por isso, ele é chamado de modelo ternário.

Em vez de utilizar 16 bits para representar cada peso, o Bonsai 2 trabalha com aproximadamente 1,76 bit efetivo por peso, combinando os valores ternários com fatores de escala em FP16 aplicados por grupos.

Na prática, isso reduz drasticamente o espaço necessário para armazenar o modelo e também diminui o volume de dados transferidos entre a memória e o processador ou GPU durante a geração dos tokens.

A compressão não é aplicada apenas em algumas camadas. Segundo a PrismML, a representação de baixa precisão é utilizada de ponta a ponta no modelo de linguagem. Apenas uma pequena parcela dos parâmetros, relacionada a componentes sensíveis como normalização e estados da atenção linear, permanece em maior precisão para preservar a estabilidade.

A importância da rotação de Hadamard

Simplesmente converter os pesos de um modelo para -1, 0 e +1 normalmente causaria uma perda significativa de qualidade. Alguns pesos carregam mais informação do que outros, e arredondá-los diretamente poderia destruir partes importantes do conhecimento do modelo.

Para reduzir esse problema, o Bonsai utiliza uma transformação conhecida como rotação de Hadamard.

Antes da quantização, essa operação redistribui matematicamente as informações entre os pesos. É como espalhar os valores mais extremos pela matriz, evitando que poucos parâmetros concentrem uma quantidade excessiva de informação.

A rotação é incorporada permanentemente aos pesos armazenados, sem aumentar o tamanho final do arquivo. Durante a inferência, uma transformação correspondente também precisa ser aplicada às ativações do modelo.

Esse detalhe explica uma das principais limitações atuais do Bonsai 2: ele não funciona corretamente no llama.cpp oficial. É necessário utilizar o fork disponibilizado pela PrismML, que contém os kernels ternários e as transformações exigidas pelo modelo. O mesmo acontece no ecossistema Apple, onde é necessária uma versão adaptada do MLX.

Sem essas modificações, o programa pode até carregar os pesos, mas produzirá resultados incorretos ou sem sentido.

Tamanho do modelo e consumo real de memória

O Bonsai 2 27B está disponível em diferentes formatos, cada um com características próprias:

Formato	Tamanho aproximado	Característica
GGUF PTQ1_0	5,95 GB	Empacotamento ternário mais denso
GGUF PQ2_0	7,21 GB	Utiliza posições de 2 bits, facilitando a descompactação
MLX 2-bit	7,67 GB	Versão destinada ao Apple Silicon
MLX com visão	8,60 GB	Inclui também o módulo visual

O tamanho do arquivo, entretanto, não representa todo o consumo de memória durante a execução. O runtime também precisa reservar espaço para as ativações, buffers e o cache KV utilizado para manter o contexto da conversa.

Em testes relatados pela MindStudio, o servidor do llama.cpp consumiu pouco mais de 12 GB de VRAM com sua configuração padrão de quatro slots paralelos. Ao limitar o servidor para uma única requisição simultânea com --parallel 1, o consumo caiu para menos de 8 GB.

Isso significa que o Bonsai 2 pode funcionar em uma GPU de 8 GB, dependendo do formato escolhido, do tamanho do contexto e da quantidade de requisições paralelas. Para uma utilização mais confortável, especialmente com contextos maiores, uma GPU com 12 GB ou mais continua sendo recomendável.

Contexto de até 262 mil tokens

Outro diferencial do Bonsai 2 é sua janela de contexto de aproximadamente 262 mil tokens. Isso permite trabalhar com grandes documentos, repositórios de código, históricos extensos e tarefas que dependem de muitas informações simultâneas.

Esse contexto seria extremamente caro se todas as camadas utilizassem atenção tradicional. O Qwen3.8 adota uma arquitetura híbrida, na qual aproximadamente 75% das camadas utilizam atenção linear e 25% utilizam atenção completa.

A atenção linear reduz o crescimento do custo computacional à medida que o contexto aumenta. A atenção tradicional permanece em uma parte das camadas para preservar a capacidade do modelo de relacionar informações distantes.

Mesmo assim, é importante lembrar que informar um contexto máximo de 262 mil tokens não significa que qualquer computador conseguirá utilizá-lo integralmente. Quanto maior o contexto efetivamente carregado, maior será o consumo de memória e o tempo necessário para processar o prompt.

Desempenho e eficiência energética

De acordo com os resultados publicados pela PrismML, o Bonsai 2 27B alcança até 143 tokens por segundo em uma NVIDIA GeForce RTX 5090 e aproximadamente 46,8 tokens por segundo em um Apple M5 Max.

Em uma RTX 4090, a empresa informa consumo de aproximadamente 0,714 mWh por token, tornando o modelo 40% mais eficiente energeticamente do que um modelo de 8 bilhões de parâmetros executado em precisão completa.

Os resultados variam conforme o hardware e o formato escolhido. O PTQ1_0 pode apresentar vantagem em GPUs limitadas pela largura de banda da memória, enquanto o PQ2_0 pode ser mais eficiente em equipamentos com maior capacidade computacional, pois seu formato simplifica a descompactação dos pesos.

Portanto, o arquivo menor nem sempre será automaticamente o mais rápido. O desempenho depende do equilíbrio entre largura de banda, capacidade de processamento, kernels disponíveis e custo da descompactação.

O modelo realmente preserva 98,2% da capacidade original?

Nos benchmarks apresentados pela PrismML, o Bonsai 2 atingiu uma pontuação agregada de 83,9, enquanto o Qwen3.8-27B em precisão completa alcançou 85,4. Os testes incluem raciocínio, matemática, programação, visão, seguimento de instruções e utilização de ferramentas.

Os números são impressionantes, mas precisam ser interpretados com cautela. O resultado de 98,2% foi obtido em avaliações realizadas e publicadas pela própria desenvolvedora.

Testes práticos relatados pela MindStudio apresentaram resultados mais variados. O modelo demonstrou bom desempenho em visão e escrita criativa, mas falhou ao localizar um erro de fuso horário propositalmente inserido em uma aplicação. Em outro teste, gerou uma interface visualmente satisfatória, porém com um botão que não funcionava, mesmo depois de diferentes tentativas de correção.

Esses resultados não significam que a tecnologia seja ruim. Eles demonstram que uma pontuação média próxima à versão original não garante comportamento idêntico em todas as tarefas. Pequenas perdas de precisão podem se tornar mais visíveis em fluxos com várias etapas, agentes autônomos, programação e uso de ferramentas.

Onde o Bonsai 2 pode ser utilizado?

A combinação de baixo consumo de memória, suporte multimodal e contexto extenso torna o modelo interessante para diferentes aplicações:

• assistentes de programação executados localmente;
• análise privada de documentos;
• interpretação de imagens e capturas de tela;
• sistemas RAG sem envio de dados para a nuvem;
• agentes capazes de utilizar ferramentas;
• automação de tarefas em estações de trabalho;
• processamento de informações corporativas sensíveis;
• arquiteturas híbridas entre IA local e serviços em nuvem.

Em uma arquitetura híbrida, tarefas frequentes ou sensíveis podem ser processadas localmente, enquanto operações mais complexas são encaminhadas seletivamente para modelos maiores na nuvem. Isso pode reduzir custos, latência, dependência de conexão e exposição de dados confidenciais.

Limitações atuais

Apesar das vantagens, o Bonsai 2 ainda possui alguns obstáculos:

• depende de forks específicos do llama.cpp ou do MLX;
• os kernels ternários ainda não fazem parte dos runtimes oficiais;
• o consumo real pode superar bastante o tamanho do arquivo;
• contextos muito extensos continuam exigindo memória e processamento;
• os resultados dos benchmarks do fabricante ainda precisam de maior validação independente;
• algumas tarefas podem apresentar perdas mais perceptíveis do que a média agregada sugere.

A dependência de um runtime personalizado é provavelmente a principal barreira para sua adoção imediata. Uma possível integração dos kernels ternários ao llama.cpp oficial tornaria a instalação mais simples e permitiria que o modelo fosse utilizado por um público muito maior.

Uma nova métrica para a inteligência artificial

O Bonsai 2 representa uma mudança importante na forma como avaliamos modelos de IA. Durante muito tempo, a evolução foi medida quase exclusivamente pela quantidade de parâmetros ou pela pontuação em benchmarks.

Com modelos ternários, uma nova métrica ganha relevância: a densidade de inteligência, ou seja, quanta capacidade útil pode ser entregue dentro de determinado orçamento de memória, processamento e energia.

Um modelo de 27 bilhões de parâmetros ocupando menos de 6 GB permite utilizar uma classe de inteligência antes restrita a servidores em equipamentos muito mais acessíveis. A tecnologia ainda precisa amadurecer, principalmente no suporte dos runtimes e na validação independente, mas demonstra que modelos maiores não precisam necessariamente exigir infraestruturas maiores.

Se a quantização ternária continuar evoluindo sem comprometer significativamente a qualidade, ela poderá transformar não apenas a IA executada em computadores pessoais, mas também servidores corporativos, datacenters e dispositivos de borda.

O Bonsai 2 27B não elimina a necessidade da nuvem, mas amplia consideravelmente aquilo que pode ser realizado localmente. E, em um cenário no qual privacidade, soberania dos dados, custo e eficiência energética estão se tornando fundamentais, essa talvez seja sua contribuição mais importante.

Referências

• PrismML — Introducing Bonsai 2 27B
• MindStudio — How to Run Bonsai 2 27B Locally
• github: https://github.com/PrismML-Eng/llama.cpp

Executar inteligência artificial localmente exige mais do que escolher um bom modelo. É preciso aproveitar o hardware disponível, administrar memória e reduzir o tempo de resposta. As novidades do OpenVINO 2026.4.0 avançam nessas frentes, com ampliação do suporte a modelos, novas técnicas de aceleração e melhorias para aplicações que utilizam CPUs, GPUs e NPUs Intel.

A atualização reúne recursos para linguagem, visão, reconhecimento de fala e geração de imagens. Para quem desenvolve soluções de IA local, embarcada ou corporativa, isso amplia as possibilidades de construir aplicações com diferentes modalidades dentro do mesmo ecossistema.

Mais modelos e possibilidades de aplicação

A relação de novos modelos suportados inclui Gemma-3n em CPU e uma lista abrangente para execução em CPU e GPU: Kokoro-82M, Qwen3-VL-4B com EAGLE-3, Qwen3-ASR, Muse Glimmer 30B, Qwen3.8 27B, Gemma 4 12B, Hy-MT2-1.8B, DeepSeek OCR-2 e Granite 4.0 H Micro.

Essa expansão aproxima diferentes etapas de uma aplicação: reconhecer fala, interpretar imagens e documentos, traduzir conteúdo, gerar respostas e sintetizar voz.

Nas NPUs, os destaques são FLUX.2-Klein 4B e Kokoro-82M, ampliando as opções para geração de imagens e síntese de fala nesse acelerador. O suporte anunciado deve ser considerado junto aos requisitos de cada modelo e plataforma: a presença de uma NPU, por si só, não garante que qualquer configuração consiga executar todas essas cargas.

Também chegam, como versões iniciais para CPU e GPU, Qwen-Image, Z-Image-Turbo, Granite 4.0 H Tiny, Fun-ASR-Nano, LFM2.5-8B-A1B, MiniCPM5-2B, RF-DETR, BGE Reranker-V2-M3 e BGE M3. São novas opções para experimentação, com validação necessária antes da adoção em produção.

Geração de texto acelerada com previsão de múltiplos tokens

Uma das novidades mais relevantes do OpenVINO GenAI é o suporte à decodificação especulativa com Multi-Token Prediction, ou MTP, para Gemma 4, Qwen3.5 e Qwen3.6 em CPUs e GPUs.

A ideia é antecipar múltiplos tokens e submetê-los à validação, aproveitando as previsões aceitas para acelerar a geração. Segundo as notas da versão, o objetivo é aumentar a vazão e reduzir a latência sem sacrificar a precisão.

O ganho efetivo depende do modelo, do hardware e da carga de trabalho. Por isso, vale medir tanto o tempo até o primeiro token quanto a velocidade de geração e o tempo total da resposta.

O release também apresenta, em prévia, aceleração DFlash para modelos Qwen em GPUs e suporte a tokens visuais voltado à redução de latência em pipelines GenAI nos processadores Intel Core Ultra Series 3.

Mais desempenho em aplicações multimodais

O EAGLE-3 passa a contar com Tree Drafting, utilizando Top-K. Em vez de explorar uma única sequência de candidatos, como no Chain Drafting com Top-1, essa abordagem permite considerar alternativas em uma estrutura de árvore.

A proposta é aumentar a vazão em pipelines de modelos de visão e linguagem, que combinam informações visuais e textuais.

Outra melhoria está nas otimizações para os gráficos integrados Xe3. Elas buscam melhorar a inferência de modelos Gemma 4 com entradas de contexto longo nos Intel Core Ultra Series 3, um cenário relevante para aplicações que precisam processar grandes volumes de informação antes de responder.

CPU, GPU e NPU na mesma ferramenta de análise

O OpenVINO estende à NPU o suporte de instrumentação e rastreamento ITT. Com isso, o Intel VTune Profiler passa a oferecer uma ferramenta consistente para analisar a execução em CPU, GPU e NPU.

Esse avanço ajuda a investigar gargalos e fundamentar decisões sobre a distribuição das cargas de trabalho. Para a computação heterogênea, observar o comportamento de cada dispositivo é tão importante quanto conseguir executar o modelo nele.

Também em prévia, o suporte a formas dinâmicas com limites definidos nas NPUs avança para tarefas de visão, como super-resolução de imagens, com validação no modelo ESPCN. É um passo relevante para entradas de dimensões variáveis, dentro dos limites suportados, sem representar suporte irrestrito a qualquer forma dinâmica.

Reconhecimento de fala diretamente no Node.js

O OpenVINO GenAI adiciona suporte ao ASRPipeline em Node.js. Desenvolvedores JavaScript passam a contar com uma API para reconhecimento automático de fala, incluindo modelos como Whisper e Qwen3-ASR, com streaming e métricas de desempenho.

A interface segue uma abordagem semelhante à disponível em C++ e Python. Isso facilita a integração de transcrição em aplicações e serviços que já utilizam JavaScript.

Servidores com melhor aproveitamento de memória

O OpenVINO Model Server recebe, em prévia, gerenciamento de modelos ociosos. A funcionalidade permite descarregar modelos que não estão em uso para reduzir o consumo de memória.

Esse recurso pode ser especialmente útil em serviços que disponibilizam vários modelos com demandas intermitentes. Na avaliação prática, será importante considerar também o tempo necessário para recarregá-los quando uma nova solicitação chegar.

O Model Server amplia ainda o suporte a modelos voltados a aplicações com agentes, incluindo Muse Glimmer 30B e Qwen3.8 27B.

Para quem trabalha com IA local e infraestrutura própria, o OpenVINO 2026.4.0 oferece novas oportunidades de aproveitar o hardware disponível. O próximo passo é transformar suporte anunciado em resultados medidos: validar compatibilidade, qualidade das respostas, consumo de memória e latência nas condições reais de uso. É assim que novas capacidades se tornam soluções úteis no dia a dia.

Fonte: https://github.com/openvinotoolkit/openvino

Dia do Programador: paixão, criatividade e 256 motivos para celebrar

Somos apaixonados pelo que fazemos. Cada linha de código carrega não apenas lógica, mas também dedicação, criatividade e horas de estudo. Por trás de cada aplicação, sistema ou ferramenta, existem pessoas curiosas, movidas por desafios e com uma sede insaciável por conhecimento.

Comemos informação no café da manhã e transformamos problemas complexos em soluções elegantes. Entre uma xícara de café e outra, aprendemos que um erro pode revelar um caminho, que uma pergunta pode mudar um projeto e que sempre existe algo novo para descobrir.

Até a data da nossa comemoração tem uma lógica especial: o Dia do Programador é celebrado no 256º dia do ano. Isso significa que ele cai em 13 de setembro nos anos comuns e em 12 de setembro nos anos bissextos, quando fevereiro ganha um dia a mais.

Mas por que 256? Porque 2⁸ = 256, a quantidade de valores diferentes que podem ser representados com oito bits, ou um byte. São valores que vão de 0 a 255 — um detalhe que faz todo sentido para quem vive no universo da computação.

Em 2026, o Dia do Programador é celebrado em 13 de setembro. Uma data para reconhecer quem transforma café em software, erros em aprendizado e ideias em inovação.

Programar exige paciência para investigar o que não funciona, humildade para revisar o próprio trabalho e disposição para continuar aprendendo. Também envolve compartilhar descobertas, pedir ajuda e contribuir para que outras pessoas possam ir além. É esse espírito que fortalece nossa comunidade.

Feliz Dia do Programador a todas as programadoras e todos os programadores aqui do Assunto Nerd! Que nunca nos faltem curiosidade, criatividade e vontade de construir. Afinal, a próxima grande ideia pode começar com uma simples linha de código.

Sistema operacional Linux integra Intel oneAPI, Level Zero, OpenVINO, Intel Arc e NPU para reduzir a complexidade da computação heterogênea e acelerar o desenvolvimento de aplicações de IA

A Inteligência Artificial está chegando cada vez mais perto do usuário. O que durante muitos anos esteve concentrado em grandes datacenters equipados com aceleradores especializados começa agora a fazer parte dos notebooks, desktops, estações de trabalho e dispositivos de borda. As novas gerações de hardware Intel são um exemplo claro dessa transformação.

Em uma mesma máquina podemos encontrar CPU, GPU Intel Arc e NPU, três arquiteturas com características diferentes e que podem ser exploradas conjuntamente em aplicações de Inteligência Artificial. O desafio, porém, não está apenas em possuir esse hardware.

É necessário fazer
tudo funcionar.

Drivers, firmware, runtimes, bibliotecas, compiladores, frameworks e diferentes camadas de acesso ao hardware precisam estar corretamente instalados, configurados e compatíveis. Foi justamente para atacar esse problema que nasceu o MultiCortex AI Intel Accelerated.

A proposta é simples: entregar um ambiente Linux no qual a infraestrutura necessária para explorar a computação heterogênea Intel já esteja disponível desde o primeiro boot. A própria plataforma apresenta CPU, Intel Arc GPU e Intel NPU como recursos complementares para processamento geral, inferência e IA eficiente.

O problema não é apenas instalar um framework

Uma das etapas mais complexas e custosas na adoção de Inteligência Artificial é a instalação, configuração e integração dos aceleradores com os frameworks utilizados pelos desenvolvedores.

Mesmo em ecossistemas extremamente populares, como NVIDIA e CUDA, preparar corretamente uma máquina para desenvolvimento de IA pode exigir conhecimento especializado. No ecossistema Intel existe um desafio adicional.

Tecnologias como Intel NPU, Intel Arc, oneAPI, Level Zero e OpenVINO ainda são menos conhecidas por uma parcela significativa dos desenvolvedores quando comparadas às stacks tradicionais de GPU.

E possuir uma NPU dentro do processador não significa automaticamente conseguir utilizá-la. Entre a aplicação e o silício existem várias camadas. De forma simplificada:

Uma falha em qualquer uma dessas camadas pode fazer com que um acelerador fisicamente presente na máquina simplesmente desapareça para a aplicação.

Foi exatamente um problema desse tipo que encontrei durante o trabalho realizado com a Intel NPU.

Quando o hardware existe, mas a aplicação não consegue utilizá-lo

Durante os testes do linux-npu-driver 1.35.0, percebi uma situação particularmente preocupante. O hardware estava presente. O firmware estava carregado. O driver de kernel estava funcionando.

Mesmo assim, o OpenVINO não conseguia disponibilizar a NPU.

Em determinados cenários, o problema era ainda mais grave: processos que dependiam da inicialização da NPU terminavam completamente com um SIGABRT.

Ou seja, não era simplesmente uma redução de desempenho ou a execução automática da carga na CPU. O processo poderia literalmente sofrer um crash durante a inicialização do Level Zero. A investigação levou a uma thread interna do driver chamada ResourceCleaner.

O código utilizava:

std::chrono::steady_clock::time_point::max()

como deadline para:

std::condition_variable::wait_until()

A intenção era representar uma espera infinita.

O problema é que determinadas implementações da libstdc++ realizam internamente conversões entre relógios ao processar o deadline recebido por wait_until(). Como time_point::max() já está próximo do maior valor suportado pelo inteiro utilizado internamente para representar o tempo, a operação de conversão poderia provocar um signed integer overflow. Em ambientes onde esse overflow era detectado pelo runtime do GCC, a execução chegava ao helper __addvdi3, que executava um abort().

O resultado final era um: SIGABRT

e o encerramento completo do processo.

Corrigindo o driver da NPU

A solução foi mudar a lógica utilizada pelo ResourceCleaner. Uma espera realmente infinita não precisa ser representada artificialmente por uma data extremamente distante. Quando nenhum timeout está configurado, a solução adequada é utilizar simplesmente:

cv.wait(lock);

Quando existe efetivamente um prazo para a operação de limpeza, permanece:

cv.wait_until(lock, timeout);

A correção também passou a proteger as atualizações da variável idleTimeout utilizando o mutex já existente no mecanismo de limpeza, evitando acesso concorrente entre setIdleTimeout() e a thread executada em background.

A alteração foi desenvolvida e submetida como contribuição upstream diretamente ao repositório oficial intel/linux-npu-driver, no Pull Request #142.

Essa contribuição representa algo importante para o projeto MultiCortex. Não estamos simplesmente instalando pacotes desenvolvidos por terceiros dentro de uma imagem Linux.

Estamos trabalhando, testando e entendendo a stack em profundidade suficiente para chegar até a camada que controla o acelerador e contribuir com sua correção.

É também mais uma contribuição Open Source brasileira chegando à infraestrutura utilizada para Inteligência Artificial.

De cinco falhas para seis testes concluídos

O problema foi reproduzido utilizando o linux-npu-driver 1.35.0 em uma Intel NPU40xx.

O teste utilizado foi:

npu-umd-test --ze-init-test -c none

Antes da alteração, apenas 1 dos 6 testes era concluído corretamente. Os outros cinco processos falhavam com:

status: 134

correspondente ao SIGABRT.

Após a aplicação da correção:

[ PASSED ] 6 tests.

Todos os seis testes foram concluídos.

Mais importante do que o teste isolado foi verificar o comportamento da stack completa.

Com Python e OpenVINO:

import openvino as ov
core = ov.Core()
print(core.available_devices)

o resultado passou a ser:

['CPU', 'NPU']

confirmando que a NPU estava novamente disponível para aplicações de Inteligência Artificial.

Esse caso ilustra exatamente por que simplesmente entregar uma lista de pacotes instalados não é suficiente para construir uma plataforma de IA.

A stack precisa ser testada do hardware até a aplicação.

É nesse ponto que entra o MultiCortex AI Intel Accelerated

O MultiCortex AI Intel Accelerated foi desenvolvido para reduzir justamente essa distância entre possuir um computador com aceleradores Intel e efetivamente conseguir utilizá-los para desenvolver Inteligência Artificial.

A imagem Linux reúne uma stack previamente preparada com componentes como:

• Intel oneAPI, como ecossistema de desenvolvimento;
• Level Zero, fornecendo acesso de baixo nível aos dispositivos;
• OpenVINO, para inferência e otimização de modelos;
• drivers e runtime para Intel Arc GPU;
• driver e runtime para Intel NPU;
• suporte à utilização da CPU como parte da mesma arquitetura heterogênea.

Esses componentes já fazem parte da proposta apresentada pela plataforma MultiCortex, reduzindo as etapas necessárias antes que um desenvolvedor consiga efetivamente executar seu primeiro workload.

Em vez de começar o projeto procurando documentação, adicionando repositórios, resolvendo dependências, compilando componentes e diagnosticando incompatibilidades entre drivers e runtimes, o desenvolvedor pode começar pelo que realmente importa:

a aplicação de Inteligência Artificial.

CPU + GPU + NPU

Um dos conceitos centrais do MultiCortex AI Intel Accelerated é a computação heterogênea.

Nem toda carga deve necessariamente ser executada no acelerador mais poderoso.

Cada dispositivo possui características diferentes.

A CPU continua sendo extremamente importante para controle da aplicação, pré e pós-processamento, modelos e operações gerais.

A GPU Intel Arc oferece grande paralelismo e capacidade computacional para cargas intensivas.

A NPU adiciona um acelerador especializado para redes neurais, criado principalmente para executar cargas de IA com grande eficiência energética.

Com ferramentas como o OpenVINO, uma aplicação pode selecionar dispositivos diferentes ou construir pipelines capazes de aproveitar essa diversidade de recursos.

Isso transforma o computador moderno em algo diferente do modelo tradicional em que praticamente todo o processamento era concentrado na CPU.

Passamos a ter diversos motores computacionais disponíveis dentro de uma mesma máquina.

CPU + GPU + NPU.

E o MultiCortex AI Intel Accelerated foi construído justamente para tornar essa computação heterogênea visível, utilizável e mensurável. A demonstração pública da plataforma mostra CPU, NPU e Intel Arc GPU sendo utilizadas simultaneamente.

OpenVINO como ponto de integração

Uma das tecnologias centrais dessa estratégia é o OpenVINO.

O OpenVINO permite desenvolver e executar aplicações de inferência em diferentes dispositivos, criando uma camada de abstração entre os modelos de Inteligência Artificial e os aceleradores disponíveis.

A geração OpenVINO 2026 ampliou ainda mais essa estratégia.

A documentação oficial da versão 2026.3 apresenta suporte a novos modelos executando em CPU, GPU e NPU, além da expansão de modelos como YOLO26 para GPU e NPU e novas integrações para aplicações de IA generativa.

O MultiCortex AI Intel Accelerated utiliza essa capacidade como uma das bases para permitir que desenvolvedores experimentem inferência, visão computacional, processamento de linguagem natural, modelos generativos e outros workloads aproveitando o hardware disponível localmente.

IA na borda

Existe ainda uma consequência importante dessa evolução.

Quanto mais capacidade computacional existe localmente, menos determinadas aplicações precisam depender exclusivamente do datacenter.

Processamento de imagens, reconhecimento de voz, biometria, análise de dados, modelos de linguagem e diferentes mecanismos de predição podem começar a ser executados diretamente no equipamento do usuário.

Isso traz vantagens importantes para aplicações que exigem:

baixa latência, privacidade, funcionamento offline, eficiência energética e soberania sobre os dados.

A NPU tem um papel particularmente interessante nesse cenário.

Ela é um recurso que já está fisicamente presente em uma nova geração de computadores, mas que ainda permanece subutilizado por muitas aplicações.

O desafio agora é permitir que mais desenvolvedores aprendam a utilizá-la.

Reduzindo a barreira de entrada

É exatamente aí que considero estar a principal contribuição do MultiCortex AI Intel Accelerated.

O objetivo não é simplesmente criar mais uma distribuição Linux.

É criar uma plataforma de experimentação e desenvolvimento capaz de reduzir uma das maiores barreiras da computação heterogênea:

a preparação do ambiente.

Um desenvolvedor que deseja estudar Intel NPU não deveria precisar passar dias tentando entender por que o dispositivo não aparece no framework.

Uma empresa que deseja validar um caso de uso com Intel Arc não deveria começar seu projeto de IA diagnosticando versões incompatíveis de drivers.

Uma equipe de inovação interessada em CPU + GPU + NPU deveria poder começar experimentando sua arquitetura, e não montando toda a infraestrutura necessária para chegar até ela.

Por isso, o conceito do MultiCortex AI Intel Accelerated pode ser resumido em uma frase:

Do hardware Intel à aplicação de IA, sem perder tempo preparando o ambiente.

Mais do que consumir tecnologia

Minha experiência trabalhando com OpenVINO e com o driver Intel NPU também reforçou uma convicção que tenho há muitos anos dentro do Open Source.

Não devemos ser apenas consumidores de tecnologia.

Precisamos aprender como ela funciona.

Precisamos empacotar.

Testar.

Encontrar problemas.

Investigar.

Corrigir.

E, sempre que possível, devolver essas melhorias para o projeto original.

A correção desenvolvida para o ResourceCleaner do Intel Linux NPU Driver é um exemplo concreto dessa filosofia.

E o conhecimento adquirido nesse processo retorna diretamente para o desenvolvimento do MultiCortex AI Intel Accelerated.

Isso significa que a plataforma não nasce apenas da integração de componentes.

Ela nasce da experiência prática de fazer CPU, GPU, NPU, Level Zero, oneAPI, drivers e OpenVINO funcionarem juntos em um ambiente Linux real.

O computador já possui um acelerador de IA. Precisamos começar a utilizá-lo.

Estamos entrando em uma nova fase da computação pessoal.

A Inteligência Artificial não estará apenas na nuvem.

Ela estará no próprio equipamento.

CPU, GPU e NPU formarão uma plataforma heterogênea capaz de executar uma parte cada vez maior dos workloads de Inteligência Artificial localmente.

O hardware está chegando.

Agora precisamos entregar aos desenvolvedores as ferramentas para utilizá-lo.

Esse é o propósito do MultiCortex AI Intel Accelerated:

transformar o hardware Intel disponível no computador em uma plataforma Linux completa, integrada e pronta para desenvolvimento e execução de Inteligência Artificial desde o primeiro boot.

Com 2,4 trilhões de parâmetros, arquitetura Mixture of Experts, 95 bilhões de parâmetros ativos por token e contexto que pode ultrapassar 1 milhão de tokens, o novo Qwen mostra que a disputa entre modelos abertos e proprietários entrou em uma nova fase.

A Alibaba acaba de dar um passo importante na corrida global pela Inteligência Artificial ao disponibilizar os pesos do Qwen3.8-2.4T-A95B, modelo que representa pela primeira vez a chegada de uma soluçao da classe Qwen-Max ao ecossistema de modelos com pesos abertos.

O número que imediatamente chama a atenção é gigantesco: 2,4 trilhões de parâmetros. Entretanto, talvez a informação mais importante esteja escondida na segunda parte de seu nome, A95B. Graças à arquitetura Mixture of Experts (MoE), o modelo não utiliza seus 2,4 trilhões de parâmetros simultaneamente para processar cada token. Aproximadamente 95 bilhões de parâmetros são ativados durante cada passagem, permitindo combinar uma capacidade total gigantesca com um custo computacional por token muito menor do que seria necessário em um modelo denso de tamanho equivalente. A própria Qwen descreve esta geração como a mais capaz de sua família aberta até o momento e afirma que ela foi desenvolvida especialmente para programação, trabalho profissional, pesquisa e tarefas autônomas de longa duração.

2,4 trilhões de parâmetros não significam 2,4 trilhões trabalhando ao mesmo tempo

É importante compreender a arquitetura para não interpretar incorretamente os números. Em um modelo tradicional denso, praticamente todos os parâmetros participam de cada etapa de inferência. No Qwen3.8-2.4T-A95B, a estratégia é diferente. O sistema possui 512 especialistas, mas seleciona apenas 10 especialistas roteados e um especialista compartilhado para cada token. Essa arquitetura permite que diferentes regiões do modelo se especializem em diferentes tipos de informação e tarefas. Em vez de utilizar indiscriminadamente toda a capacidade da rede neural, um mecanismo de roteamento decide quais especialistas são mais apropriados para processar determinado conteúdo. Segundo a especificação oficial, o modelo possui 92 camadas, dimensão interna de 8.192 e uma organização híbrida que combina Gated DeltaNet, Gated Attention e camadas MoE.

Essa abordagem é particularmente interessante porque representa uma mudança na forma como devemos analisar o tamanho dos grandes modelos. Os 2,4 trilhões de parâmetros representam a capacidade total disponível, enquanto os 95 bilhões ativos representam uma aproximação mais útil da quantidade de computação realizada por token. Isso não significa, entretanto, que estamos diante de um modelo de 95 bilhões de parâmetros comum. Todos os especialistas continuam fazendo parte do modelo e seus pesos precisam estar disponíveis no sistema de inferência. O resultado é uma característica típica dos grandes MoEs: o custo computacional ativo é muito inferior ao de um modelo denso com trilhões de parâmetros, mas os requisitos de memória e movimentação dos pesos continuam enormes.

Um modelo aberto que exige infraestrutura de datacenter

É justamente neste ponto que é necessário separar duas ideias frequentemente confundidas: ter acesso aos pesos de um modelo não significa que seja simples executá-lo localmente. Com 2,4 trilhões de parâmetros, o Qwen3.8-2.4T-A95B está muito distante da categoria de modelos que normalmente instalamos em uma única GPU de workstation. Uma conta teórica simples mostra a dimensão do problema: 2,4 trilhões de parâmetros armazenados com dois bytes por parâmetro representam algo próximo de 4,8 TB apenas para os pesos em BF16, sem considerar cache, buffers, estados intermediários e demais estruturas utilizadas durante a inferência. Mesmo representações de menor precisão continuam colocando o modelo na escala de terabytes.

A NVIDIA, que disponibilizou suporte ao modelo já no lançamento, classifica explicitamente sua execução como uma tarefa de computação acelerada em escala de datcenter. Em seus testes iniciais, a empresa utilizou uma plataforma GB300 NVL72, formada por 72 GPUs Blackwell Ultra interligadas em um domínio NVLink de alta velocidade. A NVIDIA reportou, em condições específicas de benchmark e utilizando FP8, throughput superior a 4 mil tokens por segundo por GPU no cenário de máxima vazão e mais de 350 tokens por segundo por usuário em sua configuração de teste. Esses valores não devem ser interpretados como desempenho esperado em qualquer hardware, mas demonstram o nível de engenharia de infraestrutura envolvido na exploração eficiente de um MoE dessa escala.

Isso cria uma situação interessante. O Qwen3.8 é um modelo com pesos disponíveis para download e implantação própria, porém sua escala significa que self-hosting completo continua sendo uma atividade destinada principalmente a empresas, provedores de nuvem, universidades, centros de pesquisa e organizações com clusters de aceleradores. Para a maioria dos desenvolvedores, consumir o modelo através de uma API ou de provedores especializados continuará sendo consideravelmente mais simples do que mantê-lo integralmente em infraestrutura própria.

A nova disputa passa a ser sobre quem conseguirá transformar essa capacidade computacional gigantesca em sistemas eficientes, privados, especializados, sustentáveis e realmente úteis.

A batalha deixa de ser apenas pelo melhor modelo

O lançamento também revela uma tendência maior no mercado de Inteligência Artificial. Durante algum tempo, a discussão foi dominada por uma pergunta simples: qual empresa possui o modelo mais inteligente? A evolução de arquiteturas como o Qwen3.8 sugere que a pergunta está ficando mais complexa.

Precisaremos perguntar qual modelo oferece a melhor relação entre qualidade e custo, qual consegue trabalhar autonomamente durante mais tempo, qual lida melhor com milhões de tokens, qual pode ser executado dentro da infraestrutura de uma organização, qual pode ser especializado para determinado domínio e, principalmente, quem controla os dados, o modelo e a infraestrutura utilizados durante a operação.

Nesse cenário, o Qwen3.8-2.4T-A95B representa mais do que outro lançamento da Alibaba. Ele demonstra que modelos com pesos disponíveis publicamente chegaram a uma escala que, há pouco tempo, parecia reservada aos maiores laboratórios privados do planeta. Não significa o fim dos modelos proprietários, tampouco prova superioridade absoluta sobre eles. Significa algo talvez mais transformador: a fronteira entre IA aberta e IA fechada está ficando cada vez mais estreita.

E quando um modelo com 2,4 trilhões de parâmetros, 95 bilhões ativos por token, mais de 500 especialistas e capacidade para trabalhar com aproximadamente 1 milhão de tokens de contexto pode ter seus pesos baixados e implantados por terceiros, a discussão deixa de ser apenas sobre quem consegue construir a maior Inteligência Artificial.

A nova disputa passa a ser sobre quem conseguirá transformar essa capacidade computacional gigantesca em sistemas eficientes, privados, especializados, sustentáveis e realmente úteis.

Mais informações : https://huggingface.co/Qwen/Qwen3.8-2.4T-A95B

Imagine entrar em um ambiente virtual que não foi completamente desenhado por uma equipe de artistas, programadores e desenvolvedores. Em vez de carregar um mapa pronto, armazenado previamente no computador, o cenário é criado continuamente por uma inteligência artificial enquanto o usuário caminha, dirige um veículo, movimenta um personagem ou altera a direção da câmera. Essa é a proposta do ABot-World-0, um modelo desenvolvido pelo AMAP CV Lab para gerar vídeos interativos condicionados às ações do usuário.

O paper do projeto, intitulado “ABot-World-0: Infinite Interactive World Rollout on a Single Desktop GPU”, foi publicado no arXiv em julho de 2026. O trabalho representa uma mudança importante na evolução dos sistemas de geração de vídeo, pois não se limita à criação de pequenos clipes previamente determinados. O objetivo é produzir um mundo visual que continue sendo gerado conforme o usuário interage com ele, criando uma experiência que se aproxima de um videogame, mas sem depender exclusivamente de cenários, movimentos e animações programados antecipadamente.

Muito além de um gerador tradicional de vídeos

Nos geradores de vídeo convencionais, o usuário escreve uma descrição e aguarda a inteligência artificial produzir uma sequência com alguns segundos de duração. Depois que o vídeo é concluído, não existe uma maneira real de entrar naquela cena, mudar sua direção ou decidir o que acontecerá em seguida. O ABot-World-0 funciona de forma diferente: o usuário envia comandos pelo teclado e o modelo utiliza essas ações para determinar como os próximos quadros devem ser produzidos.

Ao pressionar uma tecla para avançar, virar, recuar ou movimentar a câmera, a inteligência artificial precisa prever como o cenário deve se transformar em resposta àquela ação. Os novos quadros gerados passam a fazer parte do contexto utilizado na próxima etapa da simulação. Dessa forma, o sistema opera em um ciclo contínuo no qual o usuário envia um comando, a IA interpreta a ação, o ambiente responde visualmente e o resultado passa a ser usado como ponto de partida para os próximos movimentos.

O modelo trabalha com oito comandos principais. As teclas W, A, S e D controlam a movimentação, enquanto I, J, K e L controlam a rotação da câmera ou do personagem. Esses comandos são sincronizados com os quadros do vídeo e inseridos diretamente na rede neural. Com isso, o modelo aprende que determinadas ações devem provocar mudanças específicas no ambiente virtual. Nas demonstrações, é possível caminhar por cenários abertos, explorar construções, controlar personagens, dirigir veículos, atravessar terrenos variados e reagir visualmente a obstáculos.

A experiência lembra um jogo eletrônico, mas existe uma diferença fundamental. Em um jogo tradicional, o mapa, os objetos, as animações, a iluminação e as regras de interação foram previamente criados e programados. No ABot-World-0, uma parte considerável do que aparece na tela é prevista e sintetizada pela inteligência artificial durante a própria execução. Em outras palavras, o ambiente não está sendo apenas exibido: ele está sendo continuamente imaginado pelo modelo.

Um mundo virtual executado em uma única GPU

Um dos aspectos mais impressionantes do ABot-World-0 é sua capacidade de funcionar em uma única NVIDIA GeForce RTX 5090, sem depender de um cluster composto por várias GPUs. O sistema consegue gerar vídeos com resolução de 1280 × 704 pixels, alcançando uma taxa de até aproximadamente 16 quadros por segundo. A latência entre o comando do usuário e a geração do primeiro quadro correspondente fica em torno de 1,2 segundo, enquanto o consumo máximo de memória gráfica permanece abaixo de aproximadamente 19,3 GiB de VRAM nas configurações otimizadas apresentadas pelos pesquisadores.

Esses números não significam que o projeto pode ser executado em qualquer computador doméstico. A RTX 5090 é uma placa de vídeo de alto desempenho e representa o segmento mais avançado das GPUs de consumo. Mesmo assim, executar uma simulação generativa desse nível em uma única placa instalada em um computador de mesa é muito diferente de depender de dezenas ou centenas de aceleradores operando em um data center.

O desempenho também varia conforme a precisão numérica utilizada durante a inferência. Na configuração FP8, que procura preservar maior qualidade visual, o sistema alcançou aproximadamente 12,4 FPS. Já na configuração MXFP4, mais comprimida e voltada para maior velocidade, o desempenho chegou a cerca de 15,8 FPS, valor divulgado de forma arredondada como até 16 FPS.

Ainda não estamos falando de uma experiência comparável aos 60, 120 ou 144 quadros por segundo encontrados em jogos modernos. A latência de 1,2 segundo também é perceptível e impede que o sistema seja considerado totalmente instantâneo. Entretanto, o resultado demonstra que a geração interativa de mundos virtuais começa a entrar em uma faixa de desempenho utilizável, especialmente para pesquisa, prototipagem, simulação e experiências visuais experimentais.

Como a inteligência artificial aprende a controlar um mundo

Para ensinar uma inteligência artificial a criar um ambiente interativo, não basta fornecer vídeos visualmente atraentes. O modelo precisa compreender qual ação provocou cada movimento mostrado na gravação. Ele precisa aprender, por exemplo, que pressionar uma tecla para a esquerda deve alterar a trajetória do personagem e modificar a perspectiva do cenário de maneira coerente.

Por isso, o treinamento do ABot-World-0 combina dados provenientes de jogos eletrônicos, ambientes simulados e vídeos reais encontrados na internet. Os jogos fornecem imagens detalhadas acompanhadas de comandos precisos. Nesse contexto, é possível registrar exatamente qual tecla foi pressionada, para onde o personagem se movimentou, como a câmera reagiu e quais mudanças ocorreram no ambiente.

Os simuladores oferecem ainda mais controle sobre elementos como posição da câmera, geometria, horário, clima, iluminação, trânsito, trajetória e movimentação de objetos. Já os vídeos reais da internet acrescentam diversidade de paisagens, condições de iluminação, perspectivas e situações encontradas no mundo físico. Como esses vídeos normalmente não possuem os comandos que deram origem ao movimento da câmera, o sistema precisa estimar o deslocamento e criar rótulos aproximados para as ações observadas.

O projeto também apresenta um agente autônomo chamado WorldExplorer, responsável por percorrer jogos e ambientes simulados automaticamente. Durante esse processo, ele coleta vídeos, posições de câmera, ações, trajetórias, estados do ambiente e outros metadados necessários para o treinamento. Quando os pesquisadores identificam que o modelo apresenta dificuldades em determinado cenário, movimento ou perspectiva, o sistema pode direcionar uma quantidade maior de coleta para aquela situação específica.

Isso cria um ciclo de melhoria contínua. O agente coleta os dados, o modelo é treinado, os erros são analisados e novas amostras são produzidas para corrigir as deficiências encontradas. Em vez de criar um conjunto de treinamento estático, os pesquisadores utilizam o próprio desempenho da inteligência artificial para orientar quais dados precisam ser coletados posteriormente.

Controle de qualidade e preservação dos personagens

Como dados ruins produzem modelos ruins, o material coletado passa por uma sequência de 14 verificações determinísticas, distribuídas em diferentes categorias de qualidade. O pipeline procura quadros ausentes, vídeos corrompidos, resoluções incorretas, falhas de sincronização, telas de carregamento, menus, elementos de interface, problemas de geometria, personagens atravessando objetos, comandos incompatíveis com o movimento, metadados incompletos e cenas visualmente inadequadas.

Além das verificações automáticas, um modelo de visão e linguagem analisa semanticamente os vídeos. Os trechos aprovados recebem informações sobre o tipo de cenário, clima, horário, veículo, perspectiva da câmera, personagem e ações executadas. Essa etapa torna os dados mais organizados e ajuda o modelo a compreender não apenas o movimento, mas também o contexto visual em que ele acontece.

Outro desafio importante é preservar a aparência dos personagens durante sequências prolongadas. Em vídeos longos gerados por inteligência artificial, um personagem pode mudar gradualmente de roupa, rosto, cabelo, proporção ou cor. Para reduzir esse problema, o pipeline extrai imagens de referência dos personagens em diferentes ângulos. Essas imagens ajudam o modelo a manter roupas, rosto, cores e identidade visual de maneira mais consistente, principalmente em cenas na terceira pessoa, nas quais o personagem permanece visível durante grande parte da experiência.

O modelo professor, o modelo aluno e o LongForcing

O treinamento utiliza uma estratégia semelhante à relação entre um professor e um aluno. Inicialmente, os pesquisadores treinam um modelo professor bidirecional, capaz de observar diferentes momentos de uma sequência completa. Como possui acesso a mais informações, esse modelo consegue aprender com maior qualidade a aparência das cenas, os movimentos, a dinâmica dos objetos e as consequências de cada ação.

Entretanto, o modelo professor não é adequado para uma aplicação em tempo real, pois depende de várias etapas de processamento e de uma visão mais ampla da sequência. Seu conhecimento é então transferido para um modelo aluno causal, que precisa trabalhar como o sistema funcionará durante o uso real: observando apenas o que já aconteceu e prevendo o próximo trecho do vídeo.

A transferência de conhecimento ocorre em três etapas. Na primeira, chamada Teacher Forcing, o aluno aprende a produzir os próximos quadros utilizando sequências corretas fornecidas durante o treinamento. Na segunda, conhecida como destilação ODE, o sistema reduz a quantidade de etapas necessárias para transformar o ruído inicial nos próximos quadros, acelerando significativamente a geração. Na terceira etapa entra o LongForcing, uma das principais contribuições apresentadas pelo projeto.

O LongForcing treina o modelo utilizando suas próprias gerações prolongadas. Em vez de trabalhar apenas com sequências perfeitas, o aluno precisa continuar produzindo novos quadros a partir das imagens que ele mesmo criou. O modelo professor analisa essas sequências e ajuda a corrigir os desvios que surgem ao longo do tempo. Essa técnica é essencial porque, em uma simulação contínua, qualquer pequeno erro pode ser reutilizado como contexto e acabar provocando falhas cada vez maiores.

O ABot-World-0 possui aproximadamente 5 bilhões de parâmetros, número relativamente compacto quando comparado a modelos com dezenas ou centenas de bilhões. Isso é particularmente relevante porque o sistema não trabalha apenas com texto. Ele precisa processar simultaneamente vídeo, movimento, ações, contexto temporal, aparência e dinâmica do ambiente. A pesquisa demonstra que modelos extremamente grandes nem sempre são indispensáveis quando a arquitetura, os dados, o treinamento e a inferência são cuidadosamente otimizados.

O desafio de gerar um mundo sem perder qualidade

Em um vídeo convencional de poucos segundos, pequenos erros podem passar despercebidos porque a sequência termina rapidamente. Em um mundo interativo, o problema é muito mais grave. Cada quadro criado pela inteligência artificial é utilizado como contexto para produzir os quadros seguintes. Um pequeno erro pode gerar outro erro maior, que passa a influenciar novas previsões e se acumula progressivamente.

Esse fenômeno é conhecido como drift, ou desvio acumulado. Com o passar do tempo, o personagem pode mudar de aparência, os objetos podem se deformar, os detalhes do cenário podem desaparecer e os movimentos podem se tornar repetitivos. Também podem surgir imagens borradas, cores excessivamente saturadas, texturas artificiais ou quadros praticamente congelados.

O LongForcing foi desenvolvido justamente para reduzir esse problema. Em vez de treinar o modelo apenas com trechos curtos e visualmente perfeitos, os pesquisadores também o expõem às previsões acumuladas que ele produz durante gerações prolongadas. O modelo professor observa essas sequências e ajuda o aluno a retornar para uma distribuição visual mais coerente.

Nos testes de 60 segundos, a técnica apresentou menos borrões, repetição de padrões, saturação excessiva e degradação visual do que outras configurações avaliadas. O artigo também apresenta exemplos retirados de gerações com duração de horas e testes realizados em escala de dias.

A expressão “geração infinita”, entretanto, precisa ser interpretada com cuidado. Ela não significa que o ambiente permanecerá perfeito para sempre nem que a inteligência artificial possuirá memória ilimitada sobre todos os lugares, objetos e acontecimentos. O termo indica que o sistema não possui uma duração fixa obrigatória, como ocorre com vídeos limitados a cinco ou dez segundos. Enquanto houver recursos computacionais e comandos do usuário, o modelo pode continuar produzindo novos quadros, embora inconsistências ainda possam surgir ao longo da experiência.

Otimização completa para caber em uma GPU

O desempenho alcançado pelo ABot-World-0 não depende apenas do modelo de inteligência artificial. Os pesquisadores precisaram otimizar toda a cadeia de execução, incluindo arquitetura, precisão numérica, memória, decodificação e kernels utilizados pela GPU.

Entre as principais tecnologias estão um decodificador de vídeo VAE mais leve, o processamento do Diffusion Transformer em baixa precisão, SageAttention2, uma implementação otimizada de RoPE, gerenciamento avançado de memória, cache KV com tamanho limitado, geração em blocos de quadros, FlashAttention, LightX2V e quantizações em FP8 e MXFP4.

A configuração original não cabia na memória da RTX 5090. O sistema tornou-se viável somente depois da combinação entre quantização, decodificador mais leve, kernels especializados e um gerenciamento mais eficiente da memória. Esse resultado traz uma lição importante para o desenvolvimento de soluções de IA: não basta possuir um bom modelo. Para transformar uma pesquisa em uma aplicação utilizável, é necessário otimizar conjuntamente software, arquitetura, memória e hardware.

Resultados apresentados no WorldRoamBench

O ABot-World-0 foi avaliado no WorldRoamBench, benchmark voltado para modelos de mundos interativos. A avaliação considera a capacidade de responder aos comandos, acompanhar trajetórias, preservar a qualidade visual, reproduzir comportamentos físicos e manter informações ao longo do tempo.

O modelo alcançou 0,5266 de precisão estrita no controle das ações, ficando muito próximo da melhor pontuação apresentada na comparação, que foi de 0,5317. Também obteve 0,7290 em precisão parcial, 0,6752 no acompanhamento de trajetória, 0,5039 em estética, 0,4651 em qualidade de imagem, 0,5223 em mecânica e 0,5041 em memória.

Métrica	Resultado
Precisão estrita das ações	0,5266
Precisão parcial	0,7290
Acompanhamento de trajetória	0,6752
Estética	0,5039
Qualidade da imagem	0,4651
Mecânica	0,5223
Memória	0,5041

Os resultados demonstram um desempenho competitivo, mas não uma vitória em todas as categorias. Outros modelos apresentaram pontuações superiores em determinados critérios, principalmente na retenção de memória. Ainda assim, o ABot-World-0 consegue oferecer resultados relevantes utilizando um modelo relativamente compacto e uma única GPU de desktop.

Os exemplos divulgados pelos pesquisadores incluem veículos colidindo com objetos, personagens deixando marcas na neve, movimentos criando rastros na água e obstáculos impedindo a passagem. Isso não significa, entretanto, que o modelo possua um mecanismo tradicional de física.

O ABot-World-0 não foi programado com regras matemáticas explícitas de colisão, gravidade ou dinâmica. Ele aprendeu esses comportamentos observando grandes quantidades de vídeos e ambientes interativos. As respostas físicas podem parecer plausíveis, mas não devem ser tratadas como uma simulação científica exata. O modelo apenas prevê visualmente o que provavelmente deveria acontecer com base nos exemplos vistos durante o treinamento.

Código aberto e possíveis aplicações

O código de inferência, a demonstração local com Gradio e o modelo causal ABot-World-0-5B-LF foram disponibilizados publicamente. O projeto utiliza a licença Apache 2.0, e os pesos podem ser encontrados em plataformas como Hugging Face e ModelScope.

O ambiente oficialmente testado utiliza Ubuntu 22.04, Python 3.12, CUDA 12.8, PyTorch 2.8, NVIDIA RTX 5090, FlashAttention, SageAttention e LightX2V. A instalação ainda exige a compilação de componentes especializados e não é tão simples quanto instalar um programa convencional. O modelo professor bidirecional e o conjunto completo de aproximadamente 500 horas de vídeos acompanhados de ações anotadas aparecem no planejamento do projeto, mas ainda não estavam totalmente disponibilizados na publicação inicial.

Tecnologias como o ABot-World-0 podem transformar diferentes setores. Na indústria de jogos, desenvolvedores poderão criar protótipos de ambientes que se expandem durante a exploração, reduzindo o tempo necessário para testar conceitos visuais, cenários e mecânicas. Na robótica, agentes autônomos poderão ser treinados em ambientes virtuais antes de serem testados no mundo real. Na realidade virtual, cada usuário poderá explorar espaços personalizados e potencialmente diferentes a cada sessão.

Na educação, estudantes poderão visitar reconstruções interativas de cidades antigas, ecossistemas, laboratórios e acontecimentos históricos. Na produção audiovisual, diretores e artistas poderão navegar por conceitos visuais antes de transformar uma ideia em uma cena tradicional. Também existem possíveis aplicações em direção autônoma, treinamento industrial, planejamento urbano e criação de grandes volumes de dados sintéticos para o treinamento de outros sistemas de inteligência artificial.

Ainda é uma tecnologia experimental

Apesar dos resultados impressionantes, o ABot-World-0 ainda deve ser entendido como um projeto de pesquisa. A experiência depende de uma RTX 5090, apresenta uma latência perceptível e não alcança a taxa de quadros típica dos jogos modernos. O sistema também pode produzir inconsistências, esquecer detalhes antigos, interpretar ações incorretamente, deformar objetos, alterar a aparência dos personagens ou gerar comportamentos fisicamente impossíveis.

O documento publicado no arXiv é um preprint, ou seja, um artigo disponibilizado antes de uma revisão científica mais ampla. Os resultados foram apresentados pelos próprios pesquisadores e ainda precisam ser reproduzidos de maneira independente pela comunidade.

O projeto demonstra uma direção tecnológica promissora, mas ainda não elimina a necessidade de motores gráficos, geometria 3D, física programada, lógica criada por desenvolvedores e validação humana. No futuro, é provável que modelos generativos sejam combinados com essas tecnologias tradicionais, e não simplesmente utilizados para substituí-las.

O futuro dos mundos gerados por inteligência artificial

O ABot-World-0 mostra que a geração de vídeo está deixando de ser apenas uma ferramenta para produzir pequenos clipes. A próxima etapa pode ser a criação de ambientes que respondem, mudam e continuam existindo enquanto são explorados.

Seu principal avanço não está apenas na qualidade visual, mas na combinação entre controle por ações, geração prolongada, preservação de personagens, redução do desvio acumulado, otimização de memória e execução em uma única GPU.

Ainda estamos longe de substituir completamente os motores gráficos convencionais. Porém, o projeto oferece uma demonstração concreta de como poderão funcionar os jogos, simuladores e ambientes virtuais do futuro. Em vez de mundos totalmente armazenados em arquivos e previamente construídos, poderemos explorar ambientes que são imaginados e renderizados pela inteligência artificial em tempo real.

Vídeo e links do projeto

Abaixo um vídeos demonstrativo e links com fontes, paper e informatização técnicas.

Código-fonte no GitHub:
https://github.com/amap-cvlab/ABot-World

Página oficial do projeto:
https://amap-cvlab.github.io/ABot-World/

Artigo científico no arXiv:
https://arxiv.org/abs/2607.19191