몸통은 하나, 조각만 갈아 끼우면 됩니다: 커뮤니티 파생 모델을 함께 서빙하는 법
인기 있는 오픈 모델 하나를 내놓으면, 그 모델을 살짝 바꾼 커뮤니티 버전이 금방 수십 개씩 따라붙습니다. 이 버전들을 서버 한 대에 모아 서빙하면, 버전마다 서버를 따로 두는 것보다 비용이 훨씬 적게 듭니다. 모델 서비스를 운영하거나 서버를 몇 대 둘지 정해야 하는 분이라면, 이 글이 그 계산에 바로 쓸모가 있습니다.
이 글은 저희 연구팀이 자율로 쓴 논문 하나를 소개합니다. 논문 이름은 ‘파생판의 긴 꼬리’이고, 서버를 한 대로 모을지 여러 대로 나눌지의 갈림길을 실제 숫자로 그려 봅니다.
쉽게 말하면
커피머신을 떠올려 보겠습니다. 머신 한 대는 크고 비쌉니다. 캡슐 하나는 작고 쌉니다. 맛을 하나 새로 만들 때마다 머신을 통째로 새로 사는 사람은 없습니다. 캡슐만 새로 만들어서 서랍에 넣어 두면 됩니다.
오픈 모델을 서빙하는 일도 똑같습니다. 크고 비싼 몸통에 해당하는 것이 베이스 모델이고, 캡슐에 해당하는 것이 그 위에 커뮤니티가 만든 작은 조각들, 로라(LoRA)입니다. 조각 하나의 크기는 몸통의 반 퍼센트도 안 됩니다.
전용 서버는 조각 하나마다 몸통을 통째로 다시 놓는 쪽입니다. 조각이 백 개면 몸통도 백 벌이 필요합니다. 함께 쓰는 서버는 몸통을 하나만 두고, 남는 자리에 조각을 서랍처럼 쌓아 두는 쪽입니다. 주문이 들어오면 그 조각만 꺼내 씁니다.
다만 서랍에도 자리 한계가 있습니다. 자리를 넘는 조각은 창고까지 갔다 와야 하고, 그 시간이 곧 함께 쓰는 서버가 물어야 하는 덧붙는 비용입니다. 손님들이 몇몇 맛에만 몰리면 서랍을 자주 안 여닫아도 되니 덧붙는 비용도 줄어듭니다.
무엇을 해봤나
논문은 가정을 하나의 표로 정리하고, 그 표 위에서 두 가지 서버 방식을 계산으로 비교합니다. 베이스 모델은 성능 좋은 오픈 모델 한 종이고, 크기는 54기가바이트쯤입니다. 조각(로라) 하나는 그 반 퍼센트도 안 되는 크기입니다. 이 작은 크기가 이 논문의 질문을 만드는 지점입니다.
전용 서버는 조각마다 몸통 전체를 매번 다시 올립니다. 함께 쓰는 서버는 몸통 하나에 조각들을 얹습니다. 함께 쓰는 서버가 쓰는 그래픽카드는 H200급으로, 저장 공간이 141기가바이트입니다. 이 공간은 세 몫으로 나뉩니다.
- 몸통(베이스 모델): 54기가바이트
- 대화 기억 공간: 27기가바이트
- 조각(로라) 서랍: 60기가바이트
조각 하나가 몸통의 반 퍼센트 크기이니, 이 서랍에는 조각을 약 220개까지 담을 수 있습니다. 즉, 사람 말로는 서랍이 넉넉해 보여도 파생판이 220개를 넘는 순간부터는 자리가 모자란다는 뜻입니다.
손님 주문이 몇몇 조각에 몰리는 정도도 함께 바꿔 가며 봤습니다. 논문은 이 쏠림 정도를 낮음, 보통, 높음 세 단계로 나눠 계산했습니다. 조각 수는 2개부터 512개까지 늘려 가며 비교했습니다.
나온 결과
몸통을 몇 번 사는지가 비용을 가릅니다
조각 수가 늘어날수록 전용 서버는 몸통을 그만큼 여러 번 삽니다. 함께 쓰는 서버는 몸통을 딱 한 번만 삽니다. 그 결과 전체 비용 차이는 대략 조각 수만큼 벌어집니다.
- 조각 32개: 약 30배
- 조각 256개: 약 230배
- 조각 512개(손님이 특정 맛에 몰릴 때): 약 480배
Zipf 집중도 s = 0.5, 1, 1.5에서 어댑터 수 K에 대한 플릿 우위비 R(K, s)와 오버헤드 없는 동일선 R = K를 비교한 그림입니다. R은 밴드 전체에서 K를 따라가고, 평탄 트래픽 곡선은 K = 512에서 풀을 벗어난 호스트 링크 페널티가 초과하면서 K 아래로 휘어집니다. (분석적 모델 출력이며 실측이 아닙니다)
한 군데는 예외입니다. 손님이 고루 흩어져 조각을 몰아 시키지 않는 경우, 조각 수가 512개가 되면 서랍이 220개짜리 자리를 넘어서면서 오히려 이득이 살짝 줄어듭니다. 그래도 이 최악의 경우조차 함께 쓰는 서버가 190배 더 쌉니다. 즉, 사람 말로는 조각을 아무리 늘려도 함께 쓰는 서버가 손해를 보는 지점은 없다는 뜻입니다.
서랍이 꽉 찰 때 덧붙는 비용이 뜁니다
함께 쓰는 서버가 무는 덧붙는 비용은 두 갈래입니다. 하나는 주문마다 서랍에서 조각을 꺼내는 데 드는 비용이고, 다른 하나는 서랍 자리를 넘겨 창고까지 다녀오는 비용입니다. 서랍 한계 220개 안에서는 이 두 비용이 이렇게 갈립니다.
- 서랍에서 꺼내는 비용: 약 10퍼센트에서 멈춤
- 창고까지 다녀오는 비용: 정확히 0
멀티플렉스 토큰당 오버헤드 δ(K, s = 1)를 퍼센트 포인트로 분해한 그림입니다. 배치 내 어댑터 리스트림 항은 약 11퍼센트로 커진 뒤 223개 어댑터의 풀-핏 경계에서 평탄해지고, 풀을 벗어난 호스트 링크 경쟁 항은 경계까지 정확히 0이다가 K = 512에서 +22.0포인트로 도약합니다. (분석적 모델 출력이며 실측이 아닙니다)
220개를 넘어서면 이야기가 달라집니다. 조각 512개에서는 창고를 다녀오는 비용이 갑자기 22퍼센트포인트 넘게 뛰어오르고, 덧붙는 비용 전체가 약 34퍼센트까지 올라갑니다. 즉, 사람 말로는 서랍 크기를 넘기지 않게 관리하는 것이 함께 쓰는 서버의 진짜 관건이라는 뜻입니다.
전용 서버가 이기는 경우는 딱 하나입니다
주문 하나하나 단가로 따지면 상황이 뒤집힐 때가 있습니다. 어떤 조각 하나가 전체 주문의 아주 큰 몫을 차지하면, 그 조각만을 위한 전용 서버가 함께 쓰는 서버보다 쌉니다. 조각이 많아질수록 그 갈림선은 낮아집니다.
- 조각이 2개일 때 갈림선: 전체 주문의 거의 전부
- 조각이 512개일 때 갈림선: 전체 주문의 3분의 1 남짓
논문이 살펴본 손님 쏠림 범위 안에서는, 이 갈림선을 넘는 조각이 단 하나도 없었습니다. 가장 인기 있는 조각조차 전체 주문의 몫이 갈림선에 못 미칩니다. 즉, 사람 말로는 전용 서버가 주문 단가로 이기는 상황은, 적어도 이 논문이 살펴본 커뮤니티 파생판 세계에서는 일어나지 않는다는 뜻입니다.
파생판 목록은 가만히 있지 않습니다
파생판 목록은 계속 자랍니다. 파인튜닝 팀이 새 파생판을 매주 몇 개씩 만들어 내기 때문입니다. 논문은 매주 4개씩 새 조각이 늘어난다고 놓고 시간을 따라가 봤습니다. 처음 32개였던 목록은 약 1년이 안 돼 220개짜리 서랍 한계를 넘고, 약 2년 뒤에는 512개에서 멈춥니다.
주 4개씩의 일정한 도착(K0 = 32, Kss = 512) 하에서 카탈로그가 약 48주차에 풀-핏 경계를 건너 약 120주차(2.3년)에 512로 포화되는 동안, s = 1의 플릿 우위가 30배에서 약 385배로 흐르는 그림입니다. (분석적 모델 출력이며 실측이 아닙니다)
같은 기간 동안 함께 쓰는 서버의 이득은 약 30배에서 약 385배로 불어납니다. 즉, 사람 말로는 새 조각을 하나 더 만드는 값이 함께 쓰는 서버에서는 서랍 한 칸, 전용 서버에서는 몸통 한 벌이라는 뜻입니다.
그래서 무엇을 바꾸면 되나
논문은 이 계산을 운영 규칙 한 줄로 정리합니다. 조각이 하나뿐이면 어느 쪽을 골라도 똑같습니다. 조각이 2개에서 220개 사이면 답은 함께 쓰는 서버 하나뿐입니다. 220개를 넘으면 서랍을 늘리거나, 조각을 더 촘촘히 쌓는 방식으로 한 수를 더 둬야 합니다.
값을 매겨 보면 체감이 더 큽니다. 조각 32개, 한 달 요청 1억 건, 그래픽카드 임대료 시간당 5달러를 기준으로 잡으면 함께 쓰는 서버는 그래픽카드 한 장으로 한 달 약 3,900달러가 듭니다. 같은 조건에서 전용 서버는 그래픽카드 서른두 장으로 한 달 약 11만 6천 달러가 듭니다. 즉, 사람 말로는 그래픽카드 한 장짜리 작은 운영자도 서른두 장짜리 팀과 똑같은 목록을 30분의 1 비용으로 서빙할 수 있다는 뜻입니다.
몸통을 더 작게 압축하는 결정도 이 계산과 맞물립니다. 몸통이 작아질수록 조각의 상대적인 무게가 커지기 때문에, 몸통을 줄이는 결정과 서랍 한계선은 따로 놀지 않고 함께 움직입니다.
ThakiCloud 입장에서 이 결과는 추론 서비스인 Metis가 커뮤니티 파생판 수요를 받을 때 그래픽카드를 몇 장 둘지 정하는 규칙 그 자체입니다. 그 파생판을 만드는 쪽인 학습·평가 파이프라인 Maxis와도 맞물려 있습니다. 오픈 모델 하나가 나오면 그 주변에 이런 파생판 생태계가 함께 자란다는 사실은, 서빙 비용을 처음부터 파생판 단위로 계획해야 한다는 뜻이기도 합니다.
못 믿을 부분
이 논문의 숫자는 전부 계산이지 실측이 아닙니다. 논문은 실제 그래픽카드 위에서 여러 조각을 함께 돌리는 엔진에 손님 쏠림 정도를 바꿔 가며 실측을 얹고, 실제 서비스 기록에서 쏠림 정도를 다시 맞춰 보는 후속 검증 절차까지 함께 제안해 두었습니다. 이 글의 숫자는 그 검증이 아직 오기 전, 계산이 내놓은 예상값으로 읽어야 합니다.
계산이 꽤 안정적이라는 점도 함께 밝혀 둡니다. 손님 쏠림 정도를 낮음, 보통, 높음으로 바꿔도 서랍 한계선 안에서는 전체 비용 차이가 크게 흔들리지 않았습니다. 다만 몇 가지는 그대로 가정으로 남았습니다. 모든 조각이 같은 크기라고 놓았고, 목록이 몸통 하나 위에만 있다고 놓았습니다. 손님 주문을 한 번에 처리하는 묶음 크기도 32건으로 고정해 뒀는데, 이 값이 커지면 계산은 더 함께 쓰는 서버 쪽으로 기울 것으로 보입니다.
비용 계산에는 격리나 보안, 장애 대비 같은 값은 들어 있지 않습니다. 전용 서버는 나쁜 조각 하나가 말썽을 부려도 다른 손님에게 번지지 않게 막아 주는 몫이 있습니다. 이 계산은 주문 단가로만 보면 전용 서버가 늘 진다고 말하지만, 격리가 꼭 필요한 자리라면 비용과 무관하게 전용 서버를 두는 것이 맞을 수 있습니다. 논문도 이 예외를 계산 바깥에 따로 적어 두었습니다.
논문 상세 페이지는 여기에서 볼 수 있습니다: The Derivative Long Tail: Multiplex-vs-Dedicated LoRA Serving on H200
본문의 숫자는 읽기 쉽게 반올림했고, 정확한 값은 각 그림 캡션에 그대로 두었습니다. 이 논문의 모든 수치는 가정 표에 대한 계산 결과이며 실측이 아닙니다.