Grandes aglomerados para pequenos modelos — Daniel Svonava, Superlinked
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00Revisora: Denise RQ
00:00:12Tudo bem.
00:00:14Acho que vocês conseguem me ouvir.
00:00:15Eu com certeza consigo me ouvir.
00:00:19Quem chegou mais perto ganha uma camiseta.
00:00:21É sério.
00:00:22Tem tipo uma sacola cheia de camisetas bem aqui.
00:00:25E também para quem fizer perguntas.
00:00:26Talvez a gente tenha algumas perguntas no final.
00:00:28Se você fizer uma pergunta, também ganha uma camiseta.
00:00:31E se você adivinhar o que está no fundo deste slide,
00:00:35você também ganha uma camiseta.
00:00:39Algum palpite?
00:00:42O que isso visualiza?
00:00:44Esta imagem no fundo.
00:00:49Ninguém?
00:00:50Alguém já viu um modelo transformer?
00:00:55Isso, codificação posicional.
00:00:57Muito bem.
00:00:58Você ganhou a camiseta, meu caro.
00:00:59Tudo bem.
00:01:00Então hoje vamos discutir basicamente modelos open source pequenos, como eles estão muito bons agora e como criam desafios únicos quando você quer servir vários deles na sua própria nuvem.
00:01:15Tudo o que vamos discutir é de código aberto.
00:01:19Faça você mesmo.
00:01:20Esse é o tipo de coisa que você pode simplesmente, sabe, rodar um comando e ser dono de toda a infraestrutura.
00:01:26Então não há peças proprietárias neste quebra-cabeça.
00:01:31Vamos começar.
00:01:33Certo.
00:01:34Certo.
00:01:35Isso funciona.
00:01:36Certo.
00:01:37Modelos pequenos.
00:01:38O que queremos dizer com modelos pequenos?
00:01:40Sabe, dependendo de quem você perguntar, a forma como eu penso sobre isso é basicamente modelos que você pode rodar em hardwares NVIDIA de duas ou três gerações atrás.
00:01:49O modelo inteiro cabe em uma única GPU e, portanto, eles são fáceis de servir.
00:01:56Essas GPUs estão disponíveis e também são acessíveis.
00:02:01E aí a maioria das pessoas pensa: ok, modelos pequenos, deve haver algum tipo de perda na qualidade dos resultados.
00:02:10E espero conseguir fazer um bom trabalho nesta palestra para convencer vocês de que, na verdade, para tarefas específicas, dá para ter um desempenho de ponta ou superior e obter todos os outros benefícios óbvios, certo?
00:02:22Ordens de grandeza de economia de custos e, potencialmente, melhorias bem grandes de latência ou vazão, é claro.
00:02:35Então este é um dos gráficos que a gente gosta de mostrar.
00:02:38Este é o índice de inteligência do Artificial Analysis ao longo do tempo.
00:02:42E o que eles geralmente não mostram é que há uma divisão dos modelos open source em que você deveria pensar, certo?
00:02:49Tem o GLM 5.2 e assim por diante, esses modelos open source de ponta com, digamos, 750 bilhões de parâmetros.
00:02:57Mas aí tem os modelos open source pequenos que vêm logo atrás dos grandes e da fronteira da tecnologia.
00:03:04Dá para ver que o estado da arte está tendo retornos decrescentes hoje em dia, e os modelos pequenos estão alcançando, certo?
00:03:10Então você vê esse tipo de convergência, uma saturação no topo e o crescimento dos modelos pequenos.
00:03:16E, digamos, o Qwen 3.5 27B fica em algum lugar perto do desempenho do GPT-4o.
00:03:23Então, se você tem um fluxo de trabalho, uma pipeline que roda com o GPT-4o,
00:03:29agora você pode migrá-la para um modelo pequeno e ter todos os benefícios que discutimos.
00:03:35Então, modelos pequenos não deixam nada a desejar.
00:03:38Agora, também depende de como você usa esses modelos pequenos, certo?
00:03:44Você não pode encarar esse Qwen 3.5 de 27 bilhões de parâmetros como aquele modelo totalmente generalista a quem você pede qualquer coisa por prompt.
00:03:53Não, você precisa adotar uma abordagem em que basicamente divide a carga de trabalho do modelo generalista em tarefas menores.
00:04:00E aí, para cada tarefa, você descobre qual modelo open source se encaixa melhor.
00:04:05Você roda algumas avaliações, talvez faça alguma adaptação que vamos discutir.
00:04:08E então, sabe, é assim que você atinge a qualidade certa para realmente colocar isso em produção.
00:04:15Aqui temos um exemplo de agente de revisão de contratos que usa nove modelos diferentes.
00:04:20Esse é o tipo de estrutura que você verá nas suas cargas de trabalho e nos seus agentes ao passar a usar modelos pequenos na sua arquitetura.
00:04:28Você vai começar a ver que, em vez de bombardear uma API com um monte de requisições diferentes ou usar um único modelo,
00:04:36é preferível usar um frota de modelos.
00:04:38E aí o seu problema passa a ser: ok, como eu sirvo todas essas coisas diferentes sem enlouquecer o pessoal de infraestrutura, né?
00:04:45E este é apenas um dos agentes que você pode estar rodando.
00:04:48E pode haver, sei lá, 10 desses na sua empresa.
00:04:51Então, como a gente lida com essa expansão do escopo de infraestrutura, por assim dizer?
00:04:57Agora, para todas essas tarefas diferentes que mencionei, existe um modelo open source pronto e esperando para ser usado.
00:05:05Desde OCR até resposta a perguntas sobre documentos, rotulagem de imagens, geração de SQL e revisão de código.
00:05:14Existem modelos open source ajustados e treinados para essas tarefas.
00:05:19Se você usa um modelo open source treinado para fazer OCR em recibos em vietnamita, esse projeto foi o que mais processou recibos em vietnamita, sabe?
00:05:28Alguém se deu ao trabalho de coletar o máximo de dados possível.
00:05:32E nessa tarefa específica, esse modelo vai superar quase qualquer outro.
00:05:35E existem centenas de milhares de modelos no Hugging Face exatamente assim, entende?
00:05:41Então está tudo lá à disposição e é de graça, basicamente, na maioria com licenças bem permissivas.
00:05:46Então os modelos existem, esse não é o gargalo.
00:05:50E, bom, a gente vem falando sobre IA open source desde 2024.
00:05:56E até agora isso ainda não engrenou de verdade.
00:05:59E na medida em que acontece nas empresas, basicamente IA open source virou sinônimo de AWS Bedrock.
00:06:05Acontece que, quando você olha o catálogo de modelos no Bedrock, ele é super limitado nos tipos de modelos disponíveis.
00:06:14Esses modelos costumam ser antigos, às vezes dois ou três anos atrás do estado da arte.
00:06:19E quando você faz qualquer tipo de ajuste fino no Bedrock, você na verdade não é dono dos artefatos treinados ou ajustados.
00:06:25Então você não pode usar isso como uma vantagem real no seu negócio.
00:06:29Ele fica rodando preso à infraestrutura do Bedrock.
00:06:32Mas se sairmos do proprietário e formos servir modelos pequenos em infraestrutura open source, tipo vLLM, SGLang ou outras soluções,
00:06:41saiba que essas ferramentas não vêm otimizadas para nenhum modelo específico nem para combinações específicas de modelo e hardware.
00:06:48Você vai ter que fazer a otimização na raça.
00:06:51Todas essas ferramentas vêm com guias de como fazer a otimização, a varredura de parâmetros, a adaptação ao seu tráfego e tudo mais.
00:07:00Isso se torna um projeto de pesquisa meio sem fim toda vez que você tenta adotar uma dessas ferramentas.
00:07:05Então não é algo que você simplesmente pega e trata como um projeto de engenharia comum,
00:07:10onde uma semana depois você já tem uma infraestrutura de serviço de alto desempenho.
00:07:14Não funciona assim.
00:07:15E esse é o problema típico das ferramentas de código aberto, né?
00:07:19É um trabalho artesanal meio exagerado.
00:07:21E além de não vir pré-otimizado para modelos pequenos, a carga de trabalho e o tráfego que utilizam vários modelos diferentes
00:07:32acabam invertendo a lógica dos clusters de inferência, sabe?
00:07:37Normalmente, ao tentar servir um modelo grande, seu problema é: como distribuir esse modelo entre várias GPUs?
00:07:44Como colocar um roteador por cima que entenda o estado de todos esses workers, como o estado do KV Cache e tudo mais,
00:07:51e tome uma decisão de roteamento centralizada de enviar essa requisição para tal worker ou grupo de workers, entende?
00:07:59É uma arquitetura totalmente centralizada.
00:08:01Mas se você tem requisições pequenas e rápidas em grande volume, esse roteamento centralizado vira o gargalo, né?
00:08:09Porque o roteador tem uma visão um pouco desatualizada do estado dos workers, e fica muito difícil usar a capacidade máxima das GPUs
00:08:16quando você tem essa decisão prévia no topo que precisa acertar perfeitamente o balanceamento das filas locais em cada worker.
00:08:26Afinal, são muitas requisições pequenas.
00:08:29E a gente testou roteadores vLLM e SGLang para modelos pequenos com esse tipo de tráfego,
00:08:37e é muito difícil passar de 20% ou 30% de uso da GPU sob carga constante.
00:08:44E o problema é que esses lotes não ficam dimensionados corretamente devido a esse gargalo de roteamento.
00:08:51O terceiro problema é que, com modelos pequenos, você se beneficia muito de LoRAs e da adaptação de modelos em geral.
00:08:57Então o tráfego a ser servido envolve pessoas chegando para você e dizendo:
00:09:03"Ei, tenho 10 LoRAs. Como eu coloco isso na nossa infraestrutura de serviço?"
00:09:08Ou: "Fiz esse ajuste fino personalizado ontem à noite. Quero colocar isso em produção."
00:09:14E essa conversa entre o engenheiro de IA e o responsável pela infraestrutura para colocar esses LoRAs no ar,
00:09:21ou subir esses modelos customizados, é o que gasta tempo.
00:09:24E, no fundo, o maior vilão da agilidade organizacional é justamente a necessidade de tanta conversa, né?
00:09:30O ideal seria que os engenheiros de infraestrutura fizessem o trabalho deles, e os engenheiros de IA o deles.
00:09:37E que eles não precisassem ficar alinhando coisas no dia a dia para operar.
00:09:41Para que ninguém fique bloqueando o trabalho do outro.
00:09:45E essa necessidade de adaptação nos modelos pequenos quebra isso e gera um vai e vem enorme.
00:09:51E isso é um problema, né?
00:09:54Então esses são alguns desafios relacionados a: ok, temos vários modelos pequenos.
00:09:58Como ter um cluster? Como servir isso de forma eficiente?
00:10:02Então viemos trabalhando nesse problema há um tempo.
00:10:05Eu sou o Daniel, na verdade, da Superlinked. Acabei pulando a apresentação.
00:10:09Nós somos uma empresa financiada por capital de risco com sede em São Francisco.
00:10:13E nos últimos anos, construímos sistemas de busca, processamento de documentos e agentes alimentados por IA.
00:10:20E nossa maior dor sempre foi a inferência, especificamente os problemas que descrevi.
00:10:26Então iteramos muito e exploramos diferentes topologias de cluster para rodar frotas amplas de modelos pequenos em ambientes variados.
00:10:37Porque às vezes você precisa implantar junto com alguma plataforma num ambiente onde não se sabe o que está disponível.
00:10:44Os modelos pequenos facilitam, pois obter algumas L4s ou uma pequena cota de GPU em qualquer ambiente é muito mais fácil.
00:10:52Então é isso — vou descrever um pouco a topologia de cluster que convergimos para usar.
00:10:58A propósito, tudo isso é Apache 2.0, totalmente código aberto.
00:11:03Vocês podem simplesmente pegar, empacotar e virar uma startup de inferência.
00:11:08É código aberto desde o plano de controle até o que roda na GPU.
00:11:14Então não economizamos em nada.
00:11:18E a topologia basicamente consiste em um gateway.
00:11:21E em vez de ter um roteador que pré-determina o destino, há um gateway que analisa as requisições e anexa metadados.
00:11:30Ele insere a requisição em uma fila compartilhada e em alguns canais secundários.
00:11:36Vou detalhar isso um pouco.
00:11:37E aí os workers puxam dessa fila centralizada, em vez de empurrar dados para eles.
00:11:44Dessa forma, eles conseguem se saturar melhor.
00:11:47E a estrutura dos workers — acho que tenho um slide para isso — vai mostrar como absorvemos a complexidade de diferentes arquiteturas
00:11:57em um conjunto coerente de workers que não têm conflitos de requisitos do Python e coisas do tipo.
00:12:03Essa é a topologia geral.
00:12:06E este é o ciclo de vida de uma requisição.
00:12:11Vou destacar só algumas coisas aqui.
00:12:15Uma coisa que não gostamos no padrão de API da OpenAI é o JSON codificado em base64.
00:12:25Não é bom para modelos pequenos nem para alto rendimento.
00:12:28Então usamos MessagePack em tudo, que é um formato binário.
00:12:31Assim, também conseguimos passar todos os dados multimodais diretamente pelo API gateway.
00:12:37Evita aquilo de: dados binários por aqui e a requisição por ali.
00:12:42E aí o cluster precisar de acesso ao seu armazenamento em nuvem para carregar dados binários, imagens ou vídeos.
00:12:48Codificamos tudo e enviamos pelo gateway.
00:12:53O gateway separa as partes mais pesadas para não travar a fila interna e as adia no armazenamento em nuvem enquanto a requisição aguarda.
00:13:02Ele divide requisições maiores que um megabyte e usa o armazenamento em nuvem no backend.
00:13:09Mas, para o usuário, você envia todos os seus bytes para a camada de API e a interface fica bem limpa.
00:13:19Basicamente toda a pilha é REST: gateway em REST, worker em REST, e via socket local ele se conecta a diferentes runtimes.
00:13:30Temos basicamente PyTorch, Candle e SGLang como runtimes.
00:13:35E quando fazemos a otimização, vou explicar como garantimos que o runtime utilizado
00:13:43e o código executado nele sejam os mais eficientes possíveis.
00:13:47Temos um ciclo de pesquisa automatizada para isso.
00:13:50Então o ciclo de vida de uma requisição é basicamente esse.
00:13:54Um detalhe importante é garantir que o gateway, que recebe o primeiro impacto da requisição, não faça trabalho demais.
00:14:05Caso contrário, ele vira um gargalo, certo?
00:14:07Você nem quer analisar a requisição inteira.
00:14:09O ideal é olhar os pacotes, entender o formato geral do que está vindo, fazer a anotação,
00:14:16e aí os workers, sejam quantos forem em centenas de GPUs, checam o estado da fila e puxam dali.
00:14:25A fila usa NATS JetStream, que consegue processar um milhão de requisições por segundo.
00:14:32É muito difícil isso virar um gargalo.
00:14:35O ideal é não ficar serializando e deserializando ao passar por todos esses componentes.
00:14:42Isso é o básico e mais óbvio.
00:14:45Esta é uma animaçãozinha que mostra a ideia por trás do enfileiramento centralizado.
00:14:51Em vez de um roteador tentar preencher as filas locais perfeitamente, o que é praticamente impossível,
00:15:01a ideia é centralizar a fila e deixar que os workers assumam a tarefa de montar os próprios lotes,
00:15:09prevendo o custo do lote e se tornando muito mais eficientes.
00:15:15Um detalhe importante: ao trabalhar nisso, percebe-se que é muito difícil prever quantos itens pegar da fila compartilhada para o lote ter o tamanho ideal.
00:15:30Por isso, é bom ter um mecanismo que permita devolver alguns itens para a fila
00:15:35caso perceba que pegou um pouco a mais.
00:15:37E isso gera tráfego de rede, né?
00:15:39Aí temos um problema.
00:15:40Temos uma otimização especial para máquinas com múltiplas GPUs locais.
00:15:46Há um elemento de fila local na máquina que aproveita o fato de que os processos locais nas GPUs da mesma máquina negociam com a fila,
00:15:59coisa que pela rede adicionaria milissegundos extras de latência.
00:16:03Então não fazemos isso pela rede, apenas quando alocamos os workers em máquinas com várias GPUs.
00:16:11E não estamos falando de diferenças pequenas de 5%, sabe?
00:16:16Ao centralizar a fila, você dobra o rendimento do cluster.
00:16:19É uma diferença significativa.
00:16:22Mencionei três runtimes diferentes.
00:16:25Basicamente, para modelos encoder-only, escrevemos o código em PyTorch.
00:16:33Nós o otimizamos e temos um ciclo de pesquisa automatizada que cuida disso.
00:16:38O mesmo vale para o Candle.
00:16:39Começamos a mexer com o Candle há pouco tempo.
00:16:42Ainda não conseguimos um desempenho próximo ao do PyTorch.
00:16:45Então é mais um projeto de pesquisa.
00:16:47A questão são as dependências; a imagem Docker do worker com PyTorch tem uns 12 gigabytes.
00:16:54Já o binário estático do worker com Candle tem cerca de 10% disso.
00:17:01E se você se importa em inicializar do zero e carregar essas imagens em várias máquinas,
00:17:08reduzir de 12 gigas para 1 gigabyte faz uma enorme diferença.
00:17:13Essa é a motivação por trás do Candle.
00:17:15O difícil é alcançar o mesmo desempenho do PyTorch.
00:17:20E temos o SGLang como uma referência padrão.
00:17:25Devemos ter um desempenho no mínimo igual ao do SGLang com o ajuste ideal de todos aqueles parâmetros.
00:17:34Aqui estão alguns números.
00:17:37Quando empacotamos o SGLang com o socket e nosso sidecar em Rust,
00:17:43conseguimos superar o desempenho do SGLang puro porque fazemos algo no agrupamento em lotes que ele não faz nativamente.
00:17:54E provavelmente dá para fazer isso.
00:17:57Desenvolvendo plugins personalizados para o SGLang,
00:18:00daria para igualar nosso desempenho, afinal
00:18:04basta aplicar a mesma lógica no servidor principal do SGLang.
00:18:07Mas aí você estaria criando código personalizado exclusivo para o SGLang.
00:18:11E a lição dos modelos pequenos é que os runtimes são extremamente diversos.
00:18:16Você não quer ficar preso a um runtime específico, pois temos,
00:18:22acho que cerca de 50 adaptadores diferentes parametrizados para os modelos.
00:18:28Então é preciso lidar com essa complexidade subjacente de alguma forma.
00:18:32E isso provavelmente não se faz criando vários plugins para um único runtime,
00:18:36mas sim com abstração — no nosso caso, o conceito de sidecar em Rust e o socket.
00:18:47Agora falarei sobre alguns números, mas quanto ao termo usado em testes de desempenho,
00:18:53a “curva” é o conceito de quando você aumenta o tráfego no servidor,
00:18:57exigindo cada vez mais rendimento dele,
00:19:01e ele entrega mais rendimento, subindo de forma linear.
00:19:05Mas chega um ponto em que você pede mais e ele não entrega.
00:19:09Ele estabiliza e a latência aumenta.
00:19:12Chamamos isso de “curva de saturação”, um conceito útil em benchmarks
00:19:17porque representa o ponto de saturação.
00:19:20É o desempenho máximo sem comprometer a latência.
00:19:23Para vocês terem uma ideia do que é possível em hardwares relativamente pequenos
00:19:32e com diferentes tipos de modelos pequenos:
00:19:34isso foi medido na RTX Pro 6000.
00:19:37Trabalhamos com NVIDIA L4, A100s, RTX Pro 6000, H100, nessa faixa.
00:19:46Essas GPUs são muito mais acessíveis sob demanda em qualquer nuvem.
00:19:52A maioria dos continentes tem cota disponível.
00:19:56Nesse tipo de estrutura, para modelos de embedding,
00:20:01mesmo nos de centenas de milhões de parâmetros,
00:20:05dá para codificar centenas de milhares de tokens por segundo no embedding.
00:20:12Então imagine você aí agora, requisitando sua árvore de embeddings de texto na API da OpenAI.
00:20:17Em vez disso, você poderia ter uma única GPU e enviar meio milhão de tokens por segundo para ela e obter os vetores.
00:20:26Certo?
00:20:28Tipo, isso faz sentido, né?
00:20:31Você tem meio milhão de tokens por segundo sendo enviados para uma única GPU, que nem é tão grande assim,
00:20:38enquanto obtém vetores de embedding para o seu sistema de busca, em vez de enviar tudo isso para um endpoint gerenciado em algum lugar e pagar ordens de grandeza a mais.
00:20:49Certo?
00:20:50E você pode obter latências de, tipo, poucas dezenas de milissegundos para essas chamadas, sabe?
00:20:55Tipo, se você usa APIs da Cohere, OpenAI e assim por diante, são centenas de milissegundos, certo?
00:21:02E isso não é nenhum bicho de sete cabeças.
00:21:03Sabe, você pode ter uma redução absurda de custos, melhorias gigantescas na latência e uma operação relativamente simples com poucos GPUs e alguma infraestrutura em volta, né?
00:21:17Então essa é uma oportunidade imperdível; se você for começar em qualquer lugar com modelos open source ou modelos pequenos, embeddings são a escolha óbvia, né?
00:21:26Mas não para por aí.
00:21:27Então digamos que você queira analisar o reconhecimento de entidades nomeadas.
00:21:33Quer analisar, digamos, busca multivetorial, até mesmo geração, né, de texto ou saídas estruturadas e assim por diante.
00:21:42Você pode obter, sabe, milhares de tokens por segundo de saída também de modelos generativos específicos para tarefas, como cerca de 500 por segundo em uma GPU ali embaixo.
00:21:58E aí, digamos que você esteja gerando dados sintéticos ou anotações para o seu fine-tuning, para as suas avaliações... sabe, não faça isso em um endpoint gerenciado.
00:22:11Essa é uma tarefa perfeita porque você tem o controle da situação.
00:22:14Você pode monitorar a qualidade.
00:22:16Essa é uma tarefa perfeita para um modelo open source na sua própria infraestrutura.
00:22:20E aí, sabe, se a infraestrutura que você tem em volta dessas GPUs for razoável, você terá um dimensionamento linear com o número dessas GPUs.
00:22:31Agora, outra ideia, se você gosta de servir modelos pequenos, é que você não... sabe, normalmente, você tem um pool de workers por modelo, certo?
00:22:44Você tem um conjunto de workers, um conjunto de nós, eles têm GPUs, você meio que os inicializa e pré-carrega os modelos.
00:22:51Os modelos levam dezenas de minutos para carregar porque têm centenas de bilhões de parâmetros.
00:22:55E aí você fica feliz, “beleza, finalmente carregou, agora tenho um pool de workers”.
00:22:59Essa mentalidade não funciona muito bem com modelos pequenos.
00:23:02Sim, sim, rapidinho.
00:23:04Como... quanto tempo resta?
00:23:06Passou seis minutos.
00:23:07Ah, seis minutos estourados.
00:23:08Tudo bem.
00:23:09Certo.
00:23:10Então, agrupar modelos na mesma GPU é mais rápido.
00:23:12Esta é uma história de como você ainda quer fixar alguns modelos, mas também quer fazer basicamente carregamento preguiçoso e despejo em função da pressão de memória.
00:23:26Você quer descobrir como combinar os dois.
00:23:28Aqui tem um pouco sobre pesquisa automatizada.
00:23:32Temos loops de pesquisa automatizada para adicionar suporte a novos modelos e melhorar o desempenho deles.
00:23:39Criamos várias ferramentas internas para fazer medições e alimentar esses loops de pesquisa automatizada, avançando com os números.
00:23:47E talvez o mais importante: quando lançamos o suporte a um modelo, ele já vem totalmente otimizado, certo?
00:23:53Então não tem essa de “vamos fazer uma varredura de parâmetros”.
00:23:55Nós basicamente incluímos uma configuração de ponta a ponta para todo o cluster.
00:24:00Esta é a estrutura do loop de pesquisa automatizada.
00:24:03Existe um metaloop que constrói a estrutura que depois executa o loop.
00:24:08E há um painel por cima que ajuda você a entender como tudo funciona.
00:24:12Temos interfaces personalizadas para isso.
00:24:15E um dos resultados foi um LoRA que custou 80 centavos para treinar e melhorou a qualidade de busca em textos jurídicos em alemão em 18%, como uma prova de conceito.
00:24:27E é isso.
00:24:29Então modelos pequenos são bons.
00:24:30Eles são relativamente fáceis de servir.
00:24:32Na verdade, são muito mais baratos e rápidos.
00:24:35É uma escolha inteligente.
00:24:36E aquele código QR leva ao repositório no GitHub do nosso cluster que acabei de descrever.
00:24:43Deixem uma estrela lá.
00:24:44E boa sorte com o auto-hospedagem.
00:24:45Obrigado.
00:24:46Obrigado.
00:24:47Obrigado.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video