Transcrição de áudio multilíngue em escala com Parakeet-TDT e AWS Batch

O problema de custo em transcrição de áudio em escala

Muitas organizações lidam com volumes crescentes de áudio: bibliotecas de mídia para arquivamento, gravações de contact center, dados de treinamento para Inteligência Artificial (IA) ou vídeos sob demanda que precisam de legendas. Quando esses volumes crescem, os custos de serviços gerenciados de Reconhecimento Automático de Fala (ASR, do inglês Automatic Speech Recognition) passam a ser o principal limitador de escala.

Para endereçar esse desafio, a AWS publicou um guia mostrando como combinar o modelo NVIDIA Parakeet-TDT-0.6B-v3 com o AWS Batch em instâncias aceleradas por GPU. O resultado é um pipeline capaz de transcrever áudio em escala por frações de centavo por hora de áudio processado.

O modelo Parakeet-TDT-0.6B-v3

Lançado em agosto de 2025, o Parakeet-TDT-0.6B-v3 é um modelo open-source multilíngue de ASR desenvolvido pela NVIDIA. Ele usa uma arquitetura chamada Token-and-Duration Transducer (TDT), que prevê simultaneamente os tokens de texto e suas durações — o que permite ao modelo pular silêncios e processamentos redundantes de forma inteligente, atingindo velocidades de inferência muito superiores ao tempo real.

De acordo com as métricas publicadas pela NVIDIA, o modelo mantém uma Taxa de Erro por Palavra (WER, do inglês Word Error Rate) de 6,34% em condições limpas e 11,66% de WER a 0 dB de Relação Sinal-Ruído (SNR, do inglês Signal-to-Noise Ratio). Ele também suporta áudios de até três horas no modo de atenção local.

Os 25 idiomas europeus suportados incluem: búlgaro, croata, tcheco, dinamarquês, holandês, inglês, estoniano, finlandês, francês, alemão, grego, húngaro, italiano, letão, lituano, maltês, polonês, português, romeno, eslovaco, esloveno, espanhol, sueco, russo e ucraniano. Isso elimina a necessidade de modelos separados ou configurações específicas por idioma ao atender economias europeias internacionais.

Para implantação na AWS, o modelo requer instâncias com GPU e no mínimo 4 GB de VRAM, embora 8 GB ofereçam melhor desempenho. As instâncias G6 (GPUs NVIDIA L4) apresentam a melhor relação custo-desempenho para cargas de inferência. O modelo também funciona bem em G5 (A10G), G4dn (T4) e, para máximo throughput, P5 (H100) ou P4 (A100).

Arquitetura da solução

O fluxo começa quando um arquivo de áudio é enviado para um bucket do Amazon Simple Storage Service (Amazon S3). Esse upload dispara uma regra do Amazon EventBridge, que submete um job ao AWS Batch. O Batch provisiona os recursos de computação com GPU, e as instâncias provisionadas puxam a imagem de container — com o modelo já em cache — do Amazon Elastic Container Registry (Amazon ECR). O script de inferência baixa e processa o arquivo de áudio, e depois envia o transcript em JSON com timestamps para um bucket S3 de saída.

A arquitetura escala a zero quando ociosa, ou seja, custos são gerados apenas durante a computação ativa. Para uma análise aprofundada dos componentes arquiteturais gerais, a AWS referencia o post anterior sobre transcrição de áudio com Whisper usando AWS Batch e AWS Inferentia.

Pré-requisitos

• Crie uma conta AWS se ainda não tiver uma e faça login.
• Crie um usuário com permissões de administrador completo usando o AWS IAM Identity Center, conforme descrito em Adicionar usuários.
• Instale a Interface de Linha de Comando da AWS (AWS CLI) em sua máquina local e crie um perfil para o usuário administrador, conforme descrito em Configurar a AWS CLI.
• Instale o Docker em sua máquina local.
• Clone o repositório no GitHub para sua máquina local.

Construindo a imagem de container

O repositório inclui um Dockerfile que constrói uma imagem de container otimizada para performance de inferência. A imagem usa o Amazon Linux 2023 como base, instala o Python 3.12 e faz o cache do modelo Parakeet-TDT-0.6B-v3 durante o build — eliminando a latência de download em tempo de execução:

FROM public.ecr.aws/amazonlinux/amazonlinux:2023
WORKDIR /app

# Install system dependencies, Python 3.12, and ffmpeg
RUN dnf update -y && \
    dnf install -y gcc-c++ python3.12-devel tar xz && \
    ln -sf /usr/bin/python3.12 /usr/local/bin/python3 && \
    python3 -m ensurepip && \
    python3 -m pip install --no-cache-dir --upgrade pip && \
    dnf clean all && rm -rf /var/cache/dnf

# Install Python dependencies and pre-cache the model
COPY ./requirements.txt requirements.txt
RUN pip install -U --no-cache-dir -r requirements.txt && \
    rm -rf ~/.cache/pip /tmp/pip* && \
    python3 -m compileall -q /usr/local/lib/python3.12/site-packages

COPY ./parakeet_transcribe.py parakeet_transcribe.py

# Cache model during build to eliminate runtime download
RUN python3 -c "from nemo.collections.asr.models import ASRModel; \
    ASRModel.from_pretrained('nvidia/parakeet-tdt-0.6b-v3')"

CMD ["python3", "parakeet_transcribe.py"]

Enviando a imagem para o Amazon ECR

O repositório inclui um script updateImage.sh que detecta o ambiente (CodeBuild ou EC2), constrói a imagem, cria um repositório ECR se necessário, habilita o escaneamento de vulnerabilidades e faz o push da imagem. Para executá-lo:

./updateImage.sh

Implantando a solução

A solução usa um template do AWS CloudFormation (deployment.yaml) para provisionar a infraestrutura. O script buildArch.sh automatiza a implantação detectando a Região AWS, coletando informações de VPC, sub-redes e grupos de segurança, e implantando a stack do CloudFormation:

./buildArch.sh

Internamente, esse script executa:

aws cloudformation deploy --stack-name batch-gpu-audio-transcription \
  --template-file ./deployment.yaml \
  --capabilities CAPABILITY_IAM \
  --region ${AWS_REGION} \
  --parameter-overrides VPCId=${VPC_ID} SubnetIds="${SUBNET_IDS}" \
  SGIds="${SecurityGroup_IDS}" RTIds="${RouteTable_IDS}"

O template do CloudFormation cria: o ambiente de computação do AWS Batch com instâncias GPU G6 e G5; uma fila de jobs; uma definição de job referenciando a imagem ECR; buckets S3 de entrada e saída com notificações do EventBridge habilitadas; uma regra do EventBridge que dispara um job do Batch no upload ao S3; configuração do agente do Amazon CloudWatch para monitoramento de GPU, CPU e memória; e Funções de Gerenciamento de Identidade e Acesso (IAM, do inglês Identity and Access Management) com políticas de privilégio mínimo.

O AWS Batch permite selecionar imagens Amazon Linux 2023 com GPU especificando ImageType: ECS_AL2023_NVIDIA na configuração do ambiente de computação.

Usando instâncias Spot para reduzir ainda mais os custos

As instâncias Amazon EC2 Spot permitem executar cargas de trabalho na capacidade ociosa da EC2 com descontos de até 90%, dependendo do tipo de instância. Para habilitá-las, basta modificar o ambiente de computação no deployment.yaml:

DefaultComputeEnv:
  Type: AWS::Batch::ComputeEnvironment
  Properties:
    Type: MANAGED
    State: ENABLED
    ComputeResources:
      AllocationStrategy: SPOT_PRICE_CAPACITY_OPTIMIZED
      Type: SPOT
      BidPercentage: 100
      InstanceTypes:
        - "g6.xlarge"
        - "g6.2xlarge"
        - "g5.xlarge"
      MinvCpus: !Ref DefaultCEMinvCpus
      MaxvCpus: !Ref DefaultCEMaxvCpus
      # ... remaining configuration unchanged

Isso pode ser ativado passando --parameter-overrides UseSpotInstances=Yes ao executar o aws cloudformation deploy. A estratégia SPOT_PRICE_CAPACITY_OPTIMIZED seleciona pools de instâncias Spot com menor probabilidade de interrupção e menor preço. Diversificar os tipos de instância (G6 xlarge, G6 2xlarge, G5 xlarge) melhora a disponibilidade Spot. Definir MinvCpus: 0 garante que o ambiente escale a zero quando ocioso. Como os jobs de ASR são stateless e idempotentes, eles são ideais para Spot — e se uma instância for reclamada, o AWS Batch automaticamente tenta novamente o job (configurado com até 2 tentativas na definição do job).

Gerenciando memória para áudios longos

O consumo de memória do modelo Parakeet-TDT escala linearmente com a duração do áudio. O encoder Fast Conformer precisa gerar e armazenar representações de features para todo o sinal de áudio — dobrar a duração do áudio dobra aproximadamente o uso de VRAM. Com atenção completa, o modelo consegue processar até 24 minutos com 80 GB de VRAM.

A NVIDIA endereça isso com um modo de atenção local que suporta até 3 horas de áudio em um A100 de 80 GB:

# Enable local attention for long audio
asr_model.change_attention_model("rel_pos_local_attn", [128, 128])
asr_model.change_subsampling_conv_chunking_factor(1)  # auto select
asr_model.transcribe(["input_audio.wav"])

Esse modo pode apresentar uma leve queda de precisão — recomenda-se testar no seu caso de uso específico.

Inferência em streaming com buffer para áudios muito longos

Para áudios que excedem 3 horas, ou para processar áudios longos de forma econômica em hardware padrão como uma instância g6.xlarge, a solução usa inferência em streaming com buffer. Adaptada do exemplo de inferência em streaming do NVIDIA NeMo, essa técnica processa o áudio em chunks sobrepostos em vez de carregar o contexto completo na memória.

A configuração utiliza chunks de 20 segundos com 5 segundos de contexto à esquerda e 3 segundos de contexto à direita para manter a qualidade da transcrição nas fronteiras dos chunks. Reduzir o tamanho do chunk aumenta o tempo de processamento, então é recomendado experimentar para encontrar a configuração ideal:

# Streaming inference loop
while left_sample < audio_batch.shape[1]:
    # add samples to buffer
    chunk_length = min(right_sample, audio_batch.shape[1]) - left_sample
    # [Logic to manage buffer and flags omitted for brevity]
    buffer.add_audio_batch_(...)
    # Encode using full buffer [left-chunk-right]
    encoder_output, encoder_output_len = asr_model(
        input_signal=buffer.samples,
        input_signal_length=buffer.context_size_batch.total(),
    )
    # Decode only chunk frames (constant memory usage)
    chunk_batched_hyps, _, state = decoding_computer(...)
    # Advance sliding window
    left_sample = right_sample
    right_sample = min(right_sample + context_samples.chunk, audio_batch.shape[1])

Processar o áudio em chunks de tamanho fixo desacopla o uso de VRAM da duração total do áudio — uma única instância g6.xlarge consegue processar um arquivo de 10 horas com o mesmo footprint de memória de um arquivo de 10 minutos. Para implantar com streaming habilitado, basta definir o parâmetro EnableStreaming=Yes:

aws cloudformation deploy \
  --stack-name batch-gpu-audio-transcription \
  --template-file ./deployment.yaml \
  --capabilities CAPABILITY_IAM \
  --parameter-overrides EnableStreaming=Yes \
  VPCId=your-vpc-id SubnetIds=your-subnet-ids SGIds=your-sg-ids RTIds=your-rt-ids

Testes, monitoramento e resultados

Para validar a solução em escala, foram processados 1.000 arquivos de áudio idênticos de 50 minutos — gravações de uma conferência de imprensa pré-voo da NASA — distribuídos em 100 instâncias g6.xlarge, cada uma processando 10 arquivos.

A implantação inclui uma configuração do agente do Amazon CloudWatch que coleta métricas de utilização de GPU, consumo de energia, uso de VRAM, utilização de CPU, consumo de memória e uso de disco em intervalos de 10 segundos. Essas métricas aparecem no namespace CWAgent, permitindo a criação de dashboards para monitoramento em tempo real.

Desempenho e análise de custos

O modelo Parakeet-TDT-0.6B-v3 atingiu uma velocidade de inferência bruta de 0,24 segundos por minuto de áudio. Considerando o overhead completo do pipeline (carregamento do modelo, carregamento do áudio, pré e pós-processamento), os resultados do benchmark em uma instância g6.xlarge foram:

• Duração do áudio: 3 horas e 25 minutos (205 minutos)
• Duração total do job: 100 segundos
• Velocidade efetiva de processamento: 0,49 segundos por minuto de áudio

Em termos de custo, com base nos preços da instância g6.xlarge na região us-east-1:

• On-Demand (~$0,805/hora): aproximadamente $0,00011 por minuto de áudio
• Spot Instances (~$0,374/hora): aproximadamente $0,00005 por minuto de áudio

Os preços são estimativas com base nas taxas da us-east-1 no momento da publicação original. Os preços Spot variam por Zona de Disponibilidade e estão sujeitos a mudanças.

Esses números evidenciam a vantagem econômica da abordagem self-hosted para cargas de trabalho de alto volume em comparação com serviços gerenciados de API.

Limpeza dos recursos

Para evitar cobranças futuras, é necessário excluir os recursos criados pela solução: esvaziar todos os buckets S3 (entrada, saída e logs) e deletar a stack do CloudFormation:

aws cloudformation delete-stack --stack-name batch-gpu-audio-transcription

Opcionalmente, remova o repositório ECR e as imagens de container. Para instruções detalhadas, consulte a seção de limpeza do README do repositório.

Conclusão

A combinação do modelo NVIDIA Parakeet-TDT-0.6B-v3 com o AWS Batch e as instâncias EC2 Spot resulta em um pipeline de transcrição de áudio capaz de processar em escala por frações de centavo por hora. Com suporte a 25 idiomas europeus — incluindo português — e detecção automática de idioma, a solução elimina a necessidade de modelos separados por idioma. A técnica de inferência em streaming com buffer estende essa capacidade para áudios de qualquer duração em hardware padrão, e a arquitetura orientada a eventos escala automaticamente do zero para lidar com cargas de trabalho variáveis.

O código de exemplo está disponível no repositório GitHub para quem quiser explorar e implementar a solução.

Fonte

Cost-effective multilingual audio transcription at scale with Parakeet-TDT and AWS Batch (https://aws.amazon.com/blogs/machine-learning/cost-effective-multilingual-audio-transcription-at-scale-with-parakeet-tdt-and-aws-batch/)