VIBE IN PUBLIC_

Whisper IA: como um vibe coder escolhe o modelo quando o Windows não aloca 3,1 GB

Whisper IA no vibe coding é o large-v3 de 3,1 GB: no vídeo 3 o VAD fez 7 cortes em 40 segundos; no 4 o Windows não aloca e o médio perde palavra.

Whisper IA no vibe coding é o large-v3 que pede 3,1 GB e o Windows que não aloca no vídeo seguinte. Thiago mandou o job vídeo 4 no AutoCut. Na linha do tempo: transcrevendo o áudio, VAD local indisponível. No vídeo 3, ontem, o mesmo pipeline tinha alocado 3,1 GB, rodado o VAD em 40 segundos e feito 7 cortes. Ele leu o log:

Ixe, por que que o Vad local ficou indisponível

Ele abriu o job e testou no áudio real do vídeo 3. O médio ficou 100% estável na GPU. No log, se usasse o médio: palavras perdidas, cortes imprecisos.

O VAD local some no vídeo 4 e o alocador recusa 3 GB

O job vídeo 4 já estava na fila do AutoCut quando o VAD local caiu.

Estou trabalhando nesse job aqui no Autocut. Ah, gostaria de entender por que não funcionou o vad.

Ele comparou com o job que tinha funcionado.

Beleza, então a gente precisa descobrir porque que o vádio local falhou agora no job, porque o job vídeo 3, por exemplo, o VAD local estava disponível.

No vídeo 3, ao iniciar o job, o sistema alocou um bloco de 3,1 GB de RAM para carregar o large-v3. O VAD local rodou em 40 segundos e gerou 7 cortes. No vídeo 4, ao tentar carregar 3 GB, o alocador falhou. O bloco de segurança capturou a falha para não abortar.

O que apareceu na linha do tempo foi VAD local indisponível. O job seguiu sem o corte fino. Sem o VAD, o AutoCut perde o ponto em que a frase acaba.

O commit "use Grok" tirou o autodiscover do Python 3.11

Thiago abriu o histórico e chegou em 10 de agosto.

Putz, faz tempo, né?

No 10 de agosto o Python tinha autodiscover: encontrava o Python 3.11 no caminho mesmo sem ponto local. O commit "use Grok" migrou a transcrição primária para a API do Grok, limpou o código local e removeu esse autodiscover. Em 11 e 12 de agosto o VAD local voltou, Faster Whisper e silero VAD, para refinar fim de palavra e silêncio. A função ficou restrita.

Médio vs large no vibe coding: 156 palavras e o corte impreciso

O agente sugeriu o nível médio para caber na GPU. Thiago pediu prova da precisão.

Você tem certeza que ele entrega com a mesma precisão no nível médio?

O teste empírico usou o áudio real do vídeo 3, médio contra large. 156 palavras detectadas. O médio ficou 100% estável na GPU. No log, se usasse o médio: palavras perdidas, cortes imprecisos.

O AutoCut corta no silêncio e no fim da palavra. 156 palavras no áudio do vídeo 3 é o lote que o large enxergou; o médio segura a GPU e solta palavra no meio da fala.

Na tela veio a recomendação: large-v3 turbo, modelo oficial recente da OpenAI. Preserva 99,4% e a mesma qualidade de alinhamento em português do large-v3, arquitetura que rende na GPU sem estourar o alocador do Windows. Thiago mandou implementar; na live o turbo ficou em spec.

O MODELO

Nível médio

GPU 100% estável. Palavras perdidas, cortes imprecisos

large-v3 turbo

99,4% do large. Mesma qualidade de alinhamento em português, GPU sem estourar o alocador do Windows

Beleza, então pode fazer essa implementação, por favor

Pede o turbo e mede no áudio real

Amanhã, se o VAD local sumir de um job para o outro, não aceite o médio só porque a GPU ficou 100% estável. Roda o áudio real e lê o log de palavra perdida. Pede o large-v3 turbo (99,4% do large) e confere se o Python 3.11 ainda está no caminho.

Na mesma live ele ainda bateu em teto de agente e cota de nuvem; o recorte do teto está em ChatGPT Codex e o da cota em Supabase pricing.

Quem quiser o job vídeo 4, o log de 3,1 GB e o teste das 156 palavras pode assistir à live de 86 min. Quando o Windows recusa o large-v3, o vibe coding mede o modelo menor no áudio real antes de aceitar o fallback. O VAD local indisponível e as 156 palavras ficam no ar; é o que as leis do movimento pedem de quem constrói ao vivo.