로컬 AI 서비스가 모델을 전환한 후 첫 토큰 지연 시간이 급증하는 원인은 무엇인가?

에바 왕

IceWhale author

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

What Causes First-Token Latency Spikes After a Local AI Service Switches Models?

모델 전환 후 첫 토큰 지연 시간은 일반적으로 급증합니다. 새로 선택한 모델이 프롬프트를 처리하기 전에 상주 상태를 다시 구축해야 하기 때문입니다.

홈 AI 서버는 하나의 워밍 상태 모델로 빠르게 응답하다가 비전 또는 코딩 모델로 전환한 뒤 첫 토큰 전에 일시 중지될 수 있습니다. 이 지연에는 가중치 읽기, 역양자화, 장치 전송, 커널 컴파일, CUDA 그래프 캡처, 캐시 할당, 프롬프트 프리필이 포함될 수 있습니다. 어떤 단계가 지배적인지는 스토리지, 사용 가능한 가속기 메모리, 런타임 정책, 이전 모델이 완전히 제거되었는지 여부에 따라 달라집니다.

콜드 가중치 로딩은 첫 번째 원인군입니다

다음 모델이 RAM 또는 VRAM에 없다면 서버는 하나 이상의 체크포인트 샤드를 읽고, 이를 검증하거나 매핑하고, 텐서를 구성한 다음, 실행 장치로 사용할 수 있는 가중치를 전송해야 합니다. 파일이 크거나 NAS 경로가 느리면 추론을 시작하기 전 일시 중지 시간이 길어집니다.

LLM 콜드 스타트 지연 시간 측정 결과에 따르면 모델 상태가 콜드 상태일 때 시작 시간이 TTFT를 지배할 수 있습니다. 이 증상은 프롬프트 프리필 커널이 실행되기 전에 스토리지 읽기와 모델 로더 시간이 크게 발생하는 형태로 나타납니다. 이러한 구분은 이후 가정 환경 테스트에서도 확인할 수 있습니다.

두 모델이 모두 상주한 상태에서 전환할 때도 동일한 급증이 발생한다면 가중치 로딩만으로는 완전히 설명할 수 없습니다. 구분 기준은 느린 요청과 함께 읽은 바이트 수 및 상주 모델 상태가 변하는지 여부입니다.

런타임 초기화는 두 번째 콜드 경로를 만듭니다

로드된 모델도 운영 측면에서는 여전히 콜드 상태일 수 있습니다. 런타임은 활성화 후 첫 요청에서 장치 컨텍스트를 초기화하고, 커널을 선택하고, 셰이프를 컴파일하고, 그래프를 캡처하고, KV 블록을 할당하거나, 토크나이저 및 프롬프트 템플릿 캐시를 구축할 수 있습니다.

모델 스트리밍 및 워밍업에 관한 엔지니어링 분석은 스토리지 스트리밍과 초기화 및 워밍업을 구분합니다. 이 단계의 특징은 체크포인트 I/O가 적당한 수준으로 발생한 뒤 프롬프트 처리 전에 컴파일, 할당 또는 가속기 활동이 이어지는 것입니다. 자동화를 진행하기 전에 중간 결과를 계속 확인할 수 있어야 합니다.

모델 셰이프, 양자화 백엔드, 컨텍스트 제한, 배치 프로필, 드라이버 상태에 따라 재사용할 수 있는 아티팩트가 결정됩니다. 캐시가 유지되면 빠르게 다시 전환할 수 있지만, 메모리 압박으로 모델이 제거되면 같은 경로가 다시 콜드 상태가 됩니다.

대기열과 프리필은 모델 로드 지연처럼 보일 수 있습니다

전환 요청은 모델 종료, 메모리 회수, 다른 사용자 또는 긴 프롬프트 뒤에서 대기할 수 있습니다. 요청이 처리되기 시작하면 디코드 전에 모든 입력 토큰을 프리필하므로, 모델 로딩 시간이 변하지 않아도 긴 대화 기록으로 인해 TTFT가 증가합니다. 이 경계는 실제 운영 조건에서 별도로 측정해야 합니다.

페이지드 KV 캐시 승인 서빙 설계는 활성 시퀀스가 페이지드 KV 블록을 사용하며, 승인 여부가 사용 가능한 캐시 용량에 따라 달라지는 방식을 설명합니다. 따라서 캐시 예약을 변경하는 전환은 체크포인트 크기와 무관하게 대기 시간에 영향을 줄 수 있습니다.

초기화가 안정적이고 모델이 상주한 상태에서 프롬프트 길이 또는 동시성에 따라 지연 시간이 급증한다면 이것이 실패 경계입니다. 이 경우 모델 전환은 단지 상관관계가 있을 뿐이며, 직접적인 원인은 프리필 또는 스케줄링입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

TTFT를 로드, 워밍업, 대기열, 프리필로 분리하세요

고정된 프롬프트를 반복 실행하면서 모델 제거, 체크포인트 바이트 수, 스토리지 처리량, 호스트-장치 전송, 장치 컨텍스트 생성, 커널 컴파일, 그래프 캡처, KV 할당, 대기열 대기 시간, 프리필 시간, 첫 디코드 단계를 하나의 단조 시계로 기록하세요. 여러 원인이 제한된 컨텍스트를 두고 경쟁할 때 실질적인 결과가 나타납니다.

메모리 기반 모델 라우팅과 추적 결과를 비교한 다음, 콜드 전환, 즉시 재전환, 상주 듀얼 모델 라우팅, 짧은 프롬프트, 긴 프롬프트를 각각 테스트하세요. 의도한 상태만 변경되도록 샘플링, 클라이언트, 동시성을 동일하게 유지하세요. 이 종속성은 최종 인터페이스에 명시적으로 남겨야 합니다.

가장 먼저 증가하는 단계에 지연 급증의 원인을 할당하세요. 로딩이 지배적이면 가중치를 상주시키고, 초기화가 지배적이면 호환되는 아티팩트를 유지하며, 전환 자체가 아니라 대기열 또는 프리필이 TTFT를 결정한다면 승인 또는 컨텍스트 정책을 변경하세요.