[기획: AI 트렌드] 캐시를 반으로 나눈 날, 한 사용자의 GLM-5.3이 느려졌다 — llama.cpp MoE 캐시의 450 대 300

10월 19일, 캐시를 반으로

10월 19일, llama.cpp에 PR #30637이 머지됐습니다. llama.cpp는 내 컴퓨터에서 AI 모델을 돌리는 오픈소스 프로그램입니다. PR은 코드 수정 요청이고, 머지는 그것을 본 코드에 합치는 일입니다. eapache가 쓰고 CISC가 머지한 이 PR은 MoE 전문가 캐시를 반으로 나눴습니다. 작성자 실험에서는 조금 빨라졌는데, 같은 날 한 사용자는 자기 구성에서 느려졌다고 보고했습니다.

MoE(전문가 혼합)는 모델 안에 「전문가」라 부르는 작은 하위 신경망을 여럿 두고, 토큰마다 일부만 골라 쓰는 구조입니다. 토큰은 모델이 글을 잘게 자른 조각입니다. 전문가 묶음은 층(모델 안의 계산 단계)마다 따로 있고, 토큰은 층마다 몇 개씩 고릅니다. 그래서 층이 수십 개면 토큰 하나가 전문가를 수백 개 씁니다. llama.cpp에는 앞쪽 N개 층의 전문가를 CPU 쪽 메모리에 두는 옵션이 있습니다.

10월 7일 머지된 PR #29887은 여기에 GPU 캐시를 붙였습니다. GPU는 AI 계산을 맡는 칩이고, 캐시는 자주 쓰는 것을 가까운 곳에 복사해 두는 저장 공간입니다. 캐시가 없으면 CPU 쪽 전문가는 CPU가 직접 계산합니다. 캐시를 켜면 그 계산을 GPU가 맡고, 최근 쓴 전문가는 GPU 메모리에 남겨 두며, 캐시에 없는 것만 그때마다 실어 옵니다. 그래서 캐시에서 자주 놓치면 싣는 비용이 아끼는 시간보다 커질 수 있습니다. 크기는 사용자가 --moe-cache-mib 옵션에 MiB(메가바이트와 비슷한 단위)로 적어 정합니다.

캐시가 차면 가장 오래 안 쓴 전문가부터 내보냈고, 이 교체 방식을 LRU라고 합니다. 책상이 책으로 꽉 차면 가장 오래 안 펼친 책부터 치우는 식입니다.

이 캐시를 만든 am17an이 RTX 4090으로 잰 결과, 필요한 전문가가 이미 캐시에 있던 비율인 히트율은 72%였습니다. 생성 속도, 즉 초당 만드는 토큰 수는 캐시 없을 때의 약 1.57배였습니다.

두 칸으로 나눈 이유

#30637은 파일 두 개를 고친 수정으로, 이 LRU를 두 칸으로 나눴습니다. 작성자는 이를 SLRU라고 불렀습니다. 새로 올라온 전문가는 「수습」 칸에 들어가고, 캐시에 있다가 다시 쓰이면 「보호」 칸으로 올라갑니다. 보호 칸은 캐시의 절반까지 쓰고, 내보낼 전문가는 수습 칸에서부터 찾습니다. 책상 위 책을 두 더미로 나눠, 새로 가져온 책과 다시 펼친 책을 따로 쌓는 셈입니다.

작성자는 여러 대안을 견준 시험에서, 이 방식이 회귀(바꾼 뒤 전보다 나빠지는 일) 없이 이득이 가장 컸다고 적었습니다. 단순 LRU보다는 성능이 약 1~5% 앞섰다고 했습니다. 시험은 서로 다른 GPU 두 장을 단 기계 한 대에서, 모델 두 개로 했습니다. 캐시를 만든 am17an도 「작지만 꾸준한 이득」을 봤다며 승인했습니다. 수치 표는 없었습니다.

같은 날, 한 사용자의 GLM-5.3이 느려졌다

머지 당일, 사용자 kudraw는 GLM-5.3-Flash에서 회귀가 생긴 것 같다고 적었습니다. 생성 속도가 초당 약 15토큰에서 약 12.5토큰으로 떨어졌다는 보고입니다. 모델은 가중치를 3비트 안팎으로 줄여 담은(양자화) IQ3_XS 판이었고, 전문가를 CPU 쪽에 둔 층은 40개, 캐시는 4500 MiB, GPU는 RTX PRO 4500이었습니다.

같은 날 작성자의 계산으로는, 이 모델 판에서 전문가 하나가 약 10 MiB라 이 캐시에 약 450개가 들어갑니다. 이 구성에서 토큰 하나는 CPU 쪽 메모리의 전문가를 약 300개 씁니다. 이 PR 전에는 토큰 하나에 필요한 전문가가 캐시에 통째로 들어가고도 남았습니다. 캐시가 그 수의 약 1.5배였던 셈입니다(우리 계산).

이 PR이 캐시를 반으로 나누자, 보호 칸이 절반까지 차면 새 전문가가 쓸 칸은 약 225개로 토큰 하나에 필요한 수에 못 미칩니다(우리 계산). 작성자도 어느 칸에도 토큰 하나 분량이 들어갈 공간이 없다고 적었고, 캐시 내용이 심하게 뒤바뀌는 일을 쉽게 떠올릴 수 있다고 했습니다.

10월 20일 작성자는 경계를 다시 쟀습니다. 토큰 하나에 필요한 전문가를 딱 담는 캐시 크기를 「1x」라 부릅니다.

캐시가 그보다 작으면, 올린 전문가가 곧 밀려나 매번 다시 올리는 스래싱이 일어납니다. 이때 속도는 CPU 쪽 메모리와 GPU를 잇는 통로인 PCIe, 그리고 메모리의 전송 속도에 묶입니다.

그 크기를 넘어도 캐시가 작으면 단순 LRU가 SLRU를 크게 앞섰습니다. SLRU가 앞서기 시작하는 교차점은 작성자가 본 범위로 1x의 약 1.4배에서 1.8배였습니다. 교차점은 전문가를 얼마나 되풀이해 쓰느냐에 크게 달렸습니다. 이 사용자의 캐시는 그 범위 안에 들어갑니다(우리 계산).

캐시가 작으면 예전 방식으로

10월 20일 작성자는 수정 PR #30848을 올렸습니다. 토큰 하나 분량도 못 담는 캐시를 더 엄격히 막고, 그 1.8배보다 작으면 단순 LRU로 돌아가게 하는 수정입니다. SLRU를 버리는 수정은 아닙니다. 교차점 위에서는 SLRU가 앞선다는 작성자 관찰대로, 수정은 캐시 크기에 따라 방식을 고르게 합니다.

같은 날 kudraw는 수정 PR을 적용해 같은 입력 문장으로 다시 쟀습니다.

회귀를 보고한 구성(표 둘째 줄)에서 히트율은 4.95%에서 30.60%로 올랐습니다. 속도는 초당 13.35토큰에서 15.55토큰이 됐습니다. 수정 전에는 캐시를 쓰지 않은 구성(표 첫 줄)보다도 느렸는데, 그 구성은 전문가를 GPU에 둔 층이 하나 더 많습니다.

이 결과는 사용자 한 사람의 측정이고, #30848은 10월 20일 기준 아직 머지되지 않은 초안(Draft)입니다. 캐시가 본전을 찾는 히트율도 기계마다 다르게 보고됩니다. am17an은 느린 PCIe4 기계에서 75% 아래면 도움이 안 된다고 적었고, 다른 사용자는 PCIe 4 x8에서 85%를 손익분기로 적었습니다. 이 사용자 기계가 어느 쪽에 가까운지는 원문에서 확인하지 못했습니다.

캐시 크기는 누가 정하나

작성자는 수정 PR의 전환 기준을 스스로 「매우 대략적인 상한」이라 불렀습니다. 캐시 크기를 자동으로 고르는 기능은 「지금으로선 너무 복잡하다」고 적었습니다. 지금 초안대로 머지되면, 교체 방식은 캐시와 토큰 하나 분량의 비율에 따라 정해집니다.

앞선 글에서 우리는 답을 채점하는 테스트로는 효율의 낭비가 보이지 않는다고 봤습니다답은 맞았고 GPU마다 전문가가 전부 실려 있었다, transformers에 그것을 확인하는 테스트가 추가됐다. 이번에는 작성자가 성능을 여러 번 쟀지만, 회귀를 보고한 사람은 자기 구성에서 속도를 잰 사용자였습니다. 앞으로 볼 것은 #30848의 머지 여부와, 캐시 크기를 자동으로 고르는 기능이 생기는지입니다.

교체 방식의 우열은 방식 안에 있지 않았습니다. 같은 SLRU가 큰 캐시에서는 앞서고 작은 캐시에서는 뒤졌습니다. 우열을 가른 것은 캐시에 담기는 전문가 수와 토큰 하나가 쓰는 전문가 수의 비율이었고, 그 문턱은 전문가를 얼마나 되풀이해 쓰느냐에 따라 움직였습니다(우리 판단). 이긴 쪽의 이득은 작성자 실험에서 몇 퍼센트였고, 진 쪽의 손실은 이 사용자 구성에서 초당 15.55토큰과 13.35토큰의 차이였습니다. 그 비율을 정하는 두 값, 캐시 크기와 전문가를 CPU에 둘 층 수는 지금 사용자가 정합니다(우리 판단).