Mistral이 "Small"이라고 이름 붙인 모델이 H100 4장을 요구한다. 3월 16일에 공개된 Mistral Small 4의 스펙시트를 펼치면 이해는 되지만 — 119B 파라미터 MoE, 128개 전문가, 256K 컨텍스트, 네이티브 비전, Apache 2.0 — 이걸 "스몰"이라 부르는 건 확실히 Mistral식 유머다.

128개 전문가, 4개만 출근

128개 전문가 중 매 토큰마다 4개만 활성화. 전체 119B 중 실제 연산에 참여하는 파라미터는 임베딩 포함 8B다. 공식 숫자로는 Small 3 대비 레이턴시 40% 감소, 초당 처리량 3배. "큰 모델의 지식, 작은 모델의 비용"이라는 MoE의 오래된 약속을 꽤 그럴듯하게 실현한 셈이다.

점수보다 출력 길이를 봐야 한다

벤치마크 점수만 보면 솔직히 요즘 모델 출시마다 듣는 이야기와 크게 다르지 않다. LiveCodeBench에서 GPT-OSS 120B를 이기고, MMLU Pro에서 자사 Medium 3.1에 근접한다. 괜찮은 성적이지만 "혁명적"까지는 아니다.

진짜 눈길을 끄는 건 출력 효율이다. LCR 벤치마크에서 Small 4는 정확도 0.72를 1,600자 출력으로 달성했다. 같은 정확도 구간에서 Qwen 계열은 5,800~6,100자를 쏟아낸다. 거의 4배 차이. LiveCodeBench에서도 GPT-OSS 120B보다 20% 짧은 출력으로 더 높은 점수를 기록했다.

이게 왜 중요하냐면, API 과금이 토큰 단위이기 때문이다. 같은 품질의 답을 1/4 토큰으로 받으면 실질 비용이 그만큼 줄어든다. Small 4의 공식 가격이 입력 0.15, 출력 0.60/M 토큰인데, 출력 자체가 짧으니 체감 비용은 스펙보다 더 낮다. 고볼륨 서비스를 운영하는 입장에서는 이 차이가 월 수백~수천 달러로 누적된다.

단, 짧은 출력이 항상 미덕은 아니다. 단계별 설명이나 교육용 응답처럼 풀어쓰기가 품질인 태스크에서는 지나친 압축이 오히려 독이 된다. 분류·추출·요약 같은 고빈도 파이프라인에서 비용 효율을 극대화하고, 설명형 태스크에서는 다른 모델과 혼용하는 전략이 현실적이다. 결국 "어디에 꽂을 건지"가 먼저고, 벤치마크 종합 점수는 그다음이다.

reasoning_effort 하나로 세 가지 모드

reasoning_effort 파라미터 하나로 빠른 응답, 일반 추론, 깊은 사고를 전환한다. 분류·추출엔 none, 코드 생성이나 수학 증명엔 high. 모델 엔드포인트를 여러 개 관리하던 걸 하나로 줄일 수 있다.

from mistralai import Mistral

client = Mistral(api_key="your-key")

# 빠른 모드 — 분류, 추출 같은 단순 작업
resp = client.chat.complete(
    model="mistral-small-latest",
    messages=[{"role": "user", "content": "이 에러 로그 요약해줘"}],
    reasoning_effort="none"
)

# 깊은 추론 — 복잡한 코드 생성, 수학 증명
resp = client.chat.complete(
    model="mistral-small-latest",
    messages=[{"role": "user", "content": "이 DP 풀이의 시간복잡도를 증명해줘"}],
    reasoning_effort="high"
)

에이전트 파이프라인에서 라우팅 로직이 단순해진다는 건 인프라 관점에서 꽤 매력적이다.

셀프호스팅은 아직 부자 전용

Apache 2.0라서 라이선스는 완전히 자유롭다. 상업 이용, 파인튜닝 전부 가능. 여기까지는 훌륭하다.

현실 벽은 하드웨어다. 공식 최소 사양이 H100 4장(HGX), H200이면 2장, DGX B200이면 1대. 개인이나 소규모 팀한테 "Apache 2.0이니까 가져다 쓰세요"라고 하기엔 무거운 요구사항이다. 더 아쉬운 건 llama.cpp 통합이 아직 PR 단계라서 Ollama에서 바로 돌리는 것도 안 된다는 점. vLLM이나 SGLang 기반 서빙은 가능하지만, 양자화된 로컬 버전을 기다리는 사람이 많을 거다.

이 문제가 Mistral만의 것은 아니다. MoE 아키텍처 자체가 전체 파라미터를 메모리에 올려야 하기 때문에, 활성 파라미터가 8B라도 VRAM 점유는 Dense 119B와 비슷하다. 양자화가 해결책이 될 수 있지만 MoE 모델의 양자화는 Dense보다 까다롭다. 전문가마다 가중치 분포가 다르기 때문에 균일한 양자화를 적용하면 특정 전문가의 품질이 무너지는 경우가 있다. GPTQ나 AWQ 기반 커뮤니티 양자화가 나오겠지만, 128개 전문가 각각의 품질을 검증하는 데 시간이 걸릴 수밖에 없다.

솔직한 결론: API로 쓸 거면 가성비가 뛰어나다. 셀프호스팅이 목표라면 당장은 Qwen 3.5 9B 같은 모델이 현실적이고, Small 4의 양자화 생태계가 성숙할 때까지 좀 기다려야 한다.

MoE 진영이 점점 강해지고 있다. DeepSeek V4, Nemotron 3 Super, 그리고 이제 Mistral Small 4 — Dense 모델만 고집할 이유가 줄어들고 있다.