왜 가정용 AI 서버가 한 사용자에게는 빠르게 느껴지지만 가족 전체에게는 그렇지 않을까요?

홈 AI 서버는 한 명의 사용자에게는 빠르게 느껴질 수 있지만, 여러 가족이 동시에 요청을 공유할 때는 컴퓨팅, 메모리, 스케줄링 시간이 분산되어 느리게 느껴질 수 있습니다.

차이는 한 사람이 유휴 기간 동안 짧은 채팅 프롬프트를 보내고, 그 후 여러 가족 구성원이 동시에 긴 대화, 문서 요약, 이미지 분석, 음성 작업 또는 에이전트 워크플로를 시작할 때 나타납니다. 단일 사용자 테스트는 주로 워밍업된 모델 지연 시간을 보여주지만, 가족 사용은 대기, 혼합된 프롬프트 길이, 별도의 대화 캐시, 경쟁하는 사전 채우기 및 디코딩 단계, 예측 불가능한 출력 길이를 추가합니다. 아래 섹션에서는 서비스 계층이 이러한 차이를 어떻게 첫 토큰 지연, 불균일한 생성, 높은 메모리 압력으로 전환하는지 설명합니다.

스케줄러는 가족 요청 뒤에 있는 제어 계층입니다

로컬 모델은 하드웨어의 새 복사본에서 독립적으로 모든 사용자에게 응답하지 않습니다. 하나의 서비스 프로세스가 요청을 받고, 각 프롬프트가 모델에 들어갈 시기를 결정하며, 호환 가능한 작업을 그룹화하고, 제한된 가속기 시간과 메모리를 활성 대화에 할당합니다.

최신 시스템은 요청 스케줄링을 사용하여 이질적인 프롬프트를 균형 있게 처리하고 작업을 이전하며 지연 우선순위를 구분합니다. 단일 GPU 또는 공유 시스템 메모리를 가진 홈 서버에서는 해당 스케줄러가 새로운 용량을 생성할 수 없으며, 기존 용량을 어떻게 분배할지 결정할 뿐입니다.

이것이 동일한 네트워크에서도 동일한 모델에 연결된 두 인터페이스가 다르게 느껴질 수 있는 이유입니다. 빈 대기열에 도착한 요청은 빠르게 시작되지만, 동일하게 짧은 요청도 긴 프롬프트, 큰 이미지 또는 다른 사용자의 긴 응답 뒤에서 대기할 수 있습니다.

왜 한 명의 사용자가 서버를 실제보다 빠르게 보이게 할 수 있는가

단일 사용자 테스트는 보통 유리한 조건에서 실행됩니다: 모델이 이미 로드되어 있고, 가속기는 유휴 상태이며, 다른 컨텍스트가 캐시 메모리를 차지하지 않고, 요청이 대기 없이 시작됩니다. 그 결과는 첫 토큰까지의 시간이 짧고 토큰 생성이 안정적이라는 점입니다.

LLM 서비스에는 문서화된 처리량-지연 시간 상충 관계가 있습니다. 배칭은 총 완료 작업량을 향상시킬 수 있지만, 부하가 증가하면 특히 서버가 프롬프트 처리와 진행 중인 생성 작업을 혼합할 때 개별 요청이 경험하는 지연 시간이 늘어날 수 있습니다.

따라서 벤치마크는 “거의 모든 자원이 하나의 요청에 할당될 때 이 모델의 반응성은 어떠한가?”라는 질문에 답합니다. “가족 요청이 동일한 응답 시간 목표를 얼마나 충족할 수 있는가?”라는 질문에는 답하지 않습니다.

유용한 용량 테스트는 사용자를 점진적으로 추가하고 첫 토큰 지연, 토큰 간 시간, 대기 시간, 메모리 사용량, 완료율을 측정해야 하며, 단일 최상의 초당 토큰 수만 보고해서는 안 됩니다.

프리필과 디코드는 서로 다른 방식으로 경쟁합니다.

각 요청은 입력 프롬프트를 처리하고 생성에 필요한 상태를 구축하는 프리필로 시작합니다. 디코드는 그 후 출력 토큰을 한 번에 하나씩 생성합니다. 긴 문서나 대화는 프리필을 계산 집약적으로 만들 수 있으며, 여러 활성 응답은 반복적으로 디코드 단계로 돌아갑니다.

프리필과 디코드 연구는 두 단계를 함께 배치하면 간섭이 발생하고 지연 시간이 연동될 수 있음을 보여줍니다. 가정에서는 한 사람이 긴 문서를 붙여넣으면 이미 응답을 받고 있는 다른 사용자가 지연될 수 있는데, 이는 요청 형태가 다름에도 불구하고 발생합니다.

이 문제는 두 가지 증상으로 나타납니다. 새로운 사용자는 첫 토큰을 기다리는 시간이 길어질 수 있고, 활성 사용자는 이후 토큰 사이에 불규칙한 일시 중지를 경험할 수 있습니다. 평균 처리량은 상호작용 경험이 불안정해져도 여전히 허용 가능한 수준일 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

각 대화는 자체 KV 캐시 용량을 소비합니다.

프리필 후 서버는 이전 토큰을 나타내는 키와 값 텐서를 유지하여 매 출력 토큰마다 전체 대화를 다시 계산하지 않습니다. 대화가 길어지고 동시 사용자가 많아질수록 이 작업 집합이 확장됩니다.

원본 vLLM 연구는 KV 캐시 메모리가 배치 크기와 동시 서비스의 주요 제한 요소임을 확인했습니다. 효율적인 페이징은 낭비를 줄이지만, 모든 활성 컨텍스트는 추론 경로 어딘가에 실제 메모리가 필요합니다.

사용 가능한 GPU 메모리, 공유 RAM 또는 가속기 메모리가 부족해지면 서버는 요청 수를 줄이거나, 작업을 선점하거나, 문맥 제한을 단축하거나, 캐시 상태를 오프로드하거나, 다른 모델을 퇴출할 수 있습니다. 이러한 대처는 원활한 단일 대화를 가족 전체의 지연 시간 급증으로 바꿀 수 있습니다.

관련된 ZimaSpace의 모델 퇴출 설명은 한 가지 심각한 사례를 다룹니다: 활성 작업 부하가 상주 모델을 대체하여 다음 요청이 재로드 및 워밍업 비용을 지불한 후 정상 생성이 재개됩니다.

가족 작업 부하는 단순히 수가 많을 뿐만 아니라 불균형합니다.

두 명의 사용자가 있다고 해서 성능이 정확히 절반으로 줄어드는 것은 아닙니다. 한 명은 짧은 사실 질문을 할 수 있지만, 다른 한 명은 긴 PDF를 제공하거나, 큰 응답을 요청하거나, 이미지 인식을 실행하거나, 반복적으로 모델 호출을 하는 에이전트를 실행할 수 있습니다.

LLM 스케줄러는 입력 및 출력 토큰 비용이 다른 요청의 불균형을 처리해야 합니다. 프롬프트와 출력 길이가 예측 불가능하게 변하기 때문입니다. 제한이나 공정한 스케줄링 없이는 하나의 무거운 세션이 여러 가벼운 채팅보다 훨씬 오랜 시간 동안 대기열, 계산 및 캐시 자원을 점유할 수 있습니다.

아래 표는 사용자 수만으로는 용량 지표가 불완전함을 보여줍니다.

따라서 가족 테스트는 실제 채팅, 검색, 비전, 음성 및 자동화의 혼합을 재현해야 합니다. 다섯 개의 동일한 짧은 프롬프트는 건강해 보일 수 있지만, 하나의 긴 문맥 요청과 두 개의 활성 대화는 실제 한계를 드러냅니다.

가족 반응성을 개선할 수 있는 방법은 무엇일까요?

적합한 모델 하나를 상주시키고, 불필요한 최대 컨텍스트를 줄이며, 긴 출력을 제한하고, 공정한 동시성 또는 대기열 규칙을 할당하는 것부터 시작하세요. 더 작은 모델이 활성 컨텍스트에 거의 메모리를 남기지 않는 더 큰 모델보다 가족에게 더 나은 서비스를 제공할 수 있습니다.

동시 AI 사용자에 대한 ZimaSpace 배포 경계는 더 큰 규모에서 같은 원칙입니다: 모델 가중치, 활성 컨텍스트, 배치 크기, 서비스 전략이 모두 하드웨어에 맞아야 합니다. 저장소는 체크포인트를 보관할 수 있지만, 빠른 대화형 추론은 사용 중 가중치와 활성 상태가 어디에 있는지에 달려 있습니다.

연속 배치, 접두사 재사용, 페이징된 KV 캐시, 요청 우선순위, 별도 작업자 복제본은 활용도나 공정성을 개선할 수 있습니다. 이들의 이점은 조건적입니다: 처리량 중심 설정은 서버가 더 많은 토큰을 완료하게 하면서 한 사용자가 더 오래 기다리게 할 수 있습니다.

하드웨어가 여전히 한계를 정합니다. 가족 작업 부하가 가속기 메모리, 연산 대역폭, CPU 전처리, 또는 사용 가능한 모델 복제본을 소진하면, 스케줄링이 부족분을 더 공정하게 분배할 수는 있지만 제거할 수는 없습니다.

자주 묻는 질문

두 명의 사용자가 항상 홈 AI 서버를 두 배로 느리게 만들까요?

아니요. 결과는 프롬프트 길이, 출력 길이, 배치, 모델 크기, 캐시 사용, 요청 겹침 여부에 따라 달라집니다. 두 개의 짧은 요청은 효율적으로 배치될 수 있지만, 한 개의 긴 요청은 여러 가벼운 세션에 간섭할 수 있습니다.

각 가족 구성원마다 별도의 모델 인스턴스가 필요할까요?

보통 그렇지 않습니다. 하나의 다중 사용자 서비스 프로세스가 모델 가중치를 공유하고 별도의 요청을 스케줄할 수 있습니다. 별도의 인스턴스는 격리를 개선할 수 있지만, 메모리를 복제하거나 분할하여 작은 하드웨어에서 총 용량을 줄일 수 있습니다.

더 빠른 네트워크가 다중 사용자 AI 지연을 해결할까요?

입력 전송, 원격 저장소, 또는 클라이언트 연결이 병목일 때만 그렇습니다. 가족 부하에서 대부분의 로컬 텍스트 생성 지연은 대기열, 연산, 모델 메모리, KV 캐시 압박에서 발생합니다.

가족용으로는 더 작은 모델이 더 좋나요?

그럴 수 있습니다. 더 작은 모델은 동시 컨텍스트에 더 많은 메모리를 남겨두고 더 빠르게 생성할 수 있지만, 품질 저하가 가족의 작업에 맞아야 합니다.