가상 음성 에이전트에서 매우 짧은 지연 시간과 클라우드 경제성의 균형 맞추기

데빈 라이머

가상 음성 에이전트에서 매우 짧은 지연 시간과 클라우드 경제학의 균형을 맞추는 방법에 관한 강의에 오신 것을 환영합니다.

저는 데빈 라이머입니다.

AstroBeam의 설립자 겸 CEO입니다.

이전에는 Owlchemy Labs의 CEO이자 공동 설립자였으며, Job Simulator로 가장 잘 알려져 있습니다.

AstroBeam은 게임에 실시간 AI를 구축하는 데 주력하고 있습니다.

특히 입력 수단으로서의 음성에 집중하고 있습니다.

지금까지 VR 및 PC용 Stellar Cafe와

우주 정거장 카페에서 로봇과 대화하며 로봇의 문제를 해결하는 게임입니다.

100% 음성으로 작동합니다.

메뉴와 탐색을 포함한 전체 게임을 음성만으로 플레이합니다.

오늘 발표한 차기작인 Robo Detective는 Android XR, 특히 XREAL의 Project Aura를 위해 제작되었습니다.

이 게임에서 플레이어는 로봇 파트너와 함께 로봇을 인터뷰하여 로봇 범죄를 해결하는 형사 역할을 맡게 되며, 이 게임 역시 100% 음성으로 진행됩니다.

음성 에이전트는 정말 어렵고, 게임에서는 더 어렵습니다.

게임은 비용이 매우 저렴한데, 음성 에이전트는 파이프라인에 추가되는 새로운 비용이기 때문입니다.

또한 다른 음성 에이전트와 경쟁하는 것이 아니라 지금까지 만들어진 모든 게임의 품질과 경쟁하는 것이죠.

따라서 매우 높은 품질로 출시해야 합니다.

그렇다고 해서 고유한 과제가 있거나 위험이 훨씬 더 큰 특정 음성 에이전트 사용 사례가 없다는 것은 아니지만, 이 분야에서 게임은 기술적으로 매우 까다롭습니다.

하지만 게임이기 때문에 이러한 어려운 문제를 해결하는 방법을 실험할 여지가 많습니다.

따라서 음성 에이전트가 게임 내에서 작동할 수 있다면 거의 모든 곳에서 작동할 수 있다고 생각합니다.

따라서 이 강연에서 말씀드리는 내용은 게임뿐만 아니라 빌드하려는 모든 음성 우선 애플리케이션에 적용됩니다.

음성 에이전트를 생각할 때 세 가지 핵심 과제가 있다고 생각합니다.

지연 시간, 지능, 비용이 있습니다.

한 가지 명확히 하고 싶은 점은 제가 음성 에이전트에 대해 이야기할 때 프롬프트가 아닌 대화로서의 음성 에이전트를 이야기한다는 것입니다.

LLM에 무언가를 전송한 다음 응답을 기다리는 마이크 래퍼를 말하는 것이 아닙니다.

실시간으로 실제 대화를 주고받는 것을 말하는 것이며, 이는 실제로 구축하기가 매우 어렵습니다.

지연 시간부터 살펴보겠습니다.

얼마나 빨리 처리해야 하나요?

빠르고 매우 빨라야 하지만, 읽은 내용에 따라 생각만큼 빠르지 않을 수도 있고 생각보다 훨씬 빠를 수도 있습니다.

그럼 여러 테스트를 통해 발견한 몇 가지 수치를 살펴보겠습니다.

따라서 엔드 투 엔드 지연 시간은 마지막 사용자 발화, 즉 사용자가 마지막으로 낸 소리부터 오디오가 다시 들리는 시점까지의 시간을 의미합니다.

테스트에서 발견한 것은 약 1.5초가 사용자의 플레이 테스트 피드백을 받을 때 속도나 느림 등을 언급하지 않기 시작하는 시점이라는 것입니다.

이 시점이 사람들이 정말 편안하게 느끼기 시작하는 지점인 것 같습니다.

이보다 느려지면 사람들이 '좋긴 한데…'라며 불만을 제기하는 경우가 많으므로 이 정도가 적절한 수준인 것 같습니다.

그리고 속도가 더 빨라지면 약 1.2초에서 더 자연스러운 대화가 오가기 시작한다는 것을 발견했습니다.

제가 무언가를 말하면 이 경우 로봇이 아주 빠르게 무언가를 말하고, 이렇게 대화를 주고받는 거죠.

이 부분에서 최적의 지점이 발견된 것 같습니다.

하지만 1.2초는 스택 내에서 실제로 수행하기가 상당히 어렵습니다.

또 다른 흥미로운 발견은 많은 테스트를 거친 결과 1초 미만의 시나리오를 얻을 수 있었다는 것입니다.

그러면 '와, 정말 멋지겠다'라고 생각할 수도 있습니다.

어떤 때는 그랬고, 어떤 때는 끔찍하고 매우 기괴하게 느껴졌습니다.

따라서 응답 시간이 800밀리초가 적절하다거나 500밀리초가 적절하다는 이야기를 들을 수 있습니다.

인간의 인식이 실제로 도달하는 지점이 300이기 때문에 300에 관한 기사도 많이 읽었습니다.

실제로는 상황에 따라 크게 달라집니다.

예를 들어 제가 이름을 물어보면 여러분이 대답하는 데 걸리는 시간에 대한 기대치가 있습니다.

삶의 의미가 무엇인지 묻는다면 매우 다른 소요 시간이 예상됩니다.

실제로 테스트를 진행하고 사용자에게 이 대답이 빠른지 느린지 평가해 달라고 요청했을 때, 실제 수치를 살펴보면 결과가 매우 다양했습니다.

응답 시간이 길었던 경우에도 사용자는 빠르다고 답했고, 그 반대의 경우도 있었습니다. 이는 응답 속도가 맥락에 따라 크게 달라지기 때문입니다.

대화에서 어디에 있었는지도 표시됩니다.

일반적으로 사람들은 생각할 시간이 있기 때문에 첫 번째 응답이 후속 응답보다 빠를 것으로 기대합니다.

하지만 때로는 짧은 대화가 오가면서 기대치가 높아지기도 합니다.

완벽한 숫자가 있는 완벽한 과학은 아니지만, 1.5 정도면 꽤 괜찮은 수준이라는 것을 발견했습니다.

1.5초에 도달하면 이제 일관성에 신경을 쓰기 시작합니다.

90% 의 경우에 이와 같이 작동하지만 10% 의 경우에 3초가 걸린다면 경험이 나쁜 것이 아니라 망가진 것처럼 느껴질 것입니다.

따라서 충분히 빨라지면 일관성에만 신경 쓰게 됩니다. 대부분의 시간이 아니라 항상 빨라야 합니다.

데빈 라이머

표준 음성 파이프라인 아키텍처는 다음과 같습니다.

따라서 음성 텍스트 변환을 가져와 LLM으로 전송한 다음 LLM의 결과를 텍스트 음성 변환으로 다시 전송합니다.

즉, Speech-to-Text는 오디오를 서버로 전송한 다음 텍스트로 변환합니다.

LLM 측에서는 해당 텍스트, 즉 대답을 가져오거나 대답으로 변환한 다음 해당 캐릭터가 어떤 행동을 취할지 결정합니다.

Google은 이 두 가지가 매우 중요하다고 생각하기 때문에 긴밀하게 결합합니다.

그런 다음 TTS 측면에서 이 텍스트를 가져와 TTS로 전송하고 사용자에게 스트리밍하며, 에이전트가 수행하려는 작업과도 시간을 맞춥니다.

이 방법의 문제 중 하나는 순차적으로 실행하면 각 단계를 거쳐야 하므로 속도가 상당히 느려질 수 있다는 것입니다.

그래서 제가 자주 받는 질문은, 이 방식이 느리고 세 단계를 거쳐야 한다면 그냥 음성 음성 변환 모델을 사용하면 되지 않느냐는 것입니다.

그게 더 빠를 테니까요.

그리고 대부분의 경우 한 가지만 실행하므로 더 빠릅니다.

하지만 몇 가지 큰 단점이 있습니다.

빠르기는 하지만 몇 가지 큰 문제가 있는데, 가장 큰 문제는 비용입니다.

따라서 일반적으로 Speech-to-Speech 모델을 실행하는 데 드는 비용은 이 병렬화된 접근 방식보다 약 3~5배 더 비쌉니다.

따라서 경제적으로 타당하지 않습니다.

안전 측면에서는 에이전트가 말하기 전까지는 에이전트의 대답을 검증하기가 더 어렵기 때문에 실제로 훨씬 더 까다롭습니다.

하지만 파이프라인 접근 방식을 사용하면 LLM의 대답을 가져와서 사용자에게 전송하기 전에 바로 검증하고 안전성을 확인할 수 있습니다.

음성 스타일 지정의 경우 음성-음성 모델 내의 사전 설정에 얽매이게 됩니다.

"있잖아,

이 경우에는 이런 유형의 음성을 사용하고 싶습니다."

특정 버전에 얽매이게 됩니다.

파이프라인 방식에서는 '바꿔야지'라고 생각할 수 있습니다.

이 모델은 이 특정 사용 사례에 매우 적합하므로 이 모델을 선택하겠습니다."

지능도 마찬가지입니다.

좋은 음성을 생성하는 정말 좋은 음성 음성 변환 모델이 있지만 지능이 원하는 수준이 아니라면 이를 쉽게 바꿀 수 없습니다.

사용자가 갇혀 있는 셈입니다.

파이프라인 방식에서는 '이 사용 사례에는 특정 모델을 사용하고 싶다'고 생각할 수 있습니다.

Speech-to-Speech가 확실히 우수한 영역 중 하나는 사용자의 어조를 이해하는 것입니다.

예를 들어 비꼬는 표현 같은 것 말이죠.

현재 음성 텍스트 변환 스크립트에는 일반적으로 이러한 정보가 많지 않지만 시간이 지남에 따라 바뀔 것이라고 생각합니다.

이는 Speech-to-Speech의 확실한 장점 중 하나입니다.

따라서 Speech-to-Speech는 속도 면에서 확실히 장점이 있지만 구성 가능성 면에서는 몇 가지 문제가 있으며, 특히 높은 비용은 저희에게는 큰 걸림돌이었습니다.

그렇다면 다른 방법이 있을까요?

예.

우리가 해야 할 일은 파이프라인을 병렬화하기 위해 최선을 다하는 것입니다.

따라서 Google은 음성 텍스트 변환이 완전히 신뢰할 수 있는 수준에 도달하기 전에 LLM을 실행하는 등의 작업을 수행합니다.

여기서 신뢰도란 스크립트에 생성되는 단어에 대한 신뢰도와 발화 종료에 대한 신뢰도를 의미합니다.

따라서 사용자가 말을 멈춘 순간이고 사용자가 말한 내용이 이것일 가능성이 있다고 생각되면 바로 실행합니다.

이 경우 최악의 시나리오는 우리가 틀렸다는 것입니다.

사용자가 계속 말합니다.

하지만 이 시나리오에서도 LLM을 취소한 후 다시 실행하기만 하면 됩니다.

컨텍스트가 캐시될 가능성이 높고 생성된 토큰이 많지 않기 때문에 실제로 큰 비용이 들지 않으며, 사용자는 완전한 확신을 기다리는 것보다 더 빠르게 결과를 들을 수 있다는 이점이 있습니다.

또한 LLM이 전체 대답 생성을 완료할 때까지 기다리지 않고 Text-to-Speech로 전송하기 시작합니다.

우리가 기다리는 것은 첫 번째 말할 수 있는 청크입니다.

대부분의 경우 한 문장으로 작성합니다.

다른 구성이 있을 수도 있지만 첫 번째 문장 청크가 확보되는 즉시 Text-to-Speech로 전송합니다.

그런 다음 스트리밍할 수 있는 우수한 텍스트 음성 변환이 있으면 스트리밍할 준비가 되는 즉시 사용자에게 전달할 수 있습니다.

또한 생성해야 하는 토큰 수에도 세심한 주의를 기울입니다.

따라서 추가 토큰을 추가할 수 있는 JSON 래퍼 등은 사용하지 않습니다.

가장 빠른 응답을 얻기 위해 가장 단순화된 구조가 무엇인지 파악하려고 노력합니다.

또한 에이전트에서 첫 번째 토큰 청크가 무엇이 될지 미리 알고 있는 경우 어시스턴트 사전 입력과 같은 기능도 사용합니다.

텍스트 음성 변환의 경우 이 두 청크가 됩니다.

따라서 첫 번째 발화 가능한 청크가 들어오고 그 후에 다른 모든 항목이 실행됩니다.

하지만 오디오 재생을 듣는 데는 생성보다 시간이 더 오래 걸리므로 거의 모든 경우에 두 번째 청크가 완료될 때까지 첫 번째 청크가 사용자에게 재생됩니다.

따라서 사용자에게는 보이지 않습니다.

최대한 빨리 제공됩니다.

따라서 다양한 서비스를 선택할 때 고려해야 할 몇 가지 경험 법칙이 있습니다.

좋은 오디오 및 에이전트 프레임워크를 선택할 때는 입력 및 출력 지연 시간이 가장 짧은 것이 중요합니다.

그렇다면 얼마나 빨리 데이터를 업로드하고 다운로드할 수 있을까요?

음성 텍스트 변환 측면에서는 신뢰도에 도달하는 시간을 중요하게 생각합니다.

이것이 스크립트 신뢰도와 발화 종료 신뢰도입니다.

이 두 가지가 함께 사용되죠?

한 가지에 빠르게 확신을 갖지 못하면 그만큼 느려질 뿐입니다.

따라서 그중 가장 느린 것만큼만 빠릅니다.

LLM 측면에서는 첫 번째 문장, 즉 첫 번째 발화 가능한 청크가 생성되는 시간이 중요합니다.

두 가지 부분으로 나뉩니다.

첫 번째 토큰까지의 시간과 초당 토큰 수를 결합한 것입니다.

따라서 첫 번째 토큰까지의 시간이 매우 짧지만 초당 토큰 수가 느린 매우 좋은 모델을 갑자기 발견한다면 대안보다 더 나쁠 수 있습니다.

따라서 적절한 조합을 찾아야 합니다.

텍스트 음성 변환 측면에서는 첫 번째 오디오가 생성되는 시간이 중요합니다.

따라서 이를 측정하는 것이 매우 중요합니다. 오디오가 앞부분에 무음이 포함된 상태로 반환될 수 있으며 사용자는 이를 듣지 못할 수 있기 때문입니다.

따라서 사용자가 소리를 듣는 시점까지 측정해야 합니다.

그리고 앞서 언급했듯이 무엇보다도 최고 속도나 최상의 시나리오가 아닌 안정성에 신경을 씁니다.

이 전체 스택의 일관된 지연 시간은 얼마인가요?

데빈 라이머

현재 오디오 에이전트 프레임워크에는 LiveKit을 사용하고 있습니다.

음성 텍스트 변환에는 Deepgram을 사용합니다.

LLM의 경우 Gemma 4 31B를 사용하며 LiveKit에서 호스팅합니다.

텍스트 음성 변환 측면에서는 Inworld AI 텍스트 음성 변환 2를 사용하고 있습니다.

그리고 그 위에 AstroBeam AI 에이전트 하네스를 구축하여 이 모든 것을 하나로 묶을 뿐만 아니라, 특히 게임용 에이전트와 같이 상호작용이 뛰어난 음성 에이전트를 만드는 데 필요한 모든 요소를 추가했습니다.

아직 언급하지 않은 한 가지는 안전 모델입니다.

따라서 기존에는 안전 모델이 LLM 패스의 일부였지만, 이로 인해 지연 시간이 발생하고 추가 단계가 필요했습니다.

그렇다면 직접 실행하면 어떨까요?

이것이 실제로 Google의 스택에 더 가깝습니다.

여기서 하는 일은 첫 번째 텍스트 청크를 다시 가져올 때, 즉 텍스트 음성 변환으로 전송할 첫 번째 발화 가능한 청크를 가져올 때, 정확히 동시에 안전 모델로 전송하는 것입니다.

안전 모델은 음성 텍스트 변환보다 작고 더 빠르게 실행되므로 거의 대부분의 경우 사전에 실행됩니다.

따라서 안전 모델을 추가해도 스택에 지연 시간이 추가되지 않으며, 실제로 대부분의 사람들이 생각하는 것보다 훨씬 더 큰 안전 모델을 실행할 수 있을 만큼 충분히 큰 규모입니다.

이는 특히 게임을 개발하는 저희에게 매우 중요합니다.

그 세계에는 매우 중요한 맥락이 많이 있습니다.

예를 들어 중세 게임을 빌드하고 있고 이 중세 게임에 "돌격!

목을 쳐라!'라고 말하는 것 같지 않나요?

기존의 안전 모델은 "이런, 좋지 않네요.

그런 말을 하면 안 돼."

하지만 이 게임의 맥락에서는 완벽하게 이해가 됩니다.

이를 위해 세상에서 일어나는 일에 대한 더 많은 맥락을 포함하는 더 강력한 안전 모델을 사용하여 이를 가능하게 합니다.

여기서 안전 모델을 실제로 두 번 실행한다는 것을 알 수 있습니다. 첫 번째 청크에서 실행한 다음 마지막 청크가 모두 모이면 전체에서 다시 실행합니다.

다시 한번 말씀드리지만, 두 번 실행해야 하지만 스택에 지연 시간이 추가되지는 않습니다.

이제 속도는 충분히 빠르지만, 충분히 스마트하지 않다면 속도는 중요하지 않습니다.

데빈 라이머

그렇다면 얼마나 스마트해야 할까요?

사용자에게 충분히 스마트해야 하지만, 개발자가 개발하기에 충분히 스마트해야 한다는 점이 더 중요합니다.

그리고 이것은 사람들이 인텔리전스에 필요한 것을 선택할 때 생각하지 않는 경우가 많습니다.

저희는 약 3년 동안 음성 에이전트를 개발해 왔습니다. 예를 들어 초기에는 초기 LLaMA 모델을 사용했는데, 사용자에게는 어느 정도 작동하는 것처럼 보였지만 모든 것이 매우 불안정했기 때문에 개발 측면에서 비용이 많이 들었습니다.

모델이 바람직하지 않은 대답이나 말이 안 되는 대답을 생성하는 것은 어렵지 않기 때문에 이를 해결하기 위해 많은 엔지니어링 노력을 기울였습니다.

따라서 이 부분을 우선시합니다. 이러한 기능을 빠르게 구축하지 못하면 사용자에게 제공할 수 없기 때문입니다.

따라서 이 두 가지를 모두 고려하는 것이 매우 중요합니다.

사람들은 지능에 대해 생각할 때 LLM을 떠올리는 경우가 많습니다.

하지만 이는 일부에 불과합니다.

지능에 관해서는 모든 부분을 고려해야 합니다.

이제 Speech-to-Text 인텔리전스에 대해 알아보겠습니다.

따라서 여기서 중요한 것은 단어 오류율이 낮아야 한다는 것입니다.

또한 오류율이 낮을 뿐만 아니라 오류가 발생하더라도 실제와 매우 유사한 것을 생성합니다. 매우 유사한 경우 LLM은 컨텍스트를 통해 그것이 무엇인지 매우 잘 이해할 수 있기 때문입니다.

오류율은 낮지만 잘못된 단계가 매우 많으면 LLM은 실제 의도를 파악하는 데 훨씬 더 어려움을 겪게 됩니다.

또 다른 고려사항은 타겟 플랫폼입니다.

예를 들어 XR용으로 빌드하고 있고 사용자의 입에 매우 가까운 마이크가 있다면 고품질의 마이크 오디오 데이터를 얻을 수 있으며, 이는 특정 모델에 매우 적합할 수 있습니다.

하지만 갑자기 사람들이 혼잡한 거리에서 사용할 휴대전화용 앱을 빌드한다면 그 영향은 매우 다를 것이며, 모델마다 다르게 작동하고 다양한 방식으로 말하는 내용을 지능적으로 처리할 수 있을 것입니다.

따라서 빌드하려는 플랫폼에 적합한 것을 선택해야 합니다.

이제 지능형 방정식의 텍스트 음성 변환 측면으로 넘어가겠습니다.

자연스럽게 들리죠?

우리의 목표는 사용자가 이해할 수 있는 내용을 사용자에게 전달하는 것입니다.

하지만 그건 일부에 불과하죠?

에이전트의 표현력도 매우 중요합니다. 표현력에 정보가 담겨 있기 때문입니다. 또한 플레이 테스트를 통해 에이전트의 표현력이 뛰어날수록 사용자가 에이전트를 더 지능적이라고 느낀다는 사실을 발견했습니다. 이는 매우 타당한 결과입니다.

그리고 충분히 빠른가요?

이전 섹션에서 지연 시간에 대해 이야기했지만, 지각된 지능에서도 지연 시간이 중요합니다.

사용자는 지능과 관련하여 응답 속도가 실제 속도와 직접적인 상관관계가 있다고 인식합니다.

빠른 응답을 하면 더 똑똑해 보일 수 있습니다.

따라서 이러한 요소는 사용자가 경험을 어떻게 인식하는지, 그리고 경험에 얼마나 몰입할 수 있는지에 큰 영향을 미칠 수 있습니다.

이제 인텔리전스의 LLM 측면을 살펴보겠습니다.

이것은 균형을 맞추기가 가장 어렵습니다. 여기에는 다양한 요구사항이 있기 때문입니다.

음성 이해, 컨텍스트, 그라운딩이 있습니다.

게임에서는 전체 세계와 우주를 기반으로 해야 하기 때문에 매우 까다롭습니다.

이것은 일어나는 일을 지어낼 수 있는 텍스트 상자가 아닙니다.

게임 내 에이전트가 "테이블 위에 사과가 있습니다"라고 말했는데 테이블 위에 사과가 없다면 사용자의 경험이 깨지게 됩니다.

또한 엄격한 규칙 준수와 같은 요소도 필요합니다.

게임은 규칙을 기반으로 합니다.

LLM이 이를 처리할 수 있나요?

할루시네이션 비율을 낮출 수 있을까요?

동일한 에이전트와 계속 상호작용할 때 일관된 캐릭터를 유지할 수 있을까요?

동일한 상담사처럼 느껴지나요?

그리고 개발 초기에는 문제가 되지 않기 때문에 간과하기 쉬운 문제는 모델이 프롬프트 크기 증가를 처리할 수 있는지 여부입니다.

개발을 계속하다 보면 필연적으로 프롬프트에 더 많은 내용을 넣게 되기 때문입니다.

하지만 사용자가 계속 플레이하면 프롬프트에 더 많은 채팅 기록이 쌓이게 됩니다.

그렇다면 이 프롬프트가 증가하는 데이터를 처리할 수 있을까요?

특정 모델의 경우 프롬프트가 길어질수록 응답 품질이 떨어지기 때문에 매번 프롬프트에 입력해야 하는 양에 대한 실제 요구사항을 파악해야 합니다.

하지만 이는 빙산의 일각에 불과하며, 빌드하는 항목에 따라 크게 달라집니다.

따라서 무엇을 만들고 무엇을 달성하려고 하는지 신중하게 생각해야 합니다.

이제 충분히 빠르고 스마트해졌지만, 비용이 너무 많이 든다면 이 모든 것이 소용없습니다.

데빈 라이머

그렇다면 얼마나 저렴해야 할까요?

안타깝게도 그보다 조금 더 복잡합니다.

따라서 개발 중인 애플리케이션이나 게임의 경제성을 고려해야 합니다.

따라서 몇 가지 질문을 해야 합니다.

사용자가 음성 에이전트와 얼마나 오래 상호작용하나요?

사용자당 수익은 얼마인가요?

그리고 이 음성 스택을 실행하는 데 시간당 비용은 얼마나 드나요?

우리는 이들을 함께 모아 이해하려고 노력하고, 말이 되는지 확인합니다.

첫 번째 게임인 Stellar Cafe의 경제 시스템을 살펴보겠습니다.

Stellar Cafe의 플레이 시간은 1시간 30분에서 3시간 30분 사이이므로 평균 약 2시간이라고 가정해 보겠습니다.

음성 에이전트 실행 비용은 사용자당 시간당 약 1.20달러이며, 사용자는 항상 에이전트와 상호작용합니다.

100% 음성으로 진행되는 게임입니다.

게임에 대해 10달러의 정액 요금을 부과하는데, 이는 전통적인 방식입니다.

게임에서는 구독이 매우 어렵기 때문에 구독을 제공하지 않습니다. 저는 정액 요금으로 운영해야 한다고 굳게 믿습니다. 그렇지 않으면 제대로 작동하지 않고 확장되지 않을 것입니다.

이전에는 15달러를 청구했지만 서버 비용을 낮추기 위해 노력한 결과 이제 10달러로 낮췄습니다.

그리고 이 1.20달러가 현재 상황입니다.

이것은 보편적인 비용이 아닙니다.

이러한 것들은 다양한 비용이 들고 때로는 훨씬 더 비쌉니다.

따라서 비용 측면에서 어느 정도의 위치에 있는지도 파악해야 합니다.

더 저렴하게 만들 수도 있지만 품질 기준을 최대한 높게 유지하려고 노력하고 있습니다.

이 모든 것을 종합해 보면, 2시간의 플레이 시간 동안 사용자당 음성 스택 비용은 약 2.40달러입니다.

우리가 10달러를 청구하고 스토어에서 수수료를 가져가므로 사용자당 약 4.59달러를 벌게 됩니다.

이러한 경제학은 효과가 있습니다.

목소리가 우리의 핵심 요소이고, 여기에 돈을 쓰고 싶고, 효과가 있습니다.

이 게임은 정말 작습니다.

좀 더 큰 주제에 대해 이야기해 보겠습니다.

5~9시간, 평균 7시간 정도의 내러티브 게임을 가상으로 설정해 보겠습니다.

실제로는 대부분의 사람들이 게임을 끝까지 플레이하지 않고, 조금 플레이하다가 포기하지만, 경제성이 유지되도록 조금 더 높은 수치를 선택하고 싶습니다.

따라서 시간당 1.20달러는 유지하되, 더 큰 게임에는 음성 외에도 훨씬 더 많은 메커니즘이 있으므로 음성 구성요소는 60% 만 사용하도록 변경합니다.

따라서 여전히 음성 기반 게임이지만 그 안에 다른 종류의 기능도 포함될 것입니다.

따라서 20달러를 청구하면, 이 모든 것을 다시 계산해 보면, 사용자당 약 5달러의 비용이 들고, 결국 사용자당 약 9달러의 수익을 올리게 됩니다.

따라서 이 경우에도 경제성이 확보됩니다.

그렇다고 해서 모든 분야에서 경제성이 확보되는 것은 아닙니다.

예를 들어, "무료 플레이 게임을 만들고 싶고, 이 게임을 플레이하는 사용자는 1시간에서 100시간 이상 플레이할 것 같다"라고 생각하는 것은 좋지 않습니다.

평균 10시간이라고 가정해 보겠습니다.

100% 음성으로 구동되지만, 이 게임이 성공하여 사용자당 약 3달러의 수익을 창출한다고 가정해 보겠습니다. 무료 플레이 게임으로서는 꽤 괜찮은 수익이죠.

사용자당 10달러의 손실이 발생합니다.

따라서 아직은 이 모든 것을 처리할 수 없으며, 현재 빌드 중인 항목을 고려하고 그것이 타당한지 생각해야 합니다.

마지막까지 기다리지 말고 경제성을 파악하세요.

데빈 라이머

그렇다면 다음 질문은 로컬 모델은 어떤가요?입니다.

비용이라는 큰 문제가 있다면 로컬 모델을 사용하면 이 문제가 해결되지 않을까요?

그리고 실제로 그렇게 되었습니다.

하지만 여기에는 고려해야 할 몇 가지 장단점이 있습니다.

비용 측면에서 보면 서버 비용이 사라지므로 큰 이점이 되고 더 많은 기회가 열립니다.

하지만 현재 로컬에서 어려움을 겪고 있는 많은 문제를 클라우드가 해결할 수 있습니다.

예를 들어 컴퓨팅을 살펴보겠습니다.

사람들은 종종 "이 음성 텍스트 변환 모델은 정말 좋은데, 이 기기에서 로컬로 실행되죠?"라고 말합니다.

좋습니다. 하지만 한 가지 고려해야 할 점은 하나의 모델이 아니라 여러 모델을 실행한다는 것입니다.

이 경우에는 4개이며 동시에 실행될 수 있으므로 한 번 실행되는 것으로는 충분하지 않고 동시에 여러 번 실행되어야 합니다.

그렇게 하고 나면 게임이나 애플리케이션을 실행할 수 있는 여유가 남아 있을까요?

GPU를 최대로 사용하면 비디오 게임을 많이 렌더링할 수 없습니다.

이러한 과제를 해결했다고 가정해 보겠습니다.

다음은 속도입니다.

실행할 수는 있지만 속도가 매우 느리고 실제 실시간 대화라기보다는 프롬프트를 입력하는 것처럼 느껴질 것입니다.

따라서 이론적으로는 로컬에서 가져오는 것이 미래에 이점이 있습니다. 인터넷에서 왕복할 필요가 없기 때문입니다.

실시간으로 이 기능을 구현하기 위해 적절한 속도로 실행되는 모델을 확보하는 것이 과제입니다.

그렇다면 다음으로 컴퓨팅과 속도를 정복했다고 가정해 보겠습니다. 이제 품질에 대해 생각해야겠죠?

일반적으로 로컬 기기에서 실행하기 때문에 더 작은 LLM, 예를 들어 더 원시적인 TTS를 사용하므로 콘텐츠를 빌드할 때 몇 가지 문제가 발생할 수 있습니다.

앞서 언급했듯이 LLM을 고려할 때는 사용자에게 충분히 좋은지뿐만 아니라 개발하기에 충분히 좋은지도 고려해야 합니다.

따라서 해당 모델로 무언가를 빌드하기가 매우 어려워진다면 반드시 고려해야 할 사항입니다.

컴퓨팅, 속도, 품질을 정복했다면 다음은 이식성입니다.

이 모든 과정을 거쳐 RTX 5070에서 실행되는 모델을 얻었다고 가정해 보겠습니다. 이 모델은 RTX 5070에서만 실행될 수 있습니다.

따라서 새로운 플랫폼으로 이전할 기회가 생겨도 이전하지 못할 수 있습니다.

클라우드 측면에서는 인터넷만 있으면 됩니다.

이것이 바로 큰 변화입니다.

여러 플랫폼으로 이동할 수 있습니다.

다음으로 하이브리드 접근 방식에 대해 이야기해 보겠습니다.

따라서 일부는 클라우드에서 실행하고 일부는 로컬에서 실행합니다.

그렇게 할 수 있을까요?

생각만큼 큰 승리는 아니야.

따라서 대부분의 로컬 플랫폼에서 실행할 수 있을 만큼 작은 모델을 얻게 된다면 클라우드에서 동일한 모델을 실행하는 데 드는 비용은 아마도 몇 센트에 불과할 것입니다.

따라서 일반적으로 전체 스택을 해결해야만 가장 큰 성과를 거둘 수 있습니다.

그다음으로 제기되는 문제는 가능하면 로컬에서 실행하는 것이 어떨까 하는 것입니다.

클라우드에는 적절한 하드웨어가 있지만, 사용자에게는 없을 수 있습니다.

클라우드에서 더 강력한 기능을 실행할 수 있습니다.

여기에는 새로운 과제가 있습니다.

결국 다른 모델을 실행하게 되면 개발에 상당한 영향을 미칠 수 있습니다.

결국 최소 사양에 많은 시간을 할애해야 합니다.

그리고 매우 다르게 작동하는 모델이 있을 수 있습니다.

따라서 정확히 동일한 모델을 사용하지 않는 한 개발 시간과 비용이 많이 추가될 수 있습니다.

따라서 달성하려는 목표를 고려하는 것이 중요합니다. 이 문제를 해결하고 로컬이 필요한 경우 로컬을, 그렇지 않은 경우 클라우드를 사용한다고 해도 클라우드 모델의 경제성이 여전히 작동해야 하기 때문입니다.

갑자기 모든 사용자가 클라우드 측에 있다면 경제적 관점에서 이를 고려하지 않은 경우 손실이 발생할 수 있습니다.

따라서 로컬 모델은 경제적으로 큰 이점이 있지만 아직 초기 단계입니다.

게임과 같이 가격에 민감한 애플리케이션의 경우 결국 승리할 가능성이 높다고 생각합니다.

현재는 명령어 기반 작업과 같은 특정 사용 사례를 제외하고는 다소 까다롭습니다.

따라서 지금 당장 가능한 최고의 경험을 원합니다.

이것이 바로 클라우드를 사용하는 이유입니다.

하지만 이 분야는 매우 빠르게 변화하고 있습니다.

다음으로, 사용 중인 모델에 대해 생각해 보겠습니다.

다음 질문은 가중치 공개와 비공개에 관한 것입니다.

여기서 무엇을 해야 할까요?

이와 관련해 LLM에 초점을 맞추고자 합니다. LLM은 개방형과 폐쇄형 질문의 영향을 가장 많이 받는 영역이기 때문입니다.

따라서 여기에는 확실히 장단점이 있습니다.

폐쇄형 가중치 모델은 일반적으로 최첨단 인텔리전스라고 할 수 있습니다.

따라서 가장 많은 인텔리전스가 필요한 경우 이 곳을 이용해야 합니다.

한편, 오픈소스 측면에서는 한 세대 뒤처지는 경우가 많습니다.

따라서 이는 실질적인 장단점이 될 수 있습니다.

속도 측면에서는 첫 문장까지의 시간에 많은 신경을 쓴다고 말씀드렸습니다.

우리가 발견한 것은 폐쇄형 모델의 수명 동안 속도가 느려지는 경우가 많다는 것입니다.

여기에는 여러 가지 이유가 있을 수 있습니다.

모델을 사용하는 사람이 늘어났거나 하드웨어가 최신 모델로 변경되었을 수 있습니다.

하지만 저희가 발견한 한 가지 사실이 있습니다.

따라서 주의해야 합니다. 출시할 때는 훌륭했던 제품이 시간이 지나면서 사용할 수 없게 되는 문제가 발생할 수 있기 때문입니다.

다음은 급증입니다.

이러한 일관성을 중요하게 생각하는 경우가 많습니다. 따라서 비공개 모델은 P99 지연 시간이 아닌 비동기 작업의 일괄 처리를 중심으로 빌드되는 경우가 많습니다. 반면 개방형 모델에서는 사용자가 중요하게 생각하는 특정 사항을 중요하게 생각하는 제공업체를 선택하여 필요한 신뢰도, 속도, 지연 시간을 확보할 수 있습니다.

다음은 모델 자체의 수명입니다.

따라서 폐쇄형 모델은 약 1년 후에 지원이 종료되는 경우가 많습니다.

즉, 1년 동안 무언가를 개발하고 3년 동안 프로덕션에 사용할 것으로 예상한다면 3번 이상의 모델 변경을 거칠 수 있습니다.

또한 모델이 더 우수하다고 해서 내게 더 잘 맞는다는 의미는 아닙니다.

지난 3년 동안 많은 모델 변경이 있었고, 모든 것을 재조정하는 데 몇 주, 때로는 몇 달이 걸리기도 했습니다. 개방형 모델의 경우 누군가 호스팅할 의향이 있거나 직접 호스팅할 의향이 있다면 해당 모델을 계속 실행할 수 있습니다.

마지막은 비용입니다.

시간이 지남에 따라 이러한 비공개 모델은 새 버전을 출시하면서 이전 버전보다 비용이 더 많이 드는 경우가 많습니다.

따라서 경제성 측면에서 주의해야 할 또 다른 사항은 출시 시점에는 경제성이 있었지만 모델을 마이그레이션하면서 경제성이 없어질 수 있다는 점입니다.

개방형 측면에서는 모델을 자유롭게 이동할 수 있으며, 동일한 모델이므로 비용이 급격히 증가하지 않을 가능성이 높습니다.

그래서 Gemma 4 31B를 사용하고 있는데, 이는 속도, 지능, 비용의 최적의 조합이었기 때문에 저희에게는 큰 돌파구가 되었습니다.

또한 매우 빠르게 움직일 수 있었습니다.

이전에 사용했던 것보다 개발하기가 훨씬 쉽습니다.

그렇다고 해서 이 방법만 사용하는 것은 아닙니다.

다양한 개방형 및 폐쇄형 모델을 조합하여 사용합니다.

예를 들어 메모리 생성, 안전, 맞춤설정 등이 있습니다.

작업의 특정 요구사항에 가장 적합한 모델을 선택하는 것이 중요합니다.

하지만 음성 에이전트의 경우 Gemma 4 31B가 핵심적인 역할을 합니다.

따라서 이 두 가지의 차이점을 고려할 때 개방형 모델은 확실히 더 많은 제어 권한을 제공하며, 더 예측 가능한 비용으로 호스팅할 수 있는 한 모델을 유지할 수 있습니다.

모델 지원 중단으로 인해 일정에 영향을 받지 않습니다.

데빈 라이머

정리하자면 이 세 가지의 균형을 맞추는 것이 중요하겠네요.

지연 시간의 경우 스트리밍 측면, 병렬 측면, 속도, 일관성의 균형을 맞추려고 노력하고 있습니다.

지능 측면에서는 사용자가 사용하기에 충분히 스마트하고, 개발에 사용하기에도 충분히 스마트합니다.

비용 측면에서는 사용자당 비용과 사용자당 수익을 파악하여 경제성이 있는지 확인해야 합니다.

먼저 구축한 다음 경제성을 파악하지 마세요.

처음부터 이 점을 염두에 두세요.

아직 초기 단계이지만 수익성이 나타나기 시작했습니다.

따라서 더 저렴한 모델이 더 좋고, 더 지능적인 모델이 더 좋을 것입니다.

하지만 지금 당장, 오늘부터 음성 에이전트를 어디서나 사용할 수 있도록 하기 위해 해결해야 하는 매우 어려운 과제를 해결하기 시작할 수 있습니다.

따라서 이러한 음성 에이전트의 강력한 기능을 모든 사용자에게 제공할 수 있게 되어 매우 기쁩니다.

감사합니다.