Mistral Large 4 직접 호스팅: 뼈저린 교훈 모음

Mistral이 Mistral Large 4의 가중치를 공개했을 때(약 1조 개 파라미터, 활성 파라미터 약 520억 개), 제 받은편지함에는 같은 질문이 쏟아졌습니다. 우리도 직접 돌릴 수 있을까? 오픈 웨이트 셀프 호스팅은 이제 취미 수준의 꿈이 아니라 실제 아키텍처 선택지가 됐고, 그만큼 비싼 실수를 저지르는 팀도 곧 늘어날 겁니다. 이미 여러 팀이 그런 실수를 하는 걸 지켜봤습니다. 이 글은 실무자들이 셀프 호스팅을 잘못하는 구체적인 방식과 각각의 해결책을 정리한 교훈 모음입니다.

실수 1: “오픈 웨이트”를 “마음대로 써도 되는 무료”로 읽기

첫 번째 실수는 GPU를 만지기도 전에 일어납니다. Mistral Large 4는 수정된 MIT 계열 라이선스로 배포되는데, 중요한 예외 조항이 있습니다. 여러분이나 계열사가 모델을 서비스형으로 제공하는 사업을 한다면, 상업적으로 쓰기 전에 Mistral에서 별도의 상업 라이선스를 받아야 합니다. 사내에서 추론을 돌리는 경우, 예컨대 문서를 요약하거나 직원용 코딩 어시스턴트를 만드는 정도라면 대개 문제없습니다. 하지만 추론 서비스를 재판매할 계획의 스타트업이라면, Mistral에 메일을 보내기 전까지는 사실상 멈춰야 합니다.

이 부분을 양방향으로 잘못 이해하는 팀이 많습니다. 어떤 팀은 보도자료에 있는 “오픈”이라는 단어만 보고 가중치 위에 상업 제품을 만들었다가, 투자 실사 과정에서 제약을 발견합니다. 가장 최악의 타이밍이죠. 반대로 과잉 해석해서 상업적 사용이 전면 금지된다고 믿는 팀도 있는데, 실제로는 경쟁 추론 제공업체를 겨냥한 조항입니다. 해결책은 지루하지만 필수입니다. 발표 글이 아니라 실제 라이선스 원문을 법무팀이 읽게 하세요. “오픈 웨이트”라고 부르든 “가중치 공개(weight-available)”라고 부르든, 커뮤니티에서 시끄럽게 논쟁이 벌어지는 이 구분과 상관없이, 엔지니어링 결정은 라이선스가 실제로 허용하는 범위에 맞춰 내려야 합니다.

한 가지 더 짚자면, 이런 라이선스 방식은 이제 주요 가중치 공개의 예외가 아니라 표준입니다. 아키텍처가 Mistral, Qwen 등 여러 프론티어 가중치 모델을 오가며 쓰는 구조라면, 일회성 검토가 아니라 라이선스 매트릭스가 필요합니다. 클러스터를 만들기 전에 그 스프레드시트부터 만드세요.

실수 2: 계산 대신 마케팅 페이지를 보고 하드웨어 규모 잡기

가장 돈을 많이 태우는 실수는 이겁니다. 엔지니어가 “1T 파라미터”라는 문구를 보고, 회사 서버실에 있는 H200 네 대를 떠올리며 540GB VRAM이면 충분하겠다고 어림짐작합니다. 하지만 그렇지 않습니다. 이유는 90초면 할 수 있는 산수인데, 그걸 안 하면 한 분기 치의 민망함을 얻게 됩니다.

BF16 정밀도에서 1조 개 파라미터는 가중치만으로 약 2TB 메모리가 필요합니다. 8비트로 양자화하면 약 1TB, 4비트면 KV 캐시, 활성값, 서빙 오버헤드를 더하기 전에도 약 500~560GB가 필요합니다. 540GB 서버에 4비트 모델을 올릴 수는 있어도, 짧은 컨텍스트 윈도우와 소수의 동시 사용자를 감수할 때만 가능합니다. 혼합 전문가(MoE) 구조(토큰당 활성 파라미터 520억 개)는 토큰당 연산량을 줄여주지만 메모리에는 아무 도움이 안 됩니다. 파라미터 전부가 어딘가 주소 지정 가능한 곳에 있어야 하고, MoE에서는 전문가 가중치가 예측 불가능하게 접근되기 때문에 CPU RAM으로 오프로딩하면 밀집(dense) 모델보다 지연 시간이 훨씬 더 망가집니다.

해결책은 하드웨어에서 출발하지 말고 서빙 요구사항에서 거꾸로 계산하는 것입니다. 목표 컨텍스트 길이, 동시성, 초당 토큰 수를 먼저 정하고, 감당 가능한 양자화 수준을 도출한 다음, 하드웨어를 역산하세요. 결과가 H200 여덟 대나 NVL72급 노드 두 개라서 숫자를 보고 움찔한다면, 좋은 신호입니다. 그 움찔함이 바로 모델이 의도대로 작동하는 순간이니까요. 인접한 문제는 GPU VRAM이 부족할 때 할 수 있는 일에서 다뤘습니다. 거기 나온 방법(오프로딩, 더 작은 양자화, 더 작은 모델)은 여기서도 그대로 통하고, 다만 데이터센터 규모로 올라갈 뿐입니다.

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

정직한 표에는 KV 캐시와 오버헤드가 들어갑니다. 가중치만 적은 불성실한 표가 바로 모델은 로드되는데 사용자 세 명 이상은 감당하지 못하는 상황을 만드는 원인입니다.

실수 3: 양자화를 공짜 점심으로 취급하기

팀이 양자화가 필요하다는 걸 받아들이고 나면, 다음 실수는 4비트면 “사실상 같은 모델”이라고 가정하는 겁니다. 때로는 그렇습니다. 하지만 종종 아니고, 실패 양상이 하필 가장 신경 쓰이는 부분에서 나타납니다.

반복해서 보는 패턴이 있습니다. 팀이 4비트 배포본을 MMLU 스타일 객관식 문제로 벤치마크하고, 1% 하락을 확인한 뒤 배포합니다. 그러다 실사용자들이 여러 파일에 걸친 긴 코드 리팩터링이 엉뚱한 방향으로 흘러간다고 하거나, 도구 호출 JSON이 낮은 확률이지만 자주 미묘하게 깨진다고 보고합니다. 공격적인 양자화는 장기적이고, 구조화되어 있고, 낮은 temperature가 요구되는 작업에 불균형하게 타격을 줍니다. 바로 프론티어 모델을 쓸 이유가 되는 에이전트 및 코딩 워크로드 말입니다. 평균은 거의 움직이지 않지만, 꼬리 부분이 무너집니다.

양자화는 VRAM이 강요하는 만큼이 아니라 여러분의 태스크 평가가 허용하는 만큼 해야 합니다. 실제 워크로드 프롬프트로 FP8, 4비트, 3비트 빌드를 돌려 비교하세요. 3비트가 평가를 통과하면 축하합니다. 하드웨어 비용이 절반으로 줄었으니까요. 실패한다면, 어떤 벤치마크 평균도 구해주지 못합니다. 그리고 제작사가 배포하는 네이티브 양자화 버전이 있다면 그쪽을 우선하세요. Mistral은 BF16 가중치와 함께 NVFP4 변형을 공개했는데, 제작사가 측정한 품질 차이가 있는 공식 양자화본이, 하루 검증한 커뮤니티 GPTQ 변환본보다 낫습니다.

양자화 수준은 압축 설정이 아니라 품질 예산입니다. 워크로드가 감당할 수 있는 곳에 그 예산을 쓰세요.

실수 4: API 가격과 GPU 가격을 비교해 놓고 TCO 분석이라고 부르기

전형적인 스프레드시트가 있죠. “API는 백만 출력 토큰당 2.10달러, 예약한 GPU 노드는 시간당 X달러, 따라서 월 Y 토큰을 넘으면 셀프 호스팅이 이득이다.” 이 스프레드시트는 거의 항상 틀렸고, 틀리는 방향이 비싼 쪽입니다.

빠진 것은 활용률입니다. API는 남의 용량을 100% 활용하면서 토큰 단위로 과금합니다. 반면 직접 운영하는 클러스터는 트래픽 패턴이 주는 만큼의 활용률만 얻는데, 대부분의 사내 워크로드는 들쭉날쭉합니다. 업무 시간에는 몰리고, 밤에는 놀고, 릴리스 주변에서는 튀죠. 피크 기준으로 잡은 클러스터는 하루의 대부분을 절반쯤 비어 있게 돕니다. 여기에 스프레드시트에 안 들어가는 비용도 더해야 합니다. vLLM 업그레이드, CUDA 드라이버 불일치, 캐시 단편화로 새벽 2시에 울리는 호출을 포함한 서빙 스택을 담당할 온콜 로테이션, 새 가중치 릴리스마다 재검증해야 하는 모델 업데이트 부담(평가 스위트가 그렇다고 말합니다), 그리고 제품 대신 GPU를 돌보는 데 쓰이게 된 ML 엔지니어의 기회비용이 있습니다.

아무도 가격에 넣지 않는 움직이는 과녁 문제도 있습니다. Mistral은 이 모델의 API 가격을 프리뷰와 정식 출시 사이에 거의 절반으로 낮췄습니다. 입력 토큰은 백만 개당 1.36달러에서 0.70달러가 됐죠. 옛 가격으로 계산한 셀프 호스팅 ROI는 모두 픽션이 됩니다. 프론티어 추론은 분기 단위로 저렴해지는데, 하드웨어 감가상각은 수년 단위입니다. 이 비대칭이 셀프 호스팅 사업 계획을 조용히 죽이는 원인입니다.

해결책은 API가 구조적으로 제공할 수 없는 이유가 있을 때만 셀프 호스팅하는 겁니다. 그런 이유는 실제로 존재합니다. 하지만 대부분의 회사가 운영하는 규모에서 “대규모에서 더 싸다”는 그 이유에 해당하는 경우는 드뭅니다.

셀프 호스팅이 실제로 이기는 경우

그렇다면 Mistral급 가중치를 로컬에서 돌리는 것이 API를 이기는 때는 언제일까요? 팀들이 잘하고 못하는 모습을 지켜본 결과, 이기는 경우는 네 가지 범주로 모입니다.

• 데이터 거주성과 주권. 규제 산업, 국방 관련 업무, 엄격한 관할권 요건이 있는 EU 조직이 해당합니다. 실제로 본 제약 사례 중 하나는, 컴플라이언스 이유로 중국산 모델 사용이 금지된 회사가 있었습니다. 감사 가능한 출처를 가진 유럽 연구소의 오픈 웨이트가 어떤 API 계약으로도 해결하지 못한 문제를 풀어준 겁니다.
• 에어갭 또는 간헐적으로만 연결된 환경. 네트워크가 존재한다고 믿을 수 없다면, 로컬 가중치가 아키텍처 전체가 됩니다. 이 패턴은 오프라인에서 동작하는 LLM 만들기에서 다뤘습니다.
• 꾸준하고 예측 가능한 대량 워크로드. 24시간 일정한 처리량으로 돌아가는 배치 문서 처리는 토큰당 과금보다 실제로 저렴할 수 있습니다. 구조상 활용률 문제를 해결하기 때문입니다.
• 파인튜닝과 수정. 남의 API는 파인튜닝 엔드포인트가 허용하는 범위를 넘어서 파인튜닝할 수 없습니다. 가중치를 소유하면 학습 루프도 소유하게 됩니다. 도메인 코퍼스로 추가 사전학습, 커스텀 정렬, 더 작은 배포본으로의 증류가 가능해집니다.

목록에 없는 것도 짚어야 합니다. 지연 시간입니다. 1조 파라미터 MoE를 직접 돌린다고 해서, 잘 준비된 API보다 지연이 낮아지지는 않습니다. 추측 디코딩과 배치 1 최적화 서빙에 공격적으로 투자할 각오가 있을 때만 가능합니다. 그리고 또 하나 없는 것은 “벤더 의존성 회피”입니다. 오늘 내려받은 가중치는 1년 안에 두 세대 뒤처질 것이고, 여러분은 다시 같은 결정 지점에 서게 됩니다. 그런 점에서 일부 실무자들이 주요 가중치 릴리스의 로컬 사본을 보관하는 아카이브 습관은 꽤 합리적인 근거가 됩니다. 저장 공간은 싸고, 선택지는 가치가 큽니다.

솔직한 관점은 오픈 웨이트와 API가 경쟁자가 아니라 보완재라는 겁니다. 제가 아는 몇몇 팀은 하이브리드로 운영합니다. 들쭉날쭉한 대화형 트래픽은 API로, 규제가 걸린 부분이나 배치 중심의 부분은 로컬 가중치로 처리합니다. 기술은 옮겨갑니다. vLLM 설정, 평가 하네스, 프롬프트 템플릿은 양쪽 세계에서 모두 씁니다. 프론티어 규모에 커밋하기 전에 운영의 기본기가 필요하다면, 내 하드웨어에서 대규모 언어 모델 실행하기 가이드가 서빙 스택 전체를 다룹니다.

실수 5: 워크로드가 아니라 벤치마크로 평가하기

마지막 실수는 앞선 모든 실수를 무효로 만드는 것입니다. 팀이 모든 걸 제대로 합니다. 라이선스를 검토하고, 하드웨어 규모를 잡고, 공개 벤치마크로 양자화를 테스트합니다. 그런데 사용자가 싫어하는 모델을 출시하게 됩니다. 평가가 사용자가 실제로 하는 일을 한 번도 측정하지 않았기 때문입니다.

공개 벤치마크는 “이 모델은 전반적으로 유능한가?”라는 질문에 답합니다. “이 모델이 우리 지원 티켓을 필요한 톤과 형식으로, 4비트에서, 우리 동시성 부하 아래 분류하는가?”에는 답하지 못합니다. 예전에 AI 벤치마크가 실제 업무의 90%를 놓치는 이유를 쓴 적이 있는데, 셀프 호스팅은 그 간극을 더 날카롭게 만듭니다. API 제공자가 관리해주던 모든 변수를 이제 여러분이 책임져야 합니다. 배포 스택, 샘플러 설정, 모델이 학습된 시스템 프롬프트 관례까지, 전부 여러분이 잘못 다룰 수 있는 것들입니다.

해결책은 하드웨어를 확정하기 전에 만드는 3단계 평가 체계입니다.

1. 프로덕션에서 얻은 골든 셋. 검토된 이상적 출력이 달린 실제 프롬프트 수백 개로, 실제 작업 분포를 덮어야 합니다. 길고, 지저분하고, 다중 턴인 케이스도 포함하세요.
2. 회귀 하네스. 모든 후보(API 대 로컬, FP8 대 4비트, 이전 가중치 대 새 릴리스)가 골든 셋을 자동으로 돌아갑니다. 강력한 심사 모델과 사람의 샘플 검토로 채점하세요. 구조화된 출력에서는 심사 모델을 맹신하지 마세요.
3. 섀도 기간. 로컬 배포를 실제 트래픽에서 API와 나란히 2주간 돌리며, 출력을 비교하고 실제 부하에서의 지연 시간을 측정합니다. KV 캐시 크기 산정 실수와 양자화 꼬리 실패가 실제로 드러나는 곳이 바로 여기입니다.

이 하네스는 새 가중치 릴리스가 나올 때 본전을 뽑습니다. 회의에서 감으로 논쟁하는 대신, 오후 한나절에 데이터로 “업그레이드할까?”에 답할 수 있으니까요.

진짜 교훈: 오픈 웨이트는 답을 바꾸지 않고 질문을 바꿨다

1년 전만 해도 “프론티어 모델을 셀프 호스팅할까?”는 가정의 질문이었습니다. 프론티어가 내려받을 수 없었으니까요. Mistral Large 4와 그 밖의 1조 파라미터급 릴리스 물결은 이것을 실제 돈이 걸린 현실의 결정으로 만들었습니다. 하지만 결정 프레임워크는 바뀌지 않았습니다. 그저 필수가 됐을 뿐입니다.

주권, 연결성, 지속적인 대량 처리, 또는 모델을 수정해야 할 필요가 있을 때 셀프 호스팅하세요. 트래픽이 들쭉날쭉하고, 팀이 작고, 차별화 요소가 추론 스택이 아니라 제품일 때는 API에 비용을 지불하세요. 어느 쪽을 택하든, 서명하기 전에 90초짜리 메모리 계산을 하고, 라이선스를 읽고, 평가 하네스를 만드세요. 가중치는 이제 공개됐습니다. 안타깝게도 실수도 그렇습니다.