Баланс между наименьшей задержкой и экономией на облачных ресурсах при использовании виртуальных голосовых агентов

Девин Реймер (Devin Reimer)

Добро пожаловать на курс "Баланс между наименьшей задержкой и экономикой облака в виртуальных голосовых агентах".

Меня зовут Девин Реймер.

Я основатель и генеральный директор AstroBeam.

До этого я был генеральным директором и сооснователем Owlchemy Labs, которая, вероятно, наиболее известна по игре Job Simulator.

Поэтому в AstroBeam мы сосредоточены на создании ИИ, работающего в играх в реальном времени.

В частности, мы сосредоточены на голосовом вводе.

Пока мы выпустили две игры. Stellar Cafe доступна на ПК и в VR.

Это игра, в которой вы разговариваете с роботами в кафе на космической станции и помогаете им решать проблемы.

Она полностью управляется голосом.

Вы можете играть в нее, используя только голосовые команды.

Наша следующая игра, о которой мы объявили сегодня, Robo Detective, создана для Android XR и, в частности, для Project Aura от XREAL.

В этой игре вы играете за детектива, который работает с роботом-партнером, чтобы помочь допросить роботов и раскрыть преступления роботов, и, опять же, на 100% управляемый голосом.

Голосовые агенты – это очень сложная технология, а в играх – ещё сложнее.

Причина в том, что игры очень дешевы, а голосовой агент – это новая статья расходов, которую нужно добавить в этот конвейер.

Кроме того, мы конкурируем не с другими голосовыми агентами, а с качеством всех когда-либо созданных игр, верно?

Поэтому мы должны обеспечить очень высокое качество.

Это не значит, что в других сферах нет уникальных проблем или что ставки там ниже. Но игры – это определенно очень сложная техническая задача.

Но поскольку это игры, у нас есть много возможностей для экспериментов, которые помогают решать сложные задачи.

Поэтому я считаю, что если голосовые агенты могут работать в играх, то они могут работать практически везде.

И поэтому, приложение - то, о чем я говорю в этом разговоре, относится не только к играм, но и к любому голосовому приложению, которое вы хотите создать.

Когда вы думаете о голосовых агентах, я думаю, что есть три основные проблемы.

Итак, у нас есть задержка, интеллект и стоимость.

Но я хочу уточнить, что когда я говорю о голосовых агентах, я имею в виду голосовых агентов как собеседников, а не как подсказки.

Я не говорю о микрофонной обертке, которая отправляет что-то в LLM, а затем ждет ответа.

Я говорю о реальном мире, о диалоге в реальном времени, и это на самом деле то, что довольно сложно построить.

Начнем с задержки.

Насколько быстро это нужно сделать?

Оказывается, она должна быть быстрой, очень быстрой, но в зависимости от того, что вы читали, она может быть не такой быстрой, как вы думаете, или может быть намного быстрее, чем вы думаете.

Давайте поговорим о некоторых цифрах, которые мы обнаружили в ходе тестирования.

Когда я говорю о сквозной задержке, я имею в виду время от последнего высказывания пользователя, последнего звука, который он издал, до момента, когда он услышит ответ.

В ходе тестирования мы обнаружили, что 1,5 секунды – это время, при котором пользователи перестают упоминать скорость загрузки в своих отзывах.

Похоже, именно в этот момент люди начинают чувствовать себя по-настоящему комфортно.

Если же скорость ниже, то люди часто говорят: "Это здорово, но…". Так что, похоже, это оптимальный вариант.

А когда задержка снижается до 1, 2 секунды, общение становится ещё более естественным.

То есть я что-то говорю, а робот быстро отвечает, и так по очереди.

Похоже, что это оптимальный вариант.

Однако 1, 2 секунды – это довольно сложно.

Ещё один интересный вывод: мы провели много тестов и в итоге получили несколько сценариев, позволяющих добиться времени загрузки менее одной секунды.

И вы можете подумать: "О, это будет потрясающе!"

Иногда так и было, а иногда это было ужасно, очень жутко.

Поэтому вы можете услышать, что правильным является время отклика 800 миллисекунд или 500.

Я даже прочитал несколько статей о 300, потому что именно столько может воспринять человек.

На самом деле, это очень зависит от контекста.

Например, если я спрошу, как вас зовут, я буду ожидать, что вы ответите через определенное время.

Если я спрошу вас, в чём смысл жизни, я буду ожидать совсем другого времени ответа.

Когда мы провели тестирование и попросили людей оценить, был ли этот ответ быстрым или медленным, и посмотрели на цифры, то увидели, что они были повсюду.

Ответы, которые занимали много времени, люди называли быстрыми, и наоборот, потому что, как оказалось, это очень зависит от контекста.

и на каком этапе разговора.

Обычно люди ожидают, что первый ответ будет быстрее, чем последующие, потому что на размышления требуется время.

Но иногда вы получаете очень короткие ответы, и ваши ожидания растут.

Это не точная наука, где есть идеальное число, но мы обнаружили, что если вы находитесь в районе 1,5, то у вас все хорошо.

Итак, как только вы достигнете этого значения в 1,5 секунды, вы действительно начнете заботиться о стабильности, верно?

Потому что если это будет происходить в 90% случаев, а в 10% случаев это будет занимать 3 секунды, то ваш опыт будет казаться сломанным, не плохим, а сломанным.

И в итоге, когда вы достигаете достаточной скорости, вы начинаете заботиться о стабильности, то есть о том, чтобы скорость была высокой всегда, а не большую часть времени.

Девин Реймер (Devin Reimer)

Вот стандартная архитектура конвейера обработки голоса.

Итак, мы берем голосовой ввод, отправляем его в LLM, а затем отправляем результат из LLM обратно в сервис для синтеза речи.

То есть, говоря о преобразовании речи в текст, мы отправляем аудио на сервер, а затем преобразуем его в текст.

На стороне LLM мы берем этот текст, этот ответный диалог или преобразуем его в ответный диалог, а затем определяем, какие действия будут происходить от этого персонажа.

Мы тесно связываем эти два понятия, потому что считаем, что это очень важно.

Затем мы отправляем этот текст в сервис синтеза речи, который озвучивает его пользователю, синхронизируя с действиями агента.

Одна из проблем заключается в том, что последовательное выполнение может быть довольно медленным, потому что вам приходится проходить через каждый из этих шагов.

Часто возникает вопрос: если это медленно и требует трех шагов, почему бы не использовать модель "речь-речь"?

Так ведь будет быстрее, да?

И да, в большинстве случаев это будет быстрее, потому что вы запускаете одну вещь.

Но у него есть и существенные недостатки.

Так что, хотя это и быстро, есть некоторые серьезные препятствия для нас, и самое большое из них – это стоимость.

В целом мы обнаружили, что запуск модели Speech-to-Speech обходится примерно в 3–5 раз дороже, чем этот параллельный подход.

Поэтому для нас экономика просто не работает.

Что касается безопасности, то здесь все гораздо сложнее, потому что трудно проверить ответ агента, пока он его не произнесет.

Но если у вас есть конвейерный подход, вы можете взять ответ, который говорит LLM, и проверить его на безопасность прямо там, прежде чем вы даже приблизитесь к отправке чего-либо пользователю.

Что касается стиля голоса, вы ограничены настройками модели преобразования речи в речь.

Нельзя просто сказать: "Знаете что?

Для этого случая я хочу использовать именно такой голос".

Вы застряли на этом конкретном.

В конвейерном подходе вы можете сказать: "О, я собираюсь это изменить.

Я выберу эту модель, потому что она отлично подходит для этого конкретного случая использования".

То же самое касается и интеллекта, верно?

Если у вас есть действительно хорошая модель преобразования речи в речь, которая генерирует хороший голос, но интеллект не совсем такой, как вы хотите, вы не можете просто заменить его, верно?

Вы как бы заперты.

В конвейерном подходе вы говорите: "О, для этого случая я хочу использовать определенную модель".

Одна из областей, в которой Speech-to-Speech определенно выигрывает, – это понимание тона пользователя.

Например, сарказм и тому подобное.

Сейчас в расшифровках речи в текст обычно нет такой информации, но я думаю, что со временем это изменится.

Это определенно одно из преимуществ преобразования речи в речь.

Так что у преобразования речи в речь определенно есть преимущество в скорости, но есть и некоторые проблемы с настраиваемостью, а высокая стоимость, особенно для нас, стала решающим фактором.

Есть ли другой способ?

Да.

Что мы должны делать, так это делать все возможное, чтобы распараллелить конвейер.

Поэтому мы запускаем LLM до того, как преобразование речи в текст будет полностью завершено.

Под уверенностью я имею в виду уверенность в словах, которые генерируются в расшифровке, а затем уверенность в конце очереди.

Поэтому, как только мы думаем, что есть шанс, что это момент, когда пользователь перестал говорить, и это то, что он сказал, мы бежим вперед.

И худший сценарий в этом случае – мы ошибаемся, верно?

Пользователь продолжает говорить.

Но даже в этом случае мы просто отменяем работу LLM и запускаем ее снова.

А поскольку контекст, скорее всего, будет кэширован и мы не сгенерировали так много токенов, это не требует больших затрат, а преимущество заключается в том, что пользователь в конечном итоге слышит вещи быстрее, чем если бы вы ждали полной уверенности.

Мы также не ждем, пока LLM закончит генерировать весь ответ, прежде чем начать отправлять его в Text-to-Speech.

Мы ждем, пока не будет готов первый фрагмент, который можно озвучить.

В большинстве случаев это предложение.

Иногда могут быть и другие конфигурации, но как только у нас появляется первый фрагмент предложения, мы отправляем его в Text-to-Speech.

А затем, если у нас есть хороший синтез речи, который будет транслироваться, как только он будет готов к трансляции, он может быть передан пользователю.

Мы также очень внимательно относимся к количеству токенов, которые необходимо сгенерировать.

Поэтому мы не используем такие вещи, как оболочки JSON и тому подобное, которые могут добавлять дополнительные токены.

Мы стараемся выяснить, какая структура является наиболее упрощенной, чтобы получить максимально быстрый ответ.

Мы также используем такие вещи, как предварительное заполнение помощника, если мы заранее знаем, каким будет первый фрагмент токенов от агента.

И для преобразования текста в речь в итоге получились эти два фрагмента, верно?

Сначала мы получаем первый фрагмент, а затем обрабатываем все остальное.

Но поскольку воспроизведение аудио занимает больше времени, чем генерация, почти всегда первый фрагмент будет воспроизведен пользователю к моменту завершения второго фрагмента.

Поэтому на самом деле это невидимо для пользователя.

Оно приходит так быстро, как только возможно.

Поэтому, когда вы думаете о выборе различных услуг, вот некоторые из наших практических правил.

При выборе аудио и фреймворка агента важно учитывать задержку на входе и выходе.

Как быстро я могу отправлять и скачивать данные?

Что касается преобразования речи в текст, то здесь мы заботимся о времени до уверенности.

Это уверенность в расшифровке и уверенность в конце очереди.

Они связаны, верно?

Если вы не уверены в одном из них, то он будет работать так же медленно, верно?

Поэтому скорость загрузки страницы определяется самым медленным из них.

Что касается LLM, нас интересует время до первого предложения, то есть до первого фрагмента, который можно озвучить.

Итак, у нас есть две части.

Это время до первого токена в сочетании с количеством токенов в секунду.

Поэтому если вы вдруг найдете действительно хорошую модель, которая дает вам действительно хорошее время до первого токена, но медленно работает в токенах в секунду, это может быть хуже, чем альтернатива.

Поэтому выясните, какая комбинация подходит для этого.

А в случае с синтезом речи важна задержка до первого аудио.

Поэтому очень важно измерить, что это такое, потому что иногда звук может возвращаться с тишиной в начале, и пользователь этого не услышит.

Поэтому вам нужно измерить время до момента, когда пользователь услышит звук.

И, как я уже говорил, прежде всего вас интересует стабильность, а не пиковые скорости и не лучший сценарий.

Какова задержка всего этого стека?

Девин Реймер (Devin Reimer)

Сейчас для фреймворков аудиоагентов мы используем LiveKit.

Для преобразования речи в текст мы используем Deepgram.

В качестве LLM мы используем Gemma 4 31B, размещенную на LiveKit.

Для преобразования текста в речь мы используем Inworld AI text-to-speech 2.

Кроме того, мы создали агентную обвязку AstroBeam AI, которая не только связывает все эти элементы, но и добавляет все необходимое для создания действительно хорошего голосового ИИ-агента, особенно такого интерактивного, как наш, для игр.

Итак, я ещё не говорил о моделях безопасности.

Традиционно модели безопасности являются частью прохода LLM, но это добавляет задержку и дополнительный шаг.

А что, если вы будете проводить собственные исследования?

Вот как на самом деле выглядит наш стек.

Поэтому, когда мы получаем первый фрагмент текста, который нужно отправить в систему синтеза речи, мы одновременно отправляем его в модель безопасности.

А поскольку модель безопасности меньше и работает быстрее, чем преобразование речи в текст, она почти всегда выполняется заранее.

Это означает, что добавление модели безопасности не увеличивает задержку в нашем стеке. Более того, мы можем использовать гораздо более крупную модель безопасности, чем большинство людей могут себе представить.

Это очень важно для нас, особенно потому, что мы создаем игры.

В этом мире очень важен контекст.

Например, вы создаете игру в средневековом сеттинге, и в ней есть неигровой персонаж, который кричит: "В атаку!

"Голову с плеч!", верно?

Традиционная модель безопасности может быть такой: "Ого, это не круто.

Ты не должен так говорить".

Но в контексте этой игры это имеет смысл.

Для этого мы используем более надежную модель безопасности, которая учитывает больше контекста о том, что происходит в мире.

Вы могли заметить, что модель безопасности запускается дважды: сначала для первого фрагмента, а затем для всего текста, когда мы получаем последний фрагмент.

Опять же, нам приходится запускать его дважды, но это не добавляет задержки в стек.

Итак, теперь мы достаточно быстры, но, к сожалению, это не имеет значения, если мы недостаточно умны.

Девин Реймер (Devin Reimer)

Насколько умным он должен быть?

Она должна быть достаточно умной для ваших пользователей, но, что более важно, достаточно умной для вас, чтобы вы могли с ней работать.

И это часто то, о чем люди не думают, когда они выбирают то, что им нужно для разведки.

Мы работаем над голосовыми агентами уже около трех лет. Например, на ранних этапах мы использовали некоторые ранние модели LLaMA, и хотя нам удалось заставить их работать для пользователей, разработка была очень дорогой, потому что все было очень хрупким.

Модели могли легко генерировать нежелательные или бессмысленные ответы, поэтому мы потратили много инженерных усилий, чтобы заставить их работать.

Поэтому мы уделяем этому особое внимание, ведь если мы не сможем быстро создавать эти вещи, мы не сможем донести их до пользователей.

Поэтому очень важно учитывать оба этих фактора.

Часто, когда люди думают об интеллекте, они думают о LLM, верно?

Но это лишь часть того, что нужно сделать.

Когда речь заходит об интеллекте, мы должны учитывать каждую деталь.

Давайте поговорим о преобразовании речи в текст.

Поэтому нас интересует низкая частота ошибок в словах.

Кроме того, даже если ошибка происходит, мы генерируем что-то очень близкое к тому, что должно быть на самом деле. И если это действительно близко, LLM часто может, используя контекст, очень хорошо понять, что это такое.

Если частота ошибок низкая, но количество ошибок очень велико, LLM будет гораздо сложнее понять, каково было фактическое намерение.

Ещё один важный фактор – целевая платформа.

Например, если я создаю XR-приложение и у меня есть микрофоны, которые находятся очень близко ко рту пользователя, я получу действительно хорошие, высококачественные аудиоданные с микрофона, и это может очень хорошо работать для определенных моделей.

Но если я создаю приложение для мобильного телефона, которым люди будут пользоваться на оживленной улице, это совсем другое дело. Разные модели будут вести себя по-разному и по-разному понимать, что говорится.

Поэтому вам нужно подумать об этом и убедиться, что вы выбираете правильную платформу, для которой создаете.

Теперь перейдем к преобразованию текста в речь.

Звучит естественно, правда?

Наша цель – сообщить пользователю, что он может понять.

Но это только часть, верно?

Выразительность агента также очень важна, потому что она несёт информацию. Кроме того, в ходе игровых тестов мы обнаружили, что чем выразительнее наши агенты, тем умнее они кажутся пользователям, и это вполне логично.

И достаточно ли быстро?

В предыдущем разделе я говорил о задержке, но она также важна и для воспринимаемого интеллекта.

Пользователи воспринимают скорость ответа как напрямую связанную с тем, насколько он умен.

Если я быстро отвечаю, это, вероятно, звучит более разумно.

И поэтому эти вещи могут действительно иметь значение, когда речь идет о том, как пользователь воспринимает опыт, а также о том, насколько он может быть погружен в опыт.

Теперь перейдем к LLM.

Это, безусловно, самая сложная задача, потому что здесь так много разных требований, верно?

Итак, у нас есть понимание речи, контекст и обоснование.

В играх это очень сложно, потому что нужно заземлить целый мир и вселенную, верно?

Это не текстовое поле, в котором можно выдумывать происходящее.

Если агент в игре говорит: "На столе лежит яблоко", а яблока на столе нет, это испортит впечатление пользователя.

Нам также нужны такие вещи, как строгое следование правилам.

Игры основаны на правилах.

Может ли LLM справиться с этим?

Can we have a low hallucination rate?

Можем ли мы сделать так, чтобы у агента был постоянный характер, когда вы взаимодействуете с ним снова и снова?

Похоже ли, что это один и тот же агент?

И ещё один вопрос, который может поставить вас в тупик, потому что он не является проблемой в начале разработки: может ли ваша модель справиться с растущим размером запроса?

Потому что неизбежно, по мере того, как вы продолжаете развиваться, вы будете вкладывать больше вещей в подсказку.

Но по мере того, как пользователи продолжают играть, в этой подсказке будет больше истории чата.

Справится ли этот запрос с таким ростом?

Потому что иногда случается так, что для определенных моделей по мере роста вашего запроса качество ответа снижается, и поэтому вам нужно как бы выяснить, каковы ваши фактические потребности в количестве, которое должно входить в этот запрос каждый раз.

Но это лишь вершина айсберга, и многое зависит от того, что именно вы создаете.

Поэтому нужно очень хорошо подумать о том, что вы создаете и чего пытаетесь достичь.

Итак, теперь мы достаточно быстры и умны, но все это не имеет значения, если это стоит слишком дорого.

Девин Реймер (Devin Reimer)

Насколько дешёвым он должен быть?

К сожалению, все немного сложнее.

Поэтому нам нужно думать об экономике приложения или игры, которую мы создаем, верно?

Итак, несколько вопросов, которые вам нужно задать.

Как долго пользователь будет взаимодействовать с вашими голосовыми агентами?

Сколько вы зарабатываете на одном пользователе?

И сколько стоит час работы этого голосового стека?

Мы собираем их вместе, чтобы попытаться разобраться, понять, есть ли в этом смысл.

Вот экономика нашей первой игры, Stellar Cafe.

Время игры в Stellar Cafe составляет от 1,5 до 3,5 часов, поэтому давайте возьмем среднее значение – около 2 часов.

Стоимость работы голосовых агентов составляет около 1,2 доллара США в час на пользователя, и пользователи взаимодействуют с ними 100 % времени.

Это игра, полностью управляемая голосом.

Мы продаем игру по фиксированной цене – 10 долларов США.

Мы не используем подписки, потому что их очень сложно внедрить в игры. Я твердо убежден, что мы должны работать по фиксированной цене, иначе ничего не получится и мы не сможем масштабироваться.

Раньше мы брали 15 долларов, но мы работали над снижением затрат на сервер, поэтому теперь мы снизили их до 10 долларов.

И эти 1,20 доллара – это то, что мы имеем.

Это не универсальная цена.

Я видел, что эти вещи стоят по-разному, и иногда намного дороже.

И поэтому вам также нужно выяснить, где вы находитесь с точки зрения затрат.

Мы могли бы сделать его дешевле, но мы стараемся держать планку качества как можно выше.

Таким образом, за 2 часа игры стоимость нашего голосового стека составляет около 2,40 доллара США на пользователя.

И поскольку мы берем 10 долларов, а магазин берет комиссию, это означает, что мы зарабатываем около 4,59 долларов на пользователя, верно?

И поэтому экономика этого работает, верно?

Голос – это наша фишка, на которую мы хотим тратить деньги, и это работает.

Это очень маленькая игра.

Давайте поговорим о чем-то более масштабном.

Давайте представим гипотетическую сюжетную игру, прохождение которой занимает от 5 до 9 часов, то есть в среднем 7 часов.

На самом деле большинство людей, многие люди не заканчивают игры, они немного играют в игру и как бы бросают ее, но я хочу выбрать что-то немного более высокое, чтобы убедиться, что экономика все еще работает.

Итак, мы сохраним эту ставку в размере 1,20 доллара в час, но мы собираемся изменить то, что голосовой компонент будет использоваться в 60% случаев, потому что в более крупной игре будет гораздо больше механик, чем просто голос.

Так что это по-прежнему будет игра, в которой нужно говорить, но в ней появятся и другие функции.

Итак, если мы берем 20 долларов, то, если снова все это проработать, это будет стоить нам около... будет стоить нам около 5 долларов на пользователя, что означает, что в конце дня мы зарабатываем около 9 долларов на пользователя.

Так что, опять же, с этим экономика работает.

Это не значит, что экономика будет работать для всего.

Например, не стоит делать так: "Я хочу создать бесплатную игру, в которую пользователи будут играть от 1 до 100 часов".

Итак, давайте усредним это до 10 часов.

Она полностью управляется голосом. Допустим, она стала хитом и приносит около 3 долларов на пользователя. Для бесплатной игры это отличный результат.

Вы потеряете 10 долларов США за каждого пользователя.

Поэтому он пока не работает со всеми этими вещами, и вам нужно подумать о том, что вы сейчас создаете, и имеет ли это смысл?

Не откладывайте расчеты на последний момент.

Девин Реймер (Devin Reimer)

Следующий вопрос, который возникает: а как насчет локальных моделей?

Потому что если у вас есть эта большая проблема со стоимостью, разве локальные модели не устранят ее?

Да, это так.

Но здесь есть некоторые компромиссы, о которых нам нужно подумать.

Что касается затрат, то да, мы бы избавились от счетов за сервер, что было бы огромным преимуществом и открыло бы гораздо больше возможностей.

Но сейчас облако может решить многие проблемы, с которыми не справляются локальные устройства.

Например, вычисления.

Часто люди говорят: "Смотрите, я нашел отличную модель преобразования речи в текст, и она работает локально на этом устройстве, верно?"

Отлично, но нам нужно подумать о том, что работает не одна модель, а несколько моделей, верно?

В нашем случае четыре, потенциально одновременно, и поэтому недостаточно, чтобы что-то запускалось один раз, оно должно запускаться несколько раз одновременно.

И если вы это сделали, осталось ли что-то, что нужно для работы игры или приложения?

Если вы максимально загрузили графический процессор, вы не сможете запустить видеоигру.

Итак, предположим, вы преодолели эти трудности.

Итак, следующий пункт – скорость, верно?

Часто их можно запустить, но они будут работать очень медленно, и это будет больше похоже на подсказки, чем на реальный разговор в реальном времени.

Так что, теоретически, локальное хранение имеет преимущество в будущем, потому что вам не нужно делать этот путь туда и обратно из интернета.

Прямо сейчас сложно найти модели, которые будут работать с нужной скоростью.

Итак, допустим, вы решили проблему с вычислительными мощностями и скоростью. Теперь нужно подумать о качестве.

Поскольку вы запускаете ее на локальном устройстве, вы используете меньшую LLM, например более примитивное преобразование текста в речь. Это может представлять определенные проблемы, когда дело доходит до того, какой контент вы создаете.

И, как я уже говорил, когда вы думаете о LLM, важно не только то, достаточно ли она хороша для ваших пользователей, но и то, достаточно ли она хороша для вас, чтобы разрабатывать с ее помощью.

И если на основе этой модели становится довольно сложно что-то построить, то об этом определенно стоит задуматься.

Итак, вы освоили вычисления, скорость и качество. Следующий шаг – портативность.

Если вы выиграли и прошли весь этот процесс, и у вас есть эта штука, работающая, скажем, на RTX 5070, это может быть единственное место, где она может работать.

Поэтому, если у вас появится возможность перенести его на новую платформу, вы можете столкнуться с трудностями.

Для работы с облаком нужен только интернет.

И это очень важный момент.

Позволяет вести трансляции на нескольких платформах.

Теперь давайте поговорим о гибридном подходе.

Поэтому давайте запустим часть вещей в облаке, а часть локально.

Вроде того. Это возможно?

Ну, это не такая уж большая победа, как ты думаешь.

Если вы получите модель, которая достаточно мала для запуска на большинстве локальных платформ, то ее запуск в облаке, скорее всего, будет стоить копейки.

И поэтому, как правило, только когда вы решите весь стек, вы получите самые большие выигрыши.

Затем возникает следующий вопрос: что, если вместо этого вы запустите его локально, если это возможно, верно?

У них есть подходящее оборудование, а в облаке, если у вас его нет, верно?

Вы можете запустить более мощную вещь в облаке.

Это новые вызовы, верно?

Если вы в конечном итоге запустите другую модель, это может сильно повлиять на разработку.

и в итоге вам все равно приходится тратить много времени на работу с минимальными требованиями.

И у вас могут быть модели, которые ведут себя совершенно по-разному.

Поэтому, если вы не используете точно такие же модели, вы можете в конечном итоге добавить много времени и затрат на разработку.

Поэтому важно подумать о том, чего вы пытаетесь достичь. Допустим, вы разобрались с этим и получили хорошую локальную модель, если это необходимо, и облачную, если нет. Но экономика все равно должна работать для облачной модели.

Потому что если внезапно все ваши пользователи окажутся на облачной стороне, вы проиграете, если не подумали об этом с экономической точки зрения.

Так что, когда речь заходит о локальных моделях, это, безусловно, большая экономическая победа, но это только начало.

Для приложений, чувствительных к цене, таких как игры, я считаю, что в конечном итоге это, скорее всего, победит.

Сейчас это сложно, за исключением некоторых случаев, например команд.

Поэтому прямо сейчас, сегодня, мы хотим получить наилучший возможный опыт.

Вот почему мы используем облако.

Но эта сфера развивается очень быстро, и ситуация меняется стремительно.

Теперь давайте подумаем о моделях, которые мы используем.

Следующий вопрос: открытые или закрытые веса?

Что нам нужно сделать?

Я хочу сосредоточиться на LLM, потому что мы обнаружили, что именно на эту область больше всего влияет вопрос открытости и закрытости.

Так что здесь определенно есть свои плюсы и минусы.

Итак, когда речь заходит о закрытых моделях, это, как правило, передовой искусственный интеллект, верно?

Поэтому, если вам нужно больше информации, вам часто приходится обращаться именно к ним.

В то же время открытые модели часто отстают на поколение.

Так что это может быть реальным компромиссом.

Что касается скорости, я уже говорил, что для нас очень важно время до первого предложения.

Мы обнаружили, что за время существования закрытых моделей скорость часто снижается.

Причин может быть много.

Возможно, моделью пользуется больше людей или аппаратное обеспечение было заменено на более новое.

Но это то, что мы заметили.

Поэтому нужно быть осторожным, потому что это может вызвать проблему, когда вы отправляете что-то, и это здорово, со временем это может стать непригодным для использования.

Далее идут всплески.

Для вас важна такая согласованность, и поэтому часто закрытые модели строятся на основе пакетной обработки в асинхронных задачах, а не на задержках P99, тогда как на открытой стороне вы можете выбрать поставщика, который заботится именно о том, что вас волнует, чтобы дать вам уверенность, скорость и задержку, которые вам в итоге нужны.

Следующий фактор – срок службы самой модели.

Поэтому закрытые модели часто прекращают поддерживать примерно через год.

Это означает, что если вы разрабатываете что-то в течение года и ожидаете, что оно будет в производстве в течение 3 лет, вы можете пройти более 3 изменений модели.

И даже если модель лучше, это не значит, что она будет лучше работать для вас.

За последние три года мы внесли много изменений в модели, и часто на переоснащение уходят недели, а иногда и месяцы работы. В случае с открытыми моделями вы можете продолжать использовать их, пока кто-то готов их размещать или вы готовы размещать их самостоятельно.

Наконец, это стоимость.

Часто со временем эти закрытые модели по мере выпуска новых версий становятся дороже предыдущих.

И это ещё один момент, на который стоит обратить внимание, когда речь заходит об экономике. Опять же, ваша экономика могла работать при запуске, а затем перестать работать, когда вы в конечном итоге перейдёте на другие модели.

В открытом аукционе вы можете менять цену, и вряд ли она сильно вырастет, потому что модель та же самая.

Мы используем Gemma 4 31B, и это стало для нас огромным прорывом, потому что для нас это было своего рода лучшим сочетанием скорости, интеллекта и стоимости.

Это также позволило нам двигаться очень быстро.

Разрабатывать с ним намного проще, чем с некоторыми другими инструментами, которые мы использовали раньше.

Это не значит, что мы используем только его.

Мы используем множество комбинаций различных открытых и закрытых моделей.

Например, генерация памяти, безопасность и персонализация.

Просто очень важно выбрать лучшую модель для ваших конкретных потребностей в этой задаче.

Но Gemma 4 31B – это наша рабочая лошадка, когда речь заходит о голосовых агентах.

Поэтому, когда речь заходит о таких различиях между ними, открытые модели определенно дают вам больший контроль и позволяют сохранять модели до тех пор, пока их можно размещать по более предсказуемой цене.

и прекращение поддержки модели не повлияет на ваши планы.

Девин Реймер (Devin Reimer)

Итак, чтобы подвести итог, нужно сбалансировать все эти три вещи, верно?

Задержка. Мы стараемся найти баланс между потоковой передачей, параллельной обработкой, скоростью и стабильностью.

Что касается искусственного интеллекта, он достаточно умен для пользователей и достаточно умен для разработчиков.

Что касается стоимости, нам нужно знать, сколько это будет стоить на одного пользователя и сколько мы можем заработать на одном пользователе, чтобы мы могли убедиться, что экономика работает.

Не создавайте игру, не продумав экономику.

Подумайте об этом с самого начала.

Пока рано делать выводы, но экономика уже начинает работать.

И поэтому более дешевые модели определенно будут лучше, более умные модели определенно будут лучше.

Но прямо сейчас, сегодня, мы можем начать работать над действительно сложными задачами, которые необходимо решить, чтобы голосовые агенты стали реальностью повсюду.

И я очень рад, что теперь эти возможности голосовых агентов доступны всем.

Спасибо!