O OpenCV 5.0.0 foi lançado oficialmente em junho de 2026 e representa uma das mudanças mais importantes da biblioteca desde a consolidação do OpenCV 2.x e 4.x. Não se trata apenas de uma atualização incremental: a versão 5 reorganiza módulos, remove APIs antigas, moderniza a base de código, melhora o suporte a IA, amplia o suporte a ONNX, introduz novos tipos de dados e prepara a biblioteca para uma computação visual mais heterogênea, envolvendo CPU, GPU, aceleradores e novos backends de hardware. O release oficial do GitHub marca o OpenCV 5.0.0 como a versão mais recente e aponta para o resumo oficial e o guia de migração 4.x → 5.x

O que muda na visão geral

O OpenCV passa a manter duas linhas ativas: a ramificação 4.x, ainda estável, e a nova 5.x, também estável, onde a maior parte das funcionalidades mais recentes será concentrada. A versão 5.0 aproveita partes consolidadas do OpenCV 4.x, adiciona novos recursos, remove componentes obsoletos e introduz algumas mudanças de API, principalmente para limpar dívida técnica acumulada ao longo dos anos.

Na prática, o OpenCV 5.0.0 mira três frentes: modernização da base de código, melhor suporte a IA e melhor preparação para aceleração em diferentes arquiteturas. Isso é especialmente importante para aplicações atuais de visão computacional, robótica, edge AI, sistemas embarcados, inspeção industrial, biometria, vídeo analytics, veículos autônomos e pipelines que combinam visão clássica com deep learning.

Novos requisitos: C++17 e fim do Python 2

Uma das primeiras mudanças é o requisito mínimo de C++17. O OpenCV 5.0 é compilado por padrão com C++17 e deve ser compatível com padrões mais novos. Para quem mantém projetos C++, isso significa revisar toolchains, CMake, compiladores e pipelines de build. O guia oficial de migração recomenda configurar o projeto para C++17 e informa versões mínimas como GCC 8, Clang 9 e MSVC 2017 19.14 ou superior.

O suporte ao Python 2 foi removido. A partir do OpenCV 5.0, é necessário usar Python 3.6 ou superior, e apenas bindings para Python 3 são construídos e distribuídos. Para projetos modernos isso dificilmente será um problema, mas ambientes legados precisarão ser atualizados.

Limpeza pesada: adeus API C legada

O OpenCV 5 removeu a antiga API C do OpenCV 1.x. Funções como cvCreateMat() e cvFindContours(), além de estruturas como CvMat e IplImage, foram retiradas. Alguns macros como CV_8U e CV_32F continuam existindo, mas o caminho oficial agora é a API C++.

Essa decisão é simbólica e técnica. Simbólica porque fecha definitivamente a era do OpenCV 1.x. Técnica porque reduz complexidade, facilita manutenção e permite que a biblioteca avance com modelos de dados e APIs mais modernas. O guia de migração observa que a maior parte do código de produção da última década já não usa diretamente a API C, mas projetos legados precisarão migrar para C++.

OpenVX removido e caminho para uma HAL não CPU

O suporte a OpenVX foi removido da árvore principal. A justificativa é que o OpenCV está caminhando para uma nova camada de abstração de hardware, uma HAL não CPU, que poderá permitir a integração de acelerações específicas de fornecedores sem amarrar a biblioteca a uma única API externa.

Essa mudança é importante para o futuro do OpenCV em ambientes heterogêneos. Em vez de tentar manter integrações antigas e específicas, a biblioteca passa a caminhar para um modelo em que diferentes fornecedores podem plugar acelerações por baixo, mantendo uma interface mais consistente para o desenvolvedor.

G-API e ML clássico foram para o opencv_contrib

O módulo Graph API, conhecido como G-API, foi movido para opencv_contrib. O mesmo aconteceu com o módulo clássico de machine learning, ml. Quem ainda depende de cv::ml::SVM, cv::ml::RTrees ou da G-API precisará compilar o OpenCV com os módulos extras do opencv_contrib.

Para usuários Python, a recomendação oficial é considerar alternativas como scikit-learn para algoritmos clássicos de machine learning. O guia de migração também reforça que cv2.ml.* só estará disponível se o OpenCV for construído com opencv_contrib.

Features2D virou Features

O antigo módulo features2d foi renomeado para features. A mudança reflete uma ampliação de escopo: o módulo deixa de tratar apenas detectores e descritores clássicos 2D e passa a lidar também com vetores de características produzidos por redes neurais modernas.

Detectores clássicos importantes como SIFT, ORB, FAST, GoodFeaturesToTrack e MSER continuam no repositório principal. Já alguns descritores e detectores obsoletos foram movidos para opencv_contrib. O OpenCV 5 também adiciona recursos de características locais baseados em deep learning, incluindo ALIKED e DISK, além do matcher LightGlue.

Outra mudança relevante é a substituição prática do FLANN por busca aproximada de vizinhos mais próxima baseada em Annoy dentro do módulo features. Isso moderniza a forma como o OpenCV lida com busca ANN, especialmente em cenários envolvendo embeddings e vetores de características.

Objdetect foi limpo: Haar e HOG foram para contrib

O módulo objdetect também passou por limpeza. Detectores baseados em Haar e HOG foram movidos para opencv_contrib, no módulo xobjdetect. A explicação é direta: detectores modernos baseados em deep learning tendem a ser mais rápidos e mais precisos.

Para novos projetos, isso sinaliza uma mudança de paradigma. O OpenCV continua preservando compatibilidade via contrib para quem precisa de Haar Cascade ou HOG, mas incentiva o uso de detectores modernos, como modelos DNN para detecção facial e objetos. O guia de migração cita, por exemplo, o uso do FaceDetectorYN baseado em DNN.

Calib3d foi dividido em módulos especializados

O antigo e grande módulo calib3d foi dividido em quatro módulos: geometry, calib, stereo e ptcloud. O módulo geometry concentra algoritmos clássicos de geometria 2D, 3D e nD; calib fica com calibração de câmera; stereo cuida de estimativa de profundidade por correspondência estéreo; e ptcloud reúne algoritmos de alto nível para dados 3D, como odometria visual e TSDF.

Para C++, o cabeçalho legado opencv2/calib3d.hpp continua funcionando como uma camada de compatibilidade, incluindo os novos cabeçalhos por baixo. Para novos projetos, porém, a recomendação é incluir apenas o módulo necessário, como opencv2/geometry.hpp, opencv2/calib.hpp ou opencv2/stereo.hpp. Em Python, a mudança é transparente: as funções continuam acessíveis por cv2.

Novos tipos de dados no Core

O módulo Core recebeu novos tipos de dados. Além dos tipos já conhecidos, como CV_8U, CV_16U, CV_32F, CV_64F e CV_16F, o OpenCV 5 introduz CV_16BF para bfloat16, CV_32U para uint32_t, CV_64U para uint64_t, CV_64S para int64_t e CV_Bool para booleanos armazenados em 1 byte.

Essa mudança aproxima o OpenCV das necessidades modernas de IA. Tipos como FP16 e BF16 são fundamentais em deep learning, inferência otimizada, aceleradores e pipelines que buscam reduzir consumo de memória. O OpenCV também informa que operações básicas com hfloat e bfloat estão disponíveis mesmo em hardware sem suporte nativo, usando conversões internas eficientes.

O tipo CV_Bool também é importante porque matrizes booleanas agora podem ser usadas como máscaras onde antes se usavam máscaras uchar ou schar. Isso melhora a semântica do código e deixa mais clara a intenção do desenvolvedor.

Matrizes 1D e 0D de verdade

O OpenCV 5 passa a suportar arrays com menos de duas dimensões. Um std::vector<T> encapsulado em Mat, InputArray ou OutputArray agora é tratado como um array 1D real, e não mais como uma matriz 2D Nx1 ou 1xN, como acontecia no OpenCV 4.x.

Essa mudança pode afetar códigos que verificam diretamente .rows ou .cols. O guia de migração recomenda usar .total() para obter o número de elementos quando o código precisar funcionar de forma compatível. Para distinguir uma matriz vazia de um escalar 0D, a recomendação é usar mat.empty().

MatShape substitui MatSize

O OpenCV 5 introduz MatShape como substituto de MatSize. A nova estrutura carrega informações de forma e layout dos dados, é embutida diretamente em Mat, UMat e GpuMat e evita alocações dinâmicas extras. Ela também é usada extensivamente pelo módulo DNN para inferência de formas.

Para compatibilidade, MatSize continua disponível como alias, mas novos códigos devem preferir MatShape. Essa mudança é especialmente relevante para modelos de IA, tensores e operações multidimensionais.

LAPACK sempre disponível

O OpenCV 5 passa a ter LAPACK sempre disponível internamente. Isso melhora operações como SVD, decomposição de autovalores/autovetores e componentes do framework USAC. Quando não houver uma biblioteca LAPACK externa instalada, o OpenCV constrói e usa um subconjunto interno mínimo.

Imgproc: mais desempenho, mais precisão e melhor texto

O módulo imgproc recebeu mudanças importantes. Algoritmos de geometria computacional, como convex hull, triangulação de Delaunay e funções relacionadas, foram movidos para o módulo geometry. Em C++, pode ser necessário adicionar opencv2/geometry.hpp; em Python, as funções continuam disponíveis por cv2.

As funções warpAffine, warpPerspective e remap foram substancialmente revisadas. A interpolação bilinear e bicúbica deixou de usar aproximações baseadas em tabelas, resultando em maior precisão e melhor desempenho. Segundo o resumo oficial, os ganhos de velocidade variam de 10% a mais de 300%, dependendo da plataforma, tamanho da imagem, tipo de dado e flags de operação.

O redimensionamento por vizinho mais próximo agora segue o algoritmo do Pillow, tornando os resultados compatíveis com ele. Isso é útil para pipelines que misturam OpenCV e Pillow, mas pode exigir atualização de testes pixel-a-pixel baseados em saídas antigas do OpenCV 4.x.

A renderização de texto foi modernizada. O OpenCV 5 substitui o mecanismo antigo por um renderizador TrueType baseado em STB, com a fonte variável Rubik embutida. Usuários também podem carregar fontes customizadas. Isso amplia o suporte a Unicode, embora ainda existam limitações para scripts que exigem shaping complexo, como árabe e devanágari, e para emojis coloridos.

Também foi adicionado o algoritmo TRUCO, sigla para “Threaded Raster Unrestricted Contour Ownership”, usado para acelerar a extração de contornos. O cv::findContours() passa a usar TRUCO automaticamente quando possível, e o novo algoritmo é descrito como várias vezes mais rápido que a implementação anterior.

DNN: o módulo mais transformado do OpenCV 5

A maior mudança do OpenCV 5 está no módulo DNN. Ele recebeu um novo motor de inferência, que passa a coexistir com o motor clássico. Esse novo motor oferece suporte muito melhor a shapes dinâmicos, subgrafos e recursos modernos do ONNX. A cobertura da especificação ONNX passa de menos de 23% no OpenCV 4.x para mais de 80% no OpenCV 5.

A função cv::dnn::readNet() e variantes como readNetFromONNX() passam a aceitar o parâmetro engine = ENGINE_AUTO. Por padrão, o OpenCV tenta usar o novo motor e, se não conseguir carregar o modelo, faz fallback automático para o motor clássico. Também é possível controlar o motor por variável de ambiente: 1 para clássico, 2 para novo motor, 3 para automático e 4 para ONNX Runtime.

O OpenCV 5 também pode ser construído com ONNX Runtime integrado. Nesse modo, o OpenCV usa seu próprio parser ONNX para construir o grafo ORT internamente, evitando depender do pacote ONNX completo e reduzindo o tamanho binário. Para GPU NVIDIA via ORT, a build deve ser feita com as opções correspondentes de ONNX Runtime GPU.

Um ponto de atenção: o novo motor DNN roda atualmente apenas em CPU. O suporte a GPU para esse novo motor será adicionado em versões futuras. Enquanto isso, quem precisa de GPU deve forçar o motor clássico ou compilar com ONNX Runtime e execution providers da NVIDIA.

Fim dos parsers Darknet e Caffe

Os parsers Darknet e Caffe foram removidos. Isso afeta funções como readNetFromDarknet() e readNetFromCaffe(). A recomendação oficial é converter modelos para ONNX e carregá-los com readNetFromONNX(). Modelos TFLite continuam funcionando via motor clássico, com migração para o novo motor planejada.

Essa mudança acompanha o mercado. ONNX se consolidou como formato comum para interoperabilidade entre frameworks, enquanto Darknet e Caffe ficaram mais associados a modelos e pipelines legados.

Suporte a VLMs: visão e linguagem dentro do OpenCV

O novo motor DNN inclui suporte para modelos visão-linguagem, ou VLMs. O OpenCV 5 passa a incluir componentes necessários como tokenizers, camadas de atenção, blocos de decodificação, pós-processamento e KV-cache para executar VLMs de ponta a ponta.

Isso é uma mudança conceitual forte. Historicamente, o OpenCV era visto como uma biblioteca de visão computacional clássica, com suporte crescente a deep learning. Agora ele começa a entrar no território de modelos multimodais, capazes de combinar imagem e texto.

Desempenho do novo DNN

O resumo oficial informa que o novo motor entrega desempenho competitivo em CPU, igualando ou superando o ONNX Runtime em vários modelos. Os benchmarks apresentados comparam tempos de inferência em milissegundos em diferentes plataformas, incluindo Intel i9, Intel i7, Apple M1, Apple M5 e AMD, com modelos como MobileNetv2, ResNet-50, YOLOv8, ViT e SAM2 Encoder.

Os números variam conforme modelo e hardware. Em alguns casos, o ONNX Runtime ainda é mais rápido; em outros, o OpenCV 5 aparece à frente. O ponto central é que o OpenCV deixa de ser apenas uma alternativa simples de inferência e passa a competir mais diretamente com runtimes especializados em workloads de IA.

Modelos migrados para o Hugging Face

A coleção de modelos pequenos e eficientes do OpenCV foi migrada para o Hugging Face. Todos os modelos usam ONNX e devem ser compatíveis com outros frameworks de inferência.

Isso facilita download, reuso, versionamento e integração com ecossistemas modernos de IA. Para quem trabalha com demonstrações, protótipos, pipelines educacionais ou validação rápida de modelos, essa mudança é bastante prática.

Novo módulo Geometry e calibração multicâmera

A reorganização de geometria e calibração é uma das grandes melhorias estruturais do OpenCV 5. O framework USAC passa a ser o backend padrão para algoritmos de estimação robusta, incluindo homografia, matriz essencial, matriz fundamental, solvePnP e outros. Em comparação com o RANSAC clássico, o USAC combina estratégias modernas como PROSAC, NAPSAC, Progressive-NAPSAC, MSAC, MAGSAC++, LMeds, LO-RANSAC, GC-RANSAC e verificação SPRT.

Também foi adicionado um pipeline de calibração multicâmera ao módulo calib. Ele calibra N câmeras simultaneamente em três estágios: intrínsecos por câmera, extrínsecos par-a-par e otimização global final. O pipeline suporta modelos pinhole e fisheye, inclusive rigs mistos.

O pipeline aceita padrões checkerboard, ChArUco e circle grid. Ele também lida com observações parciais, quando nem todas as câmeras enxergam o padrão completo em todos os frames. Isso é essencial para rigs reais, nos quais o campo de visão entre câmeras pode não se sobrepor perfeitamente.

Processamento 3D: malhas, nuvens de pontos, TSDF e ICP

O OpenCV 5 adiciona suporte inicial a algoritmos de malha e nuvem de pontos, incluindo TSDF e ICP. Também foram adicionados importadores e exportadores para formatos populares como .ply e .obj.

Isso aproxima o OpenCV de aplicações de robótica, reconstrução 3D, sensores de profundidade, visão estéreo, SLAM, inspeção volumétrica e percepção espacial. Ainda é um suporte inicial, mas indica uma direção clara para o ciclo 5.x.

Samples revisados e exemplos de IA generativa

Muitos samples foram revisados, exemplos obsoletos foram removidos e novos exemplos foram adicionados. Os samples de deep learning agora usam uma coleção compartilhada de modelos, que pode ser baixada pelo script download_models.py dentro de samples/dnn.

Também foram adicionados samples experimentais para VLMs e modelos de difusão latente, LDM. Isso mostra que o OpenCV está se posicionando não apenas para visão clássica e deep learning discriminativo, mas também para fluxos mais modernos de IA multimodal e generativa.

Documentação modernizada

A documentação do OpenCV 5 foi modernizada com tema responsivo, navegação lateral persistente, índice “on this page”, busca instantânea com Ctrl+K, modo claro/escuro e melhor renderização matemática.

Essa melhoria parece secundária, mas é importante para adoção. OpenCV é usado por estudantes, pesquisadores, empresas e engenheiros de produto. Uma documentação mais navegável reduz barreiras de entrada e acelera migrações.

Mudanças importantes para migração

A migração do OpenCV 4.x para 5.x tende a exigir ajustes pequenos na maioria dos projetos, mas alguns pontos merecem atenção. O guia oficial lista como áreas afetadas: requisitos de build, remoção da API C, reestruturação de módulos, mudanças no Core, novo motor DNN, alterações de comportamento no imgproc, mudanças em Video I/O e detalhes dos bindings Python.

Projetos C++ devem revisar includes, especialmente em calib3d, features2d, imgproc, ml, gapi, Haar/HOG e geometria computacional. Projetos Java precisarão atualizar imports em alguns casos. Em Python, boa parte da reestruturação é transparente, pois as funções continuam acessíveis em cv2, mas cv2.ml.*, Haar e HOG dependem de build com opencv_contrib.

No DNN, modelos ONNX continuam sendo carregados de forma parecida, mas Caffe e Darknet devem ser convertidos para ONNX. Quem depende de GPU deve observar que o novo motor é CPU-only por enquanto, sendo necessário usar o motor clássico ou ONNX Runtime com provider NVIDIA.

No imgproc, pipelines com testes pixel-a-pixel podem precisar atualizar baselines. O resize por vizinho mais próximo agora segue o comportamento do Pillow, e warpAffine, warpPerspective e remap podem gerar pequenas diferenças numéricas por usarem interpolação mais precisa.

No módulo Video I/O, VideoCapture::get() passa a retornar -1 para propriedades não suportadas. No OpenCV 4.x, retornava 0, o que era ambíguo porque 0 também pode ser um valor válido para algumas propriedades. A recomendação é testar valores menores que zero para detectar propriedades não suportadas.

Atenção para Android e páginas de 16 KB

O release oficial traz uma observação específica para Android: o SDK Android original do OpenCV 5.0.0 foi construído com NDK antigo e inclui biblioteca C++ padrão sem alinhamento adequado para dispositivos com páginas de 16 KB. Para publicações no Google Play, a recomendação é usar o pacote com sufixo 16kb-page-fix.

Essa observação é importante para desenvolvedores Android, especialmente considerando exigências recentes de compatibilidade em dispositivos e versões novas do sistema.

O impacto prático do OpenCV 5.0.0

Para quem usa OpenCV apenas para carregar imagem, redimensionar, converter cor e salvar vídeo, a migração provavelmente será simples. Mas mesmo nesses casos há ganhos potenciais de desempenho e mudanças de comportamento em resize, warp e renderização de texto.

Para quem usa OpenCV com IA, a mudança é muito maior. O novo DNN, a maior cobertura ONNX, o suporte a VLMs, os novos tipos BF16/FP16 e a integração com ONNX Runtime colocam o OpenCV em uma posição mais competitiva como runtime de inferência em CPU e como ferramenta de prototipação multimodal.

Para robótica, visão 3D e calibração, a divisão de calib3d, o novo pipeline multicâmera, o USAC como backend padrão e o suporte inicial a nuvens de pontos e malhas tornam o OpenCV 5 mais organizado e mais alinhado com aplicações modernas de percepção.

Para sistemas embarcados e edge AI, a direção é clara: o OpenCV quer ser uma camada de visão computacional portátil, capaz de aproveitar acelerações específicas sem obrigar o desenvolvedor a reescrever a aplicação para cada hardware.

Conclusão

O OpenCV 5.0.0 não é apenas uma nova versão; é uma mudança de geração. Ele remove o passado legado da API C, reorganiza módulos, moderniza tipos de dados, melhora processamento de imagem, amplia fortemente o DNN, melhora suporte a ONNX, abre caminho para VLMs, fortalece visão 3D e prepara a biblioteca para um futuro heterogêneo.

A versão também exige cuidado na migração. Projetos que usam Caffe, Darknet, API C antiga, Haar/HOG, cv2.ml.*, G-API, comparações pixel-a-pixel ou GPU via DNN precisam testar com atenção. Mas o ganho é claro: uma biblioteca mais limpa, moderna, pronta para IA e mais adequada ao cenário atual de visão computacional.

O OpenCV 5.0.0 marca a transição do OpenCV de uma biblioteca clássica de visão computacional para uma plataforma moderna de visão, IA, geometria, inferência e percepção multimodal.

A interface entre cérebro e máquina sempre pareceu pertencer ao futuro distante. Durante décadas, a ideia de uma pessoa conseguir se comunicar apenas por meio da atividade cerebral foi tratada como ficção científica ou como uma tecnologia limitada a laboratórios altamente especializados. O projeto Brain2Qwerty, da Meta AI Research, mostra que esse futuro está ficando mais concreto.

O Brain2Qwerty é uma pesquisa de interface cérebro-computador não invasiva capaz de decodificar sentenças digitadas a partir de sinais cerebrais. Em vez de exigir implantes cirúrgicos no cérebro, o projeto utiliza registros de atividade cerebral capturados por tecnologias como MEG, magnetoencefalografia, e EEG, eletroencefalografia. A proposta é ambiciosa: aproximar a IA de um cenário em que pessoas que perderam a capacidade de falar ou se mover possam voltar a se comunicar sem precisar passar por cirurgia cerebral.

A versão mais recente, chamada Brain2Qwerty v2, representa um avanço importante em relação à primeira versão. O Brain2Qwerty v1 já conseguia prever teclas a partir de padrões de atividade cerebral registrados por MEG, mas dependia do tempo exato de cada tecla pressionada, o que limitava seu uso em tempo real. A versão v2 supera essa limitação ao gerar sentenças diretamente a partir de gravações contínuas da atividade cerebral.

Na prática, o sistema combina módulos hierárquicos para interpretar diferentes níveis da linguagem: letras, palavras e sentenças. O pipeline usa redes neurais profundas para transformar sinais cerebrais ruidosos em texto coerente, explorando também o contexto linguístico com modelos de linguagem. Esse ponto é essencial, porque o cérebro não gera um sinal “limpo” como um teclado tradicional; a IA precisa inferir padrões, corrigir ambiguidades e reconstruir o significado provável da frase.

Os resultados chamam atenção. Segundo a Meta, o Brain2Qwerty v2 foi treinado com aproximadamente 22 mil sentenças de nove voluntários, cada um gravado por cerca de 10 horas usando um equipamento de MEG enquanto digitava. O modelo alcançou 61% de acurácia média por palavra e chegou a 78% no melhor participante. Mais de metade das sentenças do melhor caso foram decodificadas com no máximo um erro de palavra.

Esse avanço precisa ser entendido com equilíbrio. Não estamos falando ainda de uma tecnologia pronta para uso doméstico ou clínico amplo. O próprio projeto reconhece dois grandes desafios: a precisão ainda não é suficiente para comunicação cotidiana confiável, e o equipamento de MEG usado nos testes é grande, caro e inacessível para a maioria dos pacientes. Ainda assim, a pesquisa mostra uma tendência promissora: quanto mais dados são usados no treinamento, melhor fica o desempenho do decodificador, sem que tenha sido observado um platô claro de evolução até o momento.

O artigo publicado na Nature Neuroscience sobre o Brain2Qwerty v1 já indicava o potencial da abordagem. Naquele estudo, os pesquisadores demonstraram a decodificação de sentenças digitadas a partir de EEG e MEG em voluntários saudáveis. O desempenho com MEG foi muito superior ao EEG, com taxa média de erro de caracteres de 29% contra 65% no EEG, chegando a 18% de erro nos melhores participantes usando MEG.

A grande mudança da v2 está na aproximação com uma interface mais contínua e natural. Em vez de depender de marcações explícitas de cada tecla, o sistema tenta compreender a produção da frase diretamente a partir do fluxo da atividade cerebral. Isso coloca o Brain2Qwerty em uma categoria muito relevante para o futuro das neuropróteses: sistemas menos invasivos, mais escaláveis e potencialmente mais seguros.

Outro ponto importante é a abertura científica. O repositório oficial no GitHub disponibiliza código para as versões v1 e v2, com licença CC BY-NC 4.0, ou seja, com restrição para uso não comercial. O dataset da v1, coletado pelo BCBL, também foi disponibilizado no Hugging Face, enquanto o dataset da v2 permanece sob embargo até a aceitação do artigo correspondente.

Do ponto de vista tecnológico, o Brain2Qwerty mostra como a próxima geração de IA não estará limitada a texto, imagem, áudio ou vídeo. A fronteira agora avança para sinais biológicos. A IA passa a atuar como tradutora entre padrões neurais e linguagem humana. Isso abre portas para aplicações em acessibilidade, reabilitação, medicina, neurociência computacional e interfaces homem-máquina.

Mas esse tipo de tecnologia também exige responsabilidade. Decodificar sinais cerebrais envolve questões profundas de privacidade, consentimento, segurança e governança. Se hoje discutimos proteção de dados pessoais, amanhã discutiremos com ainda mais intensidade a proteção de dados neurais. O cérebro não pode ser tratado como mais uma fonte comum de dados. Ele representa uma camada extremamente sensível da identidade humana.

O Brain2Qwerty não é apenas um projeto de IA. Ele é um marco simbólico de uma nova fase: a convergência entre inteligência artificial, neurociência e computação de alto desempenho. Ainda há muitos obstáculos técnicos, clínicos e éticos pela frente, mas a direção é clara. A comunicação entre cérebro e máquina está deixando de ser uma promessa distante para se tornar uma área real de pesquisa aplicada.

No futuro, talvez teclados, telas e comandos de voz não sejam as únicas formas de interação com computadores. Projetos como o Brain2Qwerty indicam que poderemos construir interfaces capazes de compreender intenção, linguagem e pensamento motor de forma cada vez mais direta. O desafio será garantir que essa tecnologia seja desenvolvida com segurança, inclusão e respeito à autonomia humana.

Brain2Qwerty é um lembrete poderoso: a próxima grande revolução da inteligência artificial talvez não esteja apenas em máquinas que falam melhor, mas em sistemas capazes de devolver a voz a quem a perdeu.

Fontes:

https://github.com/facebookresearch/brain2qwerty
https://facebookresearch.github.io/brain2qwerty

Eesta semana, a comunidade de Inteligência Artificial recebeu uma surpresa fantástica: a empresa Z.A ai lançou oficialmente os pesos abertos (open weights) do seu novo modelo, o GLM 5.2. O lançamento incluiu tanto a versão completa quanto a versão FP8 do modelo. Essa é uma mudança de postura muito bem-vinda, já que, recentemente, diversos criadores de modelos chineses estavam hesitando em liberar os pesos, optando por oferecer apenas versões proprietárias por meio de APIs.

Com base em testes rigorosos e novos benchmarks, o GLM 5.2 não é apenas uma pequena atualização, mas sim uma ferramenta incrivelmente poderosa. Aqui estão os detalhes que você precisa saber sobre o porquê de este modelo estar chamando tanta atenção.

Desempenho de Ponta e Salto em Relação ao GLM 5.1 A evolução da versão 5.1 para a 5.2 é descrita como “enorme”, particularmente em tarefas complexas como programação e uso de agentes autônomos (agentic coding). O GLM 5.2 foi construído especificamente para tarefas de longo horizonte (“long horizon tasks”) e tem mostrado resultados esmagadores nos benchmarks da Artificial Analysis.

Para se ter uma ideia do seu poder, ele está superando modelos de peso como Deep Seek Pro, Quen 3.7 Max, Miniax M3 e até modelos proprietários fechados como o GPT 5.5. Nos rankings atuais de inteligência, o GLM 5.2 tem sido batido apenas pelo Opus 4.8 da Anthropic e pelo modelo Fable (que, vale ressaltar, não está mais disponível para a maioria do público e apresentava falhas sem o uso do Opus 4.8 como fallback). Além disso, o GLM 5.2 está se destacando no novo benchmark Deep Suite, que vem substituindo métricas mais antigas da indústria.

O Segredo: Longas Cadeias de Pensamento e Predição de Múltiplos Tokens O que faz o GLM 5.2 ser tão inteligente? Em grande parte, é a sua arquitetura voltada para longas cadeias de pensamento (long chains of thought). Enquanto laboratórios como OpenAI e Anthropic têm focado em obter alta inteligência com uma quantidade menor de tokens de saída, o GLM 5.2 vai na direção oposta: ele utiliza uma grande quantidade de tokens de raciocínio para refletir profundamente antes de responder. Ao lidar com quebra-cabeças de lógica, por exemplo, o modelo aumenta significativamente a quantidade de tokens de pensamento da maneira correta, demonstrando um verdadeiro raciocínio.

Apesar de gerar muitos tokens, o modelo não é lento. Graças à adoção da tecnologia de predição de múltiplos tokens (multi-token prediction), o GLM 5.2 se tornou muito mais rápido que seus antecessores. Em testes práticos utilizando a API do Open Router, a velocidade média de geração tem ficado entre 36 a 40 tokens por segundo.

Na prática, o modelo é capaz de entregar resultados onde muitos outros falham:

• Design de Interfaces (Front-End): O GLM 5.2 assumiu o primeiro lugar na “Design Arena”, superando até mesmo a família de modelos Claude

Em um teste solicitando a criação de uma página web complexa, o modelo gerou perfeitamente um site estilo Anthropic com mais de 8.000 tokens, contendo imagens embutidas e diversas animações interativas.Geração de Textos Extensos: Se você precisa de redações longas, o GLM 5.2 brilha. Enquanto modelos tradicionais frequentemente interrompem a geração ao redor de 500 palavras, o GLM 5.2 possui a capacidade de continuar escrevendo até superar a marca de 5.000 tokens gerados em uma única resposta.Capacidade Visual/Lógica (SVG): O modelo passou tranquilamente no teste de criar visualmente um “Pelicano andando de bicicleta” usando apenas código SVG.

Custo-Benefício Imbatível e Controle de Privacidade A abertura dos pesos do modelo também resolve uma preocupação crítica corporativa: privacidade de dados. Como o modelo é de código aberto (open weights), várias empresas (como a Together AI no futuro) poderão hospedá-lo. Isso significa que os desenvolvedores não são obrigados a enviar seus dados proprietários para data centers na China, podendo escolher provedores locais de sua confiança.

No quesito preço, o GLM 5.2 chega para quebrar o mercado. Ele está sendo disponibilizado por cerca de US 4,40 por milhão de tokens de saída. Esse valor é dramaticamente inferior aos planos pagos e aos custos de API dos modelos proprietários equivalentes no mercado atual.

Veredito: Vale a Pena? Com toda certeza. O GLM 5.2 surge como um substituto formidável e infinitamente mais barato para modelos comerciais que usamos rotineiramente, como o Gemini Flash.

Dica de Segurança: Se você for experimentar o modelo agora utilizando agregadores como o Open Router, certifique-se de verificar as políticas de privacidade da plataforma em relação à retenção dos seus prompts e dados para treinamento de outros modelos de terceiros. O GLM 5.2 já está provando que modelos abertos chegaram para competir de igual para igual e possivelmente ultrapassar os gigantes da indústria.

Até a próxima.

A Inteligência Artificial deixou de ser uma promessa distante para se tornar uma ferramenta concreta de transformação em áreas essenciais da sociedade. Na saúde, esse movimento é ainda mais relevante, porque envolve vidas, tempo de atendimento, qualidade na triagem, apoio aos profissionais e proteção de dados extremamente sensíveis. É nesse contexto que nasce a IA MED, uma solução desenvolvida pela MultiCortex para levar modelos avançados de linguagem ao setor de saúde com foco em precisão, privacidade, eficiência operacional e soberania tecnológica.

A IA MED já está em funcionamento na cidade de Bebedouro, interior de São Paulo, cidade natal de Alessandro de Oliveira Faria, também conhecido como Cabelo, fundador da MultiCortex. A implantação tem um significado especial: além de representar um avanço tecnológico para a rede municipal de saúde, simboliza o retorno de décadas de pesquisa, desenvolvimento e inovação para beneficiar diretamente a população da cidade onde nasceu o idealizador da solução.

Segundo publicação oficial da Prefeitura Municipal de Bebedouro, a tecnologia IAmed foi desenvolvida pelo bebedourense e tem como objetivo auxiliar os profissionais de saúde no dia a dia, contribuindo para mais agilidade, precisão e qualidade nos atendimentos prestados à população. A Prefeitura também informa que a ferramenta foi cedida gratuitamente ao município pela MultiCortex IA, com infraestrutura Magalu Cloud, para acelerar e fomentar o uso de IA na saúde pública local.

A proposta da IA MED parte de uma preocupação muito concreta: ferramentas genéricas de Inteligência Artificial generativa, especialmente aquelas hospedadas em nuvens internacionais, não foram concebidas originalmente para lidar com a complexidade, a responsabilidade e a sensibilidade dos dados de saúde pública brasileira. Em um ambiente clínico, dados pessoais, históricos médicos, sintomas, exames, hipóteses, encaminhamentos e informações familiares não podem ser tratados como simples entradas de texto em uma aplicação qualquer. Eles exigem governança, segurança, rastreabilidade, controle de acesso e conformidade com a legislação brasileira.

A Lei Geral de Proteção de Dados Pessoais, a LGPD, estabelece regras para o tratamento de dados pessoais, inclusive em meios digitais, com o objetivo de proteger direitos fundamentais como liberdade, privacidade e livre desenvolvimento da personalidade. A própria legislação brasileira classifica dados referentes à saúde como dados pessoais sensíveis, o que torna ainda mais importante a adoção de arquiteturas tecnológicas que reduzam exposição, transferência desnecessária e dependência de ambientes fora do controle da organização pública ou privada.

Por isso, a IA MED foi pensada como uma Inteligência Artificial privada, verticalizada e adequada ao contexto da saúde. Diferente de IAs genéricas, que tentam responder sobre qualquer assunto a partir de modelos amplos e de uso geral, a IA MED trabalha com modelos de linguagem especializados, ajustados para fluxos, protocolos, terminologias e necessidades do setor de saúde. Essa verticalização permite maior aderência ao domínio médico-assistencial e reduz a dependência de respostas genéricas, vagas ou pouco contextualizadas.

Na prática, isso significa que a IA MED não existe para substituir médicos, enfermeiros, técnicos ou gestores de saúde. Pelo contrário: ela foi criada para apoiar esses profissionais. O papel da Inteligência Artificial é atuar como uma camada de auxílio, ajudando na organização das informações, na análise de dados clínicos disponíveis, na identificação de riscos, na triagem de prioridades, na sugestão de caminhos com base em protocolos e na redução de tarefas burocráticas que consomem tempo das equipes.

Nas Unidades Básicas de Saúde, onde a demanda é constante e os profissionais precisam lidar com grande volume de atendimentos, a IA pode se tornar uma aliada estratégica. Ela pode ajudar a estruturar informações do paciente, facilitar o acesso ao histórico, apoiar a classificação de risco, sugerir perguntas relevantes durante uma triagem, organizar encaminhamentos e permitir que a equipe tenha uma visão mais clara do fluxo de atendimento. Com isso, o profissional de saúde ganha tempo, reduz carga mental e pode se concentrar mais no cuidado humano.

Essa é uma das maiores contribuições da IA MED: usar tecnologia não para afastar o paciente do profissional, mas para devolver tempo ao atendimento humanizado. A saúde pública enfrenta desafios diários de volume, urgência, documentação, filas, registros e priorização. Quando uma ferramenta de IA bem desenhada assume parte do trabalho repetitivo e auxilia na organização das informações, ela contribui para que médicos e enfermeiros possam tomar decisões com mais segurança e menos sobrecarga.

Outro diferencial importante da IA MED está no custo computacional. Muitos projetos de Inteligência Artificial são inviabilizados porque dependem de servidores extremamente caros, como máquinas baseadas em GPUs H100 ou B200, que podem representar investimentos muito altos em infraestrutura. A proposta da MultiCortex é demonstrar que, com engenharia especializada, otimização de modelos, verticalização e uso inteligente de hardware, é possível entregar uma solução de IA aplicada à saúde utilizando infraestrutura com custo muito inferior na ordem de aproximadamente 10% do valor de grandes servidores baseados nessas GPUs topo de linha (GRAÇAS A COMPUTAÇÃO HETEROGÊNEA).

Essa diferença de custo é fundamental para a realidade brasileira. A inovação não pode ficar restrita a grandes centros, grandes hospitais ou instituições com orçamentos milionários. A Inteligência Artificial precisa ser viável para municípios, unidades públicas, clínicas, secretarias e organizações que buscam modernização, mas precisam respeitar limites financeiros. A IA MED nasce justamente dessa visão: criar uma tecnologia de alto impacto, com custo mais acessível e aplicação prática no cotidiano da saúde

A parceria com a Magalu Cloud reforça outro ponto central do projeto: a soberania dos dados. A Magalu Cloud se apresenta como uma nuvem brasileira, com preços em reais, suporte em português, infraestrutura local e data centers fisicamente no Brasil, distribuídos nas regiões Sudeste e Nordeste. A empresa também destaca que os dados são armazenados localmente e em conformidade com a legislação brasileira.

Para aplicações de saúde, esse detalhe é decisivo. Utilizar infraestrutura em território nacional reduz riscos associados à transferência internacional de dados, melhora a previsibilidade regulatória e aproxima a operação da realidade jurídica, técnica e institucional do Brasil. Em vez de depender exclusivamente de nuvens estrangeiras, cobradas em dólar e sujeitas a camadas adicionais de complexidade contratual e regulatória, a IA MED utiliza uma infraestrutura alinhada ao conceito de soberania digital.

A Magalu Cloud também destaca benefícios como preços em reais, previsibilidade sem variação cambial, suporte humano em português, infraestrutura local, baixa latência, custos reduzidos, escalabilidade e serviços como máquinas virtuais, armazenamento, VPC, Kubernetes, banco de dados e ferramentas de identidade e acesso. Para um projeto como a IA MED, esses elementos ajudam a compor uma base tecnológica mais adequada para o setor público brasileiro.

Além da privacidade, há também a questão da previsibilidade de custos. Muitas soluções de IA em nuvem funcionam com cobrança baseada em tokens, o que pode se tornar um problema quando há grande volume de atendimentos, consultas, registros e interações. Em ambientes públicos, onde orçamento precisa ser planejado e justificado, custos variáveis e imprevisíveis podem dificultar a adoção em escala. A IA MED busca reduzir esse problema ao operar em uma arquitetura mais controlada, privada e otimizada, sem depender do modelo tradicional de cobrança por token de plataformas externas.

Essa abordagem permite que a Inteligência Artificial deixe de ser uma despesa imprevisível e passe a ser uma infraestrutura estratégica. Em vez de pagar indefinidamente por cada interação processada em serviços de terceiros, a organização pode trabalhar com um ambiente mais previsível, controlado e adaptado à sua demanda. Para a saúde pública, isso significa maior capacidade de planejamento, menor dependência externa e mais sustentabilidade para expandir o uso da tecnologia.

O impacto para a população pode ser percebido de várias formas. O cidadão tende a se beneficiar de atendimentos mais organizados, triagens mais ágeis, melhor acompanhamento, redução de retrabalho e maior apoio à identificação de prioridades. Em muitos casos, a diferença não estará apenas em “usar IA”, mas em usar IA para melhorar processos invisíveis que afetam diretamente a experiência do paciente: tempo de espera, clareza das informações, encaminhamentos, continuidade do cuidado e segurança no atendimento.

Para os profissionais de saúde, a IA MED representa uma ferramenta de apoio em um cenário de alta responsabilidade. O cansaço mental, a pressão por produtividade, a repetição de tarefas administrativas e o volume de informações podem aumentar a margem de erro em qualquer setor. Na saúde, porém, erros podem ter consequências graves. A Inteligência Artificial, quando aplicada com responsabilidade, pode ajudar a mitigar riscos, organizar dados e apoiar decisões, sempre mantendo o profissional humano no centro do processo.

A iniciativa em Bebedouro também carrega um valor simbólico importante. Ver uma tecnologia criada por um bebedourense sendo aplicada diretamente em benefício da população local mostra que inovação não precisa nascer apenas em polos internacionais ou grandes capitais. A inovação também pode surgir do interior, de trajetórias individuais de pesquisa, de comunidades técnicas brasileiras e de empresas que entendem os desafios reais do país.

Para Alessandro de Oliveira Faria, a implantação da IA MED em Bebedouro representa mais do que um projeto tecnológico. É o resultado de mais de 25 anos de pesquisa em Inteligência Artificial, iniciada ainda em 1998, somada a uma trajetória dedicada à computação de alto desempenho, otimização de hardware, software livre e aplicação prática da tecnologia em benefício da sociedade. Levar essa experiência para a saúde pública da sua cidade natal é uma forma de transformar conhecimento acumulado em impacto social direto.

Durante a fase de avaliação, a MultiCortex disponibilizou o sistema gratuitamente ao município de Bebedouro por meio de um termo de cooperação com a Prefeitura. A empresa assumiu integralmente os custos computacionais em nuvem, reforçando o compromisso de manter Bebedouro na vanguarda da inovação tecnológica. A iniciativa remete ao histórico da cidade com projetos pioneiros de tecnologia, como ocorreu no início dos anos 2000 com a implantação da biometria de impressão digital.

Esse ponto é essencial: inovação pública não acontece apenas quando se compra tecnologia pronta. Ela acontece quando há colaboração entre poder público, empresas, pesquisadores, profissionais técnicos e a comunidade. Ao ceder a IA MED gratuitamente na fase de avaliação, a MultiCortex cria uma oportunidade concreta para que a cidade experimente, valide e compreenda os benefícios da Inteligência Artificial aplicada à saúde de forma segura, responsável e alinhada à realidade local.

A IA MED também reforça uma visão maior da MultiCortex: devolver às organizações o controle sobre sua própria Inteligência Artificial. No setor da saúde, esse controle é ainda mais importante. Não se trata apenas de desempenho técnico, mas de governança, soberania, privacidade e responsabilidade. Uma IA aplicada à saúde precisa respeitar dados, pessoas, profissionais e instituições. Precisa ser explicável dentro do possível, auditável, segura e construída para o contexto em que será usada.

Ao unir modelos de LLM verticalizados, infraestrutura nacional, custo computacional reduzido, privacidade e foco no apoio aos profissionais de saúde, a IA MED se posiciona como uma alternativa brasileira para um dos maiores desafios da atualidade: como usar Inteligência Artificial em áreas sensíveis sem abrir mão da segurança, da ética e da soberania dos dados.

Bebedouro, ao receber essa implantação, dá um passo importante rumo à modernização dos serviços públicos de saúde. A iniciativa mostra que a tecnologia pode ser uma aliada direta do cuidado, não apenas uma ferramenta distante de laboratório. Mostra também que a IA pode ser aplicada de forma responsável, com foco em pessoas, em eficiência pública e na valorização dos profissionais que estão na linha de frente.

A IA MED nasce com esse propósito: transformar a Inteligência Artificial em uma infraestrutura confiável para a saúde, capaz de apoiar decisões, otimizar processos, reduzir custos e proteger dados sensíveis. Mais do que uma ferramenta tecnológica, ela representa uma visão de futuro para a saúde pública brasileira, um futuro em que inovação, privacidade, soberania e cuidado humano caminham juntos.

A Inteligência Artificial já consegue conversar, transcrever áudio, narrar livros, atender clientes e criar assistentes de voz. Mas existe um problema que ainda passa despercebido: muitas dessas tecnologias não entendem o Brasil como ele realmente fala. O português brasileiro não é uma voz única, neutra e padronizada. Ele é caipira, baiano, nortista, gaúcho, mineiro, carioca, paulistano, nordestino, amazônico, interiorano, urbano e profundamente diverso.

É exatamente para enfrentar esse desafio que nasce o SOTAQUE — Speech-Oriented Training Audio for Quality Understanding and Expression, uma iniciativa voltada à criação de um dataset aberto de vozes em português brasileiro, com foco na diversidade regional dos sotaques do país. A proposta é simples e poderosa: reunir vozes reais de brasileiros para que tecnologias de fala, como assistentes virtuais, audiobooks, sistemas de transcrição automática e modelos de voz, consigam representar melhor a pluralidade do nosso idioma.

Meus mais sinceros
parabéns Fabrício Carraro!

Hoje, muitos modelos de fala em português ainda são treinados com pouca diversidade de vozes, muitas vezes concentradas em sotaques urbanos do Sudeste, especialmente paulistano e carioca. Isso faz com que uma IA fale português de forma artificialmente neutra e, em alguns casos, tenha dificuldade para compreender pessoas com sotaques regionais mais marcados. O resultado é uma tecnologia que funciona melhor para alguns brasileiros do que para outros

O SOTAQUE quer mudar essa realidade por meio de uma construção coletiva. A ideia é criar uma base pública, documentada e aberta, feita com contribuições voluntárias da comunidade. Cada pessoa pode ajudar enviando um áudio com sua própria voz e respondendo algumas perguntas rápidas sobre seu perfil linguístico, como região onde cresceu, estado, sotaque declarado e faixa etária. O processo leva poucos minutos e pode ser feito com uma gravação nova ou até com um áudio antigo, desde que respeite as regras do projeto.

A importância desse projeto vai além da tecnologia. Ele toca em representatividade linguística. Quando um sotaque fica fora dos datasets, milhões de pessoas também ficam menos representadas nas ferramentas digitais que escutam, falam, transcrevem e interagem em português. Ter uma IA que entende melhor o Brasil é também garantir que a inovação não apague as nossas diferenças regionais, mas aprenda com elas.

Outro ponto relevante é que o projeto nasce com uma proposta aberta. As gravações, transcrições e metadados autorizados serão publicados com licença CDLA-Permissive-2.0, permitindo uso amplo por pesquisadores, startups, escolas, criadores de conteúdo e desenvolvedores interessados em tecnologias de fala em português brasileiro. A meta inicial do projeto é alcançar 1.000 horas de áudio coletado e curado, com uma meta final de 10.000 horas.

Naturalmente, quando falamos de voz, também falamos de privacidade. O próprio termo do projeto deixa claro que a participação é voluntária, restrita a maiores de 18 anos localizados no Brasil no momento da contribuição, e que a pessoa deve contribuir apenas com a própria voz. Também é importante evitar áudios com dados pessoais de terceiros, senhas, informações financeiras ou qualquer conteúdo sensível.

O SOTAQUE é uma oportunidade para a comunidade brasileira participar diretamente da construção de tecnologias mais justas, abertas e representativas. Em vez de esperar que grandes empresas definam sozinhas como a IA deve falar português, podemos contribuir com a nossa própria voz para que os próximos modelos entendam melhor quem somos, de onde viemos e como falamos.

Contribuir é simples, vá até a página Contribuir e envie um áudio com sua voz (Leva uns 2 minutos: granvando um áudio, conta um pouco sobre você, marca o consentimento. Pronto), ajude a construir um dataset aberto que pode beneficiar toda a comunidade de IA, educação, acessibilidade, pesquisa e inovação no Brasil. A sua voz tem valor. O seu sotaque também.

Mais informações aqui: https://sotaque.ia.br/

O AutoRound (https://github.com/intel/auto-round) é uma ferramenta de quantização para LLMs e VLMs desenvolvida pela Intel. A ideia central é reduzir o modelo para 2, 3, 4 ou 8 bits, mantendo boa precisão, principalmente em cenários de low-bit weight-only quantization (converte os pesos mas manter a inferência), como W4A16, W3A16 e W2A16. O próprio repositório descreve o AutoRound como um toolkit para LLMs/VLMs que usa signed gradient descent para obter alta acurácia em 2–4 bits com baixo custo de ajuste.

Como Intel Innovator, tenho a missão mostrar o compromisso sério da Intel neste vertical tecnológica. A tecnologia beneficia GPU NVIDIA, CPU e XPU

Em termos simples: ele não apenas “arredonda” os pesos para 4 bits como um método ingênuo faria. Ele aprende a melhor forma de arredondar os pesos e também ajusta os limites de clipping para reduzir o erro entre a saída do bloco original e a saída do bloco quantizado. O paper do SignRound (https://arxiv.org/html/2309.05516v3) explica que o método adiciona parâmetros treináveis para ajustar o rounding e dois parâmetros extras para ajustar o clipping dos pesos; depois usa reconstrução por bloco e otimização com SignSGD.

Como ele funciona

O fluxo é mais ou menos assim:

1. Você passa um modelo Hugging Face, por exemplo Qwen/Qwen3-0.6B, Llama, Mistral, etc.
2. Ele usa um dataset de calibração. Por padrão, usa NeelNanda/pile-10k, mas aceita datasets customizados, JSON local, lista de strings, input ids, concatenação de datasets e aplicação de chat template.
3. Para cada bloco/camada, ele compara a saída do modelo original com a saída do modelo quantizado.
4. Ele otimiza o rounding dos pesos e o range de clipping usando signed gradient descent.
5. No final, salva o modelo em um formato escolhido: auto_round, auto_gptq, auto_awq, gguf, llm_compressor, mlx, entre outros.

Como usar?

pip install auto-round
auto-round \
--model Qwen/Qwen3-0.6B \
--scheme "W4A16" \
--format "auto_round" \
--output_dir ./qwen_autoround_w4a16

Para exportar para GGUF:

auto-round \
--model Qwen/Qwen3-0.6B \
--format "gguf:q4_k_m" \
--output_dir ./qwen_gguf_q4_k_m

O repositório mostra instalação via pip install auto-round, suporte a CPU/GPU CUDA, Intel XPU e Gaudi/HPU, além de exemplos com Qwen/Qwen3-0.6B

O que significa W4A16, W3A16, W2A16

W4A16 significa:

O AutoRound documenta esquemas como W4A16, W8A16, W3A16, W2A16, mixed bits, GGUF, NVFP4, MXFP4, FP8 e outros.

Na prática, W4A16 costuma ser o ponto mais seguro: boa redução de memória com perda pequena. W2A16 é muito mais agressivo: pode reduzir muito mais o tamanho dos pesos, mas exige algoritmo melhor, calibração melhor e validação forte.

Diferença para GPTQ, AWQ, SmoothQuant, bitsandbytes e GGUF

GPTQ se baseia em quantização weight-only com informação aproximada de segunda ordem e mostrou bons resultados em 3/4 bits em modelos grandes. AWQ usa estatísticas de ativação para proteger canais salientes e evitar quantização mista ineficiente, sem backpropagation ou reconstrução. SmoothQuant é uma abordagem PTQ para W8A8, suavizando outliers de ativação por uma transformação matematicamente equivalente entre ativações e pesos. bitsandbytes fornece camadas quantizadas 8-bit/4-bit, otimizadores 8-bit, LLM.int8() e QLoRA com NF4 para reduzir uso de memória.

Vantagens do AutoRound

A grande vantagem é que ele tenta entregar mais qualidade em baixa precisão, principalmente em 2, 3, 4 e 8 bits, onde métodos simples como RTN geralmente degradam bastante. No paper original, os autores comparam com GPTQ, AWQ, HQQ, OmniQuant e RTN, e relatam ganhos maiores conforme os bits diminuem, especialmente em W2G128, com melhorias absolutas de acurácia média entre 6,91% e 33,22% em 11 tarefas zero-shot.

Outra vantagem é a compatibilidade de ecossistema: o AutoRound suporta exportação para auto_round, auto_gptq, auto_awq, gguf, llm_compressor e mlx, além de integração com Transformers, vLLM e SGLang.

Dicas:

# equilíbrio entre qualidade e custo
auto-round --model Qwen/Qwen3-0.6B --scheme "W4A16"
# melhor qualidade, mais lento
auto-round-best --model Qwen/Qwen3-0.6B --scheme "W4A16"
# mais rápido, com possível perda de acurácia
auto-round-light --model Qwen/Qwen3-0.6B --scheme "W4A16"

A documentação recomenda auto-round como bom equilíbrio geral, auto-round-best para melhor acurácia — especialmente 2-bit — e auto-round-light para velocidade, mais indicado em 4-bit e modelos maiores que 3B.

O AutoRound não elimina a necessidade de benchmark real. Quantização muda o comportamento do modelo, e a perda pode aparecer em raciocínio, código, português, instruções longas ou domínios específicos. Para um modelo que você usa em produção, eu validaria pelo menos:

# exemplo conceitual
lm_eval \
--model hf \
--model_args pretrained=./qwen_autoround_w4a16 \
--tasks hellaswag,arc_challenge,mmlu,truthfulqa \
--batch_size auto

Também é importante entender que W4A16 quantiza principalmente os pesos, mantendo ativações em 16 bits. Isso reduz muito o tamanho do modelo, mas não resolve sozinho todos os gargalos, por exemplo KV-cache em contextos longos. O paper original deixa claro que o foco experimental era weight-only quantization em camadas lineares dos blocos transformer.

Outro ponto: alguns esquemas novos, como MXFP4/MXINT4/MXFP8, aparecem na documentação como recursos de pesquisa ou sem kernel real em certos casos; então o formato escolhido precisa casar com o runtime que você vai usar.

Minha leitura particular: AutoRound é uma das opções mais interessantes hoje para quantização low-bit de LLMs quando qualidade importa mais do que apenas velocidade de conversão. Para W4A16, eu testaria como alternativa séria a GPTQ/AWQ. Para W2A16, eu priorizaria AutoRound/SignRound, mas sempre com avaliação no seu conjunto de tarefas.

Código fonte: https://github.com/intel/auto-round

Copy Fail (CVE-2026-31431) é uma vulnerabilidade de escalonamento local de privilégio no kernel Linux QUE TOMOU CONTA DAS REDES SOCIAIS. Ela foi divulgada publicamente em 29 de abril de 2026 e está ligada ao subsistema criptográfico do kernel, especialmente à interface AF_ALG / algif_aead e ao template criptográfico authencesn. Em termos práticos: um usuário local sem privilégios pode abusar de uma falha lógica para fazer uma escrita controlada de poucos bytes no page cache de um arquivo legível e, a partir disso, alterar o comportamento de binários privilegiados para obter root.

O conceito central é que o kernel permite que programas em userspace usem algoritmos criptográficos via sockets AF_ALG. A falha apareceu em uma lógica de operação “in-place” em AEAD, isto é, quando a origem e o destino da operação criptográfica são tratados de forma inadequada como se pudessem compartilhar o mesmo espaço/mapeamento. O patch oficial basicamente remove essa complexidade e volta a operar “out-of-place”, porque não havia benefício real em operar in-place nesse caso.

O nome Copy Fail vem justamente dessa ideia: uma cópia que deveria cair em um destino seguro acaba afetando um local errado/controlável. A exploração pública descreve uma cadeia envolvendo AF_ALG, splice(), page cache e uma escrita controlada de 4 bytes em arquivo legível. Isso é perigoso porque muitos binários privilegiados do sistema, como su, sudo, pkexec, passwd, mount, chsh e chfn, normalmente são executáveis setuid-root e, em várias distribuições, também são legíveis por usuários comuns.

O impacto é alto porque não é uma exploração remota: o atacante precisa ter acesso local ao sistema, por exemplo uma conta shell, usuário em servidor compartilhado, container mal isolado ou ambiente multiusuário. Mas, uma vez dentro, a falha pode permitir virar root sem depender de race condition, offsets específicos por distribuição ou tentativas instáveis. Os pesquisadores afirmam ter testado em Ubuntu, Amazon Linux, RHEL e SUSE, incluindo SUSE 16.

Nós como membros da OWASP Capítulo São Paulo, temos a missão de ajudar a mitigar este problema…

A mitigação principal e correta é atualizar o kernel para uma versão que contenha o patch/revert de algif_aead. A mitigação com chmod é uma defesa emergencial: ela reduz a superfície de ataque removendo permissão de leitura de binários setuid sensíveis, mantendo a execução e o bit setuid. Então abaixo o comando de autoria do Raphael Bastos A.K.A. coffnix para executar o chmod removendo o direito de leitura dos comandos passwd chsh chfn mount sudo pkexec

for b in passwd chsh chfn mount sudo su pkexec; 
   do p=$(readlink -f "$(command -v "$b")"); 
   [ -n "$p" ] && chmod 4711 "$p"; done

O brinquedo funciona assim: ele percorre a lista de binários sensíveis (passwd, chsh, chfn, mount, sudo, pkexec), encontra o caminho real de cada um com command -v e readlink -f, e aplica chmod 4711 no arquivo encontrado.

O modo 4711 significa:

4 = ativa o bit setuid
7 = dono/root pode ler, escrever e executar
1 = grupo só pode executar
1 = outros usuários só podem executar

Ou seja, o binário continua funcionando como setuid-root, mas deixa de ser legível por usuários comuns. Como a exploração depende de atingir arquivos legíveis no page cache, remover a permissão de leitura desses binários dificulta ou bloqueia essa cadeia específica contra esses alvos.

Em sistemas de produção, eu usaria assim:

sudo sh -c 'for b in passwd chsh chfn mount sudo pkexec; do p=$(readlink -f "$(command -v "$b")"); [ -n "$p" ] && chmod 4711 "$p"; done'

Depois valide:

ls -l /usr/bin/passwd /usr/bin/chsh /usr/bin/chfn /usr/bin/mount /usr/bin/sudo /usr/bin/pkexec

Você deve ver algo parecido com:

-rws--x--x root root ...

Resumo: patch de kernel é a correção real; chmod 4711 nos binários setuid é uma mitigação rápida para reduzir o alvo explorável enquanto o kernel corrigido não é aplicado.

O lançamento do Origin Pilot representa um marco importante na evolução da computação quântica, não apenas pelo avanço tecnológico em si, mas pela mudança estratégica que propõe na forma como sistemas quânticos são desenvolvidos, integrados e disponibilizados ao mundo. Trata-se de uma iniciativa que vai além das tradicionais bibliotecas ou frameworks de programação quântica, posicionando-se como uma camada fundamental da infraestrutura, o sistema operacional responsável por orquestrar toda a interação entre hardware quântico e sistemas clássicos.

O Origin Pilot, desenvolvido pela empresa chinesa Origin Quantum, foi disponibilizado publicamente como software open source, algo inédito no contexto de sistemas operacionais quânticos. Essa abertura marca uma ruptura com o modelo tradicional, onde o controle do stack tecnológico quântico desde o hardware até o software permanece fechado e altamente proprietário. Ao permitir o download e uso livre do sistema, a iniciativa busca reduzir barreiras de entrada e acelerar a adoção global da computação quântica, especialmente por universidades, startups e centros de pesquisa que não possuem infraestrutura completa própria.

Diferentemente de ferramentas como Qiskit ou Cirq, que operam em níveis mais altos da pilha tecnológica, o Origin Pilot atua em uma camada mais profunda: a de integração e gerenciamento do sistema. Ele funciona como um intermediário entre diferentes tipos de hardware quântico como qubits supercondutores, íons aprisionados e átomos neutros e os aplicativos desenvolvidos pelos usuários. Essa abordagem permite a criação de um ambiente unificado capaz de lidar com a heterogeneidade dos dispositivos quânticos, um dos maiores desafios atuais da área.

Do ponto de vista técnico, o sistema incorpora funcionalidades essenciais para o funcionamento eficiente de computadores quânticos. Entre elas estão o agendamento de tarefas quânticas, a alocação de qubits, a calibração automática dos sistemas e a execução paralela de múltiplos programas quânticos. Essas capacidades são críticas em ambientes NISQ (Noisy Intermediate-Scale Quantum), onde os recursos são limitados e altamente sensíveis a erros. O Origin Pilot também promove a integração entre computação clássica e quântica, permitindo pipelines híbridos que combinam CPUs, GPUs e QPUs em um mesmo fluxo de processamento.

Outro aspecto relevante é a capacidade do sistema de lidar com problemas específicos da computação quântica que não existem no mundo clássico. Questões como decoerência, ruído quântico e necessidade constante de recalibração exigem mecanismos sofisticados de controle em tempo real. O Origin Pilot incorpora algoritmos e estratégias voltadas para esses desafios, como o mapeamento eficiente de qubits e a otimização da fidelidade dos circuitos quânticos, garantindo melhor aproveitamento dos recursos disponíveis.

A proposta do Origin Pilot também carrega implicações estratégicas e geopolíticas. Ao disponibilizar gratuitamente uma camada de integração que ainda não possui equivalente aberto no Ocidente, a China pode influenciar diretamente o padrão de desenvolvimento global da computação quântica. Instituições ao redor do mundo podem optar por adotar esse sistema como base para seus projetos, o que, ao longo do tempo, cria um ecossistema dependente das abstrações, interfaces e arquiteturas definidas pela plataforma. Essa dinâmica lembra movimentos recentes no campo da inteligência artificial, onde a abertura de modelos e ferramentas levou à rápida expansão de determinados ecossistemas tecnológicos.

Além disso, o Origin Pilot faz parte de um esforço mais amplo de construção de uma infraestrutura quântica completa, que inclui hardware próprio, plataformas de nuvem quântica e ferramentas de desenvolvimento. Essa abordagem verticalizada busca reduzir a dependência de tecnologias estrangeiras e consolidar uma cadeia de valor autossuficiente. A disponibilização do sistema operacional como open source não apenas fortalece essa estratégia, mas também posiciona o país como um potencial definidor de padrões tecnológicos na próxima geração da computação.

Do ponto de vista do desenvolvedor, o impacto pode ser significativo. A existência de um sistema operacional quântico acessível permite experimentar com arquiteturas completas, sem a necessidade de construir toda a camada de integração do zero. Isso pode acelerar o desenvolvimento de aplicações práticas em áreas como criptografia, otimização, simulação de materiais e inteligência artificial quântica. Ao mesmo tempo, cria-se um novo paradigma de desenvolvimento, onde entender o comportamento do hardware e sua interação com o software passa a ser tão importante quanto escrever algoritmos quânticos.

Em síntese, o Origin Pilot não deve ser visto apenas como mais uma ferramenta no ecossistema quântico, mas como um passo em direção à maturidade da computação quântica como plataforma.

Assim como os sistemas operacionais clássicos foram fundamentais para a popularização dos computadores pessoais, iniciativas como essa podem desempenhar papel semelhante no futuro da computação quântica, definindo como os sistemas serão construídos, utilizados e evoluídos nas próximas décadas.

Referências:
https://www.globaltimes.cn/page/202602/1355718.shtml
https://postquantum.com/quantum-computing/china-quantum-os-origin-pilot/
https://medium.com/%40noahbean3396/quantum-computers-need-a-new-kind-of-operating-system-the-first-generation-just-arrived-aeeaa0c9bb60
https://en.chinadiplomacy.org.cn/2026-03/19/content_118390706.shtml

Download: https://qcloud.originqc.com.cn/en/programming/pilotos

A evolução da inferência de IA em hardware Intel continua em ritmo acelerado, e o lançamento do OpenVINO 2026.1 consolida mais um avanço importante nessa jornada. Se a versão 2026.0 já havia estabelecido um novo patamar com suporte a Mixture of Experts (MoE), pipelines de Text-to-Video e técnicas mais inteligentes de compressão, a nova versão vai além: amplia significativamente o suporte a modelos, melhora a eficiência operacional e reforça o posicionamento do OpenVINO como uma das principais plataformas para inferência de IA em ambientes reais.

Mais do que uma atualização incremental, o OpenVINO 2026.1 representa uma resposta direta às demandas atuais do mercado: modelos maiores, workloads multimodais e a necessidade constante de reduzir latência sem comprometer qualidade.

Expansão de Modelos: Escalando a IA com Flexibilidade

Um dos pontos mais relevantes desta versão é a ampliação do suporte a modelos de grande porte e multimodais. O destaque vai para o suporte em CPU ao GPT-OSS 120B, um salto expressivo em relação à versão anterior (20B). Isso muda o jogo para organizações que precisam rodar modelos massivos sem depender exclusivamente de GPUs de alto custo.

Além disso, o suporte ao Qwen3 VL em CPU e GPU abre novas possibilidades para aplicações avançadas de visão computacional combinada com linguagem natural. Estamos falando de casos de uso como:

• Análise inteligente de imagens e vídeos
• Geração automática de descrições visuais
• Processamento documental com entendimento semântico
• Raciocínio multimodal em tempo real

Outro avanço importante está no OpenVINO Model Server, que agora suporta melhor modelos como Qwen3-MoE e GPT-OSS-20B. Com isso, há ganhos diretos em:

• Throughput via continuous batching
• Melhor uso de recursos em ambientes concorrentes
• Maior estabilidade em cenários de produção

E não para por aí: a introdução de endpoints de imagem com suporte a inpainting e outpainting leva o Model Server para além da inferência textual, entrando definitivamente no território da IA generativa visual.

LoRA Dinâmico e IA Multimodal: Eficiência em Escala

A adoção de LoRA dinâmico para modelos de visão e linguagem é um divisor de águas. Com suporte ao Qwen3-VL, o OpenVINO permite trocar adaptadores em tempo de execução sem recarregar o modelo base.

Na prática, isso resolve um problema crítico em produção: como servir múltiplas variações de um modelo sem multiplicar o consumo de memória e tempo de inicialização. O resultado é:

• Menor latência operacional
• Redução de custo de infraestrutura
• Maior flexibilidade para personalização de modelos

Outro ponto extremamente relevante é o novo notebook de referência que integra múltiplos VLMs, incluindo:

• Qwen2.5-VL
• LLaVA-Next-Video

Esse ambiente unificado permite explorar chatbots multimodais com suporte a vídeo e alternância dinâmica de modelos algo essencial para experimentação e benchmarking em cenários reais.

Performance: Onde o OpenVINO Realmente Brilha

Se há um ponto onde o OpenVINO tradicionalmente se destaca, é na otimização de performance e a versão 2026.1 reforça isso com avanços consistentes.

1. TaylorSeer Lite Caching

A introdução do caching TaylorSeer Lite para pipelines de difusão (como Flux, SD3 e LTX-Video) reduz computações redundantes durante o processo de denoising. Isso resulta em:

• Geração mais rápida de imagens e vídeos
• Menor consumo computacional
• Manutenção da qualidade do output

2. Otimizações em Vídeo (LTX-Video)

A fusão de operadores como RMSNorm e RoPE em um único kernel elimina overhead de execução sequencial. Esse tipo de otimização de baixo nível traz ganhos significativos:

• Redução de latência de kernel
• Menor uso de memória
• Aumento expressivo no throughput

3. Prompt Lookup Decoding

A extensão dessa técnica para pipelines multimodais é um dos avanços mais interessantes. Ao reutilizar padrões de tokens já processados, o sistema reduz a carga no modelo principal, acelerando a geração de tokens.

Isso é particularmente relevante para:

• Chatbots multimodais
• Assistentes com contexto longo
• Sistemas de análise documental

Um Novo Patamar para Inferência em Hardware Intel

O OpenVINO 2026.1 deixa claro que a estratégia da Intel não é apenas competir é redefinir o espaço de inferência eficiente. Ao permitir que modelos massivos rodem em CPU, otimizar pipelines multimodais e introduzir mecanismos inteligentes de caching e decoding, a plataforma se posiciona como uma solução altamente pragmática para empresas.

Em um cenário onde custo, performance e escalabilidade precisam coexistir, o OpenVINO oferece uma proposta extremamente equilibrada.

Para quem trabalha com IA aplicada seja em edge, cloud ou ambientes híbridos essa versão não é apenas uma atualização. É um convite para repensar arquitetura, otimizar pipelines e explorar novas possibilidades com modelos cada vez mais complexos.

Conclusão

O OpenVINO 2026.1 representa um avanço sólido na democratização da IA de alto desempenho. Com mais modelos, melhor suporte multimodal e otimizações profundas de performance, a plataforma continua evoluindo para atender às demandas reais do mercado.

Se você está construindo soluções com LLMs, VLMs ou pipelines generativos, este é o momento ideal para explorar o que há de novo e, principalmente, para extrair o máximo desempenho do hardware Intel com inteligência.

A próxima geração da IA não será apenas mais poderosa , será mais eficiente. E o OpenVINO está claramente liderando esse movimento.

O Zupt é uma ferramenta open source de backup que combina compressao de dados com criptografia autenticada e, no modo --pq, proteção pós-quântica baseada em ML-KEM-768 + X25519. No repositório oficial, o projeto é descrito como uma solução em C11 puro, sem dependências externas, voltada para criar arquivos de backup comprimidos e, quando necessário, protegidos com criptografia clássica por senha ou com encapsulamento híbrido resistente ao cenário de computação quântica.

O projeto teve início com a implementação em C desenvolvida por Cristian Cezar Moises.

Como Membro e Embaixador openSUSE e Chapter Lider OWASP SP, entrei na iniciativa para viabilizar sua compilação em conformidade com os requisitos de compliance das distribuições Linux.

Além de atuar no port para as arquiteturas x86, ppc64le, armv7l, aarch64 e s390x. Esta primeira etapa está sendo realizada no openSUSE, permitindo que o DiraQ (um Linux de bolso para Computação Quântica que desenvolvi com Wilson Fonseca ) já incorpore esse recurso, cuja demonstração acontecerá no UNISO Quantum Day dia 7 de Abril.

A ideia central do Zupt é simples: transformar backup em um único fluxo operacional. Em vez de usar uma ferramenta para compactar, outra para cifrar e outra para validar integridade, o Zupt concentra tudo em um só utilitário. O projeto destaca compressão, autenticação por bloco, execução multithread, ocultação de nomes/estrutura dos arquivos dentro do archive e um modo pós-quântico para arquivos que precisam continuar confidenciais por muitos anos.

OK, mas o que significa “pós-quântico” no Zupt

Para entender o diferencial do Zupt, é importante entender o papel do ML-KEM. O NIST define ML-KEM em seu padrão FIPS 203 como um KEM (Key-Encapsulation Mechanism), isto é, um mecanismo de encapsulamento de chave que permite a duas partes estabelecerem um segredo compartilhado por um canal público, para depois usar esse segredo em algoritmos simétricos de criptografia e autenticação. O padrão prevê três conjuntos de parâmetros: ML-KEM-512, ML-KEM-768 e ML-KEM-1024. (Fonte NIST)

No Zupt, o modo --pq usa especificamente o ML-KEM-768, que o próprio SECURITY.md classifica como um esquema de nível de segurança NIST 3, combinado com X25519 em um desenho híbrido. Em outras palavras, o archive não depende só de um algoritmo “novo” pós-quântico, nem só de um algoritmo clássico consagrado: ele deriva a chave de proteção a partir da combinação dos dois. Isso torna o modelo particularmente interessante para migração gradual, porque ele mantém a robustez clássica e adiciona uma camada pensada para a ameaça quântica.

O repositório resume esse benefício com a expressão “harvest now, decrypt later”. Esse risco descreve o cenário em que um adversário intercepta dados cifrados hoje, armazena tudo e espera o futuro, quando a computação quântica ou novos ataques possam quebrar mecanismos clássicos.

O README do Zupt diz explicitamente que o modo --pq existe para enfrentar esse problema; o SECURITY.md reforça que o modo com senha (-p) não é quântico-seguro e recomenda --pq para proteção de longo prazo.

Quando o projeto afirma que essa ideia segue a mesma linha de produtos como Signal e iMessage, a comparação faz sentido no nível conceitual: o Signal documenta seu protocolo PQXDH como uma combinação de X25519 com Kyber/ML-KEM, e a Apple também descreve sua transição para criptografia híbrida pós-quântica no iMessage/PQ3 como resposta ao risco de ataques futuros contra material coletado hoje. O ponto principal não é que Zupt replique literalmente esses protocolos de mensageria, mas que ele adota a mesma filosofia de hibridização entre o mundo clássico e o pós-quântico. (Fonte Signal)

Como o modo --pq funciona na prática

O fluxo híbrido do Zupt funciona assim: a chave pública do destinatário é usada em uma encapsulação ML-KEM-768; ao mesmo tempo, o programa faz uma troca baseada em X25519; depois, os segredos resultantes são combinados e passam por SHA3-512 para derivar duas chaves: uma de cifragem e outra de autenticação. Essas chaves então alimentam o mecanismo simétrico já usado pelo programa, baseado em AES-256-CTR para confidencialidade e HMAC-SHA256 para integridade.

A consequência prática desse desenho é importante: o projeto afirma que o archive continua protegido se pelo menos um dos dois componentes permanecer seguro. Ou seja, mesmo que no futuro surja uma quebra relevante contra X25519, o componente ML-KEM-768 ainda sustentaria a segurança; e, no cenário inverso, o componente clássico ainda adicionaria proteção enquanto permanecesse confiável. Esse é exatamente o valor de um desenho híbrido em uma fase de transição criptográfica.

O que mais o Zupt oferece além do modo pós-quântico

Embora o modo --pq seja o grande diferencial, o Zupt não é “só” um experimento de criptografia. O README destaca compressão, autenticação por bloco, paralelismo e um codec chamado VaptVupt, descrito como o codec padrão da linha 2.0, combinando LZ77 + tANS com aceleração AVX2 para descompressão (Uau).

O projeto também apresenta comparação funcional com gzip, zstd e 7-Zip, ressaltando que o ganho do Zupt não é apenas taxa de compressão, mas a soma de compressão, integridade, criptografia e independência de bibliotecas externas. Também vale uma observação editorial importante para o seu artigo: no momento da consulta, a página do repositório mostrava v1.5.5 como release mais recente publicada, mas o README do branch master já descrevia a linha 2.0-RC e seus recursos, incluindo o VaptVupt como padrão. Para um texto técnico honesto, vale explicitar que parte da documentação do projeto reflete uma transição de versões.

Instalação do Zupt a partir dos fontes no openSUSE

No fluxo de compilação a partir do GitHub, o README oficial documenta um processo direto: clonar o repositório, entrar no diretório, executar make e depois sudo make install. O Makefile confirma que o compilador padrão é gcc, que o binário gerado chama-se zupt e que a instalação, por padrão, vai para /usr/local/bin. Como o procedimento usa git clone, make e gcc, no openSUSE o caminho mais lógico é preparar o ambiente com esses pacotes antes da compilação.

Os pré-requisitos mínimos no openSUSE podem ser instalados assim:

sudo zypper install git gcc make

Em seguida, faça a compilação:

git clone https://github.com/cristiancmoises/zupt.git
cd zupt
make
sudo make install

Depois da instalação, você pode confirmar que o binário entrou corretamente no sistema com:

which zupt
zupt version
zupt help

Esse fluxo está alinhado ao README e ao Makefile do projeto, que mostram build sem dependências externas além do toolchain C padrão.

Instalação do Zupt via zypper no openSUSE

O README também documenta instalação por pacote no ecossistema openSUSE. No trecho consultado, a instrução publicada era adicionar o repositório da iniciativa e instalar o pacote com zypper. Como o texto do repositório explicitava o exemplo para openSUSE 16.0, o mais correto é reproduzir exatamente esse procedimento no artigo, sem extrapolar para versões que não estejam listadas no README consultado.

sudo zypper addrepo https://download.opensuse.org/repositories/home:cabelo:innovators/16.0/home:cabelo:innovators.repo
sudo zypper refresh
sudo zypper install zupt

Após isso, os mesmos comandos de verificação continuam válidos:

zupt version
zupt help

Esse método é o mais prático para quem quer começar rapidamente, enquanto a instalação via fonte é mais interessante para auditoria de código, testes com mudanças locais ou validação de uma branch específica.

Uso básico do Zupt

A interface principal do programa gira em torno de alguns subcomandos: compress, extract, list, test, bench, keygen, version e help. O README mostra o formato geral como zupt compress [OPTIONS] <output.zupt> <files/dirs...> e zupt extract [OPTIONS] <archive.zupt>, além de opções como nível de compressão, número de threads, senha, modo pós-quântico, saída de extração e modos de codec.

1. Criando um backup simples sem criptografia

Para apenas compactar arquivos, o uso básico documentado é:

zupt compress backup.zupt ~/Documents/

Esse comando cria um archive .zupt usando o codec padrão documentado no branch atual do projeto. É o modo indicado para dados não sensíveis ou para testes rápidos de desempenho e formato.

2. Criando um backup com senha

Se a intenção é proteger o conteúdo com senha, o README mostra:

zupt compress -p "changeme" backup.zupt ~/Documents/

Nesse caso, o SECURITY.md diz que a derivação passa por PBKDF2-SHA256 e gera chaves para AES-256-CTR + HMAC-SHA256. É uma proteção útil para uso comum, mas a própria documentação alerta que esse modo não é o indicado para proteção de longo prazo contra ameaça quântica.

3. Extraindo um backup

Para restaurar o conteúdo em um diretório específico, o fluxo documentado é:

zupt extract -o ~/restored/ backup.zupt

Se o archive tiver sido protegido com senha, a senha deve ser informada no comando; se tiver sido criado com --pq, será preciso usar a chave privada correspondente. A opção -o define o diretório de destino da restauração.

4. Criando um backup pós-quântico

O modo pós-quântico documentado no README envolve primeiro gerar um par de chaves, depois exportar a chave pública e usá-la na compressão:

zupt keygen -o mykey.key
zupt keygen --pub -o pub.key -k mykey.key
zupt compress --pq pub.key backup.zupt ~/Documents/

Para extrair depois:

zupt extract --pq mykey.key -o ~/restored/ backup.zupt

A lógica é semelhante a fluxos de criptografia de chave pública: quem cria o backup usa a chave pública para proteger o archive, e só quem possui a chave privada consegue abrir o conteúdo. Para arquivos arquivísticos, backups frios, documentos estratégicos e material com exigência de sigilo prolongado, este é o modo mais interessante do Zupt.

5. Listando, testando e ajustando o comportamento

Além de comprimir e extrair, o README informa que o Zupt também oferece:

zupt list backup.zupt
zupt test backup.zupt

list serve para inspecionar o archive, e test para validar integridade. O projeto também documenta -l <1-9> para nível de compressão, -t <N> para número de threads, -s para armazenar sem compressão, -f para codec rápido legado e --solid para modo sólido. Isso permite adaptar o comportamento entre velocidade, taxa de compressão e custo de CPU.

Cuidados e limitações que merecem atenção

Um artigo técnico sobre o Zupt fica mais forte quando menciona não apenas os recursos, mas também os limites atuais. O COMPAT.md informa, por exemplo, que links simbólicos são ignorados, arquivos especiais também podem ser ignorados, e as permissões dos arquivos ainda não são restauradas na extração; o documento também cita limites para tamanho de bloco, quantidade de arquivos e algumas restrições de modo sólido.

Além disso, o README do branch atual é explícito ao dizer que a linha 2.0-RC já está adequada para uso pessoal e testes, mas ainda não é indicada para ambientes críticos ou grandes volumes de dados. Portanto, um texto responsável deve apresentar o Zupt como uma ferramenta muito promissora, tecnicamente interessante e especialmente relevante por trazer criptografia híbrida pós-quântica ao universo de backup, mas ainda em evolução.

Conclusão

O Zupt se destaca por atacar um problema real com uma abordagem moderna: backup não é só compactar arquivos, é preservar confidencialidade, integridade e recuperabilidade por muitos anos. Ao combinar compressão, autenticação por bloco, execução paralela e um modo híbrido ML-KEM-768 + X25519, a ferramenta entra em um espaço ainda pouco explorado por utilitários de backup open source. O grande valor do projeto está justamente em aproximar a discussão de criptografia pós-quântica da operação cotidiana de backup.