모델 캐싱은 홈 AI 서버의 응답 시간을 어떻게 바꿀까요?

모델 캐싱은 반복 요청에서 다운로드한 파일, 메모리에 상주하는 가중치, 컴파일된 커널 또는 이전에 처리한 프롬프트 상태를 재사용하도록 하여 응답 시간을 단축합니다.

홈 AI 서버에는 하나의 보편적인 캐시만 존재하지 않습니다. 모델 아티팩트가 이미 로컬 저장 장치에 있을 수 있고, 파일 페이지가 시스템 RAM에 남아 있을 수 있으며, 가중치가 가속기 메모리에 계속 로드되어 있을 수 있습니다. 또한 컴파일된 실행 코드가 재사용되거나, 반복되는 시스템 프롬프트에 유효한 KV 상태가 남아 있을 수도 있습니다. 각 계층은 요청 경로의 서로 다른 부분을 제거합니다. 아래에서는 이러한 계층을 구분하여, 두 번째 응답이 빠르다고 해서 모델 생성 속도나 하드웨어 성능이 향상된 것으로 오해하지 않도록 설명합니다.

모델 캐싱은 여러 독립적인 계층을 의미합니다

가장 먼저 구분해야 할 것은 무엇이 캐시되었는지입니다. 다운로드된 체크포인트는 네트워크 전송을 줄이고, 파일 시스템 페이지 캐시는 저장 장치에서 일부 블록을 다시 읽는 작업을 줄이며, 상주 가중치는 모델 로딩을 생략하게 합니다. 컴파일된 아티팩트는 초기 설정 작업을 줄이고, 프리픽스 캐시는 공유된 프롬프트 토큰을 다시 계산하지 않도록 합니다.

다중 계층 캐싱에 관한 연구에서는 모델 시작을 하나의 이진적인 콜드 또는 웜 상태가 아니라 저장 장치, 호스트 메모리, 가속기 메모리 사이에서 이동하는 과정으로 설명합니다. 요청은 한 계층에서는 웜 상태이면서 다른 계층에서는 콜드 상태일 수 있습니다.

따라서 “모델이 캐시되어 있다”는 말만으로는 충분하지 않습니다. 서버에 파일이 로컬로 존재하더라도 VRAM을 할당하고, 가중치를 로드하며, 커널을 컴파일하고, 토큰을 생성하기 전에 프롬프트를 처리해야 할 수 있습니다.

아티팩트 캐시는 다운로드와 저장소 지연을 제거합니다

모델 파일이 홈 서버에 이미 저장되어 있으면 시작 과정에서 인증, 저장소 메타데이터 확인, 원격 대역폭 사용, 수 기가바이트에 이르는 샤드 다운로드를 생략할 수 있습니다. 런타임은 로컬 사본에서 바로 시작할 수 있습니다.

Netflix는 시작 중 대규모 가중치를 다운로드하면 실용적인 스케줄러 지연 시간을 초과하기 때문에 모델 아티팩트 캐싱이 필요하다고 설명합니다. 컨테이너를 다시 만들거나 정리 후 모델을 실행할 때도 홈 서버에서 같은 메커니즘이 중요합니다.

아티팩트 캐시가 첫 토큰까지의 시간을 반드시 단축하는 것은 아닙니다. 로컬 체크포인트가 느린 디스크에 있을 수 있고, 여러 샤드로 구성되어 있거나 변환이 필요할 수 있으며, NAS 읽기 및 쓰기 작업과 경합할 수도 있습니다.

파일 시스템 캐시는 두 번째 로드를 훨씬 빠르게 만들 수 있습니다

운영 체제가 모델 파일을 읽은 후에는 사용되지 않는 시스템 RAM에 깨끗한 파일 페이지가 남아 있을 수 있습니다. 이후 실행에서는 저장 장치가 다시 응답하기를 기다리는 대신 메모리에서 해당 바이트를 가져올 수 있습니다.

MAIO는 모델 로딩 중 사용되는 파일 시스템 캐시 정책을 최적화하여 LLM 시작 시간을 단축합니다. 이 결과는 동일한 NVMe 경로에서 실행하더라도 어떤 모델 페이지가 캐시된 상태로 남아 있는지에 따라 두 번의 실행 시간이 달라질 수 있음을 보여줍니다.

이 캐시는 회수될 수 있습니다. 백업, 파일 제공, 데이터베이스 또는 다른 모델이 해당 페이지를 대체할 수 있으므로, 어제 빠르게 응답하던 시스템이 메모리 압박이나 재부팅 후에는 다시 저장 장치에 의존하는 상태로 돌아갈 수 있습니다.

페이지 캐시 상태를 정의하지 않은 벤치마킹은 서로 다른 두 저장 장치 환경을 섞어 비교하게 되며, 드라이브 업그레이드 효과를 과대평가할 수 있습니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

상주 가중치는 가장 큰 재로딩 경계를 제거합니다

가중치를 RAM, 통합 메모리 또는 VRAM에 유지하면 런타임이 프롬프트 처리로 바로 넘어갈 수 있습니다. 모델을 언로드하면 다른 앱에 용량을 돌려줄 수 있지만, 다음 요청에서 로딩 경로를 다시 거쳐야 합니다.

ZimaSpace의 모델 상주 가이드는 대표적인 패턴을 보여줍니다. 모델이 축출된 후 한 번 느린 요청이 발생하고, 모델이 웜 상태로 유지되는 동안에는 정상적인 응답이 이어집니다.

상주 상태는 주로 준비 시간과 첫 토큰까지의 시간을 바꿉니다. 생성이 시작된 이후 출력 토큰 생성 속도를 반드시 높이는 것은 아닙니다.

모든 모델을 상주시키면 오히려 메모리 압박이 발생하여 다른 모델, KV 캐시 또는 홈 서버 앱이 축출될 수도 있습니다.

컴파일 및 커널 캐시는 첫 실행 작업을 제거합니다

일부 런타임은 활성 모델, GPU 아키텍처, 텐서 형태 및 런타임 구성에 맞춰 커널을 특수화하거나, 실행 그래프를 캡처하거나, 코드를 컴파일합니다. 호환되는 첫 요청에서는 이후 요청이 재사용할 수 있는 작업이 수행될 수 있습니다.

실용적인 콜드 스타트 분석에서는 런타임 컴파일이 가중치 로딩과 첫 응답 제공 사이에 발생할 수 있다고 설명합니다. 영구 컴파일 캐시는 모델, 드라이버, 런타임 또는 하드웨어 변경으로 무효화되기 전까지 이 비용을 이후 시작 과정에서 제거합니다.

이로 인해 또 다른 웜 상태가 만들어집니다. 파일과 가중치가 이미 준비되어 있더라도 새로운 형태나 실행 경로를 처음 사용할 때 지연 시간이 급증할 수 있습니다.

프리픽스 캐싱은 프리필을 줄이지만 새 토큰 디코딩은 줄이지 않습니다

반복되는 시스템 프롬프트, 긴 문서 프리픽스 또는 공유 지침 블록은 일반적으로 새로운 사용자 입력에 도달하기 전에 같은 토큰을 다시 처리해야 합니다. 프리픽스 캐시는 이전 프리필에서 생성된 재사용 가능한 어텐션 상태를 저장합니다.

Prompt Cache 연구는 요청에서 긴 프롬프트 모듈을 재사용할 때 첫 토큰 지연 시간이 감소한다고 보고합니다. 공유되는 프리픽스가 길수록 생략할 수 있는 프리필 계산이 많아지므로 효과도 커집니다.

프리픽스 캐싱은 임의의 새 프롬프트를 더 빠르게 만들지 않으며, 새 출력 토큰을 디코딩하는 비용도 제거하지 않습니다. 캐시 적중 여부는 정확히 일치하거나 지원되는 프리픽스를 재사용할 수 있는지, 사용 가능한 캐시 용량, 런타임의 축출 정책에 따라 달라집니다.

콜드 경로와 웜 경로를 서로 다른 응답 유형으로 측정하세요

재부팅 직후, 모델 로드 직후, 즉시 반복 요청 시, 장시간 유휴 후, 경쟁 작업이 실행 중일 때 동일한 고정 요청을 테스트하세요. 아티팩트 다운로드, 저장 장치 읽기, 모델 로드, 컴파일, 프롬프트 평가, 첫 토큰, 출력 토큰 속도를 각각 기록합니다.

콜드 캐시 분석에서는 일부 요청이 캐시를 놓칠 때 웜 캐시 지연 시간이 더 느린 꼬리 지연을 숨길 수 있다고 경고합니다. 가정용 어시스턴트는 즉시 반복하는 벤치마크만이 아니라 실제 사용자가 경험하는 요청 구성으로 평가해야 합니다.

캐시 적중이 실패한 계층을 확인하면 해결 방법도 구체화됩니다. 모델 파일을 미리 가져오거나, 페이지 캐시 여유 공간을 확보하거나, 모델 유지 시간을 늘리거나, 컴파일 아티팩트를 영구 저장하거나, 안정적인 공유 프롬프트에 프리픽스 재사용을 활성화할 수 있습니다.

FAQ

캐시된 모델은 항상 RAM을 덜 사용하나요?

아니요. 일부 캐시는 향후 작업을 줄이기 위해 의도적으로 RAM이나 VRAM을 사용합니다. 메모리 사용량을 줄이는 대신 용량과 낮은 지연 시간을 맞바꾸는 방식입니다.

첫 응답은 느린데 이후 응답은 왜 빠른가요?

첫 요청에서는 가중치를 로드하고, 런타임 상태를 할당하며, 커널을 컴파일하거나, 긴 프롬프트를 처리해야 할 수 있습니다. 이후 요청에서는 이러한 결과 중 하나 이상을 재사용합니다.

캐시를 지우면 잘못된 AI 답변을 고칠 수 있나요?

일부 경우 오래되었거나 손상된 런타임 아티팩트를 복구할 수는 있습니다. 그러나 모델 캐시는 일반적으로 변경되지 않은 가중치와 프롬프트의 사실성이나 답변 품질이 아니라 로딩 및 계산 재사용에 영향을 줍니다.