Equilibrio entre la latencia ultrabaja y la economía de la nube en los agentes de voz virtuales

Devin Reimer

Te damos la bienvenida al curso Equilibra la latencia ultrabaja y la economía de la nube en agentes de voz virtuales.

Soy Devin Reimer.

Soy el fundador y director general de AstroBeam.

Anteriormente, fui director general y cofundador de Owlchemy Labs, probablemente más conocido por Job Simulator.

Por lo tanto, en AstroBeam, nos enfocamos en crear IA en tiempo real para los juegos.

Específicamente, nos enfocamos en la voz como entrada.

Hasta ahora, lanzamos dos títulos: Stellar Cafe, que es para RV y PC,

Es un juego en el que hablas con robots en la cafetería de una estación espacial y los ayudas a resolver sus problemas.

Se controla 100% por voz.

Puedes jugar todo el juego, incluidos los menús y la navegación, solo con la voz.

Nuestro próximo juego, que acabamos de anunciar hoy, Robo Detective, está diseñado para Android XR y, específicamente, para el Project Aura de XREAL.

En este juego, eres un detective que trabaja con un compañero robot para entrevistar a otros robots y resolver delitos cibernéticos. Una vez más, se controla 100% con la voz.

Por lo tanto, los agentes de voz son muy difíciles de crear, y en los juegos, son aún más difíciles.

Esto se debe a que los juegos son productos de muy bajo costo, y un agente de voz ahora es un costo nuevo que se debe agregar a esa canalización.

Además, no competimos contra otros agentes de voz, sino contra la calidad de todos los juegos que se han creado, ¿verdad?

Por lo tanto, debemos ofrecer una calidad muy alta.

Eso no quiere decir que no haya casos de uso específicos de agentes de voz en los que haya desafíos únicos o en los que haya mucho más en juego, pero los juegos definitivamente son muy desafiantes desde el punto de vista técnico en este espacio.

Pero, como también son juegos, esto deja mucho espacio para experimentar cómo resolver algunos de estos problemas difíciles.

Por lo tanto, creo que, si los agentes de voz pueden funcionar en los juegos, pueden funcionar en casi cualquier lugar.

Por lo tanto, las aplicaciones, las cosas de las que hablo en esta charla, no solo se aplican a los juegos, sino a cualquier aplicación que priorice la voz que quieras crear.

Cuando piensas en los agentes de voz, creo que hay tres desafíos principales.

Por lo tanto, tenemos latencia, inteligencia y costo.

Sin embargo, quiero dejar claro que, cuando hablo de agentes de voz, me refiero a ellos como una conversación, no como una instrucción.

No me refiero a un wrapper de micrófono que envía algo a un LLM y, luego, espera una respuesta.

Me refiero a un intercambio en tiempo real y en el mundo real, y eso es lo que resulta bastante difícil de crear.

Comencemos con la latencia.

¿Qué tan rápido debe ser?

Resulta que debe ser rápida, muy rápida, pero, según lo que hayas leído, puede que no sea tan rápida como crees o que sea mucho más rápida de lo que crees.

Hablemos de algunas cifras que descubrimos en muchas de nuestras pruebas.

Cuando hablo de latencia de extremo a extremo, me refiero al tiempo que transcurre desde la última expresión del usuario, el último sonido que emitió, hasta el momento en que escucha el audio que le devuelve el sistema.

En nuestras pruebas, descubrimos que, cuando recibimos comentarios de los usuarios sobre las pruebas de juego, alrededor de 1.5 segundos es el punto en el que dejan de mencionar la velocidad o la lentitud, o cualquier otro aspecto relacionado.

Ese parece ser el punto en el que las personas comienzan a sentirse realmente cómodas con él.

En cuanto nos volvemos mucho más lentos que eso, la gente suele decir: "Esto es genial, pero…", por lo que ese parece ser el punto óptimo.

Luego, a medida que se vuelve aún más rápido, descubrimos que, en aproximadamente 1.2 segundos, se produce una interacción más natural, como un ida y vuelta.

Por ejemplo, yo digo algo, en este caso, el robot, y luego tú dices algo muy rápido, y así sucesivamente.

Parece que hay un punto óptimo que se desbloquea.

Dicho esto, 1.2 segundos es bastante difícil de lograr en una pila.

Y, luego, otro hallazgo interesante es que hicimos muchas pruebas y terminamos obteniendo algunas situaciones para obtener menos de un segundo.

Y tal vez pienses: "¡Eso va a ser genial!".

Y a veces lo era, y a veces se sentía terrible, muy extraño.

Por lo tanto, es posible que escuches a personas decir que el tiempo de respuesta correcto es de 800 milisegundos o de 500.

Incluso leí varios artículos sobre 300, porque ahí es donde realmente se sitúa la percepción humana.

La realidad es que depende mucho del contexto.

Por ejemplo, si te pregunto tu nombre, tengo una expectativa de cuánto tiempo tardarás en responder.

Si te pregunto cuál es el sentido de la vida, espero un tiempo de respuesta muy diferente.

Cuando hicimos pruebas y les pedimos a las personas que calificaran si esta respuesta les parecía rápida o lenta, y luego analizamos los números, vimos que las opiniones eran muy variadas.

Las respuestas que tardaron mucho tiempo, las personas dijeron que fueron rápidas y viceversa, porque resultó que dependía mucho del contexto.

También, en qué parte de la conversación se encontraban.

Por lo general, las personas esperan que la primera respuesta sea más rápida que las siguientes, ya que hay un tiempo de razonamiento.

Pero, a veces, terminas teniendo un intercambio muy breve, por lo que tus expectativas aumentan.

No es una ciencia exacta en la que haya un número perfecto, pero descubrimos que, si estás en 1.5, estás en un buen lugar.

Entonces, una vez que llegas a este punto de 1.5 segundos, ahora realmente comienzas a preocuparte por la coherencia, ¿verdad?

Porque si esto sucede el 90% de las veces, pero el 10% de las veces tarda 3 segundos, la experiencia se sentirá rota, no mala, sino rota.

Y, por lo tanto, terminamos Una vez que terminas obteniendo la velocidad suficiente, solo te importa la coherencia, es decir, que sea rápido todo el tiempo, no la mayor parte del tiempo.

Devin Reimer

Esta es una arquitectura de canalización de voz estándar.

Por lo tanto, tomamos nuestra entrada de Speech-to-Text, la enviamos a un LLM y, luego, enviamos el resultado del LLM de vuelta a Text-to-Speech.

Con esto, me refiero a que, con Speech-to-Text, enviamos audio al servidor y, luego, lo convertimos en texto.

En el lado del LLM, tomamos ese texto, ese diálogo de respuesta, o lo convertimos en un diálogo de respuesta, y luego, qué acciones se llevarán a cabo a partir de ese personaje.

Los acoplamos de forma estrecha porque creemos que es muy importante.

Y, luego, en el lado de Text-to-Speech, tomamos ese texto, lo enviamos a nuestro Text-to-Speech y lo transmitimos al usuario, también sincronizado con las acciones que el agente quiere realizar.

Uno de los problemas de esto es que ejecutarlo de forma secuencial puede ser bastante lento porque terminas teniendo que pasar por cada una de estas cosas.

Por lo tanto, una pregunta común que me hacen es: si ese proceso es lento y hay que realizar tres pasos, ¿por qué no usar un modelo de voz a voz?

Porque eso sería más rápido, ¿verdad?

Y, sí, la mayoría de las veces sería más rápido porque estás ejecutando una sola cosa.

Sin embargo, tiene algunas desventajas importantes.

Por lo tanto, si bien es rápido, hay algunos factores decisivos para nosotros, y el más importante es el costo.

Por lo tanto, en general, descubrimos que ejecutar un modelo de voz a voz es entre 3 y 5 veces más costoso que este enfoque paralelizado.

Por lo tanto, para nosotros, la economía simplemente no funciona.

En cuanto a la seguridad, es un poco más complicado porque es más difícil validar la respuesta que tendrá el agente hasta que la diga.

Pero, mientras tanto, si tienes un enfoque de canalización, puedes tomar la respuesta que dice el LLM y validarla y verificar su seguridad antes de que te acerques a enviar cosas a un usuario.

En cuanto al estilo de voz, estás limitado a los ajustes predeterminados de ese modelo de voz a voz.

No puedes decir: "¿Sabes qué?

Para este caso, realmente quiero usar este tipo de voz".

No puedes cambiarlo.

En el enfoque de canalización, puedes decir: "Voy a cambiarlo.

Elegiré este modelo porque funciona muy bien para este caso de uso en particular".

Y lo mismo ocurre con la inteligencia, ¿verdad?

Si tienes un modelo de voz a voz realmente bueno que produce una voz de calidad, pero la inteligencia no es exactamente la que quieres, no puedes simplemente cambiarla, ¿verdad?

Estás atrapado.

En el enfoque de canalización, piensas: "Para este caso de uso, quiero usar un modelo en particular".

Un área en la que la función de voz a voz definitivamente gana es la comprensión del tono del usuario.

Por ejemplo, el sarcasmo y cosas por el estilo.

En este momento, las transcripciones de voz a texto, por lo general, no tienen mucha de esa información, pero creo que eso va a cambiar con el tiempo.

Esa es, sin duda, una de las ventajas de la traducción de voz a voz.

Por lo tanto, la conversión de voz a voz definitivamente tiene una ventaja en cuanto a la velocidad, pero también tiene algunos desafíos en cuanto a la configurabilidad y el alto costo, que, en particular para nosotros, fue un factor decisivo.

Entonces, ¿hay otra manera?

Sí.

Lo que deberíamos hacer es esforzarnos al máximo para paralelizar la canalización.

Por lo tanto, algunas de las cosas que hacemos es ejecutar el LLM antes de que la conversión de voz en texto tenga plena confianza.

Y, por confianza, me refiero a la confianza en las palabras que se generan en la transcripción y, luego, a la confianza en el final del turno.

Por lo tanto, en cuanto creemos que existe la posibilidad de que este sea el momento en que el usuario dejó de hablar y esto es lo que dijo, nos adelantamos.

Y, por lo tanto, el peor de los casos es que estemos equivocados, ¿verdad?

El usuario sigue hablando.

Pero, incluso en ese caso, lo único que hacemos es cancelar el LLM y, luego, volver a ejecutarlo.

Y como el contexto probablemente se almacenará en caché y no generamos tantos tokens, no tiene un gran costo hacerlo, y el beneficio es que el usuario termina escuchando las cosas más rápido de lo que lo haría si esperaras a tener plena confianza.

Tampoco esperamos a que el LLM termine de generar toda su respuesta antes de comenzar a enviarla a Text-to-Speech.

Lo que esperamos es el primer fragmento que se puede pronunciar.

En la mayoría de los casos, es una oración.

A veces, puede haber otras configuraciones, pero en cuanto tenemos ese primer fragmento de oración, lo enviamos a nuestro Text-to-Speech.

Y, luego, si tenemos un buen sistema de texto a voz que transmita, en cuanto esté listo para transmitir, eso puede llegar al usuario.

También somos muy cuidadosos con la cantidad de tokens que se deben generar.

Por lo tanto, no usamos elementos como wrappers de JSON y otros similares que podrían agregar tokens adicionales.

Intentamos determinar cuál es la estructura más simplificada para obtener la respuesta más rápida posible.

También usamos funciones como el autocompletado de asistentes si sabemos de antemano cuál será el primer fragmento de tokens del agente.

Y, para el texto a voz, terminó siendo estos dos fragmentos, ¿verdad?

Por lo tanto, primero se recibe ese fragmento de texto que se puede leer en voz alta y, luego, se ejecuta todo lo demás.

Sin embargo, debido a que escuchar la reproducción de audio lleva más tiempo que la generación, casi siempre se terminará de reproducir ese primer fragmento para el usuario cuando se complete el segundo.

Por lo tanto, es invisible para el usuario.

Llega lo más rápido posible.

Por lo tanto, cuando pienses en elegir diferentes servicios, estas son algunas de nuestras reglas generales.

Cuando se trata de elegir un buen tipo de framework de audio y agente, lo que te interesa es la latencia más baja de entrada y salida.

¿Qué tan rápido puedo enviar y extraer datos?

En cuanto a la conversión de voz en texto, nos importa el tiempo hasta la confianza.

Por lo tanto, esta es la confianza en la transcripción y la confianza en el final del turno.

Esos se vinculan, ¿verdad?

Si no tienes confianza rápida en uno, será tan lento como eso, ¿verdad?

Por lo tanto, solo es tan rápido como el más lento de ellos.

En cuanto al LLM, nos importa el tiempo hasta la primera oración, ese primer fragmento que se puede pronunciar.

Entonces, son dos partes, ¿verdad?

Es el tiempo hasta el primer token combinado con los tokens por segundo.

Por lo tanto, si de repente encuentras un modelo muy bueno que te da un tiempo hasta el primer token muy bueno, pero es lento en tokens por segundo, eso podría ser peor que la alternativa.

Por lo tanto, determina cuál es la combinación adecuada para eso.

Y, en cuanto a la conversión de texto a voz, te importa el tiempo hasta el primer audio.

Por lo tanto, es muy importante medirlo, ya que, a veces, el audio puede volver con un silencio inicial y el usuario no lo escuchará.

Por lo tanto, debes medir hasta el punto en que el usuario escucha las cosas.

Y, como mencioné antes, por encima de todo, te importa la estabilidad, no las velocidades máximas ni el mejor de los casos.

¿Cuál es la latencia constante de toda esta pila?

Devin Reimer

Por lo tanto, actualmente, para nuestros frameworks de agentes de audio, usamos LiveKit.

Para la conversión de voz a texto, usamos Deepgram.

Para los LLM, usamos Gemma 4 31B y lo alojamos en LiveKit.

En cuanto a la conversión de texto a voz, usamos la versión 2 de Inworld AI.

Además, creamos todo nuestro arnés de agentes de IA de AstroBeam, que no solo une todo esto, sino que también agrega todos los elementos que necesitas para tener un agente de voz realmente bueno, en especial uno que sea muy interactivo, como el nuestro para juegos.

Hay algo de lo que no he hablado: ¿qué pasa con los modelos de seguridad?

Por lo tanto, tradicionalmente, los modelos de seguridad forman parte del pase del LLM, pero eso agrega latencia y un paso adicional.

Entonces, ¿qué tal si ejecutas tu propio modelo?

Así es como se ve nuestra pila en realidad.

Entonces, lo que hacemos aquí es que, cuando recibimos ese primer fragmento de texto, ese primer fragmento pronunciable que vamos a enviar a la conversión de texto a voz, al mismo tiempo lo enviamos a nuestro modelo de seguridad.

Y como el modelo de seguridad es más pequeño y se ejecutará más rápido que la parte de voz a texto, casi siempre se hace con anticipación.

Y lo que esto significa es que agregar un modelo de seguridad agrega cero latencia a nuestra pila y, lo que es aún mejor, es una parte lo suficientemente grande como para que podamos ejecutar un modelo de seguridad mucho más grande de lo que la mayoría de las personas piensan.

Y eso es muy importante para nosotros, en especial porque estamos creando juegos.

Hay mucho contexto de ese mundo que es muy importante.

Por ejemplo, supongamos que estás creando un juego medieval y tienes un NPC que grita: "¡A la carga!

¡Que les corten la cabeza!", ¿verdad?

Un modelo de seguridad tradicional podría decir algo como "Oye, eso no está bien.

No deberías decir eso".

Pero en el contexto de este juego, tiene mucho sentido.

Y la forma en que podemos hacerlo es usando un modelo de seguridad un poco más sólido con mucho más contexto de lo que está sucediendo en el mundo para poder lograrlo.

Aquí puedes notar que, en realidad, ejecutamos el modelo de seguridad dos veces, por lo que terminamos ejecutándolo en ese primer fragmento y, luego, lo volvemos a ejecutar en todo el contenido cuando tenemos ese fragmento final todo junto.

Una vez más, debemos ejecutarlo dos veces, pero no agrega latencia a la pila.

Ahora somos lo suficientemente rápidos, pero, lamentablemente, esto no importa si no somos lo suficientemente inteligentes.

Devin Reimer

Entonces, ¿qué tan inteligente debe ser?

Debe ser lo suficientemente inteligente para tus usuarios, pero, lo que es más importante, debe ser lo suficientemente inteligente para que puedas desarrollar con ella.

Y esto suele ser algo en lo que las personas no piensan cuando seleccionan lo que necesitan para la inteligencia aquí.

Llevamos unos tres años trabajando en agentes de voz y, por ejemplo, al principio usábamos algunos modelos LLaMA iniciales y, aunque logramos que funcionaran más o menos para los usuarios, el desarrollo era muy costoso porque todo era muy inestable.

No se necesitaba mucho para que los modelos generaran respuestas no deseadas o cosas que simplemente no tenían sentido, por lo que dedicamos mucho esfuerzo de ingeniería para que eso funcionara.

Y eso es algo que priorizamos, porque si no podemos avanzar rápido en la creación de estas cosas, no podemos ofrecerles cosas a los usuarios.

Por lo tanto, es muy importante pensar en ambos aspectos.

Por lo general, cuando las personas piensan en inteligencia, piensan en el LLM, ¿verdad?

Pero esa es solo una parte.

Debemos pensar en cada pieza cuando se trata de inteligencia.

Hablemos de la inteligencia de voz a texto.

Por lo tanto, lo que nos interesa aquí es una tasa de error de palabras baja.

Además, no solo la tasa de errores es baja, sino que, cuando ocurre, generamos algo muy cercano a lo real, porque, si es muy cercano, el LLM a menudo puede, con contexto, hacer un muy buen trabajo para comprender de qué se trata.

Si tu tasa de errores es baja, pero los errores son muy altos, el LLM tendrá muchas más dificultades para intentar averiguar cuál era la intención real.

Otro aspecto que debes tener en cuenta es cuál es tu plataforma de destino.

Por ejemplo, si estoy creando para XR y tengo micrófonos que están muy cerca de la boca del usuario, voy a tener datos de audio de micrófono de muy buena calidad, y eso podría funcionar muy bien para ciertos modelos.

Pero si, de repente, creo una app para un teléfono celular que las personas usarán en una calle concurrida, el impacto será muy diferente, y los distintos modelos se comportarán de otra manera y podrán ser inteligentes sobre lo que se dice de diferentes formas.

Por lo tanto, debes tenerlo en cuenta y asegurarte de elegir la plataforma correcta para la que estás compilando.

Ahora, pasemos al lado de texto a voz de la ecuación de inteligencia.

¿Suena natural, verdad?

Nuestro objetivo es comunicarle al usuario lo que puede entender.

Pero eso es solo una parte, ¿verdad?

La expresividad de ese agente también es muy, muy importante porque hay información en la expresividad y, además, en nuestras pruebas de juego, descubrimos que cuanto más expresivos pueden ser nuestros agentes, más inteligentes los usuarios sentían que eran, lo que tiene mucho sentido.

Y, luego, ¿es lo suficientemente rápido?

En la sección anterior, hablé de la latencia, pero en realidad también es importante para la inteligencia percibida.

Los usuarios perciben que la velocidad de respuesta está directamente relacionada con la inteligencia.

Si tengo una respuesta rápida, probablemente suene más inteligente.

Por lo tanto, estos aspectos pueden ser muy importantes cuando se trata de cómo el usuario percibe la experiencia y también de qué tan inmerso puede estar en ella.

Entonces, pasemos al lado del LLM de la inteligencia.

Este es, por mucho, el más difícil de equilibrar porque hay muchos requisitos diferentes aquí, ¿verdad?

Por lo tanto, tenemos una especie de comprensión del habla, contexto y fundamentación.

En los juegos, esto es muy difícil, porque tienes que basarte en todo un mundo y un universo, ¿verdad?

No es un cuadro de texto en el que se puedan inventar cosas que están sucediendo.

Si tu agente dentro de un juego dice: "Hay una manzana en la mesa", y no hay ninguna manzana en la mesa, eso arruinará la experiencia del usuario.

También necesitamos que se sigan las reglas de forma estricta.

Los juegos se basan en reglas.

¿Puede el LLM manejar eso?

¿Podemos tener una tasa de alucinaciones baja?

¿Podemos tener personajes coherentes cuando interactúas con ese mismo agente una y otra vez?

¿Se siente como el mismo agente?

Y, luego, un aspecto que podría hacerte tropezar, porque no es un problema al comienzo del desarrollo, es si tu modelo puede manejar el crecimiento del tamaño de la instrucción.

Porque, inevitablemente, a medida que sigas desarrollando, vas a poner más cosas en la instrucción.

Pero, además, a medida que los usuarios sigan jugando, habrá más historial de chat en esa instrucción.

Entonces, ¿esa instrucción controlará ese crecimiento?

Porque, a veces, lo que sucede es que, para ciertos modelos, a medida que crece la instrucción, la calidad de la respuesta disminuye, por lo que debes averiguar cuáles son tus necesidades reales para la cantidad que debe incluirse en esa instrucción cada vez.

Pero esto es solo la punta del iceberg y también depende de lo que estés creando.

Por lo tanto, debes pensar muy bien qué estás creando y qué quieres lograr.

Ahora somos lo suficientemente rápidos y lo suficientemente inteligentes, pero nada de esto importa si cuesta demasiado.

Devin Reimer

¿Qué tan barato debe ser?

Lamentablemente, es un poco más complicado que eso.

Por lo tanto, debemos pensar en la economía de la aplicación o el juego que estamos creando, ¿verdad?

Por lo tanto, debes hacerte algunas preguntas.

¿Cuánto tiempo interactuará el usuario con tus agentes de voz?

¿Cuánto ganas por usuario?

¿Y cuánto cuesta ejecutar esa pila de voz por hora?

Las unimos para tratar de resolverlo, ver si las cosas tienen sentido.

Aquí está la economía de nuestro primer juego, Stellar Cafe.

Por lo tanto, el tiempo de juego en Stellar Cafe es de entre 1 hora y media y 3 horas y media, así que vamos a promediarlo en unas 2 horas.

Nuestro costo de ejecutar agentes de voz es de alrededor de USD 1.20 por hora por usuario, y los usuarios interactúan con él el 100% del tiempo.

Es un juego que se controla 100% con la voz.

Cobramos una tarifa fija de USD 10 por el juego, que es tradicional.

No ofrecemos suscripciones porque son muy difíciles de implementar en los juegos, y creo firmemente que debemos lograr que funcione con un costo fijo; de lo contrario, esto no va a funcionar ni a escalar.

Antes, cobrábamos USD 15, pero estuvimos trabajando para reducir los costos de los servidores, por lo que ahora los bajamos a USD 10.

Y este USD 1.20 es el valor actual.

No hay un costo universal.

He visto que estos servicios tienen una amplia variedad de precios y, a veces, son mucho más caros.

Por lo tanto, también debes determinar en qué punto te encuentras en cuanto a los costos.

Podríamos haberlo hecho más barato, pero intentamos mantener nuestro estándar de calidad lo más alto posible.

Por lo tanto, si hacemos los cálculos, esto significa que, con 2 horas de tiempo de juego, nuestra pila de voz cuesta alrededor de USD 2.40 por usuario.

Y, como cobramos USD 10 y la tienda cobra una comisión, eso significa que ganamos alrededor de USD 4.59 por usuario, ¿verdad?

Y, por lo tanto, la economía de eso funciona, ¿verdad?

La voz es nuestro gancho, en eso queremos gastar dinero, esto funciona.

Este es un juego muy pequeño.

Hablemos de algo un poco más grande.

Hablemos de un juego hipotético, un juego narrativo, que dura entre 5 y 9 horas, digamos que un promedio de 7 horas.

En realidad, la mayoría de las personas, muchas personas, no terminan los juegos, juegan un poco y los abandonan, pero quiero elegir algo un poco más alto para asegurarme de que la economía siga funcionando.

Por lo tanto, mantendremos ese USD 1.20 por hora, pero el cambio que haremos es que el componente de voz se usará el 60% del tiempo, ya que un juego más grande tendrá muchas más mecánicas que solo la voz.

Por lo tanto, seguirá siendo un juego muy controlado por voz, pero tendrá otro tipo de funciones.

Por lo tanto, si cobramos USD 20, volviendo a calcular todo esto, nos cuesta alrededor de USD 5 por usuario, lo que significa que, al final del día, ganamos alrededor de USD 9 por usuario.

Así que, una vez más, con esto, la economía funciona.

Esto no significa que la economía vaya a funcionar para todo.

Por ejemplo, algo que no debes hacer es decir: "Quiero crear un juego gratuito y, probablemente, los usuarios lo jugarán entre 1 hora y más de 100 horas".

Por lo tanto, calculemos un promedio de 10 horas.

Se controla 100% por voz, pero supongamos que tenemos un éxito entre manos y el juego genera alrededor de USD 3 por usuario, lo que sería genial para un juego gratuito.

Perderías USD 10 por usuario.

Por lo tanto, todavía no funciona en todas estas cosas, y tienes que pensar en lo que estás creando actualmente y si tiene sentido.

No esperes hasta el final para intentar comprender la economía.

Devin Reimer

Entonces, la siguiente pregunta que surge es: ¿qué pasa con los modelos locales?

Porque si tienes este gran desafío de costos, ¿los modelos locales no lo eliminarían?

Y sí, lo sería.

Pero hay algunas compensaciones que debemos tener en cuenta.

En cuanto a los costos, sí, eliminaríamos la factura del servidor, lo que sería un gran beneficio y abriría muchas más oportunidades.

Sin embargo, hay muchos problemas que la nube puede resolver en este momento y que la infraestructura local no puede.

Por ejemplo, Compute.

A menudo, las personas dicen: "Mira, encontré este modelo de voz a texto que es muy bueno y se ejecuta de forma local en este dispositivo, ¿verdad?".

Genial, pero lo que debemos tener en cuenta es que no se ejecuta un modelo, sino varios, ¿verdad?

En nuestro caso, cuatro, posiblemente al mismo tiempo, por lo que no basta con que algo se ejecute una vez, sino que debe ejecutarse varias veces al mismo tiempo.

Y, si lo logras, ¿te queda algo para que se ejecute tu juego o aplicación?

Si la GPU está al máximo, no podrás renderizar mucho de un videojuego.

Supongamos que ya superaste esos desafíos.

Entonces, el siguiente es la velocidad, ¿verdad?

A menudo, puedes lograr que se ejecuten, pero serán muy lentos y se sentirán más como instrucciones que como una conversación real en tiempo real.

Por lo tanto, en teoría, tenerlo de forma local tiene una ventaja futura, ya que no tienes que hacer ese viaje de ida y vuelta desde Internet.

En este momento, es un desafío obtener modelos que se ejecuten a la velocidad adecuada para que esto funcione.

Entonces, supongamos que dominaste el procesamiento y la velocidad. Ahora, debemos pensar en la calidad, ¿verdad?

Por lo general, como lo ejecutas en un dispositivo local, usas un LLM más pequeño, por ejemplo, una conversión de texto a voz más primitiva, lo que puede representar algunos desafíos en lo que respecta al contenido que estás creando.

Como mencioné antes, cuando pienses en el LLM, no solo debes considerar si es lo suficientemente bueno para tus usuarios, sino también si es lo suficientemente bueno para que desarrolles con él.

Por lo tanto, si ese modelo se vuelve bastante difícil para compilar algo, definitivamente es algo en lo que hay que pensar.

Supongamos que ya dominas el procesamiento, la velocidad y la calidad. El siguiente paso es la portabilidad.

Si ganaste y pasaste por todo este proceso, y lograste que esto se ejecute en, por ejemplo, una RTX 5070, ese podría ser el único lugar donde se puede ejecutar.

Por lo tanto, si surge la oportunidad de llevarlo a una plataforma nueva, es posible que te quedes sin opciones.

En cuanto a la nube, solo necesitas Internet.

Y ese es un gran avance.

Permite transmitir en varias plataformas.

A continuación, hablemos de un enfoque híbrido.

Por lo tanto, ejecutemos algunas de las tareas en la nube y otras de forma local.

Más o menos, ¿podría funcionar?

Bueno, no es una victoria tan grande como crees.

Por lo tanto, si terminas obteniendo un modelo que es lo suficientemente pequeño como para ejecutarse en la mayoría de las plataformas locales, si ejecutaras ese mismo modelo en la nube, probablemente te costaría centavos.

Por lo tanto, por lo general, no es hasta que resuelves toda la pila que obtienes tus mayores logros.

Luego, lo siguiente que se plantea es: ¿qué pasa si, en cambio, lo ejecutas de forma local si es posible?

Tienen el hardware adecuado y, si no lo tienes, en la nube, ¿verdad?

Podrías ejecutar algo más potente en la nube.

Esto presenta nuevos desafíos, ¿verdad?

Si terminas ejecutando un modelo diferente, esto podría afectar bastante el desarrollo.

Y, de todos modos, terminas dedicando mucho tiempo a trabajar en las especificaciones mínimas.

Y podrías tener modelos que se comporten de manera muy diferente.

Por lo tanto, a menos que uses exactamente los mismos modelos, podrías terminar agregando mucho tiempo y costo de desarrollo.

Por lo tanto, es importante pensar en lo que intentas lograr, porque supongamos que lo descubriste y obtuviste un buen modelo local si es necesario, o en la nube si no lo es, de todos modos, la economía tiene que funcionar para el modelo en la nube.

Porque si, de repente, todos tus usuarios están en el lado de la nube, vas a perder si no pensaste en eso, desde un punto de vista económico.

Por lo tanto, en lo que respecta a los modelos locales, sin duda es una gran victoria económica, pero aún es pronto.

Para las aplicaciones sensibles a los precios, como los juegos, creo que es probable que gane con el tiempo.

Hoy en día, es un poco complicado fuera de los casos de uso más específicos, en particular, los relacionados con los comandos.

Por lo tanto, en este momento, hoy, queremos que tengas la mejor experiencia posible.

Por eso usamos la nube.

Sin embargo, este es un espacio muy dinámico y las cosas cambian con bastante rapidez.

Entonces, la siguiente parte es pensar en los modelos que estamos usando, ¿verdad?

Entonces, la siguiente pregunta es sobre pesos abiertos frente a pesos cerrados.

¿Qué deberíamos hacer aquí?

Quiero enfocarme en los LLM cuando hablemos de esto, ya que descubrimos que esta es el área más afectada por la pregunta de código abierto o cerrado.

Por lo tanto, definitivamente hay algunas ventajas y desventajas aquí.

Entonces, cuando se trata de modelos cerrados de ponderación, estos suelen ser de inteligencia de vanguardia, ¿verdad?

Por lo tanto, si necesitas la mayor cantidad de inteligencia, este suele ser el lugar al que debes acudir.

Mientras tanto, en el lado abierto, suelen estar una generación por detrás.

Por lo tanto, esto puede ser una verdadera compensación.

En cuanto a la velocidad, mencioné que me importa mucho el tiempo hasta la primera oración.

Lo que descubrimos es que, a lo largo de la vida útil de los modelos cerrados, la velocidad suele disminuir.

Esto puede deberse a varios motivos.

Tal vez más personas usen el modelo o el hardware haya cambiado a un modelo más nuevo.

Pero es algo que hemos notado.

Por lo tanto, debes tener cuidado, ya que puede causar un problema en el que, si envías algo y es excelente, con el tiempo, podría volverse inutilizable.

A continuación, se encuentran los picos.

Te importa mucho ese tipo de coherencia y, por lo tanto, a menudo, los modelos cerrados se crean en torno a un procesamiento por lotes en tareas asíncronas, no en latencias de P99, donde, en el lado abierto, puedes elegir un proveedor que se preocupe por esa cosa tan específica que te importa, para darte la confianza, la velocidad y la latencia que terminas necesitando.

El siguiente es el ciclo de vida del modelo en sí.

Por lo tanto, los modelos cerrados suelen retirarse después de un año, aproximadamente.

Por lo tanto, esto significa que, si terminas desarrollando algo durante un año y esperas que esté en producción durante 3 años, podrías pasar por más de 3 cambios de modelo.

Y solo porque un modelo sea mejor, no significa que vaya a funcionar mejor para ti.

Hemos realizado muchos cambios en los modelos en los últimos 3 años y, a menudo, se necesitan semanas, a veces meses, de trabajo para reestructurar todo, lo que, en el lado abierto, puedes seguir ejecutando ese modelo siempre que alguien esté dispuesto a alojarlo o que tú mismo estés dispuesto a alojarlo.

Por último, está el costo.

A menudo, con el tiempo, estos modelos cerrados, a medida que lanzan nuevas versiones, son más costosos que el anterior.

Por lo tanto, esto es algo más con lo que hay que tener cuidado cuando se trata de la economía, es decir, una vez más, tu economía podría haber funcionado en el lanzamiento y luego no funcionar a medida que terminas migrando los modelos.

En el lado abierto, tienes la flexibilidad de poder moverlo, y es probable que no aumente drásticamente porque es exactamente el mismo modelo.

Por eso, usamos Gemma 4 31B, que fue un gran avance para nosotros porque, para nosotros, era la mejor combinación de velocidad, inteligencia y costo.

También nos permitió avanzar muy rápido.

Es mucho más fácil de desarrollar que algunas de las cosas que usamos antes.

Esto no significa que solo usemos este método.

Usamos muchas combinaciones de diferentes modelos abiertos y cerrados.

Por ejemplo, la generación de recuerdos, la seguridad y la personalización.

Es muy importante elegir el mejor modelo para tus necesidades particulares en esa tarea.

Sin embargo, Gemma 4 31B es nuestro modelo más potente para los agentes de voz.

Por lo tanto, cuando se trata de este tipo de diferencias entre los dos, los modelos abiertos definitivamente te brindan un mayor control y te permiten mantener los modelos siempre que se puedan alojar a un costo más predecible.

Además, no se verá afectado tu cronograma por la descontinuación de un modelo.

Devin Reimer

Para concluir, se trata de equilibrar estos tres aspectos, ¿verdad?

En cuanto a la latencia, intentamos equilibrar el aspecto de la transmisión, el aspecto paralelo, la velocidad y la coherencia de eso.

En cuanto a la inteligencia, es lo suficientemente inteligente para los usuarios y para compilar con ella.

En cuanto al costo, necesitamos saber cuánto costará por usuario y cuánto podemos ganar por usuario para asegurarnos de que la economía funcione.

No crees primero y luego pienses en la economía.

Piensa en eso desde el principio.

Por lo tanto, aún es muy pronto, pero la economía aquí está empezando a funcionar.

Por lo tanto, los modelos más económicos y más inteligentes serán definitivamente mejores.

Pero ahora mismo, hoy, podemos empezar a trabajar en los desafíos realmente difíciles que debemos abordar para que los agentes de voz sean una realidad en todas partes.

Por eso, me entusiasma mucho poner el poder de los agentes de voz al alcance de todo el mundo.

Gracias.