홈 AI 서버에서 하나의 모델을 여러 사용자 세션과 공유할 수 있나요?

에바 왕

IceWhale author

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

Can a Home AI Server Share One Model Across Multiple User Sessions? - Zima Store Online

예. 하나의 홈 AI 서버에서 모델을 한 번만 로드하고 여러 사용자 세션을 제공할 수 있습니다. 최신 추론 서버는 비용이 큰 모델 가중치를 공유하면서 각 대화에 대한 요청 상태는 별도로 유지하도록 설계되었습니다. 이는 가족 구성원마다 동일한 모델을 두 번째 복사본으로 로드하는 것보다 훨씬 메모리 효율적입니다.

주요 확장성 한계는 대개 가중치가 아닙니다. 활성 사용자가 늘어나면서 증가하는 KV 캐시, 컨텍스트 길이, 동시 토큰 생성량, 대기열이 주요 요인입니다. 따라서 다중 사용자 서비스는 모델 크기만큼이나 스케줄링의 문제이기도 합니다.

사용자 간에 실제로 공유되는 것은 무엇인가요?

                 로드된 모델 하나
                 RAM/VRAM의 가중치
                         |
       +-----------------+-----------------+
       |                 |                 |
    세션 A         세션 B         세션 C
   KV 캐시 A        KV 캐시 B        KV 캐시 C
   기록 A         기록 B         기록 C

일반적인 추론 중에는 트랜스포머 가중치가 읽기 전용이므로 여러 요청이 동일한 복사본을 사용할 수 있습니다. 하지만 각 시퀀스에는 자체 토큰 상태와 어텐션 캐시가 필요합니다.

리소스	공유되나요?	이유
모델 가중치	예	동일한 매개변수가 모든 요청에 사용됨
KV 캐시	아니요. 제어된 접두사 재사용을 제외하면	각 시퀀스에 따라 다름
대화 기록	아니요	애플리케이션/사용자 데이터
토크나이저	예	동일한 모델 어휘
GPU 연산	스케줄링됨	요청이 처리량을 공유함
인증	아니요	각 호출자를 식별해야 하나요?

추론 서버는 동시 요청을 어떻게 처리하나요?

런타임마다 제공하는 스케줄링 제어 기능은 다르지만, 원리는 비슷합니다. 여러 시퀀스를 허용하고, 가능한 경우 작업을 배칭하며, 초과 요청은 대기열에 넣습니다.

Ollama의 FAQ에서는 병렬 요청 제어를 설명하며, 병렬 컨텍스트가 메모리 요구량을 늘린다고 안내합니다. llama.cpp의 병렬 예제에서는 하나의 모델 서버를 사용하는 여러 시뮬레이션 클라이언트를 보여 줍니다.

vLLM과 같은 고처리량 서버는 여러 수신 시퀀스에서 가속기를 계속 활용할 수 있도록 배칭과 KV 캐시 인식형 스케줄링을 사용합니다.

컨텍스트 길이가 다른 사용자가 제안한 것보다 더 많은 메모리를 사용할 수 있는 이유

모델 가중치가 VRAM에 여유 있게 들어간다고 가정해 보겠습니다. 네 명의 사용자가 각각 매우 긴 대화를 엽니다. 가중치가 네 배로 늘어나는 것은 아니지만, 활성 시퀀스마다 KV 캐시가 크게 증가할 수 있습니다.

VRAM 예산
  |
  +-- 모델 가중치      고정
  +-- 사용자 A의 KV 캐시    컨텍스트에 따라 증가
  +-- 사용자 B의 KV 캐시    컨텍스트에 따라 증가
  +-- 사용자 C의 KV 캐시    컨텍스트에 따라 증가
  +-- 런타임 오버헤드

이 때문에 “모델이 적재된다”는 사실만으로는 충분한 용량 계획이 되지 않습니다. 다중 사용자 시스템에서는 최대 컨텍스트 길이, 최대 동시 시퀀스 수, 제한된 큐를 설정해야 합니다.

ZimaSpace의 기존 다중 사용자 홈 AI용 가속기 스케줄링 가이드에서는 동일한 리소스 경계를 더 자세히 설명합니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

모든 사용자에게 전용 모델 프로세스를 제공해야 할까요?

대개 그렇지 않습니다. 별도의 프로세스는 가중치를 중복 저장하고 메모리에 적재할 수 있는 모델 수를 줄입니다. 하지만 다음과 같은 경우에는 여전히 적합할 수 있습니다:

사용자마다 다른 파인튜닝 모델 또는 양자화 모델이 필요한 경우;
효율성보다 강력한 프로세스 격리가 더 중요한 경우;
한 워크로드가 사용자 지정 런타임을 사용하는 경우;
사용자별 GPU 할당을 엄격하게 적용하려는 경우;
한 모델이 서로 호환되지 않는 컨텍스트 또는 샘플링 요구 사항을 가집니다.

동일한 모델을 사용하는 가족이나 소규모 팀의 경우, 인증된 애플리케이션 뒤에 하나의 추론 서비스를 두는 편이 일반적으로 더 간단합니다.

대화 메모리는 모델 서버 외부에 유지하세요

추론 서버는 “누가 무엇을 말했는지”에 대한 권위 있는 데이터베이스가 되어서는 안 됩니다. 명시적인 사용자/세션 ID를 기준으로 애플리케이션 계층에 채팅 기록과 사용자 환경설정을 저장하세요.

브라우저 / 앱
    |
    | 인증된 user_id
    v
채팅 애플리케이션
    |
    +-- 기록 DB(사용자별)
    +-- RAG 권한
    |
    v
공유 모델 서버

모든 생성 전에 애플리케이션은 현재 사용자가 볼 수 있는 대화 기록과 비공개 검색 컨텍스트만 조합합니다.

이는 특히 NAS의 비공개 AI 어시스턴트에서 중요합니다. 동일한 서버에 여러 가구 구성원에게 속한 개인 문서가 저장되어 있을 수 있기 때문입니다.

공유 접두사 캐싱은 공유 대화 메모리가 아닙니다

일부 런타임은 공통 프롬프트 접두사에 대한 KV 캐시 또는 기타 작업을 재사용할 수 있습니다. 따라서 공유 시스템 지침이나 반복되는 문서 접두사를 한 번만 계산하고 효율적으로 재사용할 수 있습니다.

이 최적화를 한 사용자의 비공개 컨텍스트가 다른 사용자의 프롬프트에 들어가도록 허용하는 것과 혼동해서는 안 됩니다. 캐시 시스템에는 올바른 격리 및 해싱 의미 체계가 필요하며, 어떤 콘텐츠를 요청에 제공할 수 있는지는 여전히 애플리케이션 권한이 결정합니다.

공정한 스케줄링을 사용하여 한 사용자가 서버를 독점하지 못하게 하세요

매우 긴 출력을 요청하는 단일 요청이 디코딩 용량을 소모하는 동안 다른 사용자는 대기할 수 있습니다. 다음과 같은 승인 제어를 추가하세요:

사용자별 동시 요청 제한;
최대 출력 토큰 수;
최대 컨텍스트 창;
활성 시퀀스의 전역 최대 개수;
큐 시간 초과;
짧은 대화형 요청에 우선순위 부여;
백그라운드 작업을 위한 별도의 배치 큐.

대화형 채팅과 야간 문서 요약이 동일한 스케줄링 정책으로 서로 경쟁해서는 안 됩니다.

서버 메모리가 부족해지면 어떻게 되나요?

좋은 서비스는 가속기가 충돌하기 전에 새 작업을 거부하거나 대기열에 넣습니다. 용량 제어는 낙관적인 평균값만이 아니라 실제로 설정된 컨텍스트를 기준으로 해야 합니다.

부하	더 안전한 대응
모든 시퀀스 슬롯이 사용 중	잠시 대기열에 넣으세요
대기 시간이 너무 김	사용 중 또는 재시도 신호를 반환하세요
컨텍스트가 정책을 초과함	요약하거나 거부하세요
백그라운드 배치 작업 활성화	일시 중지하거나 우선순위를 낮추세요
메모리가 한계에 가까움	OOM이 발생하기 전에 동시 실행 수를 줄이세요

서버 충돌을 막기 위해 모든 사용자의 컨텍스트 창을 조용히 줄이지 마세요. 사용자가 시스템에 저장될 수 있는 정보를 알 수 있도록 컨텍스트 정책을 명확히 공개하세요.

다중 사용자 모드에서는 개인정보 보호와 인증이 더 중요합니다

하나의 모델을 한 명의 관리자만 사용한다면 localhost 전용 엔드포인트로 충분할 수 있습니다. 여러 사람이 사용하기 시작하면 애플리케이션은 사용자를 인증하고 사용자의 데이터 소스에 대한 접근 권한을 확인해야 합니다.

다음을 보호하세요.

채팅 기록;
RAG 컬렉션과 문서 ACL;
저장된 프롬프트;
도구 인증 정보;
생성된 파일;
로그와 트레이스.

공유 모델 프로세스에는 현재 요청에 필요한 컨텍스트만 전달되어야 하며, NAS의 일반적인 권한 모델을 우회하는 편리한 수단이 되어서는 안 됩니다.

홈 AI 서버 하나가 지원할 수 있는 사용자는 몇 명인가요?

유용한 고정 수치는 없습니다. 활성 사용자가 한두 명뿐이라면 등록된 사용자가 많아도 서버가 지원할 수 있지만, 긴 컨텍스트를 사용하는 동시 사용자 두 명만으로도 소형 GPU의 용량이 소진될 수 있습니다.

다음 세 가지 상황을 벤치마크하세요.

대화형 사용자 한 명;
예상되는 동시 가정 내 사용량;
헤비 사용자 한 명과 짧은 요청 여러 개.

첫 토큰까지의 시간, 사용자별 초당 토큰 수, 대기 시간, KV 캐시 사용률, RAM/VRAM 사용량, 요청 실패율을 측정하세요.

FAQ

모델을 공유하면 사용자들이 서로의 대화를 보게 되나요?

애플리케이션이 대화 기록과 검색 컨텍스트를 분리해 유지한다면 그렇지 않습니다. 모델 가중치를 공유한다고 해서 채팅 기록까지 자동으로 공유되는 것은 아닙니다.

병렬 추론을 사용하면 각 사용자의 응답이 더 빨라지나요?

총 처리량은 늘릴 수 있지만, 여러 시퀀스가 활성화되면 각 개별 요청에 할당되는 연산량은 줄어들 수 있습니다. 일반적으로 목표는 전체 서비스 성능을 높이고 대기 시간을 줄이는 것입니다.

서버 하나에서 여러 모델도 호스팅할 수 있나요?

메모리가 허용한다면 가능합니다. 일부 런타임은 필요할 때 모델을 로드하고 언로드하는 반면, 다른 런타임은 하나 또는 여러 개의 상시 실행 서빙 프로세스를 중심으로 설계됩니다. 다중 모델 스케줄링은 다중 사용자 스케줄링에 더해 또 하나의 용량 계층을 추가합니다.

최종 결론

로드된 모델 하나는 일반적으로 소규모 홈 AI 서비스가 공유해야 할 바로 그 리소스입니다. 모델 가중치는 공통으로 유지하고, 세션 기록과 KV 상태는 분리하며, 모든 사용자를 인증하고, 컨텍스트와 동시 실행 수에 제한을 두고, 백그라운드 작업은 대화형 채팅과 별도로 예약하세요. 모델 프로세스를 늘리는 대신 세션별 상태와 대기열 동작을 고려해 설계하면 다중 사용자 AI를 안정적으로 운영할 수 있습니다.