- Para complementar um ambiente local de LLM em que apenas uma RTX 4080 16GB não bastava, foi adicionada uma Tesla V100 SXM2 16GB usada com adaptador por cerca de £200, formando um total de 32GB de VRAM
- A V100 SXM2 é uma GPU de servidor sem slot PCIe, saída de vídeo ou conector de energia comum, mas pôde ser instalada em um PC gamer com um adaptador SXM2-to-PCIe
- O fan de servidor vinha com 82dB por padrão, inviável para uso em ambiente interno, mas ao conectá-lo ao header de fan da placa-mãe com um cabo jumper PH2.0-2.54mm foi possível obter controle por PWM e operação silenciosa
- Com tensor splitting no llama.cpp, o modelo Qwen3.6-27B-MTP Q5_K_M foi dividido entre a RTX 4080 e a V100, alcançando contexto de 128k e velocidade de inferência de cerca de 32 tok/s
- Não é tão elegante quanto uma única GPU de 32GB, e ainda há problemas de driver, CUDA e warm reboot, mas GPUs de servidor usadas podem ser uma alternativa barata para expandir VRAM em LLMs locais
Um ambiente local de LLM com 32GB por £200
- Como os 16GB de VRAM da RTX 4080 não eram suficientes para rodar os modelos locais desejados, foi adicionada ao PC gamer uma GPU usada de datacenter com adaptador
- Uma Tesla V100 SXM2 16GB e um adaptador SXM2-to-PCIe foram comprados por cerca de £200 no total, formando um ambiente com 32GB de VRAM somando as duas GPUs
- Um modelo de 27B parâmetros foi distribuído entre as duas GPUs e executado a cerca de 32 tokens/s, com o modelo inteiro e o contexto cabendo na VRAM
- Não entrega a mesma experiência de uma única GPU de consumo com 32GB, mas garante capacidade de VRAM a um custo muito menor do que uma RTX 5090 32GB
Tesla V100 SXM2 e o adaptador
- A Tesla V100 SXM2 16GB é uma GPU voltada para servidores NVIDIA DGX e racks de hyperscalers
- Não tem slot PCIe comum, saída de vídeo nem conector de energia padrão
- Ela é montada em uma placa proprietária dentro do servidor e se comunica via NVLink
- Para conectá-la diretamente à placa-mãe é necessário um adaptador separado
- A V100 é uma GPU Volta com 16GB de memória HBM2 e 5120 CUDA cores
- O preço pago no eBay foi de cerca de £150
- Embora seja uma GPU de 2017, seu desempenho computacional e VRAM ainda seguem válidos para uso com LLM local
- A largura de banda da memória HBM2 é a principal vantagem
- A V100 oferece 900GB/s de largura de banda com barramento de memória de 4096 bits
- Isso é 22% acima dos 736GB/s de GDDR6X da RTX 4080
- Também supera os 400GB/s do Apple M3 Max, 546GB/s do M4 Max e 614GB/s do M5 Max
- A AMD RX 7900 XTX tem 24GB de GDDR6 e 960GB/s de largura de banda, um pouco acima da V100, mas custa mais de £700
- O suporte do ROCm para inferência de LLM ainda é considerado mais áspero do que o CUDA
- A V100 entrega 94% da largura de banda da RX 7900 XTX por menos de um quarto do preço e funciona com llama.cpp
- A RTX 5090, com 1.792GB/s de largura de banda, supera a V100 com folga, mas custa mais de £2.000
- Em inferência de LLM, a largura de banda da memória é um gargalo que determina os tokens/s, então é um fator importante
- O adaptador SXM2-to-PCIe não é um produto oficial da NVIDIA nem tem suporte oficial
- Ele é uma placa PCB nua com soquete SXM2 de um lado e conector PCIe edge do outro
- Custou cerca de £50, levando o custo total do conjunto para algo em torno de £200
- Graças ao adaptador, foi possível conectar a V100 16GB à placa-mãe junto com a RTX 4080
O problema do fan de servidor e a solução
- A V100 SXM2 foi projetada para operar no ambiente de refrigeração industrial de um servidor 2U
- O fan do adaptador fazia barulho demais para uso em um cômodo comum
- O ruído medido com um Apple Watch foi de 82dB, descrito como algo entre um triturador de lixo e um cortador de grama
- No estado padrão, não havia controle do fan
- Tentativas com
nvidia-smi, enumeração de dispositivos no Linux e Windows Afterburner falharam
- O fan do adaptador aparentemente foi feito partindo do princípio de que rodaria a 100% o tempo todo dentro de um rack de servidor
- O teste com bateria de 9V foi usado para confirmar a pinagem do fan
- Ao ligar jumpers em VCC e ground e encostar uma bateria de 9V, o fan girou
- Como ficou muito mais silencioso do que no funcionamento padrão em 12V, confirmou-se a possibilidade de controle
- O fan se comportou de forma semelhante a um fan padrão de gabinete de PC
- Foram conectados jumpers ao conector do fan, e a outra ponta foi ligada a um header livre de fan da placa-mãe
- A placa-mãe conseguiu ler o RPM e também controlar por PWM
- Mesmo mantido em 10% de velocidade, a temperatura não passou de 50°C em carga total e o ruído ficou quase inaudível
- O cabo final foi montado com um jumper cable macho 2.54mm para fêmea PH2.0
- O conector do fan no adaptador é um plugue JST PH2.0 de 4 pinos
- O header de fan da placa-mãe usa o padrão de 0,1 polegada, ou seja, passo de 2,54mm
- O lado fêmea PH2.0 foi ligado aos pinos de tachometer e PWM do fan, e o lado macho 2.54mm ao header de fan da placa-mãe
- Um cabo jumper de cerca de £2 e a confirmação do conector resolveram o problema dos 82dB
Expandindo a VRAM com duas GPUs
- A configuração final de GPUs ficou assim
- RTX 4080: 16GB de VRAM, arquitetura Ada
- Tesla V100: 16GB de VRAM, arquitetura Volta
- Total: 32GB de VRAM distribuídos entre as duas GPUs
- O llama.cpp consegue dividir o modelo entre duas GPUs com tensor splitting
- As camadas são processadas em pipeline pelo barramento PCIe
- A RTX 4080 processa parte das camadas e a V100 processa o restante
- Não é mais rápido do que uma única GPU de 32GB, mas funciona e custa cerca de 10% do valor de uma GPU de 32GB
- O consumo de energia da V100 foi observado em até cerca de 150W
- Não é pequena como GPU para inferência de LLM local, mas também não é algo anormalmente grande
- O modelo V100 32GB também continua sendo uma opção
- Custa mais do que o dobro do valor pago aqui, mas ainda permite obter 32GB de HBM2 em uma única placa por algumas centenas de libras
- Duas V100 de 32GB permitiriam chegar a 64GB de VRAM, descritas como algo em torno de 20% do preço atual de uma RTX 5090
- O formato SXM2 oferece suporte nativo a NVLink
- Em uma configuração multi-GPU adequada, as GPUs poderiam se comunicar com alta largura de banda
- Mesmo via adaptador PCIe, o desempenho de tensor split foi suficientemente sólido
Ajustando driver e CUDA no NixOS
- Graças ao NixOS, a configuração de software foi relativamente tranquila
- A V100 usa chip Volta, e a NVIDIA encerrou o suporte a Volta a partir do branch 560 dos drivers
- O último driver que suporta ao mesmo tempo a RTX 4080 Ada e a V100 Volta é o branch 550.x
- No NixOS, isso corresponde a
nvidiaPackages.legacy_535
- Esse driver suporta apenas até o CUDA 12.2
- Atualmente, o nixpkgs fornece CUDA 12.6 ou superior
- Foi necessário trazer o CUDA 12.2 do nixpkgs 24.05
- O driver exige o Linux kernel 6.6
- O driver legacy não suporta kernels mais novos
- Mesmo sendo um servidor headless de inferência, foi necessário ativar
services.xserver.enable = true
- Sem essa configuração, o módulo de kernel da NVIDIA não era carregado
- A configuração central do NixOS consiste em definir o kernel, o driver NVIDIA legacy e o driver de vídeo NVIDIA para o X server
boot.kernelPackages = pkgs.linuxPackages_6_6;
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.legacy_535;
services.xserver.enable = true;
services.xserver.videoDrivers = [ "nvidia" ];
- O CUDA 12.2 foi trazido do nixpkgs antigo via overlay
nixpkgs.overlays = [
(final: prev: {
cudaPackages_12_2 = nixpkgs-cuda.legacyPackages.${prev.system}.cudaPackages_12_2;
})
];
- As duas GPUs aparecem corretamente e o CUDA funciona normalmente
- A definição completa da máquina está incluída neste commit do repositório de dotfiles
- Também inclui a definição do serviço llama.cpp e um build customizado fixado na versão correta
Modelo executado e desempenho
- O modelo executado é a versão quantizada Qwen3.6-27B-MTP Q5_K_M
- O tamanho do modelo é de cerca de 19GB
- Com as duas GPUs, o modelo inteiro cabe na VRAM e ainda sobra espaço para o contexto
- As principais configurações de execução foram estas
- Model: Qwen3.6-27B-MTP Q5_K_M, 19GB
- Context size: 128k tokens
- GPU layers: 99, tudo offloaded
- Tensor split:
-ts 1.0,1.0, divisão equilibrada entre as duas GPUs
- O desempenho foi o seguinte
- Inference speed: cerca de 32 tok/s
- Prompt processing: cerca de 133~160 tok/s
- Os 32 tokens/s foram considerados velocidade suficiente para uso interativo
- Isso foi alcançado mesmo em uma configuração de tensor split entre duas arquiteturas de GPU diferentes ligadas por PCIe
- Considerando até a latência de rede, foi descrito como mais rápido do que a maioria dos endpoints de API em nuvem
MTP e entrada de imagens
- MTP significa Multi-Token Prediction
- Na inferência tradicional de LLM, um token é previsto por vez, aceito e só então o próximo é previsto
- No MTP, vários tokens futuros são previstos de uma só vez e depois validados
- Os tokens aceitos saem praticamente de graça, e previsões erradas voltam ao caminho normal
- O resultado do MTP é um ganho de cerca de 1,5 a 2 vezes na velocidade de geração sem perda de precisão
- Nesta configuração, foi indicado que os cerca de 32 tok/s podem chegar a 50~60 tok/s quando o MTP acerta bem
- O efeito é especialmente forte em saídas previsíveis, como código
- O suporte a MTP no llama.cpp ainda é recente
- A versão de llama.cpp no nixpkgs não suporta a arquitetura MTP do Qwen3.6
- Foi necessário compilar o llama.cpp a partir do código-fonte em um commit específico que já incluía esse suporte
- No NixOS, foi criada uma derivation customizada fixada nesse commit para manter reprodutibilidade
- Trocar de modelo ou de versão do llama.cpp passou a exigir apenas mudar uma linha da configuração e executar
nixos-rebuild switch
- O Qwen3.6-27B suporta entrada de imagem por meio de um arquivo multimodal projector separado, o
mmproj
- O arquivo adicional tem cerca de 928MB
- O vision encoder converte os pixels da imagem para o espaço de embeddings de tokens do LLM
- O modelo não “vê” a imagem como uma pessoa
- O LLM processa os vetores convertidos como se fossem outra sequência de tokens
- As flags de execução no llama.cpp são as seguintes
--mmproj /mnt/nas/llamacpp/mmproj-F16.gguf --mmproj-offload
--mmproj-offload coloca o vision encoder na GPU junto com o modelo
- Isso permite manter inferência rápida também com entrada de imagem
Forma de uso local
- Essa configuração é usada com o OpenCode
- O OpenCode é um assistente de programação com IA que pode ser executado usando modelos locais
- O servidor de LLM roda no desktop, mas o uso acontece a partir de outros dispositivos
- O acesso é feito pela rede a partir de outras máquinas da casa
- De fora, o acesso é feito via Tailscale
- No OpenCode, o uso do servidor llama.cpp é configurado definindo a URL da API
- O modelo roda localmente
- As respostas são rápidas e os dados não saem da rede
Problemas restantes e limitações
- Às vezes a V100 desaparece após warm reboot
- Depois de um reboot em que só o sistema operacional reinicia e a placa-mãe continua energizada, pode acontecer de a V100 não aparecer em
lspci nem em nvidia-smi
- Parece ser um problema de enumeração ACPI do slot PCIe
- Um cold reboot, desligando fisicamente a máquina, esperando alguns segundos e ligando novamente, sempre resolve
- Sem a V100, o llama.cpp não inicia
- Isso acontece porque o modelo não cabe em apenas uma GPU de 16GB
- O serviço entra em crash loop até a GPU voltar
- Como normalmente o reboot é feito com a máquina por perto, isso não foi considerado um grande problema na prática
- Uma configuração com tensor split entre duas GPUs de arquiteturas diferentes não é tão limpa quanto uma única GPU
- A V100 também não é a GPU mais rápida possível para inferência
- Mesmo assim, foi avaliada como tendo excelente custo-benefício
Opções e conclusão
- Por cerca de £200, o resultado obtido foi o seguinte
- Uma GPU de datacenter de 16GB funcionando junto com uma GPU gamer
- 32GB totais de VRAM para inferência local de LLM
- 32 tokens/s em um modelo de 27B parâmetros
- Janela de contexto de 128k tokens
- Suporte a visão para entrada de imagem
- Um modelo rodando totalmente local, sem nuvem e sem custo por token
- O custo real acabou sendo o ruído do fan, resolvido com cabo jumper e confirmação do conector
- Para quem quer rodar modelos locais de verdade, o mercado de GPUs de servidor usadas pode ser uma alternativa
- Mesmo sem já ter uma GPU instalada, colocar uma V100 única em um servidor barato já pode criar um ambiente local utilizável com 16GB de VRAM
- A V100 SXM2 não é a única opção
- A P40 oferece 24GB por custo parecido, mas é mais lenta e não tem Tensor Cores
- O modelo V100 32GB custa mais, mas ainda sai mais barato do que GPUs de consumo com a mesma capacidade de VRAM
- Ainda assim, é preciso estar preparado para o problema do fan
2 comentários
Comentários no Hacker News
Recentemente também comprei uma GPU de datacenter e coloquei no sistema, então vou compartilhar algumas experiências que faltaram no texto
A NVIDIA V100 aposentada e a AMD MI50 são bem baratas para experimentos locais: a de 16GB sai por cerca de 200 dólares, e a de 32GB por 400~500 dólares, mas ambas são placas bem antigas. Mesmo assim, existe uma comunidade de desenvolvedores hobbyistas que continua mantendo essas duas placas vivas em plataformas e modelos atuais
Um detalhe pequeno: a V100 não suporta bfloat16. Para mexer com modelos locais, a perda de desempenho não é tão grande, mas em termos de recursos de hardware é uma placa que já está saindo de cena
A MI50 suporta bf16, mas não é compatível com o ROCm mais recente da AMD. O suporte a Vulkan é bom, e ela funciona na maior parte das principais plataformas como llama.cpp e vllm, embora existam incômodos como recompilação manual. Felizmente, a comunidade open source já pavimentou boa parte do caminho
Os requisitos de refrigeração dessas placas não devem ser subestimados de jeito nenhum. GPUs de consumo podem sofrer throttling em gabinetes pequenos sem ventoinhas extras, mas GPUs de datacenter, nas mesmas condições, superaquecem até em idle. No mínimo, é preciso comprar várias boas ventoinhas de 120mm ou investir em water cooling
No fim, comprei uma AMD MI100 32GB por 950 dólares. Porque gosto da AMD, ela suporta o ROCm mais recente e a configuração foi relativamente tranquila. Estou pensando se compro uma segunda placa para tentar rodar modelos maiores, como qwen3-coder-next
O duto encaixa perfeitamente na entrada de ar da GPU, direcionando todo o fluxo de ar da ventoinha instalada para a placa, e também dá para vincular a curva de velocidade da ventoinha à temperatura da GPU
Essas placas esperam fluxo de ar de nível servidor, provavelmente vindo do lado da entrada de ar frio. Ele imprimiu um suporte para ventoinha e fixou na placa, e desde então tem funcionado bem
Eu também fico tentado a comprar uma placa desse nível, mas rodar modelos Qwen3.6 MOE numa 6800xt ainda é aceitável para os projetos que quero deixar com IA local, então ainda não consegui justificar a compra
O trabalho é impressionante, mas o problema não são 30 tok/s, que já bastam para coding com agente e chat, e sim o prefill
Prefill lento destrói imediatamente cargas de trabalho do tipo agente. Pelos números do texto original, processar 100.000 tokens a cerca de 150 tok/s dá 100000 / 150 segundos, ou seja, uns 11 minutos e 6,7 segundos, então a espera é considerável
Esse também é um problema geral dos LLMs locais em Mac. Mac é ótimo para ter muita memória de alta largura de banda, mas o desempenho computacional fica muito atrás das GPUs dedicadas da geração atual. Algumas configurações caras de Mac Studio conseguem rodar modelos muito grandes com tok/s utilizáveis, mas talvez seja preciso esperar bastante até a geração de tokens começar
Em linguagens como C++, em que os módulos se separam em definição (.h) e implementação (.cpp), todos os arquivos de cabeçalho do projeto poderiam virar o prefixo. Como os headers tendem a mudar com menos frequência
De forma mais geral, seria a ideia de ter um agente cujo principal objetivo de gerenciamento de contexto fosse reutilizar prefixos em cache
Para também cachear arquivos que já mudaram, o agente poderia montar o contexto no início da sessão com um prefixo fixo refletindo parte ou todo o codebase daquele momento, e depois anexar as alterações no final. Nesse caso, seria preciso um prompt dizendo para usar apenas a definição mais recente das funções
Por exemplo, se no começo o arquivo A contiver as funções X, Y e Z, o prefixo do prompt teria X Y Z. Se o usuário mudar Y para Y', esse conteúdo seria adicionado ao contexto, mantendo o prefixo em cache intacto, de forma que vire X Y Z Y'
Seria frustrante querer que o LLM começasse a trabalhar com você imediatamente ao trocar de projeto, mas até o melhor colaborador humano precisa de um longo tempo de onboarding para conseguir contribuir de forma significativa
Ao contrário do que o autor escreveu, a Tesla V100 SXM2 16GB não é de nível DGX, e sim de nível HGX
A V100 existe em duas variantes, SXM2 e SXM4, e a segunda pode ter até 80GB de memória onboard. Normalmente, 8×A100 80GB SXM4 são instaladas em um riser HGX, resultando em uma malha NVSwitch e 640GB de HBM2e agrupada. É memória empilhada no encapsulamento, com largura de banda de cerca de 2TB/s, em um tamanho padrão de rack 2U
A V100 não oferece 2TB/s
HGX é mais ou menos como um DGX com configuração adicional por cima
Pelo título, eu esperava ver como isso seria usado para jogos, mas no fim só rodaram um LLM
A AMD MI250X também é interessante. Tem 128 GB de HBM2E e 3 TB/s, e às vezes aparece usada por menos de US$ 1.000
O problema é que ela exige um soquete OAM. Nunca vi uma forma simples de conectá-la a uma placa-mãe comum
Além disso, as unidades da HPE retiradas de servidores e vendidas barato no eBay precisam de alguma coisa proprietária da HPE para funcionar, e ainda não vi ninguém descobrir o que é
A MI250X encaixa fisicamente e até aparece no sistema, mas o driver não funciona. O teste foi feito com uma HPE MI250X
Nesse tópico há um rumor de que existem dois tipos de MI250X: as da HPE e as demais. A ideia é que as da HPE precisam de firmware especial, enquanto as normais não. Mesmo assim, como a maioria das MI250X no mercado de usados é da HPE, comprador, cuidado
Excelente texto. Eu sempre considerei essas placas de datacenter para projetos, e agora fiquei com vontade de comprar uma
A parte que comparou o preço do equipamento com o custo dos tokens foi decisiva
Parabéns. A maioria das pessoas não vai querer depurar driver, kernel, ACPI, adaptadores e headers de ventoinha, mas, para quem topa, o custo-benefício é absurdamente bom
Acho injusta uma avaliação do tipo: “se você quer o melhor absoluto, existe o Opus 4.8. Mas o custo de usar pesado por 20 minutos já é maior do que o que foi pago por toda essa GPU e pelo adaptador. E mesmo assim a diferença é surpreendentemente pequena”
Eu uso modelos de ponta todos os dias com tokens pré-pagos de API, mas mal passo de US$ 100 por mês. É impressionante ter encontrado um jeito de queimar o dobro disso em 20 minutos, mas não acho que isso represente a realidade de muita gente hoje. Abordagens de uso de LLM exageradamente consumidoras estão sendo usadas como um espantalho conveniente nessa discussão
Pagar por API quase sempre é mais econômico do que hospedar por conta própria uma infraestrutura equivalente. Não sou contra hospedar localmente, mas o texto apresenta a economia como principal motivação da tentativa. Se você consome menos de 10^9 tokens por mês, não vejo muito valor em gastar tempo tentando competir com hyperscalers. O dinheiro está principalmente em integrar essa tecnologia ao negócio existente
Se seu uso é tão leve assim, usar assinatura sai muito mais em conta. Se você usa mais, aí pode valer a pena passar uma parte para local, dependendo de quão barata é sua energia. No meu caso, não vale
/fastligado dá para fazer isso em uns 10 minutosNão entendo muito bem como o pessoal está usando
Segundo o ccusage, se eu não tivesse a assinatura Max de US$ 100, em maio eu teria que ter pago cerca de US$ 4.173 para a Anthropic
Input │ Output │ Cache Create │ Cache Read │ Total Tokens │ Cost (USD)
1,948,016 │ 19,435,081 │ 103,626,350 │ 6,244,194,278 │ 6,369,203,725 │ $4173.09
Tirei os números de novo recentemente, e não usei Fast Mode nenhuma vez, mas usei Opus na maior parte do trabalho
Meu padrão de uso também não é tão extremo. Normalmente deixo o Claude Code rodando em um ou dois projetos, e às vezes ele continua rodando enquanto eu durmo. Com frequência chego a 60–80% do limite semanal
É bom ver hardware antigo sendo reaproveitado. Eu estou usando duas Tesla V100 em um servidor Supermicro X10DRU-i dual-core
Com qwen3.6-27B-mtp, em contexto de tamanho médio, ou seja, abaixo de 128k, a inferência fica em cerca de 35–40 tok/s, e eu também já rodei trabalhos longos de agente que consumiram centenas de milhões de tokens. Se eu tivesse pago isso em custos de API da Claude, teria dado centenas de dólares ou mais
Mas o principal uso dessas placas é computação científica. O desempenho em FP64 passa de 7 TFLOPS, o que é excelente considerando a idade delas, e é um nível difícil de conseguir até em placas de consumidor modernas depois que a NVIDIA limitou esse desempenho nas placas de consumidor desde Kepler. O servidor fica no porão, e faz um barulho absurdo
A parte mais interessante e mais útil para muita gente provavelmente é o controle das ventoinhas. Para fazer isso, você realmente precisa controlar as ventoinhas. Faz muito barulho
Se estiver considerando essas placas, também vale saber que a V100 tem consumo em idle muito alto. Mesmo sem carregar nada, fica em 25–35 W, e ao carregar um modelo sobe facilmente para 50 W
Opiniões no Lobste.rs
A abordagem é muito legal, e esse fenômeno da GPU desaparecer do PCIe tem tantas causas possíveis que fiquei ainda mais curioso
O barulho alto da ventoinha da GPU me lembrou da época em que eu estava na equipe do NVIDIA CUDA. Um colega estava adicionando controle de ventoinha ao NVML e ao
nvidia-smi, e eu ouvia por cima da divisória o som da ventoinha acelerando e desacelerando, até que ele apareceu com um grande sorriso no rostoEle dizia que era um dos recursos em que mais gostou de trabalhar, porque dava para ouvir o resultado no instante em que o código funcionava
Se você tem interesse em LLM auto-hospedado, a Dell OEM RTX 3090 costuma ser mais barata do que produtos de grandes marcas, e dava para encontrar por cerca de 800 dólares canadenses
Agora preciso ler mais sobre como o vLLM funciona. Às vezes o modelo começa a despejar uma longa lista de nomes e adjetivos relacionados, então provavelmente configurei alguma coisa errada
Eu achava que a maioria dos modelos minimamente úteis precisava de pelo menos 48~64GB de VRAM para rodar direito, e por isso imaginava que os chips Apple da linha M com arquitetura de memória unificada fossem populares nessa área
Já existem produtos assim em forma pronta para uso, mas normalmente é aquele esquema de receber só 3 meses de garantia do fabricante e acabou
https://ebay.com/itm/297819576914/…
Nos EUA, modelos usados de 32GB são negociados por algo em torno de 600 dólares
O adaptador eu provavelmente compraria direto da China, que deve ser a origem
Fiquei curioso se existe um equivalente do lado da AMD. No momento estou usando duas W7900 de 48GB e queria expandir para conseguir rodar modelos maiores
Você ainda precisa cuidar da refrigeração, mas não precisa ficar mexendo com adaptadores
Tenho lido toda vez que encontro alguma configuração local de modelos, e no momento não parece existir um verdadeiro ponto ótimo de custo-benefício na faixa intermediária de demanda por VRAM, entre 48 e 128GB. As opções são mais ou menos três: várias GPUs de datacenter de antes da 3ª geração (Tesla V100, Instinct MI60), várias opções de entrada da geração atual com muita VRAM (Arc Pro B70), ou caixas integradas da geração atual (DGX Spark, Mac Mini, Strix Halo)
Para quem está fazendo upgrade saindo de uma GPU de consumidor de 32GB ou de duas de 16GB, cada uma dessas opções traz concessões, mas também vantagens. Se você já está usando duas placas de 48GB, não sei se existe algum upgrade de hardware usado que de fato vá parecer uma melhora perceptível