Reddit

llama : add a GPU cache for MoE experts kept in host memory by am17an · Pull Request #29887 · ggml-org/llama.cpp

llama.cpp, 호스트 메모리에 둔 MoE 전문가를 위한 GPU 캐시 추가

호스트 메모리에 있는 Mixture of Experts(MoE) 전문가 가중치를 GPU의 LRU 캐시에 보관하고, 캐시 적중 시 GPU에서 계산하는 llama.cpp 변경입니다. VRAM이 부족한 시스템에서 생성 속도가 빨라진 사례가 있지만, 캐시 적중률과 PCIe 대역폭에 따라 오히려 느려지기도 하며 이 PR 구현은 단일 GPU만 지원합니다.

AI 요약

이 변경은 모델 전체를 GPU 메모리에 올리기 어려운 환경을 겨냥합니다. MoE 모델의 전문가 가중치 일부를 호스트 메모리에 두고, --moe-cache-mib로 지정한 용량만큼 GPU에 캐시합니다. 호스트에 있는 전문가를 호출하면 캐시 적중 시 GPU에서 계산하고, 빗나가면 필요한 가중치를 GPU로 올립니다. 구현은 LRU(Least Recently Used) 방식이며 한 번에 최대 32개 토큰을 처리합니다. 캐시 크기는 llama_context_params::moe_cache_size로도 설정하며, 이 PR 버전은 멀티 GPU를 지원하지 않습니다.

성능은 캐시 적중률과 전송량에 좌우됩니다

AMD Radeon AI PRO R9700 32GB에서 Qwen3.8-Flash-Next를 시험한 결과, 8GB 캐시는 33%의 전문가를 보관했고 생성 속도는 초당 11.0토큰에서 14.5토큰으로 올랐습니다. 16GB 캐시와 67% 보관 설정에서는 초당 27.6토큰을 기록했습니다. 다만 프롬프트 처리 속도도 달라졌습니다. 해당 시험에서는 캐시를 끈 설정이 초당 51.5~59.3토큰이었고, 8GB와 16GB 캐시 설정은 각각 65.2, 66.5토큰이었습니다.

다른 시험에서는 캐시 크기만으로 결과를 일반화하기 어렵다는 점이 드러났습니다. 같은 R9700에서 전체 모델을 GPU에 올렸을 때 생성 속도는 초당 43.3토큰이었습니다. 16GB 캐시 설정은 적중률 94.4%에서 23.2토큰, 8GB 설정은 적중률 85.3%에서 11.9토큰을 기록했습니다. 캐시 없이 CPU에서 전문가를 처리한 설정은 11.8토큰이었습니다. 작성자는 85% 적중률에서는 CPU 경로와 비슷했고, 이 장비에서는 약 94% 수준에 도달해야 캐시 이점이 뚜렷했다고 보고했습니다.

반대로 PCIe 전송이 병목이 된 사례도 있습니다. GLM-5.3-Flash를 RTX 5090 두 장으로 시험한 댓글 작성자는 캐시 적중률 47%와 함께 토큰당 약 1.5GiB를 전송했고, PCIe 수신 대역폭이 평균 초당 24.7GB에 달했다고 밝혔습니다. 캐시 설정의 생성 속도는 코드 입력에서 초당 12.9토큰으로, 캐시를 끈 설정의 18.47토큰보다 낮았습니다. CPU에서 캐시 미스 전문가를 처리하는 다른 설계는 같은 장비에서 23.7토큰을 기록했다고 덧붙였습니다. 이 사례에서는 전문가 가중치를 GPU로 계속 옮기는 비용이 캐시의 이점을 상쇄했습니다.

캐시 정책과 적용 범위가 남은 과제입니다

토론에서는 단순 LRU가 PCIe 전송을 늘려 성능을 떨어뜨릴 수 있다는 지적이 나왔습니다. 전문가 선택에는 토큰 간 시간적 지역성이 있으므로, 자주 쓰인 전문가를 우선 보관하는 빈도 기반 정책이나 특정 레이어만 캐시에 넣는 설정을 검토하자는 제안입니다. 한 포크에서는 빈도 기반 입장·퇴출 정책을 적용해 VRAM 약 20GB 중 7~8GB를 캐시에 쓰고, 약 60% 적중률을 얻었다는 경험도 공유됐습니다. 다만 모델마다 전문가 선택 양상과 장비 구성이 다르므로 한 정책이 모든 상황에 적합하다고 단정하지는 않았습니다.

멀티 GPU 지원도 논의의 중심입니다. PR은 여러 GPU를 쓰는 구성을 초기화 단계에서 거부하지만, 가드를 제거해 시험한 GLM-5.3-Flash 사례에서는 캐시 적중률이 47%에서 58%로 올라도 생성 속도가 캐시 없는 구성보다 11~19% 느렸습니다. 프롬프트 처리 속도는 개선됐지만, GPU 메모리에 담을 수 있는 전문가 비율이 낮아 PCIe 병목이 남았습니다. 다른 사용자들은 자신의 듀얼 GPU 환경에서 속도 향상을 보고해 결과가 구성에 따라 달라짐을 보여줬습니다.

Reddit 반응

  • @u/pmttyji — llama.cpp를 쓰는 많은 사람, 특히 GPU 메모리가 부족한 사람에게는 꿈이 이루어진 것 같습니다. am17an, 다시 한번 고맙습니다!
    • @u/jacek2023 — 벤치마크를 올릴 예정인가요?
    • @u/pmttyji — 지금은 노트북이 없어 바로 확인하지 못했습니다. 나중에 초당 토큰 수를 공유하겠습니다. 8GB VRAM과 32GB RAM에 맞는 --moe-cache-mib 값은 시행착오로 찾아야 할 것 같습니다. 나중에는 -cmoe처럼 자동으로 설정하는 옵션도 있으면 좋겠습니다.
  • @u/CUvinny — 9070 XT와 Vulkan에서 Gemma 4 26B A4 QAT를 간단히 시험했습니다. 캐시를 끄면 프롬프트 처리 869.7, 생성 59.3토큰/초였습니다. 캐시를 1,000MiB로 두면 생성이 27.6으로 떨어졌고, 4,000MiB에서는 65.9, 8,000MiB에서는 76.9로 올랐습니다. 제 환경에서는 캐시를 충분히 키우면 생성은 빨라졌지만 프롬프트 처리는 더 빠르게 느려졌습니다.
  • @u/Amazing_Athlete_2265 — 3080 10GB와 Qwen3.6-35B-A3B에서 처음에는 초당 약 35토큰에서 40토큰으로 올랐습니다. -cmoe와 캐시 설정을 함께 시험한 뒤에는 생성 47토큰/초, 프롬프트 처리 500토큰/초를 기록했습니다. 이전 수치는 프롬프트 처리 350토큰/초였습니다.
    • @u/Nevensitt — 같은 그래픽카드인데 초당 15토큰 정도입니다. 명령행 설정이 어떻게 되나요?
    • @u/Amazing_Athlete_2265 — 추론 옵션을 빼면 -ub 512 --fit on --fit-target 1024 --fit-ctx 128000을 썼습니다. Arch Linux와 RAM 32GB, Q4_K_XL 양자화 모델입니다.
  • @u/WizardlyBump17 — B580에서 캐시 600MiB를 쓰자 성능이 초당 28토큰에서 14.5토큰으로 떨어졌습니다.
  • @u/lapiuslt — RTX 3060 12GB와 Qwen3.6-35B-A3B Q4에서는 이득이 없었습니다. -cmoe와 캐시 8GB를 함께 쓰자 기준 초당 32토큰에서 12토큰으로 떨어졌습니다. 모델이 21GB라 가중치와 KV 캐시를 올리고 나면 캐시 공간이 7GB뿐이어서, 적중률이 CPU에서 처리하는 것보다 나빴던 것 같습니다.
  • @u/Foreign_Prune_354 — 아주 간단히 시험했지만 RTX PRO 4500 32GB와 시스템 메모리 128GiB에서 Qwen3.8-Flash-Next Q8이 초당 22토큰에서 35토큰으로 올랐습니다. 컨텍스트는 64K, ubatch는 2048, CPU에 전문가 44개를 두고 캐시에는 10GiB를 썼습니다.
  • @u/Open-Adhesiveness-86 — 큰 성능 향상을 기대하기 전에 실제 전문가 재사용률을 확인하는 편이 좋습니다. 같은 전문가가 반복해서 선택돼야 캐시가 이득입니다. 모델에 따라 선택 분포가 고르면 작은 캐시에서 계속 교체만 일어나 PCIe 복사 비용을 치릅니다. PCIe 3.0 x4라면 대역폭이 초당 약 3.5GB이므로, 토큰마다 수백 MB의 전문가 가중치를 옮기는 상황부터 한계에 부딪힙니다.
  • @u/ShaneBowen — 이 기능을 이해하는 데 도움이 필요합니다. 호스트 메모리에 전문가를 일부 보관하는 기능인가요? 기존 CPU 오프로딩과 어떻게 다른가요?
    • @u/Zombiecidialfreak — CPU의 DDR4/DDR5에서 계산하는 대신, VRAM에서 전문가를 올리고 내립니다. GPU가 16GB이고 Qwen3.8-Flash 모델을 쓴다면 일부는 GPU에, 나머지는 RAM에 둡니다. RAM에 둔 전문가가 필요할 때 불러오고 덜 쓰는 전문가를 내보냅니다. 토큰마다 전문가를 새로 선택하는 것처럼 보여도 요청 하나 안에서는 전문가를 90% 이상 재사용하는 경우가 있어, PCIe 전송이 계산과 겹칠 수 있습니다.
  • @u/karmaisnonsense — 이 PR이 나온 과정은 조금 아쉽습니다. 구현 방법에 관한 논의가 많았고, upstream에 반영하려던 시도도 있었는데 충분히 살펴보지 않은 채 다른 구현을 가져와 며칠 만에 병합됐습니다.
    • @u/am17an — 그 vendor fork 버전도 제가 작성했습니다. 며칠 동안 자동 생성된 토론을 읽지 않고 작업한 점은 죄송합니다.
    • @u/strawberry_gin — llama.cpp는 크고 복잡한 프로젝트입니다. 기존 코드베이스 구조를 이해해야 유지보수 가능한 구현을 만들 수 있습니다. 대형 기능은 프로젝트에 맞게 다른 사람의 구현을 바꾸는 데 드는 비용이 높아서, 핵심 기여자가 직접 구현하는 편이 빠를 때도 있습니다.
  • @u/Bulky-Priority6824 — 단일 GPU에서만 가능한가요, 멀티 GPU에서도 되나요?
    • @u/am17an — https://github.com/ggml-org/llama.cpp/pull/30112가 멀티 GPU 지원을 추가할 예정입니다.

원문: Reddit / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗