하나의 추론 서버로 로컬 음성 비서를 여러 방에서 사용할 수 있을까요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Can a Local Voice Assistant Work Across Multiple Rooms With One Inference Server?

그렇습니다. 여러 방에서 하나의 로컬 음성 추론 서버를 공유할 수 있습니다. 각 방에는 마이크와 스피커가 있는 위성이 필요하며, 더 많은 연산이 필요한 음성 텍스트 변환, 언어 모델 추론, 텍스트 음성 변환은 홈 서버에서 중앙 집중식으로 실행할 수 있습니다. 웨이크 워드 감지 또는 음성 활동 감지가 마이크 가까이에서 수행될 때 시스템이 가장 효율적으로 확장되므로, 유휴 상태인 방이 서버로 오디오를 계속 스트리밍하지 않게 됩니다.

가장 큰 제약은 방의 수가 아닙니다. 동시에 말하는 사람의 수와 각 파이프라인 단계에 필요한 컴퓨팅 성능이 핵심입니다. 거의 유휴 상태인 위성 6개가 Whisper, LLM, TTS 작업을 겹쳐 생성하는 방 2개보다 처리하기 쉬울 수 있습니다.

다중 방 로컬 음성 아키텍처는 어떤 모습일까요?

주방 위성 ----침실 위성 -----서재 위성 -------> 로컬 음성 서버
거실 위성 --/      |
                              +-- STT
                              +-- 인텐트 / LLM
                              +-- TTS
                              +-- Home Assistant / 도구

위성의 역할은 가볍게 유지할 수 있습니다. 오디오를 캡처하고, 웨이크 워드 또는 음성을 감지하며, 방 식별 정보와 함께 요청에 태그를 추가하고, 반환된 오디오를 재생하며, 선택적으로 로컬 음소거 제어를 처리합니다.

Home Assistant의 최신 Wyoming 통합은 이러한 분리를 잘 보여주는 예입니다. Whisper, Piper, Speech-to-Phrase, openWakeWord와 같은 로컬 음성 텍스트 변환, 텍스트 음성 변환, 웨이크 워드 시스템에 Assist를 연결할 수 있습니다.

로컬 웨이크 워드 감지가 큰 도움이 되는 이유

모든 위성이 서버로 오디오를 24시간 스트리밍하더라도 유선 또는 안정적인 Wi-Fi LAN에서는 네트워크 트래픽을 대체로 감당할 수 있습니다. 하지만 중앙 장치는 여러 오디오 스트림을 계속 검사해야 합니다. 또한 모든 방의 배경 오디오가 중앙 서비스로 전송되므로 개인정보 보호 측면의 노출 범위도 커집니다.

더 나은 설계는 다음과 같습니다.

방 위성
  |
  +-- 로컬 웨이크 워드 / VAD
  |
  +-- 트리거 후에만
          |
          v
      발화 스트리밍
          |
          v
   중앙 추론

Home Assistant의 음성 위성 문서에서는 항상 켜짐 스트리밍, 음성 감지 시 스트리밍, 로컬 웨이크 워드 모드를 설명합니다. 또한 소형 위성 하드웨어가 로컬 웨이크 감지와 오디오 정리를 처리할 수 있으므로 중앙 서버에 동일한 부하를 가하지 않고도 여러 위성을 운영할 수 있다고 설명합니다.

서버 하나가 공유 대화 하나를 의미하는 것은 아닙니다

이는 애플리케이션 계층에서 가장 중요한 규칙입니다. 추론 프로세스는 공유할 수 있지만, 각 방 또는 사용자는 자체 세션 상태를 가져야 합니다.

중앙에서 공유	방 / 세션별로 별도 유지
Whisper 모델 가중치	오디오 버퍼
LLM 모델 가중치	대화 기록
Piper 음성 모델	방 식별 정보
도구 커넥터	사용자 / 권한 컨텍스트
GPU 또는 NPU	응답 대상

이러한 분리가 없으면 “꺼 줘”와 같은 후속 명령이 다른 방의 컨텍스트를 실수로 이어받을 수 있습니다. 서버는 모든 발화에 세션 식별자를 연결하고, 이를 STT, 의도 확인, 도구 실행, TTS 재생 과정 전체에 전달해야 합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

방 컨텍스트로 짧은 명령을 더 효과적으로 만들기

멀티룸 시스템에는 단일 스마트 스피커에는 없는 정보가 있습니다. 마이크가 어디에 있는지 알고 있다는 점입니다.

사용자가 매번 “거실 조명을 꺼 줘”라고 말하도록 강요하는 대신, 위성 장치가 구역 식별자를 제공할 수 있습니다.

음성 명령: "조명을 꺼 줘"
방:   "주방"

확정된 동작:
Home Assistant -> 주방 조명 -> 끄기

이는 짧은 명령에 고가의 범용 LLM이 전혀 필요하지 않은 결정론적 홈 제어에 특히 유용합니다. ZimaSpace의 Home Assistant의 로컬 처리 확대에 관한 글에서는 보다 자유로운 요청에는 더 큰 모델을 사용하면서도 집중형 로컬 파이프라인을 함께 활용할 수 있는 이유를 설명합니다.

가장 먼저 병목이 되는 것은 무엇일까요?

음성은 파이프라인으로 처리되므로, 필요한 단계 중 가장 느린 단계가 체감 지연 시간을 결정합니다.

단계	일반적인 리소스 부담	멀티룸 위험
웨이크 워드 / VAD	위성 장치의 소형 CPU	분산 처리 시 낮음
음성-텍스트 변환	CPU/GPU, 메모리 대역폭	음성이 겹칠 때 높음
의도 / LLM	GPU/CPU + KV 캐시	자유 형식 요청에서는 높음
도구 실행	네트워크 / 서비스 지연 시간	대상에 따라 다름
음성 합성	CPU/GPU	보통
오디오 재생	LAN	일반적으로 낮음

가정용으로는 여러 사람이 동시에 말하는 경우가 드뭅니다. 따라서 모든 방에서 계속 동시에 대화할 수 있을 만큼 컴퓨팅 리소스를 갖추는 대신, 서버가 짧은 작업을 대기열에 넣어 처리하도록 할 수 있습니다.

STT, LLM, TTS를 하나의 GPU에서 공유할 수 있을까요?

가능하지만 메모리와 스케줄링이 중요합니다. 여러 모델을 동시에 로드하면 어느 한 단계에 필요한 양보다 더 많은 VRAM을 사용할 수 있습니다. 소형 서버에서는 서로 다른 장치나 실행 모드를 사용할 수 있습니다.

CPU 또는 iGPU에서 STT 실행;
GPU에서 LLM 실행;
CPU에서 TTS 실행;
또는 짧은 STT/LLM/TTS 작업을 하나의 가속기에서 순차적으로 처리합니다.

두 번째 설계는 하드웨어를 절약하지만, 두 방에서 동시에 말할 때 지연 시간이 늘어날 수 있습니다. 초당 원시 토큰 수만 측정하지 말고 첫 전사까지의 시간과 첫 오디오까지의 시간을 측정하세요.

한 방의 스피커가 다른 마이크를 작동시키지 않도록 하기

멀티룸 음성 시스템에서는 음향 문제가 발생합니다. 어시스턴트 자체의 TTS 음성이 다른 위성 장치에 들려 새로운 요청으로 해석될 수 있습니다.

사용:

모든 소리를 개방형으로 전사하는 대신 로컬 웨이크 워드 사용;
에코 제거 및 소음 억제;
위성 장치가 필요할 때 자체 응답 중 마이크를 억제할 수 있도록 재생 상태;
방별 볼륨;
일상적인 제어에 적합한 짧은 응답 표현

한 스피커가 말할 때마다 집 안의 모든 마이크를 음소거하는 방식으로 피드백 문제를 해결하지 마세요. 그러면 여러 방을 동시에 사용하는 상황이 불필요하게 불안정해집니다.

홈 서버의 대기열 크기는 어떻게 정해야 하나요?

현실적인 동시성부터 시작하세요. 위성 장치가 8개인 4인 가정에서도 동시에 요청이 2개를 넘는 경우는 드물 수 있습니다. 오디오 작업이 제한 없이 쌓이지 않도록 대기열 크기에 상한을 설정하세요.

음성 요청
   |
   +-- 슬롯 사용 가능 -> 지금 실행
   |
   +-- 짧은 대기열 -> "잠시만 기다려 주세요" / 대기
   |
   +-- 대기열 가득 참 -> 명확하게 실패 처리

우선순위 설정도 도움이 됩니다. 결정론적인 조명 제어 명령이 긴 대화형 LLM 응답 뒤에서 대기해서는 안 됩니다. 빠른 홈 제어 의도는 더 작은 파이프라인으로 라우팅하고, 실제로 필요한 질문에만 대형 모델을 사용하세요.

서버가 로컬에 있으면 개인정보 보호가 향상되지만, 권한은 여전히 중요합니다

중앙 집중식 로컬 추론을 사용하면 오디오가 클라우드 서비스로 전송되지 않지만, 이제 모든 위성 장치가 잠금장치, 조명, 미디어, 경보 및 개인 데이터에 접근할 수 있는 권한 시스템에 연결됩니다.

방과 사용자 컨텍스트를 권한 정책과 연결하세요. 게스트룸의 위성 장치는 조명과 온도를 제어할 수 있지만 캘린더나 개인 NAS 파일에는 접근하지 못할 수 있습니다. 어린이 방에는 완전히 다른 도구 세트를 적용할 수도 있습니다.

더 광범위한 오케스트레이션 계층에 대해서는 로컬 AI 도구 신뢰 경계 가이드에서 음성 인식만으로 관리 권한을 부여해서는 안 되는 이유를 설명합니다.

다중 방 음성 배포 체크리스트

모든 위성 장치에 안정적인 방 ID를 할당하세요.
가능한 경우 위성 장치에서 웨이크 워드 또는 VAD를 실행하세요.
방/세션별 대화 상태를 분리해 유지하세요.
일반적인 홈 제어 명령에는 빠르고 결정론적인 경로를 사용하세요.
고비용 STT/LLM 작업은 동시 처리 수를 제한한 대기열에 넣으세요.
여러 사용자가 겹쳐 말할 때의 지연 시간을 측정하세요.
에코 제거 / 피드백 방지를 활성화하세요.
각 방에는 필요한 도구만 제공하세요.
필수적인 홈 제어 명령을 위해 로컬 대체 경로를 유지하세요.

자주 묻는 질문

각 방에 자체 AI 컴퓨터가 필요한가요?

아니요. 위성 장치는 저렴한 마이크/스피커 엔드포인트가 될 수 있습니다. 고비용 모델은 중앙 서버에서 한 번만 실행하면 됩니다.

여러 방에서 동시에 서버와 대화할 수 있나요?

런타임에 충분한 동시 처리 용량이나 짧은 대기열이 있다면 가능합니다. 모델 가중치를 공유하더라도 각 요청에는 별도의 세션 상태와 오디오 상태가 필요합니다.

웨이크 워드 감지는 중앙에서 실행해야 하나요?

가능합니다. 하지만 로컬 웨이크 감지를 사용하면 지속적인 오디오 스트리밍, 중앙 서버 부하, 개인정보 노출을 줄일 수 있습니다. 위성 하드웨어가 이를 지원한다면 일반적으로 여러 방을 운영하기에 더 깔끔한 설계입니다.

최종 판단

하나의 로컬 추론 서버로 집 안 전체의 음성 위성 장치를 지원할 수 있습니다. 엔드포인트는 단순하게 유지하고, 웨이크 감지는 방에 가깝게 배치하며, 고비용 모델은 중앙에서 실행하고, 각 세션을 서로 격리하세요. 스피커 수가 아니라 동시 발화 수를 기준으로 용량을 산정하고, 일반적인 명령은 빠른 로컬 경로로 라우팅하여 한 방에서 긴 LLM 대화가 진행 중이어도 집 안의 다른 공간이 느려지지 않게 하세요.