DEV Community: Pedro Christo

Transcrição de Audio Distribuído em OCI com Kubernetes + Whisper

Pedro Christo — Wed, 19 Mar 2025 23:37:28 +0000

Quando falamos de processamento de arquivos em larga escala, enfrentamos desafios bem conhecidos, como custos, gerenciamento de processamento distribuído, escalabilidade e eficiência. Além disso serviços de AI geralmente são cobrados por chamada ou quantidade de dados processado, tornando assim os custos de processamento de uma grande quantidade de dados economicamente inviável.

Para superar esses desafios e trazer uma maior soberania de dados, apresento um exemplo de arquitetura distribuída baseada em Kubernetes, orientada a eventos e alinhada aos princípios Cloud Native.

A proposta dessa arquitetura é transcrever um grande volume de arquivos de áudio, otimizando ao máximo o uso da GPU de forma simples sem a necessidade de frameworks específicos.

Para isso, vamos utilização uma solução orientada a eventos baseada em serviços nativos do OCI para emitir eventos e enfileirar as tarefas de transcrição dos arquivos.

Os códigos em Python e instruções para realizar o deploy estão disponíveis neste repositório no GitHub.

Código

O código, escrito em Python, lê os nomes dos arquivos diretamente do OCI Stream ou OCI Queue paralelamente é feito o download dos arquivos que depois são transcritos.

A transcrição é realizada por meio do Faster Whisper , utilizando o modelo large-v3. Os resultados são salvos em um Object Storage de saída.

Esse código é executado no OKE (Oracle Kubernetes Engine) , com as permissões necessárias para ler e escrever arquivos no Object Storage.

Fluxo da Arquitetura

Um arquivo de áudio é carregado em um bucket de entrada na Oracle Cloud.
Esse bucket emite um evento de criação de arquivo.
O serviço OCI Events captura esse evento e inicia uma ação.
A ação pode ser o envio do evento para um OCI Stream ou a inicialização de uma função para enviar o evento para o OCI Queue.
Um pod no OKE lê os eventos do Stream ou Queue e inicia o processo de transcrição de cada áudio.
As transcrições resultantes são salvas em um bucket de saída.

Porque Kubernetes?

O Kubernetes é a plataforma de gerenciamento e execução de contêineres mais amplamente utilizada no mundo. Além disso, é uma das ferramentas fundamentais para projetos Cloud Native, sendo gerenciada pelo CNCF (Cloud Native Computing Foundation).

Kubernetes oferece resiliência e escalabilidade nativas. Caso ocorra alguma falha no nível de nó ou contêiner, novos recursos são criados automaticamente para garantir a continuidade do workload.

Neste caso específico, utilizamos o OKE (Oracle Kubernetes Engine) com Managed Nodes e um cluster configurado com GPU A10.1. Este modelo de GPU disponibiliza apenas um chip gráfico, sem suporte ao MIG (Multi-Instance GPU). No entanto, isso não impede a criação de paralelismo a nível de contêiner.

Otimização do uso de GPU

Como mencionado, a arquitetura utiliza um modelo de GPU com apenas um chip, sem suporte ao MIG. Portanto, o paralelismo deve ser implementado no nível de código.

Para resolver esse problema, o PyTorch Cuda Stream cai como uma luva. Permitindo o processamento paralelo de vários arquivos com apenas um carregamento de modelo da GPU.

A GPU A10.1 possui 24 GB de memória. O modelo Faster Whisper large-v3 , com precisão de float16, consome entre 3 e 7 GB de VRAM durante a inferência, dependendo do tamanho do arquivo processado. Com base nisso, é possível processar até três arquivos simultaneamente, com uma perda de desempenho aceitável no tempo de processamento nos picos de utilização.

Testes e Resultados

Os testes foram feitos processando o mesmo arquivo de 11 minutos, foram processados 20 arquivos iguais em cada cenário de teste dividido em 3 cenários diferentes. 1 arquivo por vez e série; 2 arquivos por vez em paralelo e 3 arquivos por vez em paralelo.

Conseguindo os seguintes resultados:

Arquivos em Paralelo	Tempo medio em Segundos
1	9,988s
2	15s
3	18.104s

Conclusão

Com essa abordagem, conseguimos maximizar o uso da GPU, garantir alta escalabilidade e manter uma arquitetura resiliente e eficiente para processamento de arquivos em larga escala. Além disso simplifica por usar ferramentas nativas da Oracle Cloud sem a necessidade de Frameworks específicos de AI para processamento distribuído.

DevOps - Não só mais um artigo

Pedro Christo — Tue, 10 Dec 2024 20:12:23 +0000

Introdução

A ideia desse artigo é manter viva e fortalecer conceitos básicos que lidamos no dia a dia de programação moderna. Nos últimos meses é possível ver um crescimento exponencial de artigos e publicações voltadas para AI. Mas e os outros assuntos associados a TI?

Continuam sendo muito relevantes e sendo aplicados diretamente no dia a dia.

Esse primeiro artigo é um compromisso de uma séria sobre Cloud Native e conceitos importantes sobre padrões de arquiteturas e casos de uso.

Procura tratar esses assuntos de forma simples e bem-humorada, sem muita preocupação com o tecniquês ou o uso de LLMs gerar textos.

DevOps

DevOps é um termo que já teve seu momento de buzzword, gerando intermináveis artigos e publicações sobre o assunto. Sendo um tema muito importante incorporado no ciclo de desenvolvimento de deploy de aplicações por inúmeras empresas de todo tipo de indústria que se pode imaginar.

A pergunta que não quer calar, o que é DevOps?

Representa uma profissão, às vezes alguma ferramenta específica, mas o mais importante uma cultura. Sim, a cultura de simplificar e automatizar os processos voltados ao desenvolvimento.

É isso, quem queria uma definição de uma frase pode dar um scroll no artigo até o fim e fingir que leu e depois fechar a aba. Mas o que mais podemos falar sobre devops?

Conceito

A ideia central da cultura Devops é aproximar as pessoas que escrevem os códigos, famosos Devs, das pessoas que colocam o código para rodar e fazem o monitoramento da execução nos servidores, nem tão famosos times de operações ou simplesmente OPS.

Lindo o conceito, mas por que aproximar essa galera não é tudo do time de TI?

Essa necessidade veio do mercado em si do consumidor final. Existe a urgência latente do ser humano moderno de sempre ter a correção de erros e a melhor versão no menor tempo possível. O termo bonito para isso é time to market, que nada mais é que o tempo de um produto ser feito ou atualizado e lançado ao consumidor final.

É um reflexo do mundo de serviços do mundo atual, muita tecnologia e pouca paciência. Se um serviço de Streaming, por exemplo, demora a fazer o login já pulamos para outro que está funcionando sem cerimônia.

Com motivação de liberar as novas versões dos aplicativos o mais rápida possível, foi surgindo um movimento dos profissionais de TI, os quais melhoram a gestão de desenvolvimento e deploy das aplicações para reduzir os ciclos de programação e ter melhor monitoramento dessas aplicações.

Os ciclos de desenvolvimento ficam mais integrados e automatizados, tornando mais simples o fluxo de desenvolvimento, teste, deploy e monitoramento. E é isso é exatamente o que você está pensando, aquele desenho clássico do infinito com os passos do DevOps, ele faz muito sentido, mas nem sempre foi assim.

Você deve estar pensando que agora seria o momento de contar a história da evolução das metodologias de desenvolvimento, mas esse não é o objetivo aqui hoje. Mas é importante saber que essas mudanças de paradigma partem da comunidade e de profissionais de TI que identificam o problema no dia de trabalho e se uniram para resolver e testar novas propostas.

Nos últimos anos o conceito de DevOps expandiu e foi evoluindo para áreas específicas como DevSecOps onde a segurança é parte central do fluxo de desenvolvimento e deploy, MLOps voltado para os pipelines de Machine Learning, DataOps que são desenvolvidos pipelines de dados, entre outros Ops da vida.

Ferramentas

Agora que já mostramos o que é e o porquê, vamos falar sobre as ferramentas que ajudaram a construir as ideias e a cultura DevOps.

Primeiro vem a criação e a implementação de metodologia ágeis como Scrum e Kanban. Essas metodologias ajudam a organizar o ciclo de desenvolvimento mais curto e a paralelizar as tarefas dos desenvolvedores.

Aliado as metodologias ágeis também surgiram a popularização de softwares de controle de código como GIT e SVN, que além de rastreabilidade possibilitado o trabalho de vários devs em um único código-fonte, trazendo dor de cabeça para quem aprova os PRs (Pull Requests) para torcer para a junção dos códigos, famoso merge, não de problema.

E por fim, as ferramentas que geram muitos empregos que são as de automação de Build e Deploy famosas ferramentas de CI/CD, Continuous Integration e Continuous Deploy/Delvery. Essas ferramentas são responsáveis por pegar o código buildar, gerando artefatos ou containers, e colocar as aplicações para executar no servidor final.

Desafios

O maior desafio no processo de adoção de DevOps é pelo seu caráter cultural e não tecnológico. Então processos precisam ser revistos e automatizados, equipes precisam ser reestruturadas e é claro é necessário da escolha e adoção das ferramentas corretas conforme a necessidade e o momento de cada empresa.

Criar uma equipe ou projeto do zero já adotando o DevOps é um processo muito mais simples. E é geralmente utilizado como piloto em grandes empresas para desenvolver novas ferramentas e funcionalidades.

Outro desafio é superar a cultura do GO HORSE, que é basicamente "Faça o que eu mando porque eu quero". Essa é a metodologia mais comum do que vocês imaginam nas empresas. Se no dia a dia já não se seguem processos em um momento de crise é trocar o pneu com o carro andando, ou mexer no código de produção enquanto seu diretor está à espera de um milagre em um domingo à noite.

Conclusão

Considerando os desafios de mudança cultura que podem ter muitos opositores em uma organização. DevOps traz uma solução moderna para problemas modernos. E isso tudo impulsionado pela adoção de arquiteturas mais modernas como microsserviços que exigem um ciclo menor de desenvolvimento, vem se tornando um padrão cultural e guia nas empresas.