Transcrição de áudio na sua própria infra: o que roda sem GPU

Entre as tarefas de IA que dá para trazer para dentro de casa, transcrição de áudio é a que apresenta a melhor relação entre esforço e resultado. O motivo é técnico: os modelos de reconhecimento de fala são pequenos comparados aos modelos de linguagem, e o trabalho é naturalmente assíncrono — ninguém espera olhando a tela enquanto uma reunião de uma hora é transcrita.

Isso muda completamente a conta. Uma tarefa que pode levar alguns minutos em segundo plano não precisa de GPU nem de latência baixa. Precisa apenas de CPU suficiente e de uma fila bem feita.

Por que este caso é diferente

Rodar um modelo de linguagem em CPU esbarra na expectativa do usuário: cinco tokens por segundo é doloroso para quem está conversando. Transcrição não tem esse problema, porque o resultado é consumido depois.

Some a isso três características que favorecem a infraestrutura própria:

• O dado costuma ser sensível. Gravação de atendimento, consulta, reunião interna e ligação comercial contêm dado pessoal em abundância — frequentemente sensível na definição da LGPD.
• O volume é previsível. Uma central de atendimento sabe quantas horas de áudio gera por dia. Carga previsível é o cenário em que máquina dedicada compensa.
• A tarefa é homogênea. Sem variação de complexidade, o dimensionamento é direto.

Escolher o tamanho do modelo

Os modelos vêm em famílias de tamanho, e a diferença de qualidade entre eles não é linear — nem uniforme entre idiomas.

Para português, o salto de qualidade mais perceptível está entre base e small. Modelos menores erram mais em nomes próprios, números e termos técnicos — que são justamente as palavras que importam em ata de reunião e registro de atendimento.

A recomendação prática: comece no small e só suba se a revisão humana estiver dando trabalho demais. Subir de tamanho custa memória e tempo de processamento; nem sempre resolve o erro que está incomodando, que muitas vezes vem da qualidade do áudio.

A velocidade que dá para esperar

A métrica útil é a razão entre duração do áudio e tempo de processamento. Um fator de 3× significa que uma hora de gravação leva vinte minutos.

Em CPU moderna, com implementação otimizada e quantização, o small costuma entregar algo entre 3× e 8× dependendo de núcleos disponíveis e do áudio. É folgado para processamento noturno e apertado para quase-tempo-real.

Duas escolhas mudam bastante esse número:

• Implementação em C++ com quantização. Versões otimizadas para CPU são substancialmente mais rápidas que a implementação de referência em Python, e usam menos memória.
• Número de núcleos. Transcrição paraleliza bem. Aqui, mais vCPU tem efeito direto e previsível — é dos poucos casos em que aumentar CPU resolve mesmo.

# Medir o fator real na sua máquina, com o seu áudio
time ./main -m models/ggml-small.bin -l pt -t 4 -f amostra.wav

Rode com um áudio representativo — ruído de fundo, sotaque, mais de uma pessoa falando — e não com uma gravação limpa de estúdio. O número obtido com áudio fácil não serve para dimensionar.

O pré-processamento que mais melhora o resultado

Antes de trocar de modelo, arrume o áudio. É onde está o ganho mais barato.

Os modelos esperam áudio mono a 16 kHz. Enviar em outro formato faz a biblioteca converter internamente, às vezes mal:

ffmpeg -i entrada.m4a -ar 16000 -ac 1 -c:a pcm_s16le saida.wav

Outros ajustes que costumam render mais que subir de modelo:

• Normalizar volume. Gravação baixa produz transcrição ruim.
• Cortar silêncio longo. Reduz tempo de processamento sem perder conteúdo.
• Separar canais quando existirem. Em gravação de call center com cliente e atendente em canais distintos, transcrever cada um separadamente melhora muito o resultado e já entrega a identificação de quem falou.
• Informar o idioma. Deixar o modelo detectar custa tempo e às vezes erra em áudio curto. Se você sabe que é português, diga.

A arquitetura que sustenta

Transcrição não deve rodar dentro da requisição HTTP. O desenho que funciona tem quatro partes:

• Recepção. A aplicação recebe o arquivo e o grava direto em um bucket S3, sem passar pelo disco da VM. Áudio ocupa espaço, e disco de VM é o armazenamento mais caro que você tem.
• Fila. Um registro de trabalho com estado — pendente, processando, concluído, falhou — e o caminho do arquivo.
• Worker. Um processo que consome a fila, transcreve e grava o resultado. Um worker por máquina, usando todos os núcleos, costuma render mais que vários competindo.
• Notificação. Webhook ou atualização de estado quando terminar.

Rode o worker como serviço do systemd, com limite de memória declarado para que um arquivo problemático não derrube a máquina:

# /etc/systemd/system/transcricao.service
[Service]
Type=simple
ExecStart=/usr/local/bin/worker-transcricao
Restart=always
RestartSec=10
MemoryMax=6G
Nice=10

O Nice=10 deixa a transcrição ceder CPU para o que for interativo. O MemoryMax evita que um caso extremo acione o OOM killer contra outro serviço da máquina.

Dimensionar sem exagerar

Faça a conta pelo volume diário. Se você recebe 8 horas de áudio por dia e a máquina entrega fator 5×, são 96 minutos de processamento — cabe com folga em qualquer janela.

O que costuma faltar não é capacidade média, é folga para pico: a segunda-feira que concentra o fim de semana, o mês de campanha. Duas saídas, e a segunda é mais barata:

• Dimensionar para o pico, deixando capacidade ociosa o resto do tempo.
• Dimensionar para a média e deixar a fila absorver, aceitando que em dia de pico a entrega demore mais. Como o consumo é assíncrono, isso costuma ser aceitável — e é a decisão mais econômica.

Se a fila crescer de forma consistente em vez de esvaziar à noite, aí sim é hora do upgrade de CPU, que é aplicado em janela curta.

O texto bruto raramente é o produto final

Transcrição devolve um bloco corrido de texto. Isso quase nunca é o que o usuário quer — ele quer a ata, o resumo, o item de ação, o motivo do contato.

A etapa seguinte é outro modelo, agora de linguagem, trabalhando sobre o texto. E aqui a arquitetura híbrida faz muito sentido: a transcrição, que é volumosa e sensível, fica em casa; o resumo, que consome poucos tokens sobre um texto já processado, pode ir para onde for mais conveniente.

Duas melhorias valem mais que qualquer refino de modelo:

• Identificação de quem fala. Sem ela, a transcrição de uma reunião com quatro pessoas é quase inútil. Quando a gravação tem canais separados, resolva por canal — é exato e não custa nada. Quando é um canal só, existe diarização, com resultado bem mais irregular.
• Vocabulário do domínio. Nome de produto, sigla interna e jargão são justamente o que os modelos erram. Uma etapa de correção com lista de termos conhecidos, aplicada depois da transcrição, corrige a maior parte:

sed -f /etc/transcricao/correcoes.sed entrada.txt > saida.txt

Guarde sempre o texto bruto além do processado. Quando alguém questionar um resumo, o original é a única forma de verificar — e reprocessar a partir do áudio custa tempo de CPU que você já gastou uma vez.

Onde isso encaixa em conformidade

O argumento mais forte para trazer transcrição para dentro raramente é custo — é não enviar gravação de cliente para fora.

Ainda assim, hospedar internamente não encerra as obrigações. Continua sendo necessário definir a base legal para gravar, informar o titular, estabelecer prazo de retenção do áudio e do texto, e restringir quem acessa. O artigo sobre IA sem vazar dado do cliente trata do ponto que mais escapa: o dado costuma vazar pelo log e pela retenção, não pelo modelo.

Um cuidado específico deste caso: transcrição gera texto pesquisável a partir de áudio que antes ninguém consultava. Isso é o objetivo, e é também um aumento real de exposição — dado que estava inerte passa a ser indexável. Vale tratar o texto com o mesmo rigor do áudio original, e não como subproduto técnico.

Na prática, isso significa aplicar a mesma política de retenção aos dois, restringir o acesso à busca da mesma forma que se restringe o acesso à gravação, e incluir o texto no fluxo de exclusão quando um titular exercer esse direito. Apagar o áudio e deixar a transcrição é um erro comum — e o que sobra é justamente a versão mais fácil de consultar.