분석: 오픈 웨이트 모델 자체호스팅 — 결정을 가르는 산수와, 아무도 예산에 안 넣는 비용들

자체호스팅 논쟁은 유난히 양쪽 다 나쁜 논증에 빠지기 쉽다. 한쪽은 «가중치가 공짜니까 우리 인프라가 당연히 싸다»고 하고, 다른 쪽은 «하이퍼스케일러의 가동률을 우리가 절대 못 이기니 아무도 직접 굴리면 안 된다»고 한다.

둘은 같은 곡선을 서로 다른 끝에서 묘사하고 있다. 호스팅 추론은 변동비이고 자체호스팅은 고정비다. 모든 실제 결정은 «특정 워크로드가 교차점의 어느 쪽에 있는가»에 대한 질문이다.

비교의 «모양»

양쪽을 같은 단위로 적어 보자.

호스팅 API 는 토큰당 값을 매긴다. 하루 입력 1천만 토큰·출력 200만 토큰이면 예측 가능한 금액이 나오고, 청구서는 사용량에 선형으로 따라간다 — 올라갈 때만이 아니라 내려갈 때도. 조용한 주말에는 줄어든다.

자체호스팅은 요청이 오든 안 오든 «가속기 시간»으로 값을 매긴다. 현행 세대 데이터센터 GPU 임대가는 사업자 대부분에서 카드당 시간당 몇 달러 수준이고, 지역·약정·등급에 따라 편차가 크다. 직접 산 하드웨어는 그것을 자본지출 + 전력 + 냉각 + 감가로 바꾸는데, 상각하고 나면 대체로 비슷한 범위에 떨어진다 — 요점은 둘 다 «토큰당»이 아니라 «시간당»이라는 것이다.

그래서 산수는 이렇게 된다.

팀들이 걸려 넘어지는 곳은 둘째 줄이다. 피크 부하에 맞춰 산 클러스터를 평균 15% 로 돌리면, 몰려서 들어오는 트래픽에 대해 하루 종일 «피크 용량 값»을 치르고 있는 것이다. 만재 상태에서 유리해 보였던 토큰 단가 비교는 실제 평균에서 6배쯤 틀린다.

처리량은 «소프트웨어»의 성질이다

가장 흔한 분석 오류는 처리량이 하드웨어로 정해진다고 보는 것이다. 최소한 그만큼은 서빙 스택이 정한다.

배치 처리가 지배한다. 큰 가속기에서 요청을 한 번에 하나씩 처리하면 대부분을 낭비한다. 진행 중인 배치에 새 요청이 «합류»하는 연속 배치(continuous batching)는 같은 카드에서 처리량을 몇 배로 올릴 수 있다. 단건 벤치마크 위에 세운 자체호스팅 비용 모델은 딱 그 배수만큼 틀린다.

양자화는 «무엇이 들어가는가»를 바꾼다. 가중치를 8비트나 4비트로 서빙하면 메모리 요구가 크게 줄고, 그것이 모델을 카드 두 장에서 한 장으로 옮길 수 있다 — 한 장은 두 장보다 «50% 싼» 것에 그치지 않고, 인터커넥트 복잡도 한 무더기를 통째로 없앤다. 요즘의 학습 후 양자화는 많은 과제에서 손실이 거의 없지만 «많은»과 «거의»가 하중을 받는 단어다. 열화는 과제별이고 평균 점수가 그것을 감추므로 반드시 우리 평가셋으로 확인해야 한다.

모델 크기가 효과가 가장 큰 지렛대다. 자체호스팅 경제성의 대부분은 «가속기당 동시 요청을 여러 개 태울 만큼 작은 모델»에 기대고 있다. 오픈 웨이트 생태계가 작은 규모에서 꾸준히 좋아진 것이 바로 평범한 제품에서 자체호스팅을 가능하게 만든 요인이다. 반대로 정말 프런티어급이 필요한 과제는 하드웨어 청구서가 전혀 다르고 논거도 훨씬 약하다.

첫 견적에서 빠지는 네 줄

지금까지 본 자체호스팅 초기 견적은 같은 누락을 공유한다.

이중화. 노드 하나는 데모다. 프로덕션은 최소 둘, 서로 다른 장애 도메인에, 롤링 재시작 여유까지 필요하다. 10% 보정이 아니라, 트래픽이 늘기도 전에 하드웨어 줄이 두 배가 되는 일이 흔하다.

엔지니어 시간. 누군가는 서빙 스택을 설정하고, 배치 파라미터를 튜닝하고, 오토스케일링을 붙이고, 헬스체크를 쓰고, 커널을 깨뜨린 드라이버 업그레이드를 처리하고, 새벽 두 시에 처리량이 무너졌을 때 호출을 받는다. 그 사람의 현실적인 총원가로 계산하면, 엔지니어 «1년의 일부»가 중간 규모 워크로드의 GPU 줄 전체보다 큰 경우가 잦다. 가장 자주 빠지는 줄이고, 결정을 가르는 줄인 경우가 많다.

평가. 자체호스팅은 대개 «더 작은 모델로 옮긴다»는 뜻이다. 그건 품질 변경이고, 받아들일 만한지 확인하려면 평가셋·비교 실행·결과를 해석할 판단이 필요하다. 실제 작업이고, 절감이 오기 «전»에 일어나며, 모델을 올릴 때마다 다시 온다.

업그레이드 러닝머신. 호스팅 API 는 우리가 가만히 있어도 좋아진다. 자체호스팅 스택은 누군가 일을 해야 좋아진다 — 새 오픈 릴리스를 평가하고, 서빙 파라미터를 다시 잡고, 평가셋을 다시 돌리고, 이관을 계획한다. 반복 비용으로 잡아라. 실제로 반복이다.

자체호스팅이 «분명히» 이기는 자리

이 글의 어느 것도 자체호스팅에 반대하는 논증이 아니다. 명백히 옳은 프로필이 있다.

꾸준하고 많고 예측 가능한 물량. 배치 분류, 문서 처리 파이프라인, 임베딩 생성, 검수 큐 — 계속 돌면서 가속기를 바쁘게 유지하는 워크로드. 존재하는 자체호스팅 후보 중 최고이고, 그중 다수가 작은 모델을 쓴다는 사실이 논거를 더 강하게 만든다.

작은 모델로 충분할 만큼 좁은 과제. 분류, 추출, 라우팅, 구조화 태깅, 고정된 도메인 안에서의 번역. 잘 고른 작은 모델이 받아들일 만한 품질로 일을 해낸다면, 프런티어 API 와의 건당 경제성은 승부가 안 된다.

오프라인·망분리 운용. 어떤 값을 내도 API 가 없다. 결정은 다른 데서 이미 났다.

비용이 아닌 이유들

자체호스팅의 가장 강한 논거 중 일부는 산수에 무관심하다.

데이터 소재지와 규제. 데이터가 관할이나 망 경계를 떠날 수 없다면 자체호스팅이 유일한 준수 가능 구조인 경우가 많고, 더 비싸더라도 그 판단은 옳다.

단단한 지연 하한. 호스팅 엔드포인트로 가는 왕복에는 로컬 추론에 없는 하한이 있다. 예산이 빠듯한 상호작용 경험 — 음성, 실시간 보조, 에디터 내 자동완성 — 에서는 그 하한이 «최적화»가 아니라 «요구사항»일 수 있다.

동작의 안정성. 호스팅 모델은 우리 밑에서 바뀔 수 있고, 고정한 로컬 체크포인트는 안 바뀐다. 특정 모델의 동작에 맞춰 정교하게 튜닝해 둔 시스템에게 그 안정성은 어느 청구서에도 안 나오는 가치를 갖는다.

남의 로드맵으로부터의 독립. 지원 종료 일정, 사용량 한도, 지역별 가용성, 약관은 전부 다른 사람이 내리는 결정이다. 가중치를 소유하면 그 의존이 사라진다 — 나머지 전부를 소유하는 대가로.

대부분의 팀이 도착하는 답

실무에서 흔한 결말은 양극단이 아니다. 라우팅 구성이다. 자체호스팅한 작은 모델이 크고 잘 이해됐으며 물량 많은 부분을 맡고, 호스팅 프런티어 모델이 어려운 꼬리 — 모호한 사례, 긴 문서, 비용보다 품질이 중요한 요청 — 를 맡는다.

돈이 있는 자리가 물량 많은 쪽이므로 절감의 대부분을 가져가면서, 작은 모델 혼자서는 못 닿는 품질 천장을 유지한다. 성능 저하도 매끄럽다 — 로컬 클러스터가 죽으면 트래픽이 «장애»가 아니라 «비싼 API»로 떨어진다.

한 가지만은 고집할 만하다. 결정을 실제 숫자로 내려라. 우리 가동률 곡선을 재고, 배치를 켠 상태로 처리량을 벤치마크하고, 엔지니어 줄에 진짜 인건비를 넣고, 평가 작업을 포함시켜라. 그렇게 하면 답은 대개 자명해진다. 건너뛰면, 데이터를 갖기 «전»에 채택한 입장을 방어하는 데 시간을 쓰게 된다.