Toda decisão de infraestrutura para IA começa na mesma conta, e ela cabe numa linha:
VRAM ≈ parâmetros × bytes por parâmetro + folga
Um modelo de 64 bilhões de parâmetros em BF16 (2 bytes cada) precisa de 128 GB só para existir na memória — antes de processar qualquer coisa. Não existe placa única no mercado com isso.
A partir daí, ou você encolhe o modelo, ou o divide. Este artigo é sobre a segunda opção — e sobre o preço que ela cobra.
1. O que é um world model · 2. Cosmos 3 por dentro · 3. Dados sintéticos · 4. Dividir entre GPUs ← você está aqui · 5. Do texto à ação
A conta, com números que você reconhece
| Modelo | BF16 (2 bytes) | 8 bits | 4 bits |
|---|---|---|---|
| 7B | 14 GB | 7 GB | 3,5 GB |
| 13B | 26 GB | 13 GB | 6,5 GB |
| 34B | 68 GB | 34 GB | 17 GB |
| 70B | 140 GB | 70 GB | 35 GB |
| 64B (Cosmos3-Super) | 128 GB | não suportado | não suportado |
Some a essa conta a folga de execução: ativações, cache de atenção, espaço de trabalho do runtime. Para um modelo de linguagem servindo poucos usuários, 15% a 20% costuma bastar. Para modelo de vídeo, muito mais — porque ele mantém dezenas de quadros vivos ao mesmo tempo, com atenção entre eles.
É daí que vem a afirmação da parte 2 de que 128 GB de pesos não rodam numa placa de 141 GB: sobram 13 GB para a parte que mais consome.
Para quase todo modelo de linguagem, a resposta a "não cabe" é quantizar: 8 bits corta pela metade, 4 bits corta a 1/4, e a qualidade cai pouco.
Para o Cosmos 3, essa porta está fechada — a ficha declara que só BF16 foi testado; FP16, FP8 e FP4 não são oficialmente suportados. Modelo de difusão é notoriamente mais sensível à precisão que modelo de linguagem: o ruído da quantização entra no processo de denoising e vira artefato visível.
Antes de planejar em cima de quantização, confirme que o modelo específico a suporta. É um pressuposto que costuma passar sem verificação.
Os cinco cortes possíveis
"Dividir o modelo entre GPUs" não é uma coisa só — são cinco cortes diferentes, e eles se combinam. Cada um corta numa direção.
1. Paralelismo de tensor — corta cada camada ao meio
Cada matriz de peso é fatiada entre as placas. Todas processam a mesma entrada, cada uma com o seu pedaço, e trocam resultado ao fim de cada camada.
Ganho: resolve memória e velocidade ao mesmo tempo. Custo: é o mais faminto por comunicação — há troca a cada camada. Fora de uma máquina com interconexão rápida entre as placas, degrada muito. Bandeira típica: --tensor-parallel-size.
2. Paralelismo de sequência (Ulysses) — corta o que está sendo processado
Em vez de fatiar o modelo, fatia a entrada: cada placa fica com um pedaço da sequência — dos tokens, no caso de texto; dos quadros, no caso de vídeo.
Ganho: é o corte que faz contexto longo e vídeo longo caberem. Custo: exige redistribuição a cada bloco de atenção. Bandeira: --ulysses-degree.
3. Paralelismo de CFG — o truque exclusivo da difusão
Este merece atenção porque é o mais elegante e o menos conhecido. Modelos de difusão com classifier-free guidance calculam, a cada passo, duas previsões: uma condicionada ao seu prompt e outra incondicional. Depois combinam as duas.
Como as duas são independentes, cada uma pode rodar numa placa diferente — em paralelo, sem comunicação até o fim do passo.
É quase o paralelismo ideal: duas placas, praticamente o dobro da velocidade, porque não há troca de dado no meio do caminho.
É por isso que a configuração recomendada do Cosmos 3 começa em --cfg-parallel-size 2 mesmo na montagem de duas placas: é a primeira duplicação que você compra, e é a mais barata.
E é específico de difusão — não existe equivalente em modelo de linguagem, o que ajuda a explicar por que a receita de servir vídeo não se parece com a de servir um LLM.
4. Sharding (FSDP / HSDP) — cada placa guarda um pedaço, monta na hora
Os parâmetros ficam espalhados; quando uma camada vai ser executada, as placas reúnem só o pedaço necessário, usam e descartam.
O H de HSDP é de híbrido: espalha dentro do grupo de placas que conversam rápido e replica entre grupos. Bandeiras: --use-hsdp --hsdp-shard-size N.
5. Paralelismo de pipeline — cada placa fica com um trecho das camadas
Camadas 1–10 na placa A, 11–20 na B, e assim por diante. O dado atravessa a fila.
Ganho: comunicação mínima. Custo: a "bolha" — enquanto a placa B trabalha, a A espera. Só compensa com fila cheia de pedidos, o que o torna mais adequado a treino do que a atender uma pessoa.
E se você só tem uma placa? Offload
Existe um plano B: manter na VRAM só a camada em execução e guardar o resto na memória do sistema, trazendo cada camada quando chega a vez. É o --enable-layerwise-offload.
Funciona, e é honesto dizer que é lento — a placa passa boa parte do tempo esperando o barramento. Serve para provar que a coisa roda, ou para trabalho de lote sem prazo. Não serve para atender pedido.
A medição que quase ninguém faz
Aqui está o ponto prático deste artigo inteiro. Todo mundo assume que mais placas é proporcionalmente melhor. Os números publicados pela própria NVIDIA para o Cosmos 3 dizem outra coisa:
| Placas | Preço por hora | Tempo por vídeo | Aceleração | Custo por vídeo |
|---|---|---|---|---|
| 2 × 141 GB | R$ 57,10 | ~3 minutos | 1× | R$ 2,86 |
| 8 × 141 GB | R$ 228,40 | ~55 segundos | ~3,3× | R$ 3,49 |
Preços consultados no catálogo em 1º de setembro de 2026, por GPU avulsa, sem interrupção programada. O catálogo se move dentro do mesmo dia — confira a vitrine antes de fechar a conta.
Quatro vezes mais placas, 3,3 vezes mais velocidade. A diferença — cerca de 22% — é o que a comunicação entre placas consome, e você a paga em dinheiro.
Isso não é defeito de implementação: é a lei de Amdahl aparecendo. Sempre existe uma fração do trabalho que não paraleliza, e é ela que fixa o teto. Quanto mais placas você adiciona, mais cara fica cada unidade de velocidade comprada.
Se alguém está esperando a resposta, compre placas — a latência vale o prêmio.
Se é lote — mil clipes de madrugada, um treino, um processamento em fila —, a configuração menor entrega mais resultado pelo mesmo dinheiro. Você troca tempo de relógio, que ninguém está contando, por custo, que todo mundo conta.
Receita prática de dimensionamento
- Calcule os pesos: parâmetros × bytes por parâmetro.
- Some a folga: +20% para modelo de linguagem; +50% ou mais para vídeo, e mais ainda se a saída for longa.
- Cheque se dá para quantizar — não assuma que dá.
- Divida pela VRAM da placa e arredonde para cima. Esse é o mínimo.
- Meça antes de escalar. Rode no mínimo, cronometre, e só então decida se a velocidade extra vale o custo extra. A aceleração real quase nunca é a que você esperava.
| Se você quer... | Configuração | Preço/h |
|---|---|---|
| Servir um modelo de linguagem de 7B a 13B | 1 placa de 24 GB | R$ 3,18 |
| Servir um modelo de 34B em BF16 | 1 placa de 96 GB | R$ 10,26 |
| Servir um modelo de 70B em BF16 | 2 placas de 80 GB | R$ 28,62 |
| Servir um modelo de 70B quantizado em 4 bits | 1 placa de 48 GB | R$ 7,08 |
| Servir um modelo de mundo de 64B (só BF16) | 2 a 8 placas de 141 GB | R$ 57,10 a R$ 228,40 |
Preços consultados no catálogo em 1º de setembro de 2026, por GPU avulsa, sem interrupção programada. O catálogo se move dentro do mesmo dia — confira a vitrine antes de fechar a conta.
A quarta linha contra a terceira é o resumo de tudo: o mesmo modelo de 70B custa quatro vezes menos por hora quantizado numa placa só do que em BF16 em duas. Quando a quantização está disponível, ela costuma ser a decisão de infraestrutura mais lucrativa que existe — e é justamente a porta que o Cosmos 3 fecha.
Medir em vez de estimar
Aceleração real só se descobre cronometrando. Você pode subir a configuração mínima, medir, subir a maior, medir de novo, e pagar só pelas horas usadas — em reais, sem contrato e sem compromisso mínimo.
Ver o catálogo →Continue: parte 2: o Cosmos 3 por dentro · parte 1: o que é um world model