Read-Ahead가 모델 로딩 시간과 공유 스토리지 트래픽에 미치는 영향

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

미리 읽기는 이후 페이지를 프리페치하여 순차적인 모델 로딩 시간을 줄일 수 있지만, 윈도우가 지나치게 크면 캐시와 공유 스토리지 대역폭을 낭비할 수 있습니다.

여러 홈 AI 워커가 NAS에서 동일한 수 기가바이트 크기의 모델을 열면, 누락된 각 페이지를 요구할 때마다 요청 읽기가 지연될 수 있습니다. 프리페치를 사용하면 이후 페이지를 준비해 둘 수 있지만, 각 클라이언트가 사용하지 않을 데이터를 요청하거나 다른 클라이언트의 트래픽과 중복되는 요청을 보낼 수도 있습니다. 결과는 접근 순서, 메모리 매핑, 페이지 캐시 재사용, 모델 샤딩, 동시성, 스토리지 지연 시간, 캐싱이 수행되는 위치에 따라 달라집니다.

미리 읽기는 순차 요청을 더 이른 I/O로 전환합니다

유용한 캐시 상태가 없으면 로더는 페이지에 도달한 뒤 스토리지가 해당 페이지를 반환할 때까지 기다립니다. 미리 읽기는 순차 접근을 인식하고 프로세스가 요구하기 전에 이후 페이지에 대한 요청을 보냅니다. 예측과 타이밍이 맞으면 스토리지가 다음 영역을 채우는 동안 연산은 현재 영역을 처리할 수 있습니다.

Linux 페이지 캐시는 미리 읽기를 적용하며, 관찰된 접근 패턴에 따라 윈도우를 늘리거나 줄입니다. 이후 페이지가 로더가 도달하기 전에 이미 상주할 수 있으므로 버퍼링된 순차 읽기에 도움이 됩니다.

스토리지 지연 시간이 그렇지 않으면 작업 중단을 일으키고 모델이 예측 가능한 순서로 읽힐 때 가장 큰 효과를 얻을 수 있습니다. 파일이 이미 캐시되어 있거나, 직접 I/O가 페이지 캐시를 우회하거나, 로더가 모든 데이터를 명시적으로 미리 로드하거나, 런타임이 매핑된 페이지를 불규칙한 패턴으로 접근하면 효과는 작아집니다.

메모리 매핑에서는 페이지 폴트 순서가 로딩의 일부가 됩니다

메모리 매핑을 사용하면 모든 가중치 페이지가 상주하기 전에 런타임이 주소 매핑을 생성하므로 모델 시작이 빠르게 보일 수 있습니다. 실제 물리적 I/O는 페이지에 접근할 때 발생합니다. 따라서 겉으로 보이는 로딩 시간은 벤치마크가 매핑 이후에 멈추는지, 아니면 추론 과정에서 작업 세트에 페이지 폴트가 발생할 때까지 계속되는지에 따라 달라집니다.

메모리 매핑된 모델 가중치는 누락된 페이지에서 폴트가 발생할 때 스토리지 지연을 일으킬 수 있으며, 불규칙한 접근은 많은 소규모 읽기를 발생시킬 수 있습니다. 페이지 접근 순서가 예측할 수 있을 만큼 충분히 순차적이면 미리 읽기가 도움이 되지만, 그렇지 않으면 잘못된 영역을 가져올 수 있습니다.

모델 객체 생성까지 걸리는 시간과 첫 번째 토큰이 완전히 생성될 때까지 걸리는 시간을 모두 측정하세요. I/O를 시작 시점에서 첫 번째 요청으로 옮긴 변경은 로딩 작업을 제거한 것이 아닙니다. 페이지 재사용이 결과에 큰 영향을 줄 수 있으므로 웜 캐시 테스트와 콜드 캐시 테스트를 분리해야 합니다.

지나치게 큰 윈도우는 캐시를 오염시키고 공유 대역폭을 소모합니다

프리페치 윈도우가 로더의 가까운 미래 작업 세트를 넘어가면, 사용하기 전에 축출될 수 있는 페이지까지 전송하게 됩니다. 이러한 페이지는 클라이언트 메모리를 차지하고 다른 캐시 항목을 밀어내며 NAS 링크와 스토리지 백엔드의 대역폭을 소모합니다. 로더가 서로 다른 모델을 동시에 시작하면 낭비가 더욱 뚜렷해집니다.

지나친 미리 읽기는 쓸모없는 데이터로 캐시를 오염시킬 수 있고, 너무 적은 미리 읽기는 이후 요청 읽기를 발생시킵니다. 두 경우 모두 성능이 저하됩니다. 순차 로딩, 희소 전문가 접근, 혼합 스토리지 트래픽에 동시에 최적인 고정 기본값은 존재하지 않습니다.

공유 스토리지는 각 클라이언트가 다른 클라이언트가 무엇을 가져오는지 반드시 알지 못한 채 로컬 예측을 수행하므로 실수를 확대합니다. 서버 측 캐시가 이러한 읽기를 병합하지 못하면, 동기화된 시작 시점의 공격적인 프리페치가 트래픽 폭주로 이어져 모든 로더와 관련 없는 NAS 작업까지 지연시킬 수 있습니다.

-15% OFF

캐시 위치에 따라 로더가 이점을 공유할 수 있는지가 결정됩니다

클라이언트 페이지 캐시는 해당 컴퓨터의 프로세스에 이점을 제공하고, NAS 캐시는 여러 클라이언트에 이점을 줄 수 있지만 여전히 네트워크 전송이 필요합니다. GPU 메모리는 또 다른 별도의 저장 위치입니다. 따라서 동일한 모델 데이터가 서버, 클라이언트 RAM, 가속기에 각각 캐시될 수 있으며, 한 계층의 캐시가 다른 계층의 데이터 이동까지 없애지는 못합니다.

모델 샤딩을 사용하면 워커가 전체 파일이 아니라 할당된 영역만 읽을 수 있습니다. 전체 파일에 대한 미리 읽기는 워커가 사용하지 않을 샤드까지 가져와 이러한 이점을 약화시킬 수 있는 반면, 샤드에 맞춘 접근은 프리페치를 유용한 범위 안에 유지할 수 있습니다.

한 호스트의 동시 프로세스는 파일 백업 페이지를 공유할 수 있지만, 서로 다른 호스트는 클라이언트 RAM을 공유할 수 없습니다. 실제 토폴로지인 로컬 SSD, 이더넷을 통한 NAS, 분산 캐시, 모델 파일 복사 환경을 기준으로 테스트하세요. 동일한 미리 읽기 설정이 로컬 지연을 줄이면서도 전체 네트워크 전송량은 늘릴 수 있습니다.

콜드, 웜, 동시 로딩으로 미리 읽기를 조정하세요

테스트하는 동안 모델 파일, 런타임, 스토리지 경로, 하드웨어를 고정하고 여러 윈도우를 비교하세요. 첫 번째 토큰까지의 콜드 시간, 웜 재시작 시간, 스토리지에서 읽은 바이트 수, 네트워크 처리량, 페이지 폴트, 캐시 압박, 다른 NAS 작업의 지연 시간을 기록하세요. 로더 하나를 사용할 때와 예상되는 동시 로더 수를 사용할 때 모두 반복해야 합니다.

프리페치와 캐시에 대한 실용적인 논의는 이러한 계층이 서로 독립적인 스위치처럼 작동하지 않고 상호작용한다는 점을 보여줍니다. 개선 효과는 단일 시작 시간 수치가 아니라 유용한 조기 읽기, 서버 캐싱, 클라이언트 재사용 중 무엇에서 비롯되었는지 구분해야 합니다.

최적의 설정은 워크로드에 따라 달라집니다. 콜드 상태의 지연을 줄이면서 사용되지 않는 데이터의 양이나 동시 간섭을 크게 늘리지 않는 동안에는 미리 읽기를 늘리세요. 접근이 희소하거나 샤딩되어 있거나 캐시 압박이 큰 경우에는 미리 읽기를 줄이세요. 런타임, 모델 형식, 샤드 배치, 스토리지 토폴로지가 바뀌면 다시 평가해야 합니다.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.