임베딩 작업이 대화형 홈 AI 채팅을 느리게 만드는 이유

임베딩 작업은 긴 백그라운드 배치가 채팅과 액셀러레이터 시간, CPU 전처리, 메모리, 스토리지 액세스를 두고 경쟁하기 때문에 대화형 홈 AI 채팅을 느리게 만들 수 있습니다.

개인 지식 베이스는 수천 개의 문서를 청크로 나누고, 토큰화하고, 임베딩 모델을 실행하고, 벡터를 정규화한 뒤, 인덱스를 몇 분에서 몇 시간 동안 기록할 수 있습니다. 채팅 요청은 예측하기 어렵게 도착하며 첫 토큰까지 걸리는 시간이 짧아야 하는 반면, 임베딩 파이프라인은 처리량을 극대화하는 대규모 배치를 선호합니다. 두 작업이 하나의 GPU, CPU, RAM 풀 또는 NVMe 장치를 공유하면 사용자의 프롬프트가 모델에 도달하기 전에 백그라운드 작업이 대기열을 점유할 수 있습니다. 아래 섹션에서는 각 경합 지점을 살펴보고 대화형 응답을 보호하는 방법을 설명합니다.

임베딩 파이프라인은 긴 배치 작업입니다

문서 수집은 단 한 번의 모델 호출보다 훨씬 많은 작업을 수행합니다. 파일을 열거하고, 텍스트를 추출하고, 콘텐츠를 청크로 나누고, 배치를 토큰화하고, 벡터를 계산하며, 메타데이터와 인덱스 구조를 저장합니다.

대규모 배치는 배치 처리량을 높이지만, 지연 시간에 민감한 요청이 액셀러레이터 시간을 할당받기까지의 간격을 늘릴 수 있습니다.

따라서 초기 라이브러리 가져오기나 전체 재인덱싱은 저장 후 새 메모 하나를 임베딩하는 작업과는 전혀 다릅니다.

채팅 프리필과 임베딩 계산은 동일한 액셀러레이터를 두고 경쟁합니다

대화형 채팅은 계산 집약적인 프롬프트 프리필로 시작합니다. 임베딩 모델 역시 대규모 병렬 배치로 전체 토큰 시퀀스를 트랜스포머 계층에 통과시켜 처리합니다.

프리필 간섭에 관한 연구는 프롬프트와 유사한 무거운 계산이 동시 디코드와 첫 토큰 처리 속도를 떨어뜨릴 수 있는 이유를 보여줍니다.

런타임이 채팅에 선점이나 우선순위를 적용하지 않으면, 채팅 모델 자체가 이미 로드되어 있더라도 짧은 질문이 현재 실행 중인 임베딩 배치 뒤에서 대기할 수 있습니다.

임베딩 배치를 줄이면 가장 긴 차단 구간은 짧아지지만 전체 수집 처리량이 낮아질 수 있습니다.

모델을 분리하면 메모리 압박이 커집니다

채팅 모델, 임베딩 모델, 재순위화 모델, 벡터 런타임은 각각 가중치와 메모리 할당자 풀을 상주 상태로 유지할 수 있습니다. 이들의 총 메모리 사용량이 늘어나면 채팅 KV 캐시와 동시 사용자에 사용할 공간이 줄어듭니다.

ZimaSpace의 액셀러레이터 메모리 경합 관련 글에서는 연산 사용률이 낮다고 해서 대화형 요청에 충분한 메모리가 남아 있다는 의미는 아닌 이유를 설명합니다.

메모리가 부족해지면 시스템은 채팅 동시성을 줄이거나, 모델을 축출하거나, 계층을 오프로딩하거나, 임베딩 단계가 끝난 뒤 콜드 리로드를 실행할 수 있습니다.

일부 아키텍처에서는 검색과 채팅에 하나의 공유 인코더를 사용할 수 있지만, 작업별 모델을 분리하면 결과가 더 좋아지고 메모리 비용도 분리되는 경우가 많습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

추론 전에 CPU와 스토리지 작업이 검색을 지연시킬 수 있습니다

토큰화, PDF 파싱, OCR, 해싱, 벡터 데이터베이스 쓰기 작업은 CPU 스레드를 포화시키고, 모델 파일과 채팅 기록이 저장된 동일한 스토리지에서 무작위 I/O를 발생시킬 수 있습니다.

백그라운드 인덱싱은 사용자에게 표시되는 CPU 그래프가 완전히 포화된 것처럼 보이지 않더라도 인덱싱 경합을 일으킵니다.

그러면 프롬프트가 구성되기 전에 채팅 검색이 데이터베이스 잠금, 캐시 미스 또는 사용 중인 NVMe 대기열을 기다릴 수 있습니다.

우선순위 및 승인 규칙으로 채팅을 보호할 수 있습니다

수집 작업을 제한된 배치로 예약하고, 배치 사이에 일시 중지 시간을 두며, 동시성을 제한하고, 대화형 대기열이 비어 있거나 특정 임계값 아래에 있을 때만 새로운 백그라운드 작업을 허용하세요.

Llumnix는 서로 다른 지연 시간과 리소스 요구 사항을 가진 요청을 처리하기 위해 동적 우선순위를 사용합니다.

홈 서버에서는 더 간단한 정책을 구현할 수 있습니다. 채팅과 음성 요청은 즉시 허용하고, 임베딩은 낮은 우선순위로 실행하거나 유지 관리 시간대에만 실행하는 방식입니다.

추측하지 말고 간섭을 측정하세요

임베딩 작업을 끈 상태와 켠 상태에서 채팅의 첫 토큰까지 걸리는 시간, 토큰 간 지연 시간, 검색 지연 시간, 초당 임베딩 청크 수, GPU 메모리, CPU 포화도, 스토리지 지연 시간을 기록하세요.

채팅이 배치 경계에서만 대기한다면 배치 크기를 줄이거나 선점을 활성화하세요. 모델 리로드가 나타난다면 상주 모델 수를 줄이거나 워커를 분리하세요. 검색이 정체된다면 인덱스 쓰기 또는 모델 파일을 다른 I/O 경로로 이동하세요.

중요한 목표는 가능한 가장 빠른 재인덱싱이 아닙니다. 가정 내 대화형 지연 시간이 평소 범위 안에 유지되도록 하면서 달성할 수 있는 가장 높은 백그라운드 수집 속도입니다.

라이브러리를 구축한 후에는 반복적인 전체 스캔 대신 증분 변경 감지로 전환하여 백그라운드 작업량이 새 콘텐츠에 비례하도록 유지하세요.

FAQ

별도의 임베딩 모델을 사용하면 항상 채팅이 느려지나요?

아니요. 별도의 임베딩 모델은 유휴 상태로 남아 있거나 다른 장치에서 실행될 수 있습니다. 컴퓨팅, 메모리, CPU, 스토리지 또는 스케줄링 경로가 겹칠 때 속도 저하가 발생합니다.

임베딩 배치 크기를 줄이면 항상 도움이 되나요?

개별 차단 구간은 짧아지지만 오버헤드와 전체 수집 시간이 늘어날 수 있습니다. 우선순위와 선점을 사용하면 처리량을 더 많이 유지할 수 있습니다.

임베딩은 밤새 실행해야 하나요?

대규모 가져오기는 밤새 실행하는 것이 좋을 때가 많습니다. 증분 업데이트는 작업량을 제한하고 대화형 요청에 양보하도록 설정하면 낮에도 실행할 수 있습니다.