Como equilibrar a latência ultrabaixa e a economia da nuvem em agentes de voz virtuais

Devin Reimer

Este é o curso "Como equilibrar a latência ultrabaixa e a economia da nuvem em agentes de voz virtuais".

Meu nome é Devin Reimer.

Sou o fundador e CEO da AstroBeam.

Antes, eu era CEO e cofundador da Owlchemy Labs, mais conhecida pelo Job Simulator.

Na AstroBeam, nosso foco é criar IA em tempo real para jogos.

Especificamente, estamos muito focados na voz como entrada.

Até agora, lançamos dois títulos: Stellar Cafe, que é para RV e PC.

É um jogo em que você conversa com robôs em um café de uma estação espacial e os ajuda a resolver problemas.

É 100% controlado por voz.

Você joga o jogo inteiro, incluindo menus e navegação, usando apenas a voz.

Nosso próximo jogo, que acabamos de anunciar hoje, Robo Detective, foi criado para o Android XR e, especificamente, para o Project Aura da XREAL.

Neste jogo, você é um detetive que trabalha com um parceiro robô para entrevistar outros robôs e resolver crimes cibernéticos. Tudo isso usando apenas a voz.

Os agentes de voz são muito difíceis de criar, e nos jogos, são ainda mais.

O motivo é que os jogos têm um custo muito baixo, e um agente de voz agora é um novo custo a ser adicionado a esse pipeline.

Além disso, não estamos competindo com outros agentes de voz, mas sim com a qualidade de todos os jogos já feitos, certo?

Por isso, precisamos oferecer uma qualidade muito alta.

Isso não quer dizer que não existam casos de uso específicos de agentes de voz com desafios únicos ou em que os riscos são muito maiores, mas os jogos são definitivamente muito desafiadores tecnicamente nesse espaço.

Mas, como são jogos, isso deixa muito espaço para experimentação de como resolver alguns desses problemas difíceis.

Por isso, acredito que, se os agentes de voz funcionam em jogos, eles podem funcionar em quase qualquer lugar.

Portanto, as coisas que estou mencionando nesta palestra se aplicam não apenas a jogos, mas a qualquer aplicativo que priorize a voz que você queira criar.

Então, quando você pensa em agentes de voz, acho que há três desafios principais.

Portanto, temos latência, inteligência e custo.

Mas quero deixar claro que, quando falo de agentes de voz, estou me referindo a eles como uma conversa, não como um comando.

Não estou falando de um wrapper de microfone que envia algo para um LLM e espera uma resposta.

Estou falando de uma conversa em tempo real, como no mundo real, e isso é o que se torna bastante difícil de criar.

Vamos começar com a latência.

Qual é a velocidade necessária?

Acontece que ela precisa ser rápida, muito rápida, mas, dependendo do que você leu, pode não ser tão rápida quanto você pensa ou pode ser muito mais rápida do que você imagina.

Vamos falar sobre alguns números que descobrimos em muitos dos nossos testes.

Então, quando falo sobre latência de ponta a ponta, estou me referindo ao tempo entre a última fala do usuário, o último som que ele fez, e o momento em que ele ouve o áudio de volta.

O que descobrimos nos testes é que, quando o tempo de carregamento é de cerca de 1,5 segundo, os usuários que dão feedback sobre o teste de jogo não mencionam velocidade, lentidão ou algo do tipo.

Parece que é nesse ponto que as pessoas começam a se sentir realmente confortáveis com ele.

Quando o tempo de resposta é maior, as pessoas costumam dizer: "Isso é ótimo, mas…". Então, esse parece ser o ponto ideal.

Depois, quando você fica ainda mais rápido, descobrimos que, em cerca de 1,2 segundo, algo mais natural, como uma conversa, começa a acontecer.

Então, eu digo algo, o robô responde rapidamente, e assim por diante.

Parece que há um ponto ideal que é desbloqueado.

Dito isso, 1,2 segundo é um tempo difícil de alcançar em uma pilha.

Outra descoberta interessante é que fizemos muitos testes e acabamos conseguindo alguns cenários para chegar a menos de um segundo.

E você pode pensar: "Ah, isso vai ser incrível!"

Às vezes era, e às vezes era terrível, muito estranho.

Por isso, você pode ouvir pessoas dizendo que o tempo de resposta certo é de 800 milissegundos ou 500.

Até li vários artigos sobre 300, porque é aí que a percepção humana realmente se concentra.

A realidade é que isso depende muito do contexto.

Por exemplo, se eu perguntar seu nome, tenho uma expectativa de quanto tempo você vai levar para responder.

Se eu perguntar qual é o sentido da vida, espero um tempo de resposta bem diferente.

Quando fizemos testes e pedimos para as pessoas avaliarem se a resposta parecia rápida ou lenta, os números variaram muito.

As pessoas disseram que as respostas que demoraram muito foram rápidas e vice-versa, porque isso dependia muito do contexto.

Também onde eles estavam na conversa.

Em geral, as pessoas esperam que a primeira resposta seja mais rápida do que as seguintes, porque há um tempo de processamento.

Mas, às vezes, você acaba tendo uma conversa bem curta, então sua expectativa aumenta.

Não é uma ciência exata em que há um número perfeito, mas descobrimos que, se você estiver em torno de 1, 5, está indo muito bem.

Então, quando você chega a esse ponto de 1,5 segundo, começa a se preocupar com a consistência, certo?

Porque se isso acontecer 90% das vezes, mas em 10% das vezes levar 3 segundos, a experiência vai parecer quebrada, não ruim, mas quebrada.

E, quando você consegue velocidade suficiente, só se preocupa com a consistência, ou seja, rapidez o tempo todo, não na maior parte do tempo.

Devin Reimer

Esta é uma arquitetura de pipeline de voz padrão.

Então, estamos pegando nossa conversão de voz em texto, enviando para um LLM e, em seguida, enviando o resultado do LLM de volta para a conversão de texto em voz.

Ou seja, com a Speech-to-Text, enviamos áudio para o servidor e o convertemos em texto.

No lado do LLM, pegamos esse texto, esse diálogo de resposta, ou o convertemos em um diálogo de resposta, e depois as ações que vão acontecer com base nesse personagem.

Nós os acoplamos de forma rígida porque acreditamos que isso é muito importante.

E, no lado da Text-to-Speech, pegamos esse texto, enviamos para a Text-to-Speech e transmitimos para o usuário, também sincronizado com as ações que o agente quer realizar.

Um dos problemas é que a execução sequencial pode ser bastante lenta, porque você precisa passar por cada uma dessas etapas.

Uma pergunta comum que recebo é: se esse processo é lento e exige três etapas, por que não usar um modelo de conversão de voz em voz?

Porque isso seria mais rápido, certo?

E, sim, na maioria das vezes, isso seria mais rápido porque você está executando uma coisa.

Mas isso tem algumas desvantagens importantes.

Embora seja rápido, há alguns problemas para nós, e o maior deles é o custo.

Em geral, descobrimos que é de 3 a 5 vezes mais caro executar um modelo de conversão de voz em voz do que essa abordagem paralelizada.

Por isso, para nós, a economia simplesmente não funciona.

No lado da segurança, é um pouco mais complicado, porque é mais difícil validar a resposta que o agente vai dar antes que ele a diga.

Mas, enquanto isso, se você tiver uma abordagem em pipeline, poderá pegar a resposta do LLM e validar e verificar a segurança ali mesmo, antes mesmo de chegar perto de enviar as coisas para um usuário.

Na estilização de voz, você fica preso às predefinições do modelo de conversão de voz em voz.

Não dá para dizer: "Sabe de uma coisa?

Neste caso, quero usar esse tipo de voz."

Você fica preso a esse modelo específico.

Na abordagem em pipeline, você pode pensar: "Ah, vou mudar isso.

Vou escolher este modelo porque ele funciona muito bem para esse caso de uso específico."

E o mesmo vale para a inteligência, certo?

Se você tem um modelo de conversão de voz em voz que produz uma boa voz, mas a inteligência não é exatamente o que você quer, não dá para simplesmente trocar, certo?

Você fica meio preso.

Na abordagem em pipeline, você diz: "Ah, para este caso de uso, quero usar um modelo específico".

Uma área em que o Speech-to-Speech definitivamente se destaca é na compreensão do tom do usuário.

Por exemplo, sarcasmo e coisas do tipo.

No momento, as transcrições de conversão de voz em texto geralmente não têm muitas dessas informações, mas acho que isso vai mudar com o tempo.

Esse é um ponto positivo para o Speech-to-Speech.

Então, a Speech-to-Speech definitivamente tem uma vantagem em termos de velocidade, mas também tem alguns desafios em termos de configurabilidade, e o custo alto, principalmente para nós, foi um fator decisivo.

Então, existe outra maneira?

Sim.

O que devemos fazer é o possível para paralelizar o pipeline.

Por isso, algumas das coisas que fazemos é executar o LLM antes que a conversão de voz em texto tenha total confiança.

E, por confiança, quero dizer confiança nas palavras que estão sendo geradas na transcrição e, em seguida, confiança no fim da fala.

Assim, quando achamos que o usuário parou de falar e que o que ele disse foi isso, nós nos adiantamos.

E o pior cenário é estarmos errados, certo?

O usuário continua falando.

Mas, mesmo nesse cenário, tudo o que fazemos é cancelar o LLM e executá-lo novamente.

Como o contexto provavelmente será armazenado em cache e não geramos tantos tokens, o custo não é alto, e o benefício é que o usuário acaba ouvindo as coisas mais rápido do que se você esperasse pela confiança total.

Também não esperamos que o LLM termine de gerar toda a resposta antes de começar a enviá-la para a Text-to-Speech.

O que esperamos é o primeiro trecho que pode ser lido em voz alta.

Na maioria dos casos, é uma frase.

Às vezes, pode haver outras configurações, mas assim que temos o primeiro bloco de frases, nós o enviamos para o Text-to-Speech.

E, se tivermos uma boa conversão de texto em voz que faça streaming, assim que estiver pronta para streaming, ela poderá ser enviada ao usuário.

Também temos muito cuidado com o número de tokens que precisam ser gerados.

Por isso, não usamos wrappers JSON e outros elementos que possam adicionar tokens.

Tentamos descobrir qual é a estrutura mais simplificada para receber a resposta mais rápida possível.

Também usamos recursos como o preenchimento prévio do assistente se soubermos com antecedência qual será o primeiro bloco de tokens do agente.

E para a conversão de texto em voz, acabaram sendo esses dois blocos, certo?

Assim, o primeiro trecho falável é recebido e, em seguida, executamos todo o restante.

No entanto, como a reprodução de áudio leva mais tempo do que a geração, quase sempre o primeiro bloco já terá sido reproduzido para o usuário quando o segundo estiver pronto.

Isso é invisível para o usuário.

Ele chega o mais rápido possível.

Então, quando você estiver pensando em escolher serviços diferentes, aqui estão algumas das nossas regras gerais.

Ao escolher um bom tipo de áudio e framework de agente, o que importa é a menor latência de entrada e saída.

Então, com que rapidez posso enviar e receber dados?

No que diz respeito à conversão de voz em texto, nos preocupamos com o tempo até a confiança.

Isso é confiança na transcrição e confiança no fim da vez.

Esses dois juntos, certo?

Se você não tiver confiança rápida em um, vai ser tão lento quanto isso, certo?

Portanto, a velocidade é limitada pela mais lenta.

No lado do LLM, nos preocupamos com o tempo até a primeira frase, o primeiro trecho que pode ser falado.

São duas partes, certo?

É o tempo até o primeiro token combinado com os tokens por segundo.

Portanto, se você encontrar um modelo muito bom que ofereça um tempo excelente até o primeiro token, mas seja lento em tokens por segundo, isso pode ser pior do que a alternativa.

Então, descubra qual é a combinação certa para isso.

E, no lado da conversão de texto em voz, você se preocupa com o tempo até o primeiro áudio.

Por isso, é muito importante medir o que é, porque às vezes o áudio pode voltar com silêncio no início, e o usuário não vai ouvir isso.

Portanto, é preciso medir até o ponto em que o usuário está ouvindo as coisas.

E, como mencionei antes, acima de tudo, você se preocupa com a estabilidade, não com as velocidades de pico, não com o melhor cenário.

Qual é a latência consistente de toda essa pilha?

Devin Reimer

Atualmente, para nossos frameworks de agentes de áudio, estamos usando o LiveKit.

Para conversão de voz em texto, usamos o Deepgram.

Para LLMs, usamos o Gemma 4 31B, hospedado no LiveKit.

Para a conversão de texto em voz, usamos a Inworld AI Text-to-Speech 2.

Além disso, criamos toda a estrutura de agentes de IA do AstroBeam, que não só une tudo isso, mas também adiciona todos os elementos necessários para ter um agente de voz realmente bom, especialmente um que seja altamente interativo como o nosso para jogos.

Uma coisa que ainda não mencionei são os modelos de segurança.

Tradicionalmente, os modelos de segurança fazem parte da passagem do LLM, mas isso adiciona latência e uma etapa extra.

E se você executar seu próprio modelo?

Então, na verdade, nossa pilha é mais parecida com isso.

O que estamos fazendo aqui é o seguinte: quando recebemos o primeiro bloco de texto, o primeiro bloco falável que vamos enviar para a conversão de texto em voz, enviamos ao mesmo tempo para o modelo de segurança.

Como o modelo de segurança é menor e funciona mais rápido do que a conversão de voz em texto, ele é quase sempre executado antes.

Isso significa que adicionar um modelo de segurança não gera latência na nossa pilha. Além disso, essa parte é grande o suficiente para que possamos executar um modelo de segurança muito maior do que a maioria das pessoas imagina.

Isso é muito importante para nós, principalmente porque estamos criando jogos.

Há muito contexto desse mundo que é superimportante.

Por exemplo, digamos que você esteja criando um jogo medieval e tenha um NPC que grita "Atacar!"

Cortem as cabeças!", certo?

Um modelo de segurança tradicional pode dizer: "Isso não é legal.

Você não deveria estar dizendo isso."

Mas, no contexto deste jogo, isso faz todo o sentido.

Para isso, usamos um modelo de segurança mais robusto, com muito mais contexto do que está acontecendo no mundo.

Você deve ter percebido que executamos o modelo de segurança duas vezes: primeiro no primeiro bloco e depois no todo, quando temos o bloco final completo.

Mais uma vez, precisamos executá-lo duas vezes, mas ele não adiciona latência à pilha.

Agora somos rápidos o suficiente, mas isso não importa se não formos inteligentes o suficiente.

Devin Reimer

Então, qual é o nível de inteligência necessário?

Ele precisa ser inteligente o suficiente para os usuários, mas, mais importante ainda, inteligente o suficiente para você desenvolver com ele.

E isso é algo que as pessoas não pensam quando estão selecionando o que precisam para a inteligência aqui.

Estamos trabalhando com agentes de voz há cerca de três anos. No início, usávamos alguns modelos LLaMA iniciais e, embora conseguíssemos fazê-los funcionar mais ou menos para os usuários, o desenvolvimento era muito caro porque tudo era muito instável.

Não era preciso muito para os modelos gerarem respostas indesejáveis ou coisas que simplesmente não faziam sentido. Por isso, gastamos muito esforço de engenharia para fazer isso funcionar.

Isso é algo que priorizamos, porque, se não pudermos agir rápido na criação dessas coisas, não poderemos lançar nada para os usuários.

Por isso, é muito importante pensar nos dois.

Então, quando as pessoas pensam em inteligência, elas pensam no LLM, certo?

Mas essa é só uma parte.

Precisamos pensar em cada peça quando se trata de inteligência.

Vamos falar sobre a inteligência de conversão de voz em texto.

Portanto, o que importa aqui é uma baixa taxa de erro de palavras.

Além disso, não é só que a taxa de erro é baixa, mas que, quando acontece, geramos algo muito próximo do que é real, porque, se estiver muito próximo, o LLM pode, com contexto, entender muito bem o que é.

Se a taxa de erro for baixa, mas os erros forem muito altos, o LLM terá muito mais dificuldade para descobrir qual era a intenção real.

Outro ponto a considerar é qual é sua plataforma de destino.

Por exemplo, se eu estiver criando para XR e tiver microfones muito próximos da boca do usuário, vou ter dados de áudio de microfone de alta qualidade, o que pode funcionar muito bem para determinados modelos.

Mas se, de repente, eu estiver criando um app para um smartphone que as pessoas vão usar em uma rua movimentada, isso terá um impacto muito diferente, e modelos diferentes vão se comportar de maneira diferente e poderão ser inteligentes sobre o que está sendo dito de maneiras diferentes.

Então, você precisa pensar nisso e escolher a plataforma certa para o que está criando.

Agora, vamos para o lado da conversão de texto em voz da equação de inteligência.

Parece natural, certo?

Nosso objetivo é comunicar ao usuário o que ele é capaz de entender.

Mas isso é só uma parte, certo?

A expressividade desse agente também é muito importante, porque há informações na expressividade. Além disso, nos nossos testes de jogo, descobrimos que, quanto mais expressivos os agentes, mais inteligentes os usuários os consideravam, o que faz muito sentido.

E, por fim, ele é rápido o suficiente?

Na seção anterior, falei sobre latência, mas ela também é importante para a inteligência percebida.

Os usuários percebem a velocidade de resposta diretamente correlacionada à inteligência.

Se eu tiver uma resposta rápida, ela provavelmente vai parecer mais inteligente.

Esses fatores podem ser muito importantes para a percepção do usuário e para o nível de imersão dele na experiência.

Agora, vamos para o lado do LLM da inteligência.

Esse é, de longe, o mais difícil de equilibrar, porque há muitos requisitos diferentes aqui, certo?

Então, temos reconhecimento de voz, contexto e embasamento.

Nos jogos, isso é muito difícil, porque você precisa se basear em um mundo e universo inteiros, certo?

Não é uma caixa de texto em que ele pode inventar coisas que estão acontecendo.

Se o agente em um jogo disser: "Há uma maçã na mesa", mas não houver nenhuma maçã na mesa, isso vai prejudicar a experiência do usuário.

Também precisamos de coisas como seguir regras rígidas.

Os jogos são muito baseados em regras.

O LLM consegue lidar com isso?

Podemos ter uma taxa de alucinação baixa?

Podemos ter personagens consistentes quando você interage com o mesmo agente repetidamente?

Parece o mesmo agente?

E, por fim, um que pode ser um problema, porque não é um problema no início do desenvolvimento: seu modelo consegue lidar com o aumento do tamanho do comando?

Porque, inevitavelmente, conforme você continua a desenvolver, vai colocar mais coisas no comando.

Mas, conforme os usuários continuam jogando, o histórico de conversas no comando vai aumentar.

Então, esse comando vai lidar com esse crescimento?

Porque, às vezes, o que acontece é que, para certos modelos, conforme o comando aumenta, a qualidade da resposta diminui. Então, você precisa descobrir quais são suas necessidades reais para a quantidade que precisa ser inserida no comando todas as vezes.

Mas isso é só a ponta do iceberg, e também depende muito do que você está criando.

Por isso, é preciso pensar muito bem no que você está criando e no que quer alcançar.

Agora que somos rápidos e inteligentes o suficiente, nada disso importa se o custo for muito alto.

Devin Reimer

Então, qual é o preço ideal?

Infelizmente, é um pouco mais complicado do que isso.

Por isso, precisamos pensar na economia do app ou jogo que estamos criando, certo?

Portanto, você precisa fazer algumas perguntas.

Por quanto tempo o usuário vai interagir com seus agentes de voz?

Quanto você está ganhando por usuário?

E quanto custa para executar essa pilha de voz por hora?

Nós as juntamos para tentar entender, ver se as coisas fazem sentido.

Então, aqui está a economia do nosso primeiro jogo, Stellar Cafe.

O tempo de jogo no Stellar Cafe é de 1h30 a 3h30. Vamos considerar uma média de 2 horas.

Nosso custo para executar agentes de voz é de cerca de US $1,20 por hora por usuário, e os usuários interagem com eles 100% do tempo.

É um jogo 100% controlado por voz.

Cobramos uma taxa fixa de US $10 pelo jogo, o que é tradicional.

Não trabalhamos com assinaturas porque elas são muito difíceis em jogos, e acredito que precisamos fazer com que funcione a um custo fixo, caso contrário, não vai funcionar e não vai ser escalonável.

Antes, cobrávamos US $15, mas trabalhamos para reduzir os custos do servidor e agora o valor é de US $10.

E esse US $1, 20 é onde estamos.

Não há um custo universal.

Já vi esses itens custarem uma grande variedade de preços, e às vezes muito mais caros.

Por isso, você também precisa descobrir onde está em relação aos custos.

Poderíamos fazer algo mais barato, mas estamos tentando manter o nível de qualidade o mais alto possível.

Então, considerando tudo isso, esse tempo de jogo de 2 horas significa que nossa pilha de voz custa cerca de US $2, 40 por usuário.

Como cobramos US $10 e a loja cobra uma taxa, isso significa que ganhamos cerca de US $4,59 por usuário, certo?

Então, a economia disso funciona, certo?

A voz é o nosso gancho, é nisso que queremos gastar dinheiro, isso funciona.

É um jogo bem pequeno.

Vamos falar sobre algo um pouco maior.

Vamos falar sobre um jogo hipotético, um jogo narrativo, que dura entre 5 e 9 horas, digamos, em média, 7 horas.

Na realidade, a maioria das pessoas não termina os jogos. Elas jogam um pouco e depois abandonam. Mas quero escolher um número um pouco maior para garantir que a economia ainda funcione.

Vamos manter o valor de US $1, 20 por hora, mas o componente de voz será usado 60% do tempo, porque um jogo maior tem muito mais mecânicas além da voz.

Então, ainda será um jogo muito focado na voz, mas terá outros tipos de recursos.

Então, se cobrarmos US $20, fazendo as contas de novo, o custo seria de cerca de US $5 por usuário, o que significa que, no fim das contas, ganharíamos cerca de US $9 por usuário.

Então, mais uma vez, com isso, a economia funciona.

Isso não significa que a economia vai funcionar para tudo.

Por exemplo, algo que não deve ser feito: "Quero criar um jogo sem custo para jogar, e os usuários provavelmente vão jogar entre 1 hora e mais de 100 horas".

Então, vamos usar uma média de 10 horas.

Ele é 100% controlado por voz, mas digamos que seja um sucesso e gere cerca de US $3 por usuário, o que seria ótimo para um jogo sem custo para jogar.

Você perderia US $10 por usuário.

Portanto, ele ainda não funciona em todas essas coisas, e você precisa pensar sobre o que está criando no momento e se isso faz sentido.

Não espere até o final para tentar entender a economia.

Devin Reimer

Então, a próxima pergunta é: e os modelos locais?

Porque se você tem esse grande desafio de custo, os modelos locais não o eliminariam?

E sim, seria.

Mas há algumas desvantagens que precisamos considerar.

Então, do lado dos custos, sim, eliminaríamos a conta do servidor, o que seria um grande benefício e abriria muito mais oportunidades.

Mas há muitas coisas que a nuvem pode resolver agora e que são difíceis para o local.

Por exemplo, computação.

Muitas vezes, as pessoas dizem: "Olha, encontrei esse modelo de conversão de voz em texto muito bom, e ele é executado localmente neste dispositivo, certo?"

Ótimo, mas precisamos pensar que não estamos executando um modelo, mas sim vários, certo?

No nosso caso, quatro, possivelmente ao mesmo tempo. Portanto, não basta que algo seja executado uma vez, é preciso que seja executado várias vezes ao mesmo tempo.

E, se você fizer isso, vai sobrar alguma coisa para o jogo ou aplicativo ser executado?

Se você atingir o limite da GPU, não vai conseguir renderizar muito de um videogame.

Digamos que você tenha superado esses desafios.

O próximo é a velocidade, certo?

Muitas vezes, é possível fazer com que eles funcionem, mas eles serão muito lentos e vão parecer mais um comando do que uma conversa em tempo real.

Então, em teoria, ter o modelo localmente tem uma vantagem futura, porque você não precisa fazer essa ida e volta pela Internet.

No momento, é um desafio conseguir modelos que funcionem na velocidade certa para que isso funcione.

Então, digamos que você tenha dominado a computação e a velocidade. Agora, precisamos pensar na qualidade, certo?

Como você está executando o modelo em um dispositivo local, geralmente usa um LLM menor, como um conversor de texto em voz mais primitivo. Isso pode representar alguns desafios em relação ao conteúdo que você está criando.

Como mencionei antes, ao pensar no LLM, não basta saber se ele é bom o suficiente para os usuários, mas também se é bom o suficiente para você desenvolver com ele.

Se esse modelo se tornar muito difícil para criar algo, é preciso pensar nisso.

Digamos que você tenha conquistado computação, velocidade e qualidade. O próximo passo é a portabilidade.

Se você venceu e passou por todo esse processo, e conseguiu executar o modelo em uma RTX 5070, por exemplo, esse pode ser o único lugar em que ele pode ser executado.

Portanto, se surgir uma oportunidade de levá-lo para uma nova plataforma, você pode ficar preso.

Na nuvem, você só precisa da Internet.

Isso é uma grande vantagem.

Permite acessar várias plataformas.

Agora vamos falar sobre uma abordagem híbrida, certo?

Então, vamos executar algumas coisas na nuvem e outras localmente.

Mais ou menos, isso funcionaria?

Não é uma vitória tão grande quanto você pensa.

Portanto, se você tiver um modelo pequeno o suficiente para ser executado na maioria das plataformas locais, se executasse esse mesmo modelo na nuvem, ele provavelmente custaria centavos.

Portanto, geralmente é só depois de resolver toda a pilha que você consegue as maiores vitórias.

Em seguida, o que é mencionado é: e se você executar localmente, se for possível?

Eles têm o hardware certo, e na nuvem, se você não tiver, certo?

Você pode executar algo mais potente na nuvem.

Isso traz novos desafios, certo?

Se você acabar executando um modelo diferente, isso pode afetar bastante o desenvolvimento.

E você acaba tendo que gastar muito tempo trabalhando na especificação mínima de qualquer maneira.

E você poderia ter modelos que se comportassem de maneira bem diferente.

Portanto, a menos que você use exatamente os mesmos modelos, poderá acabar adicionando muito tempo e custo de desenvolvimento.

Portanto, é importante pensar no que você está tentando alcançar, porque, digamos que você tenha descoberto isso e tenha um bom local se precisar, nuvem se não precisar, ainda assim a economia precisa funcionar para o modelo de nuvem.

Porque se, de repente, todos os seus usuários estiverem na nuvem, você vai perder se não tiver pensado nisso do ponto de vista econômico.

Então, quando se trata de modelos locais, é definitivamente uma grande vitória econômica, mas ainda é cedo.

Para aplicativos sensíveis ao preço, como jogos, acredito que ela provavelmente vai vencer.

Hoje em dia, é um pouco complicado fora de casos de uso mais específicos, principalmente em relação a comandos.

Então, hoje, queremos a melhor experiência possível.

É por isso que estamos usando a nuvem.

Mas esse é um espaço muito dinâmico, e as coisas estão mudando rapidamente.

Agora, vamos pensar nos modelos que estamos usando.

A próxima pergunta é sobre pesos abertos versus pesos fechados.

O que devemos fazer aqui?

Quero focar nos LLMs quando falarmos sobre isso, porque descobrimos que essa é a área mais afetada pela questão de aberto versus fechado.

Então, há vantagens e desvantagens.

Então, quando se trata de modelos fechados de peso, eles geralmente são sua inteligência de fronteira, certo?

Portanto, se você precisa de mais inteligência, geralmente é aqui que você deve ir.

Enquanto isso, no lado aberto, eles costumam estar uma geração atrás.

Portanto, essa pode ser uma escolha difícil.

Em relação à velocidade, mencionei que me importo muito com o tempo até a primeira frase.

Descobrimos que, ao longo da vida útil dos modelos fechados, a velocidade geralmente diminui.

E isso pode acontecer por vários motivos.

Talvez mais pessoas estejam usando o modelo ou o hardware tenha sido atualizado para um modelo mais recente.

Mas é algo que notamos.

Por isso, é preciso ter cuidado, porque isso pode causar um problema em que, se você enviar algo que é ótimo, com o tempo, pode se tornar inutilizável.

Em seguida, temos os picos.

Você se importa muito com esse tipo de consistência e, por isso, muitas vezes, os modelos fechados são criados em torno de tarefas assíncronas em lote, não de latências P99, em que, no lado aberto, você pode escolher um provedor que se importa com essa coisa muito específica que você se importa, para dar a você o tipo de confiança, velocidade e latência que você acaba precisando.

A próxima é o ciclo de vida do próprio modelo.

Por isso, os modelos fechados costumam ser desativados após cerca de um ano.

Isso significa que, se você desenvolver algo por um ano e esperar que ele fique em produção por três anos, poderá passar por mais de três mudanças de modelo.

E só porque um modelo é melhor, não significa que ele vai funcionar melhor para você.

Passamos por muitas mudanças de modelo nos últimos três anos e, muitas vezes, leva semanas, às vezes meses de trabalho para reestruturar tudo. No lado aberto, você pode continuar executando esse modelo desde que alguém esteja disposto a hospedá-lo ou você mesmo esteja disposto a hospedá-lo.

Por último, o custo.

Muitas vezes, com o tempo, esses modelos fechados, à medida que lançam novas versões, são mais caros do que os anteriores.

Portanto, é preciso ter cuidado com a economia, porque ela pode ter funcionado no lançamento e não funcionar mais quando você migrar os modelos.

No lado aberto, você tem flexibilidade para movê-lo, e as chances são de que ele não aumente drasticamente porque é o mesmo modelo.

Por isso, usamos o Gemma 4 31B, que foi uma grande conquista para nós, porque é a melhor combinação de velocidade, inteligência e custo.

Isso também nos permitiu avançar muito rápido.

É muito mais fácil de desenvolver do que algumas coisas que usamos antes.

Isso não significa que usamos apenas isso.

Usamos muitas combinações de diferentes modelos abertos e fechados.

Por exemplo, geração de memória, segurança e personalização.

É muito importante escolher o melhor modelo para suas necessidades específicas nessa tarefa.

Mas o Gemma 4 31B é nosso carro-chefe quando se trata de agentes de voz.

Portanto, quando se trata desse tipo de diferença entre os dois, os modelos abertos definitivamente oferecem maior controle e permitem que você mantenha os modelos pelo tempo que puderem ser hospedados a um custo mais previsível.

E sua programação não é afetada pela desativação de um modelo.

Devin Reimer

Para resumir, é preciso equilibrar esses três fatores, certo?

Sua latência, estamos tentando equilibrar o aspecto de streaming, o aspecto paralelo, a velocidade e a consistência disso.

No lado da inteligência, é inteligente o suficiente para os usuários e para criar com ele.

Sobre o custo, precisamos saber quanto vai custar por usuário e quanto podemos ganhar por usuário para garantir que a economia funcione.

Não crie primeiro para depois descobrir as finanças.

Pense nisso desde o início.

Ainda é muito cedo, mas a economia aqui está começando a funcionar.

Portanto, modelos mais baratos e inteligentes serão definitivamente melhores.

Mas agora, hoje, podemos começar a trabalhar nos desafios realmente difíceis que precisamos enfrentar para que os agentes de voz se tornem uma realidade em todos os lugares.

Por isso, estou muito animado para levar o poder dos agentes de voz para todo mundo.

Nossa equipe agradece.