Vibe coding para GPU sob demanda em vez de VPS com uma GPU: 5 na fila

Vibe coding para GPU sob demanda em vez de VPS com uma GPU é a conta que Thiago precisava fechar no Autocut, produto ainda a R$ 0: 1 GPU na VPS atende 1 render, e se 5 clientes enviam vídeo ao mesmo tempo, 5 entram na fila.

Ele perguntou o que fica mais barato e mais rápido quando um monte de gente tenta fazer a edição ao mesmo tempo. A explicação na live colocou o teto da máquina na mesa: 1 placa ocupa 1 job até o fim, e quem chega depois entra na espera.

A pergunta da VPS chega no Autocut

O arquivo já está no Google Drive API. Aqui a dúvida é quem paga a GPU quando 5 chegam juntos.

O Autocut é o produto que recebe esses envios. A pergunta da VPS aparece quando ele imagina vários clientes na edição ao mesmo tempo.

Thiago pesou a VPS como o lugar do render:

Não seria melhor que uma VPS.

Ele abriu preço e tempo no mesmo fôlego, enquanto desenhava o fluxo do Autocut:

É, eu quero saber qual que fica mais barato, né, e mais rápido também. Imagina um monte de gente tentando fazer essa edição. Será que minha VPS vai aguentar?

A dúvida dele junta as 2 coisas: o que custa menos e o que entrega o render mais cedo quando vários clientes clicam juntos. O app leve já está na Vercel. A parte pesada é o render. Uma VPS com 1 GPU parece o lugar para esse render. Ele quer saber se a máquina segura a rajada e se essa escolha ganha da outra em preço e em tempo. Isso aparece também em vibe coding para exigir evidencia antes de confiar na ia.

A explicação na live trouxe a regra de ocupação da placa.

Uma GPU só atende um render. Se cinco clientes enviar vídeo ao mesmo tempo, cinco espera fila. GPU fica 100%. Então tempo de fila cresce linearmente. Para aguentar 10 em paralelo, você teria que pagar 10 GPUs.

1 GPU atende 1 render

Crescer linearmente, no que a live descreveu, é a placa em 100% sem espaço para o render 2. O job 2 espera o job 1 terminar. O job 3 espera os 2 da frente. Com 5 na porta, os últimos da fila esperam os renders de quem chegou antes. Com 10 na porta, a espera só alonga.

Thiago ouviu as 10 GPUs da VPS:

Tá doido.

O 5 é cenário se. Com 1 GPU na VPS você fica com 1 caixa. O cliente 6 espera alguém terminar. O cliente 10 espera mais. Para 10 em paralelo, a conta da VPS vira 10 placas.

A rajada no RunPod sobe 10 workers

A explicação na live seguiu com a mesma rajada do outro lado.

A mesma rajada escala sozinho. 10 drop, 10 workers efêmeros. Cada um paga seus segundos. Todo mundo termina quase ao mesmo tempo. Você paga 10x.

Na mesma porta de 10, cada job sobe com a sua GPU e você paga os segundos que cada um usar. Os 10 terminam quase juntos e a conta daquela rajada vem 10x.

Thiago encaixou a conta:

Entendi.

A live chamou de caminho certo separar o app leve do render:

Separar as coisas exatamente o caminho certo.

Separar, no recorte da live, é deixar o app leve onde já está e subir GPU só no job pesado.

A mesma explicação fechou o recorte:

Cada job tem sua própria GPU.

O desenho que ficou: o app leve continua sempre ligado, já na Vercel, e o RunPod entra só na parte pesada, pago por segundo. Contratar o RunPod continua pendente.

No vibe coding do job, a GPU sobe com a rajada

Amanhã, no vibe coding de um job de vídeo, conte a placa antes de cravar a VPS. 1 GPU é 1 render. A porta de 5 já é fila. Se a rajada importa, o caminho que a live fechou é cada job com a sua GPU, pago no segundo. A live fez a conta com 5 e com 10 na porta, porque a VPS com 1 GPU só mostra o teto quando os jobs se sobrepõem. O mesmo problema apareceu em vibe coding para extrair fatos do pdf uma vez so.

Dá para assistir à live e ouvir a pergunta da VPS e o Tá doido das 10 GPUs, quando a rajada ganha 1 GPU por job.