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.