NVIDIA RTX Spark, contexto e perspectivas

No inicio deste mês recebi um email da Nvidia apresentando o RTX Spark, basicamente um SOC ARM feito em colaboração com a Mediatek e com GPU RTX integrada. Vou até postar o cabeçalho do email aqui porque vai servir também para analise depois:

 

De um modo geral era o esperado,  já haviam rumores, e também era o passo lógico para competição com o Snapdragon X Elite e os chips M da Apple, que vinham sendo usados cada vez mais para rodar modelos LLM locais, principalmente este último, devido a memória unificada. E de início leva uma vantagem técnica enorme por vários motivos que veremos mais no final.

Logo em seguida ao anúncio da Nvidia a mídia especializada de hardware o cobriu em peso, inclusive pela falta de novos lançamentos na área ultimamente, e esse é mais um ponto a se guardar na memória para a conclusão final. O que quase todos esses analistas, todos os que eu vi na realidade, concordam é que essa solução, como mencionado antes, estaria pelo menos inicialmente se destinando ao mercado profissional que precisa da carga de trabalho que é bem atendida pela GPU integrada, ou seja, IA local, renderização e etc. E os games? Agora cito o cabeçalho que mostrei no inicio, interessante que acabamos de estabelecer, o remetente seja "gaming@nvgaming.nvidia.com". E apesar também das fotos do evento fartamente divulgadas do Jensen segurando os dois laptops rodando jogos, como essa abaixo, que ninguém se engane, não fazem o menor sentido para o jogador no momento, vamos entender porque.

 

Citando o press release linkado no email:

 "Powering agents on local devices requires both robust security and performant hardware. RTX Spark features up to 1 petaflop of AI compute and 128GB of unified memory to meet the processing demands of on-device agents."

Ora, qual a faixa de preço de um equipamento com 128 GB e uma GPU equivalente a uma 5070? Mas não é só isso, Há a questão da compatibilidade limitada dos jogos com ARM usando a camada de emulação Prism da Microsoft. Muitos títulos sequer abrem, e a maioria terá uma performance muito inferior e/ou alguns bugs. Jogos nativos são exceção atualmente. Ou seja, mesmo o entusiasta com dinheiro "infinito" não teria motivos de adquirir esta máquina (hipotética) atualmente para jogos, porque teria um resultado muito melhor gastando menos dinheiro com soluções tradicionais de desktop x86. Eu sei disso, todos os influencers que eu vi sabem disso, todos que acompanham hardware deveriam saber, e Jensen com certeza também sabe. Mas então porque o esforço em posar para a mídia segurando esses dois laptops, e ainda, porque direcionar um email apresentando o produto para a base de usuários domésticos de placa de vídeo (que foi o meu caso).

Aqui entra a minha interpretação pessoal dos fatos. Primeiro, junte a isso que não há lançamentos significativos na área neste momento, que praticamente todos os recursos da Nvidia estão direcionados para datacenter e IA. Então para mim é como se a empresa dissesse: "Não esquecemos de vocês, fiquem aí, coisas boas virão..." ao invés de simplesmente: "Pois é, acabou, tudo um dia acaba, obrigado por tudo...". Mas na realidade o que realmente acredito é que, apesar de não estarem focando no mercado doméstico no momento,  eles não vão abandonar completamente o segmento, só não será mais como era antes, alguma coisa virá, mas talvez não como se esperava que seria. Então vale a pena para a Nvidia um baixo investimento de marketing (emails, tempinho de palco na apresentação) pra não estimular toda a base de clientes a debandar para a concorrência.

Voltando ao Spark, qual a probabilidade de ele chegar com preço compatível com o mercado consumidor individual não especializado, que não ganha dinheiro com um PC com esses requisitos? No médio prazo talvez, quando houverem cortes do chip menores, o que faz parte do processo de fabricação de qualquer chip, e se ele for empacotado junto com menos RAM, digamos 64 ou 32 GB, ai talvez se aproximem dos atuais laptops com Snapdragon X Elite, que ainda são posicionadas como máquinas premium. E na minha opinião, levando alguma vantagem.

Primeiro, porque a GPU da Nvidia terá muito mais capacidade bruta de processamento que as atuais NPU do Snapdragon X Elite, ou mesmo do X2 Elite. E leva vantagem em compatibilidade, a maioria dos softwares de LLM  local é projetada roda nativamente em GPUs, poucos rodam nativamente na NPU da Qualcomm. Vai ganhar provavelmente do M5 também, sendo uma alternativa para quem não quer um Mac. 

Resumindo, apesar de que neste momento muitos possam sentir que ficaram de fora, o anuncio é positivo em geral, tanto porque ele pode chegar depois a um segmento mais barato, possibilitando inclusive o uso de LLM local em menor escala, como porque vai estimular a competição com outros fabricantes. E num futuro muito distante, quem sabe até se torne viável para jogos.

Mas e quanto ao futuro do atual modelo de GPUs dedicadas para PCs DIY? Neste ponto a minha previsão atual não é nada boa. Não acho que vai acabar amanhã, mas também não percebo chances de grande evolução. Por um lado, parece que tecnicamente se chegou a um limite do aumento viável da rasterização bruta, e se está dependendo cada vez mais de IA para fazer o trabalho. Por outro, a necessidade de injetar mais potência elétrica levou a sistemas de arrefecimentos imensos, que levam a placa de vídeo a precisar de um suporte adicional pra não entortar, ou novos conectores como o infame 12VHPWR, substituído depois sem muito sucesso pelo 12V-2x6, e seus derretimentos e incêndios. Ao mesmo tempo, quem quer rodar uma IA local esbarra em uma quantidade de VRAM limitada mesmo nos modelos de GPUs mais caros, o que é a grande vantagem das soluções com memória unificada como a da Apple. E os gamers continuarão também insatisfeitos com pouca VRAM, sofrendo com os também infames 8 GB de VRAM nos modelos mais populares (os que a maioria pode comprar), dificuldades técnicas (conector, tamanho da placa) e preço alto. Também tem os que se orgulham das placas imensas, ocupando 4 slots, cheias de fans e com suportes pra não despencar com o próprio peso, mas vamos deixar os ostentadores de lado aqui. Racionalmente, tamanho, peso, dissipação, consumo  elétrico e preço aumentando são problemas. E lidar com consumidor final de placa também é problema para as fabricantes: RMA, inclusive aumentando por causa o conector, canais de suporte, marketing separado, embalagem, distribuição. E aqui nem é exatamente a Nvidia, mas Asus, Gigabyte, MSI, Palit, que AINDA fabricam GPUs dedicadas. 

Parece que a Nvidia já percebeu tudo isso e está apostando suas fichas em outro lugar, e com razão. Datacenters e no lado do consumidor final, fabricantes terceiros integrando os chips em soluções completas: Lenovo, HP, Dell. Citando novamente o press release:

 "RTX Spark-powered slim Windows laptops with all-day battery life and premium displays, as well as compact desktop PCs available this fall from ASUS, Dell, HP, Lenovo, Microsoft Surface and MSI, with models from Acer and GIGABYTE to follow."

 

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/

 

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.