quarta-feira, 6 de maio de 2026

O fim da GALAX. Acabou mesmo?

O primeiro impacto foi o vídeo (short) do Ronaldo Buassali semana passada, informando sobre o encerramento da Galax. O que me veio à mente: a lembrança do fim da EVGA, o fim da Crucial, e no subconsciente talvez mais uma confirmação da decadência no PC DIY. Depois vieram as contra-notícias: a Galax não ia acabar, era uma "reestruturação", o nome e a marca continuam ...

Vamos separar os fatos de opiniões e narrativas. O que de fato aconteceu foi o fim de uma empresa. Sim, ela já era subsidiária da Palit. Então sim, a versão de que foi uma reestruturação também não está errada, mas concretamente, é o fim de uma "estrutura", equipes inteiras de pessoas, cargos, contabilidade própria, e do relacionamento comercial de representantes da marca como por exemplo o próprio Ronaldo. Logo, a versão dele faz total sentido. A empresa, por mais que fosse uma subsidiária e compartilhasse uma estratégia com a controladora, poderia definir uma identidade própria, controle de qualidade diferente, público alvo, segmentação, etc. No meio automobilístico isso é muito comum, grandes conglomerados, como a GM e Stellantis, possuem diversas marcas para faixas de preço, interesses, enfim públicos diferentes, resultando em produtos de qualidade e especificações muito distintas.

Mas a marca Galax vai continuar, publicou a Palit. Ver o comunicado oficial. Pode ser, mas isso é só uma promessa, talvez uma intenção, fica no futuro, enfim, não é um fato. De concreto nada e, mesmo que continue, já não teria o mesmo nível de independência. A integração faz sentido do ponto de vista econômico, não estou de modo algum criticando ou condenando.

 GeForce RTX™ 5080 HOF Gaming GALAX

Se compara com o fim da EVGA? Embora isso tenha me vindo a mente no inicio, de fato é bem diferente. A EVGA era uma empresa completamente independente e seu fim teve realmente mais impacto. E quanto à Crucial? É mais parecido, já ela também foi encerrada pela controladora (Micron). Mas acontece que aí também houve mais impacto no mercado, pois a Micron parou de vender produtos para o consumidor final.

Isso leva ao problema da perda de concorrência. Ora, não creio que uma controladora mantenha uma subsidiária para competir de verdade, canibalizar seu mercado. Então não vejo menos concorrência em geral. Mas com algumas exceções, aqui no Brasil não temos muita presença de Palit ou outras marcas controladas além de Galax, então se sai a Galax e elas não ocupam o lugar, aqui no Brasil em particular teríamos menos uma opção, e relevante.

E por fim, a decadência ou crise do mercado DIY. Pois o pano de fundo evidente é a pressão no mercado pela falta de insumos (notadamente RAM) e a competição implacável de outro segmento da indústria, datacenters para IA.

Neste ponto vamos citar o próprio comunicado da Palit sobre o assunto, transcrito pelo artigo no site WCCFTech:

"Optimize Supply Chain: Streamline production and logistics to better serve our international markets." 

Para surpresa de zero pessoas (pelo menos entre as que acompanham tecnologia). A consolidação advém pelo menos em parte da pressão por manter a margem de lucro diante dos custos crescentes na cadeia de suprimentos. Ou seja, sim, está relacionada pelo menos em parte com uma "crise no PC gamer".

Minha opinião pessoal é que não há motivo para desespero, operações corporativas deste tipo são comuns. No fundo já era o mesmo conglomerado, gerido pela mesma estratégia e servindo aos mesmos acionistas, eles estão enxugando custos. Mas um dos motivos pelos quais decidiram isso especificamente agora é significativo. E, segundo a Palit, a Galax continua. Ninguém perde garantia, e no curto prazo ao menos nada muda.

sábado, 11 de abril de 2026

Workstation para LLN local - parte 2: instalando e configurandoi o WebUI

No primeiro artigo desta série mostramos como instalar o Ollama para permitir rodar LLMs locais usando duas GPUs. Nesta segunda parte vamos configurar uma interface Web semelhante a de IAs comerciais como Chat-gpt e Gemini, rodando em servidor web local em containet docker. 

Caso o docker ainda não esteja instalado no seu sistema será necessário fazê-lo. Como isso pode variar dependendo da distribuição, indico a página de documentação do docker:  https://docs.docker.com/engine/install/

Em seguida vamnos baixar e rodar o container da Open WebUI:

$ sudo docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/data --name open-webui ghcr.io/open-webui/open-webui:main


Depois da inicialização a WebUI poderá ser acessada pelo browser:

            http://localhost:3000


Na primeira execução será preciso criar um usuário e senha. Note que para isto funcionar também deve ter sido feita a configuração da inicialização do Ollama no arquivo override.conf:

[Service]

Environment="CUDA_VISIBLE_DEVICES=1,0"

Environment="OLLAMA_HOST=0.0.0.0"

 

Veja o primeiro artigo referenciado no início para mais detalhes. 

Se o container não estiver configurado para auto-execução no reinicio do sistema, o que prefiro para economia de recursos, é necessário execitar antes, depois de um reinicio do PC:

            $ sudo docker start open-webui


O processo pode ser facilitado com a criação de scripts e atalhos na área de trabalho. Por exemplo, crie o arquivo  "iniciar_ia.sh:

#!/bin/bash

sudo systemctl start ollama

sudo docker start open-webui

notify-send "IA Iniciada." 

 

Caso, ao contrário, prefira que a WebUI sempre reinicie junto com o sistema:

$ sudo docker update --restart always open-webui


Caso esteja obtendo erro, verifique se o Ollama está sendo executado:

$ systemctl status ollama


E se necessário, o reinicie. Garanta também que o próprio docker está sendo reiniciado no boot:

$ sudo systemctl enable docker.service

$ sudo systemctl enable containerd.service


Neste ponte temos um sistema plenamente funcional com duas GPUs utilizando Ollama e WebUI para prompt. Como foi comentado no primeiro artigo, o fato de existirem duas GPUs na máquina pode gerar algum conflito no linux em alguns jogos. No WoW por exemplo, depois de muita pesquisa e tentativa e erro, a solução foi configurar dentro do jogo para DX11 (e não 12). Não é o ideal, mas também não notei diferença. A solução específica vai depender do título. Mas adianto também que existem configurações no Lutris e na Steam que podem ser feitas. No GW2 utilizei um parâmetro de configuração na Steam. Clique com o botão dirreito no jogo (na biblioteca), depois Propriedades e sem seguida Opções de Inicialização. No acampo adicione:

 __NV_PRIME_RENDER_OFFLOAD=0 __GLX_VENDOR_LIBRARY_NAME=nvidia %command%


Isso vai direcionar a carga para a GPU 0, que como vimos nno primeiro artigo é a que está ligada ao monitor.

Por fim, cabe uma nota sobre a atualização do Ollama. Pode ter sido notado no artigo anterior que ele não foi instalado por meio do gerenciador de pacotes do sistema. Com isso ele também não será atualizado junto com os demais pacotes com apt-get update e upgrade. Para atualizar o Ollama basta rodar novamente o script de instalação, com o mesmo comando passado no primeiro artigo. è recomendável apenas fechar qualquer processamento que esteja sendo executado ou aba do Open WebUI antes. Para verificar se é necessária atualização rode o comando:

        $ ollama --version

E compare com a última versão disponível.


Referências: 

Documentação sobre a Open Web UI pode ser encontrada em https://github.com/open-webui/

 

Método Telecom adquire telefonia fixa da Oi

No dia 8 de abril de 2026, a Justiça do Rio de Janeiro homologou a venda da operação de telefonia fixa da Oi para a empresa mineira Método Telecom. A transação, realizada via leilão judicial no contexto do processo de falência da Oi, foi fechada pelo valor de R$ 60,1 milhões, pagos à vista. A Método Telecom superou a proposta da Sercomtel, que oferecia R$ 60 milhões de forma parcelada, tornando-se a vencedora para assumir a Unidade Produtiva Isolada (UPI, divisão de ativos isolada para venda em processos de recuperação judicial) de Serviços Telefônicos.

Os ativos envolvidos na negociação abrangem a infraestrutura física, como torres, postes, cabos e os tradicionais "orelhões", além da manutenção da base atual de clientes. A área geográfica de atuação é vasta e crítica, compreendendo mais de 7,4 mil localidades em todo o Brasil onde a Oi era a única prestadora do serviço. No setor de telecomunicações, a Método assume também a responsabilidade por serviços essenciais de utilidade pública, como as linhas de emergência (190, 192 e 193), com a obrigação contratual de garantir a continuidade da telefonia fixa nessas regiões até, pelo menos, dezembro de 2028. A transação foca na UPI Serviços Telefônicos, que lida majoritariamente com a rede de cobre (STFC) e obrigações de universalização.

Essa movimentação sinaliza uma transição importante no mercado: a saída definitiva de grandes grupos concessionários de modelos de negócio legados em direção a operações mais enxutas e regionalizadas. Para o setor, a entrada da Método Telecom, livre de dívidas anteriores da Oi, pode representar mais dinamismo na gestão de serviços que, embora em declínio nos grandes centros, permanecem vitais em áreas isoladas. A tendência é que a telefonia fixa passe a ser operada por empresas de médio porte focadas em eficiência operacional e manutenção de infraestrutura essencial, enquanto o mercado de telecomunicações como um todo se consolida em torno da conectividade móvel e da fibra óptica de alta velocidade.

terça-feira, 31 de março de 2026

Quero ficar no meu sistema antigo! Dica rápida para o Ubuntu

Com a data de lançamento do Ubuntu 26.04 LTS se aproximando, 23 de abril de 2026, precisei decidir se vou entrar na nova versão ou me manter na atual. Até não muito tempo atrás a minha mentalidade para linux no PC era que novo = bom, quero novidades, e não há dúvidas. E de fato continuo gostando de novidades, mas dado que estou usando o PC com o Ubuntu para uso pessoal, entretenimento e trabalho, há outras coisas a considerar. O fator estabilidade e previsibilidade pesam mais. Decidi ficar no 24.04 por enquanto, e abaixo explico porque, lembrando que esta não é necessáriamente a melhor opção para todo mundo, então vamos detalhar alguns pontos a serem considerados e ajudá-lo a tomar a melhor decisão para a sua realidade.

quarta-feira, 25 de março de 2026

Criando uma workstation multi-GPU para IA, distribuindo a carga de VRAM

O uso de GPUs para executar LLMs localmente coloca a quantidade de VRAM disponível na máquina, na placa de vídeo, normalmente, como o fator limitante do tamanho do modelo a ser carregado. Algumas arquiteturas de computadores resolvem em parte este problema em parte com uma memória unificada (como máquinas da Apple ou alguns notebooks Windows ARM) e, de fato, isso dá uma certa flexibilidade. Nestes casos existe ainda a restrição da memória total, que em geral é cara e não pode ser aumentada (depois da compra, pois nestes modelos normalmente é soldada, e antes da compra até pode-se configurar mais, só que a peso de ouro).

Mas e se usarmos duas (ou mais) GPUs, poderíamos usar as duas para carregar um modelo maior do que seria suportando individualmente por cada uma, redistribuindo o uso de memória entre as duas? A boa notícia é que isso é possível e relativamente fácil de configurar no Ollama, e possivelmente em outras plataformas similares. Deescreverei um breve experimento para verificar a viabilidade técnica, sem entrar na comparação de custos com outras opções, como a compra de uma GPU maior que a soma das duas, lembrando que a eficiência não é só dependente da quantidade de VRAM, teria que ser feita umas análise custo/benefício completa, comparar diversas placas e conjuntos de placas, rodando benchmarks. A idéia aqui é apenas ver se funciona. No entanto usar as duas GPUs pode ser a diferença em algumas situações entre conseguir rodar o modelo ou não. 

Voltando ao cenário concreto, tenho duas GPUs GTX-1080 (EVGA e Asus ROG), já obsoletas, sem as últimas tecnologias, mas ainda com capacidade razoável para execução de LLMs, com 8 GB de VRAM cada. Alias, um outro motivador para o teste, tenho outras duas GPUs mais atuais, RTX 3060Ti e RX 6600, mas todas tem 8 GB, e não tenho como com uma única placa rodar modelo maior. Tenho à disposição também uma máquina Linux (Ubuntu 24.04 LTS) com 16 GB de RAM, Core i7 6700K e aproximadamente 1.5 TB em SSD SATA (480 Gb + 1 TB). A CPU bem antiga obviamente não é a melhor escolha para uma máquina de produção deste tipo, mas se mostrou válida para o teste. Provavelmente esta solução funcionará com outras GPUs, incluindo AMD, mas isso não foi testado, embora as GPUs nVidia dominem largamente o mercado e seriam o caso mais comum. Também não vejo porque não funcionaria em outras distros linux ou mesmo no Windows. De todo modo, para registro, o teste foi feito com sucesso com Ubuntu Linux e nVidia. Apenas a facilidade de balanceamento de carga de memória do Ollama é que não sei se é similar em outras soluções deste tipo, lembrando que o Ollama está disponível também em Windows.  

O primeiro passo é a instalação física da segunda placa de video. O PC usado já tinha uma GTX 1080 no slot principal (16x). Olhando no manual da motherboard e planejando uma separação saudável entre as duas placas, para evitar aquecimento, coloquei a segunda placa dois slots abaixo depois. É uma placa ATX normal, e elas ficaram a uns 10 cm de distância entre si. Importante, não utilizei pontes SLI entre as placas. Uma pesquisa rápida me mostrou que agora em 2026 o SLI está totalmente morto, não é utilizado nem em jogos e muito menos o Ollama não utilizaria esta via para comunicação de dados. Tudo é feito pelo barramento normal do PC. Notar também que no segundo slot PCI-e utilizado, por limitações da placa mãe, a velocidade ficou em 4x. Isso não causou problema algum. Outros dois pontos de atenção aqui, o gabinete, que pode ser um ATX barato, mas o ideal é que não seja muito compacto, por motivos obvios, e ofereça boa ventilação. E a fonte de alimentação tem que segurar tudo, ser de qualidade razoável (aliás isso sempre, independente do uso), e ter boa margem na potência total. Usei uma Corsair CX750M, também nada muito extraordinário. 

Próximo passo, ligar o PC e confirmar que tudo continua funcionando como antes (a não ser talvez por alguns jogos, como comento no último parágrafo, e que podem precisar de ajustes nas configurações e parametros de inicialização para forçar a placa certa). Neste momento estamos com duas GPUs, a "GPU 0", na qual está ligado o monitor (ou mais), e a "GPU 1", a qual vai ficar em princípio apenas para processamento. Um fato interessante é que como usei placas semelhantes, de chipsets iguais, na maioria das vezes dentro de jogos, não tenho como diferenciar pois aparecem exatamente com a mesma descrição. tenho que ir por tentativa e erro, levando em conta a ordem em que aparecem, ou que a primieira é a zero e a segunda é a 1, o que eventualmente não é verdade. Um pequeno contratempo, mas de qualquer modo são apenas duas tentativas (e não 3 como no USB-A... rs). As vezes, como no comando a seguir, é possivel diferencia-las por alguma característica. Por exemplo, a Asus tem uma potência máxima maior (198 W contra 180W da EVGA e isso já aparece logo no comando a seguir).  

Entre agora em um terminal e rode:

            nvidia-smi

Isso obviamente só vale para nVidia, placas AMD e Intel devem ter algo semelhante. Deve aparecer uma saída semelhante à tela abaixo (clique pra aumentar se necessário):


Aqui podemos ver que a segunda placa, a "GPU 1", está conectada corretamente e acessível, do contrário não apareceria, e vemos como disse antes, a capacidade máxima listada de 198W. Note também que o Xorg já alocou um processo nela, há como impedir isso completamente mas não achei necessário. Além disso é possivel acompanhar dados sobre a saúde da placa, percentual de uso dos fans, temperatura e bem importante, a memória usada por cada processo. É por aqui que comprovaremos que o modelo está sendo distribuído entre as duas placas (além do fato que muitos deles nem caberiam em apenas uma). Isso conclui a etapa da instalação da segunda GPU, confirmando que o PC continua normal e a segunda placa foi instalada corretamente e reconhecida pelo sistema. 

A próxima etapa já será observar um modelo rodando nas duas. Em seguida, caso já não tenha no seu PC, instale o Ollama:

            curl -fsSL https://ollama.com/install.sh | sh

Agora teste com um modelo pequeno, para um download rápido:

            ollama run mistral-nemo

Recomendo explorar um pouco o Ollama no terminal, mesmo que depois a intenção seja usar pela interface Web, apesar de ser linha de comando é bem simples e intuitivo. Rode o comando "nvidia-smi" em outra janela de terminal, de preferência enquanto a IA estiver pensando, se bem que ela não desaloca a memória imediatamente depois, por eficiência, já que o usuário pode continuar mandando prompts no mesmo chat. Observe que a GPU 1 já está sendo usada pelo Ollama.

Agora vamos testar um modelo maior, que fará mais sentido neste teste. Rode por exemplo, no terminal:

            ollama run llama3.1:8b-instruct-q8_0

ou o "gemma3:12b", ou o "gpt-oss:20b", ou qualquer um se sua escolha, o importante aqui é escolher um que caiba na capacidade total somada das suas duas placas e que seja maior do que uma das duas placas. No caso aqui estou escolhendo modelos entre 8 e 16 GB (porque as duas placas aqui tem 8 GB, no caso do seu teste o valor total pode ser diferente). O ponto é provar que estou rodando um modelo que não poderia por estar com apenas uma das duas placas. Pelos meus testes, quando o modelo é maior ou nem abre ou fica extremamente lento. Aqui a coisa começa a ficar interessante, rode de novo "nvidia-smi" em outra janela de terminal, com a IA grande resolvendo algum prompt, o que pode até ser difícil, já que a maioria dos comandos fois resolvida de imediato e é dificil encontrar algum que demora, mas como também mencionei, não é crítico. Observe abaixo:



O total consumido pelo modelo é 5.974 MB + 6.736 MB, ou seja, mais de 8 e, além disso, note com a GPU 1 está sendo mais usada.

A seguir um item de preparação, que é de certa forma opcional em um teste rápiudo, mas e rápido e demonstra um cenário mais realista. A intenção é que o Ollama interfira o minimo nas aplicaçãoes graficas rodando, seja jogo ou outra aplicação profissional. Para isso o procedimento abaixo inverte a prioridade de uso das GPUs pelo Ollama:  

                              sudo systemctl edit ollama.service

E no editor que irá abrir, inserir:

            [Service] 

            Environment="CUDA_VISIBLE_DEVICES=1,0" 

            Environment="OLLAMA_HOST=0.0.0.0"

Salve e saia. A primeira linha muda a prioridade de uso do Ollama, e a segunda será necessária depois para compatibilizar com o Web-UI, e já que estamos com a mão na massa podemos inserir logo. Essa mudança de prioridade das GPUs também vai ajudar na compatibilização com jogos, podendo eventualmente se dar ao luxo de jogar e deixar a IA rodando, dependendo da VRAM consumida por cada um deles, o jogo e o modelo. Os jogos (se for o caso) deverão rodar sempre na GPU 0, ao passa que o Ollama começara a preencher pela GPU 1, embora acabe balanceando entre as duas, como poderá ser observado rodando de vez em quando o "nvidia-smi". 

Logo a seguir execute no terminal:

            sudo systemctl daemon-reload

            sudo systemctl restart ollama

Após tudo funcionando e testado, ainda existem algumas considerações a fazer. Primero que, para uso prático é interessante instalar uma interface web, como o conhecido Web-UI. Na realidade quando escrevo já fiz isso e ela está operacional, mas não vou incluir aqui para não ficar tão extenso. Penso em publicar depois o procedimento de instalaçâo, apenas para registro, mas em todo caso o processo não tem muito mistério e pode ser encontrado na Web. O foco aqui foi mais a novidade, pelo menos para mim, do uso de mais de uma placa. Cabe apenas ressaltar aqui que existe um segundo método de instalação em que tudo é instalado por container, ao contrário da que usei, na qual o Ollama é instalado direto no sistema operacional host e depois a WebUi apenas acessa a API do Ollama pelo protocolo padrão. 

O outro ponto é a compatibilidade com outras aplicações gráficas na máquina. No meu caso tenho a pretensão de também usar este PC para jogar alguns jogos no Steam e no Lutris. Antes quando estava usando apenas uma GTX 1080 tudo funcionava perfeitamente. Ao inserir a segunda placa tive que fazer algumas configurações para evitar conflitos em alguns jogos, que se confundem com a existência da segunda placa e podem direcionar o processamento para ela, com resultados adversos (lembrando que a segunda placa não controla vídeo). Na realidade a instalação do Web-UI e a resolução deste conflitos demorou muito mais tempo que a primeira parte que foi fazer os modelos funcionarem nas duas placas, mas também nada extraordiário. A compatibilização dos jogos acho que vale um terceiro post.

A questão final: vale a pena para uso prático montar PC multi GPU para IA? Acho que depende muito, mas já adiantando que provavelmente eu manterei o resultado desta implementação o meu para uso pessoal. Na minha realidade não precisei comprar nenhuma peça, e complementando depois com configurações para tornar o uso mais prático, como instalaçâo Web-UI e outras configurações dos jogos, está se mostrando uma solução muito funcional e barata. Se eu tivesse um uso profissional remnunerado e orçamento tenderia a ir com uma unica placa poderosa e atual, mas estou apenas fazendo testes.

Caso não se tenha nenhuma GPU disponível teria que fazer as contas, comparar comprar duas ou uma única mais cara, bem como as diferenças de performance entre essas opções, pois existe o tráfego pelo barramento da máquina envolvido também. E também valeria a pena considerar o mercado de pĺacas usadas. Além disso, soluções assim  talvez façam mais sentido em ambiente de testes doméstico, profissional individual, já que com orçamento maior é fácil buscar opções prontas otimizadas. O custo pode até ficar menor, mas o usuário terá que garantir toda a compatibilidade das peças, tamanho do gabinete, capacidade da fonte, posição dos slots, etc.