서버가 한동안 유휴 상태로 있으면 로컬 LLM의 첫 토큰 지연 시간이 증가하는 이유는 무엇인가요?

첫 토큰 지연 시간은 유휴 상태 이후에 증가하는 경우가 많습니다. 다음 요청이 이미 실행 중인 요청에서 재사용하는 모델, 메모리, 가속기 및 전원 상태를 다시 구성해야 하기 때문입니다.

홈 AI 서버는 반복되는 프롬프트에는 빠르게 응답하다가도 다음 날 아침 첫 요청에는 느리게 느껴질 수 있습니다. 모델이 디스크에 여전히 존재하더라도 해당 모델의 페이지, GPU 할당, 커널 및 실행 컨텍스트가 더 이상 웜 상태가 아닐 수 있습니다. 스토리지 속도, 메모리 압박, 런타임 축출, 디바이스 전원 관리 및 프롬프트 길이에 따라 지연 시간이 얼마나 다시 발생할지가 결정됩니다.

유휴 시간은 여러 종류의 웜 상태를 제거합니다

웜 요청은 RAM 또는 VRAM에 이미 상주하는 가중치, 운영 체제가 유지하는 파일 시스템 페이지, 초기화된 가속기 라이브러리, 컴파일된 커널, 메모리 풀 및 활성 모델 워커를 재사용할 수 있습니다. 유휴 정리는 한 계층만 제거할 수도 있고 전체 프로세스를 종료할 수도 있습니다.

다중 계층 체크포인트 로딩은 체크포인트를 가속기 가까이에 유지하고, 여러 스토리지 계층을 통해 로드하며, 모델 상태가 이미 로컬에 있는 위치로 요청을 예약해 서버리스 모델 시작 시간을 줄입니다. 이 설계는 콜드 지연 시간이 단일 디스크 읽기 수치가 아니라 전송과 초기화 단계가 이어지는 과정임을 보여줍니다.

실제로 관찰되는 지연 시간은 어느 계층이 콜드 상태가 되었는지에 따라 달라집니다. 계속 실행 중인 프로세스라면 디바이스 클록 상승만 필요할 수 있지만, 축출된 모델은 가중치를 읽고, 디바이스 메모리를 할당하고, 런타임 구조를 다시 구축한 다음 프롬프트를 처리해야 토큰을 출력할 수 있습니다.

모델 로딩과 프리필은 토큰이 나타나기 전에 누적됩니다

첫 토큰까지의 시간에는 대기열 처리, 가중치 가용성, 런타임 초기화, 토큰화 및 전체 입력에 대한 프리필이 포함됩니다. 프리필이 첫 디코딩 상태를 생성하기 전에는 출력 토큰이 존재하지 않으므로, 빠른 디코딩 속도만으로는 이러한 단계를 숨길 수 없습니다.

GPU 메모리 재사용은 사용하지 않는 GPU 메모리에 파라미터를 유지하고 선호도 기반 스케줄링을 사용해 반복되는 전송을 줄입니다. 보고된 콜드 시작 개선 결과는 서비스가 모든 모델을 완전히 로드된 상태로 유지할 수 없더라도 부분적인 상주 상태를 보존하는 것이 중요한 이유를 보여줍니다.

따라서 가중치가 웜 상태인 후에도 긴 시스템 프롬프트는 느릴 수 있고, 짧은 프롬프트라도 콜드 모델 로딩 때문에 지연될 수 있습니다. 로딩 시간, 초기화, 프리필 및 첫 디코딩을 분리하면 평균 TTFT 하나의 값이 실제 콜드 구성 요소를 가리는 일을 방지할 수 있습니다.

전원 절약은 대체로 더 작지만 측정 가능한 계층입니다

CPU, GPU, NVMe 디바이스 및 PCIe 링크는 비활성 상태에서 저전력 상태로 전환될 수 있습니다. 첫 번째 버스트에서는 클록을 높이고 활성 경로를 복원해야 하므로 지속적인 연산이 시작되기 전에 짧은 상승 시간이 추가됩니다. 호스트 절전이 적극적으로 적용되면 서비스를 일시 중단하거나 디스크를 중지하기 때문에 훨씬 더 긴 지연이 발생할 수 있습니다.

콜드 시작 단계 중첩은 엣지 LLM 콜드 시작에서 모델 로딩, 통신 및 연산을 중첩합니다. 이 연구는 특히 가중치와 연산이 제한된 디바이스에 분산되어 있을 때, 한 시작 단계를 숨기려면 다른 단계와의 조율이 필요하다는 점을 보여줍니다.

모든 느린 첫 응답의 원인을 전원 상태 탓으로 돌리는 것이 문제의 경계입니다. 지연 시간이 수초 단위로 측정된다면 밀리초 규모의 클록 전환보다 모델 축출, 스토리지 읽기, 컨테이너 시작 또는 프롬프트 프리필이 대개 더 큰 영향을 줍니다. 기본적으로 모든 에너지 절약 기능을 비활성화하기보다 타임라인을 진단하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

콜드 시작 비용과 콜드 프롬프트 비용을 분리하세요

0분, 1분, 10분, 60분 및 480분 동안 유휴 상태로 둔 후 동일한 짧은 프롬프트 하나를 보냅니다. 각 간격마다 프로세스 유지 시간, 모델 상주 상태, RAM 및 VRAM 사용량, 읽은 바이트 수, 디바이스 클록, 대기열 시간, 토큰화, 프리필, 첫 디코딩 및 전체 TTFT를 기록합니다.

모델 콜드 시작 스토리지를 사용해 스토리지 계층을 비교한 다음, 워커를 고정하고, 파일 시스템 캐시만 웜 상태로 만들고, 호스트 RAM만 웜 상태로 유지하며, 프롬프트 길이를 변경하면서 다시 테스트합니다. 각 실행에서는 모든 최적화를 한꺼번에 적용하지 말고 하나의 상태 계층만 변경해야 합니다.

다른 서비스의 리소스를 고갈시키지 않으면서 반복되는 유휴 간격 후에도 필요한 TTFT가 유지될 때만 서버를 웜 상태로 간주하세요. 모델을 고정해 메모리 압박이 발생하거나 우선순위가 더 높은 워크로드가 차단된다면, 트레이드오프를 숨기기보다 제한된 콜드 시작을 받아들이고 이를 사용자에게 드러내세요.